The EU AI Act Is Here: What Enterprise Teams Need to Do Before August 2026

August 2026 is eleven weeks away. If your organization uses AI to screen job applicants, score loan applications, manage employee performance, or make decisions that affect EU residents in any material way, you are almost certainly operating a high-risk AI system under the EU AI Act. And if you have not started your Annex IV documentation, you are not slightly behind. You are structurally unprepared for an enforcement regime that carries fines of up to 35 million EUR or 7 percent of global annual turnover for the most serious violations.

This is not a theoretical risk. The EU AI Act entered into force on August 1, 2024. Prohibited AI practices were banned from February 2, 2025. The obligations that apply to high-risk AI systems, including Annex IV technical documentation, Article 10 data governance, Article 14 human oversight, and Article 72 post-market monitoring, become enforceable on August 2, 2026. National competent authorities in every EU member state are building enforcement capacity now.

The good news: most enterprise teams already have compliance artifacts that map to Act requirements. The challenge is organizing them, filling the gaps, and building the ongoing documentation process the Act requires. This post walks you through both.

Quick Test: Is Your AI System High-Risk?

The EU AI Act's high-risk classification comes from Annex III, which lists eight categories. If any AI system you deploy falls into one of these categories, you are subject to the full high-risk obligations.

Annex III Categories:

1. Biometric identification and categorization. Real-time and post-remote biometric identification systems. If you use facial recognition for access control or employee attendance, read this carefully.

2. Critical infrastructure management. AI systems managing or operating critical digital infrastructure, road traffic, water, gas, heating, or electricity supply. Energy and utilities companies need to review this category thoroughly.

3. Education and vocational training. AI systems that determine access to or assignment in educational institutions, or that evaluate learning outcomes. AI-driven admissions tools, proctoring systems, and adaptive assessment platforms fall here.

4. Employment, workers management, and access to self-employment. This is the category most enterprises underestimate. Any AI system used to recruit, screen, filter, or evaluate applicants; any AI used for promotion, task allocation, monitoring, or performance evaluation of workers. If your ATS uses a scoring algorithm or your performance management tool uses AI to rank employees, you are in scope.

5. Access to essential private services and public services and benefits. AI used in credit scoring, insurance risk assessment, and health insurance underwriting. Fintech and insurance organizations have been in scope since day one.

6. Law enforcement. AI used by law enforcement for risk assessment of individuals, evidence evaluation, or crime prediction. Applies to public sector and certain government contractors.

7. Migration, asylum, and border control management. AI used for visa and asylum processing, risk assessment for border control, and document authenticity checking.

8. Administration of justice and democratic processes. AI systems assisting judicial authorities in applying the law, and AI used to influence elections.

If you are a B2B software company whose product includes an AI feature that any of your EU customers use in these categories, you are a provider of a high-risk AI system and the Act's provider obligations apply to you directly.

If you are an enterprise deploying AI systems built by a third-party vendor in one of these categories, you are a deployer and you have a separate, overlapping set of obligations that include conducting fundamental rights impact assessments and maintaining logs of system operation.

The honest version of the scope question: if your organization uses AI for anything that affects a person's employment, credit, education, or access to services, and any of those persons are EU residents or the processing occurs in the EU, assume you are in scope and work backward from there.

What Annex IV Documentation Requires

Annex IV is the technical documentation requirement for high-risk AI systems. It has nine sections. Every provider of a high-risk AI system must maintain this documentation and make it available to national authorities on request. Here is what each section means in practice:

Section 1: General description of the AI system. This is not a marketing summary. It requires the intended purpose, the version number, the hardware and software environment the system is designed to run on, the forms of input data (including data type and format), and the performance metrics relevant to the system's purpose. Think of it as a formal system card with regulatory force.

Section 2: Description of the elements of the AI system and the process for its development. This covers the training methodology, training data characteristics, the architecture, and how design choices were made. If you are using a foundation model from a third-party provider, you will need your vendor to supply the portions of this documentation they hold, and you will need to document your fine-tuning or adaptation process.

Section 3: Monitoring, functioning, and control of the system. This section requires documentation of the system's capabilities and limitations, the expected accuracy levels, and the circumstances that may lead to the system generating risks. It connects directly to NIST AI RMF MAP-3.5, and if you have already built limitation registers for a NIST audit, much of this documentation exists.

Section 4: Description of the appropriateness of the performance metrics. You need to justify why the metrics you chose are appropriate for your use case. An accuracy score without context is not sufficient. You need to show you considered disparate impact, edge cases, and the consequences of errors in your specific deployment context.

