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"
This is the implementation journey, from the trigger that made AI governance unavoidable to an organisation able to survive and thrive in the AI era. Start where you are: teams already certified to ISO/IEC 42001 can begin around Phase 4, while greenfield programmes start at Phase 1. Select a phase for the work it involves, the maturity stage it reaches, the artifact it produces and the credential that builds it.
Phase 1 builds urgency and secures board sponsorship so AI governance has a clear reason and a clear owner from day one. Its output is not a document. It is authority: a recorded mandate and a named executive who is answerable.
Everything downstream is an exercise of authority that phase 1 either created or did not. Appointing an AI governance lead without a mandate produces somebody with a job title, a backlog and no ability to stop anything. Writing a policy without sponsorship produces a document that teams route around, politely.
The phase is short and it is skipped constantly, usually by well-intentioned people who feel that talking to the board is slower than starting work. It is slower. It is also the difference between a programme that can decline a launch and one that can only document its concerns.
There is a second, quieter reason. The mandate is what makes governance somebody’s actual job rather than an addition to five people’s existing jobs. Programmes that skip phase 1 are almost always staffed by volunteers, and volunteer governance decays the moment those people get busy.
Phase 1 is an evidence-and-persuasion phase. Three activities, in order.
A mandate that does not carry these four things will not survive its first real disagreement.
| Element | Why it is load-bearing |
|---|---|
| A named accountable executive | Accountability that is assigned to a committee is assigned to nobody |
| Stated scope | Which entities, which markets, which classes of system — so arguments about applicability end early |
| Authority to stop | Explicit power to withhold approval, or the role is advisory in practice whatever the title says |
| A reporting line to the board | A cadence and a route, so escalation does not depend on goodwill |
| Evidence | What it demonstrates |
|---|---|
| Board or committee minute recording the mandate | That authority exists and can be cited |
| Written appointment of the accountable executive | That accountability sits with a person |
| Stated scope of the AI management system | That applicability arguments were settled up front |
| AI-policy intent: principles and red lines | That direction was set before controls were designed |
| Initial AI use scan | That the case rested on evidence rather than assertion |
| Programme resourcing decision | That governance is somebody’s job, not everybody’s spare time |
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 templateDrafted here, adopted in phase 4DownloadDOCXBoard reporting pack outlineFirst pack lands hereDownload| Role | Responsibility in phase 1 |
|---|---|
| Board & governing body | Grants the mandate; accountable for the decision itself |
| Accountable executive | Accepts named accountability and sponsors the programme |
| AI governance lead | Assembles the scan and drafts the mandate paper |
| Risk & assurance lead | Frames AI risk in the organisation’s existing risk language |
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 ImplementerWriting an AI policy that will actually be adoptedHow to Write an AI PolicyGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clauses 4 and 5 (context, leadership, policy) · ISO/IEC 38507 (governance implications of AI for the governing body) · NIST AI RMF — the Govern function.
Related articles. How to use the roadmap · Govern, accountability & roles · Operating context · The governance loop · Phase 2 · Operating model & CoE
Phase 2 stands up the governing body and a central AI Governance Office — a Center of Excellence — as the hub, then sets the federated operating model so business units run as spokes within its rails. It converts a mandate held by one executive into a structure that can carry it.
There are only two ways to organise AI governance, and both fail on their own.
Fully centralised governance puts every decision through one team. It is consistent, and it becomes a queue. Delivery teams route around the queue, which means the governance function sees a shrinking and increasingly unrepresentative sample of what the organisation is actually building. Consistency is preserved over a smaller and smaller share of reality.
Fully federated governance lets each business unit govern itself. It is fast, and it produces five incompatible interpretations of the same policy, five evidence formats, and no way to answer a regulator's question at the organisational level.
Hub-and-spoke is the resolution: one hub owning the standard, the tooling and the evidence model; spokes owning application inside their own function. The hub does not approve everything. It makes it possible for the spokes to approve things correctly, and it can see what they decided.
The boundary that matters most is the last row on each side. Spokes decide inside the rails; anything outside them escalates to the hub and, if needed, to the governing body. Write the rails down. An escalation rule that depends on judgement about whether to escalate does not work.
The hub is smaller than people expect. Its job is leverage, not throughput — it should be sized to build and maintain the rails, not to review every system. If hub headcount scales linearly with the number of AI systems, the operating model has drifted back to centralised without anyone deciding to.
| Evidence | What it demonstrates |
|---|---|
| Governing body terms of reference and minutes | That a decision-making forum exists and functions |
| AI Governance Office remit and resourcing | That the hub is defined rather than assumed |
| Completed RACI / accountability map | That every activity has exactly one owner |
| Named champions per function with allocation | That the spokes are real |
| Documented escalation rails | That the boundary between spoke and hub authority is explicit |
| Operating model diagram and description | That the federation is designed rather than emergent |
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 matrixPhase 2's principal outputDownloadDOCXRACI / accountability mapThe narrative versionDownload| Role | Responsibility in phase 2 |
|---|---|
| Accountable executive | Chairs or sponsors the governing body; owns the operating model design |
| AI governance lead | Establishes the hub, drafts terms of reference, completes the RACI map |
| Board & governing body | Approves the operating model and the escalation route |
| Domain experts | Take up spoke roles in their own functions |
| Risk & assurance lead | Confirms the model preserves independence of the second and third lines |
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 ImplementerHR, people and workforce functionsCertified AI HR ProfessionalRelated standards. ISO/IEC 42001 clause 5.3 (roles, responsibilities and authorities) and Annex A internal organization controls · ISO/IEC 38507 · the three-lines model as applied to AI assurance.
Related articles. How to use the roadmap · Govern, accountability & roles · The Governance Core · Phase 1 · Mobilize & mandate · Phase 3 · Scope & baseline
Phase 3 defines the management-system scope and builds a complete inventory of AI use cases and the models — and agents — behind them. It is the phase that replaces belief about the AI estate with knowledge of it, and it is the foundation every later phase stands on.
Every governance activity after this phase takes the inventory as its input. Policy scope is drawn from it. Risk assessment is prioritised by it. Controls are applied to the systems in it. Audit samples from it. Board reporting counts it. An inventory that is 60% complete does not produce governance that is 60% effective; it produces governance that is confidently wrong about its own coverage.
There is a second reason phase 3 carries disproportionate weight: it is the only phase whose output is regularly cited by people outside the programme. A customer questionnaire asks how many AI systems you operate. A regulator asks which of them fall in scope of an obligation. A board asks what changed this quarter. All three are inventory queries.
And discovery is genuinely hard, which is why this phase is the most commonly underestimated on the roadmap. The systems that are easy to find are the ones somebody built deliberately and told you about. The ones that matter are the model inside a purchased SaaS product, the scoring step buried in an existing workflow, the assistant a team stood up on a corporate card, and the agent chain somebody assembled last month.
Scope is decided before discovery, not after, because scope determines what you are obliged to find. It states which legal entities, which markets and jurisdictions, which business units and which classes of system are inside the management system — and, explicitly, what is outside and why.
No single discovery channel finds everything, because each is blind to a different category. Run several in parallel and reconcile.
| Method | What it finds | What it misses |
|---|---|---|
| Ask the functions | Systems people know they built or bought | Anything not recognised as AI by its users |
| Procurement and spend review | Purchased tools and SaaS with AI features | In-house builds and free-tier tools |
| Model, project and code registries | Deliberate in-house development | Purchased capability and shadow use |
| Network, SSO and expense data | Shadow and unsanctioned tools | On-premise and embedded functionality |
| Vendor contract and DPA review | AI clauses and sub-processor AI | Features added after signature |
| Existing process walkthroughs | Scoring and decision steps inside workflows | Anything outside the walked processes |
The register carries one row per system, and the columns are chosen so that later phases can act on them without re-surveying: system ID, name, owner, purpose, lifecycle stage, data used, risk tier, autonomy level, human oversight arrangement, regulatory scope, and date last reviewed.
Two columns do most of the downstream work. Risk tier drives how much of the control set applies, which is what keeps phase 4 proportionate. Autonomy level determines whether the agentic control domain is in play, which is what keeps the framework current.
Once the estate is visible, tier it. The baseline is not a full risk assessment of every system — that is phase 4 work. It is a first-pass classification that answers one question: where does depth need to go?
An inventory built once and never maintained is worse than none, because it creates confidence in a snapshot that is silently ageing. Registration has to become a step in the paths by which AI actually enters the organisation: procurement approval, project initiation, vendor onboarding, and the design gate in the lifecycle. If registration depends on people remembering to tell the hub, the register decays from the day it is finished.
| Evidence | What it demonstrates |
|---|---|
| Documented management-system scope with justified exclusions | That boundaries were set deliberately |
| AI inventory register, populated and owned | That the estate is known |
| Discovery method record showing multiple channels | That completeness was pursued, not assumed |
| Risk tiering criteria and assigned tiers | That later depth will be proportionate |
| Autonomy level per system | That agentic scope is determined |
| Registration process embedded in procurement and project intake | That the register will stay current |
| Risk baseline summary to the governing body | That the picture reached the 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 System Inventory registerThe baseline is the registerDownloadXLSXAI Governance Maturity ScorecardBaseline the score at the same timeDownload| Role | Responsibility in phase 3 |
|---|---|
| AI governance lead | Owns scope, the register and the discovery programme |
| Governance analysts & coordinators | Run discovery, populate and reconcile the register |
| Domain experts | Surface AI inside their function, including what is not called AI |
| Product & system owners | Accept named ownership of their systems |
| Data & security lead | Contributes shadow-IT, SSO and vendor data to discovery |
| Accountable executive | Answers for the completeness of the baseline |
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 GovernanceOperating AI governance inside the Govern365 platformGovern365 Certified AssociateRelated standards. ISO/IEC 42001 clause 4.3 (determining scope) and clause 6.1 (risk and opportunity) · ISO/IEC 23894 (risk management) · ISO/IEC 5338 (lifecycle processes) · NIST AI RMF — the Map function.
Related articles. How to use the roadmap · The AI system lifecycle · Operating context · Phase 2 · Operating model & CoE · Phase 4 · Policy, risk & controls
Phase 4 writes the policy, treats risk, sets the Statement of Applicability and implements controls across the lifecycle. It is the phase where governance stops being structure and starts being something that acts on systems.
Phase 4 is where most of the programme’s visible output is produced, and where the largest single failure mode on the roadmap lives: producing all four artefacts without ever running a system through them.
A policy that no system has been tested against is a hypothesis. A Statement of Applicability assembled from a template is a claim about controls that may not exist. A risk register populated in a workshop describes risks somebody imagined. All four can be complete, well-formatted, board-approved, and entirely disconnected from what the organisation does.
The correction is simple to state and unpopular to run: before the phase closes, take one real system — ideally an awkward one, high tier, already in production — and put it through the full control set end to end. Everything that is impractical, ambiguous or missing surfaces in that single pass, and it surfaces while the programme still has the attention and budget to fix it.
The AI policy is the organisation’s recorded direction: purpose, scope, principles, risk appetite, roles, red lines, lifecycle requirements, third-party requirements, and how compliance is reviewed. Its test is not whether it is comprehensive but whether it is decidable — can a team read it and tell, without escalating, whether what they are proposing is permitted?
Two sections carry most of that weight. Risk appetite has to be expressed in terms someone can apply at a gate, not as a statement of prudence. Red lines — uses the organisation will not pursue — are the fastest-acting clause in the document, because they resolve a whole class of proposals without analysis.
Risk assessment is prioritised by the tiering done in phase 3, not run uniformly. High-tier and autonomous systems get full assessment including impact assessment; limited-tier systems get a proportionate review. The output is a risk register with owners, treatments and residual positions that somebody has actually accepted by name.
The Statement of Applicability records, for each control area, whether it applies, the justification, the owner, the implementation status and where the evidence lives. It is the phase’s most externally-visible artefact: certification bodies, customers and regulators all read it, and it is usually the first document an assessor asks for.
Work through all ten control domains, not nine. The standard control set covers nine; the agentic and autonomous AI domain is a GAICC extension, and any organisation running agents needs a recorded position on it whether or not a certification scheme asks for one yet.
Controls are implemented at the lifecycle stage where they bite, not collected in a document. A control that exists as a policy sentence and has no attachment point in how work actually happens is a control in name only.
The practical test is the one from the lifecycle article: can somebody produce the release approval for a system that went live last quarter in under five minutes? If yes, the control is embedded in the work. If it takes a day of email archaeology, it is not.
| Evidence | What it demonstrates |
|---|---|
| Approved AI policy, versioned and communicated | That direction exists and binds |
| Risk register with owners, treatments and named acceptances | That risk is managed rather than catalogued |
| Completed impact assessments for high-tier and autonomous systems | That effects on people were analysed before reliance |
| Signed Statement of Applicability across ten domains | That control decisions were made and justified |
| Control implementation records mapped to lifecycle stages | That controls are attached to real work |
| End-to-end evidence pack for one system through the full set | That the control set is workable, not theoretical |
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 ApplicabilityPhase 4's principal outputDownloadXLSXAI Risk RegisterPopulated hereDownloadDOCXAI Policy templateFormally adopted hereDownload| Role | Responsibility in phase 4 |
|---|---|
| Governing body | Approves the policy, the risk appetite and the Statement of Applicability |
| AI governance lead | Drafts the policy and owns the SoA and control framework |
| Risk & assurance lead | Owns risk assessment method and challenges residual acceptances |
| Product & system owners | Implement controls and carry accepted risk for their systems |
| Data & security lead | Owns the data and third-party control implementation |
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 ImplementerWriting an AI policy that will actually be adoptedHow to Write an AI PolicyGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clauses 6 and 8, Annex A and the Statement of Applicability at clause 6.1.3 · ISO/IEC 23894 (risk management) · ISO/IEC 42005 (impact assessment) · NIST AI RMF — the Manage function.
Related articles. Control domains · The AI system lifecycle · Risk, impact & trustworthiness · Phase 3 · Scope & baseline · Phase 5 · Embed across disciplines
Phase 5 operationalises governance into each function’s daily work through embedded AI champions — the spokes — who connect legal, HR, product, procurement and more back to the hub. It is the phase where governance stops being something the programme does and becomes something the organisation does.
By the end of phase 4 an organisation has a working management system that a small central team operates. That is a real achievement and an unstable one. It has a single point of failure, it scales linearly with headcount, and it is felt everywhere else as an external tax on delivery.
Phase 5 resolves this by moving application into the functions. Procurement asks the AI questions as part of vendor assessment because they are in the procurement checklist, not because the hub reminded them. HR knows what an impact assessment on a hiring tool needs to cover. Legal knows which contract clauses commit the organisation to controls it has to be able to deliver. Product knows what the design gate asks before they reach it.
The reason this is the phase that moves maturity from Defined to Managed is that Managed means consistent operation without central prompting. You cannot reach it while the hub is still the mechanism.
A playbook translates the control framework into one discipline’s own workflow and vocabulary. It is not a summary of the policy; it is the answer to “what do I do differently on Tuesday?”
| Function | What its playbook has to answer |
|---|---|
| Procurement | Which AI questions go into vendor assessment, which contract clauses are mandatory, what evidence to require and retain |
| Legal | Which commitments the organisation can actually deliver, how role determination is made, what disclosure is required |
| HR | What governance applies to AI used on people, what oversight a hiring or performance tool needs, how to handle a challenge |
| Product & engineering | What the design gate asks, what evidence the build must emit, what testing is required before release |
| Data & security | Provenance and permitted-use checks, robustness and adversarial 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 |
Phase 5 closes when the functions are running their playbooks without prompting from the hub. That is an observable state, and it has a specific test: stop prompting for two cycles and see what still happens.
| Evidence | What it demonstrates |
|---|---|
| Function playbooks, one per in-scope discipline | That the framework was translated, not just distributed |
| Named champions with recorded time allocation | That the spokes are resourced |
| Procurement checklist and contract clause set including AI | That the inflow of third-party AI is governed at source |
| Vendor assessment records for AI suppliers | That third-party controls operate |
| Data provenance and permitted-use records produced by the data function | That controls run inside the function, not the hub |
| Training and competence records by discipline | That capability was built where it is applied |
| Spoke-to-hub forum minutes with control changes made | 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.
XLSXRACI / accountability matrixExtended to each disciplineDownloadDOCXAI Impact Assessment templateRun by the discipline, not the centreDownload| Role | Responsibility in phase 5 |
|---|---|
| AI governance lead | Owns the transfer; resists the temptation to keep approving |
| Domain experts | Write and own their function’s playbook |
| People & capability | Resource and evidence discipline-specific training |
| Product & system owners | Operate controls as part of delivery rather than as a gate imposed on it |
| 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.
HR, people and workforce functionsCertified AI HR ProfessionalCost engineering, estimating, planning and project controlsAI Cost & Control ProfessionalDelivering AI projects and programmesCertified AI Project ProfessionalRelated standards. ISO/IEC 42001 clause 7 (support, competence, awareness) and Annex A controls for resources, third parties and responsible use · ISO/IEC 42005 (impact assessment) as applied within functions · NIST AI RMF — the Govern function’s culture and workforce elements.
Related articles. People, Functions & Capability · Control domains · Foundations · Phase 4 · Policy, risk & controls · Phase 6 · Assure & certify
Phase 6 runs the three lines — first-line owners operating controls, second-line oversight, third-line independent internal audit — then external conformity assessment to earn certification. It is the phase where the organisation stops asserting that its governance works and has somebody independent test it.
Everything up to phase 5 is self-reported. The organisation designed its own controls, decided they were adequate, and confirmed they were running. That is necessary and it is not assurance, because the people who built a control are the least able to see what it does not catch.
Phase 6 introduces independence. The value is not the certificate; it is the finding you would never have generated yourself. A well-run internal audit before external assessment is the cheapest way an organisation ever discovers that a control everyone believed was operating has not produced evidence since March.
The commercial value is real but secondary, and it is routinely overstated in a way that creates risk. Certification against ISO/IEC 42001 demonstrates that a management system meets that standard. It is not a determination that the organisation complies with any particular regulation, and describing it that way in a customer conversation is a claim the organisation cannot support.
Independence is structural, not a matter of professionalism. The test is a reporting line: 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: use an independent third party for the internal audit, or use a function that is 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.
Scope the audit against the Statement of Applicability, because that is the document the external assessor will use. Audit control effectiveness, not existence: for each control, what would you expect to see if it had failed silently three months ago, and have you looked for it?
Findings need owners, dates and evidence that the fix works. An open finding older than a full cycle is the clearest signal that the assurance rhythm is convening rather than functioning — and it is the first thing an assessor will pull on.
Management review is the governing body examining the whole system against evidence: performance, incidents, audit findings, risk movement, changes in the operating context, and whether the policy and risk appetite still fit. It closes the loop between what the evidence showed and what the direction says, and it must be minuted with decisions traceable into changed controls or policy.
Conformity assessment by an accredited body typically runs in two stages: a documentation and readiness review, then an on-site or remote assessment of the system in operation. Between them, the organisation fixes what stage one surfaced.
This phase generates the organisation’s most quotable claims and therefore its highest claim risk. Three rules: certification against ISO/IEC 42001 is not regulatory compliance; voluntary frameworks are voluntary and should not be described as requirements; and accreditation status should be described exactly as it is, including where it is in progress rather than complete.
| Evidence | What it demonstrates |
|---|---|
| Internal audit programme and completed audit reports | That independent testing happened |
| Findings register with owners, dates and closure evidence | That findings drive change rather than accumulate |
| Management review minutes with traceable decisions | That the governing body examined the system against evidence |
| Control effectiveness test results | That controls were tested for working, not for existing |
| Evidence pack sampled across systems and lifecycle stages | That evidence is retrievable at assessment speed |
| Certification body accreditation confirmation | That the assessment will carry weight |
| Stage 1 and stage 2 assessment reports | That external conformity assessment was completed |
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 RegisterThe certification file, assembledDownloadXLSXStatement of ApplicabilityTested againstDownload| Role | Responsibility in phase 6 |
|---|---|
| Board & audit committee | Receives audit findings directly; satisfies itself findings close |
| Risk & assurance lead | Owns the audit programme; independent of delivery |
| AI governance lead | Prepares evidence, coordinates assessment, tracks findings |
| Accountable executive | Answers for unclosed findings and for claim accuracy |
| Product & system owners | First line; produce evidence and remediate findings |
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 AuditorStanding up and running the AI management systemISO/IEC 42001 Lead ImplementerAuditing an AI management system independentlyISO/IEC 42001 Lead AuditorRelated standards. ISO/IEC 42001 clause 9 (internal audit, management review) and clause 10 (nonconformity and improvement) · ISO 19011 (auditing management systems) · ISO/IEC 17021 (certification body requirements) · ISO/IEC 42006 (requirements for bodies auditing AI management systems).
Related articles. The assurance rhythm · Risk, Assurance & Audit · Control domains · Phase 5 · Embed across disciplines · Phase 7 · Adapt & extend
Phase 7 keeps the system alive as work becomes agent-driven: policy-as-code, continuous and increasingly automated assurance, governance for autonomous agents and automated workflows, and horizon-scanning for new regulation. It is the only phase with no exit criterion, because it is not a phase you finish.
A certified management system is a snapshot of adequacy. Three things move underneath it, all faster than an annual review cycle: the regulation, the technology, and the organisation’s own use of it.
Of the three, the technology moves fastest and least predictably. A control set designed for systems that produce outputs a human acts on does not automatically govern a system that takes actions, chains them, calls tools and runs for hours without a person in the loop. That shift is already underway in most organisations, and phase 7 is where the framework keeps pace with it rather than quietly falling behind.
The organisational failure this phase prevents is specific and common: the programme achieves certification, is declared complete, and its team is redeployed. Eighteen months later the surveillance assessment finds a management system that has been maintained by nobody, governing an estate that has changed substantially. Phase 7 exists to make that outcome a decision rather than a drift.
Manual assurance has a ceiling. At a certain estate size, sampling evidence by hand every quarter stops being feasible and starts being theatre. The response is to move controls from documented expectations toward mechanisms that enforce and evidence themselves.
| From | To |
|---|---|
| Policy as a document people are expected to read | Policy-as-code: constraints enforced where systems are built and deployed |
| Periodic control sampling | Continuous control monitoring with exceptions surfaced automatically |
| Evidence assembled for an audit | Evidence emitted by the pipeline as a by-product of the work |
| Inventory maintained by request | Inventory populated from deployment and procurement systems |
| Drift discovered at review | Drift detected by monitoring and routed to an owner |
The tenth control domain is where most phase 7 extension work lands. Agentic systems need everything the other nine domains require, plus four things the original control set does not naturally produce.
Accountability does not move. However autonomous the system, the credential and the accountability sit with the human who owns and supervises it. An agent is never itself certified or accountable.
Somebody is named to watch each band of the operating context, changes are assessed for impact on the existing control set, and the result goes to the same governance forum as everything else. The output of a good horizon-scan is usually not new work — it is a recorded decision that an existing control already covers the change, made six months before anyone asks.
Three quieter obligations that phase 7 carries and programmes routinely drop: surveillance assessment cycles have to be resourced and prepared for; competence has to be refreshed as people move and the technology shifts; and the framework itself needs versioning, with a published changelog, so readers can tell which edition they are looking at.
| Evidence | What it demonstrates |
|---|---|
| Permanent resourcing line for AI governance | That the system is operated, not just built |
| Automated control and policy-as-code implementations | That assurance scales past manual sampling |
| Continuous monitoring output with exception routing | That drift is detected rather than discovered |
| Autonomy levels recorded per system, with change history | That autonomy is governed rather than drifting |
| Runtime guardrail configuration and stop-control test records | That agentic controls operate in production |
| Action-level logs traceable to an accountable human | That accountability survives long action chains |
| Horizon-scan log with dated impact assessments | That context change is assessed, not just noticed |
| Surveillance assessment records and framework changelog | That the system is maintained across cycles |
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 TrackerRe-run when the regulatory picture movesDownloadXLSXAI Governance Maturity ScorecardRe-score each cycleDownload| Role | Responsibility in phase 7 |
|---|---|
| Accountable executive | Sustains the permanent resourcing and answers for continued adequacy |
| AI governance lead | Owns automation, framework versioning and the horizon-scan |
| Risk & assurance lead | Keeps assurance independent as it automates |
| Data & security lead | Owns runtime guardrails, logging and monitoring infrastructure |
| Product & system owners | Own autonomy levels and stop controls for their agents |
| Board & governing body | Tests that the system is still fit as the estate and the rules move |
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.
Extending the management system across sectors, borders and business unitsISO/IEC 42001 Senior Lead ImplementerWriting an AI policy that will actually be adoptedHow to Write an AI PolicyRelated standards. ISO/IEC 42001 clause 10 (continual improvement) and the surveillance cycle under ISO/IEC 17021 · ISO/IEC 42006 · ISO/IEC 23894 (risk management as conditions change) · NIST AI RMF — Govern and Manage as continuous functions.
Related articles. Control domains · The governance loop · The assurance rhythm · Operating context · Phase 6 · Assure & certify
The implementation roadmap is the seven-phase sequence that takes an organisation from no AI governance to a certified, continuously-assured management system. It is an ordering of dependencies, not a calendar: each phase exists because the phases after it cannot hold without it.
A roadmap is only useful if it tells you two things a list of good practices cannot: what has to come first, and how you know a phase is finished.
Most AI governance programmes fail one of those two tests. They start at the phase that feels most productive rather than the one that unblocks the rest, and they finish phases by running out of time rather than by meeting a criterion. The result is a programme with impressive artefacts and no authority: policies nobody is bound by, inventories nobody maintains, assessments that cannot stop a launch.
The seven phases are ordered by dependency. Phase 2 needs the mandate from phase 1, because you cannot appoint accountable roles without the authority to appoint them. Phase 4 needs the baseline from phase 3, because you cannot write a proportionate policy for an estate you have not yet seen. Phase 6 needs everything before it, because independent audit against controls that do not exist produces a finding, not assurance.
Read the sequence as a set of preconditions rather than a schedule, and the roadmap stops being a plan you fall behind and becomes a diagnostic you can use at any point to answer: what is the earliest thing that is not yet true?
| Phase | What it produces | Loop movement | Maturity movement |
|---|---|---|---|
| 1 · Mobilize & mandate | Board mandate, AI-policy intent, named programme owner | Direct | Initial → Developing |
| 2 · Operating model & CoE | Governing body, AI Governance Office, hub-and-spoke model, accountable roles | Direct | Developing |
| 3 · Scope & baseline | AI inventory, management-system scope, risk baseline | Assess | Developing → Defined |
| 4 · Policy, risk & controls | AI policy, risk register, Statement of Applicability, controls in place | Operate | Defined |
| 5 · Embed across disciplines | Function playbooks, embedded champions, vendor and data controls in use | Operate | Defined → Managed |
| 6 · Assure & certify | Three-lines assurance, internal audit, management review, certification | Assure & improve | Managed |
| 7 · Adapt & extend | Continuous and automated assurance, agentic-AI governance, horizon-scan | Improve (continuous) | Optimizing (continuous) |
Almost nobody starts at phase 1 with a blank sheet. Four entry points are legitimate, and choosing the right one saves months.
Each phase closes on an exit criterion, not on a date. The criterion is deliberately a single observable fact, because a phase with a checklist of twelve conditions never closes.
| Phase | Exit criterion — the phase is done when… |
|---|---|
| 1 | A named executive is accountable for AI governance in writing, with a board-recorded mandate. |
| 2 | The governing body has met, and every accountable role in the RACI map has a name against it. |
| 3 | The inventory is complete enough that a business unit cannot name an AI system missing from it. |
| 4 | The policy is approved, the Statement of Applicability is signed, and one system has passed through the full control set. |
| 5 | Each in-scope function has a playbook and a named champion, and is using them without prompting from the hub. |
| 6 | An independent internal audit has been completed and its findings have owners and dates. |
| 7 | The horizon-scan and the assurance cycle both run without the programme team driving them. |
Phases overlap freely, and most organisations run two or three at once. Four dependencies, though, do not bend.
Duration varies with estate size and regulatory exposure far more than with headcount. The figures below are typical ranges for a mid-size organisation running the programme with a small dedicated team, not commitments.
Each phase advances a maturity dimension, produces a toolkit artefact and builds toward a credential. That is the weave that makes the four GAICC pages one system rather than four microsites: the roadmap says when, the framework says what, the maturity model says how far, and the credential landscape says who is capable of it.
| Evidence | Phase it closes |
|---|---|
| Board minute recording the mandate and the named accountable executive | 1 |
| Terms of reference for the governing body and a completed RACI map | 2 |
| AI inventory register and documented management-system scope | 3 |
| Approved AI policy, risk register and signed Statement of Applicability | 4 |
| Function playbooks and named champions per discipline | 5 |
| Internal audit report, management review minutes, certification pack | 6 |
| Horizon-scan log and continuous-assurance records | 7 |
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 ScorecardScore first; the score picks the phaseDownload| Role | Responsibility for the roadmap |
|---|---|
| Board & governing body | Grants the mandate and receives phase-gate reporting |
| Accountable executive | Owns delivery of the roadmap and answers for phase closure |
| AI governance lead | Runs the phases day to day and holds the exit criteria |
| Risk & assurance lead | Independently confirms that phase 6 criteria are genuinely met |
| Domain experts | Own their function’s playbook from phase 5 onward |
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 ImplementerGoverning AI across an organisation — policy, risk, regulation and the operating modelCertified Professional in AI GovernanceRelated standards. ISO/IEC 42001 clauses 4 to 10 as the implementation arc · ISO/IEC 42006 for the certification-body requirements that shape phase 6 · ISO/IEC 23894 (risk management) · ISO/IEC 38507 (governance implications for the governing body) · NIST AI RMF Playbook.
Related articles. The governance loop · The assurance rhythm · Operating context · Control domains · every phase article below
One obligation, mapped end to end across the regimes that matter — ISO/IEC 42001, the NIST AI RMF and the EU AI Act — to the GAICC credential that builds the skill and the evidence an auditor expects. Select any row.
cl. 6.1 (risk & opportunities) + Annex A risk controls
MAP · MEASURE
Article 9 — risk-management system
Certified Professional in AI Governance + ISO/IEC 42001 Lead Implementer
Annex A — data for AI systems
MAP · MEASURE
Article 10 — data and data governance
Annex A — responsible use; cl. 5 accountability
GOVERN · MANAGE
Article 14 — human oversight
Annex A — lifecycle & information for interested parties
GOVERN ·
Articles 12 & 13 — record-keeping and transparency
Board-ready policy: principles, scope, risk appetite, roles and red lines.
Track every AI system, agent and workflow — owner, risk tier, autonomy and oversight.
The nine control areas, ready to mark applicable, justify and assign.
Assess a system’s impact on people and society, with mitigations and sign-off.
Who is Responsible, Accountable, Consulted and Informed across governance.
A repeatable structure for reporting AI governance to the board.