Migration Risk-Assessment AI: High-Risk Under Annex III Point 7

If your system scores the security, irregular-migration or health risk of a person arriving at a border — or sorts asylum, visa and residence applications — it is high-risk under Annex III point 7 of Regulation (EU) 2024/1689. That is the default the moment the use is by, or on behalf of, a competent public authority. The interesting questions are narrower: where does high-risk stop and the Article 5 prohibition begin, and what does a public body actually have to do before go-live.

This page draws those two lines. It is the operational sibling to the broader asylum, migration and border-control overview — here the focus is the risk-assessment use specifically, the prohibited boundary, and the Article 27 / Article 49(4) duties that bite on a public deployer.

The high-risk regime for stand-alone Annex III systems applies from 2 December 2027 under the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026 (the original date was 2 August 2026). Systems a public authority already uses before then must comply by 2 August 2030.

---

What Annex III Point 7 Actually Covers

Annex III point 7 names four uses in the migration, asylum and border-control field. Where AI is intended to be used by — or for — competent public authorities (or EU bodies acting in this field), the following are high-risk:

• (a) polygraphs and similar tools, where their use is not otherwise prohibited;
• (b) risk assessments — security risk, irregular-migration risk, or health risk — of a natural person who intends to enter, or has entered, a member state;
• (c) examination of applications for asylum, visa and residence permits, and associated complaints about eligibility, including assessments of the reliability of evidence;
• (d) detection, recognition or identification of natural persons, with the express exception of verifying travel documents.

Point (b) is the heart of the "migration risk-assessment AI" query. A model that ingests traveller data and outputs a security or irregular-migration risk score, used by a border authority, is squarely high-risk — there is no Annex III area where the stakes for the affected person run higher.

The travel-document carve-out in (d) is narrow and deliberate. Checking that a passport is genuine and matches its holder is not the high-risk identification use; running facial recognition to identify an unknown person against a watchlist is.

---

The Prohibited Line — Where Article 5 Takes Over

High-risk is not the ceiling. Two Article 5 prohibitions sit above this area, in force since 2 February 2025, and a system that crosses into them is not "high-risk with extra paperwork" — it is banned outright, carrying the top penalty tier of €35 million or 7% of worldwide annual turnover (Article 99(3)).

• Predictive policing of individuals (Article 5(1)(d)): AI that assesses or predicts the risk of a natural person committing a criminal offence based solely on profiling or personality traits is prohibited. A migration risk score that, in substance, predicts an individual's criminality from a profile rather than from objective, verifiable facts tied to criminal activity risks falling on the wrong side of this line.
• Real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes (Article 5(1)(h)): prohibited save for exhaustively listed exceptions. A border zone open to the public can be a publicly accessible space; live face-matching there for law-enforcement ends is presumptively banned.

The practical test: a risk assessment that informs a human official's lawful decision on entry or an application is high-risk and permitted with controls. A system that profiles a person to predict criminality, or runs live public biometric identification for policing, is prohibited. Draw this line before you build, not after.

---

What the Public Authority Has to Do

A migration authority deploying a high-risk risk-assessment system is a deployer (Article 26) and inherits two duties that most private deployers never face.

1. A Fundamental Rights Impact Assessment — Article 27. Because the deployer is a public body, a FRIA is mandatory before first use. It maps the processes the system will run, the categories of people affected, the specific risks of harm to their fundamental rights, the human-oversight measures, and what happens when risks materialise. A FRIA is not a GDPR DPIA (GDPR Article 35) — though Article 27(4) lets the FRIA build on an existing DPIA rather than duplicate it. For an area touching non-refoulement, the right to asylum and the right to an effective remedy, the FRIA is the document that matters most.

2. Registration in the restricted section of the EU database — Article 49(4). This is the detail people miss. Most high-risk systems register in the public part of the EU database (Article 49; the database itself is Article 71). But for Annex III point 7 — migration, asylum and border control — alongside law enforcement, deployers that are public authorities register in a non-public, restricted section accessible only to the Commission and relevant authorities. The sensitivity of the domain is the reason the register is shielded.

The deployer must also follow the provider's instructions for use, ensure input data is relevant, assign trained human oversight (Article 14), keep the automatically generated logs (Article 26), and inform affected persons where required.

The provider — whether an external vendor or the authority's own development team — carries the full Article 16 stack: risk management (Article 9), data governance (Article 10), technical documentation (Article 11 / Annex IV), accuracy and robustness (Article 15), the conformity assessment (Article 43, internal-control Annex VI route for point 7), the Declaration of Conformity (Article 47), and CE marking (Article 48).

---

Worked Example

Grenzschutz-Digital GmbH (a fictional EU vendor, ~70 employees, ~€11M turnover) builds a system that scores the irregular-migration risk of visa applicants and flags files for closer review by case officers at a national migration agency.

• Classification: high-risk under Annex III(7)(b) and (c) — risk assessment plus examination of applications, used for a competent public authority.
• Prohibited-line check: the score must rest on objective, case-specific factors and feed a human decision; it must not predict an individual's criminality from profiling alone (Article 5(1)(d)). The team documents that the model does not do this.
• Vendor (provider) duties: Article 9 risk management, Annex IV documentation, Annex VI conformity assessment, an Article 47 Declaration of Conformity, CE marking.
• Agency (deployer) duties: an Article 27 FRIA before go-live, Article 49(4) registration in the database's restricted section, Article 14 human oversight, log retention.
• Fine exposure: a provider/deployer breach sits at €15M or 3% (Article 99(4)); crossing into a prohibited practice would jump to €35M or 7% (Article 99(3)). Under Article 99(6), for a company of Grenzschutz-Digital's size the fine is the lower of the percentage or the fixed sum.

The verdict: build it, but the FRIA and the prohibited-line analysis are the two pieces of work that decide whether this is lawful, not the paperwork that comes after.

---

How Confir Helps

Confir registers each AI system, classifies it under Articles 5 and 6 with Annex III logic through plain-English checklists, and derives whether you are acting as provider or deployer. For an Annex III point 7 system it surfaces the prohibited-practice flags, runs the Article 27 FRIA, and assembles the Article 11 / Annex IV documentation. The classification engine is rule-based and deterministic — the same intake produces the same finding, and the rule that fired is written in plain language you can show an auditor.

---

Related guides

• Asylum, migration and border-control AI overview
• Visa application AI under Annex III
• Asylum application AI
• Border-control AI
• Article 5 prohibited practices
• The FRIA under Article 27
• How Annex III classifies high-risk AI