Section 5: Risk management documentation. This is the formal record of your risk management system under Article 9. It covers the methodology, the results, the risk mitigation measures applied, and the residual risks accepted.

Section 6: Description of the changes made through the lifecycle. A version history of material changes to the system, with documentation of any new conformity assessment or re-evaluation triggered by those changes.

Section 7: Standards, specifications, and common specifications applied. If you have mapped to ISO 42001, NIST AI RMF, or another recognized framework, document it here. This is where the crosswalk work pays off.

Section 8: EU declaration of conformity. The formal declaration that the system complies with the Act, signed by the authorized representative.

Section 9: Post-market monitoring plan. A forward-looking document describing how you will monitor system performance after deployment, what metrics you will track, how often you will review them, and what triggers a re-evaluation or temporary suspension of the system.

The Data Governance Requirements Under Article 10

Article 10 is one of the most substantive and least discussed provisions of the EU AI Act. It applies to any high-risk AI system that involves training, validation, or testing with data, which is essentially every system on the Annex III list.

Article 10(2) requires that training, validation, and testing datasets be subject to appropriate data governance practices covering the design choices, data collection processes, data preparation operations (labeling, cleaning, enrichment), examination for possible biases, identification of relevant data gaps, and measures to address those gaps.

Article 10(3) requires that the datasets be relevant, representative, and free of errors to the extent possible. This is a due diligence standard, not an absolute requirement, but you need documentation that shows you assessed the data and took reasonable steps.

Article 10(5) addresses sensitive attributes. Where bias mitigation is necessary, providers may process special categories of personal data (race, health, religion, etc.) for the purpose of detecting and correcting bias in the AI system, subject to appropriate safeguards. This is a narrow exception, and using it requires careful legal review, but it exists and many organizations are unaware of it.

In practice, Article 10 means you need a data governance document for each high-risk AI system that covers: where the training data came from, how it was collected and labeled, what bias assessment you ran, what you found, and what you did about it. If you are using a pre-trained model from a vendor, you need the vendor's equivalent documentation or a formal acknowledgment of what they cannot provide.

Human Oversight Under Article 14

Article 14 requires that high-risk AI systems be designed and developed so that they can be effectively overseen by natural persons during the period in which they are in use. This is not a soft requirement. It has specific implications for product design.

Article 14(3) specifies that human oversight measures must enable the persons responsible to understand the system's capabilities and limitations, monitor its operation, detect and address anomalies and failures, intervene when needed (including by interrupting operation), and override or ignore the system's output.

For enterprise teams building AI-assisted decision tools, this means a few concrete things. The system cannot be designed to make final decisions without a human review step in consequential contexts. The interface must expose enough about how the system reached its output that a human reviewer can meaningfully evaluate it. There must be a documented process for when and how a human can override the system.

Article 14(4) adds that for systems where human oversight is not reasonably possible in real time, the oversight mechanisms must be built into the design and deployment context. Auto-approval workflows that route AI outputs directly to downstream systems without human review are inconsistent with Article 14 in high-risk contexts.

If your product includes an "autopilot" mode for HR decisions or credit approvals, you need a legal and product review of whether that mode is compatible with Article 14 for EU deployments. The answer may be that it is compliant for lower-risk configurations but not for the Annex III use cases. That distinction needs to be documented.

Post-Market Monitoring Under Article 72

Article 72 is the provision that separates a one-time compliance project from a compliance program. It requires that providers of high-risk AI systems implement a post-market monitoring plan that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.

The post-market monitoring system must collect, document, and analyze data on the performance of high-risk AI systems throughout their lifecycle. It must cover performance in the real world, not just in test conditions. It must identify and report serious incidents to national authorities.

Article 72(3) specifies that where post-market monitoring reveals that the system no longer meets the requirements of the Act, the provider must take corrective actions, including suspension of the system if necessary.

For enterprise teams, this means that Annex IV documentation is not complete at deployment. It is a living set of documents that must be updated as the system evolves, as monitoring data comes in, and as the risk picture changes. The compliance obligation is continuous, not punctual.

The practical infrastructure for Article 72 compliance includes: a defined monitoring cadence (quarterly is typical for most Annex III use cases), documented metrics that serve as your performance benchmarks, a process for investigating anomalies, a record of every review cycle, and a clear escalation path for material performance degradation.

The Crosswalk to NIST AI RMF and ISO 42001

