2026-07-28 · Architecture

DORA turned your LLM vendor into an ICT third party

The Digital Operational Resilience Act has applied since January 2025, and Articles 28 to 30 govern how a financial entity manages ICT third-party risk. Nothing in it mentions language models, which is precisely why it applies to them. An LLM provider or a hosted agent platform supporting a critical or important function is an ICT third-party service provider, with everything that follows.

The oversight layer landed next. In November 2025 the European Supervisory Authorities designated the first critical ICT third-party providers, nineteen of them, including AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix and Swift, and those providers came under direct EU oversight from 2026. Almost every production AI workload runs on one of them. Even an AI vendor not designated in its own right is typically sitting on one that is.

Your stack, re-read as a dependency graph #

A typical hosted agent deployment has more third parties in the critical path than the architecture diagram suggests:

• The agent platform vendor, holding your conversations and your configuration.
• The model provider, receiving your prompts, which contain your customer data.
• The cloud the platform runs on, frequently a designated critical provider.
• The observability, vector, and storage services the platform uses, which you may never have been told about.

Each is a register entry if the function is critical or important. Each needs diligence, contract terms, and an answer to the resilience questions. And the fourth category is the one that causes trouble in an audit, because subcontracting chains are exactly what Article 30 asks you to be able to describe.

Register entries and pre-contract diligence #

The mechanics are unglamorous and they are where projects stall. You maintain a register of ICT third-party arrangements, classify which support critical or important functions, run diligence on those before contracting, and meet specific contract content rules: access and audit rights, subcontracting conditions, service levels, incident cooperation, data location, and termination rights.

Two of those are consistently hard to get from an AI vendor. Audit rights over a multi-tenant inference service tend to arrive as a certification rather than a right. And data location commitments get vague once you follow the chain to where inference actually runs. Neither is unreasonable of the vendor. They are simply facts about the delivery model, and they belong in your risk assessment rather than in a hopeful clause.

Concentration risk is the quiet one #

Concentration risk in AI is easy to underestimate because the concentration is layered. Ten agent products from ten vendors can resolve to two model providers running on one hyperscaler. A rate limit, a policy change, or a regional outage at that layer takes out capabilities you had assumed were independent.

Running the agent platform yourself does not eliminate the model dependency, but it separates the layers so they can fail and be replaced independently. If the platform is a library inside your own perimeter and the model is reached through an OpenAI-compatible gateway you operate, then switching provider is a configuration change rather than a migration. The gateway playbook covers pointing at LiteLLM, vLLM, or a Bedrock or Azure proxy inside your VPC, with bounded retries and per-gateway timeouts.

The exit strategy test #

DORA expects exit strategies for critical arrangements, and it is the requirement that most cleanly separates architectures. Ask four questions about any agent platform:

1. Where is the conversation history, and in what format? If the answer is a vendor database with an export endpoint, your exit depends on that endpoint working at the moment you need it most.
2. Where is the agent definition? Behaviour encoded in a vendor's visual builder does not port. YAML and Markdown in your own repository does.
3. Where is the audit trail? This is the one with a retention obligation measured in years, potentially outlasting the vendor.
4. How long would a switch take, and have you tested it? An untested exit plan is a document, not a strategy.

A self-hosted platform answers all four structurally. The institution operates it on infrastructure it controls, stores data in open formats, and does not depend on a vendor's continued cooperation to keep running, which is what makes the exit credible rather than asserted.

What this implies for how you build #

• The platform is a library, not a service. pip install into your own runtime, no control plane, no outbound telemetry you did not configure. Your register entry for the platform is a software dependency rather than an ICT service arrangement.
• The model is behind a gateway you own. One place where provider credentials live, one place to swap providers, one place to enforce timeouts and fallbacks.
• The data stores are yours. Sessions, contact ledgers, and the audit chain in your SQLite or Postgres, under your backup and retention policy.
• The configuration is in your repository. Agents as YAML plus Markdown means the definition is versioned, reviewable, and portable, and the config hash in the audit chain ties each conversation to an exact revision.
• Observability goes to your stack. OpenTelemetry spans into whatever collector you already run, with only metadata leaving the process by default rather than message bodies.

Open source matters here for a specific reason rather than a philosophical one: you can read the code that handles customer data, your security team can review it, and the dependency does not disappear if the company does.

What self-hosting does not fix #

Worth being honest about the residual.

• You still depend on a model. Unless you serve open weights yourself, there is a provider in the path, and it is a register entry. Self-hosting narrows the dependency to inference rather than to your whole agent estate.
• You inherit the operational burden. Patching, capacity, incident response, and resilience testing become yours. DORA has opinions about all of them.
• Your cloud is still your cloud. Running in your own account on a designated critical provider is still concentration on that provider.
• Nothing here is a compliance guarantee. Architecture makes the obligations satisfiable. It does not satisfy them.

The argument is narrower than "self-host everything". It is that the exit strategy question has a structural answer and a contractual one, and only the structural one survives the scenario where the vendor is the problem.

Related: the AI Act obligations that sit alongside this, and the audit playbook for the retention side.

← All posts