ISO/IEC 42001 is an international standard for an AI management system. It audits how an organization governs AI work, not whether a particular model is safe. For DevOps, that means the pipeline becomes a source of records: what shipped, who approved it, what changed and how it is monitored.
What is being certified?
A management system standard asks for repeatable processes, defined roles, risk assessment, documented controls and regular review. It follows the same logic as other ISO management system standards, which is why organizations that already run an information security management system often extend it rather than start fresh.
The standard text is sold by ISO, so this post does not quote it. Read the purchased text or ask your certification body for the control list before you scope work. Anything below about specific clauses should be checked against that text.
Why does DevOps get pulled in?
Auditors test claims against evidence. Ask yourself which of these an auditor could request on a Tuesday afternoon:
- The list of AI systems in production, with owners.
- The change history for a model version, prompt template or retrieval index.
- The approval record for the last release.
- The monitoring that would show a drift or a failure.
- The rollback path and the last time someone used it.
Most of that already exists in version control, deployment logs and ticketing. The gap is usually tying it together by AI system name.
What is different from ordinary change management?
Three things stand out in AI work. Prompts and configuration change behavior without a code release. Data and model artifacts come from outside, sometimes from public hubs. And evaluation results, not unit tests alone, decide whether a change is acceptable.
So extend your normal controls rather than building a parallel process. Treat prompt files, retrieval settings and model identifiers as versioned, reviewed configuration. Record the evaluation run that justified a release. Pin model and dataset versions by hash where the source allows it.
A constructed example
A platform team runs a summarization service. An auditor asks: "Show me what changed between last month's behavior and this week's." The team finds the deployment record, but the model provider changed an alias silently, and nothing in the repository pinned the version. The fix is small. Pin the model identifier, store the evaluation report next to the release tag, and alert when the provider's reported version differs from the pinned one.
What to do
- Get the control list from the standard or your certification body before estimating effort.
- Create an inventory of AI systems, models, datasets and owners, kept in version control.
- Treat prompts, retrieval settings and model identifiers as reviewed, versioned configuration.
- Store evaluation outputs with the release that used them.
- Add monitoring and a documented rollback for each AI system, and test the rollback.
- Decide which logs hold prompts and tool calls, and set retention with your privacy team.
- Map the work to your existing ISMS so evidence is shared, not duplicated.
Safeguard can scan dependencies and produce inventories, and its policies and gates can block releases that miss agreed checks. Certification itself comes from an accredited auditor.
Quick check
Does ISO 42001 say a model is safe or accurate?
No. It addresses the management system around AI work, so an audit examines governance and records, not model quality on its own.
Where should DevOps start?
With an inventory of AI systems and pinned, versioned configuration, since both feed nearly every other piece of evidence.
Sources
- European Commission, AI Act overview (overview of the risk based approach)
- NIST SP 800-218A, secure development practices for generative AI
- Hugging Face documentation on pickle scanning
Last reviewed: 18 October 2026.
