AI Solutions · AI Governance
AI Governance
Most organisations have one of two positions on AI: a ban, or nothing written down. Neither survives the first question from a regulator or a major customer. [Draft copy]
The problem
A ban does not stop it. It just moves it somewhere you cannot see.
Where AI is prohibited, people use it anyway on personal accounts and consumer tiers — which is the worst version of the situation, because company data is now leaving through a channel you have no visibility of, no contract covering, and no record of. Where nothing is written down, there is simply no boundary at all.
Either way the answerable question is the same one, and the answer is the same: nobody can say what data has been sent to which model, by whom, under what terms, or whether it was retained.
What enterprise-grade looks like here
A boundary that is enforced, not requested.
Enterprise-grade governance is not a longer policy document. It is a register of the AI systems actually in use with an owner and a risk classification against each, a stated boundary on what data may reach which model, and that boundary enforced at the platform rather than asked for in a PDF nobody opens.
Where the obligation is absolute — data that cannot leave the perimeter under any circumstance — the answer is an air-gapped deployment: models running inside your own network with no egress, so the question of what left does not arise. It costs more and it is sometimes the only thing an assessor will accept. We will tell you honestly which of your workloads genuinely need it, because most do not.
Acceptable use matters too, and the framing matters as much as the rule. The purpose is to protect staff from an unclear boundary and the organisation from an unrecorded one — not to surveil people. A rule that is written down, technically enforced and monitored proportionately is fairer than a vague prohibition selectively enforced after something goes wrong.
This framing repeats on every capability page. It is the differentiator, and it reads consistently across all of them (§9 T3).
What we do
Six moves, in this order.
-
Inventory what is already in use
Including the shadow usage on personal accounts. This is the uncomfortable step and it is always the one that changes the conversation.
-
Classify by risk and by obligation
Not every use case carries the same exposure. Classification is what stops a uniform policy that is simultaneously too strict to follow and too loose to defend.
-
Set the data boundary and enforce it technically
What may reach which model, under what terms, with what retention — enforced at the platform boundary so compliance is the default path rather than an act of discipline.
-
Air-gap what genuinely requires it
Self-hosted inside your perimeter with no egress, for the workloads where nothing else will be accepted. Scoped narrowly, because the cost is real.
-
Define acceptable use, and monitor proportionately
What staff may use and what they may not, with detection sized to the risk and a stated response. Published to the people it applies to, not held by security alone.
-
Produce the evidence
The register, the decision log, the boundary configuration and the monitoring record — assembled as delivery happens, which is the only version that stays true.
[Draft copy]
What you end up owning
Documents and configuration, not a dependency.
| Deliverable | Owned by |
|---|---|
| Register of AI systems with owners and risk classification | Risk & compliance |
| Data-handling boundary, enforced at the platform | Security and platform |
| Air-gapped deployment where required | Platform team |
| Acceptable-use policy and proportionate monitoring | HR, legal and security |
| Evidence pack for assessors and customers | Risk & compliance |
[Draft copy]
Tell us what you are being asked to prove.
Bring your current position on AI — including if that position is a ban nobody follows.
Start a conversation