Compliance drift: why agents pass audits and still miss

By KYN AI Advisory Team — AI implementation specialists, Singapore

Compliance drift is the gap between what a runbook says and what a running system enforces. An agent can complete every documented step, pass an audit that checks step completion, and still be wrong, because the judgment that made the runbook work was never written down. The remedy is to make the agent ask when a case does not match, name what it could not resolve, and feed each escalation back into the runbook.

What is compliance drift?

An audit checks work against the written spec. A runbook captures the general case. It rarely captures what the person doing the job learned: which near-misses are fine, which compliant-looking actions are red flags, which formats are non-negotiable and why.

An agent has none of that. It applies the rules it was given, literally, at a speed no person matches. It follows the steps and produces a clean record. The record shows the steps ran. It does not show whether the steps still cover the situation.

That is the drift. The agent is not breaking rules. It follows them exactly while the rules stop covering reality.

Where does the unwritten policy live?

Three places turn up repeatedly.

Format and reference data. A person knows a slightly wrong vendor name or item code will probably be accepted. A system integration rejects it unless the reference data matches the exact expected format.
Tolerance. A reconciler knows a transaction a few dollars and a day off is probably fine, and knows which few-dollar gaps are not. A mechanical rule knows only the band it was given.
Ambiguity. A person generating a quote knows when a missing quantity or unclear currency deserves a phone call. An agent must be designed to spot real ambiguity, not pattern-match past it.

Why does a passed test not prove the agent is right?

A sandbox passes the cases its builder thought to test. Live systems enforce more.

In integration work, vendor documentation describes how a system should behave. Master data such as item codes, client records and a chart of accounts must match the target system's expected format before it accepts any transaction. A mismatch that looks trivial on paper can block or corrupt everything that follows.

The only reliable way to find the gap is to test with real data, read-only where possible, in an isolated copy of production. A runbook behaves the same way. An agent built and tested only against the documented steps clears every audit item and still breaks a constraint that lives in someone's memory.

Why are false positives the real risk?

An agent that stalls and asks is a nuisance. An agent that confidently resolves the wrong thing is a risk. In reconciliation design, marking an item "matched" when it is not is treated as worse than leaving it in a review queue. A person reading a queue can fix what they see. A person reading "handled" has no reason to look.

Three rules follow:

When a value falls outside a tight, currency-aware tolerance, the agent asks. It does not assume.
Before the agent widens a tolerance to catch real near-misses, it requires a second independent signal, such as a matching vendor or reference number. Otherwise a loose threshold matches unrelated items that happen to be close in amount.
On documents that carry a number, such as an invoice, the agent never guesses silently. It asks only when something is genuinely ambiguous, such as a currency mismatch or a missing quantity.

An agent that resolves an ambiguous step to keep throughput high is optimising the wrong measure.

What do drifted rules look like in practice?

Reconciliation shows the shape clearly. Three cases look like the general case to a mechanical rule and are not:

Foreign-currency settlement. The card network converts at its own rate and posts a day or more after checkout, so amount and date do not match the receipt.
Refund pairs. A charge and its refund should net to zero. If they are never linked, both sit unresolved.
Self-transfers. A move between a person's own accounts looks like a purchase to any rule that checks amount and counterparty only.

None of these is a documented exception in a typical policy. A human learns them by doing the job. An agent built on the written rules processes all three "successfully" and is systematically wrong.

How do you make the agent surface what it did not decide?

Making the agent more cautious across the board does not work. An agent that flags everything is as useless as one that flags nothing, because people stop reading. The design that holds up is narrower: the agent states what it could not resolve and why.

Name the condition. "Amount differs by SGD 3.40 after conversion, no second reference" beats "needs review".
Give the reviewer enough context to act in one step.
Cap retry and escalation loops, so one ambiguous case does not stall the whole runbook.

Then make the agent's behaviour visible on a schedule:

An audit trail records who or what changed each record, with a before and after. Drift can then be traced after the fact.
A fixed daily report shows what the agent did and what it left open. In a manufacturing system we built, a 06:30 report goes to each department on WhatsApp, at roughly S$0.05 per report.
A hard gate stops bad output. Autonomy and a gate belong together.

How do escalations get back into the runbook?

Detection is half the job. The other half is making each escalation change the document.

Treat every named escalation as a candidate edit to the runbook, not a one-off ticket.
Log why a value fell outside tolerance. Repeated escalations at the same threshold show which unwritten rule needs writing down.
Do not loosen a threshold without a second confirming signal.
Test against real conditions on a schedule, not only at build time. Enforcement in connected systems can change.
Fold confirmed patterns, such as the currency-gap and refund-pair cases, into the runbook so the next agent version does not rediscover them.

Related reading: why outdated runbooks erode trust in agents and our operations systems.

What does drift look like in a worked example?

Illustrative example. The amounts and names are made up to show the pattern.

A runbook for supplier payments says: match each bank debit to an approved invoice, mark the invoice paid, and list anything unmatched for review. The agent follows it. For a month, every step logs as complete. The auditor samples twenty items, confirms each step ran and signs off.

In week three, a supplier invoice for S$4,200 is paid in two debits, S$2,100 each, a day apart. The agent matches the first debit to the invoice by reference. The amount differs, but the second signal matches, so it marks the invoice "matched". The second debit finds no open invoice and goes to the review list. The runbook never said what to do with a part payment, because the person who wrote it always paid in full.

Nothing broke a written rule. The log shows every step. The invoice now reads "paid" in the ledger while S$2,100 is still open, and the review list holds a debit nobody can place. A person would have called the supplier. The agent followed the steps.

