DORA Article 28 for AI: The 2026 ICT Register Your OpenAI Subscription Cannot Pass

Companion long-form on X, read the X Article version

DORA registers of information list every ICT third-party arrangement, AI vendors included, at banks, asset managers, insurers, and payment institutions. The compliance work behind them is often excellent; the weak point is that the underlying contracts with AI vendors were never designed to live inside a regime like DORA.

This piece is for the CTO, CIO, Head of Compliance or DPO at an EU financial entity who already knows DORA exists, has a register, and is now staring at the AI columns wondering whether OpenAI, Anthropic, Microsoft 365 Copilot, or Mistral La Plateforme will hold up when BaFin or the ACPR knocks on the door. Short answer: not in their current shape. Long answer: there is a path, and it goes through hardware-level evidence rather than another round of contract redlines.

Who DORA Actually Catches, And Why AI Got Pulled In

DORA's scope under Article 2 covers around 22,000 financial entities across the EU: credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, central counterparties and trade repositories, insurance and reinsurance undertakings, IORPs, credit rating agencies, crowdfunding service providers, and administrators of critical benchmarks. Plus, and this is where it widens, ICT third-party service providers when they are designated as critical.

Until late 2025 there was a debate about whether AI/SaaS vendors fell under DORA at all or only under sectoral guidance. The practical map for AI in financial services now looks like this:

• Customer-facing assistants. Chatbots that answer authenticated customer questions, suggest products, or surface account information. Always Article 28 third parties; usually classed as supporting an important function.
• Underwriting and credit-decision assist. LLMs that summarise applications, extract from loan files, or pre-score. Almost always supporting a critical or important function. Often also high-risk under AI Act Annex III.
• Trading-floor research and surveillance. LLMs that summarise filings, flag suspicious orders, or draft client communications. Critical-or-important when they inform regulated activity.
• Compliance, AML, KYC. LLMs reading documents, flagging risk, drafting SAR/STR narratives. Default to critical because of supervisory exposure.
• Internal "copilots." Microsoft 365 Copilot, Glean, Notion AI, and similar reading internal data on behalf of staff. In scope as soon as the data they touch supports a regulated function, which it almost always does.

If any of those describe your shop, you owe a fully populated Article 28 register row per vendor instance, with the sub-processor chain, the criticality classification, the contract clauses, the exit plan, and the supporting evidence. The fastest self-check most compliance teams use:

# DORA Article 28, ICT third-party register self-check.
# If ANY answer is "no", your AI vendor entry will fail the BaFin sample audit.

vendor = current_ai_vendor()  # OpenAI, Anthropic, Microsoft 365 Copilot, Mistral...

questions = [
    "Can you produce a SIGNED list of every sub-processor and physical location?",
    "Is the contract enforceable under EU law with a named EU controlling entity?",
    "Does the contract grant unrestricted on-site audit rights to YOU and YOUR regulator?",
    "Is there a documented exit plan testable within the supervisory window?",
    "Can the vendor evidence, cryptographically, that your data is processed in the region you contracted?",
    "Does the contract name a specific CRITICAL or IMPORTANT function status under DORA?",
]

if not all(answered_yes(questions)):
    print("FAIL: Article 28 register row will be flagged.")
    print("Expected outcome at next BaFin/ACPR/MFSA sample: formal finding,")
    print("remediation deadline, and management body sign-off liability.")

Why Standard AI Vendor Contracts Fail Article 28

Article 28(2) and 28(7) are where audits stall. Together they require: a written contract with a specific list of clauses, an enforceable EU-law forum, full audit rights for both the financial entity and its competent authority, geographic transparency including sub-processor locations, contractual security obligations proportionate to the function, and a tested exit plan. The standard enterprise AI DPA hits roughly three of those cleanly.

1. Audit rights. The boilerplate is "audit reports made available on request, with reasonable notice, not more than once per year." DORA expects on-site audit access for the competent authority. Most enterprise AI vendors will not sign that unmodified, and the negotiated middle ground (third-party audit reports plus questionnaire) is exactly what BaFin started flagging in 2025 sample audits.
2. Sub-processor transparency. The standard pattern is "current list at this URL, we will notify you of changes." A DORA register row needs a point-in-time-signed sub-processor chain, geographic pinning per sub-processor, and a mechanism to evidence that the contracted region was actually used at inference time. URL change-logs do not produce evidence; they produce promises.
3. Cybersecurity proportionality. Article 28(7)(d) wants security measures "proportionate to the criticality." For critical functions touching personal, regulated, or commercially-sensitive data, the operator-trust threat model matters. ISO 27001 and SOC 2 Type II are necessary but increasingly read by supervisors as floor, not ceiling. Hardware-rooted tamper resistance is now what differentiates a passing register row from a flagged one.

The good news: none of these are unfixable. The bad news: they are not fixable through another round of redlines on a SaaS contract. The contractual layer needs to be backed by a technical layer that produces evidence the supervisor can verify independently.

