Framework · EU financial services
DORA evidence for the AI workload.
The Digital Operational Resilience Act has applied to EU financial entities since January 2025 — and your AI providers are ICT third-party service providers under it. Meilynx produces the runtime evidence for the AI workload slice: asset inventory, tamper-evident monitoring, anomaly detection, and the observed-provider register.
Identify, monitor, detect, register.
DORA's operational core for the AI workload is evidential: know your ICT assets and their third-party dependencies, monitor them continuously, detect anomalies promptly, and keep the register of information current.
- ICT asset identification — including AI systems and their provider dependencies (Article 8).
- Continuous monitoring and protection of ICT systems and the data they carry (Article 9).
- Prompt anomaly detection over ICT activity (Article 10).
- The register of information on ICT third-party providers — your AI providers included (Article 28).
Runtime obligations, to runtime evidence.
A specific Meilynx control for each runtime-side obligation, and the artifact it produces. Process obligations — the risk framework, resilience testing, contractual provisions — stay attested in your own program, and the package says so per control.
DORA → Meilynx controls (AI workload slice)
| Requirement | How Meilynx maps | Examination artifact |
|---|---|---|
Identify and document ICT assets and their third-party dependencies DORA · Art. 8 | The inventory of AI models and providers in use is derived from live traffic and enforced by runtime model allow-listing — the AI slice of the asset register starts from what actually runs, not from a survey. | AI asset inventory, generated from traffic |
Continuously monitor and control the security and functioning of ICT systems DORA · Art. 9 | Every AI request, response, and governance decision is captured inline at the proxy and sealed into a tamper-evident, hash-chained record — with detection of personal-data and credential egress before it leaves your perimeter. | Hash-chained monitoring record + egress findings |
Promptly detect anomalous activities and ICT-related incidents DORA · Art. 10 | Prompt-drift and tool-grant-drift detection flag unapproved changes to AI system configuration against approved baselines — anomaly detection for the way AI systems actually change. | Drift findings against approved baselines |
Detect, manage, and notify ICT-related incidents DORA · Art. 17–19 | Critical and high-severity findings from governed AI traffic are detection input to your incident process. Classification and reporting to your competent authority remain your processes — the package records the detection side. | Severity-ranked finding log for the period |
Maintain the register of information on ICT third-party providers DORA · Art. 28(3) | Your AI model providers are ICT third-party service providers. The observed-provider list — which providers, which models, how much traffic — substantiates the register's factual basis; the contractual fields stay maintained in your GRC program. | Observed AI provider & model register |
Identify and document ICT assets and their third-party dependencies
DORA · Art. 8
Maps to · The inventory of AI models and providers in use is derived from live traffic and enforced by runtime model allow-listing — the AI slice of the asset register starts from what actually runs, not from a survey.
Examination artifact · AI asset inventory, generated from traffic
Continuously monitor and control the security and functioning of ICT systems
DORA · Art. 9
Maps to · Every AI request, response, and governance decision is captured inline at the proxy and sealed into a tamper-evident, hash-chained record — with detection of personal-data and credential egress before it leaves your perimeter.
Examination artifact · Hash-chained monitoring record + egress findings
Promptly detect anomalous activities and ICT-related incidents
DORA · Art. 10
Maps to · Prompt-drift and tool-grant-drift detection flag unapproved changes to AI system configuration against approved baselines — anomaly detection for the way AI systems actually change.
Examination artifact · Drift findings against approved baselines
Detect, manage, and notify ICT-related incidents
DORA · Art. 17–19
Maps to · Critical and high-severity findings from governed AI traffic are detection input to your incident process. Classification and reporting to your competent authority remain your processes — the package records the detection side.
Examination artifact · Severity-ranked finding log for the period
Maintain the register of information on ICT third-party providers
DORA · Art. 28(3)
Maps to · Your AI model providers are ICT third-party service providers. The observed-provider list — which providers, which models, how much traffic — substantiates the register's factual basis; the contractual fields stay maintained in your GRC program.
Examination artifact · Observed AI provider & model register
What you show a supervisor.
The audit trail renders into an evidence package scoped to the AI workload — every control classified as proxy-verified runtime evidence or attested in your GRC program, so the boundary of the claim is explicit on every row.
In the package
- AI asset and provider inventory, auto-populated from traffic.
- Tamper-evident monitoring record across the reporting period.
- Severity-ranked detection findings as incident-process input.
- Per-control scope classification — proxy-verified vs. attested.
DORA and the AI workload.
Does DORA really cover our AI usage?
Yes. DORA has applied to EU financial entities since 17 January 2025, and it regulates ICT risk broadly — AI systems are ICT assets, and the model providers behind them are ICT third-party service providers. The asset-identification, monitoring, detection, and third-party-register obligations all reach the AI workload.
Does the Meilynx DORA preset make us DORA compliant?
No — and no runtime product could. DORA spans governance-body accountability, the ICT risk framework, resilience testing, and contractual provisions that live in your organization, not in a proxy. The preset evidences the AI workload slice: the runtime obligations Meilynx can substantiate from live traffic carry proxy-verified evidence, and each control in the package is explicitly classified as proxy-verified or attested in your own GRC program.
How does this fit with the register of information?
The register requires you to record every contractual arrangement with ICT third-party providers — including AI model providers. Because Meilynx observes the AI traffic itself, it produces the factual half continuously: which providers and models are actually in use, in which systems, at what volume. Your team maintains the contractual fields; the register stops drifting from reality.
See exactly what an examiner receives
Download a sample examination package — model inventory, control coverage, a governance policy snapshot, and a SHA-256 integrity hash.