AI Governance Templates

18 ready-to-use AI governance templates, covering the model register, consequence-based risk tiering, the approval gate checklist, vendor assurance questions, use case scoring, readiness assessment, and maturity rubric. Each is drawn from a practitioner playbook and written to be used without modification.

All 18 working artefacts from the six AI playbooks, on one page. Every template states the decision it supports, how to apply it, and what goes wrong when it is skipped.

AI Model Register Template

An institution that cannot list its AI systems cannot govern them. The register is the base record that every other governance activity refers to: tiering, approval, review, and incident response all read from it and write back to it.

One table, one owner, updated at every gate. Fields below are the minimum that survives an audit.

FieldPurpose
System IDStable identifier used across all other systems
Business ownerNamed individual who accepts the output, not a team
Technical ownerNamed individual accountable for operation
Purpose statementOne sentence on the decision this system informs or makes
Consequence tier1 to 4, assigned by the tiering criteria below
Build or buyInternal, vendor, or vendor component embedded in a wider product
Model and versionIncluding vendor model identifiers where applicable
Data sourcesSystems of origin, plus lawful basis where personal data applies
Human roleDecides, reviews, or is informed
Stopping conditionObservable trigger for withdrawal
Authorised to stopNamed individual and their delegate
Approval date and approver
Next review dateMandatory field, no null values permitted
Incidents to dateCount and link to records

How to use it

  • Create one table with one owner. Distributed registers held per department stop reconciling within a quarter.
  • Populate business owner and technical owner with named individuals, never a team or a role. Accountability that is not attached to a person is not accountability.
  • Update the register at every gate rather than on a review cycle, so the record and reality do not diverge between reviews.
  • Treat next review date as mandatory with no null values permitted. A null there is how systems quietly leave supervision.

From AI Governance: A Practical Playbook

AI Risk Tiering Criteria

Tiering schemes built around technology age badly, because every wave of capability needs a new rulebook, and they reach the wrong conclusion: a rules engine that denies a claim deserves more scrutiny than a language model that drafts meeting notes.

TierTestRequirement
4. CriticalAffects rights, safety, eligibility, or livelihood. Effect hard to reverse.Full review, named accountable owner at director level, pre-agreed stopping condition, quarterly review
3. SignificantAffects individuals materially but with appeal and correction routes.Full review, semi-annual review cycle
2. OperationalAffects internal process efficiency. Errors visible and correctable in workflow.Light review, annual cycle, self-attestation against checklist
1. AssistiveDrafting, summarising, search. Human reviews every output before use.Registration only, no gate

How to use it

  • Assign the tier from the consequence of a wrong output, not from whether the system uses machine learning, generative models, or ordinary rules.
  • Apply the four tests in order: who is affected, whether rights or eligibility are touched, whether an appeal route exists, and whether the effect can be reversed.
  • Record the tier in the model register, and let it drive review frequency and control requirements rather than sitting as a label.
  • Re-tier when the use changes. A system promoted from drafting to deciding has changed tier even if the model has not changed at all.

From AI Governance: A Practical Playbook

AI Approval Gate Checklist

The gate is where governance either constrains behaviour or reveals itself as decoration. Its function is to refuse systems that cannot answer for themselves, which requires that someone present has the authority to say no.

Before a tier 3 or tier 4 system goes live, the submission shows all of the following:

  • Purpose statement and the specific decision affected
  • Named business owner who accepts the output in writing
  • Evidence of performance on data representative of live conditions, including performance on the smallest affected subgroup you can measure
  • Failure mode analysis covering what a wrong output does downstream
  • Human role defined and the reviewer given authority to override without escalation
  • Stopping condition, named stopper, and maximum time to withdrawal
  • Data lawful basis and retention position
  • Rollback plan to the prior process, tested
  • Next review date

How to use it

  • Run the gate before production, not after an incident. A gate applied retrospectively is a report.
  • Require a written stopping condition on every approval: the observable trigger, the named individual authorised to act on it, and the maximum time from detection to removal.
  • Give the independent reviewer, usually data protection or risk, genuine authority to refuse. Without it the gate records decisions rather than making them.
  • Write the approval and the next review date into the model register at the moment of the decision.