What an Audit-Grade Register Row Actually Looks Like

Article 28(3) requires financial entities to maintain a register of information at entity, sub-consolidated and consolidated level. The harmonised template the European Supervisory Authorities published in 2024 has 14 tables and around 400 fields. The painful columns for AI vendor rows are the function-criticality columns, the sub-processor chain columns, and the "ICT security measures" columns, the last of which has historically been a free-text paragraph that supervisors are now treating as a evidence claim.

Operationally, the evidence you can produce today comes from a few commands, run inside your Confidential VM and then on your own machine:

# Inside your Confidential VM: generate both proofs on a challenge you choose
# The image ships without pip: install it first
curl -sS https://bootstrap.pypa.io/get-pip.py | python3 - --user --break-system-packages
python3 -m pip install --user --break-system-packages "voltage-verify[attest]>=0.2.1"
export PATH=$HOME/.local/bin:$PATH
voltage-verify manifest --challenge auto -o manifest.json
sudo env PATH=$PATH PYTHONPATH=$(python3 -c 'import site;print(site.getusersitepackages())') \
  voltage-verify attest --manifest manifest.json --mode single-gpu -o bundle.json

# On your own machine: check the Intel TDX quote and the NVIDIA report
pip install "voltage-verify>=0.2.1"
voltage-verify verify bundle.json --challenge <the challenge printed above>
# RESULT: VERIFIED

What those commands give you: an Intel TDX quote and an NVIDIA GPU report that the auditor can verify on their own laptop without any cooperation from VoltageGPU, since the signature chains roll up to Intel's and NVIDIA's roots of trust, not to us, both bound to a challenge you chose, so they cannot be replayed from another session. What they do not give you: a region record, or a binding to a specific model and prompt template; those stay in your contract and your register row.

Penalties

Penalties for financial entities are set by each Member State (DORA, Article 50). The one amount the regulation fixes itself concerns critical ICT third-party providers: a periodic penalty payment of up to 1% of their average daily worldwide turnover, for up to six months (Article 35).

A Practical Roadmap For The Next 90 Days

1. Inventory every AI vendor that touches a regulated function. Use the register self-check above. Rank by criticality. For most mid-market firms this is a one-week exercise that turns up two to three times more vendors than the official list.
2. Triage the contracts. Group vendors into "contract is fixable with redlines," "contract needs technical compensating control," and "vendor cannot satisfy Article 28 at any criticality." The third bucket is where most of the surprise lives.
3. Move critical-function inference behind an attested enclave. With VoltageGPU Confidential VMs you run the workload inside a trust domain you control and generate the TDX quote and the NVIDIA GPU attestation yourself; the inference API does not return an attestation with each request. With Azure Confidential Computing it is heavier and the unit price is higher (NCC H100 v5 lists at $8.90/hr, 12 Sept 2026); AWS Nitro Enclaves isolate CPU workloads only.
4. Wire the register row to evidence, not narrative. Every register row for a critical AI function should reference an artifact you can replay: an attestation quote, a model-artifact hash, a region-pinning record. Free-text paragraphs are now what gets flagged.
5. Test the exit plan. Article 28(8) requires a documented and tested exit strategy. "We could fall back to GPT-3.5" is not tested. Run a half-day game-day with the regulated function team and document the timing.
6. Brief the management body. Article 5(2) makes ICT risk management a board-level responsibility. Personal liability is real. The brief should be in the language of the register findings, not in the language of MLOps.

What This Article Does Not Solve (Pratfall, Honest Edition)

I would rather you know the limitations now than discover them mid-audit:

• Confidential computing does not produce your exit plan. Article 28(8) is operational. If you cannot evidence a tested fallback, no attestation quote will fix it.
• It does not eliminate concentration risk. Article 29 wants you to think about supplier-level dependency. Moving every critical AI workload onto one TEE provider is its own concentration story; we expect supervisors to start asking about this in late 2026.
• The CTPP designation regime is still ramping. If your AI vendor is eventually designated a Critical ICT Third-Party Provider under Article 31, the oversight-fee bill and lead supervisor regime will reshape the contract again.

Who Should Read This Twice

• Heads of Compliance, DPOs, and Risk Officers at EU credit institutions, insurers, asset managers, payment institutions, and crypto-asset service providers.
• CIOs, CTOs, and CISOs who own the ICT third-party register and now need to retrofit AI vendors into a regime that did not anticipate them.
• Founders selling AI products into EU financial services, your buyers will increasingly require DORA-grade evidence as part of vendor onboarding from mid-2026, and a vendor that ships register-ready evidence wins.

Two starting points if you want to go deeper: our piece on the EU AI Act high-risk deadline for the high-risk AI angle, and the GDPR & AI 2026 piece for the privacy-side of the same conversation. All three regimes converge on the same evidence pipeline.

FAQ