If your organization has already done compliance work against NIST AI RMF or ISO 42001, you have more EU AI Act coverage than you may realize.

The overlap is substantial. NIST AI RMF GOVERN-1.1 and GOVERN-4.1 map to EU AI Act Article 9 (risk management system) and Article 17 (quality management system). MEASURE-2.5 (bias testing) and MEASURE-4.1 (documentation of measurement results) map directly to Article 10 data governance and Annex IV Section 4. MAP-3.5 (limitations documentation) maps to Annex IV Section 3.

ISO 42001 Clause 8.4 (AI risk treatment) and Clause 9.1 (monitoring, measurement, analysis, and evaluation) map to Article 72 post-market monitoring. ISO 42001 Annex B, which covers AI objectives and risk management, provides a structural template that satisfies much of the Article 9 risk management system requirement.

The organizations that are best positioned for August 2026 are the ones that treated their NIST AI RMF implementation as the foundation rather than as a standalone project. The evidence they collected for MEASURE controls is the same evidence that goes into Annex IV documentation. The vendor inventory they built for MAP-5.1 is the foundation of their deployer obligations. The gap is usually not the substance of the compliance work. It is the EU-specific documentation format and the formal declaration process.

CertiComply Enterprise maintains a live crosswalk across NIST AI RMF, ISO 42001, and EU AI Act requirements. When your team logs evidence against a NIST control, the system identifies which EU AI Act articles that evidence supports and flags what is still missing. The Annex IV documentation builder pre-populates from your existing evidence library, so you are not rewriting documentation that already exists in a different format.

A Practical 90-Day Sprint to Get Annex IV-Ready

If you are starting now, you can be materially compliant by August 2026 with a focused sprint. Here is the structure:

Days 1 to 14: Scope and inventory. Complete an AI system inventory. For every system, determine whether it falls into an Annex III category. Assign an owner to each in-scope system. Document the deployment context and the EU nexus (who is affected, where the data is processed, where the provider is established).

Days 15 to 30: Gap assessment against Annex IV. For each in-scope system, work through the nine sections of Annex IV and document what you have and what is missing. Identify vendor documentation gaps and send formal requests to your AI providers. Many enterprise AI vendors have EU AI Act documentation packages ready; you just need to ask.

Days 31 to 60: Documentation build. Write the sections you can write with existing materials. Commission the sections that require new work: data governance documentation, limitation registers, bias testing if not already completed, post-market monitoring plans. Get the risk management documentation through your approval process and signed.

Days 61 to 75: Human oversight review. Review each in-scope system against Article 14. For any product that ships to EU customers, confirm that override mechanisms exist and are documented. If product changes are needed, this is your last window to get them shipped before August.

Days 76 to 90: Final review and declaration. Assemble the complete Annex IV package for each in-scope system. Prepare the EU declaration of conformity. Brief your legal team and the executive who will sign the declaration. Confirm your post-market monitoring infrastructure is operational.

Annex IV Documentation Checklist

Section	Key Documents Required	Owner
1. General description	System card; intended purpose statement; input/output specification	Product
2. Development process	Training methodology; architecture description; vendor documentation	Engineering
3. Monitoring and control	Limitations register; known failure modes; performance bounds	Engineering + Risk
4. Performance metrics	Metric justification; accuracy by demographic subgroup; error consequence analysis	Data Science
5. Risk management	Article 9 risk register; mitigation measures; residual risk sign-offs	GRC
6. Lifecycle changes	Version history; change log; re-evaluation triggers	Engineering
7. Standards applied	NIST AI RMF mapping; ISO 42001 certification (if held); other frameworks	GRC
8. Declaration of conformity	Signed EU declaration; authorized representative details	Legal
9. Post-market monitoring	Monitoring plan; metrics and cadence; escalation process	Product + GRC

The EU AI Act is a compliance regime that rewards organizations that have built genuine AI governance processes, not ones that have produced documentation for its own sake. The Annex IV requirements, read carefully, are asking the same questions that any rigorous internal AI review should ask: What does this system do, what can go wrong, how do you know when it is working, and who is responsible when it is not?

If your organization can answer those questions with evidence, August 2026 is manageable. If you cannot, the next eleven weeks are not enough time to build the governance program from scratch. But they are enough time to build the documentation layer on top of the governance work you have already done, identify the gaps that represent real risk, and get the most critical controls in place before enforcement begins.

Start with the scope question. Everything else depends on knowing which systems are in scope and who owns them.