The August Deadline Is a Documentation Deadline

TL;DR: Teams preparing for August are mostly working on the model. Read the obligations closely and the model is a small part of it. Risk management, record-keeping, human oversight, accuracy and robustness, post-market monitoring. These are questions about a system in operation, and the honest answer to most of them is a query against a ledger nobody is currently keeping.

The thing everyone is preparing for is not the thing being asked

Sit in on a readiness programme and you will hear about evaluation harnesses, bias testing, red-teaming, model cards. All useful. All aimed at a question the regulation asks once and then moves past.

The bulk of what a high-risk classification demands is not “is this model good”. It is: what did the system do, on whose instruction, inside what limits, and can you show me. Those are properties of a deployment, not of a set of weights. You can score perfectly on every benchmark you own and still have no answer.

The gap is not technical sophistication. It is that nobody wrote down the authority.

Four questions, and where the answers actually live

Who is accountable for this system? Not the team. A person. Most organisations can name a business owner for an application and cannot name one for the specific autonomous behaviour inside it. When an agent takes an action, the record needs a human at the end of the chain, and “the platform team” is not one.

What was it allowed to do at the time? Note the tense. Not what it is configured to do today. What the configuration was at the moment of the decision under review, which may be eighteen months ago and three releases back. Systems that reconstruct this from a config repository are guessing, competently.

What did it refuse? This is the question teams are least ready for, and the one that carries the most weight. A control you cannot demonstrate operating is a control you have described. Refusals are the demonstration. An agent stopped 40 times last quarter is evidence; an agent that was never stopped is either perfectly bounded or not bounded at all, and from the outside those look identical.

What happened after something went wrong? Post-market monitoring is a continuous obligation, not a report. It assumes you noticed.

Why “we log everything” is not the answer

Every organisation asked about this says they have logs. They do. Logs are the wrong shape for the question, for three reasons that are structural rather than a matter of effort.

Logs record what happened, not what was permitted. Reconstructing authority from an application log means inferring intent from effect, which is exactly the inference an auditor will not accept.

Logs record successes. The refusal that matters most is usually the one that never became an event, because the code path that would have logged it returned early.

Logs are mutable and unsequenced. “Nothing is missing” is not a claim a log file can support. A gap in a sequence is detectable; a gap in a log directory is invisible.

The part that is genuinely hard

Here is the uncomfortable bit, and the reason this is a documentation deadline rather than an engineering one: most of the work is deciding what the agent may do. Not implementing the check. Deciding.

Somebody has to say that the payments agent may move up to a specific amount, on behalf of a named function, during defined hours, for a defined purpose, and that after that limit it stops. That sentence does not exist in most organisations. It has never had to. A human in the same role operated under judgement, seniority and a mandate everyone understood without writing down.

Software has no judgement, no seniority, and no sense of when to ask. The mandate has to become data.

Teams that start in August will spend the first six weeks in meetings about that sentence, not in code. Teams that start now will spend the same six weeks, just earlier.

Start with the inventory, because you cannot bound what you cannot list

The first deliverable is unglamorous: a list of the autonomous behaviours in production, each with a named owner. Most organisations discover two things doing this.

The list is longer than expected, because “agent” turns out to include a lot of scheduled automation nobody classified as AI, some of which now calls a model.

And a meaningful fraction has no owner. Not a disputed owner. None at all. The person who built it left, the team was reorganised, and it has been running quietly ever since. That finding is worth the exercise on its own, and it will appear in your readiness assessment whether or not you go looking for it.

Enforcement is a dial, and turning it is a separate decision

A programme that promises to start blocking actions in August will not happen, because no operations team will accept a new refusal path in production against a deadline.

The way through is to separate recording from refusing. Run the checks and record what they would have done, changing nothing. That gives you two things immediately: a real inventory of what your agents are actually doing, and a defensible position that the control exists and is being calibrated. It also gives you the argument you need internally, because the first week of data usually contains at least one behaviour nobody knew about.

Then move the dial, per grant, when the team that owns it agrees. Nobody has to flip an estate from nothing to blocking in one step, and any vendor suggesting otherwise has not deployed into a bank.

What this looks like when it is working

An examiner asks about a decision from fourteen months ago. Someone runs a query. It returns the action, the grant it drew on, the human who signed for that grant, the enforcement mode in effect at that moment, the limits that applied, and, if it was stopped, the gate that stopped it and why.

No reconstruction. No warroom. No fortnight of correlating three systems.

That is the deliverable. The model was never the hard part.

The bottom line

August is not asking you to prove your model is good. It is asking you to prove you were in control of what it did. Those are different projects, and only one of them is mostly documentation. That is the good news. Documentation is a thing you can start on a Tuesday.