Who signs the breach report when the AI wrote it?
The Senior Managers and Certification Regime is under review, and one of the questions inside its scope matters to anyone automating compliance work: how does individual accountability operate where an AI system performs a function that was previously subject to direct human oversight?
Clarity has been asked for by the end of the year. Until then, firms are on their own.
This is not an abstract problem. If a breach analysis is drafted by a model, reviewed in ninety seconds by a compliance analyst, and reported to a board committee, who has actually formed the view? The SMF16 has signed something. Whether they have discharged their responsibility depends on facts the firm may not have recorded.
The two answers that do not work
The first is to treat the AI as a tool and stop thinking about it. A spellchecker is a tool. Something that reads an IMA, forms a view on whether a holding breaches a restriction, and drafts the explanation is doing work that used to require a qualified person, and the fact that a human clicked approve does not by itself establish that the work was supervised. Accountability does not transfer to an algorithm, and a black box is not a defence — it is an admission that nobody can explain the control.
The second is to require full human re-performance of everything the system does. This is defensible and completely pointless — it costs more than the manual process it replaced and produces reviewer fatigue, which is its own control failure. If your analyst is approving forty machine-drafted assessments a day, the fortieth is not being reviewed.
What does work: write down where the automation stops
The workable position is documentary. For every automated step, a firm should be able to state four things, in writing, before the process goes live:
What the system is permitted to decide. Usually: nothing that carries regulatory consequence. Gathering, comparing, drafting, flagging and prioritising are not decisions. Concluding that a breach is immaterial is.
Where the human checkpoint sits, and what the human is actually checking. “Review the output” is not a control. “Confirm that the cited clause matches the restriction described, and that the affected portfolio list matches the holdings extract” is. The checkpoint has to be specific enough that a reviewer can fail it.
What the reviewer sees. If the interface presents a conclusion with an approve button, you have designed a rubber stamp. If it presents the conclusion alongside the source clause and the underlying data, you have designed a check. This is a control design decision and it is usually made by whoever built the screen, which is a problem.
How you would know if it degraded. Models change, documents change, data feeds change. Sampling, periodic re-performance on a defined percentage, and a trend on override rates. If nobody has overridden the system in six months, either it is perfect or nobody is looking.
The uncomfortable part
Most firms automating compliance processes today cannot produce these four statements for the processes they have already deployed. Not because they were careless, but because the automation arrived as a productivity improvement rather than a change to a control, and productivity improvements do not go through control design.
That is the gap the review is likely to land on. The firms that will be comfortable are the ones that documented the control before they needed to.
A practical starting point
Take one automated or semi-automated process you already run. Write the four statements above on a single page. If you cannot complete any one of them without inventing an answer, that is the piece of work to do next — regardless of what the review eventually concludes.
Ferenc Elekes is the founder of Dobosi Consulting, which builds auditable AI workflows for investment compliance functions. This is a personal view and not legal or regulatory advice.
Related: Oversight and governance.