Governance is the controls, and the document is the record of them

A policy is not a control, and the difference is testable

A policy says staff must not put customer records into external tools. A control is the thing that blocks it, or records it, or raises an alert when it happens. The test for which one you have is short: name what stops it, name what records it, and name who is told. If all three answers are that people know better, you have a document.

This matters more with AI systems than with most software, because the interface is conversational and the boundary is invisible. Nobody accidentally uploads a customer database to a supplier's file server, and everybody has pasted more context into a chat window than the task needed. That is the interface working as designed, so the correction has to be structural.

Write the policy anyway. It is the record of the decisions and the reference when somebody asks why a control exists. Just count it as documentation rather than as protection, and build the paired control for every clause that matters.

• For each policy clause, name the control that enforces it
• For each control, name the log that proves it ran
• For each log, name who reads it and how often

Name what stops it, name what records it, and name who is told. If the answer to all three is that people know better, you have a document.

Access, and what the system is allowed to reach

The first governance question about any AI system is what it can see and what it can change, not which model it uses. Most incidents in automated systems come from a credential that was scoped generously because scoping it properly took an extra afternoon during a build that was already late.

Give each workflow its own credential rather than sharing one service account. It costs a little more to set up, a single revocation does not take down six unrelated things, and the audit log becomes capable of telling you which workflow did what. Scope each credential to the records the workflow actually needs, not to the table, and certainly not to the database. Start read-only and add write access deliberately.

Then decide what the system may change without a person. Reading is low risk and reversible. Writing into a system other people trust is neither, and writing outward to a customer is a third category again, because it cannot be recalled once sent. Those three deserve different rules, and a design that treats them the same is a design that has not thought about the worst case.

• One credential per workflow, so revocation is precise and the log is attributable
• Scoped to records rather than to tables, and to tables rather than to databases
• Read-only by default, with write access granted deliberately and narrowly
• Separate rules for reading, for writing internally and for sending anything outward
• A documented rotation schedule, and a named person who owns it

Residency, retention and what a provider actually keeps

Three questions get collapsed into one in most procurement conversations. Where is the processing physically done. What is retained after the request completes, and for how long. And is anything used to improve the provider's own systems. Those have different answers, they differ by provider, and they frequently differ between tiers of the same provider's service.

The answers also change. A provider's enterprise agreement may commit to processing in a chosen region, to a short retention window, or to no training on submitted content, while the same provider's consumer product commits to none of that. The only defensible source is your own signed agreement and the documentation it references, read rather than summarised by whoever is selling you the integration.

Ask for the subprocessor list too, because the model provider is rarely the only party in the path. There is usually a hosting platform, sometimes a vector store, often a monitoring or logging service, and each of them is a place your data goes. A diagram showing every hop, with the region of each, is worth more than a page of assurances, and any supplier who cannot produce one has not thought about it either.

• Where processing happens, per component, including logging and monitoring
• What is retained, for how long, and whether that is contractual or a default setting
• Whether submitted content is used for training, and under which agreement tier
• The full subprocessor list, with a region against each entry
• Which of these are commitments in your contract and which are current product behaviour

An audit trail that survives being asked for

The moment that tests a log is six months after the fact, when somebody asks why a particular decision was made about a particular customer. Reconstructing that requires more than a record that the workflow ran. It requires knowing what went in, what came out, which version of the instructions produced it, what was written where, and whether a person approved it.

Log the model and version, because behaviour changes when a provider updates one, and a system whose outputs shifted in March is easier to explain if you know what changed in March. Log the version of the prompt or instruction template for the same reason, since those get edited casually by people who do not think of them as code. Log the trigger, the inputs, the output, the downstream writes and the approver.

Then decide retention and immutability deliberately. A log anyone can edit is evidence of nothing. A log kept for thirty days will not be there when the question arrives. And a log containing full customer records has become a second copy of your sensitive data, sitting somewhere with weaker controls than the system it came from.

• Inputs, outputs, model version and instruction version, per run
• What triggered it and what it wrote downstream
• Who approved it, where approval was required
• A retention period long enough to answer a question that arrives late
• Storage that is append-only, and does not quietly duplicate sensitive records

Where a person belongs in the loop

Human review is expensive, so it should be placed rather than sprinkled. Four conditions justify it: the action is irreversible, the output is visible to someone outside the business, money or a commitment is involved, or the system itself reports low confidence. Anything meeting one of those is a candidate. Anything meeting none of them probably does not need a queue, and putting one there mostly teaches people to click approve.

