EU AI Act Compliance: What Engineering Teams Must Do Before the August 2026 Deadline

The EU AI Act's compliance clock for high-risk AI systems runs out on August 2, 2026 — six weeks from now. Regulation (EU) 2024/1689, in force since August 2024, established a phased rollout: prohibited AI practices became enforceable in February 2025, General Purpose AI (GPAI) model obligations in August 2025, and high-risk AI system requirements — the tier that affects most enterprise software teams building or deploying AI — take full effect on August 2, 2026. If your engineering team ships an AI feature that touches employment decisions, credit scoring, critical infrastructure, healthcare, biometrics, or education, EU AI Act compliance is not optional and not theoretical. The deadline is in weeks, not months.

The regulation draws a sharp line between providers and deployers. A provider is any organization that develops a high-risk AI system and places it on the market — that is the software company that built the product. A deployer is an organization that uses a high-risk AI system in a professional context. If you are a SaaS company shipping an AI-powered feature, you are a provider and carry the heaviest compliance burden. If you are a corporate IT team integrating a vendor's AI tool, you are primarily a deployer with a narrower but still real set of obligations. This guide focuses on what providers — software engineering teams building AI products — need to implement before the deadline.

This guide covers EU AI Act compliance from the engineering side: how to classify your AI systems correctly, what the specific technical requirements are under Articles 9 through 15, what the Annex IV documentation must contain, and how conformity assessment works in practice. For teams already building AI governance on top of a security baseline, our guide on securing AI agents in the enterprise covers the overlapping access control and audit trail requirements that form the foundation for EU AI Act compliance.

The EU AI Act's Four-Tier Risk Model

The EU AI Act classifies AI systems into four risk tiers. The tier determines your compliance burden — and the classification is based on the system's intended purpose and the context in which it is used, not on the underlying technology, model size, or what the developer chooses to call it.

• →Unacceptable risk (prohibited): AI practices banned outright as of February 2025 — social scoring by public authorities, real-time remote biometric identification in public spaces with narrow exceptions, subliminal manipulation causing harm, exploitation of vulnerabilities of specific groups, and untargeted facial recognition scraping from the internet or CCTV
• →High-risk (Annex III): AI systems that pose significant risks to health, safety, or fundamental rights — and must comply with the full set of Articles 9–15 requirements before being placed on the market. The August 2, 2026 deadline governs this tier
• →Limited risk: Systems with transparency obligations only — primarily chatbots and synthetic-content generators that must disclose their AI nature to users. No technical documentation or conformity assessment is required
• →Minimal risk: All other AI systems, including spam filters, AI in video games, and most content recommendation engines. No specific obligations under the EU AI Act

The critical engineering insight: the Act specifies explicitly that a system's risk tier is determined by its actual intended purpose and use, not by how you describe it in marketing. An AI feature that helps HR teams rank job applicants is high-risk employment AI regardless of whether you market it as an 'AI assistant' or a 'productivity tool.' Misclassification is not a safe harbor — national market surveillance authorities evaluate actual function when assessing compliance.

How to Classify Your AI Features Under Annex III

Annex III is the list that controls who must comply by August 2, 2026. It enumerates eight high-risk use-case categories. If your AI system falls under any of them, the full Chapter 3 requirements apply. The same machine learning model can be minimal-risk in one application and high-risk in another — classification follows intended purpose, not the model itself.

• →Category 1 — Biometric identification and categorization: AI used to identify natural persons remotely by biological characteristics, or to infer protected attributes — emotions, political views, or demographic characteristics — from biometric data
• →Category 2 — Critical infrastructure: AI managing or operating electricity grids, water systems, gas networks, transport infrastructure, or digital infrastructure — including AI-driven anomaly detection that can trigger shutdowns or rerouting
• →Category 3 — Education and vocational training: AI that determines access to educational institutions, assesses examination results, evaluates learning competences, or monitors students during assessments
• →Category 4 — Employment and workers management: AI used in recruitment (screening, ranking, selecting candidates), promotion decisions, task allocation, performance monitoring, or termination — the most common high-risk category in enterprise B2B SaaS
• →Category 5 — Access to essential services: AI used in creditworthiness assessment, insurance pricing, eligibility decisions for social services, or emergency services dispatch
• →Category 6 — Law enforcement: AI used for risk assessment of individuals, lie detection, crime prediction, crime pattern analysis, or profiling in criminal investigations
• →Category 7 — Migration and border control: AI used in refugee and asylum processing, border checks, or irregular migration prediction models
• →Category 8 — Administration of justice: AI used to research and interpret facts and law, or to assist judicial authorities in applying law to specific cases

