Governance is an architecture decision, not a paperwork exercise.
Where your data sits, who can read it, and what happens when a regulator asks — these are answered by how the system is built, not by a certificate on a website. Here is how we answer them.
We would rather show you the architecture than a badge.
Most AI governance pages are a wall of logos. They tell you a vendor passed an audit; they tell you nothing about where your data goes when your team asks a question on a Tuesday afternoon.
We do not hold certifications, and we are not going to imply otherwise. What we can put in front of you is the deployment topology, the review points where a human signs off, and the record that gets written every time the system acts. Those are inspectable today, on your own infrastructure, by your own auditors.
That is the same commitment as the rest of our delivery: nothing behind a black box, and every artefact yours to keep.
Four places the system can run. You choose, not us.
Residency stops being a risk register item once it is a deployment target. Each is a deployment shape we build to, and the trade-offs are stated rather than buried.
- 01Your cloud
Runs in your own cloud account.
The system is deployed into infrastructure you already own and already govern. Your identity provider, your network policy, your billing, your logs.
Your cloud account- Your cloud account
- Application
- Data
- Logs
Public APIOutside it- Model endpoint
No saasinator-hosted tenancy holding your data.
- 02In-VPC
Inside your private network boundary.
For workloads that must never traverse the public internet, the build sits inside your VPC and reaches model endpoints over private connectivity.
Your VPC- Your VPC
- Application
- Data
- Logs
Private connectivityOutside it- Model endpoint
Traffic stays within the perimeter your security team drew.
- 03In-country
Pinned to a named region.
Where data must remain in a jurisdiction, the deployment region is fixed to it and the constraint is enforced by configuration rather than by promise.
Named region- Named region
- Application
- Data
- Logs
Region fixed by configurationOutside it- Model endpoint
Region is a deployment parameter, reviewable in your console.
- 04Self-hosted weights
Open-weight models on your own hardware.
When no external inference call is acceptable, we build against open-weight models served from infrastructure you control — no third-party model API in the path at all.
Your hardware- Your hardware
- Application
- Data
- Logs
- Open-weight model
No external inference callOutside it: —Nothing leaves your estate, including the prompt.
What sits between the model and your business.
An agent that can act on production data needs more than a good prompt. These four controls are built in from the first commit, not retrofitted before go-live.
- 01Human-in-the-loop
A person approves anything consequential.
Consequential actions stop and wait for a named human. Which actions qualify is a decision we take with you during the build and write down, not one we infer on your behalf.
- 02Audit trail
Every action leaves a record.
Inputs, retrieved context, the model's response and the action taken are all written down, with the timestamp and the identity behind them. The record lives in your systems and outlives the engagement.
- 03Observability
You can see it working, and see it failing.
Latency, cost, failure and refusal rates are on a dashboard your team reads — not in a report we send monthly. Behaviour drift is visible while it is still small.
- 04Evals
Behaviour is specified, then tested.
Each capability carries a versioned eval suite that runs on every commit. A build that fails its evals does not ship, and the suite is yours to run long after we have left.
This is what one record looks like.
The control above says every action leaves a record. Rather than assert that, here is the row our own chat agent writes — field names, types and order exactly as the live migration defines them.
| id | uuid | 00000000-0000-4000-8000-000000000001 |
|---|---|---|
| session_id | text | sess_illustrative_0001 |
| state | text | QUALIFYING |
| qualified | jsonb | redacted |
| messages | jsonb | redacted |
| lead_id | uuid | 00000000-0000-4000-8000-000000000002 |
| created_at | timestamptz | <insert time> |
| updated_at | timestamptz | <last write> |
Two fields are withheld rather than filled in. On a real row they carry what the visitor typed, and a plausible-looking invention would be worse than a blank.
Where we work, and what that means in practice.
Much of our delivery lands in the Middle East, so two environments shape how we architect. The UAE's federal personal-data regime sets expectations for how personal data is handled and transferred; the DIFC and ADGM financial free zones each operate their own data-protection regime, distinct from the federal one and from each other.
We treat those as design inputs. They shape which region a deployment is pinned to, what a client's own auditors will want to read, and which processing has to stay inside the country. That is the whole of the claim.
We do not certify your compliance and we do not offer a legal opinion — your counsel and your auditors own that judgement, as they should. Our job is to make sure the architecture can satisfy them: when the answer has to be that the data never left, the deployment is built so that it never did.
Bring your hardest residency question.
Thirty minutes with the people who would architect it. If the honest answer is that a constraint rules something out, you will hear that in the call.