"Does the AI Act apply to us?" is the first question every project owner asks, and the honest answer is a short chain of smaller questions. Each one has a provision behind it. This walk-through follows that chain in the order a screening tool would ask it, explains what each answer changes, and ends with the two outcomes people misread most: "out of scope" and "requires review".
Step 1: is there an AI system at all?
Art. 3(1) defines an AI system as a machine-based system designed to operate with varying levels of autonomy, that may adapt after deployment, and that infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions. The operative word is infers. A trained model infers. A large language model infers. A decision table that applies fixed rules written by a policy officer does not, even if it is called an algorithm in the organisation's register.
Two practical tests help. First, was anything trained on data? Second, does the output depend on learned parameters rather than on rules a person could read and rewrite? If both answers are no, the AI Act's system-level duties are unlikely to attach, though the GDPR and national law still apply to what the system does with personal data.
If the answer is unclear, record it as unclear. A scoping decision that starts with a guess about the definition is the one most likely to be overturned later.
Step 2: which role do you hold?
Art. 3(3) and 3(4) separate the provider, who develops a system and places it on the market or puts it into service under its own name, from the deployer, who uses a system under its own authority. The lists of duties are different, so nearly everything downstream depends on this answer.
Look at the procurement file. A system bought and used as delivered makes you a deployer. A system your own team trained, or one you put your name on, makes you a provider as well. The borderline case is modification: under Art. 25 a deployer that substantially modifies a high-risk system, or changes its intended purpose so that it becomes high-risk, takes on the provider's duties for the modified system. Retraining a vendor's model on your own case data is the usual example.
"Unsure" is an acceptable answer at this stage, but it makes every later classification provisional.
Step 3: which Annex III areas does it touch?
Annex III lists eight areas. A system used in any of them is high-risk under Art. 6(2) unless a documented Art. 6(3) derogation applies. For a Dutch public body the areas that come up most are point 5(a), eligibility for public assistance benefits and services; point 4, employment and worker management; point 3, education; point 6, law enforcement; and point 7, migration and border control. Point 8 covers the administration of justice and democratic processes. Point 1, biometrics, and point 2, critical infrastructure, appear less often but carry their own particular rules.
Answer this from the purpose of the system, not its technology. A language model that drafts letters is not in Annex III. The same model used to score applications for a benefit is.
Step 4: does an exclusion apply?
Art. 2(3) removes systems used exclusively for military, defence or national security purposes. Art. 2(6) removes systems and models developed and put into service for the sole purpose of scientific research and development. Art. 2(8) also excludes research and testing before a system is placed on the market, but not testing in real-world conditions.
These are the answers that most often go wrong, because claiming an exclusion is easy and defending one is not. Ask for the written decision that established the system and check that it says "exclusively". A system a defence organisation also uses for ordinary administration does not qualify. A prototype a research group hands to an operational team has left the research exclusion.
Step 5: what kind of body deploys it?
Art. 27(1) puts the fundamental rights impact assessment on deployers that are bodies governed by public law or private entities providing public services, and on any deployer of a creditworthiness or life and health insurance system. Art. 49(3) adds registration in the EU database for deployers that are public authorities. So the constitutional position of the deploying organisation decides two of the heaviest deployer duties. A ministry, a province, a municipality or a water authority is a body governed by public law. A privately run school or care provider is a private entity providing a public service, which owes the assessment but not the public-authority registration.
Step 6: which Art. 50 features does it have?
Art. 50 attaches per feature, whatever the risk classification. Does a person talk to the system directly? Does it infer emotions or categorise people by biometric data? Does it generate image, audio or video that could pass for real, or text published to inform the public on matters of public interest? Each yes is a disclosure duty, and a system with none of the Annex III areas can still owe several of these.
A worked example
The fictional municipality of Zilverdam runs a chatbot on its website that answers questions about parking permits. The same team is piloting a model that flags permit applications for manual checking.
The chatbot: an AI system, deployed, no Annex III area, an Art. 50(1) feature. Result: disclosure duty, AI literacy, and GDPR for the chat logs. The flagging model: an AI system, deployed, and it decides which residents get scrutiny for a municipal service. Whether that is Annex III point 5(a) depends on whether a parking permit counts as an essential public service, which is a genuine question for counsel. The right screening outcome is "requires review", with the question written down.
What "out of scope" and "requires review" mean
Out of scope means an Art. 2 exclusion is claimed. It is not a finding that the system is harmless. It is self-declared, narrow, and should be recorded with the reasons. The GDPR, sector rules and national law continue to apply to the same system, and any Art. 5 signals should still be examined, because claiming an exclusion on top of a possible prohibited practice is exactly the situation a supervisory authority will look at.
Requires review means the inputs do not decide the point. An unsure answer, a missing answer, or a trigger condition that could not resolve all lead here. It is not a quiet no and it is not a soft yes. It is an instruction to a person: look, decide, and record the decision with your name on it. A screening that resolved these silently would be guessing on your behalf.
How Landfall helps
Landfall asks the six steps above, in this order, and reads the codebase and any Algoritmeregister entry first so that fewer questions are left to answer by hand. Suggestions from those sources are shown with their evidence and become answers only when a person confirms them. An unanswered classification question produces "undetermined", a claimed exclusion produces "out of scope" with a note that data-protection law still applies, and an unsure answer produces a review item that is printed in the report rather than dropped.