Somewhere in your backend, a rule that decides money changed last week.
An auto-adjudication threshold — the dollar amount under which an insurance claim gets approved without a human ever looking at it — moved from $2,500 to $5,000. The change shipped clean. Tests passed. Nobody got paged. Then the quarterly exam comes around, and the examiner across the table asks the only questions an examiner ever really asks: who made that change, what exactly did it do, when, and who said it was allowed?
You open the change history. It says agent.
This is where the "AI wrote it" era of backend development runs into the audit function, and the two do not get along. The instinct in the room is that AI made everything lighter — faster to build, and surely easier to sign off on. It didn't. Letting an agent author a change to a governed rule doesn't lower the evidentiary bar you have to clear. It raises it. And the thing that has to clear that bar isn't the agent. It's your backend.
"An agent did it" is not an answer to any question your auditor asks
An auditor reconstructs a regulated change from four facts, and only four: who made it, what exactly changed, when, and why it was allowed. That frame doesn't care whether you sit in claims, lending, or a clinical system. It's the shape of every change-control conversation you will ever have with an examiner.
Run the four facts against that threshold change and watch each one come up empty.
Who. "An agent" is a category, not an actor — the equivalent of answering "a person" when you're asked for a name. Which agent, acting on whose behalf, under what identity?
What. The auditor needs the before and the after — $2,500 and $5,000, side by side — not the fact that "a change occurred." Impact lives in the delta.
When. A timestamp you can trust and place in order against everything else that happened that day.
Why allowed. The authorization that made this change permissible — the approval, the policy, the guardrail it cleared on the way to production.
"The AI wrote it" answers none of the four. It doesn't even partially answer one of them; it names the tool where the auditor asked for a fact. Had a person made the change, at least a fragment of each answer would exist somewhere by default — a name on a commit, a reviewer on a pull request, a ticket, a thread where someone signed off. The agent left the rule changed and nothing else behind.
Why AI authorship raises the bar instead of lowering it
Here's the part that runs against intuition. When a person changes a governed rule, a surprising amount of provenance comes along for free. Their name is attached to the work. They opened a ticket, or someone reviewed the change with them, or there's a message where a manager said go ahead. In the last resort, you can put them in a room and ask what they were thinking. None of that is deliberate audit infrastructure. It's the ambient trail a human being leaves just by moving through your process.
An agent leaves none of it. It doesn't file its own ticket, doesn't loop in a reviewer out of habit, and can't be deposed about its intent six months later. So the speed goes up and the ambient provenance drops to zero at the same moment. The examiner's demand didn't shrink because a machine is faster — the informal supply that used to quietly meet that demand disappeared. Everything the human used to produce by accident, the system now has to produce on purpose. That is the bar going up.
None of this is an argument against letting agents author changes. The speed is real and worth keeping; an agent that can adjust a rule in seconds is a genuine advantage. The point is narrower, and it's structural: the faster the authoring gets, and the less human ceremony surrounds it, the more the burden of proof shifts onto the system that records what happened.
The frameworks already decided this, and they don't make an exception for AI
Change control and audit trails aren't a new obligation someone invented for AI. They're a standing feature of the frameworks a regulated business already lives under, and they were written long before an agent could touch production.
SOC 2's change-management criterion, CC8.1, requires that an organization authorize, document, test, and approve changes before they reach production. In practice, an auditor pulls a sample of changes and traces each one back to an approved request — and a change that reached production with nothing authorizing it is a finding. Notice what's being tested: not whether the change was a good idea, but whether it was authorized and recorded.
HIPAA's Security Rule requires audit controls under § 164.312(b) — mechanisms that record and examine activity in systems that hold electronic protected health information — alongside a standing duty to actually review that activity under § 164.308(a)(1)(ii)(D). ISO 27001:2022 carries the same two ideas as named controls: change management in Annex A 8.32, where changes must be planned, assessed, authorized, tested, and documented, and logging in Annex A 8.15, which requires you to produce, protect, and review records of what the system did.
Read them back to back and the pattern is hard to miss. Every one is written in terms of the change and the record, never the author. Not one of them says "unless a model generated it." The frameworks are actor-agnostic by design — they care that a change to a governed system was authorized, documented, and reviewable, full stop. An agent doesn't inherit an exemption your engineers never had. It walks into a standard that was already there, carrying less of its own paperwork than a person would.
What your backend has to record before an agent touches a rule
Turn the four facts into system requirements and you get a short, uncompromising list — four things the backend has to capture at the moment of change, not reconstruct under deadline afterward.
The actor, resolved to an identity. The agent is a first-class actor with a stable identity of its own, and the record has to reach past the agent to the authorization behind the run: the human who initiated or approved it. "System" is not an actor. A blank field is not an actor.
The before and the after. Not "the eligibility rule was modified," but the prior value and the new value, stored side by side and diffable. $2,500 became $5,000. The auditor reconstructs impact from that delta, so the delta has to be a first-class thing the system kept — not something you reverse-engineer later from two backups and a good guess.
A timestamp you can defend. Synchronized and ordered against every other change, so "when" survives contact with an examiner who's building a timeline.
The authorization. The specific thing that made this actor's change allowable — the approval it cleared, the environment it was permitted to run in, the guardrail it passed. Teams skip this one, because when a human makes the change the authorization lives comfortably in their head and their manager's memory. When an agent makes it, there is no head to check. The permission has to be data.
And all four have to be durable and queryable — something an auditor can walk through directly, without taking anyone's word for it. A log you assemble the week after the examiner emails you isn't provenance. It's a story you're telling about the past, and refusing to take your story on faith is the entire job an auditor was hired to do.
Provenance has to be structural, or it isn't provenance
There's a trap hiding in that list. If the audit trail is something you bolt on — a logging call an engineer remembers to add, a table someone writes to by convention — then it's exactly as reliable as the discipline of whoever wired it up. It can be skipped or quietly switched off, and you won't know until you go looking for a record that was never written. Provenance you have to remember to produce is provenance you will eventually forget to produce.
The way out is to make the record a property of where the logic lives, rather than a chore stacked on top of it. This is the whole idea behind a backend where what you see is what runs. When your business rules live as visually auditable function stacks instead of generated files only a model can read, "what changed" is legible by construction — a compliance lead can read the rule that governs a claim without an engineer translating it first. When the backend traces every request, logs errors, and captures agent telemetry, an agent's run is visible while it happens, not excavated from wreckage afterward. Separate environments and role-based access decide who and what may change a rule, and where — enforced, not asserted. Retained prior releases make the before-and-after and the rollback real artifacts instead of promises. And when SOC 2, HIPAA, ISO 27001, and GDPR are part of the platform rather than retrofitted after something already shipped, the controls the auditor asks about are the same controls that were running the whole time.
That's the role a backend like Xano is built to play here: the structural home where the actor, the before-and-after, and the authorization are recorded as a byproduct of how a change is made — so provenance becomes the path of least resistance instead of a tax paid under pressure. The agent still moves fast. The record just stops depending on anyone remembering to keep it.
The question isn't whether AI wrote it
When the examiner asks about that threshold change, "an agent wrote it" is going to land the way "I don't remember" would — as a gap where a fact belongs. The examiner doesn't care whether a person or a model authored the rule. They care whether you can show what it did and who let it happen. A backend that can answer that lets an agent move as fast as it likes against governed logic, because every fast change drops into a record someone can walk. A backend that can't answer it has no business letting an agent near a rule that decides a payout or a diagnosis — not because the agent can't be trusted, but because "trust me" is the one answer an audit exists to reject.
The speed was never the thing at risk. The trail behind the speed was. Build the trail into the backend, and you get to keep both.
See what a governed backend looks like when the audit trail is structural instead of bolted on. Start building on Xano for free, or request a demo to walk through how it maps to your own compliance obligations.
---
This article is for general informational purposes only and does not constitute legal, regulatory, or compliance advice. Requirements under SOC 2, HIPAA, ISO 27001, and other frameworks depend on your jurisdiction, your industry, and the current version of each standard, and they change over time. Consult your own legal counsel, compliance team, and auditor before relying on any control or practice described here to satisfy a regulatory obligation.
