AI Governance Framework for Enterprise

An AI governance framework is the set of principles, named roles, policies, controls and lifecycle gates an organisation uses to decide what AI it builds or buys, how each system is risk-classified, who signs off on it, and how it is monitored and retired. It is workable only when three things exist together: a named owner for every system, a risk-tiering rule that is actually applied before deployment, and an evidence trail that survives an audit without relying on anyone's memory. A policy document alone is not a framework; it becomes one once it is run as an operating model with gates, owners and records.

What does an enterprise AI governance framework actually contain?

Every credible framework rests on the same governing principles, whichever standard it is built against. ISO/IEC 42001, the OECD AI Principles, the NIST AI Risk Management Framework and the EU AI Act's stated aims converge on the same short list. Treat these as the DNA the rest of the framework operationalises, not a separate ethics chapter to file and forget:

• Accountability. A named individual owns every system, not "the AI team".
• Transparency and explainability. Proportionate to risk, not uniform across every system.
• Fairness and non-discrimination. Bias testing across the lifecycle, not a one-off check at launch.
• Human oversight. A human can intervene, override or stop the system.
• Robustness, safety and security. Including resilience against adversarial inputs.
• Privacy and data governance. Lawful basis, data minimisation, provenance.
• Auditability. Decisions and the data behind them are traceable after the fact.

These principles are then expressed as a policy architecture, nested from board level down to system level:

• AI policy (board-level). States principles, risk appetite and scope, including what counts as "AI" for policy purposes, which must cover third-party and embedded AI, not only systems built in-house.
• AI risk classification standard. The rule for sorting each system into a risk tier. The EU AI Act's unacceptable, high, limited and minimal risk tiers are the most worked-out public taxonomy available and a genuinely useful reference model even for organisations outside the EU.
• Acceptable use policy. Governs staff use of generative AI tools day to day: what data classification may or may not be pasted into a public model, and what disclosure is required.
• Model and system-specific standards. Data governance, testing and validation, human-in-the-loop requirements and documentation requirements, keyed to risk tier.
• Third-party and vendor AI standard. Due diligence questions for any AI embedded in a purchased product or service, which is where governance and procurement intersect.
• Incident response and escalation procedure. What happens when a system produces a harmful, biased or materially wrong output.

Who is accountable for AI governance, from the board down?

This is the layer most competing guides handle vaguely. It should not be vague, because most enterprise AI failures trace back to no one individual owning the specific system that failed.

The single most practically useful idea in this structure is the named system owner. A committee can approve a use case, but only a named person can be expected to notice drift, respond to an incident, or answer for a specific model's behaviour six months after launch.

What controls does a working AI governance framework need?

Principles and roles mean nothing without controls a team can actually run and an auditor can actually test. The core set:

• Pre-deployment risk assessment and sign-off, gated by risk tier, before any system reaches production.
• Data governance controls: provenance, lawful basis, data quality checks, and bias or representativeness testing on both training and evaluation data.
• Model documentation: intended use, known limitations, a training data summary and evaluation results. This mirrors both ISO/IEC 42001's documentation requirements and the EU AI Act's technical documentation obligations for high-risk systems.
• Human oversight controls: defined override points, escalation thresholds, and clear "stop" authority resting with a named role.
• Monitoring controls: drift detection, performance degradation alerts, and logging of inputs and outputs sufficient to reconstruct a decision after the fact.
• Security controls: access control over models and training data, adversarial testing, and supply-chain checks on any third-party model or component.
• Change control: a re-assessment trigger whenever a model is retrained, fine-tuned, or its use case expands beyond what was originally approved.

How does an AI system move from proposal to production safely?

A framework becomes an operating model once it is run as a gated lifecycle, each gate with a named owner and a clear exit criterion. Systems that skip a gate should not be allowed to proceed, regardless of business pressure.

