Compliance AI should check against rules, not reread the regulation. Abu Dhabi put that design into production
Abu Dhabi's machine-readable government pilot ties each food import assessment to a governing rule. For regulated firms: interpret the rule once, under review, and let AI cite it.
Listen to this article · 5 min
AI-generated narration of the full article.
Ask a language model whether a shipment complies with an import regulation and it will read the regulation, the shipment documents and your question, and produce an answer. Ask it again tomorrow with the same documents and it will read everything again. Every answer is a fresh interpretation of the law, made by a model, at request time, with no record of which reading of the rule it applied.
That is how most compliance assistants work today, and it is the wrong design for regulated work.
What Abu Dhabi did differently
On November 2, the Abu Dhabi Government and OpenAI launched what they call an AI-native Machine-Readable Government initiative, led and governed by the emirate’s Department of Government Enablement. It covers a defined set of government policies and regulations and turns them into a form AI systems can apply to routine compliance assessments, such as permits and certificates.
The first pilot is in production at the Abu Dhabi Agriculture and Food Safety Authority, focused on food imports. Two design commitments stand out in the announcement: each assessment is traceable to the governing rule, and officials retain oversight and accountability for final decisions. Inference runs on GPUs in UAE data centers.
No accuracy, speed or cost results were published, and the sponsors’ claim that this is a world first is theirs. What is useful is the architecture, because it inverts the usual one.
Interpretation moves to the front, and happens once
In a machine-readable design, the hard work of interpretation still happens, but earlier, by people, and only once per version of the rule. Lawyers and regulators decide what a clause means in operational terms, encode it, review the encoding and publish it with a version. The AI then does a narrower job: map the case to the applicable rules, check the evidence against them and cite which rule, in which version, it applied.
- Regulation text
- Encoded rule, versioned and reviewed
- AI assessment citing rule and version
- Official decides and owns it
- Record of case, rule, evidence, decision
- People, once per rule version: Regulation text · Encoded rule, versioned and reviewed
- Every case: AI assessment citing rule and version · Official decides and owns it · Record of case, rule, evidence, decision
This is the same move several vendors are making in enterprise data. SAP’s new Business Data Cloud Ontology Manager, announced on October 29, builds domain views of a knowledge graph that connects business entities, relationships and rules so that agents work against defined context rather than raw documents. Oracle’s Deep Trust architecture pushes business rules into the database as assertions that no generated query can bypass. The pattern is consistent: keep the model away from the part that defines what is allowed.
Why this matters more than it looks
We have argued that proof in regulated AI has to come from outside the model. A versioned rule is exactly that: an artifact the model did not write, against which its output can be checked. It also answers the question an inspector will ask first. “Why did the system approve this?” gets a crisp answer, for example: rule 4.2 in its March version, evidence items one to three, decided by this official.
It is also the logical extension of treating agent skills as controlled documents. A skill tells an agent how to do a task; an encoded rule tells it what the organization has decided a regulation requires. Both are procedures, both need an owner, a review and a version.
Our view, and it is a view rather than a fact: within two years, regulated companies will be expected to show the rule base behind an AI-assisted compliance decision, not the prompt.
What does not go away
Encoding a rule does not remove ambiguity; it records one interpretation and makes it consistent. That is a benefit only if the interpretation is reviewed and can be challenged. Three things need design from the start.
Exceptions and appeals. Real cases fall between rules. The system needs a path that sends them to a person with the reason, and those cases should feed the next version of the rule base.
Change control. When the regulation changes, every encoded rule derived from it needs review, and past decisions must stay linked to the version they used.
Ownership. Someone in legal or compliance owns each rule, the same way someone owns each business definition an agent reads. Without an owner, the rule base becomes another unreviewed prompt, only longer.
For a pharmaceutical quality team, a bank’s compliance function or a customs broker, the first step is not choosing a model. It is picking one narrow, high-volume assessment, writing its rules down in a form a machine can apply, and getting the people who own the regulation to sign the encoding.