The fix has three parts:

A rule that part payments never mark an invoice paid. They create a named exception with both debits attached.
An entry in the runbook that describes the part-payment case, so the next reader sees it.
A test case built from the real event, kept in the regression set.

How do you find drift before an incident does?

Audits sample. Drift hides in the cases the sample does not reach. Four checks catch it earlier.

| Check | What you do | What it finds | |---|---|---| | Replay | Run the agent over last quarter's real records in an isolated copy and compare its output with what staff did | Cases where the agent and the person disagree | | Override count | Count how often staff correct the agent's output, by rule | Rules that no longer fit | | Queue age | Measure how long items sit in the review list | Exceptions nobody knows how to resolve | | Silent success audit | Pull a random set of items the agent marked resolved and have a person re-check them | False positives that never reached a queue |

The silent success audit matters most. Escalations announce themselves. Wrong resolutions do not. Sample the "handled" items on a schedule, and make the sample size part of the runbook.

Who owns the runbook once an agent runs it?

An agent changes who reads the runbook. People used to read it and fill gaps with judgment. The agent reads it and fills gaps with nothing. So the runbook needs an owner whose job is the gaps.

Assign three roles by name:

Runbook owner. Approves every edit, and reviews each cluster of escalations.
Step owner. The person who used to do the step by hand. They know the unwritten rules and are the first to be asked.
Reviewer. Reads the agent's exceptions each day and decides each one.

Write the names into the document. An unowned runbook goes stale, and an agent will run a stale runbook exactly as written. See the runbook staleness problem for how that erodes trust.

What should the escalation message contain?

A useful escalation is short, specific and actionable. A fixed shape helps.

The record. Which invoice, payment or document.
The condition. "Amount differs by S$2,100; one reference matches; second debit unmatched."
What the agent checked. The rules it applied and the sources it read.
What it did not do. "No status change made."
The options. The two or three actions a person can take.

Compare that with "needs review". The first lets a reviewer act in one step. The second sends the reviewer to rebuild the context. When reviewers rebuild context every time, they start approving without reading, which is drift again, this time in the people.

How do you stop the review loop from stalling everything?

Cap the loops. If an item has been escalated twice and is still open, it goes to the runbook owner, not back to the reviewer. If a batch has more than a set number of exceptions, the agent pauses and reports the pattern rather than posting each one. A batch of 200 identical exceptions means a rule is missing, not that 200 people need to decide.

The same discipline shows up in content review, where a quality check names the specific defect, such as an unsupported claim, and returns the work for revision. That loop has a fixed number of rounds so a stubborn case ends in a decision rather than going round forever. A runbook loop needs the same ending: a named person decides.

What belongs in the audit trail?

An audit trail is useful when it answers a question after the fact. Four fields do most of the work:

Actor. Which named account or agent account acted. No shared logins.
Before and after. The record's state on each side of the change.
Rule applied. Which runbook step and version triggered the action.
Evidence. The records read to make the decision.

The "rule applied" field is the one most systems omit. Without a version, you cannot tell whether a wrong action followed an old rule or a new one, and you cannot show an auditor that a changed rule applied from a given date.

Version the runbook like code. Each edit has an author, a date and a reason. Each agent action cites the version it ran under. When an escalation leads to an edit, link the two.

What limits does this approach have?

It cannot find rules nobody has encountered yet. The first occurrence of a new case still gets through.
It needs a person who reads exceptions. If the queue is ignored, the feedback loop does not close.
It adds review time. The saving comes from the agent clearing the routine cases, not from removing the reviewer.
Tighter tolerances raise the exception count at first. That is expected, and the count should fall as rules are written down.

Money, filings, outbound messages and deletions wait for a named person throughout. A cleared runbook step is not a reason to release them.

A quarterly review you can run in an afternoon

Export the last quarter's escalations, grouped by rule.
List the five rules with the most escalations. Each is a candidate edit.
Pull a random sample of 30 items marked resolved. Have the step owner re-check them.
Compare the runbook text with how the step owner describes the work today.
Update the runbook, bump the version and add the new cases to the replay set.
Record what changed and who approved it.

The output is a short change log. Over a year the log shows how far the runbook has moved from its first draft, which is the measure of how much unwritten judgment the agent would have missed.

How do you tell the board or an auditor what the agent covers?

State scope in plain terms. List the runbook steps the agent executes, the steps it only drafts and the steps it never touches. Add the count of exceptions raised and resolved in the period, and the date of the last runbook edit. Those four items let a non-technical reader see the boundary. They also stop a clean audit result from being read as proof that the agent handles cases the audit never tested.

Where KYN fits

KYN builds operations and finance agents that run in your own cloud account. Each agent has its own restricted account. Every action is logged with the actor. Outbound messages, money, filings and deletions wait for a named person. For a manufacturer we moved eleven systems to three and built a ledger of 3,309 reconciled rows with zero duplicates.

The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. Rights in the custom code and configuration pass to you on full payment. See security.

Frequently asked questions

Can an agent pass an audit and still be non-compliant?

Yes. Audits usually check that documented steps ran. They do not test the unwritten judgment around those steps. An agent can show a complete record and still apply a rule in a case the rule was never meant for.

How often should the runbook be reviewed?

Review it when escalations cluster, and on a fixed schedule such as quarterly. A cluster of escalations at one threshold is evidence the rule behind it is missing from the document.

Should every ambiguous case go to a person?

No. Send cases that fall outside a defined tolerance and name the reason. Cases inside the tolerance with a second confirming signal can resolve automatically and still appear in the log.

Checked 30 October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →