DORA makes your AI coding assistant a compliance object twice: once as an ICT third-party service you have to register and manage, and again in every change it writes into your systems. Procurement owns the first. Nobody owns the second.
That split is the risk. The register of information says you use the tool. Your change records say an engineer made each change. Nothing connects the two, so when a supervisor, an incident, or your own risk function asks what the tool actually touched, the only answer is someone reading commit history by hand.
What DORA expects of ICT change management
DORA has applied since 17 January 2025 to banks, insurers, investment firms, payment and e-money institutions, and most other EU financial entities. Its ICT risk management rules expect changes to ICT systems, software included, to be recorded, tested, assessed, approved, implemented, and verified in a controlled way. A delegated regulation on the ICT risk management framework fills in the procedure: clear roles, separation between the people who make changes and the people who approve them, fallback procedures, and documented handling of emergency changes.
DORA is technology neutral. It does not prohibit code written by AI and does not exempt it. A change an agent wrote enters the same procedure as any other, and the procedure has to keep working at the volume agents produce. If your group also reports under SOX, the same changes face a separation of duties test, covered in SOX change control when an AI agent writes the code.
Is an AI coding assistant an ICT third-party service under DORA
Usually, yes. A coding assistant delivered as a service under a contract is an ICT service from a third-party provider. DORA expects financial entities to keep a register of information on their contractual arrangements for ICT services, to assess the risk each provider brings, and to plan how they would exit. Arrangements that support critical or important functions carry more detailed contract and oversight requirements. In November 2025 the European Supervisory Authorities designated the first critical ICT third-party providers, bringing the largest providers under direct EU oversight.
Where the evidence gap opens
Third-party risk asks what happens if a provider fails, changes, or has to be replaced. For a coding assistant, the answer depends entirely on what it wrote. Three questions your ICT risk function could reasonably ask:
- A model version shipped a class of bug. Which production changes did that tool and model write while it was live?
- We have to exit the provider. Which systems carry its code, and which teams depend on it to keep delivering?
- An incident traces back to a change. Did a person or an agent write it, and did it pass the same review and testing as everything else?
Each question joins the register to the change records. Without that join, every answer is a manual investigation run after the fact, often against an incident reporting clock.
What to put in place
- Record the tool and model on every agent change. The change record should say which assistant and which model wrote it, next to the ticket, the reviewer, and the test results.
- Keep agent changes in the normal procedure. No side lane, and no use of the emergency change path to clear an agent backlog.
- Link the register to the change population. For each AI tool in the register, be able to list the systems and changes it touched. That is what turns an exit plan from a document into something you could execute.
- Watch the procedure's capacity. When approvals start to wait because agents multiplied the number of changes, the control is under strain before anyone breaks it.
Building the join
This is the part Bloomfilter does. It connects agent sessions, with the tool and model behind each one, to the work items, pull requests, and reviews in your change process, so every AI tool in your register has a change population you can query. When an exit plan or an incident asks what the tool touched, the answer is a list, not an investigation. See how it works across regulated software.