How to Prepare High-Risk AI Systems Before December 2027

The December 2027 deadline for high-risk AI systems gives European businesses more time to prepare, but it does not make preparation a 2027 project.

Under the current EU AI Act timeline, the rules for stand-alone high-risk AI systems classified under Article 6(2) and Annex III apply from 2 December 2027. High-risk AI systems covered through the regulated-product route under Article 6(1) and Annex I have a later application date of 2 August 2028. The revised timeline was introduced through the AI Omnibus, which entered into force on 27 July 2026.

That additional time is useful for a practical reason: high-risk AI compliance touches the system itself, not just the compliance team’s paperwork.

Organizations need to understand which AI systems they operate, determine whether those systems qualify as high-risk, identify whether they act as a provider or deployer, establish risk controls, prepare technical documentation, implement human oversight, maintain logs, test performance and cybersecurity, and keep evidence up to date. The European Commission identifies these areas among the requirements for high-risk AI systems.

So the useful question is not:

“When is the high-risk AI deadline?”

It is:

“What should we have in place before December 2027?”

This guide explains how to prepare high-risk AI systems by connecting classification, compliance requirements, development processes, documentation, evidence, and ongoing monitoring.

 

For the wider regulatory timeline, see our complete guide to the EU AI Act Annex III deadline. If you need to determine whether an AI system could be classified as high-risk, see our guide to classifying AI systems under the EU AI Act.

What Makes an AI System High-Risk Under the EU AI Act?

The EU AI Act does not classify every advanced or business-critical AI application as high-risk.

Article 6 establishes two main routes for high-risk classification:

1. The AI system is a safety component of a product, or is itself a product, covered by the EU harmonisation legislation listed in Annex I, and the relevant product requires third-party conformity assessment.
2. The AI system falls within one of the high-risk use cases listed in Annex III. 

For businesses preparing now, classification should therefore begin with the system’s intended purpose, not the model name or technology stack.

Which AI Use Cases Fall Under Annex III?

Annex III covers eight areas:

• Biometrics
• Critical infrastructure
• Education and vocational training
• Employment and worker management
• Access to essential private and public services
• Law enforcement
• Migration, asylum and border control
• Administration of justice and democratic processes

The European Commission’s draft classification guidelines provide practical examples of systems that may or may not qualify as high-risk. The Commission states that these examples are not exhaustive and may be updated. The final guidelines are expected by the end of 2026.

That makes the classification record particularly important. Businesses should be able to explain why a system falls within an Annex III category or why an Article 6(3) exception applies.

Does Every AI System Listed in Annex III Automatically Become High-Risk?

No.

This is one of the areas where a simplistic classification approach can create problems.

Article 6 contains an Article 6(3) filter for certain Annex III systems. Under the current framework, an Annex III system may not be considered high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including where it does not materially influence the outcome of decision-making, subject to the conditions set out in Article 6(3). Certain profiling uses remain high-risk regardless.

The Commission’s classification guidance recommends working through the assessment in a defined sequence:

AI system → intended purpose → Annex I route → Annex III route → Article 6(3) filter → transitional rules

That is a much stronger approach than assigning a risk label based only on the industry in which the AI is used.

Is There a “30% Rule” for High-Risk AI?

The term “30% rule” appears in some AI Act searches and discussions, but it should not be presented as an official EU AI Act threshold for high-risk classification.

The official Commission material and Article 6 instead focus on the system’s intended purpose, applicable Annex I or Annex III route, and the specific Article 6(3) conditions.

For publication, it is better to explain the actual classification test than to introduce an unsupported percentage.

Why Should Businesses Prepare Before December 2027?

The deadline is a legal milestone. It is not a project start date.

A high-risk AI system can involve engineering, product, security, compliance, legal, data, operations, and management teams. Those groups may already maintain pieces of the information needed for compliance, but they do not necessarily maintain it through a connected workflow.

Starting early gives an organization time to answer questions such as:

• Which AI systems are in use or development?
• What is each system’s intended purpose?
• Which Annex III category could apply?
• Are we acting as provider, deployer, or both?
• What documentation already exists?
• Which controls still need to be implemented?
• Where is the evidence?
• What changes should trigger reassessment?

The Commission itself notes that the postponement to December 2027 is intended to give providers and deployers more time to prepare for the high-risk rules and implement them as supporting tools, including standards, become available.

How Should Businesses Build an AI Inventory?

Start with visibility.

A business cannot reliably assess high-risk AI if it does not know which systems it has.

AI may be embedded in a customer-facing SaaS product, an HR workflow, a fraud detection process, an internal analytics tool, or a third-party service. Some systems may be formally approved, while others have entered production through ordinary software procurement or development processes.

The inventory should capture information such as:

• AI system name and version
• Business owner
• Provider and deployer
• Intended purpose
• Users and affected individuals
• Data processed
• Model or technology used
• Deployment environment
• Potential AI Act classification
• Applicable obligations
• Current compliance status

