A written AI policy is not evidence of enforcement

Updated 17 October 2026. A written policy is a starting point. The question is whether a person or system behaves differently because it exists. Earlier unsourced market percentages have been removed from this article.

Trace one policy statement into behaviour

Take a statement such as “sensitive data must not be sent to an unapproved service”. Identify the workflow where this could happen, the control intended to prevent it and the evidence that would reveal a failure. The wording alone does not establish any of those things.

An illustrative implementation might combine an approved tool list, access restrictions and an escalation path for exceptions. Which controls are appropriate depends on the environment. The important point is to connect the policy to something observable.

Test how the process handles a legitimate request that does not fit the approved path. If the only answer is silence, people may invent workarounds. A usable policy needs a way to ask for an exception and receive an accountable decision.

Keep the review proportionate. Not every sentence needs a software control, but every important commitment should have a clear owner and a way to assess whether it is being followed. Otherwise policy coverage can rise while practical understanding stays flat.

The practical next step

Pick one policy commitment and follow it to the product. If the trail ends at another document, keep going until the team can explain the actual behaviour.

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.