From AI Governance: A Practical Playbook

AI Vendor Assurance Question Set

Where a system is bought rather than built, assurance replaces inspection. The contract and the questions asked before signing are the only governance instruments that still work once the system is in place.

Send this before contract, not after. Score each answer as answered, partial, or refused.

Supply chain

  1. List all sub-processors, including underlying model providers and inference hosts.
  2. Where is inference physically performed, by jurisdiction?
  3. Which sub-processors can access customer content, and under what controls?

Data handling

  1. Is customer content used for training, fine tuning, or evaluation? State the default and how to opt out.
  2. What is the retention period for prompts, completions, and logs?
  3. Is content isolated per tenant at rest and in transit? Describe the mechanism.
  4. Which of your staff can read customer content, under what approval, and is that access logged and reviewable by us?

Change management

  1. What is your notice period for a change to the underlying model?
  2. What is your deprecation policy and minimum support window for a pinned version?
  3. Do we have the contractual right to re-test after a model change?

Security controls

  1. Provide the results of your most recent independent security assessment and the remediation status of open findings.
  2. Describe your controls against prompt injection, and state which residual risks you consider open.
  3. What permissions does the product require in our environment, and what is the minimum viable set?

Incident and exit

  1. What is your incident notification commitment, in hours, and what triggers it?
  2. On termination, how is our content deleted, on what timeline, and how is deletion evidenced?

How to use it

  • Send the set before contract. After signature the leverage to obtain answers is gone.
  • Score each answer as answered, partial, or refused, and treat a pattern of refusals as a finding in itself rather than a gap to chase.
  • Insist on evaluation results against your own data and languages, not the vendor’s published benchmark.
  • Carry the answers into the model register entry so the assurance position is visible at every later review.

From AI Security and Assurance: A Practical Playbook

AI Control Checklist

Applying every control to every system guarantees that the controls are ignored on the systems that matter. Proportionality is what makes a control set survive contact with delivery pressure.

Apply proportionally to consequence tier.

ControlTier 1Tier 2Tier 3Tier 4
Registered in model registerYesYesYesYes
Data classification of inputs recordedYesYesYesYes
Data path diagramNoYesYesYes
No standing credentials held by modelYesYesYesYes
Authorisation enforced outside the modelYesYesYesYes
Untrusted content marked and de-privilegedYesYesYesYes
Consumption limits and spend alertsYesYesYesYes
Prompt and completion logging with access controlNoYesYesYes
Confirmation required for irreversible actionsNoYesYesYes
Structured red team exercise before go liveNoNoYesYes
Independent review of output quality on live-like dataNoNoYesYes
Tested rollback to prior processNoNoYesYes
Named stopper with withdrawal authorityNoNoYesYes
Re-test triggered by vendor model changeNoNoYesYes

How to use it

  • Read the tier from the model register rather than assigning it separately, so one classification drives everything.
  • Apply the controls marked for that tier as mandatory, and record the exceptions rather than allowing silent omission.
  • Escalate the control set when a system is promoted to a higher tier, which happens whenever its use widens.

From AI Security and Assurance: A Practical Playbook

AI Incident Triage Sheet

Incident response for AI systems fails when teams begin by diagnosing. An agent with live credentials continues acting while the investigation proceeds, and every minute of analysis is a minute of continued exposure.

When something goes wrong, answer these in order.

  1. Is data leaving the boundary right now? If yes, cut the egress before anything else.
  2. Can the system take actions? If yes, revoke its credentials before investigating.
  3. What is the fallback process, and is it running?
  4. How many outputs are affected, and can you enumerate the recipients?
  5. Is the cause input, model, integration, or permission? Investigate in that order, because that is the order of frequency.
  6. Does this trigger a notification obligation? Start the clock from detection, not from confirmation.

How to use it

  • Work the questions in the order given. The order is the artefact; the individual questions are obvious in isolation.
  • Cut egress before anything else if data is leaving the boundary, including before establishing what data it is.
  • Revoke credentials from any system that can take actions before investigating, because an agent keeps acting during triage.
  • Only then establish scope, cause, and notification obligations.

Where this goes wrong

  • Triage starts only once someone recognises an event as an AI incident. Most of these arrive as a service complaint, a wrong decision, or a data query. The intake route has to be the ordinary one, with AI identified during triage rather than before it.
  • Severity is scored on system behaviour instead of consequence to a person. A model degrading quietly while it decides eligibility is more serious than one failing loudly in a reporting dashboard, and severity scales that only measure technical impact invert that.
  • Nobody holds the authority to stop the system. A triage process that can escalate but cannot halt produces well-documented harm. The stopping authority must be named in advance and reachable outside working hours.
  • Incidents are closed without changing anything upstream. Triage that ends at restoration and never reaches the register, the risk tier, or the approval gate guarantees the same incident returns.

From AI Security and Assurance: A Practical Playbook

Sovereignty Control Ladder

Sovereignty decisions are usually made implicitly, one procurement at a time, and only become visible when a dependency fails. The ladder makes the choices explicit and priced.

Complete one row per layer. The right hand column is the one that gets skipped and matters most.

LayerControl postureRationaleAnnual costExit or alternative if dependency fails
Data residencyHold, share, or accept
Legal jurisdiction of operator
Operating personnel
Network path
Compute location
Model weights
Right to modify

Posture definitions. Hold means the state controls it directly. Share means joint control under binding agreement, including regional arrangements. Accept means external dependency with a documented exit.

How to use it

  • Complete one row per layer rather than making a single overall sovereignty judgement.
  • Price each posture annually. A posture without a cost is a preference, not a decision.
  • Complete the exit column for every row. It is routinely skipped and it is where the actual risk sits.
  • Review when a dependency changes ownership, jurisdiction, or pricing model.

Where this goes wrong

  • The ladder is treated as a ranking, so every system is pushed toward the top rung. Sovereignty is a cost, not a virtue. A system holding no personal data and no policy leverage does not need the controls that a population register needs, and spending them there means underspending somewhere that matters.
  • The rung is claimed on the location of the data centre alone. Physical hosting inside a jurisdiction means little if the operator, the key material, the model weights, or the support contract sit outside it. Each of those is a separate question and each needs its own answer.
  • Nobody names the specific dependency being removed. A rung that cannot be stated as "we no longer depend on X for Y" is a label rather than a control, and it will not survive the first procurement challenge.
  • The assessment is done once at approval and never repeated. Vendors reorganise, subprocessors change, and models get retired. A ladder position recorded eighteen months ago describes an arrangement that may no longer exist.

From Sovereign AI Strategy: A Practical Playbook

National AI Strategy Test

National AI strategies commonly announce capability without committing to the operating cost of keeping it, and without stating which dependencies are being accepted deliberately.

Run any draft strategy against these ten questions. A draft that fails more than three is not ready for cabinet.

  1. Does it state which sovereignty layers are held, shared, and accepted?
  2. Does it carry a five-year operating cost, not only a capital figure?
  3. Does it name an accountable institution for each commitment, with an individual title?
  4. Does it identify the data estate work that precedes the AI work?
  5. Does it commit to procurement clause reform with a date?
  6. Does it state what the state will not do?
  7. Does it include an exit or alternative for each accepted external dependency?
  8. Does it define measurable outcomes reportable quarterly?
  9. Does it address who is accountable when a public sector system harms a citizen?
  10. Does it survive a change of minister, meaning are the commitments institutional rather than personal?

How to use it

  • Run the test on the draft before it reaches cabinet, not after publication.
  • Count failures rather than debating each one. More than three is a signal about the document as a whole.
  • Pay particular attention to the operating cost question: capital is funded easily and year four is not.

Where this goes wrong

  • The strategy is judged on its document rather than on its commitments. Length, breadth, and the number of pillars say nothing. What matters is whether a named institution owns a dated deliverable with money behind it.
  • Funding is described without a source. A figure attached to no budget line, no appropriation, and no fiscal year is an aspiration. Ask which existing allocation it comes out of.
  • The strategy assumes capability that does not exist yet and does not fund building it. Plans that depend on scarce specialist staff, with no training pipeline and no pay scale that can attract them, stall at implementation regardless of how sound the analysis is.
  • There is no stated way to know the strategy has failed. A strategy with no falsifiable milestone cannot be corrected, only replaced, and replacement usually waits for a change of administration.

From Sovereign AI Strategy: A Practical Playbook

Five-Year AI Cost Model Structure

The most common failure in sovereign AI programmes is a capital budget with no operating budget behind it. Announcements are funded easily; year four is not.

Build the model with these lines. Understating any of them is the standard failure.

Capital. Facility, power distribution, cooling, compute hardware, network hardware, initial software licensing.

Operating, annual. Power at realistic utilisation. Cooling. Hardware refresh provision at 20 to 33 percent of compute capital per year. Software and support licensing. Connectivity. Facility operations.

People, annual. Platform engineering, security operations, data engineering, model operations, governance function. Cost these at retention-competitive rates, not at standard public scale, then state the gap explicitly rather than hiding it.

Programme, annual. Evaluation and benchmarking, corpus and dataset development, training and capability building, external assurance.

Contingency. Not less than 15 percent. Power costs and hardware availability have both moved sharply and will again.

How to use it

  • Build every line, including the ones that make the total uncomfortable. An omitted line does not reduce the cost, it defers the discovery.
  • Cost staffing at market rates rather than public-sector scales, or the model assumes people who will not be hired.
  • Include the capability you will still buy externally. Sovereign infrastructure rarely removes all external spend.
  • If the honest total is unaffordable, hold fewer layers well rather than every layer badly.

Where this goes wrong

  • The model counts build and ignores the run. Inference, storage, monitoring, retraining, and the staff who operate the thing usually exceed the build cost within two years, and they arrive in a different budget line than the one that approved the project.
  • Human review is left out. Systems that need a person checking borderline cases carry a permanent staffing cost proportional to volume. Omitting it produces a business case that only works if the oversight is quietly dropped.
  • Vendor pricing is treated as fixed for five years. Per-token, per-seat, and per-call pricing all move, and the switching cost is rarely modelled. Include what leaving would cost as a line of its own.
  • Decommissioning is absent. Every system ends. A five-year model with no exit cost understates the commitment and makes the cheap-to-start option look better than it is.

From Sovereign AI Strategy: A Practical Playbook

AI Centre of Excellence Operating Mode Selector

Most centres of excellence fail by choosing a mode that does not match the organisation around them: delivering where units can already build, or enabling where nobody can.

Answer these and the mode usually chooses itself.

QuestionIf yes, points toward
Do business units already have technical delivery capacity?Enable
Is the immediate demand two or three high consequence systems?Build
Is the organisation already deploying AI without oversight?Govern
Is the sponsor's stated goal a named flagship deliverable?Build, with a sunset date
Is the sponsor's stated goal organisational capability?Enable
Is there an existing risk or assurance function?Enable, and partner rather than duplicating Govern
Is the budget under five full time equivalents?Choose one mode only

How to use it

  • Answer the questions honestly about current capacity, not the capacity you intend to build.
  • Let the answers point to a primary mode and a secondary mode, and state both in the charter.
  • Revisit the mode when delivery capacity in the business units changes materially, because the correct mode moves with it.

Where this goes wrong

  • The mode is chosen from ambition rather than from staffing. A centralised centre of excellence with two people delivers a queue, not a service. Pick the mode the current headcount can actually run, then change it when the headcount changes.
  • Nobody decides what the centre is allowed to refuse. A centre that cannot say no becomes a general technology helpdesk within a quarter, and the governance work it was created for stops happening.
  • The federated mode is selected without any shared standard underneath it. Federation without a common register, a common risk tier, and a common approval gate produces divergence with a coordinating committee attached.
  • The mode is never revisited after the pilot phase ends. The arrangement that suits five exploratory projects rarely suits fifty production systems, and the transition is a decision rather than something that happens on its own.

From AI Centre of Excellence: A Practical Playbook

AI Centre of Excellence Charter Template

A charter earns its place by settling arguments before they happen: what the centre decides, what it advises on, and what it declines. A charter that lists activities settles nothing.

Keep it to two pages. Longer charters are not read and therefore not binding.

1. Purpose. One paragraph. The organisational outcome, not the function's activities.

2. Operating mode. Primary and secondary. State the mode you are explicitly not adopting and who holds that responsibility instead.

3. Scope. In scope by domain and system type. Out of scope, stated plainly.

4. Decision rights. What the CoE may decide alone. What it recommends. What it may block, and the appeal route.

5. Services and response times. Each service, its intake route, and its published turnaround.

6. Funding. Central, chargeback, or hybrid. Rate card if applicable.

7. Staffing. Roles, seniority, and embedded placement policy including maximum duration.

8. Measures. Three to five outcome measures with named business owners. Reporting cadence and audience.

9. Governance. Who the CoE reports to, meeting cadence, and escalation path.

10. Sunset conditions. The observable conditions under which the function dissolves, and the review date at which those conditions are assessed.

How to use it

  • Hold it to two pages. Length is not thoroughness; an unread charter binds nobody.
  • State the organisational outcome in the purpose, not the function’s activities.
  • Name the decision rights the centre holds and, just as explicitly, what it will not do.
  • Have it signed by the executive who will be asked to enforce it, not only by the function that wrote it.

From AI Centre of Excellence: A Practical Playbook

AI Use Case Intake Form

The intake form does most of the filtering that a governance committee would otherwise do slowly. A request that cannot name the decision it changes or the person who owns it is not a use case yet.

Ten fields. If a requester cannot complete these, the request is not ready and the conversation should start there.

  1. What decision or process does this change?
  2. Who owns that decision today, by name?
  3. What does the current process cost, in time, money, or error rate?
  4. What does good look like, expressed as a number?
  5. What data exists, who owns it, and have you seen it?
  6. Who accepts the output and acts on it?
  7. What happens when the system is wrong?
  8. Is the effect reversible?
  9. Who has funded implementation, as distinct from the pilot?
  10. What is the deadline and what drives it?

How to use it

  • Require all ten fields before the request enters any queue.
  • Treat an incomplete form as the start of a conversation rather than a rejection: the missing fields are usually the real problem.
  • Insist on a named decision owner. "The department" is not an answer.
  • Capture current process performance, because without a baseline no later claim of improvement can be tested.

Where this goes wrong

  • The form collects the proposed solution instead of the problem. An intake that opens with "we want a chatbot" has already foreclosed the analysis. Capture the decision being made, who makes it today, and what it costs to get it wrong.
  • There is no field for the option of not building anything. Intake processes that only accept proposals generate proposals, and a register full of approved low-value systems is harder to unwind than an empty one.
  • Data availability is asserted rather than checked. A use case that depends on a dataset nobody has confirmed exists, in a form nobody has confirmed is usable, will fail late and expensively.
  • Submissions are scored by the team that submitted them. Self-scored intake converges on everything being high value and low risk. Scoring belongs with someone who carries no delivery incentive.

From AI Centre of Excellence: A Practical Playbook

AI Use Case Scoring Sheet

Most use case prioritisation fails by averaging. A case with compelling value and no usable data scores respectably on a mean and then consumes a year proving it cannot be built.

Score each axis 1 to 5. Multiply rather than add, so a zero on any axis removes the case rather than being averaged away.

Value

  1. Marginal convenience, no measurable effect
  2. Efficiency gain in a minor process
  3. Measurable improvement in a process that matters
  4. Material improvement in a priority outcome
  5. Removes a constraint on the organisation's mandate

Data readiness

  1. Data does not exist or is not accessible
  2. Data exists in fragmented form, quality unverified
  3. Data accessible, quality acceptable, labels partially available
  4. Data accessible, quality verified by sample, sufficient history
  5. Data already in production use for a comparable purpose

Decision ownership

  1. No identified owner
  2. Owner identified, not consulted
  3. Owner engaged, has not committed to act on the output
  4. Owner committed, has capacity to review outputs
  5. Owner committed and has funded implementation beyond the pilot

Reversibility

  1. Irreversible effect on individuals with no appeal route
  2. Irreversible operationally, correctable at high cost
  3. Correctable within the process at moderate cost
  4. Human reviews before effect, correction routine
  5. Fully reversible, output advisory only