If any of your AI features touch Category 3, 4, or 5 — which covers most B2B SaaS AI in HR tech, fintech, insurance, edtech, and enterprise workflow automation — you are building a high-risk system and need to complete compliance implementation before August 2. For the broader production operations context that this compliance layer sits on top of, our LLMOps in enterprise production guide covers the observability, versioning, and deployment infrastructure that EU AI Act logging and monitoring requirements depend on.

Article 9: Building a Continuous Risk Management System

Article 9 requires a continuous, documented risk management system for every high-risk AI system — not a pre-launch security review, not a compliance document you file once. It is a running process that must be maintained throughout the system's operational life, updated as the system changes and as new risks emerge from real-world performance data. A compliance PDF is not Article 9 compliance. A living process with documented review cycles, test results, and mitigation tracking is.

• →Risk identification before deployment: document every known risk and every reasonably foreseeable misuse scenario. This requires adversarial red-teaming of the system — not just standard QA. Each risk must be recorded with severity, likelihood, and which populations are affected
• →Risk quantification: estimate how frequently each identified risk could manifest under normal intended use, how severe the potential harm is, and whether affected persons can recover from a wrong decision or whether it is irreversible
• →Mitigation measures for every identified risk: technical controls (output filtering, confidence thresholds, rate limits on automated decisions), operational controls (mandatory human review for specific output categories), and documentation controls (deployer warnings in instructions for use)
• →Post-market monitoring mechanism: the system must have a defined channel for collecting real-world performance data after deployment — feedback forms, incident reports, accuracy sampling — and a documented process for feeding that data back into the risk assessment when metrics deviate from pre-deployment baselines
• →Vulnerable group impact assessment: the risk assessment must explicitly evaluate impacts on minors, people with disabilities, elderly persons, and other populations who may be disproportionately harmed by system errors or biases in training data

Article 12: Logging Requirements Engineering Teams Must Build Into the System

Article 12 requires that high-risk AI systems technically allow automatic recording of events throughout their operational lifetime. This is not application logging for debugging — it is audit-grade logging for regulatory accountability. Logs must be built into the system architecture, retained for a minimum of 6 months (or longer per applicable sector regulation), and stored in a form that cannot be altered by the application itself.

• →Session-level records: each interaction's start and end timestamp, the system version active during the session, and the deployer or operator identity initiating the session
• →Input records: the data provided to the AI system for each decision or output — in a form that allows later reconstruction of exactly what the system received, not just what it produced
• →Output records: the system's decision, recommendation, or output for each input, stored alongside the corresponding input so auditors can reconstruct the full decision context
• →Human interventions: every case where a human operator overrode, modified, or rejected the system's output — with the override action and rationale if captured
• →Reference data: for systems that check inputs against databases (biometric matching, credit bureau lookups), the specific database version or dataset queried for each decision
• →Model version: the exact model version, checkpoint, or parameter set active at the time of each decision — required because model updates change system behavior and auditors need to know which model produced which outcome

The key implementation constraint: Article 12 logs must be immutable and tamper-evident. Storing them in your primary application database — where application code can modify records — is insufficient for regulatory purposes. Use append-only storage or a separate audit log service with write-once semantics. On AWS this maps to S3 with Object Lock in Compliance mode; on Azure to Immutable Blob Storage; on GCP to retention-locked Cloud Storage buckets with Data Access audit logs enabled.

Article 13: Transparency Documentation for Deployer Organizations

