Ask a modern AI assistant almost anything and you will get a fluent, confident answer. For writing an email or summarising a report, that is often all you need. But ask it to approve a purchase order, check a contract or recommend a maintenance action, and something important changes: the answer no longer has to be convincing. It has to be correct, according to rules your organisation has to follow.
That is where generic AI quietly breaks down.
The model gives you the most likely answer, not the right one
A large language model is, at heart, a prediction machine. It has read an enormous amount of text and learned which words tend to follow which. When you ask it a question, it produces the answer that is statistically most likely to sound right.
Most of the time, likely and right are the same thing. In business decisions, they often are not:
- A purchase order either complies with your procurement policy or it doesn't.
- A supplier's certificate is either valid today or it has expired.
- A drug either interacts with a patient's other medication or it doesn't.
These are yes-or-no facts. "Probably fine" is not an acceptable answer, and a mistake is not a bad suggestion: it is a compliance breach, a safety incident or a contract dispute.
"But we gave it our documents"
The usual fix is to connect the AI to company documents: policies, procedures, contracts. This approach, often called RAG (retrieval-augmented generation), lets the model look things up before it answers. It genuinely helps. The AI now has the right context in front of it.
But context is not the same as control. The model reads your rules; it is not bound by them. Three things still go wrong:
- It can still contradict what it just read. Nothing stops the model from producing an answer that conflicts with the policy it retrieved, especially in unusual cases.
- It finds similar text, not the applicable rule. Search returns passages that look relevant. It doesn't know that clause 4 was replaced by an amendment last year, or that one approval limit only applies to a certain category of spend.
- It can't show its working. When an auditor asks "why did the system approve this?", the honest answer is "the model said so". That doesn't pass an audit.
Your rules already exist. They just aren't usable by a machine
Every organisation runs on rules: regulatory requirements, approval chains, safety conditions, procurement thresholds, contract obligations. The problem is where those rules live:
- in policy PDFs and procedure manuals written for people,
- in settings buried inside ERP and finance systems,
- and in the heads of experienced staff who "just know" how things work.
People can cope with that mess. Software can't. And when experienced staff retire or move on, a lot of that knowledge leaves with them.
What has to change: rules the AI must respect, not just read
The fix is not a bigger or smarter model. It is giving the AI a formal, machine-readable model of how your business works, and checking its answers against that model before they reach anyone.
In practice that means three things:
- Write the rules down as logic, not prose. "A purchase order needs an approved supplier. An approved supplier needs a valid certificate. A certificate is valid only before its expiry date." Expressed this way, in what is called an ontology, a computer can apply the rules exactly, every time.
- Check every answer against those rules. Before an AI output is released, a validation step tests it against the rules. If it breaks one, it is blocked and passed to a person, with the specific rule that failed.
- Keep a record of every decision. Because each answer is checked against named rules, you automatically get an audit trail: which rule applied, which data was checked, what was decided, and when.
The difference shows up immediately in the answers. Here is the same supplier question answered both ways:
Generic AI: "Supplier ACME-12 may have compliance concerns. You should verify their certification status before proceeding."
Rule-checked AI: "Rule 47.3: Supplier ACME-12 blocked. ISO 9001 certificate expired 3 days ago. Order halted pending re-certification. Compliant alternative: Supplier ACME-07."
(An illustrative example.) The first answer sounds helpful but leaves all the work, and all the risk, with you. The second can be acted on, checked and defended.
Writing the rules down reveals problems you didn't know you had
There is a useful side effect. When organisations formalise their rules, they almost always discover that some of those rules contradict each other. A policy says one thing, a procedure says another, and the system enforces neither.
In one compliance audit Archisus carried out, formalising the rules surfaced 47 logic gaps: approval conditions that contradicted each other, approval chains that looped back on themselves, and compliance rules that were officially in force but never actually checked. None of them were visible in the original documents. Results vary with the domain and the scope, but the pattern is common.
Where to start
You don't need to model your whole organisation at once. Pick one process where mistakes are expensive and the rules are well understood: procurement compliance, regulatory reporting, maintenance approvals. Map its rules, find the gaps, and test AI against that one process with real data.
That is exactly what the Archisus Business DNA Audit does in two weeks: it maps the rules of one domain, reports the contradictions and gaps, and gives you a draft ontology and a ranked shortlist of pilot projects. If the case isn't compelling, you stop there, with a much clearer picture of your own rules.
Key takeaways
- Generic AI produces the most likely answer; business decisions need the correct one.
- Giving AI your documents helps, but it reads your rules without being bound by them.
- The fix is a formal model of your rules (an ontology) and a check on every output before release.
- Formalising rules often uncovers contradictions that were invisible in the documents.
