AI that stays in your estate.
Models and data on hardware you own or a UK cloud you control, for work that cannot go to a US-hosted model. Keep the record beside them, or on AUDITSU if you would rather the verification sat outside your own walls.
The model you want runs somewhere your data cannot go.
- Procurement asks where inference happens, and nobody can answer it precisely.
- Residency is promised by a contract rather than by the architecture.
- The vendor holds the log of what the AI did, in the vendor’s cloud.
- The data that would make the AI useful is the data you are not allowed to send.
- Changing model later means re-architecting, so the first choice quietly becomes permanent.
Where it runs is one question. What it was allowed to do is the other, and both answers should be yours.
In. Build. Leave. Prove.
One job, four weeks, in production. Then it keeps proving itself.
In
The job, the data classification and where it is allowed to run. Written down first.
Build
Stand it up in your environment and run the job beside the current way.
Leave
Your team operates it, with the runbook. We maintain it if you ask.
Prove
Every decision checked and recorded. Keep the record in your estate, beside the work, or on AUDITSU if you would rather the verification sat outside it.
What you are left with.
- A deployment of open-weight models sized to the job, on your hardware or a cloud account you control.
- The agent for the job, with what it is allowed to do written down first.
- The checks that run before each decision, and the record they produce.
- The record, in your estate beside the work or on AUDITSU, whichever you choose.
- The runbook your team keeps, so they can operate and change it.
Where does this run, who can compel access to it, and can you prove what it did?
What the AI is allowed to do is written down first.
Every decision is checked against those rules before it happens.
A named person signs it off. The check produces the evidence; a person judges.
You can replay the whole history any day and get the same answer.
If anyone changes it later, it shows. Patent pending, UK application GB2620101.2.
The request
Show us that the Aurora Banking app meets EN 301 549.
From a procurement team · 2 Sep
What you show them
Account overview
42 checks
Signed off
QA lead · 4 Sep
Payments
38 checks, 2 fixes re-checked
Signed off
Product owner · 6 Sep
Onboarding
29 checks
Signed off
QA lead · 9 Sep
That is what a deployment leaves running for your job, and what the record holds. In the accessibility product today, a person on your team accepts every finding before it reaches your record.
Who this is for.
- Financial services, health, legal and public sector teams with a residency or confidentiality constraint.
- Teams whose most useful data is the data they cannot send to a hosted model.
- Boards who have been asked where inference happens and want a precise answer.
Not for
Teams whose data can already go to a hosted model. You do not need this, and we will say so.
Who you deal with.
You deal with Simon and Jason from the first call. One engineer sits inside your team, full time, for the four weeks.
Simon Milner, Founding Architect
He designed the record: what the AI is allowed to do, checked before it acts, and replayable afterwards. Twenty-five years in Silicon Valley before that.
Jason Crispin, Founder
He owns the customer side of a deployment: what the job is, what it is worth, and that it lands. He is on the first call and every one after.
Four weeks, then it keeps proving itself.
Week 1
The baseline
The job, the data classification, the hardware, and what the AI is allowed to do in it. Written down before anything runs.
Weeks 2 to 4
The build
Our engineer stands it up in your environment and runs the job beside the current way.
Week 4 on
The proof
Every decision checked and recorded. The record runs in your estate, maintained by us, or on AUDITSU on a monthly subscription.
What you keep
- The deployment, running where you said it would.
- The model and the rules, both changeable by your team.
- The runbook, and the code assigned to you in writing.
- The record of every decision, where you chose to run it.
What people ask.
What does sovereign mean here?
What does sovereign mean here?
Your models, your data, your hardware, your jurisdiction. The work runs where you say it runs, and the record of what the AI did sits in the same place.
Does our data ever leave the country?
Does our data ever leave the country?
Not if your rules say it cannot. That is the point of this option: the deployment is sized to run where your data already is, rather than sending it somewhere a contract promises is safe.
Which models can we use?
Which models can we use?
Open-weight models you can run yourself, chosen for the job rather than the brand. We size the model to the work in week one.
Can we change model later?
Can we change model later?
Yes. The rules and the record sit around the model, not inside it, so changing model does not mean rewriting what the AI is allowed to do.
Whose hardware is it, and who maintains it?
Whose hardware is it, and who maintains it?
Yours, or a cloud account you control. Your team operates it, with the runbook we leave behind. We maintain it if you ask.
Where does the record itself run?
Where does the record itself run?
Your choice. It can run in your estate, on the same infrastructure as the work, and we maintain it there. Or it can run on AUDITSU, which some teams prefer because the verification then sits outside their own walls. The rules and the history are yours either way.
What does it cost?
What does it cost?
Scoped on the call. It depends on the job, the model it needs and where it has to run.
Where to go next.
Which job is stuck because the data cannot move?
Thirty minutes with Simon and Jason. Bring the job and the constraint, and you leave knowing what it would take and what it would cost.