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.
For the AI workload, DORA's core is evidential: identify assets and their dependencies, monitor continuously, detect anomalies promptly, and keep the register 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.
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. | AI asset inventory, generated from traffic |
Continuously monitor and control the security and functioning of ICT systems DORA · Art. 9 | AI requests, responses, and governance decisions are captured inline at the proxy and sealed into a tamper-evident, hash-chained record. Personal-data and credential egress is detected 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. | 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 yours; 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, while 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.
Examination artifact · AI asset inventory, generated from traffic
Continuously monitor and control the security and functioning of ICT systems
DORA · Art. 9
Maps to · AI requests, responses, and governance decisions are captured inline at the proxy and sealed into a tamper-evident, hash-chained record. Personal-data and credential egress is detected 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.
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 yours; 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, while 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. Each control is 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 or 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, outside any proxy. The preset evidences the AI workload slice, and each control in the package is classified as proxy-verified from live traffic 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, AI model providers included. Because Meilynx observes the AI traffic itself, it produces the factual half continuously: which providers and models are in use, in which systems, at what volume. Your team maintains the contractual fields, and the register stops drifting from reality.
Build the evidence.
See exactly what an examiner receives
Request a sample examination package: model inventory, control coverage, a governance policy snapshot, and a SHA-256 integrity hash.