A bank that uses an AI tool in a credit decision must document it three times: for the AI Act, for DORA, and for its data protection officer. Most of that documentation depends on one question: what does the vendor hold, and what does it operate? If the answer is nothing, the bank documents facts about its own infrastructure. If the vendor hosts the system, the bank documents clauses in someone else’s contract.
The bank is the deployer
The AI Act classifies as high-risk any AI system that assesses the creditworthiness of individuals or sets their credit score, fraud detection excepted.[1] The bank operating such a system is its deployer. Article 26 sets out what that entails: use the system according to the provider’s instructions, assign human oversight to people with the competence, training and authority to exercise it, monitor its operation, and keep the logs it generates for at least six months, where those logs are under the bank’s control.[2]
The provider owes the rest. Article 12 requires a high-risk system to record events automatically throughout its lifetime, and Article 13 requires it to come with instructions for use.[3] The deployer’s file therefore starts with two documents from the vendor: the instructions, and a description of what the system records and where.
“Under their control”
Article 26 asks the deployer to keep the logs to the extent they are under its control.[2:1] The whole file turns on that clause. If the logs sit in the vendor’s cloud, the bank’s control rests on a contract. If they sit on the bank’s own servers, the bank can show them to a supervisor without asking anyone.
The logs also need the right content. A record of prompts and model outputs shows what the model said. A supervisor asking why a loan was refused needs to know what was done: which data was read, which rule applied, who approved. A trail that can be replayed is evidence. A trail that can only be read is a narrative.
Human oversight needs a name
Article 26 requires oversight by natural persons with authority.[2:2] Someone approving several hundred machine proposals a day is not overseeing anything.[4] The oversight the bank documents must be a named person, with the authority to reject a proposal and the time to examine it.[5]
If the system attaches a name to every action by design, the oversight section simply describes how it works. If names are added afterwards through a review procedure, the supervisor will ask how often that procedure is skipped.
DORA: the register, the contract, the exit
DORA requires financial entities to manage ICT third-party risk and to keep a register of every contractual arrangement for ICT services provided by a third party.[6] Those contracts must cover where the service is provided and where data is processed and stored, the entity’s rights of access, inspection and audit, and termination rights with an exit strategy.[7]
For a hosted AI service, each of those provisions must be negotiated, because each concerns something the vendor holds. For software the bank installs and runs on its own infrastructure, the register entry still exists and the compliance function decides how to classify it. The content is simpler. The data is in the bank’s own datacentre. The audit right is exercised by the bank’s own operations team on its own logs. The exit strategy is trivial, because the software keeps working if the vendor disappears.
Infrastructure vendors reach the same conclusions. Cockroach Labs argues that the database under an AI agent needs append-only audit storage, identity attribution and data residency controls before deployment, because none of it can be added later for an examiner.[8] Teleport argues that agentic systems need audit events tied to a single, immutable identity per action, and that static documentation does not count as evidence.[9]
GDPR: the DPO decides
When a vendor processes personal data on the bank’s behalf, Article 28 of the GDPR requires a contract with specific terms.[10] Software that the bank installs and operates itself, with the vendor holding no data, is a different situation. The data protection officer decides which applies, based on one question: does the vendor ever hold, receive or access the data? A good vendor gives an answer the DPO can verify from the bank’s own network.
Who writes what
- Instructions for use and record-keeping description. Provided by the vendor, kept by the deployer.[3:1]
- Human oversight. Written by the deployer: one name per decision, with authority to refuse.[2:3]
- Logs. Recorded by the system, retained by the deployer when under its control.[2:4]
- Register entry, data location, audit rights, exit strategy. Written by the deployer; their content depends on where the software runs.[6:1]
- Article 28 assessment. The DPO.[10:1]
Each of these is quicker to write when the vendor holds no data, operates nothing, and every action carries a name. Auditability is a competitive advantage: what the market will require within five years can be offered today.[11]
Our position
Galahad does not host your data and runs no control plane your deployment depends on. We do not claim to carry your compliance for you: the file belongs to the deployer. Monarch runs in your infrastructure and your jurisdiction, within the scope of your accreditation, and it complies with the GDPR and the AI Act.
Bring your DPO and your DORA register to the demonstration. See it on your data.
Regulation (EU) 2024/1689, Article 26, obligations of deployers of high-risk AI systems. Source ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Regulation (EU) 2024/1689, Article 12, record-keeping, and Article 13, transparency and provision of information to deployers. Source ↩︎ ↩︎
Regulation (EU) 2022/2554, Article 28, general principles of ICT third-party risk, including the register of information. Source ↩︎ ↩︎
Regulation (EU) 2022/2554, Article 30, key contractual provisions. Source ↩︎
Cockroach Labs, “DORA Compliance for AI Agents: Database Requirements Before Deployment”. Source ↩︎
Teleport, “Guide: DORA Compliance Evidence for Agentic AI”. Source ↩︎
Regulation (EU) 2016/679, Article 28, processor. Source ↩︎ ↩︎