What does DORA Article 9 require for AI inference?

Article 9 requires continuous monitoring and control of ICT security and prompt detection of anomalous activity. An inference call is an ICT operation carrying the entity's data to an external model, so Article 9 expects the entity to see and constrain that operation. In practice that is a control on the request path that applies policy on what data leaves and which model receives it, enforced before the call completes rather than reviewed afterward.

How do you reconstruct an AI incident under DORA?

Article 17 incident management and the associated reporting require reconstructing what happened and reporting major incidents on a defined timeline. For an AI-involved incident, reconstruction needs a record of the requests and responses around the event, including the calling identity, the prompt content, the model reached, and the output. That record has to be captured at the time of each call, because application logs written for performance omit the prompt and the model identity that the reconstruction depends on.

Does DORA testing cover the AI request path?

For entities in scope of threat-led penetration testing under Articles 24 to 27, a complete program exercises the AI estate, including whether a tester can reach an unapproved model or exfiltrate data through a prompt. Testing those paths assumes an enforcement control exists on the AI traffic to probe. A deployment with no control at the inference layer offers the testing program nothing to assess there, which the resilience assessment has to note as a gap.

DORA AI Inference Controls: ICT Risk Requirements at the AI Request Layer

Q: Is DORA only about the ICT third-party register?

No. The register and exit-strategy obligations in Chapter V are one part, and Chapter II's ICT risk management framework and Chapter IV's resilience testing reach the running systems themselves. For an AI deployment that means the protection, detection, incident, and testing requirements attach to the live inference traffic, not only to the contract with the model provider. Entities that treat DORA as a documentation exercise around vendors leave the operational chapters unaddressed at the layer where the AI system actually runs.

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied to EU financial entities since January 17, 2025, and most of the AI compliance discussion around it stops at the third-party register. That register matters, and it is Chapter V. The chapters that reach the running AI system are earlier: the ICT risk management framework in Chapter II and the resilience testing in Chapter IV. When a bank or insurer runs an LLM in a live workflow, DORA's protection, detection, incident, and testing requirements attach to the inference traffic itself, not only to the contract with the provider. I want to walk the DORA obligations that land on the AI request path, and show what a financial entity has to enforce and record on that traffic to satisfy them.

Protection and prevention: Article 9

Article 9 requires mechanisms that continuously monitor and control the security of ICT systems and minimize their exposure, including tools that promptly detect anomalous activities. Applied to an AI deployment, an inference call is an ICT operation that carries the entity's data to an external system, and the Article 9 expectation is that the entity can see and constrain that operation. The DORA compliance framework for banks covers the register and exit-strategy side. At the inference layer, protection means a control that reads AI requests, applies policy on what data leaves and which model receives it, and holds the line before the call reaches the provider, rather than a periodic review of logs after the traffic has gone.

Detection: Article 10

Article 10 requires prompt detection of anomalous activities, including performance issues and ICT-related incidents, with multiple layers of control and defined alert thresholds. AI traffic has its own anomaly surface: a caller suddenly sending far more data than its baseline, prompts reaching an unapproved model, or output patterns that indicate a prompt-injection attempt in progress. Detecting these requires telemetry on the request path, because the anomalous signal lives in the prompt and response content and the calling identity. An entity that instruments the application around the model and never inspects the model traffic has no detection layer where DORA expects one.

Incident management and reconstruction: Article 17

Article 17 establishes the ICT-related incident management process, and the reporting obligations that follow require an entity to classify an incident, reconstruct what happened, and report major incidents to its competent authority on a defined timeline. Reconstruction of an AI-involved incident depends on a record of the requests and responses around the event: which identity called which model, what data the prompt carried, and what came back. Without a per-request record, the incident team reconstructs from application logs that omit the prompt content and the model identity, which are the two facts the reconstruction turns on. The record has to exist before the incident, captured at the moment of each call.

Resilience testing: Articles 24 to 27

Chapter IV requires a testing program, and for significant entities that includes threat-led penetration testing modeled on the TIBER-EU framework. A testing program that covers the AI estate has to exercise the inference path: can a tester reach an unapproved model, exfiltrate data through a prompt, or bypass the policy control on AI traffic. Testing those scenarios presumes a control on the request path exists to test. An AI deployment with no enforcement point on the traffic gives the testing program nothing to probe at the inference layer and leaves a gap the assessment has to report. This is distinct from the third-party dependency testing covered in DORA third-party AI risk.

The common requirement across the chapters

Article 9 wants protection on the operation, Article 10 wants detection on the anomaly, Article 17 wants reconstruction of the incident, and Articles 24 to 27 want a control to test. Each lands on the same object: the live AI request between the entity's systems and the model endpoint. DORA treats resilience as a property of running systems, and an AI system's running surface is its inference traffic. The broader map of how DORA sits alongside SR 11-7 and the EU AI Act is in AI compliance in banking. The inference-layer point is that the register and the contract are static artifacts, and DORA's operational chapters ask for controls that act on traffic as it happens.

DeepInspect

This is the inference-layer control DORA's operational chapters ask for, and it is what DeepInspect provides. DeepInspect is a stateless proxy on the AI request path between a financial entity's applications and agents and the model endpoints they call. It reads each request, binds it to the authenticated identity, classifies the data it carries, and applies a deterministic pass, block, or modify decision before the call reaches the provider, which is the Article 9 protection on the operation.

It monitors the traffic for anomalies against caller baselines and flags data volume, unapproved destinations, and injection patterns, which is the Article 10 detection layer. It commits a per-decision audit record naming the caller, the data classes, the model, and the outcome, which is the reconstruction evidence Article 17 reporting depends on. And it gives the Chapter IV testing program a defined control on the inference path to exercise. It runs inline and fails closed, so a policy violation is prevented rather than reported after the fact. Book a demo today.