EU AI Act High-Risk Readiness: 11 Weeks to August 2026

What Actually Applies on August 2, 2026

The Act entered into force August 1, 2024. Prohibited practices became applicable February 2, 2025. General-purpose AI model obligations took effect August 2, 2025. The next major milestone is the application of obligations on high-risk AI systems and the rest of the Act, effective August 2, 2026.

If your system falls inside Annex III, the calendar matters now. Annex III lists eight categories of high-risk use that, for most B2B teams, reduces to four areas worth checking against:

• Employment and worker management. Recruitment, performance evaluation, task allocation. Almost any HR-tech AI lands here.
• Access to essential services. Credit scoring, insurance pricing, public-benefit eligibility.
• Critical infrastructure. Safety components of digital infrastructure, road traffic, energy supply.
• Education and vocational training. Admissions, assessment, allocation.

Annex III also covers law enforcement, migration, administration of justice, and biometric categorisation. Most B2B SaaS teams will not touch those. If you are building HR-tech, insurance, or fintech AI, you almost certainly are in scope.

The Four Obligations That Need Code

The Act creates many obligations on paper. Four of them require changes in the system itself rather than in the legal binder. The other obligations are documentation, governance, and process, and they can be drafted by counsel in parallel. The four that touch the code:

1. Risk management system (Article 9)

A continuous, iterative process across the system lifecycle. In practice: a written risk register linked to specific model versions and data refreshes, a residual-risk threshold the team agrees to, and a process for re-running the assessment when the model changes materially. Most teams already have something like this for security; the AI version extends it to model behaviour, dataset drift, and known failure modes.

2. Data and data governance (Article 10)

Training, validation, and test datasets must be relevant, representative, and free of errors to the extent possible. The hard part is the documentation: data provenance, the choices made on sampling and labelling, the known biases in the dataset and what was done about them. For models trained on data the team did not collect (Azure OpenAI, Claude, open-weights from Hugging Face), this means working from the provider's documentation and from your own fine-tuning or RAG dataset.

3. Technical documentation (Article 11, Annex IV)

Annex IV defines the contents of the technical documentation. It is roughly a system datasheet: intended purpose, design choices, architecture, training and evaluation methodology, performance metrics, foreseeable misuse, human oversight measures. The document does not need to be a thousand pages. It needs to be true, kept current, and ready for the market surveillance authority.

4. Human oversight (Article 14)

The system must be designed so that natural persons can effectively oversee it during use. For automation systems, that translates into specific design choices: confidence thresholds that route low-confidence decisions to a human, the ability to override the model, audit trails that make individual decisions reviewable.

// Sketch of a high-risk decision surface with built-in oversight
async function evaluateApplicant(application: Application) {
  const result = await model.predict(features(application));

  if (result.confidence < HUMAN_REVIEW_THRESHOLD) {
    return queueForHumanReview({ application, modelOutput: result });
  }

  await auditLog.record({
    decision: result.decision,
    confidence: result.confidence,
    modelVersion: MODEL_VERSION,
    inputFeatures: features(application),
    timestamp: new Date(),
  });

  return result;
}

The threshold, the queue, the audit trail. Three concrete things. The Article 14 documentation describes them; the code makes them real.

Transparency Obligations Outside Annex III

Article 50 imposes transparency obligations on AI systems intended to interact with natural persons (most chatbots), AI systems generating synthetic content (most image and text generators), and deep-fake systems. These obligations sit outside the high-risk regime and apply to far more products.

Practically: a chatbot must disclose it is AI. AI-generated content must be marked as such in a machine-readable way where reasonable. Deep fakes carry stronger disclosure obligations. The implementation work is small but real, and the deadline is the same August 2, 2026 date for systems placed on the market after that point.

What General-Purpose AI Model Providers Owe You

If you build on Azure OpenAI, Anthropic via API, AWS Bedrock, or Google Vertex, the GPAI obligations (in force since August 2, 2025) fall on the provider. Your obligations as a downstream deployer are different: you assess your own use case against Annex III, you maintain your own technical documentation, and you implement your own human-oversight design.

Ask the provider for the model card or system card, the safety evaluation summary, the copyright training-data summary, and the GPAI compliance statement. All major providers publish these. The downstream deployer documentation should cite them rather than reinvent the model description.

The 11-Week Readiness Checklist

A pragmatic order of work for teams that have not started:

1. Map every AI feature against Annex III. List the ones in scope. Document the ones out of scope and why.
2. For each high-risk feature, write the Annex IV technical documentation skeleton. Even a five-page draft is a starting point.
3. Identify the human-oversight surfaces. Confirm the code routes low-confidence decisions correctly. Write the audit trail if it does not exist.
4. Pull GPAI provider documentation into the system file. Reference, do not duplicate.
5. Add the Article 50 transparency disclosures to any chatbot or content-generation surface.
6. Stand up a versioned risk register. Link it to model versions and dataset refreshes.
7. Brief legal counsel on the work, then run a tabletop on the market-surveillance authority asking for the file.

None of these steps is a six-month project. All of them require someone owning the work. The teams that miss the August 2 date will miss it because nobody was assigned, not because the obligations were unclear.

Enforcement Reality So Far

The first nine months of GPAI obligations produced more guidance than penalties. The AI Office published clarifications on the GPAI Code of Practice. National authorities issued sector-specific notices. Public enforcement actions have been limited and have focused on the most egregious cases.

This pattern is likely to continue for the high-risk regime. The first year will be about establishing precedent, not maximising fines. That does not mean the deadline is theatre. It means teams that have credible documentation and a serious oversight design will be in a different conversation than teams that have nothing.

Where Compliance Spending Misfires

Three categories of spend that consultants will sell and that often do not produce compliance value:

• Generic AI governance platforms. Many of them produce documentation that does not map to Annex IV. The output is policy, not technical documentation.
• Pre-built bias audits without scope. A bias audit on the wrong dataset, against the wrong reference, produces a binder that does not survive contact with a serious assessor.
• External certifications that are not standards. Until harmonised standards under the Act exist (the CEN-CENELEC work is ongoing), external "AI Act certification" claims do not confer presumption of conformity.

For Teams Already Past the Basics

If the readiness checklist is already done, the higher-value work is post-market monitoring (Article 72), the registration in the EU database for high-risk systems (Article 49), and the serious-incident reporting obligation. These are operational obligations that begin once the system is on the market and require pre-built reporting workflows.

The Act will not pause for any team. Eleven weeks is short, but the work that matters is finite. Start with the inventory, finish with the audit-trail code, and the rest is paperwork that can be ready by August.