If you are a provider supplying a high-risk AI system to deployer organizations, Article 13 requires that your system come with deployer-facing documentation that enables those organizations to use it responsibly and implement their own oversight controls. This documentation is distinct from your internal Annex IV technical documentation — it is what your customers receive as part of the system, and it defines what they are legally responsible for implementing on their side.

• →Provider identification: your organization's name, registered address, and the contact point for technical and compliance inquiries about the system
• →System capabilities: what the system can do, under what conditions it performs reliably, and the specific tasks it was designed and evaluated for — written for operational staff, not lawyers
• →Limitations and failure modes: where the system performs less reliably, the conditions under which outputs are less accurate (data quality thresholds, distribution shift, edge cases), and known demographic performance disparities from your evaluation datasets
• →Input data requirements: the format, quality, and completeness requirements for data provided to the system, and what behavior to expect when input data does not meet those requirements
• →Performance metrics: accuracy, error rates, and false positive rates on your validation datasets — specific numbers, not qualitative descriptions
• →Human oversight measures: the specific oversight controls deployers are required to implement, including which output categories require human review and how to configure the system's built-in oversight features
• →Change notifications: when you materially update the system, the Article 13 documentation must be updated to describe what changed and what impact deployers need to account for in their configurations

Article 14: Engineering for Genuine Human Oversight

Article 14 requires that high-risk AI systems be designed to allow natural persons to effectively oversee them. 'Effectively' is doing real work in that sentence: oversight controls must be genuinely usable in normal operational conditions — not buried in admin interfaces, stripped from the production UI to reduce complexity, or designed as token compliance features that operators never actually use. The regulation specifies that oversight must allow oversight persons to understand the system's capabilities and limitations, detect anomalies or unexpected outputs, avoid automation bias, interpret outputs, decide not to act on them, and interrupt the system's operation.

• →Confidence and uncertainty surfacing: present the system's confidence level or uncertainty estimate in the primary user interface alongside its output — not buried in logs or API responses that operators never see. Operators must be able to calibrate their trust in individual outputs before acting on them
• →Output interpretability: for consequential decisions, surface the inputs or factors that most influenced the output in a form operators can evaluate. Full explainable AI is not required for every system, but the output must not be an opaque number with no traceability
• →Override controls in the main operator workflow: the ability to reject or modify an AI output must be accessible in the normal workflow, not behind additional confirmation screens. A UI pattern where the AI decision auto-advances unless the operator catches a small flag is not Article 14 compliant
• →Hard stops for defined high-risk outputs: certain output categories should require explicit human confirmation before the system proceeds — define these in your risk assessment and build the confirmation step into the workflow as a hard gate, not a soft suggestion
• →Session audit access for oversight persons: operators and oversight personnel designated by the deployer must have access to the system's decision history for cases they are responsible for, with enough context to evaluate what the AI recommended and why
• →Biometric identification double-check: for any biometric identification system, Article 14(5) explicitly requires that any identification result be verified by at least two competent persons before any action is taken — this is not optional and not waivable by the deployer

Annex IV: The Nine-Section Technical Documentation File

Annex IV specifies the structure of the technical documentation every high-risk AI provider must maintain. This documentation must be retained for 10 years after the last unit of the system is placed on the market. The nine sections cover the full lifecycle from designed purpose through data, development methodology, testing, monitoring, and post-market management. An audit can demand this documentation at any point during the ten-year retention period — and it must accurately describe the system as built, not as designed.

• →Section 1 — General description: the system's name, version, intended purpose, target users, geographic scope of deployment, and any intended limitations on use that must be documented before the system is placed on the market
• →Section 2 — Development methodology: the data sources used for training and evaluation, preprocessing methods applied, the model architecture, training approach, and the specific design decisions that shaped the system's behavior — including hyperparameters and evaluation criteria
• →Section 3 — Monitoring and control: how the system is monitored in production, which metrics are tracked, how anomalies are detected and escalated, and how the risk management system feeds into operational monitoring and incident response
• →Section 4 — Performance metrics: accuracy measurements on your validation dataset, error rates, false positive and false negative rates, and demographic breakdowns that surface performance disparities across population groups — the specific numbers that support your risk assessment
• →Section 5 — Risk management records: the complete Article 9 documentation — all identified risks with severity and likelihood assessments, the mitigation measures implemented and their effectiveness, and the residual risk assessment
• →Section 6 — Lifecycle changes: every material change to the system after initial deployment — model retraining, architecture updates, data source changes — with the rationale for the change and the impact assessment conducted before deployment
• →Section 7 — Applied harmonized standards: the technical standards your system conforms to, if any — ISO/IEC 42001 for AI management systems, ISO/IEC 23894 for AI risk management, or equivalent NIST AI RMF controls
• →Section 8 — EU declaration of conformity: a copy of the signed declaration that the system meets all applicable EU AI Act requirements, updated whenever the system changes materially
• →Section 9 — Post-market monitoring plan: the specific metrics tracked in production, the thresholds that trigger re-evaluation of risk classification, and the feedback mechanism for collecting deployer and end-user incident reports

GPAI Foundation Models in High-Risk Applications: Who Owns What

Most enterprise AI products today are built on top of General Purpose AI (GPAI) foundation models — Claude, GPT-4, Gemini, Llama. The EU AI Act has separate GPAI obligations (Article 53) for the organizations that train and distribute these models: technical documentation, model cards, training data summaries, copyright compliance, and — for models with systemic risk above the 10^25 FLOP training threshold — adversarial testing and incident reporting. Those obligations fall on Anthropic, OpenAI, Google, and Meta. They do not transfer to you. But they also do not shield you from your own high-risk system obligations when your product applies a foundation model to a high-risk use case.

• →You are the provider of your AI application — not the GPAI model provider. If you build a hiring screening tool on top of Claude's API, you are the provider of a Category 4 high-risk AI system under Annex III. Anthropic is the GPAI model provider with its own separate Article 53 obligations. Your Annex IV must describe both the foundation model used and your specific application of it
• →Document the GPAI model in Annex IV Section 2: model provider, model version pinned to a specific release (not 'latest'), the model card reference, and any fine-tuning or system-prompt engineering applied. A floating model version that updates silently when the provider releases a new version is a compliance gap — the model changes, your documentation does not
• →Run your own evaluation: the GPAI provider's safety benchmarks were conducted against their model in general-purpose contexts. Your compliance evaluation must be run against your specific application — different data distributions, different task framing, different failure modes that only appear in your use case
• →Chain-of-responsibility documentation: where your Annex IV relies on the GPAI provider's technical documentation to support a compliance claim, explicitly document which claims rely on external provider documentation and which you have independently verified through your own testing

Conformity Assessment: Self-Assessment vs. Notified Body Audit

For the majority of high-risk AI systems under Annex III, conformity assessment follows the internal control (self-assessment) procedure: the provider completes the Annex IV technical documentation, implements a quality management system per Article 17, conducts an internal conformity assessment, issues the EU declaration of conformity, applies CE marking, and registers the system in the EU AI database. No third-party audit is required for most Annex III systems. Notified body assessments are required for biometric identification systems used by law enforcement, and for high-risk AI systems that are also regulated medical devices or safety components under other EU product safety legislation. For the underlying security and compliance infrastructure that EU AI Act controls sit on top of, our security and scalability engineering service covers the hardened baseline that makes audit-grade logging and access control tractable to implement.

• →Step 1 — Complete Annex IV technical documentation: this is the core of the conformity assessment and must accurately describe what was built. It cannot be written in parallel with late-stage development; documentation that describes the planned system rather than the shipped system does not demonstrate conformity
• →Step 2 — Implement a quality management system (Article 17): a QMS covering how design decisions are made and documented, how data quality is controlled, how testing is conducted and recorded, how post-market monitoring operates, and how changes to the system are authorized, documented, and assessed for impact
• →Step 3 — Conduct the conformity assessment: a structured internal review against each Article 9–15 requirement, with documented evidence for each claim of conformity. The output is a conformity assessment report — not just a declaration
• →Step 4 — Issue the EU declaration of conformity: a signed legal document asserting that the system meets all applicable EU AI Act requirements. This declaration must be updated whenever the system changes materially enough to affect compliance
• →Step 5 — Register in the EU AI database: providers of most Annex III high-risk systems must register the system in the EU's centralized AI database before placing it on the EU market. Registration is separate from the conformity assessment and requires specific system metadata

Frequently Asked Questions

Does the EU AI Act apply to companies outside the EU?

Yes. The EU AI Act applies to any provider that places a high-risk AI system on the EU market or puts it into service in the EU, regardless of where the provider is incorporated or headquartered. If your AI product is used by customers in EU member states, you are subject to the same compliance requirements as an EU-based provider. U.S., UK, and APAC companies with European enterprise customers are already being asked for compliance documentation as a vendor qualification requirement by those customers — the commercial pressure precedes formal enforcement.

What counts as a high-risk AI system under the EU AI Act?

Annex III lists eight high-risk categories: biometric identification and categorization, critical infrastructure management, education and vocational training, employment and worker management, access to essential private and public services (credit, insurance, social services), law enforcement, migration and asylum processing, and administration of justice. Classification is based on actual intended purpose and use — not labels. An AI feature that ranks job applicants is a Category 4 high-risk employment AI system whether the developer calls it an 'intelligent ranking engine' or an 'AI-powered HR assistant.'

What happens if we miss the August 2, 2026 deadline?

National market surveillance authorities in EU member states can issue fines of up to €15 million or 3% of global annual turnover for violations of high-risk AI system requirements — whichever is higher. For violations of the prohibited AI practices provisions, penalties reach €35 million or 7% of global turnover. There is no announced grace period after August 2. The more immediate commercial consequence for enterprise software providers is contractual: large enterprise customers in banking, healthcare, government procurement, and insurance are already conditioning vendor selection and contract renewals on EU AI Act compliance, and the intensity of that scrutiny rises sharply after the deadline.

How long do we need to retain AI system logs under the EU AI Act?

Article 12 specifies a minimum retention period of 6 months for automatically recorded event logs, unless sector-specific regulation requires longer. The Annex IV technical documentation must be retained for 10 years after the last unit is placed on the market. Healthcare AI subject to medical device regulation, financial services AI under EBA or ECB guidelines, and data processed under GDPR all carry their own retention requirements that typically exceed the EU AI Act minimums. Design your logging architecture for the longest applicable retention period across all regulations that touch your system — not just the AI Act minimum.

Do we need a third-party audit for EU AI Act compliance?

Not for most Annex III high-risk AI systems. The majority follow the internal control self-assessment conformity path — the provider completes the Annex IV documentation, conducts the conformity assessment internally, and issues the EU declaration of conformity without external auditor involvement. Notified body assessments are required for biometric identification systems used in law enforcement contexts and for high-risk AI systems that are also regulated as medical devices or safety components under other EU product safety legislation. If your system falls outside those categories, self-assessment is the correct conformity path.

How Belsoft Helps with EU AI Act Compliance Implementation

EU AI Act compliance is not a legal exercise that runs alongside engineering — it is an engineering exercise that requires legal context. The logging architecture, the human oversight controls, the risk management system, and the Annex IV documentation are all built into the software, not filed as paperwork. Teams that treat compliance as a post-launch documentation task will find that the actual requirements — immutable audit logs, built-in override controls, continuous risk monitoring, pinned model versions — require architectural changes that are expensive to retrofit after a system is in production. Belsoft helps engineering teams build EU AI Act compliance into the system from the start: risk classification of existing AI features, logging and audit architecture that meets Article 12's tamper-evident requirements, human oversight UX controls for Article 14, and the Annex IV documentation structure that ties it together. If you are in the final weeks before August 2 and need to assess your compliance posture before enforcement begins, book a technical compliance scoping call or explore our AI and automation engineering service for implementation support.

“The engineering teams that will be compliant on August 2 started treating EU AI Act risk management as a system requirement — not a compliance checkbox to fill in after launch.”