AI in Asylum and Migration Processing: High-Risk Under Annex III Point 7
Asylum AI falls under Annex III point 7 — high-risk. Deployers need Article 26 duties, Article 27 FRIA, and Article 49 registration by 2 December 2027.
An AI system that helps a public authority evaluate an asylum claim, assess the risk posed by a border crosser, or examine a residence permit application is high-risk under EU AI Act Regulation (EU) 2024/1689. That classification flows directly from Annex III, point 7 — Migration, asylum and border control — and it is not a borderline case. The fundamental rights at stake make this one of the most consequential segments of the high-risk list.
The deployers in this space are almost always public bodies: national asylum offices, border control authorities, immigration ministries, or contractors acting on their behalf. That changes several things. It puts the Article 27 Fundamental Rights Impact Assessment (FRIA) in play. It routes EU-database registration to the non-public section under Article 49. And it adds a dimension that pure commercial compliance rarely carries: the people affected are often vulnerable, lack legal representation, and face consequences — deportation, detention, family separation — that cannot be undone.
What Annex III Point 7 Actually Covers
Annex III, point 7 designates as high-risk any AI system intended for use by competent public authorities, or on their behalf, for:
- Assessing risks posed by natural persons in migration, asylum or border control — including security risks, irregular-migration risks, and health risks
- Assisting in the examination of applications for asylum, visa or residence permits, and associated complaints
- Detecting, recognising or identifying persons in the context of migration, asylum and border control
The third item — detecting or identifying persons — explicitly excludes document verification. A system that checks whether a passport is genuine is not automatically in point 7. A system that identifies who a person is, or flags them as a risk, is.
The phrase "intended to be used" is important. If a general-purpose analytics tool is configured and deployed for asylum case assessment, that intended use determines the classification — not the vendor's original design.
Where the Prohibition Boundary Sits
Not everything in this domain is high-risk. Some things are outright prohibited under Article 5.
Biometric categorisation of persons using sensitive attributes — race, ethnicity, political opinions, religious beliefs, nationality inferred from physical appearance — is prohibited under Article 5(1)(g). A system that screens border crossers by assigning them nationality-risk profiles derived from biometric traits crosses that line. The prohibition has been in force since 2 February 2025; there is no grace period.
Emotion recognition in a non-medical, non-safety context raises its own Article 5(1)(f) question. Systems marketed as detecting deception or emotional state during asylum interviews warrant serious scrutiny before deployment.
The distinction matters: prohibited practices carry a penalty ceiling of €35,000,000 or 7% of worldwide turnover under Article 99(3), compared to €15,000,000 or 3% for high-risk compliance failures under Article 99(4). Before classifying a migration AI system as high-risk, confirm it does not fall on the prohibited side of the line.
The Article 6(3) Exemption Is Not Realistic Here
Article 6(3) allows a provider to conclude that an Annex III system is not high-risk if it poses no significant risk of harm to health, safety or fundamental rights — for instance, because it performs a narrow procedural task, improves a previously completed human activity, or detects decision patterns without influencing individual assessments.
For asylum and migration AI, this exemption is almost never available in practice. The systems that warrant point 7 coverage are precisely those that shape case outcomes for individuals. An eligibility-scoring tool that feeds into an interviewer's framing of a claim; a risk-assessment model that flags someone for secondary inspection; a system that ranks applications by apparent credibility — each of these influences an individual determination. That is the definition of what the regulation is trying to govern.
Any system that profiles natural persons is always high-risk under Article 6(3)'s own terms. Most migration AI does exactly that.
A provider that does invoke Article 6(3) must document the self-assessment and still register the system in the EU database under Article 49.
Who Deploys These Systems and What That Means
The dominant role in migration and asylum AI is the deployer — the public authority that puts an existing system into operation. National immigration agencies are rarely developing their own AI from scratch; they procure or commission systems and run them within their processes.
Deployers carry a substantial obligations stack under Article 26. They must:
- Use the system in accordance with the provider's instructions for use
- Ensure human oversight is operational — not just documented, but genuinely exercised
- Monitor the system's performance against its documented capabilities and flag risks or incidents to the provider
- Retain the logs generated by the system for at least six months (Article 26 — cite the article, not a sub-paragraph, as the exact numbering is disputed in secondary sources)
- Inform the individuals affected that an AI system is being used in a decision that concerns them
When the deployer is a public body using a high-risk system that affects the rights of natural persons, Article 27 also requires a Fundamental Rights Impact Assessment before deployment begins.
If a national agency substantially modifies a procured system — adapting its models, extending its intended purpose, retraining it on domestic data — it may become the provider under Article 25. That shifts the full provider stack onto the agency, including conformity assessment under Article 43 and technical documentation under Article 11.
The FRIA Obligation for Public-Body Deployers
Article 27 is one of the most operationally significant requirements for this use case. Public authorities deploying high-risk AI that affects the rights of natural persons must complete a Fundamental Rights Impact Assessment before the system goes live.
In the asylum context, that assessment must engage seriously with:
Non-refoulement and the right to asylum (EU Charter Articles 18 and 19). An incorrect rejection recommendation that goes unchallenged by a fatigued caseworker can set in motion a deportation to a country where the person faces persecution. The FRIA must address how the system's error profile interacts with human oversight in practice — not just in design.
Equal treatment across protected grounds. Training data for asylum assessment systems typically reflects historical decision patterns. Historical patterns in asylum systems have been challenged in multiple EU jurisdictions for nationality-based disparities. The FRIA must examine whether the system perpetuates those patterns and what disaggregated performance testing has been done.
Procedural rights. Applicants have a right to know that an AI system is involved in assessing their case, and to understand the basis of a decision. This connects to the transparency requirements under Article 13 (information to deployers, who pass it on to affected individuals) and the human oversight requirements under Article 14.
The FRIA itself. Article 27 permits the assessment to build on an existing GDPR Data Protection Impact Assessment (DPIA) under GDPR Article 35, if one has been conducted. These are related but distinct exercises: the DPIA focuses on data processing risk; the FRIA addresses the broader spectrum of fundamental rights. The FRIA subsumes and extends the DPIA, it does not replace it.
The completed FRIA feeds into the EU database registration. Under Article 49, deploying public bodies register in the non-public section of the EU database maintained under Article 71. This is not optional, and it is a separate act from any registration the provider may have done.
Conformity Assessment: Annex VI Internal Self-Assessment
Annex III point 7 falls outside point 1 (biometrics). That means conformity assessment follows the Annex VI internal self-assessment route under Article 43 — providers conduct the assessment themselves without a notified body. This is a significant practical distinction from biometric AI (which may require a notified body under Annex VII) but it does not reduce the documentation burden.
The provider must complete the Annex VI assessment before the system is placed on the market or put into service. For a system purpose-built for a government agency, "put into service" is the operative trigger. The assessment covers compliance with Articles 9 through 15 — risk management system, data governance, technical documentation, logging, transparency, human oversight, and accuracy and robustness.
After the assessment, the provider issues an EU Declaration of Conformity under Article 47 and registers the system in the EU database under Article 49. The deploying public body then performs its own verification that the system is functioning as documented within the specific institutional environment, and conducts the FRIA.
What the Obligations Require in Practice
A national asylum office deploying a case-triaging tool that scores incoming applications by apparent eligibility and flags complex cases for specialist review needs to address these requirements before 2 December 2027:
From the provider (the system developer or vendor):
- A risk management system under Article 9, identifying foreseeable misuse scenarios and data-representation risks for the specific applicant populations the system will process
- Technical documentation under Article 11 / Annex IV, including disaggregated performance metrics by nationality, age, gender, and other relevant characteristics
- A logging system under Article 12 that captures the system's outputs and the inputs that generated them
- Instructions for use under Article 13 that enable the deployer to operate the system within its documented scope
- Design features that enable human oversight under Article 14 — case officers must be able to understand the system's reasoning and override its outputs without technical barriers
- Post-market monitoring under Article 72, with a mechanism to feed incident data from the deployer back to the provider
From the deploying public authority:
- Verification that the provider has completed the Annex VI conformity assessment
- Operational implementation of human oversight: trained staff, clear protocols for overriding the system, documented override tracking
- Log retention for at least six months under Article 26
- An Article 27 FRIA completed before deployment, addressing non-refoulement, equal treatment, procedural rights, and the specific decision environment
- Registration in the non-public section of the EU database under Article 49
- Notification to applicants that an AI system contributes to the assessment of their case
The Deadline
Under the Digital Omnibus agreed in May 2026, the obligations for stand-alone high-risk Annex III systems apply from 2 December 2027 — deferred from the original 2 August 2026 date. For systems that are safety components of regulated products under Annex I, the date is 2 August 2028, but asylum and migration AI does not fall into that category.
The December 2027 date is the compliance deadline, not the preparation start date. Assembling technical documentation, completing disaggregated performance testing, conducting a credible FRIA, and training casework staff takes time that the headline date does not convey. Public authorities that commission procurement processes in 2026 are already shaping whether they will reach that deadline with adequate documentation.
How Confir Helps
Confir's classification engine works through Annex III point 7 logic using plain-English scenarios to determine whether a migration or asylum AI system is high-risk and what role your organisation holds — provider under Article 16, deployer under Article 26, or a hybrid where Article 25 applies.
For deploying public authorities, Confir runs the Article 27 FRIA workflow as a structured assessment — mapping the system against the relevant fundamental rights, documenting proportionality analysis, and generating the output required for EU database registration. The structured assessment also covers the deployer obligations under Article 26 across Confir's four compliance areas: classification, data and technical robustness, transparency and human oversight, and governance and post-market monitoring.
Everything the tool produces is generated by deterministic, rule-based logic — the same inputs produce the same finding, the rule that fired is human-readable, and the output is audit-defensible by design.
Frequently Asked Questions
Does Annex III point 7 apply if we only use AI to prioritise which cases to review first, not to make the decision?
Yes. The classification covers systems used to assist in the examination of applications — which includes any tool that shapes how caseworkers approach a claim. A prioritisation model that sends applications to the front of the queue or flags them for specialist review is influencing the examination process. The relevant question under Article 6(3) is whether the system influences the individual assessment; a triaging tool that affects case outcomes for specific applicants does. Assume high-risk applies and document the assessment.
Who registers in the EU database — the technology vendor or the asylum office?
Both may need to act, but their registrations serve different purposes. The provider registers the system under Article 49 in the general section as part of conformity assessment. The deploying public body registers separately in the non-public section of the EU database (maintained under Article 71) before deployment. The non-public section exists specifically for public authorities deploying high-risk AI affecting natural persons — it is a separate obligation from the provider's registration, not a duplication of it.
Is the FRIA the same as a GDPR Data Protection Impact Assessment?
No. A DPIA under GDPR Article 35 focuses on data processing risk and is triggered by high-risk data processing involving personal data. The Article 27 FRIA addresses fundamental rights more broadly — non-refoulement, equal treatment, access to justice, procedural guarantees — beyond what GDPR covers. Article 27(4) explicitly allows the FRIA to be built on an existing DPIA where one is available. If your organisation has conducted a DPIA for the same system, start there and extend it to cover the full FRIA scope.
What penalties apply for non-compliance?
Violations of the high-risk obligations — deploying without conformity assessment, inadequate human oversight, missing FRIA — fall under Article 99(4): a maximum of €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. The Article 99(6) cap for SMEs and start-ups reduces this to the lower of the percentage or fixed sum, but that provision is unlikely to help a national immigration authority. If a system crosses into prohibited territory under Article 5 — for example, biometric categorisation by sensitive attributes — the ceiling rises to €35,000,000 or 7% under Article 99(3).
Can private contractors who operate asylum AI on behalf of a government authority be deployers?
Yes. Article 26 covers any person who uses a high-risk AI system in a professional context under their authority — including contractors operating systems on behalf of a public authority. The phrase "or on their behalf" in Annex III point 7 was drafted precisely to capture this. A private IT firm running a case-triaging system on behalf of a national immigration agency is a deployer. The agency that has commissioned the contract must also ensure compliance, and they share responsibility for the Article 27 FRIA.
Does the deadline change if the system was deployed before the regulation took effect?
No extension applies simply because the system pre-dates the Act. Systems already in use when the high-risk obligations apply from 2 December 2027 must comply from that date. Operators should treat existing deployments as the most urgent case for documentation and assessment work — retrofitting a FRIA and technical documentation onto a live system is harder than building compliance in from the start of a new procurement.
Related guides
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 →