Most teams introduce agents into delivery first and meet the regulator second. The meeting goes badly for a specific reason, and the reason has little to do with the quality of the code.
An assessor does not open the diff and judge whether it is good. An assessor asks who made the change, who approved it, and what shows that the review took place. Those questions were written for people. When an agent wrote the change, they still apply, and most teams find out at the worst moment that nothing in their pipeline can answer them.
What the standards ask
The change control standards in common use assume an identified, authorised person made each change. PCI DSS 4.0.1 wants traceability over changes to systems in scope. SOC 2 wants an approval trail for change management. DORA wants demonstrable control over ICT change, including who decided and on what basis. None of them forbid an agent writing code. Each of them asks who authorised the change and what proves the review happened.3standards that ask who authorised the change
Read side by side, the 3 regimes are asking for the same 4 facts about a change:
- Who requested it, and what it was meant to do
- Who wrote it, person or session, and under which credentials
- Who reviewed it, separately from whoever wrote it
- Who approved its release, and when
A team with human-only delivery usually answers these from habit. The ticket names the requester. The commit names the author. The pull request names the reviewer. The deployment log names whoever pressed the button. Nobody designed that trail. It accumulated because each tool records the person using it.
Where an agent breaks the assumption
Put an agent into that pipeline and the accumulation stops working. The commit author is a service account. The review was a second session, which is good practice, but the session has no name in the tools an assessor will look at. The merge happened because a check passed. Each step was sound, and the record of it says almost nothing.
A commit authored by an agent, reviewed by a session and merged by a pipeline answers none of the 4 questions. The work may well be better than the human version. What is missing is the recording.
The gap is easy to miss from inside the team because nobody is hiding anything. Engineers know exactly what happened. They watched it. The problem is that their knowledge lives in their heads and in chat threads, and an assessment does not accept either.
The Act asks for the same thing
The EU AI Act sharpens the same point for systems in its high-risk categories. It asks for record-keeping across the lifecycle and for human oversight that works in practice: a named person able to understand what the system is doing, intervene, and override it. Oversight that exists on an organisation chart and nowhere in the workflow does not meet that test.
A delivery process with 4 sign-offs, each owned by a named person and each leaving a recorded trace, is an implementation of that requirement. Nothing about it has to be reinterpreted for the Act. The sign-offs exist because they make the work better, and they happen to be the record the Act asks for.4sign-offs, each with a name against it
Which means 2 things at once. Teams already working this way are closer to compliant than they think, and teams running agents without it are further away than they have been told.
Why reconstruction fails
The usual response to an upcoming assessment is reconstruction. Someone spends the weeks before the audit collecting screenshots, exporting chat history and writing narratives about how changes were approved. It is expensive, and it rarely works as well as people hope.
Reconstructed evidence is assembled by people who already know what the answer should be. An assessor knows that too.
Three things go wrong with it. The records are incomplete, because the decisions that mattered were often made in a call. The records are inconsistent, because each team kept its own. And the narrative is written after the fact by someone with an interest in it being clean, which is exactly the property an assessor is trained to distrust. A record rebuilt months later costs several times what writing it down cost, and still has gaps an assessor will find.
The fix is a log kept with the code
The fix is a log, a set of names and a few checks, all of which live in the repository and run in the agent loop.
- An action log, appended as the agent works, listing files touched and commands run, kept with the code it describes
- A named owner on each gate: the scope, the design, the work plan, the finished change with its tests
- A review by a session that did not write the code, with its findings attached to the change
- Refusals recorded with their reason, so a blocked attempt to read a secret is evidence of control rather than an absence of incidents
- A production gate enforced by the pipeline, which the agent cannot pass and a named person must
None of this needs a policy document to exist. A policy describes intended behaviour. A check in the loop produces the behaviour and the evidence of it at the same moment, and it keeps doing so when nobody is paying attention, which is the condition every control eventually runs under.
Working back from the assessment date
Start with the assessment date, then work backwards. Pick the systems in scope and look at the last 10 changes to them. For each one, try to answer the 4 questions from what the tools recorded, without asking anyone. The changes you cannot answer for show where the trail breaks.
Most teams find the break in the same 2 places. Approval happened verbally, and review was done by the session that wrote the code. Both are cheap to fix before the assessment and expensive to explain during it. Built as the work runs, the evidence costs nothing, and the question that arrives late finds an answer already written down.