Insights · AI Governance
Governed, Auditable AI For Mid-Market Companies
Enterprises solve AI governance with a committee. Mid-market companies do not have one, and copying the enterprise artefact produces a forty-page policy nobody reads while an unreviewed agent quietly writes to production. What works at this size is a small number of controls wired into the system itself, where they cannot be skipped.
- Published
- Author
- Tim de Vallée
- Cluster
- AI Governance
The short answer
Governed AI at mid-market scale means five controls, built into the system rather than written into a policy document: a defined scope for what each agent may access, role-based limits on what it may change, an approval gate on anything irreversible or above a value threshold, a complete decision log for every action taken, and one named person with authority to stop a release. Those five are enough to answer an auditor, a client questionnaire or a board question. Anything beyond them is enterprise theatre until you have the headcount for it.
Governance is an architecture decision, not a document
A policy that lives in a shared drive constrains nobody. A scope definition compiled into the agent's configuration constrains everybody, every time, with no discipline required from the person under deadline pressure.
That distinction drives everything here. Every control below is something a system does, not something a person promises to do. The document still gets written — you need it for client questionnaires and your own clarity — but it describes the controls, it does not implement them.
The five controls
- 01
SCOPE
Each agent gets an explicit statement of the data it may read and the systems it may touch, expressed as configuration. An agent built for order handling cannot read the payroll table because it was never given the path, not because a policy asked it not to. Scope is defined before build and reviewed when it changes.
- 02
ACCESS
Role-based controls define what each agent may create, change or delete, mirroring the permissions a human in that role would hold. Read and write are separated deliberately. Most agents that people describe as risky are simply agents that were given write access they never needed.
- 03
HUMAN REVIEW
Every new system runs in review mode first: a person approves each action before it executes, while the system earns trust. Once it is trusted, approval narrows to the cases that warrant it — anything irreversible, anything external-facing, anything above a value threshold you set, anything the system flags as low confidence. Review mode is not a training-wheels phase you outgrow entirely. It is where the risky subset permanently lives.
- 04
LOGGING
Every input, decision, tool call, escalation and commit is recorded with a timestamp, the version of the logic that produced it, and the identity of any human who approved it. The test is simple: if a client asks what happened on the fourteenth, you can show them, in minutes, without reconstructing anything. A system that cannot show its work is a liability wearing a demo.
- 05
THE STOP
One named person holds the authority to block a release, and that authority is real — it does not get overruled by a delivery date. At DBAI, that gate is our lead architect, and nothing reaches a client environment past it. The control that matters most is the one with a name attached.
Documented governance is not certification, and should not pretend to be
This is where most mid-market AI programmes overstate themselves, so it is worth saying directly about our own practice.
DBAI holds no SOC 2. What we maintain instead is an evidence set: an inventory of where AI is used and for what, a register of subprocessors, contractual scope and liability terms, documented security controls, and the named release gate above. Anything acting outside our own environment requires human review and a human commit. That is a defensible posture, honestly described.
The dishonest version — implying a certification you do not hold, or describing an aspiration in the present tense — fails the first time a client's procurement team asks for the report. Say what you have. It is usually enough, and it is always more durable than the alternative.
What an auditable trail actually contains
Teams tend to assume logging is solved because their application writes logs. Application logs record that something ran. An auditable AI trail records why a specific decision was made, and reconstructs it. The difference is five fields:
The input as received, before any normalisation. The rule or policy version in force at that moment. The retrieved context the decision was grounded in. The action taken, including anything that was escalated rather than executed. And the human approval, where one was required, with an identity attached.
Store those and you can answer any question about any decision, including the ones asked eighteen months later by someone who was not there. Store less, and you are relying on memory.
The trade-offs, stated plainly
Approval gates cost throughput. A system that escalates every marginal case will burn more of a manager's day than the manual process did — and the usual failure is not too few gates, it is too many, set once and never tuned. Review thresholds need to be reviewed themselves, quarterly, against what actually got escalated and what the human actually changed.
Logging costs storage and design time, and it has to be built in from the first commit. Retrofitting an audit trail onto a system that was not designed for one is close to a rebuild.
And governance slows the first deployment. It is meant to. The speed shows up on the fifth deployment, when the controls are a template rather than a debate.
What to do this quarter
Write down every place AI currently touches your business, including the tools individuals adopted without telling anyone. That inventory is usually the most uncomfortable document in the programme and the most valuable.
Then, for each one, answer four questions: what can it read, what can it change, who approves the irreversible actions, and where is the record. The gaps are your roadmap. Most companies find that two or three systems need controls urgently, and the rest need nothing more than being written down.
Related
Show us the process you are nervous about automating.
We will design the control surface around it before a line of it gets built.
Book a Discovery Call