An AI agent that confidently does the wrong thing is not just fixed by a better prompt or a bigger model. If you want to ensure control, quality, and compliance, it is central that the agent checks the intended actions against your organisation's knowledge rulebook before it starts acting.
You Already Own the Knowledge Your AI Agents Need
In a regulated company, that knowledge rulebook already exists, often in the shape of good practice in the records management discipline. What defines a record? How long it is kept? Who may approve what? What the words on a label mean?
Most organisations deploying agents into production, meaning AI that takes actions rather than answering questions, are rebuilding parts of that existing rulebook from scratch under new labels rather than reusing established governance practices.
Gartner expects more than 40 % of agentic AI projects to be cancelled by the end of 2027 due to escalating costs, unclear business value and inadequate risk controls. Cost and business value are not always easy to control -- risk controls, however, are. The latter can be, and in a regulated business it often is, the factor that decides whether a pilot is ever allowed near live operations.
The Problem Is the Action and the Subsequent Consequences of the Action
A false sentence is embarrassing; a false action is a finding
Most conversations about AI risk today are about hallucination: the chatbot that invents a court case or a clause in a contract. The hallucinations are a real problem, however the wrong issue to worry about first. A chatbot that says something false has produced a sentence. However, an agent that acts on something false has produced a consequence.
Frank Coyle, from UC Berkeley, made this point in a talk published by AI Engineer on 23 July 2026. A language model, he reminds his audience, cannot touch anything on its own. It produces the most likely next words, and when it concludes that a task needs doing, it writes down what it wants done and asks the surrounding software to do it.
There is a gap in that handover: the software has fetched what the model asked for, and nothing has been written yet. That gap is where you intervene and the tool you intervene with should not be more AI. The key in the handover is a written statement of what is true in your business.
For example:
- An agent issues a second refund on an order that has already been refunded or sends a payout to the customer service representative instead of the customer.
- An agent reports an order as "probably shipped". This exact status, however, is not one in your rulebook.
The above requests are properly formed, however still they are wrong in this context. Adding a plain rule to your AI, catches each: “an order has at most one refund”, “a customer and a customer service representative are not the same”, and “a status must come from a fixed list”.
Two checks, not one, is key
Frank Coyle describes two checks. The first, at the door, asks whether a request is properly filled in, the way a form is checked. The second, at the ledger, where the accounts are kept, asks whether it is true. In his engineering shorthand: "Pydantic at the door, ontology at the ledger." (AI Engineer, 23 July 2026). The first check is routine software engineering. The second needs a written description of your business, a knowledge rulebook, and it is the one most AI projects skip or overlook.
What it Looks Like in Your Own Documents
- One document, two destruction dates
An agent clearing a migration backlog applies a retention rule to a document that already has one, and nothing crashes. The document now carries two dates on which it should be destroyed, and nobody can prove which one governed, so the evidence for its disposal is unusable. At the next inspection that is not a tidy-up but a finding, and the finding covers the whole batch the document belongs to. One rule, written once, catches every instance of this mistake.
- An approval from someone with no authority to give it
An agent processing a deletion request sends the approval to whoever last edited the file, rather than to the person named as the document's owner. The regulated version invalidates the destruction record for everything approved that way, and you discover it on the day someone asks you to prove the deletion was authorised.
- A status that does not exist
In a quality system, a document is in one of a fixed list of states: draft, in review, approved, effective, superseded, obsolete. An agent that reports a document as "pending final approval" has written a perfectly reasonable phrase and a broken audit trail, because that state is not on the list and nothing downstream knows what to do with it.
- Two documents that works well separately – however not together
Each document is cleared for AI processing on its own. Together they identify a person who was supposed to stay anonymous or reconstruct a formulation that neither of the documents reveals alone. No check that looks at documents one at a time will ever find this. Only a check that knows how documents relate to each other can.
What the above four have in common
In each case the agent lacked a fact about your business that it could not have known unless someone had written it down. E.g. how many retentions rules a document may carry, who counts as an owner, which states exist, which documents must not interact. The same four shapes turn up in a bank's complaint files and a utility's incident reports. Two clocks on one file, an approval from the person who wrote it, a status nobody defined, two documents that are harmless apart and not together.
This is a Records Management Problem, and Records Management is a Profession
The AI industry has a word for the written description of your business and how It is linked together: an ontology. Which is a description of the entities, roles, relationships and constraints that exist within an organisation. Charles Cutter published the rules for how a library catalogue should be structured in 1876, and the rules are still recognisable in the records classification schemes in use today. The rule that one real thing gets exactly one official name, with every variant spelling pointing to it, has been kept by librarians for as long.
The standards already say so: ISO 25964, the international standard that governs how vocabularies are built and connected, lists the kinds of vocabulary it covers and includes classification schemes for records management and ontologies. The standard behind your filing scheme has formally placed the AI industry's new tool in the same family as that scheme. Much of what AI teams are building for the first time, then, is this profession's work under a newer name. That matters, because the profession is not hard to find, and neither is its work that needs to be done in your own organisation.
Why more AI Cannot Check the AI
The natural objection is that a good prompt, or a large enough model, closes the gap. It does not, and the reason is structural. An AI produces an answer with a probability attached. A rule is true or false. However confident the model becomes, you cannot get the second from the first, because a check must be independent of the thing it checks or it is not a check. E.g. It is why the quality system separates the person who does the work from the person who approves it, and why the reviewer signs a different line. Nobody would accept a batch record where the operator also countersigned as the checker. The same logic applies to a model reviewing its own output, and to a second model reviewing the first.
Five Kinds of Rules do Most of the Work
What the rulebook adds is a handful of relevant rule types.
| The rule type | In plain words | In your document archive |
| Only one | A thing cannot have more than one of these | One governing retention rule per document; one owner per archive |
| Not the same role | Two roles that must never be held by the same party for one decision | "The last person to edit a document" is not "the person who may approve its deletion", however often the same human holds both roles |
| One of this lists | The value must come from a fixed list | The six lifecycle states in your quality system |
| Follows the chain | A link that carries on down a chain | A document that replaces one that replaced another has replaced both; permissions inherited down a folder tree |
| Only these kinds | The two ends of a link must be the right sorts of thing | "Approved by" needs a person holding an approval role at one end and a document at the other, never an automated system account |
In short: Written down formally, a machine can apply the rules to every action an agent proposes, every time. And when it says no, it says why.
A Refusal You Can Put in a Deviation Report
That last part matters more than it sound. When the check refuses an action, the reason is a sentence: "approved-by requires a person holding an approval role, and this is a system account." You can put that sentence in a deviation report, however you cannot put "the model was 62 % confident" in a deviation report.
What a Rulebook Cannot Do
A rulebook obviously has limits, it only catches what someone wrote down, and it cannot judge whether a summary is good or a translation is faithful. It enforces a wrong rule as faithfully as a right one, which is why it needs review as well as an owner, and why it rots without either. However those are the same limits your quality system has, and you have run one for years.
Most of the Rulebook is Already in Your Document System, and it is Untidy
Gartner's framing of the gap is blunt: through 2026, organisations will abandon 60 % of AI projects that are not supported by AI-ready data, and in its 2024 survey of 248 leaders, 63 % either did not have the data practices AI needs or did not know whether they did.
If your documents live in SharePoint and Microsoft 365, you are not starting from nothing, you have a rulebook that is usually half-built and rarely curated. The pieces are there. Your term store is the list of words your organisation is allowed to file things under, with synonyms and translations attached. Your content types say what kind of thing a document is and what must be recorded about it. Your retention labels and sensitivity labels attach policy to that classification, and declaring a document a record changes, from that moment, who may edit it and when it may be destroyed. In short, every structural part of the rulebook has a place to live in most Microsoft 365 installations.
What is Missing is Discipline
Someone creates a term for a project. The project ends; however, the term stays. Later, there are four synonyms for the same business function and no rule about which one wins. Document categories get set up in one department's corner and cannot be used anywhere else. Labels are applied by whoever remembered. A human reads the metadata, understand the context and quietly corrects it. If an agent reads it and acts, because the agent has no idea which of the four synonyms is the real one and will pick whichever scores best.
Keep the Groundwork Updated
Help the AI agent, by doing the groundwork, decide what things exist, what they are called and which relationships hold. Write the rules down. Then keep them current as the business changes, which is the same upkeep a library catalogue has always needed. No version of agentic AI removes that work. There is only the choice between doing it deliberately and finding out later what the agent assumed in its absence.
The Regulator is Already Asking for It
The EU AI Act Read as an Operator
The EU AI Act requires high-risk AI systems to stay accurate, robust and secure over their working life, under effective human oversight, with governance over the data they use (Regulation (EU) 2024/1689, Articles 10, 14 and 15). Its Recital 75 spells out what robustness means in practice and names fail-safe plans: mechanisms that let the system stop safely when something irregular happens or when operation moves outside predetermined bounds. A fail-safe plan for an agent is a check that refuses the action. The predetermined bounds are your rules. The Act do not use the word ontology, but it asks you to show that the system stays inside limits you set in advance, and a probabilistic component cannot show that about itself. Not every document agent will count as a high-risk system under the Act. What the Act treats as evidence of control is still a useful description of what an inspector will want to see.
The Quality System, One Layer Down
In life science, the data-integrity principles named “ALCOA” requires that a record must be accurate and consistent. In finance and energy, the names differ, but every regulator's rule asks the same questions of a record is it accurate and is it consistent with what happened. An agent that writes a lifecycle state that is not on the approved list fails both, in exactly the way an inspector is trained to look for. ISO 15489, the records management standard defines what a record is and what governs it. You are not being asked to invent a compliance model for agents. You are being asked to connect the agent to the one you already run.
Where to Start
- Pick one agent action with consequences. Not a chatbot. Something that writes, applies a label, declares a record, routes an approval, deletes.
- Write down what must be true for that action to be legitimate. e.g. "One retention rule per document", "The approver holds an approval role", "The status is one of these six".
- Find where this information already lives. The term store, the content types, the retention policy, the quality manual. The information usually exists and often disagrees with each other. Resolving that disagreement is most of the value, and it is worth doing whether an agent ever ships.
- Put the check between what the agent has found out and what it is about to write. Not after. An agent that has already deleted the file has not been governed.
- Make every refusal explain why and keep the log. That log is your evidence, your debugging trail and your answer to the AI Act in one place.
- Ensure the rulebook has an owner and a review date. A vocabulary without an owner decays. That is the oldest finding in the records management profession.
The Dull Answer is the Right One
The industry's current answer to unreliable agents is more AI: a critic model, a judge model, a committee of models. However, asking a probabilistic system to certify a probabilistic system, moves the problem rather than solving it. The answer that works is to put your “rulebook” in place. Decide what is true in your business and write it down. Check against it before you act and give someone the job of keeping it current. If that sounds like library work, it is because it is library work.
The organisations that get agents into regulated production first will not be the ones with the best prompts. They will be the ones that already treat their information as something you classify rather than something you search, and that have someone whose profession is exactly that.
AI has not created a new governance problem but rather exposed an old one. Every organisation already depends on definitions, classifications, responsibilities and rules that determine what actions are legitimate. The organisations that succeed with agents will not be those that automate fastest. They will be those that translate that existing knowledge into a form machine that can check before they act.
