AI in Border Control and Migration Management: EU AI Act High-Risk Classification
Annex III point 7 makes border and migration AI high-risk. Understand scope, the Art 5 prohibited boundary, FRIA, and the 2 December 2027 deadline.
Annex III, point 7 of the EU AI Act (Regulation (EU) 2024/1689) places AI systems used for migration, asylum, and border-control management in the high-risk tier. If your organisation builds or deploys such a system, the full obligation stack applies — and part of it sits close to the line between high-risk and outright prohibited. Getting that line right is the first task.
What Annex III Point 7 Actually Covers
The text of Annex III, point 7 names four distinct categories:
- Polygraph-like tools and deception-detection systems used by or on behalf of competent authorities in migration or border contexts.
- Risk-assessment tools that evaluate the risk — security, irregular migration, or health — posed by a natural person intending to enter the EU or already present.
- Application-examination tools assisting in the assessment of asylum claims, visa applications, and residence permits, including tools that evaluate the reliability of evidence.
- Identification tools that detect, recognise, or identify natural persons in the migration or border context — with one explicit carve-out: verification of travel documents is excluded from this point.
That carve-out matters. An OCR tool that reads a passport chip and confirms name, date of birth, and document number against the bearer is not automatically high-risk under point 7. A system that then cross-references the traveller against a risk database, or scores the likelihood of irregular intent, is a different matter.
The Prohibited-Practice Boundary
Before asking whether a system is high-risk, ask whether it is banned outright.
Article 5(1)(g) prohibits AI systems that categorise natural persons based on biometric data to infer or deduce their race, political opinions, trade-union membership, religious beliefs, sexual orientation, or health. A system that attempts to derive ethnicity or religion from facial geometry to inform a border decision is prohibited — not merely high-risk — and that prohibition has been in force since 2 February 2025.
Article 5(1)(h) prohibits real-time remote biometric identification (RBI) of natural persons in publicly accessible spaces for law enforcement purposes, except in narrowly defined emergency scenarios. Border checkpoints are publicly accessible spaces. A live CCTV sweep that identifies individuals by face against a watchlist is prohibited. A one-to-one gate verification — comparing a presented biometric to the passport chip of the traveller standing at the gate — is not real-time remote biometric identification and remains permissible under point 7, subject to the high-risk obligations.
Keep these two questions separate: does the system cross an Article 5 line, or does it sit in the Annex III high-risk zone? The answer changes the entire regulatory response.
Article 6(3) and the Self-Assessment Exemption
Article 6(3) allows a provider to claim that an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights. The conditions are narrow: the system must perform a purely procedural task, improve a previously completed human activity, detect decision patterns without influencing or replacing human assessment, or carry out preparatory work only. Crucially, any system that profiles natural persons falls back into the high-risk tier regardless.
In border and migration contexts, the Article 6(3) exemption almost never applies. Risk-scoring, eligibility assessment, or identification tools touch natural persons directly and consequentially. A provider claiming the exemption must document the assessment and register it under Article 49 — there is no silent opt-out.
The Obligation Stack for Providers
Classification as high-risk triggers the Chapter III obligations in their entirety. For border-control AI, the following deserve particular attention.
Risk management system (Article 9). You must establish, document, and maintain a risk management system throughout the system's lifecycle — not only at launch. For this use case, the system must explicitly address discrimination risks across ethnicity, nationality, gender, and age; failure modes under adverse conditions; and the downstream consequences of errors (wrongful detention, asylum refusal, deportation). Residual risks must be documented and accepted with justification.
Data and data governance (Article 10). Training data must be representative of the populations the system will encounter at deployment, including demographic groups that are historically underrepresented in border-crossing datasets. Bias in training data reproduces bias in outcomes; Article 10 requires you to identify and address it, not merely note it.
Technical documentation (Article 11, Annex IV). The documentation package must be compiled before the system is placed on the market or put into service. It covers architecture, training data composition and sourcing, validation methodology, performance metrics disaggregated by demographic group, known limitations, and intended deployment conditions. This documentation is the foundation for conformity assessment and the starting point for any regulatory investigation.
Transparency to deployers (Article 13). Instructions for use must give border authorities clear information on what the system can and cannot do, the conditions under which it should not be used, and the human oversight measures that must be in place. Deployers cannot meet their own obligations without this information.
Human oversight (Article 14). The system must be designed so that border officers can monitor outputs in real time, detect anomalies, and override or halt the system. This is not a soft requirement. Under Article 14(4), the measures must ensure that no consequential decision flows from the system without a human being able to intervene and stop it. For a risk-scoring tool recommending detention or denial of entry, that means a trained officer must review and accept the recommendation before it takes effect.
Accuracy, robustness, cybersecurity (Article 15). Border systems face adversarial inputs — document forgeries, presentation attacks on biometric sensors, deliberate manipulation of declared information. Article 15 requires the system to be resilient to these and to fail safely when inputs fall outside expected parameters.
Conformity assessment (Article 43). Stand-alone border-control AI follows the Annex VI internal self-assessment route — the provider conducts the assessment, documents it, and issues the EU Declaration of Conformity (Article 47) before market placement. No notified body is required for this category. A biometric gate that is a safety component of a physical product regulated under EU harmonisation law would instead follow the Annex I / Annex VII notified-body route, with the 2 August 2028 deadline — but that path applies to the product as a whole, not to a standalone software tool.
Registration (Article 49, non-public entry). Providers must register high-risk border and migration AI systems in the EU database before placing them on the market. Because competent authorities are the deployers in this context, the registration entry for point 7 systems is not publicly accessible — a specific rule for migration and border systems that reflects the sensitivity of the information. The obligation to register still applies; the entry is simply withheld from the public-facing database.
Post-market monitoring (Article 72) and serious-incident reporting (Article 73). Once deployed, the system requires a post-market monitoring plan. If the system causes or contributes to a serious incident — for example, wrongful detention resulting in harm — the provider must report to the relevant market-surveillance authority within the timelines set by Article 73: 15 days from awareness of a serious incident (Article 73(2)); 2 days for widespread infringement or serious disruption of critical infrastructure (Article 73(3)); 10 days if a death has occurred (Article 73(4)).
Deployer Obligations: Public Authorities Bear the Heavier Weight
In the border and migration context, the deployer is almost always a public authority — a border agency, immigration service, or national police force. This matters for one significant obligation.
Article 27: Fundamental Rights Impact Assessment (FRIA). Public bodies deploying high-risk AI must conduct a FRIA before putting the system into operation. This is not a one-time checkbox. The FRIA must identify the categories of natural persons affected (asylum seekers, transit passengers, irregular entrants, family-reunification applicants), assess the likelihood and severity of potential harm to fundamental rights (non-discrimination, right to asylum, protection from refoulement, right to an effective remedy), describe mitigation measures, and document stakeholder consultation. For border and migration AI, the FRIA is likely to be the most demanding document in the compliance file.
Article 26: General deployer duties. Beyond the FRIA, deployers must use the system only for its intended purpose and in accordance with provider instructions; ensure staff responsible for human oversight have the training, authority, and competence to intervene; maintain logs of operation for at least six months (Article 26); and monitor the system for anomalous behaviour and report serious incidents or risks to the provider.
Article 14 in practice. Designing human-oversight capability into a system is the provider's job. Ensuring it is actually exercised is the deployer's. A border agency that deploys a risk-scoring tool but trains officers only on how to read the output — not on when and how to override it — is failing its Article 26 obligations regardless of what the provider's instructions say.
The Deadline
Under the Digital Omnibus (political agreement reached 7 May 2026, formal adoption expected before 2 August 2026), the high-risk obligation date for stand-alone Annex III systems has moved to 2 December 2027, deferred from the original 2 August 2026. The prohibition obligations in Article 5 remain in force from 2 February 2025 — those do not move.
The shift to December 2027 is real breathing room. It is not a relaxation of what must be done. Risk management systems, technical documentation, and a FRIA for a border-control tool each take months to produce correctly. An authority procuring a new system today should be building compliance requirements into the tender, not leaving them for 2027.
The fine ceiling for non-compliance with the high-risk requirements is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For public authorities, national law typically determines whether fines apply directly, but the reputational and operational consequences of a supervisory finding are substantial regardless.
How Confir Helps
Confir's rule-based classification engine handles three of the most time-consuming steps. Enter your system's description in plain English: Confir determines whether it falls under Annex III point 7, applies the Article 6(3) filter, and derives your role — provider (Article 16) or deployer (Article 26) — from the same intake.
For deployers that are public authorities, the Article 27 FRIA workflow generates a structured assessment document across the standard sections: affected groups, rights at stake, likelihood and severity of harm, mitigation measures, and consultation record. The output is audit-ready and version-controlled.
For providers, the Annex IV technical documentation package and the Article 47 Declaration of Conformity are generated from the same compliance data. No separate drafting cycle.
The engine is deterministic and reproducible — same inputs, same output, every time. For a compliance process where an auditor or supervisory authority may ask you to demonstrate how a finding was reached, that traceability matters.
Frequently Asked Questions
Is travel-document verification high-risk under Annex III point 7?
No. Annex III, point 7 explicitly excludes the verification of travel documents. A system that reads a passport chip and confirms the bearer's identity against the document is not captured by this point. However, if that system then feeds the result into a risk-scoring or profiling tool, the downstream system may be high-risk, and the combination may need to be assessed as a single pipeline.
What is the difference between a prohibited system and a high-risk one in border contexts?
A prohibited system under Article 5 cannot be deployed regardless of safeguards — the practice itself is banned. Real-time remote biometric identification of individuals in public spaces for law enforcement, and systems that categorise people by sensitive characteristics inferred from biometric data, are prohibited since 2 February 2025. A high-risk system under Annex III is lawful to deploy if you meet the full compliance stack: risk management, technical documentation, human oversight, conformity assessment, and registration. Getting these two categories wrong in either direction is a serious error.
Does a public authority always need a FRIA for border-control AI?
Yes. Article 27 requires a Fundamental Rights Impact Assessment from public bodies deploying high-risk AI systems. In the migration and border-control context this is categorical — the deployer is a public authority by definition when the system is used for border management. The FRIA must be completed before the system goes into operation, not retrospectively.
Where is my system registered, and is it public?
Article 49 requires registration in the EU AI database before market placement. For Annex III point 7 systems used by competent authorities in migration, asylum, and border control, the registration entry is not made publicly accessible. The obligation to register is unchanged — you must still submit the entry — but it is not visible to the public. This exception reflects the sensitivity of operational border data.
What are the deadlines and what happens if I miss them?
Stand-alone high-risk Annex III systems must comply by 2 December 2027 (deferred from 2 August 2026 under the Digital Omnibus agreed May 2026). Article 5 prohibitions have applied since 2 February 2025. The maximum fine for non-compliance with the high-risk obligation stack is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). The fine applies to providers and deployers independently.
What conformity assessment route applies to border-control AI?
For stand-alone software tools — risk-scoring systems, eligibility-assessment tools, biometric identification software — the route is Annex VI internal self-assessment (Article 43). The provider documents compliance, conducts the assessment internally, and issues the Article 47 EU Declaration of Conformity without a notified body. A biometric gate that is a safety component of an Annex I regulated product follows the notified-body route under Annex VII, with a later deadline (2 August 2028).
Who is the deployer for border-control AI, and what are the most critical deployer obligations?
The deployer is the competent authority — border agency, immigration service, or equivalent public body — that puts the system into operation under its own authority. The most demanding deployer obligations are the Article 27 FRIA, the Article 14 human-oversight duty (ensuring officers have genuine authority and training to override the system), and the Article 26 log retention requirement of at least six months. Authorities that contract out deployment to a third party must verify that Article 25 role-shift rules do not inadvertently make that third party a provider.
Related guides
- Article 9 risk management system
- high-risk AI classification test
- Article 6 high-risk criteria
- high-risk AI obligations
- Article 49 registration obligations
- Annex III high-risk categories
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →