A practical AI governance kit connects a policy with the records and decisions needed to apply it. Start with an AI-use register, a risk and control record, an approval decision, an incident route, and a recurring review. A policy that no one can operationalize is not enough.
This public guide supplies the fields and a worked example. Adapt the process to the organization’s operating context and obtain the specialist review required for consequential or regulated uses. The templates do not establish compliance on their own.
1. AI-use register
| Field | Purpose |
|---|---|
| Use-case identifier and name | Make the system easy to find and track |
| Business owner and technical owner | Assign decisions and operating responsibility |
| Intended use and exclusions | Prevent unreviewed changes in purpose |
| Users and affected people | Identify whose work or outcomes can change |
| Data inputs and sources | Clarify information boundaries and permissions |
| Provider, model, and configuration | Record the evaluated operating version |
| Human review and escalation | Explain how outputs are checked or challenged |
| Approval status and conditions | Distinguish experiments from permitted production use |
| Review date and incident contact | Make ongoing ownership actionable |
Keep the register linked to the real workflow. If a team changes the input data, users, model, or decision role, review whether the approval still describes what the system does.
2. Risk and control record
For each material failure, record the scenario, affected people or business outcome, likely consequence, proposed control, control owner, test evidence, and remaining exposure. Distinguish a control that is planned from one that has been demonstrated.
The NIST AI RMF Core organizes risk-management work through Govern, Map, Measure, and Manage. Those functions can help structure a review; they are not a certificate or a substitute for task-specific evidence.
Examples of risk scenarios include incorrect answers presented without sources, unauthorized access to restricted documents, biased recommendations, unreviewed changes to customer-facing outputs, and missing operational ownership. Choose the relevant scenarios rather than copying a long list without evaluating it.
3. Approval decision record
Record the reviewed version, the evidence considered, unresolved issues, the decision-maker, permitted scope, required controls, conditions for suspension, and next review. Approval should identify the task it covers. It should not become a blanket authorization for any future feature using the same vendor.
An approval can be conditional: a bounded pilot with no customer-facing actions, for example, can have different conditions from a production system. Conditions must be observable and assigned to owners.
4. Incident and pause procedure
Define how a user reports a problem, who triages it, who can pause the system, what manual process replaces it, and how affected information or actions are corrected. Include provider failures, wrong outputs, inappropriate disclosures, and control failures relevant to the use case.
Test the route with an exercise. A named incident owner without access to disable the workflow is not a working pause mechanism. Record lessons and update the approved operating process.
Worked example: an internal policy assistant
Consider a fictional assistant that answers staff questions from an approved policy collection. Its permitted use is information retrieval; it cannot approve expenses, interpret legal duties, or decide staff eligibility.
The register names the policy owner, technical owner, curated document set, retrieval-permission boundary, and escalation route. The risk record includes outdated policy answers and restricted-document disclosure. The team tests changed policies, unanswerable questions, and user roles with different access rights.
The approval allows a limited pilot only after source references and permissions are verified. When a policy is revised, the owner updates the collection and reruns relevant tests. An answer without a reliable source is sent to the policy owner, not presented as authorization.
Recurring governance review
At each review, reconcile the register with the systems actually in use. Examine changed use cases, incidents, exception patterns, vendor changes, training needs, control failures, and evidence that human review is working.
Ask whether the original business outcome is still being measured and whether the operating owners remain available. A technically functioning system can become ungoverned when the team responsible for it changes.
Use the executive governance review checklist to prepare the review. Use the enterprise policy guide for policy drafting and the security checklist for technical controls.
Public templates and advanced support
Download the governance worksheet for the register, risk record, approval decision, and incident exercise. This public material is available to read and adapt. A facilitated governance review or organization-specific operating model can be scoped with Artebello through a consultation.
Frequently asked questions
Is an AI governance kit the same as an AI governance checklist?
A checklist helps identify what needs review. The kit provides records through which the team can assign ownership, preserve evidence, and document decisions. They work together.
How do we keep it proportionate?
Start with the actual uses and their consequences. A low-risk drafting aid and an automated consequential decision should not receive identical review merely because both use AI.
What should a board receive?
A concise account of approved uses, material risks, incidents, control performance, ownership, and decisions needed. The board-pack quality guide helps structure AI-assisted checks on that information.