Design the review so it can actually be performed. A reviewer needs the reason the item was flagged, the input it came from, and the ability to correct rather than only to accept or reject. A queue that presents a finished output with no context produces rubber stamping, and rubber stamping is worse than no review, because it manufactures a record of oversight that did not happen.

Then measure the override rate. If reviewers change nothing over a month, either the system is performing well enough that the threshold should move, or the review is theatre. Both are findings. Reviews nobody measures survive long after they stopped doing anything, because removing one feels like removing a safeguard.

• Irreversible actions, anything sent outside the business, anything committing money, and low confidence outputs
• Every queued item carries its reason and its source input
• Reviewers can correct, not only approve or reject
• Override rate measured monthly, and thresholds moved when it stays at zero

What this takes to put in place, and where governance is not your risk

This is normally a scoped piece of work with an end rather than a retainer, and it is usually done alongside a build, because governance designed in isolation from a system tends to describe a system nobody built. It produces a set of controls, the logging behind them, a documented decision on residency and retention, review thresholds with owners against them, and the short policy document recording why each exists.

Three things move the size of it. How many systems the AI touches, since every integration is its own access decision. Whether specific obligations apply, which turns some choices into requirements and rules out some architectures. And what already exists, because a business with identity management and existing logging is extending something, while a business without them is building its first version, which is a larger and more political job than it sounds.

There are cases where this is not where the risk is. If the AI system reads public information and writes nothing anywhere, most of the above is ceremony, and imposing it slows down something harmless while the actual exposure sits in a shared spreadsheet nobody has looked at in two years. Governance effort should follow the data, not the novelty.

It also cannot make an unsafe process safe. Controls constrain what a system does. They do not improve the quality of its judgement, and a workflow producing subtly wrong output within its permitted scope will pass every control you build.

And none of this is legal advice. What obligations apply to your business, in your industry and your customers' jurisdictions, is a question for someone qualified to answer it. What is written here is how to build controls once somebody has told you what you are obliged to do.

Where a person sits inside the control, and who holds the keys

A control with no person in it is a rule, and a rule is not a control. So this work names, for each class of action, whether the system acts and reports or prepares and waits for a person. Reading a record, drafting a response and flagging an anomaly are the first kind. Deleting data, granting access, sending anything to a regulator or a customer's legal representative, and any decision touching somebody's money or employment are the second, and each needs human approval logged with the name of whoever gave it.

Logged is the operative word. An approval nobody can produce six months later is the same as no approval, and that is the finding which turns a routine audit into a problem.

Every credential, key and account created during this work is created in your own accounts and inventoried at handover. You own the audit trail, the policy documents and the access matrix, and none of it depends on a supplier still being in business. Wobble is based in Karachi and stays accountable for the controls it implemented, which is a narrower promise than certifying you against a standard, and the difference is worth insisting on from anybody selling this.

Moiz Khan decides the architecture on governance builds, because a control usually has to be enforced in the workflow rather than in a document. Doing this in-house is the right call when you already employ somebody with a compliance remit, and the useful outside work then is the enforcement layer rather than the policy set, which your own team will write better than an outsider anyway.

Common questions

What is the difference between an AI policy and an AI control?

A policy states what should happen. A control makes it happen or records it when it does not. The test is to name what stops the behaviour, what records it, and who is told. If the only answer to all three is that people know better, the organisation has documentation rather than protection.

How should access be scoped for an AI workflow?

One credential per workflow rather than a shared service account, scoped to the specific records it needs, read-only until write access is deliberately granted. Treat reading, writing into internal systems and sending anything outward as three different risk categories with different rules, because only one of them can be undone.

What should we ask a model provider about data retention?

Three separate questions. Where the processing physically happens, what is retained after the request and for how long, and whether submitted content is used to improve their systems. The answers differ by provider and by service tier, so the defensible source is your own signed agreement rather than anyone's summary of it.

What belongs in an AI audit log?

The inputs, the outputs, the model and version, the version of the instructions used, what triggered the run, what it wrote downstream and who approved it. Keep it append-only, keep it long enough to answer a question that arrives late, and avoid turning it into a second unprotected copy of sensitive records.

When should a human review an AI output?

When the action is irreversible, when the output goes outside the business, when money or a commitment is involved, or when the system reports low confidence. Give reviewers the reason for the flag and the ability to correct, then measure the override rate. A review nobody ever changes anything in is a record of oversight rather than oversight.

Does governance make an AI system safe?

It constrains what the system can do. It does not improve the quality of its judgement, so a workflow producing subtly wrong output inside its permitted scope will pass every control. That is a design and testing problem. Governance effort should also follow where the sensitive data actually is rather than where the new technology is.