Building an AI Governance Framework Your Legal Team Will Sign Off On
Governance fails when it starts as a policy document
The typical first attempt is a twenty-page AI policy circulated for comment, which everyone approves and nobody applies. Governance that works is closer to a build pipeline: a short intake form, a risk tier assigned at the start, and a set of controls that attach automatically to that tier. Engineers should be able to tell within ten minutes of an idea whether it needs a full review or can ship under standing approval. If the answer takes three weeks and two committees, teams will route around it — usually by calling an API from a laptop.
Tier your use cases before you write controls
Three tiers cover most organisations. Low: internal productivity tools with no personal data and a human reading every output — drafting, summarising, code assistance. Medium: customer-facing systems or anything touching personal data, requiring a documented eval, a data protection impact assessment and defined fallback behaviour. High: anything influencing decisions about people — credit, hiring, insurance, healthcare, access to services — which needs formal review, bias testing, logging and a human override path. The EU AI Act's risk-based structure maps onto this closely, which makes the same tiering useful for compliance evidence later.
The five controls that matter most
Data lineage: know what went into the system and whether you had the right to use it. Human oversight: a named role that can override or switch the system off. Logging: inputs, outputs and model version retained long enough to investigate a complaint. Evaluation: a documented test set with accuracy and failure-mode results, re-run on every model change. Vendor terms: written confirmation of whether your data trains anyone's model and where it is processed. Almost every regulatory question we've seen a client field reduces to one of those five.
Model changes are the gap nobody plans for
Providers deprecate and update models on their schedule, not yours. A system validated against one model version can behave differently after an upgrade, and if your governance record says 'tested and approved' with no version attached, it is worth nothing. Pin model versions explicitly, keep your eval suite runnable on demand, and treat a model upgrade like a production dependency bump — regression tested before rollout, with the results filed.
Regional differences you can't ignore
European deployments carry EU AI Act obligations layered on top of GDPR, with transparency and documentation duties that vary by risk tier and by whether you are a provider or a deployer. US work is sector-driven — HIPAA, FCRA, state privacy laws and evolving state-level AI rules rather than one federal framework. Gulf deployments run into data residency expectations and national data protection laws in the UAE and Saudi Arabia, plus sector rules from financial regulators. Design for the strictest market you serve; retrofitting residency into a live system is genuinely painful.
Start small and make it routine
A workable first version is a one-page intake form, a tiering rule, an owner per system in a register, and a quarterly review of anything in the top tier. That is achievable in a few weeks and gives auditors and boards something concrete. Elaborate frameworks written before you have three AI systems in production tend to describe a company you aren't. Build the register first; the policy will write itself from what you find in it.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch