EU AI Act High-Risk Compliance: What You Actually Need to Build

The EU AI Act became fully applicable for high-risk AI systems in August 2026. For most European organisations using AI in HR, credit scoring, access control, or critical infrastructure, the compliance deadline is no longer theoretical.

The legal commentary is extensive. The technical guidance is sparse. This is the engineering side.

What Makes an AI System “High-Risk”

Annex III of the AI Act defines eight categories of high-risk AI systems. The ones most likely to affect mid-market European companies:

• Employment: AI used for recruitment, selection, promotion, task allocation, monitoring, or termination decisions
• Access to essential services: credit scoring, insurance risk assessment
• Biometric identification: systems that identify individuals from biometric data
• Critical infrastructure: AI managing energy, water, transport networks
• Education: AI that determines access to educational institutions or evaluates students
• Law enforcement: AI used by public authorities for risk assessments

If your company uses an AI-powered ATS, automated credit scoring, or any AI system that informs decisions affecting individuals in these areas — you are in scope.

The Six Technical Requirements

The Act defines specific technical obligations. Here is what each one means in practice:

1. Risk management system (Article 9) A documented, ongoing process for identifying, analysing and mitigating risks throughout the system lifecycle. This is not a one-time assessment. You need a risk register that is reviewed when the system is updated, when new failure modes are discovered, or when the operational context changes.

2. Data governance (Article 10) Training data must be relevant, representative, free from errors and complete. For most organisations, this means auditing your training data for demographic bias, documenting data sources and preprocessing steps, and maintaining records of data quality validation.

3. Technical documentation (Article 11 + Annex IV) A 13-point technical file including: system description and intended purpose, design choices and assumptions, training methodology, performance metrics on relevant populations, known limitations, and post-market monitoring plan. This documentation must be available to national supervisory authorities on request.

4. Logging and record-keeping (Article 12) The system must automatically generate logs sufficient to trace events throughout the system’s lifetime. Minimum: input data at inference time, outputs, human override events, system failures. Retention period: at least six months, or longer if required by sector-specific regulation.

5. Transparency and provision of information (Article 13) High-risk AI systems must be interpretable by deployers and, where relevant, by affected individuals. This does not mandate full explainability of every prediction — but it does require the ability to explain, in human-understandable terms, the main factors affecting a given decision.

6. Human oversight (Article 14) High-risk AI systems must be designed to enable effective human oversight. Practically: a mechanism to pause or override the AI, clear escalation paths for edge cases, and training for human operators on the system’s limitations.

The Common Architecture Gaps

Based on gap analyses we have conducted, the most frequent technical shortfalls are:

No inference logging. The model produces outputs but they are not persisted with the input context. Without logs, you cannot investigate a complaint, demonstrate compliance, or identify drift.

Training data documentation does not exist. The model was trained on “data from the CRM” with no record of the date range, preprocessing steps, or exclusion criteria. Reconstructing this is expensive and sometimes impossible.

No human override mechanism. The AI output feeds directly into a downstream process with no point where a human can intervene. This is non-compliant and also operationally fragile.

Performance metrics are population-level only. You know the overall accuracy but not whether it is significantly worse for specific demographic groups. Annex IV requires performance across relevant subpopulations.

A Practical Compliance Roadmap

For organisations starting from a typical enterprise AI deployment (cloud API, minimal documentation):

Weeks 1-4: Inventory and scoping List all AI systems in use. For each, determine whether it falls under high-risk categories. Prioritise the ones used in HR, financial decisions or customer-facing assessments.

Weeks 5-8: Gap analysis per system For each in-scope system, map current state against the six technical requirements. Document what exists, what is missing, what needs to be built.

Weeks 9-16: Technical remediation Implement logging, build or document the risk management process, prepare technical documentation. The logging infrastructure alone — capturing inputs, outputs, and metadata at inference time, with a 6-month retention window — is typically 2-4 weeks of engineering work for an existing system.

Ongoing: Monitoring and review Post-deployment monitoring for model drift, performance degradation, and new failure modes. Trigger a review whenever the system or its context materially changes.

The organisations that will be ready have started. Those that have not face a compressed timeline with limited internal AI compliance expertise available in the market.