• Intake and proposal. The new use case is logged and given an initial risk screen. Owner: business sponsor.
• Risk classification. Formal tiering against the risk classification standard. Owner: governance committee, or a delegated risk function for lower tiers.
• Design and build review. The data governance and fairness testing plan is agreed before build starts, proportionate to the assigned tier.
• Pre-deployment assurance. Testing evidence is reviewed, documentation is complete, the human oversight mechanism is defined, and sign-off is recorded. Owner: system owner plus second line for higher tiers.
• Deployment. The system is added to the model inventory and monitoring is switched on.
• Ongoing monitoring. A performance and bias review cadence set by risk tier, for example continuous review for high-risk systems and periodic review for limited-risk systems.
• Change or retrain trigger. Any material change re-enters the process at the design and build review gate.
• Retirement and decommission. A formal sunset with records retained per the organisation's retention policy.

Why does an AI model inventory matter, and what should it record?

Most organisations that fail an AI audit fail at the first question: they cannot produce a complete list of the AI they actually run, including AI embedded inside third-party SaaS products they never formally procured as "AI". The inventory is a distinct, non-negotiable artefact, not a by-product of the policy set.

A usable inventory records, per system: owner, purpose, risk tier, data used, deployment status, date of last review, and whether the system is proprietary, licensed, or embedded in a vendor product. This is also the first artefact ISO/IEC 42001 auditors and EU AI Act conformity assessors ask to see, because it demonstrates whether the organisation actually knows what it is governing before it demonstrates how well it governs it.

How does this map to ISO/IEC 42001 and the EU AI Act?

ISO/IEC 42001:2023 is the world's first international standard specifically for an AI management system, published by ISO/IEC in December 2023. It follows the same high-level structure family as ISO 27001 and ISO 9001: clauses 1 to 3 cover scope, references and terms, and the certifiable requirements sit in clauses 4 to 10, covering context of the organisation, leadership, planning, support, operation, performance evaluation and improvement. The clause worth naming specifically is the AI system impact assessment, introduced at clause 6.1.4 and performed at clause 8.4, because it is genuinely AI-specific rather than a repackaged security control borrowed from ISO 27001. Certification is voluntary and issued by accredited third-party certification bodies. It is a credible external benchmark to work towards; it should never be claimed on an organisation's own behalf unless it has actually been certified.

The EU AI Act's risk-tier structure is worth using as a mental model even for organisations outside the EU, because it is the most developed public risk taxonomy available:

• Unacceptable risk: prohibited outright, including social scoring, certain manipulative or exploitative systems, and some biometric categorisation and untargeted facial-recognition scraping.
• High risk: systems that are safety components in regulated products, or that fall within the Annex III use-case list, covering biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential services including credit scoring, law enforcement, migration and border control, and the administration of justice. Subject to the core obligations in Articles 9 to 49: a risk management system, data governance, technical documentation, record-keeping, transparency to users, human oversight, and accuracy, robustness and cybersecurity requirements, plus conformity assessment before market placement.
• Limited risk: transparency obligations only under Article 50, such as disclosing that a user is interacting with an AI system or that content is AI-generated, covering cases like chatbots and deepfakes.
• Minimal risk: the majority of AI systems, including spam filters, recommendation engines and basic games, carry no mandatory obligations.

The current, settled position on timing: the original deadline for the Annex III high-risk obligations was 2 August 2026. Following the EU's Digital Omnibus on AI, stand-alone Annex III high-risk obligations are now due on 2 December 2027, and high-risk AI embedded in regulated products under Annex I is deferred to 2 August 2028. Article 50 transparency obligations largely remain on their original schedule and have not been deferred. This is a build window, not a reprieve: the underlying proof requirements of risk management, documentation, human oversight and conformity evidence survive the date move intact, so the governance work described in this guide does not change because a deadline moved.

Two further reference points are worth a brief, neutral mention. The NIST AI Risk Management Framework, AI RMF 1.0, is the American counterpart: voluntary, and organised around four functions, Govern, Map, Measure and Manage. The OECD AI Principles sit a level above both, as the values-level reference most national AI policy frameworks trace back to.

How is an AI governance framework audited?

Audit and assurance work at two levels. Internal audit should test the framework itself on a set cadence, not only the individual systems running under it, because a framework that looks complete on paper can still fail to operate as designed. External assurance runs through two distinct routes: ISO/IEC 42001 certification, which involves an accredited third-party certification body auditing the AI management system directly, or a self-attested framework with no external certification. Both are legitimate positions; the difference is what each can be shown to a customer, regulator or investor. ISO/IEC 42001 certification is voluntary, but it is increasingly requested inside procurement processes and RFPs, which makes it a commercial as well as a compliance decision.