Interpretation. Scores above 200 are strong candidates. Between 100 and 200, address the weakest axis before proceeding. Below 100, decline and record the reason. Any axis at 1 removes the case regardless of the total.

How to use it

  • Score each axis independently from one to five using the descriptors, before comparing cases against each other.
  • Multiply the four scores rather than adding them. The multiplication is the mechanism: it lets a single fatal axis remove a case.
  • Score the specific use case rather than the general ambition. "AI for HR" cannot be scored; "screening applications against mandatory criteria" can.
  • Where data readiness is the weak axis, treat the data work as the project rather than treating the model as the project.

From AI Use Case Discovery, Readiness and Maturity: A Practical Playbook

AI Readiness Assessment

Readiness is a property of a use case in an organisation, not of the organisation alone. An institution can be ready for one system and entirely unready for another running on different data.

Six dimensions, assessed as red, amber, or green with evidence. Assess the specific use case, not the organisation in general.

DimensionGreen requires
DataSample inspected, quality verified, access granted, lawful basis confirmed
ProcessCurrent process documented as performed, baseline measured
PeopleBusiness owner committed, reviewers identified and available
PlatformDeployment path exists, monitoring available, rollback tested
GovernanceConsequence tier assigned, gate requirements known, stopping condition drafted
FundingImplementation and first operating year funded, not only the pilot

Any red on Data or People means the use case is not ready to start. Red on Platform or Governance means it can start with a defined remediation plan and a hold at the go live gate.

How to use it

  • Assess the specific use case. An organisation-level readiness score cannot tell you whether this system can be built.
  • Require evidence for every green. A green without an inspected data sample is an opinion.
  • Treat amber as work to be scheduled rather than a soft pass, and red as a precondition that has to be met before delivery starts.
  • Re-run the assessment when the use case changes scope, because readiness does not transfer between problems.

From AI Use Case Discovery, Readiness and Maturity: A Practical Playbook

AI Maturity Rubric

A maturity score on its own changes nothing. The rubric is useful when it is read as a gap against specific planned work, which converts an assessment into a sequenced investment case.

Five dimensions, five levels. Assess where you are, then mark where your next three use cases require you to be. The gap is the work plan.

LevelDataDeliveryGovernanceOperationsPeople
1. InitialFragmented, no catalogueIndividual experimentsNoneNoneIsolated enthusiasts
2. EmergingCatalogue exists, quality unevenPilots delivered, few in productionPrinciples publishedManual monitoringSmall central team
3. DefinedGoverned sources, documented lineageRepeatable path to productionTiering and gates operatingMonitoring and alerting standardRoles defined, training in place
4. ManagedQuality measured, issues remediated on cycleDelivery predictable, platform sharedRegister complete, reviews on scheduleIncident process tested, retraining routineCapability distributed to business units
5. OptimisingData products with owners and service levelsPortfolio managed against outcomesGovernance informs strategyAutomated detection and responseInternal faculty, capability self-sustaining

Do not target level 5 across all dimensions. Most organisations need level 4 on Data and Operations and level 3 elsewhere. Targeting uniformly high maturity spends budget on capability that no current use case requires.

How to use it

  • Mark the current level honestly on each of the five dimensions.
  • Mark the level your next three use cases actually require. Not an aspirational target level.
  • Treat the difference as the work plan, and fund the dimensions that block the planned work rather than the lowest-scoring dimension overall.
  • Re-assess annually or when the delivery portfolio changes materially, not quarterly. Maturity moves slowly and frequent scoring invites gaming.

From AI Use Case Discovery, Readiness and Maturity: A Practical Playbook

AI Curriculum Map for Three Audiences

A single AI training programme delivered to an entire organisation satisfies nobody: it is too shallow for the people building systems and too technical for the people approving them.

Audience 1: those who decide. Executives, directors, budget holders, governance body members.

  • Format: three sessions of two hours, spaced two weeks apart, cohort of twelve to twenty
  • Content: what these systems do and do not do reliably. How to read a business case. Consequence tiering and where accountability sits. Vendor questions worth asking. Cost of the operating year.
  • Method: live proposals from their own portfolio, assessed in the room
  • Artefact: each participant reviews one real proposal and produces a written decision with rationale
  • Assessment: quality of the interrogation, not the conclusion

