An AI policy is useful, but a policy alone does not make an AI system trustworthy. Leaders also need to know which systems are being used, who owns their decisions and what happens when something goes wrong.
This checklist turns governance into a small set of operational questions. Start with one consequential use case rather than attempting to document every possible risk at once.
1. Inventory the AI you actually use
Include purchased software with embedded AI, staff use of general-purpose tools and systems built internally. An inventory that only covers the technology team's projects misses important exposure.
For each entry, record its purpose, users, supplier, data inputs and whether its output influences a real decision. Separate a tool that drafts internal notes from one that affects eligibility, employment or access to services.
- Name a business owner and a technical owner.
- Record where data goes and who can access it.
- Identify affected people and the decisions they may need to challenge.
2. Classify risk before approving use
Assess the consequences of an incorrect answer, not just the model's sophistication. A simple classifier used in a sensitive workflow can require more oversight than a complex tool used for brainstorming.
Consider privacy, unequal treatment, security, service continuity and the ability to explain an outcome. Document the reasoning behind the risk level and the conditions under which the assessment must be repeated.
3. Make human oversight specific
A statement that a human is 'in the loop' is not enough. Specify what that person can inspect, whether they have time to review the output and how they can override or stop the system.
Give reviewers clear escalation routes. For a high-consequence decision, identify an accountable decision-maker rather than treating a supplier's output as the final authority.
- Define which decisions cannot be automated.
- Test whether reviewers can recognise a plausible but incorrect output.
- Provide a route for affected people to seek a review.
4. Set an evidence threshold for release
Use representative examples from the intended workflow, including difficult cases and relevant languages. A supplier demonstration is not a substitute for testing how the system behaves with your data.
Agree measurable acceptance criteria before seeing the results. Record failure types, data limitations, mitigations and who accepted the remaining risk. Connect governance approval to a release gate that can genuinely block deployment.
5. Monitor, review and retire
Assign responsibility for incidents, user feedback, quality checks and supplier changes. A model upgrade or a change in the data source can invalidate an earlier assessment.
Define review triggers and an exit plan. The organisation should be able to pause the service, restore a non-AI workflow and retain the records needed to investigate a disputed outcome. Governance continues after launch; it is not a one-time permission slip.
General practical guidance, not legal advice. Adapt these steps to your organisation and seek appropriate specialist advice.