EU AI Act readiness checklist for asset managers (2026)

EU AI Act readiness checklist — 30 items across inventory, data, robustness, transparency, documentation, and vendor governance for asset managers in 2026.

Benedikt Hofmann

10 Mar 2026 — 8 min read

The EU AI Act has now been in force long enough that the supervisory cadence around it is becoming visible. Our Regulatory Crawler has flagged 19 regulatory and supervisory items and 8 pieces of clarifying commentary touching on AI use in financial services since the start of 2026 (and the trend in February was steeper than January). The market priced the Act as a one-time compliance event when it came into force; the lived reality is that it has become a continuous regulatory perimeter.

This post is a practical 2026 readiness checklist for asset managers and institutional finance teams. It is not legal advice — we always recommend working with qualified counsel on the regulatory specifics. It is, however, an operational distillation of what we see firms preparing for and what we see them systematically under-preparing for.

12-minute read · Updated 16 May 2026

Key takeaways

30-item checklist across six sections: inventory & classification, data & governance, technical robustness, transparency & oversight, documentation, third-party vendors.

Three areas where firms are systematically under-prepared: inventory completeness, continuous documentation, and vendor governance evidence.

The EU AI Act's lifetime-documentation obligation (Article 11 and Annex IV) means technical documentation must be kept up to date throughout a system's life, not produced once at a validation cycle — and in our reading, that is best met by documentation generated from runtime state.

Proportionality applies — high-risk uses carry the full burden, lower-risk uses face proportionate requirements. Classify aggressively, document proportionately.

A two-minute framing

Three points to anchor on before the checklist:

The Act's "high-risk AI system" definition reaches further into financial services than many firms initially assumed. Risk assessment, fraud detection, creditworthiness, pricing — all are within scope. AI components inside portfolio risk and analytics also fall in scope when their outputs influence decisions affecting clients or markets.
The documentation expectation is continuous, not periodic. The Act requires technical documentation to be kept up to date throughout the system's lifetime (Article 11, Annex IV). In our reading, that means documentation should reflect the current state of the system, not the state at the last validation cycle.
Third-party AI services are in scope. If you use external AI tooling — whether SaaS analytics, embedded models, or APIs — your responsibility for governance over those services does not transfer to the vendor. Documentation of vendor governance is part of your documentation.

The checklist — six sections, 30 items

The checklist is organised into six sections that follow the structure of the Act and align with how a supervisor is most likely to ask about your AI estate.

Section A — Inventory and classification (6 items)

Maintained inventory of all AI systems in production use across the firm — internal and third-party. Updated continuously, not annually.
Classification of each system against the Act's risk categories (prohibited, high-risk, limited-risk, minimal-risk). Documented rationale per system.
Identified provider vs. deployer roles for each system. For SaaS vendors, documented which obligations sit with the vendor and which sit with you.
Documented intended purpose for each system, in language a supervisor can read.
Identified residual-risk vs. core-risk uses. A system used at the margin of decisions has a lower bar than one in the critical decision path; document which is which.
Process for adding a new AI system to the inventory before it enters production use.

Section B — Data and governance (5 items)

Data sources documented for each high-risk system: provenance, refresh cadence, quality controls, retention.
Bias and representativeness assessment of training and reference data, particularly for systems that touch client outcomes.
Personal data handling documented under the GDPR/Act interaction. Joint controllership where applicable.
Data residency and cross-border flow documented per system.
Periodic review of data quality controls with documented outcomes.

Section C — Technical robustness and accuracy (6 items)

Documented performance metrics appropriate to each system's purpose, with thresholds for acceptable performance.
Continuous monitoring of performance against thresholds, with alerting and escalation defined.
Drift monitoring on inputs, outputs, and performance, with thresholds and remediation paths.
Challenger models maintained for high-risk systems, with disagreement-event logging.
Adversarial-robustness assessment for systems that consume unstructured data (e.g. LLM-driven systems consuming filings and news).
Documented incident response for material model failure: detection, containment, communication, post-mortem.

Section D — Transparency and human oversight (5 items)

Per-system documentation of how outputs are produced, in language a non-technical reviewer can understand.
Documented human-in-the-loop thresholds for actions, parameter changes, and escalations. Audit log of human interventions.
User-facing transparency where required: notification when interacting with an AI system, disclosure of AI involvement in outputs that reach clients.
Explainability artefacts available for high-risk systems: feature importance, evidence chain, model-version trail.
Documented training for staff who operate, review, or oversee AI systems.

Section E — Documentation and record-keeping (5 items)

Technical documentation per system — continuous, current, exportable. Aligned with the Act's specified contents.
Logs retained sufficient to reconstruct any production output, for the period required.
Version history of models, configurations, governance thresholds, and human interventions.
Documented post-market monitoring plan for each high-risk system.
Records of supervisory dialogue and clarifications received, including informal communications.

Section F — Third-party and vendor governance (3 items)

Vendor governance pack on file for each third-party AI system: vendor's documentation, contractual commitments, audit rights, incident notification process.
Documented assessment of vendor's AI Act compliance posture — provider obligations are vendor's responsibility, but you have to evidence that you assessed them.
Exit and substitution plan for each critical third-party AI service.

Where firms are systematically under-prepared

From our work with clients and from what Regulatory Crawler is flagging, three areas come up disproportionately.

Under-prep #1 — Inventory completeness

Firms are good at listing the AI systems they procured. They are bad at listing the AI components that have crept into systems they already had. The financial reporting tool that added an LLM summary feature in a quarterly update; the OMS that introduced an anomaly classifier; the BI dashboard that quietly added an embedded forecast — all are in scope, and many are missing from inventories.

The remedy is a periodic active sweep: each business line owner attests that the inventory of AI components used in their workflows is complete, with a defined process for updating it whenever a vendor releases new functionality.

Under-prep #2 — Continuous documentation

Most documentation we see is built around a validation-cycle model — a thick PDF produced at validation, then stable until the next validation. The Act's lifetime-documentation obligation (Article 11, Annex IV) requires the documentation to be kept up to date throughout the system's life. In our reading, that means drift status, current challenger comparison, current threshold configurations, and the current human-intervention log should all be in the live documentation.

The remedy is to generate the documentation pack from the platform's runtime state rather than as a static deliverable. This is what we ship by default with PortIQ and CyronOS — and we have helped clients retrofit the same pattern onto their own systems.

Under-prep #3 — Vendor governance evidence

Asking the vendor a question is not the same as evidencing that you assessed them. A signed vendor questionnaire from 18 months ago is not the same as a live assessment. The Act's expectation that compliance is maintained over a system's life applies to vendor assessments too — they should be kept current and their incident-notification processes tested.

The remedy is a vendor governance review cadence — quarterly for critical AI vendors, annually for non-critical — with documented outcomes.

A note on proportionality

The Act is proportionate; not every AI system carries the same burden. Limited-risk and minimal-risk uses face materially lighter requirements. The checklist above is most relevant to high-risk uses; for lower-risk uses, sections A, B (partially), D and F still apply with reduced depth.

The pragmatic move is to classify aggressively (be honest about what is high-risk) and then build proportionate documentation. Over-documenting a minimal-risk system is wasted effort; under-documenting a high-risk one is regulatory exposure.

How DF Analytics can help

Two ways, depending on what you need:

For your own AI estate: Our Regulatory & MRM Documentation service line works with internal teams to produce continuous, audit-ready documentation packs for your in-house and third-party AI systems — aligned with the Act's specified contents.
For our products in your stack: Our MRM documentation packs for PortIQ, CyronOS, the Quantitative Engines, and the Agent Systems are generated continuously from the platform's runtime state. They drop into your inventory without requiring re-authoring.
If you want to walk through where your readiness is strongest and where it has gaps, the discovery call is a good starting point.

Coming next

17 March — MRM documentation for LLM-based agents: a template you can use. The most technically demanding documentation we see firms producing right now, and the one most likely to face supervisory scrutiny.

Frequently asked questions

What is the EU AI Act readiness checklist?

A 30-item operational checklist covering inventory and classification, data and governance, technical robustness and accuracy, transparency and human oversight, documentation and record-keeping, and third-party vendor governance — distilled from the EU AI Act and our operational experience applying it.

Are asset managers high-risk under the EU AI Act?

Many AI uses inside asset management — risk assessment, fraud detection, creditworthiness, pricing, and AI components in portfolio risk analytics that influence client outcomes — fall under high-risk classification. Each system requires individual classification with documented rationale.

Does the Act require continuous documentation?

The Act requires technical documentation to be kept up to date throughout the system's lifetime (Article 11, Annex IV). In our reading, the practical way to meet that bar is documentation generated from runtime state, so that it reflects the current state of the system rather than the state at the last validation cycle.

Are third-party AI services in scope?

Yes. If a firm uses external AI tooling (SaaS analytics, embedded models, APIs), the firm's responsibility for governance over those services does not transfer to the vendor. Vendor assessments must be evidenced and kept current.

What are the most common readiness gaps?

Inventory incompleteness (AI components that crept into existing tools), documentation built as a periodic deliverable instead of continuously, and vendor governance treated as a one-time questionnaire rather than an ongoing process.

External references

EU AI Act — official text
European Commission AI Office
ESMA — AI in financial services
About the author — Compliance Liaison — Deep Finance Analytics. The Compliance Liaison tracks supervisory developments through Regulatory Crawler and translates them into operational guidance. See the Insights hub for the full archive, or book a discovery call to discuss this post with the team.