The inventory should also have a change process.

If a system originally used to summarize documents later starts ranking candidates for employment, that change can affect its regulatory analysis. The inventory should make that kind of change visible.

How Should a Business Classify Its AI Systems?

Classification should be a documented assessment rather than an informal decision.

The European Commission’s draft guidelines recommend starting by confirming that the technology qualifies as an AI system under the Act and identifying its intended purpose. The assessment then moves through the Annex I and Annex III routes before considering the Article 6(3) filter where relevant.

A useful classification record should capture:

System → intended purpose → use context → affected people → relevant Annex category → Article 6 assessment → conclusion → evidence

This creates an explanation that can be reviewed when the system changes.

It also addresses a common misconception: using AI in a sensitive industry does not automatically make every AI application high-risk. The intended use and regulatory conditions matter.

How Do Provider and Deployer Responsibilities Differ?

The organization also needs to establish its role.

A provider generally develops an AI system or has it developed and places it on the market or puts it into service under its name.

A deployer uses an AI system under its authority.

A company can hold both roles.

For example, a SaaS company could use a third-party AI recruitment tool for its own hiring while providing an AI-powered product to customers. The compliance responsibilities for those two systems may be different.

Role classification should therefore be recorded alongside the system’s risk classification. This prevents teams from creating a generic compliance checklist for systems with different regulatory responsibilities.

What Should Be Documented During High-Risk AI Development?

This is a critical area of preparation.

The EU AI Act requires providers of high-risk AI systems to prepare technical documentation and keep it up to date. The Commission’s framework also identifies documentation and record-keeping as core high-risk requirements.

The documentation should reflect the actual system, not a simplified description created months after development.

Depending on the system, teams should be prepared to maintain information covering areas such as:

• Intended purpose and system description
• System architecture and components
• Development and design methods
• Data used for training, validation and testing
• Risk management processes
• Testing and validation results
• Performance characteristics and limitations
• Human oversight arrangements
• Cybersecurity measures
• Relevant system changes
• Logging and monitoring arrangements

The important point is timing.

Documentation created during development is usually stronger than documentation reconstructed after development.

That is particularly relevant for teams building AI systems through rapid software release cycles.

How Should Businesses Establish Risk Management?

Risk management should operate throughout the AI system lifecycle.

A practical process can begin with identifying foreseeable risks and then move into assessment, mitigation, testing, and monitoring.

For example:

Identify a risk → assess its impact → define a control → test the control → record the result → monitor the outcome

The process should also define when reassessment is required.

A model update is one obvious trigger. So are significant changes to data, intended purpose, integrations, users or operating conditions.

This makes risk management a working engineering and governance process rather than a document prepared once for an audit.

How Should Businesses Manage Data Governance?

Data quality matters because high-risk AI systems can produce harmful outcomes when their training, validation or operational data is unsuitable for the intended purpose.

Businesses should establish where relevant data comes from, how it is processed, what quality controls exist, and how potential bias is identified and addressed.

For an AI system used in employment, for example, the team should be able to explain how relevant datasets were selected and validated and what steps were taken to identify potential discriminatory outcomes.

The focus should be on fitness for purpose and risk reduction, not simply collecting more data.

How Should Human Oversight Be Designed?

Human oversight should be visible in the workflow.

A policy saying “a human remains responsible” does not explain what that person actually does.

For each high-risk system, define:

• Who is responsible for oversight
• What information the reviewer receives
• When intervention is required
• What decisions the reviewer can override
• When the system can be stopped
• How interventions are recorded

The right design depends on the system.

For an AI recruitment tool, human oversight might involve reviewing recommendations before a hiring decision. For another system, intervention could mean suspending operation when performance falls below a defined threshold.

The oversight mechanism needs to match the risk.

How Should Accuracy, Robustness and Cybersecurity Be Tested?

Testing should not be left until the compliance deadline.

The AI Act identifies accuracy, robustness and cybersecurity as key requirements for high-risk AI systems.

A testing programme should reflect the actual use case. It may examine:

• Expected performance
• Failure conditions
• Unexpected inputs
• Security vulnerabilities
• Reliability
• Relevant bias risks
• Changes in model behaviour

A system used to rank job applicants, for example, may need different testing criteria from an AI component used in industrial machinery.

The test plan should therefore be linked to the risk assessment and intended purpose.

How Can Businesses Build Technical Documentation and Evidence Together?

Documentation explains the system. Evidence demonstrates what the organization actually did.

Those two functions should connect.

A useful evidence structure can follow:

AI system → risk → obligation → control → document → evidence → owner → review

For example, if human oversight is identified as an applicable requirement, the organization should be able to connect that requirement to the responsible role, the oversight procedure, training or competency records, relevant system controls, and records showing that the process was actually followed.

This is where compliance becomes operational.

The goal is not to accumulate files. It is to make the relationship between requirement, control, and evidence easy to reconstruct.

