GAICC AI Conference & Awards 2026 "Governing the Future – Building Responsible, Safe and Human-centric AI"
GAICC AI Conference & Awards 2026 "Governing the Future – Building Responsible, Safe and Human-centric AI"
One management system, mapped to every regime — EU AI Act, NIST and ISO — through the crosswalk. Build the evidence once; demonstrate it to many.
Governs hybrid human + autonomous-agent teams as a first-class capability — the frontier where today’s standards still lag.
Hub-and-spoke plus three lines of defence, with the roles, cadence and artifacts to actually run governance — not a list of things to do.
A scoreable maturity model to place yourself, a sequenced roadmap to advance, and a credential for every layer.
Governance and its roles span every layer; a continuous loop runs across the top; the management system drives the middle; foundations hold the base. Click any element for its article — where the underlying standards live. Flip to Future-ready to see how it governs AI-agent teams.
Every layer and actor of AI governance on one canvas — the accountability layer, the management system, the lifecycle, risk and assurance, and the people who run it. Select a part above to focus on one accountability layer in context.
For Directors, the C-suite and the AI oversight committee.
The accountability layer: who sets AI strategy and risk appetite, who is answerable when something goes wrong, and how the board keeps AI on its agenda. Even when autonomous agents do the work, a named human stays accountable.
For The AI governance lead and the central function — your Center of Excellence.
The central hub that owns the management system: policy, the control framework, an inventory of every AI system, agent and workflow, and the standards everyone builds within. Business units run as spokes inside the rails it sets.
For Product teams, system owners, ML and AI engineers — and the AI agents themselves.
Where AI is built and run. Governance follows each system across its lifecycle, with controls applied where they belong. The operators are increasingly a mix of people and supervised autonomous agents.
For Risk, compliance, internal audit and the audit committee.
The independent view: assessing AI risk and impact, testing that controls work, and giving the board assurance that the programme runs as designed — through the three lines, ending in independent audit and certification.
For HR and L&D, function leads and embedded AI champions.
How governance lands in real teams: the roles people play, the credentials that build the skill, and the function-level playbooks — legal, HR, finance, procurement — that turn policy into daily practice as federated spokes.
Direct → Assess → Operate → Improve — a continuous loop across every layer.
The Board & Executive layer is where AI strategy and risk appetite are set, where a single executive is made answerable, and where the board keeps AI as a standing item. This is the governing body in the three-lines sense — and even as autonomous agents take on real work, accountability stays with a named human.
Every other part of the framework exercises authority that this layer either created or did not. A governance function without board authority can document its concerns and cannot act on them. A control set nobody at the top has approved is a set of suggestions.
The failure this layer prevents is subtle, because it does not look like a failure. An organisation can have an AI governance team, a policy, an inventory and a review forum, and still have no one who is answerable when something goes wrong. Responsibility is spread across a committee, and a committee cannot be held to account: in any dispute each member can point at the others, and in an incident nobody has to explain.
This becomes sharper as systems become autonomous. When an agent takes an action nobody individually approved, the question “who is answerable?” has to have an answer that was decided in advance. If it was not decided here, it will be decided afterwards, by someone else, under worse conditions.
Directors, the C-suite, and the AI oversight or risk committee.
The distinction that matters most here is between responsibility, which can be distributed widely, and accountability, which cannot be distributed at all. Many people are responsible for AI governance working. Exactly one person is accountable for whether it does.
Boards govern risk, obligation and licence to operate. They do not govern technology, and reporting that asks them to will be received politely and acted on rarely. The cadence should put four things in front of them and ask for a decision on at least one.
| What the board sees | The question it answers |
|---|---|
| Portfolio movement | What changed in the AI estate since last time, by risk tier and autonomy level |
| Risk and incidents | What happened, what it revealed, and what changed as a result |
| Assurance findings | What independent testing found, and what is still open beyond a cycle |
| Regulatory horizon | What is coming, and whether existing controls already cover it |
Risk appetite set at this layer is only worth what a delivery team can do with it. “We take a prudent approach to AI” decides nothing. Appetite has to be expressed so that somebody at a decision gate can apply it without escalating — which classes of use are acceptable, which require additional assurance, and which are refused outright.
Red lines are the fastest-acting expression of appetite, because they resolve a whole class of proposals without analysis. Boards are often reluctant to name them, on the grounds that they sound negative. They are the most useful sentence the board will write.
In an agent-dominated decade the board’s role shifts from approving individual systems to setting the limits the whole control plane operates within: autonomy thresholds, escalation triggers and stop conditions. Reviewing systems one at a time does not scale past a few dozen; setting the envelope inside which thousands operate does.
| Evidence | What it demonstrates |
|---|---|
| Board minute recording the mandate and the accountable executive | That accountability sits with a person |
| Approved AI policy with risk appetite and red lines | That direction was set at the top |
| Board reporting packs across cycles | That oversight is continuous rather than occasional |
| Minuted decisions traceable into changed controls | That the loop closes between evidence and direction |
| Recorded autonomy limits per class of system | That the envelope is governed |
| Audit committee papers and internal audit reports | That independence is preserved structurally |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXBoard reporting pack outlineThe pack that carries oversight evidenceDownloadDOCXAI Policy templateThe instrument through which the board sets directionDownload| Role | Definition |
|---|---|
| Board & governing body | The body with ultimate oversight of AI — setting risk appetite, approving policy and holding management to account. |
| Accountable executive | The single named senior leader answerable for the AI-governance programme, with the authority and budget to run it. |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceWriting an AI policy that will actually be adoptedHow to Write an AI PolicyRelated standards. ISO/IEC 38507 (governance implications of AI for the governing body) · ISO/IEC 42001 clause 5 (leadership) and clause 9.3 (management review) · NIST AI RMF — the Govern function.
Related articles. Govern, accountability & roles · The Governance Core · Risk, Assurance & Audit · The assurance rhythm · Phase 1 · Mobilize & mandate
The Governance Core is the central hub — your AI Governance Office or Center of Excellence — that owns the management system: policy, the control framework, the inventory of every AI system, agent and workflow, and the standards everyone builds within. Business units run as spokes inside the rails it sets.
Federated governance without a hub produces as many interpretations of the policy as there are business units, five incompatible evidence formats, and no way to answer a regulator’s question at the organisational level. Centralised governance without spokes produces a queue, and delivery teams route around queues.
The hub resolves this by owning the standard rather than the decisions. It writes the rails; the spokes drive inside them. That distinction is what lets one small team govern an estate it could never individually review.
The test of whether a hub has drifted back to centralised is simple and worth running quarterly: is headcount growing in proportion to the number of governed systems? If it is, the hub is doing throughput work rather than leverage work, and it will hit a ceiling.
The AI governance lead and the central function — the Center of Excellence, or AI Governance Office.
Rails are the written boundary between what a spoke may decide and what must escalate. They are the single most under-produced artefact in AI governance, and their absence is why hubs become queues: without them, a spoke either escalates everything, which recreates the bottleneck, or escalates nothing, which recreates the fragmentation.
The inventory is the hub’s most load-bearing asset, and the one thing it should never delegate. Policy scope is drawn from it, risk is prioritised by it, controls are applied to what is in it, audit samples from it, and the board counts it. The hub owns the data model, the completeness and the maintenance path even where the spokes populate the rows.
As agents proliferate, the registry has to cover more than systems. An agent that invokes tools at runtime, an automated workflow that chains three models, a purchased product whose vendor switched on a new feature — all of these are governable objects, and none of them announce themselves.
The hub is smaller than people expect. Its work is leverage: standards, tooling, the evidence model, assessment calibration and aggregate reporting. Governance analysts and coordinators do most of the day-to-day — maintaining the inventory, running assessments, tracking actions — and this is the field’s main entry point, requiring policy, risk and oversight skills rather than ML engineering.
The hub stops being an approval desk and becomes a control plane: policy-as-code, automated guardrails and continuous observability, so governance keeps pace with machine-speed volume rather than bottlenecking it. The direction of travel is from requesting compliance to enforcing it at the point where systems are built and deployed.
| Evidence | What it demonstrates |
|---|---|
| AI Governance Office remit and resourcing decision | That the hub is defined rather than assumed |
| Documented rails and escalation rules | That the spoke/hub boundary is explicit |
| Live AI registry covering systems, agents and workflows | That the estate is known and maintained |
| Control framework and Statement of Applicability | That the standard exists and is owned |
| Standards, templates and evidence formats issued to spokes | That the hub works by leverage |
| Spoke-to-hub forum minutes with control revisions | That the feedback route is live |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXStatement of ApplicabilityThe core owns and maintains itDownloadXLSXAI System Inventory registerThe core owns and maintains itDownload| Role | Definition |
|---|---|
| AI governance lead | Runs the day-to-day governance function — the central hub that owns policy, standards and the AI inventory. |
| Governance analysts & coordinators | The analysts and coordinators who do the day-to-day governance work — maintaining the AI inventory, running assessments, tracking actions and supporting the leads. This is the field’s main entry point: policy, risk and oversight skills, no ML engineering required. |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceExtending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerRelated standards. ISO/IEC 42001 clauses 4 to 8 and Annex A internal organization controls · ISO/IEC 42001 clause 6.1.3 (Statement of Applicability) · the three-lines model as applied to AI.
Related articles. The AI management system · Control domains · Board & Executive · Delivery & Operations · Hub-and-spoke: federating AI governance · Phase 2 · Operating model & CoE
Delivery & Operations is where AI is actually built and run — the first line that owns risks and operates controls day to day. Governance follows each system across its lifecycle, with controls applied where they belong rather than bolted on at the end. The operators are increasingly a mix of people and supervised autonomous agents.
Every piece of evidence the rest of the framework relies on is created here. The hub can design a control; only the first line can operate it. The third line can test a control; there is nothing to test unless this layer produced a trace.
That makes the first line the place where governance either becomes real or quietly does not. A control that exists in the control framework and has no attachment point in how work actually happens is a control in name only — and it will pass a documentation review and fail an audit.
The single most useful design principle for this layer: evidence should be a by-product of the work, not a separate activity. An approval recorded because the workflow required it before proceeding costs nothing extra at the moment it happens and is durable. An approval reconstructed from an email thread six months later costs a great deal and convinces nobody.
Product teams, system owners, ML and AI engineers — and the AI agents themselves.
The lifecycle article sets out the seven stages and the four decision gates. What matters at this layer is that each control has a specific attachment point — a step in the actual delivery process where it fires, blocks or records.
| Stage | What the first line produces here |
|---|---|
| Inception | Statement of intended purpose, limits and risk tier; a named owner |
| Design | Design records showing controls and human-oversight points; data provenance |
| Development | Impact assessment for higher-risk and autonomous systems; build evidence |
| Verification | Test and validation results against requirements and trustworthiness criteria |
| Deployment | A recorded release approval naming the accountable person |
| Operation | Monitoring records, incident log, drift reviews, rollback path |
| Retirement | Decommissioning record, data handling and retention decisions |
The composition of this layer is changing. Autonomous agents increasingly carry out work that people used to do, as first-line participants — and that changes what the first line has to design, without changing who is accountable.
Three obligations follow. Design has to set the autonomy level and the oversight points. Verification has to test behaviour under conditions the agent will actually meet, including adversarial ones, not just accuracy on a benchmark. Operation has to include a stop control: a person who can halt the agent, who knows they hold that authority, and whose ability to do so has been tested.
When most operational work runs on agents and automated workflows, the first line’s core job becomes designing the human-on-the-loop oversight, capability boundaries and stop controls that keep autonomous systems safe. The work shifts from performing tasks to specifying the envelope inside which tasks are performed.
| Evidence | Produced at |
|---|---|
| Statement of intended purpose, limits and risk tier | Inception |
| Design records showing controls and human-oversight points | Design |
| Data provenance, preparation and quality records | Design / Development |
| Completed impact assessment for higher-risk and autonomous systems | Development |
| Test and validation results | Verification |
| Recorded release approval naming the accountable person | Deployment |
| Monitoring records, incident log and drift reviews | Operation |
| Autonomy level, oversight points and stop-control test records | Design / Operation |
| Decommissioning record and retention decisions | Retirement |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXAI System Inventory registerDelivery keeps the register trueDownloadDOCXAI Impact Assessment templateDelivery runs it; assurance reviews itDownload| Role | Definition |
|---|---|
| Product & system owners | The people accountable for individual AI systems or products — owning their risks and operating their controls. |
| Engineers & data scientists | The people who build, train, evaluate and maintain the AI systems and the controls embedded in them. |
| AI agents | Autonomous software actors that carry out work as first-line participants — always under defined human accountability. An agent is not itself certified; the credential is held by the human who owns and supervises it. |
| Autonomous agents (supervised) | Agents that execute multi-step work with limited human intervention, within set boundaries and human oversight. Certification rests with the human supervising the agent, not the agent itself. |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceDelivering AI projects and programmesCertified AI Project ProfessionalRelated standards. ISO/IEC 5338 (AI system lifecycle processes) · ISO/IEC 42001 clause 8 and Annex A lifecycle controls · ISO/IEC 42005 (impact assessment) · NIST AI RMF — Measure and Manage.
Related articles. The AI system lifecycle · Control domains · The Governance Core · Risk, Assurance & Audit · Foundations
Risk, Assurance & Audit is the independent view. It assesses AI risk and impact, tests that controls actually work, and gives the board assurance that the programme runs as designed. It spans the second line — oversight and challenge — and the third line, independent internal audit, ending in external conformity assessment.
Everything the first line reports about itself is self-assessment. That is necessary, and it is not assurance, because the people who built a control are the least able to see what it fails to catch.
This layer exists to produce the finding the organisation would never have generated on its own. A well-run internal audit is the cheapest way an organisation ever discovers that a control everyone believed was operating has not produced evidence since March. The alternative is discovering it during an external assessment, or during an incident.
Its second function is quieter and equally important: it gives the board something it can rely on. A board that only hears from management about how well management is doing is governing on a single source. The audit committee route exists so that the board’s picture does not depend on the goodwill of the people being assessed.
Risk, compliance, internal audit and the audit committee.
Independence is a reporting line, not a professional attitude. The person testing must not report to the person whose controls are being tested, and must have a route to the board or audit committee that the audited function cannot intercept.
Smaller organisations without a standing internal audit function have two workable options: commission an independent third party, or use a function genuinely uninvolved in AI governance delivery and give it a direct reporting line. What does not work is asking the second line to audit itself.
The distinction that gives this layer its value is between a control that exists — documented, assigned, present in the framework — and one that is effective, meaning it is actually preventing or detecting what it was designed for. Testing only for existence produces a clean report and no assurance.
This layer is where the trustworthiness characteristics stop being adjectives and become measurements. Valid and reliable, safe, secure and resilient, fair, explainable, privacy-enhanced — each needs a threshold, an owner and a test, or it cannot be assured.
Two disciplines matter most in practice. First, results must be disaggregated: a system reported at high overall accuracy can perform far worse for a group that is a small share of the evaluation set, and aggregate metrics conceal exactly the failures assurance exists to catch. Second, the choice of fairness definition is a governance decision that should be recorded with its reasoning, because the competing definitions are largely mathematically incompatible and you cannot satisfy all of them.
The health of this layer is measurable in a way the others are not. Count the findings from the last cycle; count how many are closed with a named owner, a date, and evidence that the fix works. An open finding older than one full cycle is the clearest single indicator that assurance is convening rather than functioning.
Sampling a handful of systems cannot keep pace with thousands of models and agents. Assurance becomes continuous and largely automated — monitoring agent behaviour and control conformance in real time and flagging drift, rather than reconstructing a quarter after the fact. The independence requirement does not relax as this happens; it applies to whoever owns the monitoring.
| Evidence | What it demonstrates |
|---|---|
| Internal audit programme and completed reports | That independent testing happens on a cadence |
| Findings register with owners, dates and closure evidence | That findings drive change |
| Control effectiveness test results | That controls were tested for working, not existing |
| Risk register with treatments and named acceptances | That risk is managed rather than catalogued |
| Impact assessments across the lifecycle | That effects on people are assessed iteratively |
| Disaggregated performance results | That group-level failure is not concealed |
| Management review minutes with traceable decisions | That the board's picture is independent |
| Conformity assessment reports | That external assurance was obtained |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXEvidence RegisterWhat assurance samples fromDownloadXLSXStatement of ApplicabilityWhat assurance tests againstDownload| Role | Definition |
|---|---|
| Risk & assurance lead | Owns the risk and assurance view — assessing AI risk, monitoring controls and providing independent challenge. |
| Data & security lead | Accountable for the data-governance and information-security foundations that trustworthy AI depends on. |
| Board & governing body | Receives third-line findings directly and satisfies itself that they close. |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Providing second-line assurance and running internal auditsISO/IEC 42001 Internal AuditorAuditing an AI management system independentlyISO/IEC 42001 Lead AuditorLeading audits that reach the annexes, maturity and cross-border scopeISO/IEC 42001 Senior Lead AuditorRelated standards. ISO/IEC 42001 clause 9 (performance evaluation, internal audit, management review) and clause 10 · ISO 19011 · ISO/IEC 17021 · ISO/IEC 42006 · ISO/IEC 23894 (risk management) · ISO/IEC TR 24027 (bias).
Related articles. The assurance rhythm · Risk, impact & trustworthiness · Board & Executive · Foundations · Phase 6 · Assure & certify
People, Functions & Capability is how governance lands in real teams. It covers the roles people play, the credentials that build the skill, and the function-level playbooks — legal, HR, finance, procurement and more — that turn policy into daily practice. These functions are the federated spokes: embedded AI champions who connect each area back to the hub.
A management system operated entirely by a central team has a single point of failure, scales linearly with headcount, and is experienced everywhere else as a tax on delivery. It works, and it does not last.
This layer moves application into the functions. Procurement asks the AI questions because they are in the procurement checklist. HR knows what an impact assessment on a hiring tool must cover. Legal knows which contract clauses commit the organisation to controls it then has to deliver. None of this happens because the hub reminded them.
It is also the layer that decides whether the framework’s roles are real. A role that appears in a RACI map and nowhere in anyone’s objectives, time allocation or competence framework is a name in a box.
HR and L&D, function leads, and embedded AI champions across the business.
The framework names eleven roles across three groups. They answer the question most visitors arrive with: where do I fit?
| Role | Definition |
|---|---|
| Board & governing body Set direction | The body with ultimate oversight of AI — setting risk appetite, approving policy and holding management to account. |
| Accountable executive Set direction | The single named senior leader answerable for the AI-governance programme, with the authority and budget to run it. |
| AI governance lead Run governance | Runs the day-to-day governance function — the central hub that owns policy, standards and the AI inventory. |
| Risk & assurance lead Run governance | Owns the risk and assurance view — assessing AI risk, monitoring controls and providing independent challenge. |
| Data & security lead Run governance | Accountable for the data-governance and information-security foundations that trustworthy AI depends on. |
| Governance analysts & coordinators Run governance | The analysts and coordinators who do the day-to-day governance work — maintaining the AI inventory, running assessments, tracking actions and supporting the leads. This is the field’s main entry point: policy, risk and oversight skills, no ML engineering required. |
| Product & system owners Build & operate | The people accountable for individual AI systems or products — owning their risks and operating their controls. |
| Domain experts Build & operate | Function specialists — legal and privacy, ethics, HR, finance and risk, procurement, clinical and others — who judge AI in the context of their discipline. The GAICC speciality credentials live here. |
| Engineers & data scientists Build & operate | The people who build, train, evaluate and maintain the AI systems and the controls embedded in them. |
| AI agents Build & operate | Autonomous software actors that carry out work as first-line participants — always under defined human accountability. An agent is not itself certified; the credential is held by the human who owns and supervises it. |
| Autonomous agents (supervised) Build & operate | Agents that execute multi-step work with limited human intervention, within set boundaries and human oversight. Certification rests with the human supervising the agent, not the agent itself. |
A playbook translates the control framework into one discipline’s own workflow and vocabulary. It is not a summary of the policy; it answers “what do I do differently on Tuesday?”
| Function | What its playbook has to answer |
|---|---|
| Procurement | Which AI questions go into vendor assessment, which clauses are mandatory, what evidence to retain |
| Legal | Which commitments the organisation can deliver, how provider/deployer role is determined, what disclosure is required |
| HR | What governance applies to AI used on people, what oversight a hiring tool needs, how to handle a challenge |
| Product & engineering | What the design gate asks, what evidence the build must emit, what testing precedes release |
| Data & security | Provenance and permitted-use checks, robustness testing, monitoring and incident routes |
| Finance | How AI spend surfaces shadow systems, what cost and control questions belong in approval |
| Customer-facing teams | What to disclose, how to handle a question about an AI decision, when to escalate |
As agents do more of the doing, the scarce human skill becomes supervising, directing and auditing AI. Capability programmes and credentials shift toward oversight of agents and automated workflows — specifying autonomy limits, designing human-on-the-loop points, and testing stop controls, rather than performing the task the agent now performs.
| Evidence | What it demonstrates |
|---|---|
| Roles map with names, matched to the RACI map | That the framework's roles are real |
| Function playbooks, one per in-scope discipline | That the framework was translated, not distributed |
| Named champions with recorded time allocation | That the spokes are resourced |
| Competence framework by role, at defined depths | That capability is specified rather than assumed |
| Training and credential records | That capability was built where it is applied |
| Spoke-to-hub forum minutes with resulting control changes | That the feedback route is live |
| Evidence of function-owned control operation | That handover reached level three |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXRACI / accountability matrixFederated accountability, one sheet per functionDownloadXLSXAI Governance Maturity ScorecardCapability & culture is a scored dimensionDownload| Role | Responsibility for this layer |
|---|---|
| People & capability / HR | Resources and evidences the training that builds competence |
| AI governance lead | Owns the competence framework and the transfer to the spokes |
| Domain experts | Write and own their function’s playbook |
| Accountable executive | Holds line managers to the champion time allocations |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerHR, people and workforce functionsCertified AI HR ProfessionalGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clause 7 (support, competence, awareness) and Annex A resources controls · ISO/IEC 17024 for personnel certification · NIST AI RMF — the Govern function’s culture and workforce elements.
Related articles. Govern, accountability & roles · Foundations · The Governance Core · Delivery & Operations · Phase 5 · Embed across disciplines
Govern, accountability & roles is the accountability layer and the people in it: how the board and executive set direction for AI, own the risk, and make someone answerable. It also names the roles that run governance day to day, increasingly a mix of people and AI agents.
After any AI failure, regulators and courts ask the same two questions: who was accountable, and what did they decide? Without a named owner, a board mandate and defined roles, governance is good intentions no one is responsible for.
As AI agents take on real work, the question extends to who is accountable for what an autonomous system does — and that answer has to be decided in advance. An agent takes an action nobody individually approved; if accountability was not assigned beforehand, it gets assigned afterwards, by somebody else, under considerably worse conditions.
This layer is also the one whose absence disables every other part of the framework. Lifecycle controls need somebody with the authority to enforce a gate. Assurance needs a route to a body that can act on findings. An organisation can do excellent work on any other layer and deliver nothing, if there is no one who can require it.
| Rail item | What it is | How to tell it is real |
|---|---|---|
| Board oversight | The board’s active supervision of AI — a standing agenda item, regular reporting and clear escalation paths. | The board has declined or deferred something, and the minute records it. |
| AI policy | The approved statements of intent and rules that govern how AI is developed and used across the organisation. | A delivery team can resolve a routine proposal against it without escalating. |
| Roles & accountability | Who does what across the governance model, with exactly one accountable party per activity. | Every row of the RACI map has one A, and each A has authority to act. |
| Risk appetite | How much risk the organisation is willing to carry, including how much autonomy an agent may hold. | Somebody at a decision gate can apply it without a meeting. |
| Vision & roadmap | Where AI governance is going and the sequence that gets it there. | The next phase is named, owned and resourced, not aspirational. |
Responsibility distributes widely; accountability does not distribute at all. Many people are responsible for AI governance working. Exactly one person is accountable for whether it does.
The framework names eleven roles across three groups — set direction, run governance, build and operate. Each is defined in the canonical glossary and covered in depth in People, Functions & Capability.
Risk appetite set here is only worth what a delivery team can do with it. “We take a prudent approach to AI” decides nothing and generates escalation. Usable appetite states which classes of use are acceptable, which require additional assurance, and which are refused outright — and it states autonomy limits per class of system, because that is the fastest-moving variable in the estate.
Red lines are the most efficient sentence in the policy: they resolve an entire class of proposals without analysis. Boards are often reluctant to write them because they sound negative. They are the most useful thing this layer produces.
| Evidence | What it demonstrates |
|---|---|
| A signed AI policy with a review date | That direction exists, binds and is maintained |
| Terms of reference and minutes recording AI decisions and risk acceptances | That the governing body decides rather than receives |
| An accountability or RACI map for AI roles, including agent owners | That accountability is assigned to people |
| Evidence the board has reviewed the AI risk profile | That oversight is active |
| Recorded risk appetite and autonomy limits | That the envelope is set |
| Written appointment of the accountable executive | That one person answers |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXRACI / accountability mapThe accountability map is the artefact this layer producesDownloadXLSXRACI / accountability matrixSame map as a working matrix — one sheet per business unitDownload| Role | Definition |
|---|---|
| Board & governing body | The body with ultimate oversight of AI — setting risk appetite, approving policy and holding management to account. |
| Accountable executive | The single named senior leader answerable for the AI-governance programme, with the authority and budget to run it. |
| AI governance lead | Runs the day-to-day governance function — the central hub that owns policy, standards and the AI inventory. |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceStanding up and running the AI management systemISO/IEC 42001 Lead ImplementerHR, people and workforce functionsCertified AI HR ProfessionalRelated standards. ISO/IEC 38507 (governance implications of AI for the governing body) · ISO/IEC 42001 clause 5 (leadership) and 5.3 (roles, responsibilities and authorities) · ISO/IEC 42001 Annex A internal organization controls · NIST AI RMF — the Govern function.
Related articles. Board & Executive · The Governance Core · People, Functions & Capability · The AI management system · Phase 2 · Operating model & CoE
The AI management system is the operational core, certifiable to a published standard. Like an information security management system, it gives you a repeatable cycle — plan, do, check, act — for objectives, risk, controls and improvement. It is the engine every other layer plugs into.
A management system turns one-off good practice into something durable and provable. It is what a certification body audits, the structure regulators recognise, and the reason your governance survives staff turnover, the next model release, and the shift toward agent-driven work.
The distinction worth being precise about is between doing good things and having a system. An organisation can run excellent impact assessments, maintain a real inventory and operate sensible controls, and still have nothing a third party can assess — because none of it is scoped, none of it is tied to stated objectives, and nothing forces it to happen again next quarter.
The management system is what makes governance repeatable by structure rather than by effort. That matters most at the moment the people who built it move on, which is the point at which effort-based governance quietly stops.
Scope determines what the system covers: which parts of the organisation, which AI systems, which markets. It is decided before the estate is discovered, not after, because scope determines what you are obliged to find. Exclusions are legitimate and must be justified in writing at the moment they are decided — an unjustified exclusion is the thing an assessor finds first.
Objectives state what the system is for in terms the organisation can measure. The risk-and-opportunity plan ties treatment to the risk appetite set in the accountability layer. Together they are what stops a control set from being an arbitrary collection of good ideas: every control should trace to an objective or a treated risk.
The Statement of Applicability records which controls apply, at what depth, and why anything does not. It is the most externally-visible artefact the management system produces, and it is usually the first document an assessor asks for.
The support and operation clauses are where the system becomes a habit rather than a document: competence, awareness, documented information, operational control, monitoring and measurement, internal audit, management review, and corrective action.
Certification demonstrates that a management system meets a published standard, assessed by an accredited third party. Its value is that it is not self-reported: somebody with no stake in the outcome sampled real evidence from real systems.
The reason this layer is described as an engine rather than a document set is that it is the part designed to keep running when conditions change. New regulation enters through the context clause and lands in objectives and controls. A new class of system enters through scope and risk assessment. Staff turnover is absorbed by competence requirements attached to roles rather than to individuals. None of that happens automatically, but the structure is what makes it possible at all.
| Evidence | What it demonstrates |
|---|---|
| Scope statement and AI objectives | That the system has boundaries and a purpose |
| Risk assessment, treatment plan and Statement of Applicability | That controls were chosen deliberately |
| Internal audit reports and management review minutes | That the check movement runs |
| Records of nonconformities and corrective actions | That the act movement runs |
| Competence records matched to roles | That capability is resourced, not assumed |
| Operational control records across the lifecycle | That the system governs real work |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXStatement of ApplicabilityThe Statement of Applicability is the management system's spineDownloadXLSXStatement of ApplicabilityWorking version with all ten control areas and evidence columnsDownload| Role | Responsibility for the management system |
|---|---|
| Accountable executive | Answerable for the system existing and working |
| AI governance lead | Owns scope, objectives, the control framework and the Statement of Applicability |
| Risk & assurance lead | Owns internal audit and independent challenge |
| Governance analysts & coordinators | Maintain documented information and track corrective actions |
| Product & system owners | Operate controls and produce the evidence the system depends on |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerWorking anywhere inside the management system and needing the shared vocabularyISO/IEC 42001 FoundationExtending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerRelated standards. ISO/IEC 42001 clauses 4 to 10 and Annex A · ISO/IEC 42001 Annex B and C for implementation guidance · ISO/IEC 27001 as the structural precedent · ISO/IEC 42006 for the requirements on bodies auditing AI management systems · ISO/IEC 17021.
Related articles. Control domains · The governance loop · The assurance rhythm · The Governance Core · Phase 6 · Assure & certify
Risk, impact & trustworthiness is where the framework gets specific about AI risk: risk managed across the lifecycle, impact assessed on people and society, and the trustworthiness characteristics expressed as measurable properties with thresholds, tests and owners. For agents, it adds autonomy levels and human oversight.
AI risk is not ordinary IT risk: a model can be accurate and still unfair, compliant on paper and harmful in use. Autonomous agents raise the stakes — acting without a human in each loop — so risk, impact and oversight must be explicit and continuous.
This is also the layer that external parties probe first. A regulator asks what you assessed and when. A customer asks how you know the system is fair. An incident review asks whether the harm that occurred was one you had considered. All three are answerable only if assessment happened before reliance, was recorded, and produced something measurable.
The failure mode is specific and common: assessment performed after launch. An impact assessment completed once a system is live is a description rather than a control — nothing it finds can realistically change the design, so its findings get accepted instead of acted on. Organisations end up with a full folder of assessments and no case where one changed an outcome.
| Discipline | What it asks | When it runs |
|---|---|---|
| Risk management | What could go wrong for the organisation, and what are we doing about it? | Iteratively across the lifecycle, prioritised by risk tier |
| Impact assessment | What could this do to people and groups, including those who never interact with it? | Before build completes, for higher-risk and autonomous systems |
| Trustworthiness | Does the system actually hold the properties we claim for it? | Verification, then continuously in operation |
They are separate because they fail separately. A thorough risk register says nothing about whether a particular group is being disadvantaged. A completed impact assessment says nothing about whether the system is robust under adversarial conditions. Running one and reporting it as though it covered the others is the most common way a governance programme overstates its own coverage.
These are the properties that make an AI system trustworthy. They are shared across the major standards and frameworks, and the GAICC framework adds the tenth explicitly because autonomy changes what oversight has to mean.
| Characteristic | Definition |
|---|---|
| Valid & reliable | The system performs as intended — accurately and consistently — across the conditions it will actually face, and keeps doing so over time. |
| Safe | Under defined conditions, the system does not lead to states that endanger human life, health, property or the environment. |
| Secure & resilient | The system withstands adversarial attack and unexpected conditions, and can recover or fail gracefully rather than catastrophically. |
| Accountable | Responsibility for the system’s behaviour is clearly assigned to identifiable people, with records to trace decisions back. |
| Transparent | Meaningful information — that it is AI, how it is used, its capabilities and limits — is available to the people it affects. |
| Explainable | The reasons behind the system’s outputs can be described in terms appropriate to the audience and the stakes of the decision. |
| Privacy-enhanced | The system safeguards personal data and individual autonomy through choices in its design, data handling and deployment. |
| Fair | Outcomes are checked and managed for harmful bias and unjustified disparities across the groups the system affects. |
| Resilient to misuse | The system is designed and governed to limit foreseeable abuse, misuse or harmful repurposing beyond its intended use. |
| Autonomy & human oversight | How much an AI agent may decide on its own, and where a human must stay in or on the loop — calibrated to the stakes. |
The characteristics are not independent, and treating them as a checklist obscures the real work. Explainability often costs accuracy. Privacy-enhancing techniques can reduce the data available to detect unfairness. Security hardening can reduce transparency. Resilience to misuse can constrain legitimate use.
Because of that, the useful artefact is not a score against all ten but a recorded set of trade-off decisions: which property was prioritised, at whose expense, and why. That is a governance decision, and it should be made by someone with the standing to defend it rather than settled implicitly by an engineering default.
Fairness is the characteristic most often reduced to a single test, and it is the one where that reduction does most damage. Bias enters at several distinct points, and the mitigation differs at each: in the world the data records, in how the data was collected, in the choice of what to predict, in optimisation for aggregate performance, and in how the system is deployed and overridden.
Two consequences follow. A fairness metric measured once at development says nothing about the last two sources. And the competing definitions of fairness are largely mathematically incompatible — you cannot satisfy all of them at once, which makes the choice of definition a governance decision that should be recorded with its reasoning.
For agentic systems the tenth characteristic does most of the work. Autonomy is a level chosen per system and recorded, not a property discovered after deployment — and it drifts upward unless it is governed downward, because scope expands one reasonable increment at a time with no single change large enough to trigger review.
Meaningful oversight requires three things that are easy to claim and harder to evidence: a person who can intervene, who knows they hold that authority, and whose ability to do so has actually been exercised. A reviewer approving two hundred outputs an hour is not meaningfully in the loop, and a stop control nobody has tested is a hypothesis.
| Evidence | What it demonstrates |
|---|---|
| An AI risk register with analysis and treatment | That risk is managed rather than catalogued |
| Completed impact assessments | That effects on people were analysed before reliance |
| Trustworthiness test results and acceptance criteria | That characteristics are measured, not asserted |
| Bias and robustness records | That the hard properties were examined |
| Disaggregated performance results on the deployment population | That group-level failure is not concealed |
| Recorded fairness definition with reasoning | That the position is defensible |
| Residual-risk sign-off with a named acceptor and date | That acceptance sits with a person |
| Autonomy levels, oversight points and stop-control test records | That oversight is real for agentic systems |
| Links from each risk to live monitoring | That treatment continues after sign-off |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXAI Impact Assessment templateImpact assessment is where trustworthiness stops being a wordDownloadXLSXAI Risk RegisterAI risk register with inherent, control and residual scoringDownload| Role | Responsibility |
|---|---|
| Risk & assurance lead | Owns the risk and impact method and challenges residual acceptances |
| Product & system owners | Carry accepted risk for their systems and operate the mitigations |
| Engineers & data scientists | Own trustworthiness measurement, bias testing and robustness testing |
| Domain experts | Judge what the data represents and where it misleads in their domain |
| Accountable executive | Answerable for the residual risk the organisation carries |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceStanding up and running the AI management systemISO/IEC 42001 Lead ImplementerRelated standards. ISO/IEC 23894 (risk management) · ISO/IEC 42005 (AI system impact assessment) · ISO/IEC TR 24027 (bias in AI systems and AI-aided decision making) · ISO/IEC 24029 (robustness of neural networks) · ISO/IEC 42001 Annex A impact assessment controls · NIST AI RMF — the Map and Measure functions and its trustworthiness characteristics.
Related articles. Risk, Assurance & Audit · Foundations · The AI system lifecycle · Control domains · Using the AI Impact Assessment template
The operating context is the set of external demands your AI has to satisfy — regulations, obligations, sector rules and public trust — and the discipline of translating all four into a single set of internal requirements rather than four competing compliance projects.
Organisations rarely fail at AI governance because they misread a single law. They fail because they treat each source of demand as a separate project.
The pattern is familiar. Legal reads the regulation and starts a compliance workstream. Procurement answers a customer’s AI questionnaire and commits the company to controls nobody in engineering has heard of. A sector regulator issues guidance and the risk function opens a third track. Communications handles the reputational side. Four teams, four spreadsheets, four sets of evidence, and no single answer to the question an auditor actually asks: what is your control, who owns it, and can you show it working?
The cost is not just duplication. It is contradiction. The commitment made in a customer contract turns out to be stricter than the regulation, but nobody notices until an incident. The sector guidance assumes a documentation format the internal process does not produce. Effort goes up, assurance goes down, and the organisation ends up expensive and exposed.
Reading the operating context properly is what prevents this. It is a deliberate act: identify every external demand that applies to you, express each one as an internal requirement, and route all of them into one management system. Do this once, well, and every subsequent obligation becomes an increment rather than a new programme.
The framework separates external demand into four bands because each behaves differently — different sources, different enforcement, different speed of change, and different consequences for getting it wrong.
| Band | What it is | How it reaches you | What failure costs |
|---|---|---|---|
| Regulations | Binding laws and rules that set hard requirements for AI in the markets you operate in. | Legislation and regulator guidance; phased commencement dates | Penalties, enforcement action, market withdrawal |
| Obligations | Contractual, sector and stakeholder commitments your AI must meet beyond what the law strictly requires. | Customer contracts, procurement questionnaires, supplier terms, funder conditions | Lost deals, breach of contract, remediation at your cost |
| Sector rules | Domain-specific requirements — in finance, health, the public sector and others — that shape how AI may be used. | Sector regulators, professional bodies, accreditation schemes | Licence conditions, supervisory intervention, loss of accreditation |
| Public trust | The expectations of customers, employees and society that AI be used responsibly — effectively a licence to operate. | Media, employees, customers, civil society, your own workforce | Adoption collapse, talent loss, political attention, reputational damage |
The fourth band is the one organisations most often leave out of the analysis, on the grounds that it is not written down. That is precisely why it belongs. Public trust is the only band with no compliance deadline and no appeal process, and it is the band that determines whether the AI you are permitted to build is AI anyone will actually use.
Most regulatory regimes distinguish between the organisation that builds an AI system and the organisation that uses one built by somebody else. The obligations differ substantially, and a great deal of confusion comes from organisations assuming they hold only one role.
This is the step that does the real work. An external demand is written in someone else’s language, for someone else’s purposes. It is not directly actionable. Translating it means answering four questions and recording the answers.
The output of this process is not a compliance report. It is a set of entries in the same management system that governs everything else — the same risk register, the same control set, the same evidence trail. That is what makes the next obligation cheap.
The reason a single management system works is that the four bands overlap far more than they differ. Strip away the vocabulary and most of them ask for the same small number of things: know where your AI is, assess what it could do to people, keep a human meaningfully in charge, test it before you rely on it, tell people it is being used, and be able to show all of the above.
Read that grid as a build order. The rows shaded most heavily across the most bands are the controls that pay for themselves several times over — an inventory satisfies all four bands at once. The rows that light up in only one band are where genuinely specific work is needed.
Mature organisations do one more thing: they treat the operating context as a monitored input rather than an inbox. Somebody is named as responsible for watching each band. Changes are assessed for impact on the existing control set. The result goes to the same governance forum that sees everything else, on the same cadence.
This is the difference between an organisation that discovers a new obligation when a customer asks about it, and one that had already mapped it, decided it was covered by an existing control, and recorded that decision six months earlier.
An auditor, assurance function or regulator will typically ask to see:
| Evidence | What it demonstrates |
|---|---|
| Applicability register listing every external demand and the systems it touches | That the analysis was performed deliberately and is complete |
| Role determination per system, with the reasoning recorded | That obligations were scoped correctly rather than assumed |
| Requirement-to-control mapping | That each demand has an owner and a mechanism, not just an acknowledgement |
| Statement of Applicability | That control decisions, including exclusions, were made and justified |
| Contract and procurement review records for AI commitments | That obligations are assessed before they are accepted |
| Horizon-scanning log with dated entries and impact assessments | That the context is monitored rather than assumed static |
| Governance forum minutes recording context changes and decisions taken | That the context reaches the people accountable for responding |
| Stakeholder and incident communication records | That the trust band is managed, not merely hoped for |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXObligation Crosswalk TrackerTrack every obligation you are subject to, in one registerDownload| Role | Responsibility for the operating context |
|---|---|
| Board & governing body | Satisfies itself that the organisation knows which demands apply and is meeting them |
| Accountable executive | Answerable for the completeness of the analysis and the adequacy of the response |
| AI governance lead | Owns the applicability register and the translation into internal requirements |
| Risk & assurance lead | Independently tests that mapped controls exist and are working |
| Domain experts | Interpret sector rules and professional obligations for their own domain |
| Product & system owners | Determine and record the role held for each system they own |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceLegal, compliance and regulatory affairsCertified AI Law & Compliance ProfessionalRelated standards. ISO/IEC 42001 clause 4 (context of the organisation) and clause 4.2 (needs and expectations of interested parties) · ISO/IEC 23894 (risk management) · ISO 31000 (risk management principles) · the EU AI Act provider and deployer duties · NIST AI RMF — the Govern and Map functions.
Related articles. Govern, accountability & roles · The AI management system · Risk, impact & trustworthiness · The governance loop · The assurance rhythm
The AI system lifecycle is the path every AI system travels — from inception through design, development, verification, deployment and operation to retirement — and the point at which governance stops being a policy and becomes a set of decisions, controls and evidence applied at the moment they matter.
Most AI governance failures are not failures of intent. They are failures of timing.
An organisation writes a sound policy, then discovers that the model was trained on data nobody assessed, released without a documented approval, and left running for eighteen months after the business need changed. Every individual step looked reasonable. The problem was that governance arrived after the decisions had already been made.
Governance applied at the end is expensive and weak: expensive because rework at deployment costs far more than a design constraint, and weak because the evidence a regulator or auditor wants — what you decided, when, on what basis, and who approved it — cannot be reconstructed afterwards. It has to be captured as the work happens.
The lifecycle view fixes the timing problem. It says: for each stage, here are the decisions that belong here, the controls that apply here, and the evidence produced here. Nothing is bolted on at the end, because nothing needs to be.
The lifecycle is deliberately generic. It describes any AI system — a purchased tool, a fine-tuned model, a retrieval pipeline or an autonomous agent — because governance obligations do not change with implementation style.
| Stage | The governance question it answers |
|---|---|
| 1 · Inception | Should we build or buy this at all, for what purpose, and within what limits? |
| 2 · Design | What data, what approach, what controls, and where does a human stay in the loop? |
| 3 · Development | Is it being built as designed, and is the evidence being captured as we go? |
| 4 · Verification | Does it meet its requirements and its trustworthiness expectations before anyone relies on it? |
| 5 · Deployment | Who approved release, what is being monitored, and how do we roll it back? |
| 6 · Operation | Is it still performing as intended, and who acts when it is not? |
| 7 · Retirement | How do we shut it down responsibly, and what records must survive it? |
Stages overlap and iterate in practice. The sequence is a governance ordering, not a waterfall — an organisation running continuous delivery still passes through every one of these questions, just faster and more often.
Four points in the lifecycle carry decisions that should not be implicit (Figure 1):
The same lifecycle applies to every system, but the weight of each stage scales with risk. Tier each system at inception and let the tier drive how much verification, documentation and oversight is required. Without tiering, organisations either over-govern trivial tools until the process is ignored, or under-govern consequential ones. Both outcomes end in the same place.
For agentic systems, three lifecycle stages carry additional weight:
The governance loop — Direct, Assess, Operate, Improve — is not a stage in the lifecycle. It runs across all of them. Direction set at the top (policy, risk appetite, autonomy limits) constrains what happens at every stage; what is learned in operation feeds back into the direction for the next system. A lifecycle without the loop produces well-governed individual systems and an organisation that never gets better at it.
An auditor, assurance function or regulator will typically ask to see:
| Evidence | Produced at |
|---|---|
| Statement of intended purpose, limits and risk tier | Inception |
| Design records showing controls and human-oversight points | Design |
| Data provenance, preparation and quality records | Design / Development |
| Completed impact assessment for higher-risk and autonomous systems | Development |
| Test and validation results against requirements and trustworthiness criteria | Verification |
| Recorded release approval naming the accountable person | Deployment |
| Monitoring records, incident log and drift reviews | Operation |
| Decommissioning record, data handling and retention decisions | Retirement |
| Audit log traceable from an output back to the decision behind it | All stages |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXAI System Inventory registerEvery system on the register, with its lifecycle stageDownloadDOCXAI Impact Assessment templateRun before deployment; re-run on material changeDownloadThe lifecycle is not a standalone idea — it connects to every other part of the framework:
| Role | Responsibility across the lifecycle |
|---|---|
| Product & system owners | Own the system end to end; accountable at each gate |
| Engineers & data scientists | Build to the design, embed controls, capture evidence |
| Governance analysts & coordinators | Maintain the inventory, track stage and gate status, run assessments |
| Risk & assurance lead | Independently tests that lifecycle controls are present and working |
| Accountable executive | Answerable for the portfolio of systems and the risk they carry |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceStanding up and running the AI management systemISO/IEC 42001 Lead ImplementerWorking anywhere inside the management system and needing the shared vocabularyISO/IEC 42001 FoundationRelated standards. ISO/IEC 5338 (AI system lifecycle processes) · ISO/IEC 42001 clauses 6 and 8, and Annex A lifecycle controls · ISO/IEC 23894 (risk management) · ISO/IEC 42005 (impact assessment) · NIST AI RMF — Map, Measure and Manage functions.
Related articles. The AI management system · Risk, impact & trustworthiness · Control domains · Delivery & Operations · The governance loop
Control domains are the ten objective areas into which every AI control falls — policies, organisation, resources, impact assessment, lifecycle, data, stakeholder information, responsible use, third parties, and agentic AI. They are the organising structure that turns a long list of controls into something an organisation can scope, assign, test and prove.
Ask most organisations what AI controls they have and you get a list. The list is usually long, usually genuine, and almost always impossible to reason about.
A list cannot answer the three questions that matter. Is anything missing? You cannot tell, because a list has no shape — there is nothing to be absent from. Who owns this? Unclear, because controls that belong together organisationally are scattered across the list by whatever order they were written in. Have we done enough? Unanswerable, because “enough” requires a denominator.
Domains supply the denominator. Ten objective areas is a small enough number to hold in your head and complete enough that a gap becomes visible as a gap. The moment you organise controls by domain, three things happen at once: the empty domain becomes obvious, the owner becomes obvious, and the scoping conversation becomes possible.
There is a second reason, less discussed and more practical. Domains are the currency of external assurance. An auditor works through objective areas, not through your list. A customer questionnaire is structured by them. A Statement of Applicability is written against them. An organisation whose internal structure matches the structure it will be assessed against does the assessment once. An organisation whose structure does not match does a translation exercise every single time.
Nine of the ten mirror the established control structure for AI management systems, which is what makes GAICC’s domains directly usable in an audit or certification conversation. The tenth is a GAICC extension, added because agentic systems break assumptions the original nine were built on.
| # | Domain | The objective it names |
|---|---|---|
| 1 | AI policies | Top-level policies that set the organisation’s direction and rules for developing and using AI responsibly. |
| 2 | Internal organization | Defined roles, responsibilities and reporting lines so accountability for AI is clear and decisions have owners. |
| 3 | Resources | The people, skills, data, tooling and compute the organisation documents and provides to run AI responsibly. |
| 4 | Impact assessment | A structured process to assess an AI system’s potential consequences for individuals, groups and society. |
| 5 | Lifecycle | Controls applied across the AI system’s life — from objectives and design through development, deployment, operation and retirement. |
| 6 | Data | Management of the data used to build and run AI: its provenance, quality, preparation and appropriate use. |
| 7 | Stakeholder information | What the organisation tells affected stakeholders about its AI, and how it handles their reports and concerns. |
| 8 | Responsible use | Defining and enforcing the intended use of each AI system, and guarding against use outside those bounds. |
| 9 | Third parties | Governing AI capabilities, data and services obtained from suppliers and partners, and the risks they introduce. |
| 10 | Agentic & autonomous AI | Extending the control framework to autonomous agents and automated workflows that act with limited human intervention. |
The domains are not siblings. They stack, and knowing the stack tells you what to build first.
This ordering explains a common and expensive mistake. Organisations frequently begin with domain 4 or 5 — impact assessments and lifecycle gates — because those feel like “real” AI governance. The assessments get written. Then nobody has authority to reject a system on the strength of one, because domain 2 was never done, and the assessments become documentation rather than control.
The nine established domains were designed for AI systems that produce outputs a human then acts on. An agentic system does not fit that assumption. It takes actions, chains them, calls tools, and may operate for extended periods without a person in the loop at all.
Three of the nine bend badly under that load. Responsible use assumes intended use is bounded by what a human chooses to do with an output — an agent chooses for itself, inside whatever limits you set. Lifecycle assumes a system whose behaviour is broadly fixed between releases — an agent’s effective behaviour changes with its tools and its context. Third parties assumes a supplier relationship you can inspect — an agent may invoke services at runtime that nobody assessed.
Every domain applies to every organisation using AI. What varies is depth, and the honest way to record that variation is a Statement of Applicability: for each domain, what you have implemented, to what depth, and where you have decided a control is not applicable together with why.
The justification is the part that carries the weight. “Not applicable” with a defensible reason is a governance decision. “Not applicable” with no reason is an omission that an assessor will find and a regulator will not accept.
A domain with two owners has none. The most reliable predictor of whether a domain is genuinely operating is whether one named person would answer for it in a review without first checking who else is involved.
Ownership does not mean doing the work. Data is owned by a data lead but implemented by engineering; third parties is owned by governance but implemented largely through procurement. What ownership means is that the objective has somebody who knows its state and is answerable for its gaps.
Domains are one of the framework’s two cross-cutting structures. The lifecycle answers when a control applies; the domains answer what kind of objective it serves. Every control has a position on both axes, and a control you cannot place on either is usually a task rather than a control.
An auditor, assurance function or regulator will typically ask to see:
| Evidence | Domain it evidences |
|---|---|
| Approved AI policy set, versioned and communicated | 1 · AI policies |
| Role definitions, RACI map and reporting lines | 2 · Internal organization |
| Competence records, training plan and resourcing decisions | 3 · Resources |
| Completed impact assessments with mitigations and sign-off | 4 · Impact assessment |
| Stage-gate approvals and lifecycle control records | 5 · Lifecycle |
| Data provenance, quality and permitted-use records | 6 · Data |
| Disclosure notices, complaint and concern handling records | 7 · Stakeholder information |
| Intended-use statements and out-of-scope-use monitoring | 8 · Responsible use |
| Supplier assessments, contract clauses and ongoing monitoring | 9 · Third parties |
| Autonomy levels, oversight points, stop controls and action logs | 10 · Agentic & autonomous AI |
| Statement of Applicability covering all ten domains | All domains |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXStatement of ApplicabilityOne row per control area, with justification and evidenceDownloadDOCXStatement of ApplicabilityThe narrative version for the certification fileDownload| Role | Responsibility for the domains |
|---|---|
| Accountable executive | Answerable for coverage across all ten domains and for the exclusions accepted |
| AI governance lead | Owns the domain structure, the Statement of Applicability and the coverage report |
| Data & security lead | Owns the data domain and contributes to third parties and agentic controls |
| Product & system owners | Own responsible use and lifecycle controls for their systems |
| Risk & assurance lead | Independently tests domain effectiveness rather than domain existence |
| Governance analysts & coordinators | Maintain the control-to-domain mapping and evidence trail |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerExtending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerWorking anywhere inside the management system and needing the shared vocabularyISO/IEC 42001 FoundationRelated standards. ISO/IEC 42001 Annex A control objectives A.2 to A.10, which correspond to domains 1 to 9 · ISO/IEC 42001 clause 6.1.3 and the Statement of Applicability · ISO/IEC 27001 Annex A for the information security controls the data and third-party domains build on · ISO/IEC 42005 (impact assessment) · NIST AI RMF — the Manage function. Domain 10 is a GAICC extension with no direct equivalent in the current published control sets.
Related articles. The AI management system · The AI system lifecycle · Risk, impact & trustworthiness · Govern, accountability & roles · Operating context
The foundations are the four shared competences every other layer of the framework depends on — a common terminology, data quality, bias and robustness, and machine learning fundamentals. They are not a beginner’s topic. They are the layer that determines whether the governance above them describes reality or merely describes itself.
Foundations are placed at the bottom of the canvas, and being at the bottom is routinely misread as being at the beginning — something covered in an induction deck and then left behind.
The opposite is true. These four are the competences that the layers above silently assume, and silent assumptions are the ones that fail without warning. A governance forum can run for two years with clear roles, a maintained inventory and a functioning assurance rhythm, and still be approving systems on the basis of tests that could not have detected the problem, because nobody in the room could tell the difference between a model that generalises and one that memorised its evaluation set.
The failure signature is consistent. The governance is not absent; it is nominal. Approvals are given, but the approver could not have withheld one on technical grounds. Impact assessments are completed, but the harms considered are the ones that were easy to imagine. Data controls exist, and describe storage rather than fitness. Everything is present and nothing is load-bearing.
Foundations are what make governance decisions real decisions. They are also the cheapest layer to strengthen, and the one that most reliably improves every layer above it at once.
Terminology is a shared, consistent vocabulary for AI so everyone in the programme means the same thing. It sounds like the least consequential of the four and is frequently the most.
AI terminology is unusually treacherous because the same word carries different meanings in law, in engineering, in procurement and in ordinary speech — and all four sit in the same meeting. “Model” means a trained artefact to a data scientist and an entire product to a customer. “Accuracy” is a specific metric to one person and a general reassurance to another. “Automated decision” has a precise regulatory meaning that is narrower than its everyday one. “Agent” currently means whatever the speaker last read.
Where this becomes a governance failure rather than a communication annoyance is at the boundaries. A control is written by one function and implemented by another that understood the term differently. An obligation is scoped using a legal definition and implemented against an engineering one, so the systems that actually attract the obligation are not the systems that got the control.
Data quality is the fitness of data for its purpose — accuracy, completeness, relevance and representativeness. The last word is the one that carries most of the AI-specific weight, and the one most often missing from data quality programmes inherited from the reporting world.
Traditional data quality asks whether a record is correct. AI data quality has to ask a harder question: whether the data represents the world the system will actually meet. A dataset can be complete, accurate, well-documented and entirely unsuitable, because it describes a population, a period or a set of conditions that no longer matches deployment. Nothing in a conventional quality check catches that.
| Dimension | The question it answers | What it looks like when it fails |
|---|---|---|
| Accuracy | Do the values correctly describe what they claim to describe? | The system learns a pattern in the errors rather than in the world |
| Completeness | Is what is missing known, bounded and accounted for? | Absence is treated as a value; gaps concentrate in particular groups |
| Relevance | Does this data bear on the decision the system is making? | Proxy variables carry the decision; correlation without applicability |
| Representativeness | Does it reflect the population and conditions at deployment? | Strong test performance, weak real-world performance, uneven by group |
| Provenance | Where did it come from, on what basis, and may we use it this way? | Permitted-use problems found after the system is in production |
| Timeliness | Does it still describe current conditions? | Silent degradation as the world moves and the data does not |
Provenance deserves particular attention because it is the dimension with a legal edge. Data that is accurate, complete and representative but obtained or repurposed without a basis for that use is a governance problem no amount of statistical quality resolves. Provenance is where the data foundation meets the third-party and responsible-use control domains.
Bias and robustness means identifying and managing harmful bias, and ensuring the system holds up under varied and adversarial conditions. They are paired for a reason: both are questions about behaviour outside the conditions the system was optimised for, and both are invisible to headline performance metrics.
On bias, the essential foundation is that it is not a single quantity and cannot be eliminated by a single test. Bias enters at several distinct points, and the mitigation differs at each.
Two consequences follow. First, a fairness metric measured once at development says nothing about the last two sources. Second, the competing definitions of fairness are, for the most part, mathematically incompatible — you cannot satisfy all of them at once, which makes the choice of definition a governance decision that should be recorded with its reasoning, not a technical default.
Robustness is the same concern in a different direction: does the system hold up when conditions are unusual, degraded or hostile? Strong average performance is compatible with catastrophic behaviour on inputs that are rare, out of distribution or deliberately adversarial. For systems that act rather than advise, that gap is the entire risk.
ML foundations are the core machine learning concepts that underpin how modern AI systems are built and behave. The governance-relevant subset is small, and it is the part that explains why AI systems fail differently from the software that preceded them.
| Concept | Why a governance decision depends on it |
|---|---|
| Learned from data, not specified | Behaviour is induced from examples, so it cannot be fully read off a specification or reviewed like code |
| Training, validation and test separation | If the evaluation data leaked into training, the reported performance is fiction — and this is common |
| Generalisation and overfitting | Strong performance on familiar data with weak performance on new data is the default failure, not an anomaly |
| Distribution shift and drift | Performance decays as the world moves away from the training conditions, silently and without an error |
| Probabilistic outputs and thresholds | Where the decision threshold sits is a value judgement about error trade-offs, not a technical setting |
| Error asymmetry | False positives and false negatives harm different people differently; one number cannot express both |
| Foundation models and adaptation | Fine-tuning, retrieval and prompting inherit properties from a base model you did not build and cannot fully inspect |
| Generative failure modes | Fluent, confident and wrong is a normal output state, not a malfunction to be patched |
| Tool use and action | When a model can call tools, an error stops being an incorrect answer and becomes an incorrect action |
| Explainability has limits | Post-hoc explanations approximate a model’s behaviour; they are not a faithful account of its reasoning |
Notice what this list is for. Each item exists because it changes a decision somebody in governance actually makes — whether a test result can be believed, whether a threshold is a technical or an ethical choice, whether an explanation offered to an affected person is truthful, whether monitoring needs to detect decay rather than outage.
The foundations are not four independent competences. Weakness in one reliably shows up as a symptom attributed to another, which is why they are governed together.
Foundations are a resourcing question as much as a training one, and the framework treats them that way: the resources control domain covers the people, skills, data and tooling the organisation documents and provides. Different roles need different depth, and the practical failure is assuming that having deep expertise somewhere in the organisation means it is available at the point of decision.
| Who | Depth needed |
|---|---|
| Board & governing body | Enough to ask why a reported metric should be believed, and to recognise a non-answer |
| Accountable executive | Enough to test whether an approval had a technical basis or only a documented one |
| AI governance lead | Working fluency across all four; able to challenge a technical claim and follow the answer |
| Governance analysts & coordinators | Terminology precision and data quality literacy, applied daily to the inventory and assessments |
| Domain experts | Deep knowledge of what the data represents in their domain and where it misleads |
| Engineers & data scientists | Full technical depth, plus the vocabulary to make it legible to the other five rows |
An auditor, assurance function or regulator will typically ask to see:
| Evidence | What it demonstrates |
|---|---|
| Canonical glossary, versioned, with a change log | That terminology is governed rather than emergent |
| Data quality assessment covering representativeness and fitness for purpose | That data is assessed against the deployment reality, not just internal consistency |
| Data provenance and permitted-use records | That the basis for using each dataset was established before use |
| Recorded fairness definition with the reasoning for choosing it | That the fairness position is a governance decision somebody can defend |
| Disaggregated performance results on the deployment population | That aggregate metrics are not concealing group-level failure |
| Robustness and adversarial test results | That behaviour outside normal conditions was examined before reliance |
| Evidence of train/test separation and leakage checks | That reported performance can be believed |
| Drift and decay monitoring records | That degradation is detected rather than discovered |
| Competence framework and training records by role | That foundation capability is resourced and present at the point of decision |
| Role | Responsibility for the foundations |
|---|---|
| Accountable executive | Answerable for foundation competence being present where decisions are made |
| AI governance lead | Owns the glossary and the competence framework; enforces terminology discipline |
| Data & security lead | Owns data quality, provenance and permitted-use controls |
| Engineers & data scientists | Own technical evaluation, bias measurement and robustness testing |
| Domain experts | Judge whether data represents their domain and where it misleads |
| People & capability | Resource and evidence the training that builds foundation competence |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceWorking anywhere inside the management system and needing the shared vocabularyISO/IEC 42001 FoundationRelated standards. ISO/IEC 22989 (AI concepts and terminology) · ISO/IEC 23053 (framework for AI systems using machine learning) · ISO/IEC 5259 (data quality for analytics and machine learning) · ISO/IEC TR 24027 (bias in AI systems and AI-aided decision making) · ISO/IEC 24029 (robustness of neural networks) · ISO/IEC 42001 Annex A controls for resources and data · NIST AI RMF — the Measure function and the trustworthiness characteristics.
Related articles. Risk, impact & trustworthiness · The AI system lifecycle · Control domains · People, Functions & Capability · The AI management system
Board oversight is the governing body’s active supervision of AI: a standing agenda item, reporting on a defined cadence, and escalation paths that do not depend on goodwill.
The test of board oversight is not whether AI appears on the agenda. It is whether anything has ever been declined, deferred or changed as a result — and whether the minute records it.
Boards govern risk, obligation and licence to operate, not technology. Reporting framed as technology gets received politely and acted on rarely. “Four systems now act without a human approving each decision; here is who can stop them and how we tested that” produces a question worth answering.
| Evidence | What it demonstrates |
|---|---|
| Board or committee minutes recording AI decisions | That the body decides rather than receives |
| Board reporting packs across consecutive cycles | That oversight is continuous |
| Evidence the board reviewed the AI risk profile | That supervision is substantive |
| Escalation route and cadence documented | That escalation does not depend on goodwill |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXBoard reporting pack outlineOversight leaves a paper trail or it did not happenDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 38507 · ISO/IEC 42001 clause 5 and 9.3.
Related articles. Board & Executive · Govern, accountability & roles · Using the Board reporting pack outline
The AI policy is the organisation’s approved direction on AI: principles, scope, risk appetite, roles, red lines, lifecycle and third-party requirements. Its test is whether it is decidable, not whether it is comprehensive.
A policy nobody can apply generates escalation, and escalation volume is what turns a governance hub into a queue. The two sections that carry most of the weight are risk appetite — expressed so somebody at a decision gate can apply it — and red lines, which resolve a whole class of proposals without analysis.
Test it before approval the way a delivery team will: take one clearly acceptable proposal, one clearly unacceptable, and one genuinely borderline. Give the draft to somebody who did not write it. If they resolve the first two unaided and know where to escalate the third, it works.
| Evidence | What it demonstrates |
|---|---|
| Signed AI policy with a review date | That direction exists and binds |
| Governing body approval minute | That it was approved, not circulated |
| Policy change log | That amendments are traceable |
| Evidence of communication beyond the governance team | That it reaches the people it governs |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXAI Policy templateThe template itselfDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Writing an AI policy that will actually be adoptedHow to Write an AI PolicyStanding up and running the AI management systemISO/IEC 42001 Lead ImplementerRelated standards. ISO/IEC 42001 clause 5.2 and Annex A policy controls.
Related articles. Govern, accountability & roles · Using the AI Policy template · Control domains
Roles & accountability defines who does what across the governance model. Its single hard rule is that every activity has exactly one accountable party, and that party has the authority to act.
Responsibility distributes widely; accountability does not distribute at all. Many people are responsible for AI governance working — exactly one is accountable for whether it does.
Two failures dominate. Accountability assigned to a committee, which cannot be held to account because in any dispute each member defers to the others. And an accountable party with no authority — a name in a box, unable to direct resources or stop work. Check every A against the mandate and the operating model.
| Evidence | What it demonstrates |
|---|---|
| Completed RACI / accountability map | That every activity has one owner |
| Role definitions consistent with the policy | That naming is canonical |
| Written appointment of the accountable executive | That accountability sits with a person |
| Agent ownership records in the inventory | That autonomy has a human owner |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXRACI / accountability matrixThe matrix that settles argumentsDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerHR, people and workforce functionsCertified AI HR ProfessionalRelated standards. ISO/IEC 42001 clause 5.3 and Annex A internal organization controls · ISO/IEC 38507.
Related articles. Govern, accountability & roles · People, Functions & Capability · Using the RACI / accountability map
Risk appetite states how much risk the organisation will carry with AI, expressed so that somebody at a decision gate can apply it without escalating — and including how much autonomy an agent may hold.
“We take a prudent approach to AI” decides nothing. It generates escalation, because every case has to be interpreted, and escalation volume is what turns a hub into a queue.
Usable appetite sorts proposals: which classes of use are acceptable, which need extra assurance, and which are refused outright. It also states autonomy limits per class of system, because autonomy is the fastest-moving variable in the estate and it drifts upward unless it is governed downward.
| Evidence | What it demonstrates |
|---|---|
| Recorded risk appetite statement | That the boundary is set |
| Autonomy limits per class of system | That the envelope is governed |
| Residual acceptances referencing the appetite | That it is applied rather than filed |
| Governing body approval | That it carries authority |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXAI Risk RegisterAppetite is meaningless until it appears as a threshold in the registerDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clause 6.1 · ISO/IEC 23894 · ISO 31000.
Related articles. Govern, accountability & roles · Risk, impact & trustworthiness · Phase 4 · Policy, risk & controls
Vision & roadmap states where AI governance is going and the sequence that gets it there — expressed as dependencies and exit criteria rather than as a calendar.
A roadmap earns its place by answering two things a list of good practices cannot: what has to come first, and how you know a phase is finished. Programmes fail those tests by starting where it feels productive and finishing when time runs out.
The framework’s rule is to fix the earliest gap, not the largest, because the phases are ordered by dependency. A Managed lifecycle capability sitting on an Initial accountability dimension delivers nothing, because nobody can enforce what the controls require.
| Evidence | What it demonstrates |
|---|---|
| Documented roadmap with phase owners | That the sequence is real |
| Exit criteria recorded per phase | That closure is defined |
| Maturity assessment history | That movement is evidenced |
| Governing body reporting on phase progress | That the vision reaches decision-makers |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXAI Governance Maturity ScorecardThe roadmap starts from a score, not an opinionDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceExtending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerRelated standards. ISO/IEC 42001 clauses 4 to 10 as an implementation arc.
Related articles. How to use the roadmap · The two axes · Run a maturity assessment
The governance loop is the continuous cycle — Direct, Assess, Operate, Improve — by which an organisation sets its intent for AI, understands its reality, runs with controls in place, and feeds what it learns back into intent. It is not a stage in the lifecycle. It runs across all of them.
There is a specific failure mode that afflicts well-resourced AI governance programmes, and it is not the one people expect.
The organisation does the work. It writes the policy, appoints the roles, builds the inventory, runs the assessments, buys the tooling. Twelve months later everything on the plan is marked complete. And the governance is no better than it was at month three, because nothing that was learned in operation ever made it back into the direction. The policy still says what it said. The risk appetite was never revisited against what the systems actually did. The controls that turned out to be unworkable are still in the control set, quietly bypassed.
That is a governance programme without a loop. It produces artefacts rather than improvement, and it decays from the moment the implementation project closes.
The loop is what makes governance a system rather than a project. Each movement produces something the next one needs, and the fourth produces something the first one needs. Close that circuit and the organisation improves whether or not anyone is running a programme. Leave it open and every gain has to be pushed uphill by a person.
Direct sets the direction: objectives, policy, risk appetite and roles, so everything downstream has a mandate. It answers what the organisation is trying to achieve with AI, what it will not do, how much risk it will carry, who decides, and how far a system may act on its own.
Direction that stays abstract governs nothing. “We will use AI responsibly” is not a direction; it is a sentiment. A usable direction is specific enough that a team can tell whether a proposed system is inside it or outside it without escalating. Risk appetite expressed in terms someone can apply at a decision gate. Autonomy limits stated per class of system. Prohibited uses named.
Assess understands the context and risks: it maps where AI is used and measures how it performs against expectations. It has two halves, and organisations routinely do the first and skip the second.
The gap between the two halves is where most programmes sit. An inventory tells you what you have; it does not tell you whether any of it is behaving. A programme that maps but never measures has visibility without assurance, and will be surprised.
Operate is the day-to-day: running AI with controls in place, managing risks as systems are built and used. It is the movement with the most people in it and the least ceremony, and it is where the evidence for everything else is created.
The design principle that matters here is that evidence should be a by-product of the work, not a separate activity. An approval that is recorded because the workflow requires it before proceeding is durable evidence. An approval reconstructed from an email thread six months later is not evidence; it is an account. The first costs nothing extra at the moment it happens. The second costs a great deal and convinces nobody.
Improve reviews what the evidence shows and acts on it, closing gaps and adapting as conditions change. It is the movement most often skipped, because it is the only one with no external forcing function. Nobody sends a deadline for Improve.
Two things distinguish real improvement from a review meeting. First, it changes something — a control, a policy, a threshold, a role, a limit. Second, the change is recorded as a change, so that six months later somebody can see what was learned and why the direction moved. Improvement that leaves no trace is indistinguishable from drift.
The loop only works if two specific connections are live. Both are easy to leave broken, and both are invisible until something goes wrong.
The commonest break is between Operate and Improve: monitoring data is collected diligently and read by nobody with the authority to act. The second commonest is between Improve and Direct: a review concludes that something must change, and the policy is never actually amended.
Because it is a loop, there is no wrong entry point — but there is a most useful one. Organisations with no governance at all usually start at Direct, because a mandate is what unblocks everything else. Organisations that already have AI in production and no governance almost always get further by starting at Assess, because the inventory produces the evidence that makes the case for the mandate.
This is the distinction that most often needs restating. The lifecycle is the path a single AI system travels from inception to retirement. The loop is how the organisation governs, and it runs continuously across every system at every stage at once.
Direction set at the top constrains what happens at every lifecycle stage. What is learned in operating one system feeds back into the direction that will shape the next. A lifecycle without a loop produces well-governed individual systems and an organisation that never gets better at it. A loop without a lifecycle produces good intentions with no point of application.
An auditor, assurance function or regulator will typically ask to see:
Read the grid downward to test your own loop. If the Improve column is thin, the organisation is governing but not learning. If the Assess column is thin, it is learning from anecdote. If the Direct column is thin, everything downstream is discretionary.
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXBoard reporting pack outlineThe loop's output is what the board actually readsDownload| Role | Responsibility in the loop |
|---|---|
| Board & governing body | Owns Direct at the top; receives the output of Improve and tests that it changed something |
| Accountable executive | Answerable for the loop turning at all, and for the cadence being adequate |
| AI governance lead | Runs the loop day to day; owns Assess and drives Improve to a decision |
| Governance analysts & coordinators | Maintain the inventory, gather evidence, track corrective actions to closure |
| Product & system owners | Own Operate for their systems and surface what the evidence shows |
| Risk & assurance lead | Independently tests that the loop is closing rather than merely convening |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clauses 5 to 10, and the Plan-Do-Check-Act structure that underlies them · ISO/IEC 38507 (governance implications of AI for the governing body) · ISO/IEC 23894 (risk management) · NIST AI RMF — Govern, Map, Measure and Manage as a continuous set rather than a sequence.
Related articles. Govern, accountability & roles · The AI management system · The AI system lifecycle · The assurance rhythm · Operating context
The assurance rhythm is the recurring cadence — plan, operate, review, audit, improve — by which an organisation runs its AI controls for a period, checks them itself, has them tested independently, and acts on what both find. It is what turns the governance loop from a principle into a dated, repeatable calendar.
The governance loop says what has to happen. The assurance rhythm says when, and that turns out to be the harder half.
Governance that has no cadence does not stop. It degrades in a specific and recognisable way: it becomes reactive. Reviews happen after incidents. Audits happen because a customer asked. Policy is revisited when somebody notices it is out of date. Every activity is triggered by an external event, which means the organisation only ever examines the parts of its governance that something has already gone wrong with.
A rhythm inverts that. Because the review is scheduled, it examines the controls nothing has gone wrong with — which is precisely where undetected weakness lives. Because the audit is scheduled, its findings arrive while there is still time to act on them cheaply. Because the plan is scheduled, resourcing decisions are made deliberately rather than defended after the fact.
There is a second effect that matters as much. A rhythm makes governance legible. Everyone knows when the review is, what it will ask for, and what happens to the findings. Evidence gets produced continuously because people know it will be looked at on a date. Assurance stops being a fire drill and becomes a habit.
Plan sets the objectives, scope and controls for the period ahead. It is a commitment, not a wish list: what will be governed, to what depth, with what resources, and what will be true at the end that is not true now.
The most useful thing a plan does is make scope explicit. Which systems are in this cycle. Which domains get depth this period and which are carried at baseline. What the audit will cover. Organisations that skip this end up with an assurance programme whose scope is whatever the auditor happened to look at, which is not a scope at all.
Operate runs the AI and its controls in line with the plan. This is the same movement that appears in the governance loop, and it is the longest phase of the cadence by a wide margin — most of the period is spent here.
The rhythm imposes one requirement on it that the loop alone does not: evidence has to accumulate in a form somebody else can read on a known future date. Not reconstructable. Not held by one person. Findable, dated, attributable.
Review checks performance, incidents and control effectiveness against expectations. It is management’s own examination, and it precedes audit deliberately: an organisation that finds its own gaps first is in a fundamentally different position from one that waits to be told.
The distinction that gives review its value is between control existence and control effectiveness. A control that exists is documented and assigned. A control that is effective is actually preventing or detecting what it was designed for. Review that only confirms existence produces a clean report and no assurance.
Audit independently tests that controls are present and working as intended. The word doing the work is independently. An audit performed by the people who built and run the controls is a review with a different name, and it carries none of the assurance value.
Independence is structural, not attitudinal. It means the person testing does not report to the person whose controls are being tested, and has no stake in the outcome. This is the second and third lines of defence made concrete: the second line sets and oversees the control framework, the third tests it and reports where the first two cannot suppress the finding.
Improve acts on what the evidence shows, adjusting controls, policy and the plan. Its health is measurable in a way the other movements are not: count the findings from the last cycle, and count how many are closed, with a named owner and a date, and evidence that the fix works.
An open finding older than a full cycle is the clearest single indicator of an assurance rhythm that is convening rather than functioning. The organisation is generating knowledge about its own weaknesses faster than it is acting on it, and every cycle widens the gap.
A single cadence cannot govern systems that change at different speeds. Healthy organisations run the same five movements at three tempos, with each feeding the one above it.
| Tempo | Typical period | What it examines | Who receives it |
|---|---|---|---|
| System | Continuous to monthly | Monitoring, drift, incidents, control operation for individual systems | System owners; governance analysts |
| Portfolio | Quarterly | Control effectiveness across the estate, risk register movement, findings closure | AI governance forum; accountable executive |
| Enterprise | Annual | Management review, internal audit programme, policy and risk appetite, certification cycle | Board, audit committee, external assessor |
The mistake is running only the slowest. A board that reviews AI annually is doing something valuable and is structurally incapable of governing a system that was built, deployed and changed three times since the last meeting. The fast tempo is where control actually happens; the slow tempo is where direction gets reset.
The governance loop and the assurance rhythm are the same idea at two resolutions. The loop names four movements and says they must connect. The rhythm splits Operate into operate-and-review, adds independent audit as a distinct movement, and attaches dates to all of it.
Put simply: the loop is why, the rhythm is when. An organisation that has adopted the loop but never scheduled it has agreed with the principle and not yet implemented it.
An auditor, assurance function or regulator will typically ask to see:
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXEvidence RegisterEvery rhythm event leaves a dated recordDownloadDOCXBoard reporting pack outlineThe quarterly output of the rhythmDownload| Role | Responsibility in the rhythm |
|---|---|
| Board & governing body | Receives audit findings directly; satisfies itself the rhythm is running and findings close |
| Accountable executive | Owns the plan and answers for unclosed findings |
| Risk & assurance lead | Runs review and the audit programme; independent of delivery |
| AI governance lead | Maintains the calendar, drives evidence readiness, tracks findings to closure |
| Product & system owners | Operate controls and produce evidence at system tempo |
| Governance analysts & coordinators | Assemble cycle packs, maintain the findings register |
This framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Providing second-line assurance and running internal auditsISO/IEC 42001 Internal AuditorAuditing an AI management system independentlyISO/IEC 42001 Lead AuditorStanding up and running the AI management systemISO/IEC 42001 Lead ImplementerRelated standards. ISO/IEC 42001 clause 9 (performance evaluation, internal audit, management review) and clause 10 (improvement) · ISO 19011 (guidelines for auditing management systems) · ISO/IEC 17021 for the certification audit process · ISO/IEC 38507 (governance implications of AI for the governing body) · NIST AI RMF — the Measure function.
Related articles. The governance loop · Risk, Assurance & Audit · The AI management system · Govern, accountability & roles · Control domains
Evidence artefacts are what governance produces as it runs — policy, risk register, impact assessment, evidence records and audit logs. What distinguishes real evidence from an account is not its format but whether it was produced by the work or assembled afterwards.
Every obligation, control and assurance activity in the framework ultimately resolves to a request: show me. The organisations that answer that question well are not the ones with the most documentation; they are the ones whose documentation was a by-product of doing the work.
The practical test is timing. An approval recorded because the workflow required it before proceeding costs nothing extra at the moment it happens and is durable. The same approval reconstructed from an email thread six months later costs a great deal and proves little. Design controls so that the compliant path emits the record.
| Evidence | What it demonstrates |
|---|---|
| Policy, versioned and approved | Direction exists and binds |
| Risk register with owners, treatments and named acceptances | Risk is managed |
| Completed impact assessments that changed something | Assessment is a control |
| Control operation records and approvals | Controls run |
| Audit log traceable from output to accountable human | Accountability survives |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXEvidence RegisterOne row per artefact, with owner, location and review dateDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerProviding second-line assurance and running internal auditsISO/IEC 42001 Internal AuditorRelated standards. ISO/IEC 42001 clause 7.5 (documented information) and clause 9 · ISO 19011.
Related articles. The AI system lifecycle · The assurance rhythm · Phase 6 · Assure & certify
Governing the operating context is the discipline of translating every external demand — regulations, obligations, sector rules and public trust — into internal requirements that land in one management system rather than four parallel compliance projects.
Organisations rarely fail because they misread a single law. They fail because each source of demand starts its own workstream: legal reads the regulation, procurement answers a customer questionnaire, a sector regulator issues guidance, communications handles the reputational side. Four teams, four evidence sets, and no single answer to what an auditor actually asks.
The cost is not just duplication, it is contradiction — the contractual commitment that turns out stricter than the regulation, discovered during an incident. The resolution is to notice that the bands overlap far more than they differ. Strip the vocabulary and most ask for the same small number of things: know where your AI is, assess what it could do to people, keep a human meaningfully in charge, test before you rely on it, disclose, and be able to show all of the above.
An inventory satisfies all four bands at once. That is the argument for one management system, made concrete.
| Evidence | What it demonstrates |
|---|---|
| Applicability register covering all four bands | That the analysis was deliberate and complete |
| Requirement-to-control mapping | That each demand has a mechanism, not an acknowledgement |
| Role determination per system | That obligations were scoped rather than assumed |
| Horizon-scanning log with dated impact assessments | That the context is monitored |
| Contract and procurement review records | That commitments are assessed before acceptance |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXObligation Crosswalk TrackerOne register, many obligationsDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Standing up and running the AI management systemISO/IEC 42001 Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clause 4 and 4.2 · ISO/IEC 23894 · NIST AI RMF — Govern and Map.
Related articles. Operating context · How to read the crosswalk · Control domains
The three lines model separates who owns and operates controls, who sets and oversees the control framework, and who independently tests that it works. Applied to AI, the model is unchanged; what changes is that the first line increasingly includes autonomous agents.
The model is widely claimed and frequently not implemented, because the labels are easy and the reporting lines are not. Independence is structural: the person testing must not report to the person whose controls are being tested, and must have a route to the board that the audited function cannot intercept.
For AI specifically, one structural failure dominates — internal audit of AI governance performed by the AI governance function. The people are usually competent; the arrangement still produces a review rather than an audit, and an external assessor identifies it immediately.
| Evidence | What it demonstrates |
|---|---|
| Organisation chart showing reporting lines | That independence is structural |
| Internal audit charter and programme | That the third line is mandated |
| Audit reports delivered to the board or audit committee | That the route is not intercepted |
| Findings register with closure evidence | That findings drive change |
| Second-line monitoring and challenge records | That oversight is active |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXRACI / accountability matrixWhich line holds which controlDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Providing second-line assurance and running internal auditsISO/IEC 42001 Internal AuditorAuditing an AI management system independentlyISO/IEC 42001 Lead AuditorRelated standards. ISO/IEC 42001 clause 9 · ISO 19011 · ISO/IEC 17021 · the IIA three-lines model.
Related articles. Risk, Assurance & Audit · The assurance rhythm · Phase 6 · Assure & certify
Hub-and-spoke is the operating model in which one central function owns the standard, the tooling and the evidence model, while business units apply it inside written rails. The hub does not approve everything; it makes it possible for the spokes to decide correctly.
Fully centralised governance is consistent and becomes a queue; teams route around queues, so the hub ends up seeing a shrinking and unrepresentative sample of what is actually being built. Fully federated governance is fast and produces five incompatible interpretations of one policy.
Hub-and-spoke resolves this by splitting ownership: the hub owns the standard, the spokes own application. The rails — the written boundary between what a spoke may decide and what must escalate — are the most under-produced artefact in AI governance, and their absence is precisely why hubs become queues.
| Evidence | What it demonstrates |
|---|---|
| Documented operating model and rails | That the boundary is explicit |
| Named champions with recorded allocation | That the spokes are resourced |
| Function playbooks per discipline | That the standard was translated |
| Spoke-to-hub forum minutes with control revisions | That feedback is live |
| Hub remit and resourcing decision | That the hub is defined |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXRACI / accountability matrixCentral versus federated accountability, side by sideDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Extending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clause 5.3 and Annex A internal organization controls.
Related articles. The Governance Core · Phase 2 · Operating model & CoE · Phase 5 · Embed across disciplines
Governing agentic AI means extending the control framework to systems that take actions, chain them, call tools and operate without a human in each loop. It adds four controls the established nine domains do not produce — and it adds to those nine rather than replacing any of them.
The nine established control domains were designed for AI systems that produce outputs a human then acts on. Three of them bend badly under agentic load: responsible use assumes intended use is bounded by what an operator chooses to do with an output; lifecycle assumes behaviour is broadly fixed between releases; third parties assumes a supplier relationship you can inspect.
The most consequential scoping error in agentic governance is treating the tenth domain as a substitute. An agentic system needs everything the nine require, plus autonomy limits, guardrails, stop controls and action-level logging. And accountability does not move: an agent is never itself certified or accountable.
| Evidence | What it demonstrates |
|---|---|
| Autonomy levels per system with change history | That autonomy is governed, not drifting |
| Runtime guardrail configuration | That constraints hold in production |
| Stop-control test records | That the control has been exercised |
| Action-level logs | That accountability survives long chains |
| Agent ownership entries in the inventory | That a human owns each agent |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
XLSXStatement of ApplicabilityControl area 10 · Agentic & autonomous AIDownloadXLSXAI Risk RegisterAgentic risk lines with autonomy level recordedDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceExtending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerRelated standards. ISO/IEC 42001 clause 10 · ISO/IEC 5338 · ISO/IEC 24029 · NIST AI RMF — Manage. The agentic control domain is a GAICC extension with no direct equivalent in current published control sets.
Related articles. Control domains · AI-native · Phase 7 · Adapt & extend · Human oversight and autonomy levels
Autonomy is the level at which a system may act without a human decision. Human oversight is what has to be true at that level for a person to remain able to understand, intervene and stop it. Both are chosen and recorded per system, not discovered after deployment.
Human oversight is the requirement most often satisfied on paper, because the paper version is easy: name a reviewer. Effectiveness has observable properties, and they are harder. A reviewer approving two hundred outputs an hour is not meaningfully overseeing anything. A person who can technically halt a system but has never been told they hold that authority cannot exercise it.
Autonomy also has a direction of travel. Agents are routinely given slightly more scope than last month, one reasonable increment at a time, with no single change large enough to trigger review. Recording autonomy as a level, and making increases a decision, is what converts drift into a governed choice.
| Evidence | What it demonstrates |
|---|---|
| Autonomy level per system, with change history | That autonomy is a governed choice |
| Oversight design and operator instructions | That oversight is specified |
| Escalation paths and assigned stop authority | That intervention is possible |
| Stop-control exercise records | That it works when tested |
| Competence records for overseers | That the person can actually oversee |
| Intervention and override logs | That oversight is observable |
Artefacts for this element
Governing AI you can prove means producing documents somebody can read back to you. These are the artefacts this element produces — the template is the starting point, not the answer.
DOCXAI Impact Assessment templateAutonomy level is an input to the assessmentDownloadThis framework, the maturity model and the implementation roadmap are the body of knowledge; the GAICC credentials are extracted from it, each examining a defined part. Listed here by the kind of work they suit — none of them is a prerequisite for anything above.
Governing AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceLegal, compliance and regulatory affairsCertified AI Law & Compliance ProfessionalRelated standards. ISO/IEC 42001 clause 5 and Annex A responsible-use controls · ISO/IEC 42005 · NIST AI RMF — Govern and Manage.
Related articles. Governing agentic and autonomous AI · Crosswalk · Human oversight · Delivery & Operations