The EU AI Act's August deadline

The EU AI Act's obligations for high-risk AI systems take effect on 2 August 2026. That is under six months away, and the compliance work — if it applies to you — is not a six-week project.

the structure, briefly#

The Act is risk-tiered rather than technology-specific.

Prohibited (in force since February 2025). Social scoring, certain biometric categorization, emotion recognition in workplaces and schools, untargeted facial image scraping, and manipulative techniques exploiting vulnerabilities.

High-risk (August 2026 for most). Systems used in employment decisions, education access, credit scoring, essential services, law enforcement, migration, justice administration, and as safety components in regulated products.

Limited risk. Transparency obligations. Tell people they are talking to an AI. Label synthetic media.

Minimal risk. Most software. No specific obligations.

General-purpose AI models. Separate obligations that began August 2025 — documentation, copyright policy, training data summaries, and additional requirements for models above a compute threshold.

the classification question#

Most of the compliance work is answering "is my system high-risk," and the answer is less obvious than people assume.

The high-risk categories are defined by use, not by technology. A simple scoring model used to filter job applicants is high-risk. A sophisticated transformer used to suggest recipes is not.

Specific things that catch people:

• Recruitment tooling. Anything that screens, ranks, or filters candidates. This includes a keyword filter, not just an ML model.
• Employee evaluation. Performance assessment, task allocation, monitoring that affects work relationships.
• Creditworthiness. Including proxies for it.
• Educational assessment. Grading, admission, proctoring.
• Safety components in products already covered by EU product safety legislation — which is a long list including machinery, medical devices, and vehicles.

If any of those describe your product, you have obligations, and if you are a provider (you put it on the market) rather than a deployer (you use it), the obligations are substantial.

what high-risk actually requires#

• A risk management system, documented and maintained across the lifecycle.
• Data governance — documented training, validation, and test data, with attention to bias and representativeness.
• Technical documentation sufficient for a regulator to assess conformity.
• Automatic logging of the system's operation.
• Transparency to deployers about capabilities and limitations.
• Human oversight designed in — a person must be able to understand, intervene, and override.
• Accuracy, robustness, and cybersecurity appropriate to the purpose.
• Conformity assessment before market placement, and CE marking.
• Registration in an EU database.
• Post-market monitoring and serious incident reporting.

That is a quality management system, not a checklist. The nearest analogue is medical device regulation, and it is deliberately modeled on it.

the practical advice#

Classify now. Before anything else, determine which of your systems fall in scope. This is a legal question with technical inputs and it should involve both. A lot of organizations discover they are in scope for one feature they did not think about.

Documentation is the bulk of the work. Most engineering teams do not document their training data provenance, their validation methodology, or their known failure modes. The Act requires all of it. Starting that documentation now is cheaper than reconstructing it later.

Logging is a technical requirement with a deadline. Automatic recording of system operation, retained, with enough detail to trace a decision. If your system does not do this, that is engineering work, and it is not trivial to add.

Human oversight is a design constraint. "A person reviews the output" is not sufficient if the person cannot meaningfully understand or override it. Designing for genuine oversight — surfacing confidence, explaining inputs, making override easy and recorded — affects your interface.

Watch for timeline adjustments. There has been active discussion about simplification and phasing, and the details have moved before. Track it, and do not use possible delay as a reason to defer classification, which is the part with the longest lead time.

the honest framing#

Whatever you think of the Act's design — and there are serious criticisms about compliance cost for small companies and about whether risk categories map cleanly onto real systems — it is law, it has extraterritorial reach, and the penalties are proportional to global turnover.

For most developers building most software, none of this applies. For the ones it applies to, six months is not very long.