Audience 2: those who build. Data, engineering, analytics, and delivery staff.

  • Format: extended cohort over eight to twelve weeks with project work
  • Content: evaluation design, failure mode analysis, retrieval and grounding patterns, agent permission design, monitoring and drift, deployment path, secure integration
  • Method: build against the organisation's own platform and standards
  • Artefact: a working system passing the internal gate, or a documented decision not to proceed
  • Assessment: peer and faculty review against the gate checklist

Audience 3: those who use. Everyone whose work the tools touch.

  • Format: ninety minutes, role specific, plus an open office hour weekly
  • Content: what the approved tools are, what may and may not be entered, how to verify an output, when not to delegate the task, how to report a problem
  • Method: participants work on their own live tasks during the session
  • Artefact: one task in their own workflow, completed and verified
  • Assessment: self-reported at ninety days with an example

How to use it

  • Split by decision role rather than by seniority or department.
  • For executives, use short spaced sessions with a small cohort rather than a single long briefing.
  • Teach practitioners on the organisation’s own material and failure cases, not on generic examples.
  • Give the wider workforce concrete rules about approved tools and prohibited inputs, which is what they actually need.

From AI Leadership and Workforce Capability: A Practical Playbook

AI Executive Session Design

Executive AI briefings usually fail by demonstrating success only, which leaves decision-makers unable to judge where a system will break and inclined either to over-trust or to prohibit.

The three-session format that works, in detail.

Session one. What these systems do. Sixty minutes of demonstration on the organisation's own material, including two deliberate failures shown live. Forty minutes of discussion on where in their own portfolio the same failure would matter. Twenty minutes to identify one candidate use case each.

Session two. How to read a proposal. Participants bring their candidate. The group applies the four-axis scoring model and the readiness assessment. At least a third of the candidates should fail, and the session is working when participants reach that conclusion themselves.

Session three. What you are accountable for. Consequence tiering applied to their own systems. Stopping conditions drafted. Vendor question set applied to a real contract in the organisation. Each participant leaves with a written decision on their candidate and a named next action.

How to use it

  • Demonstrate on the organisation’s own material. Generic demonstrations do not transfer to the decisions this audience makes.
  • Show two deliberate failures live. It is the most useful sixty seconds in the session.
  • Space the sessions rather than compressing them into one day, so that questions can form between them.
  • Keep the cohort small enough that senior people will admit what they do not know.

From AI Leadership and Workforce Capability: A Practical Playbook

AI Capability Evidence Framework

Training that is not recorded as an expectation decays within a year and has to be repurchased. Evidence attached to roles survives staff turnover in a way that attendance records do not.

For each affected role, complete this row. This is the document that turns a programme into a durable expectation.

RoleCapability requiredEvidence of capabilityWhere it is recordedReassessed
Example: service managerCan assess whether a proposed system should be adopted in their serviceCompleted use case assessment reviewed by the CoEAnnual objectivesYearly
Example: data engineerCan design and run an evaluation against live-like dataSystem passing internal gateRole profile and objectivesYearly

How to use it

  • Complete one row per affected role rather than per course.
  • Define evidence as something observable, not attendance.
  • Record it in the system that already governs the role, so it survives the programme that created it.
  • Set a reassessment interval, because capability claims age as tools change.

Where this goes wrong

  • Evidence is collected after the claim is made. Assembling proof to support a decision already taken produces selection, not evidence. Fix the measure before the system is built and record what would count as failure.
  • A demonstration is accepted as evidence of capability. Demonstrations run on chosen inputs in favourable conditions. Capability is what the system does on the distribution it will actually meet, including the cases nobody prepared for.
  • Accuracy is reported without a baseline. A model at eighty-five per cent means nothing until you know what the existing process achieves and what chance would achieve. Many published gains disappear against that comparison.
  • The evidence is never tied to a decision. A framework that produces a report rather than a go, no-go, or conditional-approval outcome adds process without adding control.

From AI Leadership and Workforce Capability: A Practical Playbook

Each template belongs to a longer playbook that sets out the reasoning, the rules of thumb, and the failure signals around it.