AI governance
AI governance that works inside the operating model
Turn AI principles into practical controls: permitted uses, data access, testing, human decisions, incident response and accountable ownership.
At a glance
- Record the purpose, owner and consequence of each AI use.
- Test information access and action limits.
- Prepare human review, stop conditions and incident response.
An AI policy becomes useful when a delivery team can apply it to a real decision. Which information may this system use? What may it do without approval? Who can stop it? Governance should make those answers visible in design, release and everyday operation, rather than remain a document beside the project.
The working method
- 01
Scope
Identify the use, users and information involved.
- 02
Control
Test permissions, behavior and approvals.
- 03
Maintain
Review changes and operational issues.
Part 01
Know what is being used and why
Maintain an inventory of AI uses with a business owner, purpose, affected users and information sources. Include tools bought directly by a department as well as custom applications. Distinguish a drafting aid from a system that influences an important decision or takes an action.
Record the intended benefit and the foreseeable consequence of failure. Use that context to decide the depth of review, testing and oversight. Applying the same checklist to every use can consume attention without improving the decisions that carry the most risk.
Part 02
Make permissions and action limits explicit
Define which sources can be accessed, which users can see the output and what actions the system may initiate. Use appropriate technical access controls rather than relying on instructions alone. Treat information from a document, message or external page as content to assess, not permission to change the system's behavior.
Set approval points around consequential actions. A system that prepares a recommendation can have a different boundary from one that changes a customer record, releases funds or sends an external message. Decide what happens when approval is absent, delayed or withdrawn.
| Control | Practical evidence | Owner to agree |
|---|---|---|
| Permitted use | Defined purpose, exclusions and affected users | Business owner |
| Data access | Tested permissions and information handling | Data and security owners |
| Release | Evaluation cases, findings and acceptance decision | Accountable release owner |
| Operations | Monitoring, stop conditions and escalation route | Service owner |
Swipe the table to view all columns →
Part 03
Evaluate the behavior that matters
Create cases that reflect the intended task, including ambiguous requests, missing records, conflicting sources and attempts to cross an access boundary. Review the quality of the outcome and the route to a person when the system cannot complete the work. An answer that sounds confident is not a substitute for evidence.
Record the model and configuration used for each evaluation. Reassess material changes to sources, tools, permissions or the underlying model. Keep enough evidence to explain the release decision while limiting the sensitive content retained in test records.
Part 04
Give human review an actual job
A reviewer needs relevant context, time, authority and a way to disagree. Define what they are checking: source accuracy, a proposed action, policy alignment or an exception. Avoid a design where a person is nominally responsible but cannot understand or challenge the output.
Track whether review adds value and whether work is being pushed into an unmeasured queue. If every output needs extensive reconstruction, revisit the scope or the design. Oversight should be an operational capability, not a label placed on a button.
Part 05
Prepare for incidents and changes
Set a route for reporting harmful, incorrect or unauthorized behavior. Agree who can pause the service, what evidence to preserve and how affected operations continue. Test the fallback before it is needed. Any notification obligations must be assessed for the specific incident and jurisdiction.
Use a periodic review to retire unused cases, reconsider permissions and inspect unresolved issues. A risk framework can organize the work, but using one does not establish certification or legal compliance. The useful outcome is an operating model with controls people can demonstrate.
- A current inventory with business ownership.
- Access and action boundaries that are tested.
- Recorded evaluation and release decisions.
- An incident route, stop conditions and a supported fallback.
