An AI governance operating model should name who is accountable for AI Act work, who owns each system and each obligation, which forum decides classification, release and incident questions, how decisions are escalated, and how AI governance links to existing risk, data, security and product governance. The model should be documented, proportionate to the organisation, and operated through regular forums and records, not only through a policy document that is never used.
Who is accountable, and for what?
Accountability should be named at a senior level for the AI governance programme as a whole, with owners named for each system, each obligation, and each forum. Senior accountability means the accountable person can allocate resources, resolve conflicts between delivery and compliance, and answer for the programme to the board or to a supervisor. System ownership means a named person can obtain accurate information about a system, challenge its classification, and ensure its file is current. Obligation ownership means a named person is responsible for carrying out a specific duty, such as conformity assessment, registration, or incident reporting, by the date it is due. A model that names only a committee, without individual owners, leaves no one accountable when a deadline is missed or a file is incomplete, and should be avoided.
What forums and decision rights are needed?
Forums should be set up for the decisions the Act requires: classification and scope, risk and requirements, release and conformity, transparency, incidents, and changes. Each forum should have a clear remit, a chair, members with the competence to decide, a decision right, and a record. Decision rights should state who can approve a classification, who can approve a release, who can approve a substantial modification, and who can decide to suspend or withdraw a system. Forums should meet on a cadence that matches the volume of decisions, with an escalation route for urgent decisions between meetings. A forum that meets but cannot decide, because its remit or decision rights are unclear, will push decisions into informal channels where they are not recorded, and the governance file will not reflect how decisions were actually made.
For the broader regulatory framework, see AI governance planning checklist.
How should escalation work?
Escalation should be a defined route, with triggers, timescales, and owners, for questions that cannot be resolved at the working level. Triggers include borderline classification, a failed test, a serious incident, a supplier gap, a legal uncertainty, and a disagreement between teams. The escalation route should lead to a forum or person with the authority to decide, and should require the question to be presented with the facts, the options, the risks, and a recommendation, so that the decision can be recorded with its reasoning. Escalated decisions should be logged, with the date, the decision, and the follow-up actions, and should be communicated to the teams affected. An escalation route that is used only in a crisis, or that is bypassed because it is slow, will not be trusted, and teams will make borderline decisions without the review the model intends.
How does AI governance link to existing governance?
AI governance should link to existing governance for risk, data protection, information security, product safety, procurement, and sectoral compliance, rather than operating as a parallel system. Links should be recorded as shared forums, shared registers, shared assessments, and shared escalation routes, with named liaison owners. For example, a fundamental rights impact assessment should link to a data protection impact assessment, a risk assessment should link to the enterprise risk register, and a supplier assessment should link to procurement due diligence. Linking avoids duplication, ensures that a question raised in one governance process is visible in the others, and prevents a system from being approved in one process while a material issue remains open in another. The links should be documented in the operating model, with the shared records identified.
How is the operating model kept proportionate and live?
The operating model should be proportionate to the organisation's size, the number and risk of its systems, and the complexity of its supply chain. A small organisation with few systems needs a lean model with named owners and a single forum, while a large organisation with many high-risk systems needs a more structured model with several forums and a programme office. Proportionality should be recorded with the reasoning, and the model should be reviewed when the organisation, its systems, or the legal requirements change. The model should be tested by tracing a sample of decisions through the forums, the records, and the follow-up actions, to check that it works in practice. A model that is documented but never tested, or that is not updated when the organisation changes, will not support the governance work it is meant to organise.
Continue with Who must comply with the EU AI Act.
What does this guide not decide?
This guide does not decide what governance structure a particular organisation must adopt, who should be accountable, or whether a decision was correctly escalated. It does not design a committee structure or assess a governance record. Those questions depend on the organisation's size, systems, risks, existing governance, and the obligations that apply to it. An organisation should design its operating model to fit its circumstances, document it, test it with real decisions, and confirm the design with a competent authority or legal adviser where the governance position is material to a release or an incident decision.
Frequently asked questions
Must a small organisation have a large governance committee?
No. The operating model should be proportionate to size, systems and risk. A small organisation needs named owners, clear decision rights, and a forum that can decide, even if that forum is small and meets infrequently, with escalation for urgent questions. Proportionality should be recorded with reasons.
Should AI governance be separate from other governance?
No, in general. AI governance should link to risk, data protection, security, product and procurement governance through shared forums, registers and escalation routes, so that issues are visible across processes and are not approved in one process while open in another.
How is a governance model tested?
Trace a sample of real decisions through the model: from the question raised, through the forum and decision, to the record and follow-up action. Check that owners, decision rights, escalation and records all worked as documented, and record the test and any fix made.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗Commission AI Act Service Desk timeline ↗European Commission AI Act overview ↗