Category: AI Regulation | Reading time: 9 minutes

A firm decides to adopt an AI assistant. There is a paper, a risk assessment, a discussion about the vendor's data handling, and eventually an approval. The AI register gains one entry.

What gets deployed is not one thing. It is a set of connections. The assistant reads a document store. It reaches a CRM. It sends through an email system. Somewhere in a pilot that never formally ended, a team wired it to a payments provider, or an external model, or a spreadsheet on a shared drive that turned out to be the only place a particular dataset lived.

The register still says one entry.

This is not a new problem in technology. Infrastructure teams have called it API sprawl for years: the uncontrolled growth of interfaces across an organisation, created without central visibility, consistent standards, ownership or lifecycle management. What is new is that AI systems accumulate connections faster than conventional software, because the value of an assistant is proportional to what it can reach. Every integration makes it more useful. Nothing in the approval process counts them.

The failure modes are familiar to anyone who has run an estate.

Multiple integrations doing the same job, built by different teams who did not know the other existed. Old connections still live after the system they served was replaced, because switching something off requires knowing it is there. Credentials issued during a proof of concept and never rotated. Inconsistent authentication, because each integration was built to its own standard. No complete inventory. Owners who have left.

None of these announce themselves. A forgotten integration does not fail. It sits there, authenticated, with whatever access it was granted on the day it was created, until either nobody remembers it or somebody finds it.

The AI-specific version has a sharper edge. An agent chooses which tools to invoke. So the question is not only what it is connected to, but what it might reach in a situation nobody anticipated when the approval was signed.

Three provisions are worth citing, and all three are in force or approaching.

EU AI Act Article 12, record-keeping. High-risk AI systems shall technically allow for the automatic recording of events, logs, over the lifetime of the system. Logging capabilities must enable the recording of events relevant for identifying situations that may result in a risk within the meaning of Article 79(1) or in a substantial modification, for facilitating the post-market monitoring referred to in Article 72, and for monitoring the operation of high-risk AI systems referred to in Article 26(5).¹

Article 12 is one of the most frequently omitted provisions in published mapping tables, which is odd, because it is the natural citation for anything to do with traceability.

EU AI Act Article 72, post-market monitoring. Providers must establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the risks of the system. That system must actively and systematically collect, document and analyse relevant data on performance throughout the system's lifetime. And then the clause that matters here: where relevant, post-market monitoring shall include an analysis of the interaction with other AI systems.¹

That is the regulation naming the problem. Monitoring the model is not sufficient. The interactions are in scope.

The Mills Review, on third-party tools. The FCA's review, published 6 July 2026, found that the existing framework remains sound and did not recommend AI-specific rules. It also recorded that firms will still be responsible for the services they provide, including where they use third-party models or agentic tools.²

Read together, the position is not ambiguous. Responsibility does not stop at the boundary of the thing you procured, and monitoring that ignores interactions is monitoring the least interesting part of the system.

It is tempting to treat this as something for the IT function to tidy up. Three reasons it is not.

Evidence. You cannot evidence oversight of connections nobody has catalogued. If a regulator, an auditor or a client asks what your AI can reach, the answer has to come from a record, not from asking around. Building that record is a governance activity, not a maintenance task.

Approval scope. The approval was granted for a system. If the system's reach changed materially after approval, the approval no longer describes what is running. Whether that constitutes a substantial modification is a real question, and it is one the accountable person has to be able to answer.

Data paths. An assessment done on a model asks what the model does with data. It does not ask which route the data takes to get there. Personal or regulated data flowing through a service that was never assessed is a data protection question, and the assessment that was done does not cover it.

Four steps, and the first one is deliberately small.

Take the entry in your AI register you are least comfortable with. Not the whole register. One entry. For that system, write down every other system it can reach, who owns each connection, what data passes across it, and when it was last reviewed.

Most firms cannot complete that list from memory. Discovering that is the point of the exercise, and it takes an afternoon rather than a project.

Give every connection an owner and a review date. An unowned integration is a liability with no one to raise it. A named owner and a date is the minimum viable control, and it is enough to make the next review possible.

Retire, do not merely disable. A disabled integration with live credentials is still an exposure. Retirement means the credential is revoked, the access is removed and the record says so.

Then make it a question at approval. Add one line to whatever your AI approval process is: what will this system be able to reach, and who approves changes to that. It costs nothing at approval and it is the only point at which the answer is easy to give.

Governance that stops at the model governs the part of the system that came with documentation.

The model was procured, assessed and recorded. The connections were accumulated, one useful decision at a time, by people acting reasonably. Nobody made a bad call. The register simply never had a field for the thing that was growing.

There is a question worth putting to your own firm, and the discomfort of answering it is the finding:

Can you identify every active connection your AI systems hold, who owns each one, what data it touches, what depends on it, and when it was last reviewed?

If not, that is not a failure of controls. It is a gap in what the controls were ever designed to see.

This article is general guidance, not legal advice. Whether the EU AI Act applies to your organisation depends on your role in the AI value chain, the classification of the system and your jurisdiction. How the FCA's requirements apply to a specific deployment is a question for your compliance function and legal counsel.