Will ISO 42001 certification disrupt AI product development by distracting my engineers?
Maybe. But there are ways to reduce the impact.
Short answer
Maybe.
Long answer
ISO 42001 is primarily a way to do AI risk management. External auditing is a way to confirm that you do it as the specification requires. ISO 42001 does not, however:
Require you to meet any specific regulatory standard
Tell you what your risk appetite should be
Prohibit any given AI use cases
Some Annex A controls can be technically intensive
With that said, it does require that you at least consider certain controls, detailed in Annex A, as part of your risk management process. The ones most likely to impact engineering organizations and product development due to the technically-intensive nature of implementing them are:
A.4.2 - Resource documentation
A.4.3 - Data resources
A.4.4 - Tooling resources
A.4.5 - System and computing resources
A.6.2.2 - System requirements and specification
A.6.2.3 - Documentation of system design and development
A.6.2.4 - System verification and validation
A.6.2.5 - System deployment
A.6.2.6 - System operation and monitoring
A.6.2.7 - System technical documentation
A.6.2.8 - System recording of event logs
A.7.2 - Data for development and enhancement
A.7.3 - Acquisition of data
A.7.4 - Quality of data
A.7.5 - Data provenance
A.7.6 - Data preparation
Control exclusion may be an option
You may exclude some Annex A controls with appropriate justification. See this post for examples.
Of course, an external auditor doesn’t necessarily need to accept your exclusion justification. And your statement of applicability (SoA) will describe which controls you have implemented. A customer might demand to inspect your SoA and determine your exclusion of a given control was inappropriate (low likelihood but high impact from a business perspective).
Additionally, if you are training or fine-tuning your own models, arguing you can exclude controls A.4.x, A.6.x, and A.7.x would be difficult.
How to minimize the burden on engineering teams
Re-use existing controls
Many controls from SOC 2 and ISO 27001 can be slightly tweaked for ISO 42001 purposes, such as:
Internal audit
Change control
Whistleblowing programs
Competence documentation
Incident response policies and procedures
Use ISO 42001 as a way to document and standardize business-as-usual
Even if you haven’t specifically identified them as a security or compliance control, many organizations with established engineering and data science processes are likely implementing A.4.x, A.6.x, and A.7.x in some form already as:
User stories
Vision documents
Logging and telemetry
Database columns and tags
There is no need to recreate these from scratch specifically for ISO 42001. You may need to tweak your procedures slightly rather than completely revamp them.
Automate
Once you have established procedures in place, the most effective way to implement controls while reducing toil is automation. Some ways to implement this include:
Applying provenance, quality, and bias tags based on data source (A.7.3-4, A.7.6).
Tracking tooling resources with software composition analysis (A.4.4).
Auto-documentation with app-building software tools (A.6.2.7).
Concerned about the burden of ISO 42001 certification on engineering and data teams?
Having implemented all ISO 42001 Annex A controls (and an additional one), StackAware knows all of the challenges involved. But we also know how to surmount them.
Our goal is to minimize disruptions to product development while ensuring you can meet the standard’s requirements. So if you are seeking ISO 42001 certification to:
Improve the likelihood of getting safe harbor under laws like SB 205,
Build trust with customers to accelerate deal closure, and
Manage AI-related risks and societal impacts, then: