The EU AI Act is live. The first enforcement phase took effect February 2, 2025 — prohibiting AI systems with unacceptable risk. General-purpose AI model obligations followed on August 2, 2025. And the phase that most US enterprise CISOs need to care about — high-risk AI system obligations — takes effect August 2, 2026.
That is 14 months away. For US enterprises with any EU footprint — customers, employees, data, or operations — the clock started.
EU AI Act Enforcement Timeline
You are here. High-risk AI system requirements apply to US companies with EU customers, data, or operations. 14 months remain.
This checklist covers the 12 mandatory compliance requirements that apply to US companies with high-risk AI systems under EU AI Act Articles 8–15. It is designed for CISOs at mid-market and enterprise organizations who need a concrete, actionable list — not a 150-page regulation summary.
Who's Affected: US Enterprises with EU Exposure
The EU AI Act is extraterritorial. Any organization that places AI systems on the EU market, or whose AI systems produce outputs used in the EU, falls within scope — regardless of where the company is headquartered. If any of the following describe your organization, you are likely in scope:
- Your products or services are used by EU-based customers or employees
- Your AI systems process data belonging to EU natural persons (GDPR's "data subjects")
- Your AI outputs inform decisions about EU individuals — hiring, credit, health, insurance, content moderation
- You operate in the EU through subsidiaries, branches, or commercial partnerships
- You sell software-as-a-service to EU-based organizations
Healthcare & Life Sciences
Clinical decision support, diagnostic AI, patient risk scoring — all classified high-risk under Annex III. FDA-aligned systems likely in scope.
Financial Services
Credit scoring, algorithmic trading, insurance underwriting, fraud detection — all high-risk. SR 11-7 alignment helps but doesn't substitute for EU AI Act compliance.
Defense & Government Contractors
Dual-use AI systems, biometric identification, and AI supporting government decisions. EU AI Act Annex I + III overlap with CMMC obligations.
Technology & SaaS
Customer-facing AI in recruitment, HR tools, content recommendation, chat support, and document processing — all potentially in scope if EU users are affected.
US companies systematically underestimate their exposure. Most CISOs at companies with any European customer base believe they are not "in the EU market" because they are not physically present there. This is incorrect. If your AI systems affect EU individuals — even indirectly — you are subject to the EU AI Act. The threshold for "placing on the market" is very broad.
Understanding EU AI Act Risk Tiers
The EU AI Act classifies AI systems by risk level. Compliance obligations scale with risk. Understanding your tier is the first step in the checklist process.
Prohibited
Unacceptable Risk
Social scoring, real-time biometric surveillance in public, manipulation of vulnerable groups. These are banned outright — not compliance targets, just removal targets.
High Risk
Annex III Systems
Biometrics, critical infrastructure, education, employment, essential services, law enforcement, border control, administration of justice. Full compliance required.
Low/Minimal Risk
All Other Systems
Chatbots, spam filters, games. Transparency obligations only — label AI-generated content, disclose AI use.
The 14-month August 2026 deadline applies to high-risk systems. If your AI portfolio has any Annex III systems — and for most US enterprises in regulated sectors it does — your compliance clock is already running.
The EU AI Act Compliance Checklist
The following 12 items are the mandatory obligations under EU AI Act Articles 8–15 for high-risk AI systems. Complete these to demonstrate conformity before August 2, 2026.
EU AI Act High-Risk Compliance Checklist
1 — Foundation: Risk Management System (Art. 9)
AI risk management system established. Documented, ongoing process covering the full AI system lifecycle — from design through deployment to post-market. Identifies known and foreseeable risks, implements mitigations, tests effectiveness, and updates as the system or its operating environment changes. This is not a one-time assessment — it is an operational capability with named ownership and defined review cadence.
Risk register maintained. For each high-risk AI system, a register documents identified risks, chosen mitigation measures, residual risk after mitigations, and acceptance rationale. Regulators can request this during market surveillance. If it doesn't exist in documented form, it doesn't exist for compliance purposes.
2 — Data Governance (Art. 10)
Data governance framework documented. Covers data sourcing, representative datasets, bias detection, data cleaning, and data protection. The training, validation, and testing data for each high-risk system must be relevant, representative, free of errors, and complete. If you use EU-subject personal data, GDPR and EU AI Act data governance requirements must be aligned — they overlap significantly.
Dataset bias documentation. For each high-risk system, you must document what bias risks exist in the training data, how you tested for them, and what mitigations were applied. This documentation is required before deployment and must be updated when the system changes materially.
3 — Technical Documentation (Art. 11)
Technical documentation produced and kept current. For each high-risk AI system, a technical file must exist covering: system description and intended purpose, design specifications and architecture, data handling and governance, risk analysis and mitigation log, performance metrics and testing results, known limitations, and update history. This documentation must be updated every time the system changes. It must be available to authorities within 15 days of a request.
4 — Transparency & User Information (Art. 11)
AI system transparency achieved. Users and affected individuals must be informed they are interacting with an AI system — unless this is obvious from context. Output confidence scores and limitations must be disclosed. For systems making consequential decisions, the logic must be explainable to the extent the state of the art permits. Deploying a "black box" high-risk system without any explainability mechanism is a compliance violation.
AI-generated or AI-manipulated content labeled. Any image, audio, or video content produced by your AI systems that could be mistaken for real must be labeled in a machine-readable format (e.g., C2PA metadata, watermarks). This applies even for low-risk systems under Article 50, but is mandatory for high-risk deployment documentation.
5 — Human Oversight (Art. 14)
Human oversight controls designed and documented. For each high-risk system, you must define who has authority to oversee, monitor, and override the AI's outputs — particularly for consequential decisions. These controls must be integrated into the system architecture, not bolted on after deployment. "Human oversight" means a named person with the capability and authority to make decisions, not a checkbox signed by an automated process.
Override authority documented and operationalized. Document who can override AI decisions in what circumstances, how they exercise that override, and how overrides are logged. The override mechanism must be accessible, comprehensible, and actually used — not a theoretical capability that exists only on paper.
6 — Accuracy, Robustness & Cybersecurity (Art. 15)
Accuracy metrics defined and benchmarked. For each high-risk system, document the accuracy metrics relevant to the intended use, the benchmark or test methodology used, and the minimum acceptable accuracy threshold. Systems must be tested against appropriate benchmarks at deployment and monitored for accuracy degradation over time. Drift detection is not optional — it is required under the continuous monitoring obligation.
Adversarial robustness testing completed. Systems must be evaluated for vulnerability to adversarial inputs, out-of-distribution inputs, and known attack vectors relevant to the use case. Robustness testing results must be documented and fed into the risk management system.
7 — Conformity Assessment (Art. 16)
Conformity self-assessment completed. High-risk AI systems generally require a conformity assessment — either by a Notified Body (for specific Annex III categories like biometrics, police, and justice) or via self-assessment (for other Annex III systems). Complete the relevant assessment, document your compliance evidence package, issue the EU Declaration of Conformity, and affix the CE marking. For most US enterprise SaaS, self-assessment applies — but verify your specific use case against the Annex III list.
8 — EU Declaration of Conformity & CE Marking (Art. 19)
EU Declaration of Conformity drafted and maintained. A formal declaration that your high-risk AI system meets all applicable requirements under the EU AI Act. This is a legal document — it must be kept current and be available to authorities. If your system changes materially, the Declaration must be updated and the conformity assessment re-run.
CE marking process completed. Affix the CE marking to your AI system (or product it is integrated into) and ensure the registration in the EU database (EU database for high-risk AI systems under Article 51) is complete. For software-only systems, determine whether the CE marking applies to the software itself or to the product it operates within.
9 — Post-Market Monitoring (Art. 61)
Post-market monitoring system established. A documented, active system for collecting and documenting data about your AI system's performance and compliance in real-world use. The purpose is to identify risks that emerge after deployment — performance drift, new bias patterns, edge cases not captured in testing. This is not the same as an incident log — it is an ongoing data collection and analysis function.
Post-market monitoring plan documented. Define what data you collect, how you analyze it, what triggers a review, who is responsible, and what update process follows identification of issues. This plan must be in place before the system goes live — not something you build reactively.
10 — Serious Incident Reporting (Art. 62)
Incident reporting process defined. "Serious incidents" — system failures or misuse that could harm health, safety, or fundamental rights — must be reported to the relevant national authority within 72 hours of awareness. Incidents that could not have been foreseen by the operator must be reported immediately. Define your classification criteria for what constitutes a "serious incident" and who has authority to make that determination.
Incident response procedures documented and tested. The 72-hour reporting window is aggressive. You need an incident response process that can identify, classify, escalate, and report serious incidents on that timeline. If your current security incident response process doesn't have a specific AI incident classification pathway, build one now.
11 — Supply Chain Due Diligence (Art. 29)
Third-party AI vendor compliance verification completed. For every high-risk AI system you deploy — including third-party and SaaS-based systems — you are responsible for verifying that the provider has met their EU AI Act obligations. This means: obtaining and reviewing the provider's technical documentation, confirming the CE marking and conformity assessment, and documenting your own verification process. You cannot outsource compliance by buying a vendor's system.
AI vendor contracts updated with EU AI Act obligations. Contracts with third-party AI providers should include obligations to maintain compliance documentation, provide updated technical files on material changes, notify you of serious incidents, and cooperate with market surveillance authorities. Standard SaaS contracts often don't include these provisions — renegotiate before August 2026.
12 — Registration & EU Authorized Representative (Art. 22)
EU Authorized Representative appointed. US companies without an EU establishment must designate an Authorized Representative in the EU to act as the point of contact for regulatory authorities. This person (natural or legal) must be established in an EU member state and must receive, store, and provide all compliance documentation on demand. This is a legal requirement, not an operational preference.
High-risk AI system registered in EU database. High-risk AI systems must be registered in the EU database before they are placed on the market or put into service. Registration includes the system identifier, intended purpose, registration date, and basic technical information. Registration is operator-side — if you use a third-party high-risk AI system, confirm that the provider has registered it.
Non-compliance is not theoretical. Violations of EU AI Act prohibitions carry fines up to €35 million or 7% of global annual turnover — whichever is higher. Market surveillance authorities in EU member states can order removal of non-compliant systems from the EU market. For US companies with significant EU revenue, the financial exposure is real and immediate.
The NIST AI RMF Crosswalk: Credit for Work You're Already Doing
If your organization has already invested in NIST AI RMF alignment, you have a meaningful head start. The four NIST AI RMF functions map to EU AI Act obligations in ways that reduce duplication — if you build your documentation correctly. This table shows how.
| EU AI Act Requirement | NIST AI RMF Function | How to Leverage Existing Work |
|---|---|---|
|
Art. 9 — Risk Management
Risk management system, risk register, mitigation documentation
|
GOVERN + MANAGE | Your GOVERN policy work and MANAGE controls documentation form the basis of your EU AI Act risk management system. Map existing risk register entries to EU AI Act format. Risk tolerance thresholds in your GOVERN documentation satisfy EU Art. 9 documentation requirements. |
|
Art. 10 — Data Governance
Training data quality, bias testing, dataset documentation
|
MAP + MEASURE | AI system data flow documentation from your MAP sprint directly satisfies EU Art. 10 data governance requirements. Bias assessment artifacts from MEASURE work (model validation documentation, fairness testing results) map to EU dataset bias documentation requirements. |
|
Art. 11 — Technical Documentation
System description, architecture, testing results, limitations
|
GOVERN + MEASURE | AI system documentation from GOVERN accountability structures and performance benchmark documentation from MEASURE activities provide the content for EU Art. 11 technical documentation. Merge existing AI system descriptions with EU-required format (intended purpose, architecture, test results, known limitations). |
|
Art. 14 — Human Oversight
HITL controls, override authority, monitoring log
|
MANAGE | Human-in-the-loop controls documented for MANAGE (who reviews what, with what frequency, override authority) directly map to EU Art. 14 human oversight documentation requirements. Ensure override logs and decision records are being maintained — these are the evidence for both NIST MANAGE and EU Art. 14 compliance. |
|
Art. 15 — Accuracy & Robustness
Performance metrics, drift detection, adversarial testing
|
MEASURE | MEASURE performance metrics, baseline measurements, and testing schedules map directly to EU Art. 15 accuracy requirements. The key addition for EU compliance is documenting adversarial robustness testing specifically — this is often in the NIST MEASURE backlog but explicitly required under EU Art. 15(3). |
|
Art. 61 — Post-Market Monitoring
Real-world performance monitoring, issue identification
|
MANAGE | AI incident register from MANAGE (active log of model failures and unexpected outputs with root cause documentation) is your post-market monitoring foundation. The gap is the systematic data collection function — ensuring continuous, structured monitoring rather than reactive incident logging. Build the monitoring process to run alongside the existing incident register. |
|
Art. 62 — Incident Reporting
72-hour serious incident reporting to national authorities
|
MANAGE | AI incident classification from MANAGE forms the foundation — but the EU 72-hour reporting window requires a specific escalation pathway that existing security incident response processes often don't have. Add a classification tier for "serious incidents" under EU AI Act Art. 62, and a separate reporting pathway to EU national authorities (separate from your US regulatory reporting obligations). |
|
Art. 29 — Supply Chain
Third-party vendor compliance verification, contract obligations
|
MAP | Third-party AI vendor risk scores from MAP (your AI vendor list with risk classifications) directly satisfies the supplier verification requirement under EU Art. 29. Extend vendor risk documentation to include EU AI Act compliance status for each vendor — the vendor's conformity assessment, CE marking, and technical documentation. This is an addendum to your existing vendor risk framework, not a new framework. |
Do not build EU AI Act compliance from scratch. If you have completed the NIST AI RMF MAP sprint and documented MANAGE controls, you have 60–70% of the content required for EU AI Act compliance. The remaining work is: translating existing artifacts into EU-required format, adding specific requirements (adversarial robustness testing, post-market monitoring process, EU Authorized Representative), and building the 72-hour incident reporting pathway. Leverage what you have.
Priority Actions for the Next 90 Days
With 14 months remaining, the highest-value work you can do in the next 90 days is:
- Determine your AI portfolio's EU AI Act risk classification. Run through each AI system in your inventory and classify it against Annex III. Any Annex III system is in the high-risk compliance track. If you don't have an AI inventory, your first action is running the MAP sprint — this is both your NIST AI RMF requirement and your EU AI Act requirement.
- Appoint your EU Authorized Representative. This is a legal prerequisite that takes time to establish. Do this first — you cannot complete conformity assessment without it.
- Map existing NIST AI RMF evidence to EU AI Act requirements. Crosswalk your GOVERN/MAP/MEASURE/MANAGE artifacts to the 12-item checklist above. Identify the gaps — most organizations find they need to add adversarial robustness testing, build the post-market monitoring process, and establish the 72-hour incident reporting pathway.
- Audit your third-party AI vendor compliance status. For each third-party AI system in your high-risk portfolio, request the provider's EU AI Act technical documentation and conformity assessment. If your vendors haven't started their own compliance work, you have a supply chain compliance gap you need to address through contract renegotiation.
- Build the conformity assessment evidence package. Start assembling the documentation portfolio (Art. 11 technical file contents) for each high-risk system. The documentation requirements are substantial — beginning early means you won't face a documentation sprint in month 12.
The goal is not "perfect" — it is "documented and defensible." The EU AI Act does not require perfect AI systems. It requires documented evidence that you understood your system's risks, implemented appropriate controls, and maintain an ongoing compliance capability. An incomplete checklist with documented evidence is dramatically more defensible than a perfect-looking system with no documentation behind it.