Either route depends on the same evidence trail: risk assessments, sign-offs, monitoring logs and incident records, the documentation set that answers "prove it" during a regulatory inquiry, a customer audit or a board question. It is worth distinguishing generic ISO 27001-style compliance evidence, which most enterprises already hold, from the AI-specific pieces an AI-focused audit will actually ask for: impact assessments, bias testing records and human oversight logs. An organisation with strong information security evidence and no AI-specific evidence will still fail an AI governance audit.

Where do sovereignty and auditability fit for regulated sectors?

A governance framework is only as strong as the evidence trail behind it. The genuine test is whether an organisation can reconstruct, after the fact, why a specific AI system produced a specific output, without relying on a vendor's word for it. That question is independent of any vendor and it is where deployment architecture becomes a legitimate governance design choice rather than a sales angle: whether a system runs on-premises or in a private cloud, whether data ever leaves the organisation's control to reach a third-party model provider, and whether the audit trail can be independently verified rather than taken on trust from the vendor that generated it.

Enterprises handling regulated or sensitive data increasingly weigh deployment sovereignty, meaning on-premises or private-cloud hosting with no data egress to a third-party model provider, as part of their AI risk classification and vendor due-diligence standard, alongside the more familiar model-risk controls. That is true whichever vendor or platform an organisation ultimately chooses.

Mickai is one credible route for organisations that want deployment control and an independently verifiable audit trail built into the operating system itself, rather than assembled afterwards from vendor attestations. We built our sovereign intelligence operating system around that requirement: on-premises or private-cloud deployment options, and an audit chain designed to be checked rather than taken on trust. That is one option among several a governance framework of this kind should evaluate on its merits, alongside self-hosted open-source deployments, hyperscaler AI governance tooling such as cloud-native model registries and policy engines, and dedicated GRC platforms.

The infrastructure layer that makes an evidence trail provable, not just written down, is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

What is an AI governance framework?

An AI governance framework is the combined set of principles, named roles, policies, controls and lifecycle gates an organisation uses to decide what AI it builds or buys, classify each system's risk, approve its deployment, and monitor and retire it. It only functions as a framework once it is run as an operating model with named owners and evidence, not left as a static policy document.

Who should own AI governance in an enterprise, the board or IT?

Neither owns it alone. The board sets risk appetite and approves the policy, an executive sponsor such as a CIO, CDO or Chief AI Officer runs the AI management system day to day, and a named owner is assigned to every individual system. IT typically builds and operates systems but should not be the sole approver of their risk classification, which sits with a cross-functional governance committee.

Is ISO/IEC 42001 certification mandatory?

No. ISO/IEC 42001 certification is voluntary, issued by accredited third-party certification bodies. It is not a legal requirement in any jurisdiction, but it is increasingly requested inside procurement and RFP processes as external evidence that an AI management system is in place and independently assessed.

Is the EU AI Act's high-risk deadline still 2 August 2026?

No. That was the original deadline and it has moved. Following the EU's Digital Omnibus on AI, stand-alone Annex III high-risk obligations are now due on 2 December 2027, and high-risk AI embedded in regulated products under Annex I is deferred to 2 August 2028. Article 50 transparency obligations, such as disclosing AI-generated content, largely remain on their original schedule.

What is an AI model inventory and why does it matter?

An AI model inventory is a record of every AI system an organisation runs, including AI embedded in third-party products, listing owner, purpose, risk tier, data used, deployment status and last review date. It matters because most organisations that fail an AI audit fail at this first step: they cannot produce a complete list of what AI they actually run, and it is the first artefact ISO/IEC 42001 and EU AI Act assessors typically ask to see.

What is the difference between an AI governance policy and an acceptable use policy?

An AI governance policy is the board-level document setting principles, risk appetite and the overall scope of what counts as AI for governance purposes. An acceptable use policy sits underneath it and governs day-to-day staff use of AI tools, such as what data may be entered into a public generative AI system and what must be disclosed. The governance policy is the constitution; the acceptable use policy is one of several operating documents beneath it.