AI governance
An AI governance framework you can actually implement
Most AI governance frameworks stop at principles. This one maps five layers of control onto the place they can be enforced: the boundary between your applications and the model provider. Each layer below states the question it answers and the concrete steps to put it in place.
1. Policy control
Which AI calls are allowed, and under whose rules?
Governance starts with a written, versioned rule that a machine can enforce. Every request from an application is matched to a policy before it reaches a model provider. If no policy matches, the call does not happen — a fail-closed default that prevents ungoverned usage from appearing quietly in production.
Implementation steps
- Inventory the applications and workflows that call an LLM today.
- Write one policy per application, with an explicit default for unmatched traffic.
- Version policies so a decision can always be traced to the exact rule in force at the time.
- Enforce at the gateway, not in each application's code, so rules cannot drift per team.
2. Sensitive data handling
What leaves your boundary, and in what form?
Most AI risk is data risk. Detectors inspect prompt content for email addresses, phone numbers, national identifiers, payment card numbers, and organization-specific patterns before a request is forwarded. Each policy decides what happens on a hit: redact the value, warn, block the call, or route it to a human.
Implementation steps
- Classify the data categories your prompts can realistically contain.
- Enable built-in detectors and add custom patterns for internal identifiers.
- Choose a per-policy action: redact, warn, block, or require approval.
- Set the audit mode so stored prompt content is redacted unless full retention is justified.
3. Human in the loop
Who decides on the edge cases?
A framework that only allows or blocks pushes teams to loosen rules until they stop meaning anything. High-risk requests should instead pause and wait for a named reviewer. Once approved, the request resumes through the same pipeline, so the reviewed call and the delivered call are the same call.
Implementation steps
- Define the risk conditions that require review rather than an outright block.
- Assign approvers per organization and keep the queue visible to them.
- Track the decision and the delivery outcome separately so a failed provider call can be retried without a second approval.
- Monitor approval latency — a queue nobody clears is a blocked queue.
4. Immutable audit
Can you reconstruct any decision months later?
Auditors and incident responders need the record, not a summary. Every request writes an append-only audit event carrying correlation IDs, timestamps, the matched policy and its version, detector findings, the decision, and the reasoning behind it — including which provider key served the call.
Implementation steps
- Record every request outcome, including blocks and approvals, not just successes.
- Keep correlation IDs consistent from application through gateway to provider.
- Set retention to match your compliance obligations.
- Rehearse a retrieval: pick a date and reconstruct what happened and why.
5. Continuous review
How does the framework stay accurate as apps change?
AI usage changes faster than policy documents. Treat the audit log as the feedback loop: review blocked and approved traffic on a schedule, tighten detectors that miss, and relax rules that create noise without reducing risk. Every change is a new policy version, so the history stays intact.
Implementation steps
- Review decision volume and approval outcomes on a fixed cadence.
- Adjust detectors and thresholds based on real findings, not assumptions.
- Re-approve policy versions through your normal change process.
- Re-run the inventory whenever a new application ships.
Where Airlock fits
Airlock is an OpenAI-compatible gateway, so adopting the framework does not mean rewriting your applications. Point your existing client at Airlock with an Airlock API key, connect your own OpenAI key, and the five layers above apply to every call: policy match, detector pass, optional approval, and an audit event — before the request reaches the provider.