The situation
Many regulated organisations have done the hard governance work. There is an AI policy, an acceptable-use standard, a data classification scheme and an approved tool. Yet staff in operations still do not use AI for the work it would obviously help with: drafting incident summaries, preparing regulatory returns for review, searching procedures, triaging correspondence.
The reason is usually the same. The policy is written in principles (“confidential data must not be disclosed to third parties”, “outputs must be subject to appropriate human review”) and staff cannot tell what those principles mean for the task in front of them. Cautious people stop. Less cautious people use whatever is to hand. Neither outcome is what the policy intended.
This page is about closing that gap for specific workflows: turning agreed policy into controls that are built into how the work is done.
What the work involves
I start with one or two workflows, chosen with your operations sponsor because they matter, recur often and have contained data exposure. For each, I break the work into steps and ask, step by step, which policy requirements apply and how each can be met.
Controls come in three kinds, and the mapping says which is used where:
- Technical controls enforced by the tool or environment: which data sources are connected, which classifications are blocked, which actions are disabled, where outputs are stored.
- Review controls performed by a named person at a defined point: approving a draft before release, checking a sample each week, signing off a source list.
- Procedural controls written into the team’s working instructions: what not to paste in, how to record the use of AI in a case file.
Technical controls are preferred wherever they are possible, because they do not depend on memory. This follows the approach in my published work on agent safety: permissions and approval boundaries enforced by the system, not requested in a prompt. My governance framing comes from designing AI agent infrastructure for regulated financial services and the published Tiered Governance Model, which grades each AI step by whether it reads, advises or acts.
The signature deliverable, illustrated
Illustrative example, not taken from a client:
| Policy requirement | Workflow step | Control | Type | Evidence | Owner |
|---|---|---|---|---|---|
| Restricted data not sent to external services | Staff paste incident notes | Restricted-label documents blocked from the assistant | Technical | Block events logged | IT security |
| Outputs reviewed before external use | Draft regulator correspondence | Draft cannot be sent from the tool; reviewer approves in case system | Review | Approval record with reviewer and version | Team lead |
| Records retained per schedule | All steps | Prompts and drafts stored with the case, not in personal history | Technical | Retention tag on case | Records manager |
| Ambiguous: are supplier contracts “confidential”? | Contract summary | Flagged for interpretation | Open question | Decision recorded | Compliance owner |
Alongside the map sits an approval dependency list: each approval the pilot needs, who gives it, what they need to see and the order in which they can act.
How acceptance is judged
Acceptance has two halves. The controls must be demonstrable: each one shown working, with its evidence, in front of the risk owner. And the workflow must be useful: staff time, rework and reviewer findings measured against the current process over the pilot period. Your sponsor and risk owner decide whether to approve, revise or stop. My obligation is to give them complete evidence for that decision.
Ownership and handover
The operations sponsor owns the workflow and its results. The risk owner owns the control map and any change to it. At handover, a named member of your team holds the working instructions, the evidence configuration and the method for adding the next workflow to the map.
When to choose something else
For AI systems inside customer-facing financial processes, see AI engineering for financial services. If you need an agent that takes actions in your systems, governed AI agent implementation covers the build. If the tool is bought but unused and policy is not the obstacle, AI tool rollout and adoption support is the better start. To decide between training and enablement, read AI training versus enablement.