The AI Policy Is Not The Control

A policy can help because it gives people a boundary, and in a regulated firm that boundary matters. Staff need to know which tools are allowed, which data should stay out, when a human review is required, and when a use case needs compliance involved. The mistake is treating that policy as if it proves how the work happened.

A risk lead will eventually ask a much plainer question:

What did AI touch, and what evidence did we keep?

That question usually cannot be answered by the policy itself. It has to be answered closer to the workflow, where the work is actually happening and where the evidence can still be captured without turning every use case into a special project.

What the policy can do: the policy sets intent. It can say that staff should use approved tools, keep customer data out of public systems, review outputs before they leave the firm, and escalate sensitive use cases. Those rules are useful. The gap appears when the policy becomes the only artifact anyone can point to, because the real AI work is usually more ordinary than the policy language.

It shows up in complaint summaries, credit notes, call notes, legal first passes, support tickets, board-pack drafts, vendor dashboards, browser extensions, research workflows, and internal email drafts. That is where the proof has to live, because that is where the business dependency is being created.

The row I would build: for each serious AI workflow, I would build one row that a business owner, compliance lead, and operations manager can all understand. The first version only needs enough detail to make the work testable.

FieldQuestion it answersWorkflowWhere does AI touch the work?OwnerWho owns the final judgment?Data classWhat information can enter?Approved pathWhich tool, model, workspace, or vendor route is allowed?EvidenceWhat log, approval, sample, or review artifact is kept?FallbackWhat happens if access changes?

That row is not a grand framework. It is a simple way to stop treating the approved-tool list as if it were the real AI inventory.

Take complaint summaries before escalation. The policy may say that customer data cannot enter public AI. The row should say who owns the summary, what customer text can enter, which route is allowed, what edited version is kept, and what the team does if the vendor route changes. That is much easier to test than a broad policy sentence.

Why fallback belongs in the row: a workflow can become dependent on AI quietly. Nobody announces it. The tool just starts saving time, and the manual path gets weaker because people stop using it. Then a vendor changes the model, region, retention setting, logging path, or access rules. The feature may still exist, but the original approval no longer describes the work properly.

That is not a reason to panic. It is a reason to write the trigger down. If the workflow breaks when the AI path changes, the dependency is already real enough to govern.

The same logic applies to privacy. A public article summary, a complaint summary with customer text, a legal first pass, and a credit memo from internal notes should not be routed through the same environment just because they all involve AI. One workflow may be fine in public AI. Another may need private cloud controls. A third may need local processing or an isolated route. The row forces that decision into the open before people build a workaround.

How I would start this week: I would not begin by asking for every AI tool in the firm. I would ask for the 10 workflows people already rely on. Not the demos, not the wish list, but the work someone would feel tomorrow if the AI route disappeared.

For each one, fill the row in plain language. If the team cannot name the owner, data class, evidence, or fallback, that is the finding. It does not need to be dressed up. It means the policy is still floating above the work.

Once those rows exist, the conversation gets calmer. Legal is not debating every possible AI use in one giant document. IT is not forced to block everything because the risk picture is blurry. Compliance can ask for evidence instead of vague assurance that "a human checks it." Operations can see which workflows are becoming dependent on AI before the dependency becomes too useful to unwind.

The policy is still useful, but the row is where the work becomes governable. A policy tells people the boundary. A row shows whether the boundary was followed in a real workflow, by a real owner, with evidence that can be reviewed later.

Where this helps in practice: the row gives each function something concrete to challenge. Operations can say whether the workflow description is real. Compliance can say whether the evidence is enough. IT can say whether the approved path matches the environment. Legal can say whether the data class is being handled properly. The business owner can say whether the fallback is realistic or just a sentence nobody would follow under pressure.

It also gives leadership a better way to prioritize. If 10 rows exist, not every row needs the same treatment. A public research workflow may only need light evidence and a clear owner. A credit memo, complaint escalation, claims workflow, or legal review may need tighter routing and stronger proof. A vendor-embedded AI feature may need a reopen trigger tied to model, data route, region, retention, logging, and access changes. The row makes those differences visible without turning every conversation into a policy rewrite.

The register should stay close to the work. If it becomes a static compliance artifact that nobody updates, it will drift. I would ask the workflow owner to update the row when the tool path changes, when the data class changes, when the evidence changes, or when the fallback stops being realistic. That is much lighter than reopening the whole policy, and much more useful than pretending the original approval still describes the current workflow.

P.S. If I were starting inside a regulated firm next week, I would not ask, "Send me every AI tool." I would ask, "Show me the workflows people already depend on, and tell me what breaks if the AI path changes tomorrow."