Updated 17 October 2026. A governance framework becomes operational when it changes what people do on an ordinary working day. A document launch is not the same milestone.
Put the checks where decisions happen
Connect the relevant checks to product design, release review and incident handling. A separate annual exercise may miss changes that happen every week. The exact process should match the system’s scope and consequences.
An illustrative release review can identify changed tools or permissions, inspect the affected tests and record the decision. It does not need to repeat every previous assessment if the unchanged evidence remains relevant. It does need to explain what changed.
After release, monitoring and support should feed useful findings back into the review. A recurring exception may suggest a new test case. An incident may expose a missing permission boundary or unclear owner. The loop matters more than the number of policy pages.
Keep the process usable. If following it requires navigating five disconnected systems and locating a person who has left the company, the control may exist mostly in theory. Operational design includes the people who must operate the process.
| Question | Evidence or action |
|---|---|
| Design | Purpose and boundary decisions |
| Release | Changed behaviour and evidence |
| Operation | Findings returned to the next review |
The practical next step
Rehearse the routine on the next small change. Notice where information or authority is missing and fix that friction before increasing the system’s scope.
Keep the resulting decision, its owner and unresolved questions in a short decision record. For claims about agent behaviour, connect the decision to evaluation evidence rather than relying on a successful demonstration alone.
Further primary reading: NIST AI Risk Management Framework. The review map and product recommendations above are my analysis, not a certification or a legal assessment of a particular deployment.
