On 2 August 2025, a significant tranche of the EU AI Act’s obligations became applicable. A year on, many organisations have learned an uncomfortable lesson: the date that felt like a finish line was, in fact, a starting gun. The documentation packs assembled in the weeks before the deadline are now ageing. Models have been retrained, vendors have shipped new versions, use cases have multiplied, and the staff who understood the original risk assessments have moved on. The compliance evidence that looked complete in August is already drifting away from operational reality.
This is the central insight that separates organisations who treat regulation as a one-off project from those who treat it as a discipline: AI compliance is not something you complete, it is something you operate. Risk management, human oversight, post-market monitoring and technical documentation are not deliverables to be signed off and filed. They are recurring duties that must be performed for the life of every AI system you deploy. The most durable way to discharge those duties consistently, at scale, and in a way you can demonstrate to a regulator, a customer or an auditor, is to build a proper management system around them.
That is precisely what an ISO 42001 AI management system gives you. ISO/IEC 42001:2023 is the world’s first certifiable management-system standard for artificial intelligence, and it provides the scaffolding to turn ad-hoc compliance activity into a repeatable, improvable enterprise AI governance operating model. This article sets out, from a practitioner’s perspective, how to build that operating model, how it maps onto your EU AI Act obligations, how it integrates with management systems you may already run, and what the certification journey looks like.
This is a practitioner’s view of how to structure governance, not legal advice. Where your specific regulatory exposure is at stake, take qualified counsel.
Why a Management System, Not a Compliance Binder
The instinct when faced with a regulation is to produce a document: a policy, a register, a checklist. Documents are necessary, but on their own they decay. A management system is different in kind. It is a structured set of policies, roles, processes and controls, together with the mechanisms to measure whether those things are actually working and to improve them when they are not.
ISO/IEC 42001 follows the same Annex SL “high-level structure” that underpins ISO 27001, ISO 9001 and the other modern ISO management-system standards. If you have implemented any of those, the architecture will feel familiar. The standard is organised around a consistent set of themes:
- Context of the organisation — understanding the internal and external issues relevant to your use of AI, the needs of interested parties (customers, regulators, data subjects, affected persons), and defining the scope of the AI management system (AIMS).
- Leadership and policy — top management commitment, an AI policy that sets direction, and clearly assigned organisational roles, responsibilities and authorities.
- Planning — addressing risks and opportunities, and crucially the two processes that distinguish an AIMS from any other management system: the AI risk assessment and the AI system impact assessment.
- Support — the resources, competence, awareness, communication and documented information needed to make the system function.
- Operation — operational planning and control, executing the risk treatment and impact assessment processes across the AI system lifecycle.
- Performance evaluation — monitoring, measurement, internal audit and management review.
- Improvement — handling nonconformities and driving continual improvement.
Alongside this management structure, ISO/IEC 42001 includes a normative annex (Annex A) of reference controls covering areas such as AI policies, internal organisation, resources for AI systems, impact assessment, the AI system lifecycle, data management, information for interested parties, use of AI systems, and third-party relationships. A companion guidance annex elaborates on how to implement those controls. You select and justify the controls relevant to your context, in much the same way you produce a Statement of Applicability under ISO 27001.
The defining feature of any management-system standard is the Plan-Do-Check-Act (PDCA) loop, and it is what turns governance from a binder into an operating model. You plan by setting policy, objectives and risk assessments. You do by implementing controls across the lifecycle. You check through monitoring, measurement and internal audit. You act by correcting nonconformities and improving the system. Then the loop runs again. This continual-improvement cycle is the mechanism that keeps your governance aligned with reality as your AI estate, your suppliers and the regulatory landscape all change around you.
The Anatomy of an AI Governance Operating Model
Building an AIMS in practice means standing up several interlocking components. None of them is exotic, but their combination is what produces durable governance.
Policy and objectives. A concise AI policy, owned by top management, that states your organisation’s principles for developing and using AI: lawfulness, safety, fairness, transparency, accountability and human oversight. From the policy flow measurable objectives — for example, that every AI system in scope has a current impact assessment, or that human-oversight controls are tested on a defined cadence.
Roles and accountabilities. This is where many AI initiatives quietly fail. An operating model assigns named accountability: an executive sponsor, an AI governance lead or committee, system owners responsible for individual AI systems, and clear escalation paths. The RACI for each AI system should make it unambiguous who decides to deploy, who monitors in production, and who can pull a system out of service.
AI risk assessment and impact assessment processes. The AIMS requires a repeatable process to identify and treat risks arising from AI systems, and a distinct process — the AI system impact assessment — to evaluate consequences for individuals and groups, including affected third parties. ISO/IEC 42005 provides dedicated guidance on conducting AI system impact assessments, covering when to perform them, what to consider, and how to document and integrate the results. Treating these as standing processes, triggered by defined events such as a new use case or a material model change, is what keeps the analysis fresh rather than frozen at the moment of first deployment.
Lifecycle controls. Governance has to attach to the AI system across its whole life: problem definition, data sourcing and preparation, model development or selection, validation, deployment, operation, monitoring and decommissioning. Controls at each stage — data quality checks, validation criteria, release gates, logging, drift monitoring — ensure that the system that runs in production matches the system that was assessed.
Supplier and third-party management. Almost every organisation now consumes AI through third parties: foundation-model APIs, embedded AI features, fine-tuned vendor models. The AIMS extends governance to these relationships, requiring due diligence, contractual clarity on responsibilities, and ongoing oversight of suppliers whose components materially affect your AI systems’ behaviour.
Monitoring and continual improvement. Finally, the system watches itself. Performance metrics, incident logging, internal audits and management reviews feed the “check” and “act” phases of PDCA, generating corrective actions and improvements that keep the operating model honest.
How ISO/IEC 42001 Operationalises EU AI Act Obligations
Here is the strategic payoff. The EU AI Act imposes a set of duties that are, by their nature, ongoing. ISO/IEC 42001 does not map one-to-one onto the Act — it is a voluntary international standard, not a harmonised standard that grants a presumption of conformity — but it provides the operational machinery to discharge those recurring duties systematically. Think of the Act as defining what you must achieve and the AIMS as defining how you reliably keep achieving it.
Consider the recurring obligations the Act places on providers and, in their own way, deployers of high-risk systems:
- Risk management as a continuous process. The Act expects a risk management system that runs throughout the lifecycle, not a single assessment. The AIMS planning and operation clauses, plus the impact-assessment process, provide exactly this rhythm.
- Data governance. Requirements around training, validation and testing data map naturally onto the AIMS data-management controls and lifecycle stages.
- Technical documentation and record-keeping. The Act demands documentation that is kept up to date, and automatic logging. The AIMS “documented information” discipline and lifecycle logging controls make maintaining that documentation a routine output of the system rather than a periodic scramble.
- Human oversight. The Act requires that high-risk systems can be effectively overseen by humans. Within the AIMS, human-oversight measures become controls that are designed, assigned to owners, tested and reviewed.
- Post-market monitoring. Providers must actively monitor systems in the field and feed findings back. This is the PDCA “check and act” loop in regulatory language — the AIMS already gives you the monitoring, incident-handling and improvement processes to satisfy it.
- Accuracy, robustness and cybersecurity. These map onto validation, performance evaluation and the integration points with your information security controls.
The point is not that certification to ISO/IEC 42001 makes you EU AI Act compliant — it does not, and any consultancy claiming otherwise should be treated with caution. The point is that an organisation running a mature AIMS already performs, as business as usual, most of the activities the Act requires evidence of. When the regulator or your enterprise customer asks how you manage AI risk, “here is our certified management system and its records” is a far stronger answer than a folder of point-in-time assessments.
Integrating With ISO 27001 and ISO 9001
Few organisations adopting ISO/IEC 42001 are starting from a blank sheet. Many already operate an ISO 27001 information security management system (ISMS) or an ISO 9001 quality management system, and the deliberate alignment of all these standards to the Annex SL structure means they integrate cleanly rather than competing.
The overlaps are substantial and worth exploiting. Leadership commitment, document control, competence and awareness, internal audit, management review, nonconformity and corrective action, and continual improvement are essentially common requirements across ISO 27001, ISO 9001 and ISO 42001. If you already run those mechanisms for one standard, you extend rather than duplicate them. A single internal audit programme can cover all three; one management review meeting can take all three on its agenda; one corrective-action process can handle findings from any of them.
The relationship with ISO 27001 is especially close. AI systems are information systems, and many AI risks — data confidentiality, integrity of training data, security of model endpoints, access control — are information-security risks that your ISMS may already address. The AIMS then adds the distinctly AI-shaped concerns the ISMS does not cover: fairness and bias, explainability, the societal impact assessment, autonomy and human oversight, and the behaviour of models that change over time. ISO 9001’s process discipline, meanwhile, complements the lifecycle and quality controls within the AIMS.
In practice we recommend building an integrated management system with a shared core of common processes and standard-specific modules layered on top, rather than three parallel systems that each demand their own bureaucracy. This is both cheaper to run and more credible, because governance that is woven into how the business already operates is governance that actually gets done.
The Certification Journey
If you choose to pursue certification — and even if you do not, the path is a useful implementation roadmap — the journey follows a recognisable sequence.
Gap analysis. You begin by assessing your current practices against the requirements of ISO/IEC 42001 and its Annex A controls. The output is a prioritised picture of what exists, what is partial and what is missing. For organisations with a mature ISMS, much of the management-system machinery is already present; the gaps tend to cluster around the AI-specific processes — impact assessment, lifecycle controls and supplier oversight.
Implementation. You then build out the AIMS: writing the AI policy, defining scope, establishing roles, standing up the risk and impact assessment processes, implementing the selected controls and producing your Statement of Applicability. This is also where you create the evidence trail — records, logs and assessments — that a certification audit will examine.
Internal audit and management review. Before any external body assesses you, the standard requires you to audit yourself. An internal audit tests whether the system as designed is actually operating, and a management review confirms that leadership has examined performance and committed to improvements. These are not box-ticking exercises; they are your first genuine run of the PDCA loop and your best opportunity to fix problems cheaply.
Certification audit. An accredited certification body conducts the external assessment, typically in two stages: a Stage 1 readiness review of your documentation and design, followed by a Stage 2 audit of implementation and effectiveness in practice. Major nonconformities must be resolved before a certificate is issued.
Surveillance and recertification. Certification is not permanent. Surveillance audits, usually annual, confirm that the system continues to operate and improve, with a fuller recertification on a multi-year cycle. This ongoing scrutiny is, fittingly, the external mirror of the internal continual-improvement discipline — and the clearest demonstration that you are running an operating model rather than having completed a project.
Scaling the Operating Model
The strongest argument for the management-system approach reveals itself over time. The first AI system an organisation governs always feels disproportionately expensive, because you are building the machinery as well as governing the system. The second is cheaper. By the tenth, the marginal cost of bringing a new AI system under governance is low, because the processes, templates, roles and controls already exist. You are no longer inventing governance each time; you are running a system through it.
This is what makes an enterprise AI governance operating model a genuine strategic asset rather than a compliance cost centre. As AI proliferates across an organisation — from a handful of pilots to dozens of production systems embedded in products and operations — an ad-hoc approach scales linearly at best and collapses at worst. A management system scales sub-linearly: a central AI register and risk-tiering process route each new system to the appropriate level of scrutiny, lightweight controls handle low-risk uses, and the heavyweight impact-assessment and oversight machinery is reserved for the high-risk systems that warrant it.
Maturity then compounds. The data your monitoring generates improves your risk models. Patterns from past impact assessments accelerate new ones. Lessons from incidents harden your controls. Supplier assessments build into a reusable knowledge base. Over a few cycles of PDCA, governance stops being a brake on AI adoption and becomes the thing that lets the organisation adopt AI faster and more safely, because every stakeholder — board, customers, regulators, staff — can trust that there is a system catching the risks. That is the difference between surviving the next regulatory deadline and building a durable capability that turns responsible AI into competitive advantage.
How McKenna Consultants Can Help
McKenna Consultants brings 22 years of software engineering discipline to the practical work of building AI governance that holds up in production. As an AI governance consultancy in the UK, we sit at the intersection that matters: deep technical understanding of how AI systems are actually built, deployed and monitored, combined with a working knowledge of the management-system and regulatory landscape your governance has to satisfy.
We help organisations move from compliance-as-a-project to AI-governance-as-an-operating-model — running pragmatic gap analyses against ISO/IEC 42001, designing an AI management system that integrates cleanly with any ISO 27001 or ISO 9001 systems you already operate, building the risk and impact-assessment processes and lifecycle controls that operationalise your EU AI Act duties, and helping your teams develop the internal capability to run and improve the system over time. Whether you are governing your first high-risk system or scaling oversight across a growing AI estate, we can help you build something durable.
If you are wrestling with how to turn the next regulatory deadline into a lasting capability, we would welcome a conversation. Get in touch with McKenna Consultants to talk through where you are and what a workable AI governance operating model could look like for your organisation.
This article reflects our practitioner perspective on AI management systems and governance. It is not legal advice; for decisions about your specific regulatory obligations, please consult qualified legal counsel.
