AI Governance Toolkit

This is a set of ready-to-adapt artefacts for the governance work Domain 3 tests: an operating model, a RACI, a use-case intake form, a risk register, a risk-tier to control matrix, a tool-classification policy, launch and incident checklists, and a vendor due-diligence set. It is independent preparation, not an official AWS compliance framework — adapt every artefact to your own regulatory obligations before you rely on it. The AIB-C01 beta exam does not ask you to configure any of this; it asks you to recognise which structure, control or accountability fits a scenario. Everything here stays at that decision level.

The toolkit at a glance

   Use case ──▶ INTAKE FORM ──▶ RISK CLASSIFICATION ──▶ CONTROL SET
                    │                    │                   │
                    │                    ▼                   ▼
                    │              RISK REGISTER        HUMAN OVERSIGHT
                    │              (owned rows)         + MONITORING
                    ▼                                        │
              OPERATING MODEL (who decides) ◀── RACI ────────┤
                    │                                        ▼
                    ▼                                 LAUNCH READINESS
              TOOL CLASSIFICATION                          │
              (approved/blocked/eval)                      ▼
                                                    INCIDENT RESPONSE

Each artefact answers a different governance question. Read down the diagram: intake captures the request, classification sets the tier, the tier drives the control set, the operating model and RACI say who decides, and launch and incident procedures close the loop.

1. AI governance operating model

Governance fails in two opposite ways: a single committee that becomes a bottleneck, or no forum at all so decisions happen by accident. The operating model names a small number of bodies, gives each clear decision rights, and sets a cadence. It maps directly to task 3.2.1 (cross-functional representation and clear accountability).

The design rule is delegated authority by tier: low-risk use cases clear at the working-group level so governance does not throttle volume, while high-risk use cases rise to the council. A body that cannot say no is not a governance body; each row’s “may not decide” column is deliberate.

2. RACI across the AI lifecycle

A RACI stops the two classic accountability failures: everyone assumes someone else owns a control, or one person is accountable for everything and therefore for nothing. Responsible does the work, Accountable owns the outcome (exactly one per row), Consulted gives input before, Informed hears after.

The exam signal: when a stem says “no one was clearly responsible for X after launch”, the fix is a named A in the monitoring or incident row — not a new tool. Note that data approval is accountable to the data owner, not the business owner who wants to use it; that separation is what prevents a team from waving its own data through.

3. Use-case intake form

Intake is the cheapest place to say no. A structured form forces a proposal to state its outcome, its data and its risk before anyone spends money, and it feeds prioritisation (task 2.1.3) and classification (task 3.2.4).

• Sponsor and business owner — named individual, not a team.
• Problem and current baseline — what the process costs or takes today, measured (link to the KPI Library baseline methods).
• Proposed outcome and target — the specific metric that should move, and by how much.
• Why AI, not rules — the deterministic-vs-AI test (task 1.2.1); if the logic is fixed, this is a rule engine.
• Data required — sources, sensitivity, ownership, whether it may leave the org, quality state.
• Consequence of a wrong output — reversible or not, who is affected, regulated or not.
• Human-in-the-loop point — where a person reviews before an action is taken.
• Build / buy / partner leaning — with a rough cost and timeline.
• Success and kill criteria — the numbers that would make you scale, pause or terminate.

A proposal that cannot fill “consequence of a wrong output” and “kill criteria” is not ready for a budget decision. That is the intake gate doing its job.

4. Risk register template with worked rows

The register is the living record the exam expects to exist before production, not after an incident. Each row names an owner, a likelihood and impact, the current control and a residual rating. These worked rows span the risk categories the guide lists (accuracy, privacy, security, IP, regulatory, reputational, workforce).

The teaching point is that likelihood-times-impact drives the tier, the tier drives the control, and the residual rating is what the governance council actually signs off — not the raw risk. A row with no named owner is not a managed risk.

5. Risk-tier to control-set matrix

This is the artefact that turns “apply a risk classification framework” (task 3.2.4) into something a reader can use tomorrow. Classify the use case by consequence and reach, then read the control set across the row. It mirrors the tiered logic of the EU AI Act and the NIST AI RMF without citing article numbers, which is exactly the level the exam tests.

The oversight column carries the exam’s core distinction: human-in-the-loop means a person approves before the action, human-on-the-loop means a person monitors and can intervene, and human-in-command means a person can override and shut down. Higher consequence pushes you up that ladder.

6. AI tool classification policy — the answer to shadow AI

Task 1.2.4 is explicit: a transparent classification of tools as approved / blocked / under evaluation is the concrete answer to shadow AI. Banning everything drives usage underground; approving everything abandons control. The policy names states and the criteria that move a tool between them.

        request ──▶ UNDER EVALUATION ──▶ APPROVED (scoped)
                          │                   │
                     hard criterion      term change /
                        fails              incident
                          ▼                   ▼
                        BLOCKED  ◀────────────┘
                          │
                     re-request ──▶ UNDER EVALUATION

The exam signal for shadow AI is always visibility plus a sanctioned path, never a blanket ban.

7. Launch readiness checklist

Before a use case goes live, the sponsor confirms each item. This operationalises “envision → launch” from AWS CAF and the transition to production-grade from task 4.4.5.

• Risk tier assigned and control set applied.
• Baseline metric captured before go-live (you cannot claim value later without it).
• Human-oversight point defined and staffed for the chosen tier.
• Guardrails / content filters configured and tested against known-bad inputs.
• Monitoring and drift-detection in place with named owner and alert thresholds.
• Kill switch and rollback path tested; a holding message ready.
• Incident runbook written and the response owner (RACI A) briefed.
• Data terms, residency and retention confirmed; vendor indemnity on file.
• Success and kill criteria agreed by the steering committee.
• Workforce communication sent; affected staff know what changes.

8. Incident response outline for AI failures

AI incidents differ from classic IT outages: the system stays “up” while producing harmful, biased or wrong output. The outline names phases and owners.

9. Vendor due-diligence question set

Build-buy-partner (task 2.1.2) usually lands on buy or partner, which makes vendor scrutiny a governance control, not a procurement formality. Ask every vendor:

The discriminator on a vendor-selection item is rarely price; it is usually a data-use, indemnity or residency answer that a cheaper vendor cannot give.

10. How AWS’s own controls map onto these artefacts

The exam does not require you to configure any AWS control, but it expects you to recognise which AWS capability supports which governance artefact. Keep this at the mapping level.

The single most-tested idea in this table: no managed service removes the customer’s accountability for what the system is used for and whether its output is fit for purpose. Guardrails and Clarify are tools that support your controls; they are not a substitute for the operating model, the tiering and the human oversight that you own.

Key takeaways

• Governance is a set of bodies with decision rights and a cadence, not one committee; delegate low tiers so volume is not throttled.
• Every managed risk and every lifecycle activity has exactly one accountable owner — the fix for “no one owned it” is a name, not a tool.
• Classify first: tier drives approvals, oversight mode, monitoring cadence, documentation and escalation.
• Shadow AI is answered by a transparent approved / blocked / under-evaluation policy with a sanctioned path and a substitute for anything blocked.
• Capture the baseline before launch and write the incident runbook before you need it.
• Vendor due diligence — data use, training, retention, residency, indemnity, evidence, roadmap — is a governance control, not paperwork.
• AWS Guardrails, Clarify, Model Monitor and AI Service Cards support these artefacts; shared responsibility keeps use-case and fitness accountability with you.