What is AI governance?
The named answers to who approved this system, who is accountable when it is wrong, what it is allowed to touch, and how anyone would notice it degrading. Not a document. Four answers with names against them.
Most governance work that gets bought is a policy document, and most policy documents do not survive the first real incident, because they describe intentions rather than mechanisms. The version that holds is much smaller and much more specific: a named owner per deployed system, a stated boundary of what it may read and write, a defined review point, and a measurement that would reveal drift before a user does.
Worth being clear about what we do and do not sell here, because the phrase is used for both. Readiness and opportunity assessment is the audit stage; ongoing oversight of deployed systems is the advisory stage. Neither is listed as a separate service line, deliberately - listing them would have us appearing to sell the same thing twice under two names, which is a thing a careful buyer notices.
| On this | AI governance | An AI policy document |
|---|---|---|
| What it contains | An owner, a boundary, a review date and a measurement, per system | Principles, and a commitment to be responsible |
| What happens in an incident | Somebody is called, and the boundary says what was possible | The document is read for the first time |
| How it is checked | Against the systems actually running | Against the approval that adopted it |
- When it is the right answer
- When a board or a risk committee asks for it. Bring the four answers rather than the document; the document is the easy part and it is not what they are exposed by.
Start here
If a term here is the one your board paper turns on, ask us about it.
We will send the entry, the evidence behind it, and the honest note about where it does not apply.
You get a reply within one working day, from the engineer who would do the work - not a sales sequence.