ISO 42001 in practice: what your first AIMS actually looks like

ISO 42001 is the first management-system standard for artificial intelligence, and the first six months of implementation reveal patterns that no template can prepare you for. The organisations we have supported through initial certification readiness share a common experience: the technical controls are the easy part. The hard part is sustaining the operational discipline the standard assumes you already have.

The starting point is scope. Most teams instinctively define their AI Management System (AIMS) around "all AI systems in production" and then discover that the definition of an AI system under the standard is broader than they expected. Rule-based automation with a learned component, decision-support tools that were procured rather than built, and third-party features embedded in SaaS platforms all fall within scope once you look closely. We recommend an initial scoping workshop that inventories every system with a machine-learned component, regardless of whether your team built it, and then explicitly excludes items with a documented rationale. Auditors accept a narrow scope; they do not accept a scope that is silent on obvious systems.

The controls that consistently fall over at internal audit are rarely the technical ones. They are the ones that require sustained cross-functional discipline. Risk registers drift out of date within weeks of go-live because no single owner is accountable for keeping them current as models are retrained or repurposed. Human oversight becomes a signature on a change ticket rather than a substantive review. AI impact assessments are written for the initial deployment and never revisited when the roadmap shifts the system's purpose or user base.

The single most valuable artefact we have seen teams produce is a lightweight "AI system record" — one page per system, updated quarterly, covering purpose, data sources, model provenance, known limitations, human oversight arrangements, and the date of the last impact review. It is not glamorous, but it is what an auditor asks for first and it is what internal stakeholders reach for when a question lands unexpectedly.

Governance structures matter more than policies. A monthly AI governance forum with representation from product, engineering, legal, and a senior risk owner will catch more issues than a fifty-page policy that nobody reads. The forum's minutes become audit evidence in their own right. We recommend a standing agenda that covers new systems entering scope, changes to existing systems, incidents or near-misses, and a rolling review of the risk register.

The shortcuts we have seen backfire are predictable. Copying an ISO 27001 risk methodology wholesale ignores the specific harms the standard cares about — bias, explainability, safety, and the rights of affected individuals. Delegating the AIMS entirely to a compliance function detaches it from the engineering decisions that determine whether the controls actually work. And treating certification as the goal, rather than the by-product of a working management system, produces a paper trail that collapses under the first real incident.

Six months in, the teams that are thriving under ISO 42001 have three things in common. They have a named senior owner who chairs the governance forum and is willing to say no to a deployment. They have an engineering culture that treats impact assessments as design inputs, not compliance overhead. And they have made peace with the fact that the AIMS is a living system: it will look different in twelve months, and that is a sign of health rather than failure.

If you are at the start of your ISO 42001 journey, our advice is to resist the temptation to build the full documentation set before you have a working governance rhythm. Establish the forum, inventory your systems, write short impact assessments for the highest-risk ones, and let the rest of the artefacts follow from real operating experience.