AI governance
How I turn AI risk into release decisions
Governance works when a team can see the intended use, evidence, open question, accountable authority, release condition, and signal that reopens the decision.
The cases below come from systems I built. The operating model is the clearly labeled enterprise method I would bring to a larger review program. The distinction stays visible because a proposed program is useful only when it is not mistaken for biography.
Proposed operating model
Chapter 1 · Operating model
One record from intake through change review
Review depth changes with consequence and uncertainty. The decision record does not disappear at approval; monitoring, incidents, and material changes route back into it.
01
Intake
Define intended use, affected people, owner, data, model or vendor, autonomy, workflow, and decision consequence.
02
Tier
Set review depth from consequence, population, data sensitivity, reversibility, scale, and human authority.
03
Review
Bring required domain owners into one evidence record and separate expert judgment from unresolved questions.
04
Decide
Approve, condition, return for evidence, restrict, or stop. Record rationale, owner, conditions, expiry, and dissent.
05
Release
Verify controls, training, fallback, monitoring, escalation, and the accountable signoff before go-live.
06
Monitor and change
Connect bounded signals to action and reopen review when the model, data, vendor, workflow, use, law, or incident changes.
No accountable owner means no release decision.
An unresolved expert question stays unresolved in the record.
A condition without a test, owner, and expiry is not a condition.
Monitoring without a named action is observation, not governance.
A material model, data, vendor, workflow, use, or law change reopens review.