AI in Regulated Industries: Regulators Block the Missing Record, Not the Model

The rule that stops the project is a records rule

In finance, health and legal work, no risk committee has ever told me the model itself was forbidden. What they have told me, usually around month nine, is that there is no record of who approved what.

I have watched this play out in a bank's credit operations, a hospital group's clinical documentation, and a law firm's contract review. None of the three stalled on model quality, and none stalled on hallucination. They stalled because someone in risk asked for the log and the honest answer was that the log could not be produced, because the fields it would have needed were never written. The projects were technically fine. They were unapprovable, which in a regulated business is the same thing as broken.

Regulation rarely forbids the AI system a company wants to build. It forbids the audit trail nobody planned to keep — and that trail is a data-model decision made in week one, not a feature added at month nine.

Which obligations actually apply to an AI workflow?

Most of them predate large language models by years, which is why they get missed when a project is framed as an AI initiative with a compliance appendix bolted on. Read the operative text and you find logging, retention and documentation clauses, not prohibitions on automation.

• HIPAA Security Rule, §164.312(b) requires audit controls that record and examine activity in systems holding electronic protected health information. It specifies the control, not the format, which is why your format still has to answer the question.
• FDA 21 CFR Part 11 sets out what makes an electronic record trustworthy: secure, computer-generated, time-stamped audit trails that identify who did what and when.
• SR 11-7, the Federal Reserve and OCC model risk guidance, expects documentation, validation and ongoing monitoring for models that inform decisions. It is not a ban on models; it is a standard for the file that accompanies them.
• The EU AI Act requires high-risk systems to keep automatic event logs (Article 12), providers to retain them, and deployers to keep logs for at least six months under Article 26(6).
• SOX and SEC rules require audit workpapers retained for seven years; FINRA Rule 4511 requires broker-dealer books and records for six. If your AI event log is the only evidence that a decision happened, it is a book and record, whatever your team calls it.

The AI Act's calendar deserves an honest caveat. The high-risk obligations were scheduled to apply from 2 August 2026, and the Commission has proposed delaying parts of that, so the date is genuinely in flux and anyone quoting it to you with confidence is overstating what is settled. The logging requirement is not in flux, and neither is the mechanism: you cannot retroactively log a decision that was made last year. Plan against the record, not the date.

Why can't the audit trail be added later?

Because an event log can only contain what the schema already carried at write time.

You can reconstruct a total from history. You cannot reconstruct an author. If the row recording a status change carried a service account and a timestamp, then a year later the truthful answer to "who approved this adjustment" is "the integration account" — and that answer ends a review badly, because it identifies a credential rather than a person who exercised judgement. The same applies to the model: if the request never recorded which model and which prompt version produced the output, and the provider later retires that version, then no amount of forensics will say what the system was when the decision was made. And if the retrieved clause was not snapshotted at the revision in force that day, you cannot show what the decision rested on.

The least obvious version of this is that the model's explanation is not a record. A generated rationale is another generated sentence, produced by the same thing being audited. It is useful to the reviewer in front of it and worthless in the file.

This is why the write path matters more than the log format. A system that can only propose, with a separate commit path that carries a human actor id, produces two classes of row with two different authors — and it is separating the machine's proposal from the person's commit, so that every change to a system of record has a human author, rather than the layout of a log file, that decides whether the review conversation is short.

What has to be in the event record?

Six fields carry almost all the weight. The absence of any one of them converts a question you can answer in a meeting into a question you cannot answer at all.

Two tradeoffs come with this, and I would rather name them than sell the design.

The first is that a prompt log is a second copy of regulated data. If the log store holds the same client, patient or personnel content as the system of record, it inherits the same obligations: encryption, access control, retention limits, and probably its own audit. Teams that ship prompts to a convenience observability tool have created a copy of regulated data outside the boundary they drew on the whiteboard, and that is the single most common finding I have seen in a design review. Log the identifiers, the versions and the hash; store the content only where you would store the content.

The second is that you will not be able to reproduce most hosted model outputs exactly. Providers retire versions on their own schedule, and routing and sampling are not stable enough to promise determinism. The honest goal is a reconstructable decision, not a reproducible one: keep the inputs, the version and the output, and state in the design document that bit-exact reproduction is not guaranteed. An auditor told this up front accepts it. An auditor who discovers it during a test does not.

What does it cost, and where does the money actually go?

Storage is a rounding error and should not anchor the discussion. Four thousand AI-assisted actions a day at roughly six kilobytes of prompt, output and metadata each is about 24 MB a day, under 9 GB a year before compression. Immutability and retention are configuration on object storage, not a purchase.

Engineering is where the real choice sits. Across three builds where I have added this to an existing workflow — the write gate, the event schema, the retention class — it took between one and three weeks of one engineer's time. That is a fraction of the build, and it is the cheapest week in the project. Retrofitting is a different category of work, because the missing field is in history rather than in code.

The recurring cost is reviewer attention, and it scales with volume rather than with data size. That is the argument for classifying write paths rather than gating everything: gating a draft that nobody sends buys a log line and costs a person's time; gating a regulatory filing is the reason the system is approvable at all. Classifying writes by reversibility and by how many records they touch at once takes an afternoon, and it is the table a risk function is really asking for when it asks for a policy.

What I cannot give you is a credible number for the cost of a finding. Every figure I have seen quoted is either a regulatory maximum nobody pays or an anecdote from another jurisdiction. The mechanism is the part that transfers: remediation after the fact is more expensive than design before it, because it usually means reconstructing decisions from email and memory.

Does this change whether you should build at all?

Sometimes it changes the answer, and that is worth saying plainly. If the process is genuinely rules-based and the regulator wants determinism, a rules engine with a proper log is cheaper to build, cheaper to defend and easier to test than a model with a proper log. The model earns its place where the judgement is fuzzy — extracting terms from a contract, triaging an intake queue, drafting correspondence for a specialist to edit — not where a threshold and a lookup would do.

It should also change the sequencing. Start where the audit trail is easy, which means read-only work first: retrieval, summarisation, extraction, drafting that a person assembles. That is not a soft option; it is how the organisation builds the logging habit, the review discipline and the override-rate measurement while the consequences of a mistake are still small. Only then move to a write path, and move to the irreversible ones last, with the gate intact.

What should be on the page before the first line of code?

Ask for one artefact before you approve spend: a table of every write path the workflow can reach, the fields the event record will carry, and who owns the retention class for each. If that table exists and the built system matches it, most of the compliance conversation is over before it starts, because the questions a reviewer asks are answerable by reading a row. If the table does not exist, the project is not blocked by regulation; it is blocked by a decision nobody has made yet, and that decision gets more expensive every sprint it is deferred. The next time an auditor asks who approved a change, the answer has to be a name in a column, and that column either exists in your schema or it does not.