What Should a High-Risk AI Preparation Checklist Include?

Preparation area	What to establish before December 2027	Practical outcome
AI inventory	Systems, owners, versions, and intended purposes	Clear visibility
Classification	Documented Article 6 and Annex III assessment	Defined scope
Provider/deployer role	Role and responsibilities for each system	Clear accountability
Risk management	Risk identification, mitigation and reassessment	Controlled risk
Data governance	Relevant data quality and governance controls	Better data oversight
Technical documentation	Current system and development information	Traceability
Logging	Appropriate event and activity records	Operational evidence
Human oversight	Defined reviewers and intervention procedures	Meaningful oversight
Testing	Use-case-specific accuracy, robustness and security tests	Performance evidence
Evidence management	Linked records for controls and obligations	Audit readiness
Monitoring	Change and reassessment triggers	Lifecycle control

What About EU Database Registration?

Registration should also be part of the preparation plan.

Article 49 contains registration requirements for certain Annex III high-risk AI systems before they are placed on the market or put into service. It also contains a specific registration requirement where a provider concludes that an Annex III system is not high-risk under Article 6(3).

This is an important detail because an organization should not assume that an Article 6(3) conclusion means the system simply disappears from the regulatory workflow.

The registration analysis should therefore be included in the classification process rather than treated as a separate task at the end.

How Should Businesses Monitor High-Risk AI After Preparation?

High-risk AI compliance should be managed throughout the system lifecycle.

A new model version, dataset, integration, user group, or intended purpose can change the compliance assessment.

A practical release workflow could look like:

System change → reassess risk → review controls → update documentation → capture evidence → approve release

This creates a direct connection between AI development and compliance.

Regulatory monitoring matters as well. The European Commission is still developing guidance and standards for high-risk AI. The draft classification guidelines were published in May 2026, stakeholder consultation was extended through July, and the Commission says final guidelines are expected by the end of 2026.

Teams preparing for December 2027 should therefore expect their compliance process to evolve as additional guidance and standards become available.

What Should Businesses Do Between Now and December 2027?

The preparation period is easier to manage when it is broken into distinct stages.

1. Discover

Create the AI inventory and identify systems that could fall within Annex I or Annex III.

2. Classify

Document intended purpose, applicable route, risk category, provider/deployer role, and any Article 6(3) assessment.

3. Build

Establish risk management, data governance, documentation, logging, human oversight, testing and cybersecurity controls.

4. Connect the evidence

Link each applicable obligation to its control, owner, and supporting evidence.

5. Validate

Review the system against the applicable requirements and address any unresolved gaps before the deadline.

This sequence avoids the common mistake of treating compliance as a final documentation exercise.

Why Does AI Compliance Software Matter for High-Risk AI?

Managing one AI system through documents and spreadsheets may be manageable.

The situation changes when an organization has dozens of systems, multiple business owners, third-party models, different deployment environments, and changing regulatory obligations.

AI compliance software can bring those activities into a connected workflow.

For example, a team may need to move from:

AI inventory → classification → obligation mapping → documentation → evidence → monitoring

without manually rebuilding the same information in different systems.

For AI companies and SaaS businesses, that connection can make compliance easier to maintain as products change.<

The objective is not to create another dashboard for its own sake. It is to answer operational questions quickly:

Which AI systems do we have? Which ones may be high-risk? What obligations apply? Who owns them? What controls are active? What evidence supports them?

What Should European Businesses Do Now?

The December 2027 deadline is far enough away to allow thoughtful preparation. It is not far enough away to justify leaving the work until the final months.

Start with your AI inventory.

Then document the classification decision for each relevant system. Establish provider and deployer roles. Build the risk, data, documentation, oversight, testing, and evidence processes around the systems that may fall within the high-risk framework.

The biggest improvement comes from connecting those activities.

Classification should inform obligations. Obligations should inform controls. Controls should generate evidence. System changes should trigger reassessment.

That is a more durable model than maintaining a static compliance checklist.

How AnnexOps Helps Prepare High-Risk AI Systems

AnnexOps is AI compliance software designed to help organizations operationalize EU AI Act and GDPR compliance.

Its workflow supports AI system registration, Annex III risk classification, provider/deployer role classification, obligation mapping, documentation generation, evidence management, and continuous monitoring. AnnexOps also takes a developer-first approach through SDK and CI/CD integrations, helping teams connect compliance activities with existing AI development workflows.

For organizations preparing high-risk AI systems before December 2027, AnnexOps can provide a centralized workflow for connecting AI inventory, risk assessment, obligations, documentation, evidence, and monitoring.

The aim is practical: help teams move from fragmented compliance tracking toward a structured process that can evolve with their AI systems.

Author: Nitin Grover

Nitin Grover is an AI compliance strategist and writer focused on EU AI Act compliance, AI governance, Annex IV documentation, AI risk management, and AI compliance operations for AI startups, SaaS companies, and enterprise AI teams across Europe.