AI Observability for DORA Compliance
DORA (Digital Operational Resilience Act) has been in force since January 2025. LLM API providers are third-party ICT concentration risks — observability is how you manage them.
99.9%
Uptime SLA
< 5ms
Trace overhead
SOC 2
Certified
OTel
Native
DORA compliance
DORA requires financial entities to manage ICT risk, report incidents, test resilience, and monitor third-party ICT providers. AI systems using external LLM APIs — OpenAI, Anthropic, AWS Bedrock — fall under DORA's third-party ICT concentration risk scope, making AI observability a compliance necessity for EU financial institutions.
DORA and AI systems — what financial entities must manage
Instrument once, observe everything
One OTel SDK, one OTLP exporter. No proprietary agents or middleware sitting in the critical request path.
Eval scores on production traffic
Faithfulness, answer relevancy, and hallucination rates measured on live requests — not just curated test sets.
Compliance evidence built in
Structured audit logs formatted for HIPAA, EU AI Act, DORA, and MAS FEAT. No manual export, no post-processing.
ICT risk management applies to AI systems
DORA applies to the full range of EU financial entities and entered into force on 17 January 2025. The regulation's ICT risk management pillar (Articles 5–16) requires financial entities to maintain a comprehensive framework identifying, classifying, and continuously monitoring ICT risks — including AI system failures, LLM API outages, and model degradation.
LLM APIs are ICT third-party providers
The critical third-party provision (Articles 28–44) is where most AI deployments encounter DORA. OpenAI, Anthropic, AWS Bedrock, and Azure OpenAI are ICT third-party service providers. If a financial entity uses these APIs in a critical or important function (fraud detection, credit scoring, customer service, trading assistance), they become subject to DORA's third-party concentration risk requirements.
Observability as operational evidence
AI observability satisfies DORA's operational monitoring obligations: you need evidence that you are continuously monitoring third-party LLM API dependencies, tracking service degradation, detecting and classifying ICT incidents (including AI hallucination or model failures as ICT incidents), and maintaining an up-to-date register of ICT third-party dependencies.
What is
DORA (Digital Operational Resilience Act)?
A reference overview of DORA (Digital Operational Resilience Act) — its governing authority, enforcement timeline, applicable penalties, and what it requires of AI systems in practice.
Regulation
DORA (Digital Operational Resilience Act)
Authority
European Commission / European Supervisory Authorities (ESAs)
In force
January 2025
Penalties
Member state-specific; critical ICT third-party providers face EU-level oversight fines and potential suspension orders
Requires EU financial entities (banks, insurers, investment firms, payment processors, crypto-asset service providers) to manage ICT risk, report major ICT incidents, perform resilience testing, and manage third-party ICT provider concentration. AI systems using external LLM APIs are subject to third-party ICT concentration risk obligations.
Observability capabilities for DORA compliance
Everything your team needs to instrument, evaluate, and audit AI systems in production — with evidence that satisfies your compliance requirements.
Third-Party ICT Dependency Mapping
Track which LLM API providers (OpenAI, Anthropic, Bedrock) serve which functions, with SLA and concentration exposure dashboards.
ICT Incident Detection and Classification
Classify AI system failures — model degradation, API outages, hallucination spikes — as ICT incidents with the timing and impact data DORA Article 18 requires.
Resilience Testing Evidence
Traces from AI system resilience tests (failover scenarios, fallback model activation) that satisfy DORA's TLPT (Threat-Led Penetration Testing) documentation requirements.
Regulatory Incident Reporting
Structured incident export aligned with DORA's major ICT incident reporting templates to the competent authority (ECB, EBA, ESMA, EIOPA depending on entity type).
How observability satisfies DORA (Digital Operational Resilience Act)
How AI observability satisfies DORA obligations
| Requirement | Observability capability | Notes |
|---|---|---|
| Art. 8 ICT Asset Management | AI system and LLM API dependency register from trace metadata | Auto-discovered from span telemetry — no manual inventory needed |
| Art. 10 ICT-Related Incident Management | AI incident detection, classification, and structured logging | Hallucination spikes and API degradations classified as ICT incidents |
| Art. 19 Major Incident Reporting | Structured incident export with timing, impact, and root-cause data | Mapped to DORA reporting template fields |
| Art. 28 Third-Party Concentration Risk | Per-provider dependency exposure dashboards, SLA deviation alerts | OpenAI/Anthropic/Bedrock exposure visible in real-time |
| Art. 25 Testing of ICT Tools | Test execution traces with before/after performance comparison | Resilience test evidence for DORA Article 25 documentation |
Common questions, answered
Answers to the most common questions about this regulation, what it requires, and how AI observability helps you meet it.
Which financial entities must comply with DORA?
Banks, investment firms, payment institutions, e-money institutions, insurance and reinsurance undertakings, pension funds, crypto-asset service providers, crowdfunding platforms, trade repositories, and central securities depositories — if they operate in the EU or provide services to EU financial entities. DORA applies from 17 January 2025.
Is using OpenAI or Anthropic API a DORA ICT third-party risk?
Yes, if the LLM API is used in a critical or important function. DORA Article 3 defines 'critical or important function' broadly — any function where operational disruption would materially affect financial performance, customer harm, or compliance. Fraud detection AI, customer service AI, credit model AI, and trading assistance AI all qualify. This means the LLM API provider relationship requires a contractual framework aligned with Article 28.
What is an ICT incident under DORA for AI systems?
DORA Article 3 defines ICT-related incident as an event 'compromising the security of network and information systems, the information that such systems process, store or transmit, or the services they provide.' AI system failures qualify: a model producing systematically incorrect outputs (hallucination spike), an LLM API outage affecting critical functions, a prompt injection attack that compromises data integrity — all are ICT incidents under DORA.
How does DORA interact with the EU AI Act?
They overlap for financial entities using high-risk AI systems (e.g. credit scoring AI — Annex III EU AI Act). EU AI Act adds post-market monitoring and human oversight obligations; DORA adds ICT risk management, incident reporting, and third-party concentration management. For a bank deploying an AI-powered credit decisioning system, both frameworks apply — and observability infrastructure satisfies the monitoring obligations under both.
What DORA documentation does AI observability produce?
Perimattic AI Suite produces: third-party ICT dependency register (from span telemetry), ICT incident log (classified by severity and impact), resilience test execution traces, major incident reports in DORA-template format, and operational risk metrics (LLM API availability, latency p99, error rate by provider).
Related pages
Dig deeper into the topics that matter most for your AI observability stack and compliance posture.
Ready to add observability to your AI systems?
Join the waitlist and we'll show you how Perimattic AI Suite traces your agents, catches hallucinations, and proves compliance.