Questionnaire field guide

This guide lists every question Landfall asks on a project scoped to the EU AI Act and the GDPR, in the order the questionnaire asks them. For each one it gives three things: the question in plain language, why it is asked and which provision the answer feeds, and where the answer normally lives inside a Dutch public body.

The plain-language and "why we ask" text is read directly from the questionnaire's own content, so this page and the form cannot disagree. The "where the answer lives" line is written for a Dutch public-sector reader and is guidance, not law.

Three habits make the questionnaire much shorter:

• Connect the repository first. The codebase scan pre-fills several answers as suggestions, never as answers — you still confirm each one.
• Import the Algoritmeregister entry if this algorithm is already published. Landfall reads it back into suggestions rather than making you retype it.
• Answer "Unsure" honestly. An unsure answer routes the item for review; a guess produces a verdict nobody can defend.

What the system does with personal data. These answers drive the GDPR half of the pre-scan: the Art. 22 question about automated decisions, the Art. 35 DPIA screening and the Art. 30 records duty.

In plain language. Do you handle any data that relates to an identifiable person?

Why we ask. Processing personal data at all is what brings GDPR-style regimes into play; 'personal data' is defined very broadly.

Where the answer lives. The register of processing activities that your data protection officer keeps under Art. 30 GDPR. For a system that is not in the register yet, the processing description in the project start document.

In plain language. What kinds of personal data do you actually collect?

Why we ask. The categories you hold decide which data-protection duties attach. Art. 30(1)(c) GDPR requires them to be recorded, and a category that falls under Art. 9 narrows the grounds on which you may process it at all.

Where the answer lives. The processing entry for this system in the register of processing activities, plus the data dictionary or table definitions the engineering team maintains. Where a supplier runs the system, the processing annex to the processor agreement lists them.

In plain language. Setting the legal labels aside, do you collect any of these particular data types?

Why we ask. These are the data types Art. 9(1) GDPR treats as special categories, which narrows the lawful grounds for processing them and is one of the screening criteria for a data protection impact assessment under Art. 35(3)(b). We ask for the concrete types and derive the legal classification ourselves, so you answer facts rather than law.

Where the answer lives. The same data dictionary as the previous question. In a Dutch public body the DPIA — or part 2 of the IAMA, 'Wat' — usually lists the special categories already; if the DPIA says there are none, that is the answer.

In plain language. How long do you keep user data before deleting it?

Why we ask. Storage limitation under Art. 5(1)(e) GDPR requires data to be kept no longer than the purpose needs, and Art. 30(1)(f) requires the envisaged period to be recorded. For a public body the Archiefwet selection list sets that period, so the two have to agree.

Where the answer lives. The selection list (selectielijst) under the Archiefwet that covers this process, and the retention column of the register entry. The two must agree; where they do not, the selection list governs the records the Archiefwet covers.

In plain language. Do you pass user data to anyone outside your own company?

Why we ask. Recipients have to be recorded under Art. 30(1)(d) GDPR, and every processor acting on your behalf needs a contract meeting Art. 28. Hosting suppliers, analytics providers and the supplier running the model all count.

Where the answer lives. The recipients and processors listed in the register entry, the processor agreements in the procurement file, and — for a cloud service — the sub-processor list the supplier publishes.

In plain language. Does your system decide something about a person on its own, with no person meaningfully reviewing it, where the outcome really matters to them?

Why we ask. GDPR Art. 22 restricts decisions based solely on automated processing that produce legal effects or similarly significantly affect someone, and gives the person a right to human intervention.

Where the answer lives. The casework procedure and the mandate decision: who signs the decision, and can that person in practice depart from the model's output? A caseworker who only counter-signs is not meaningful human involvement.

In plain language. Which of these descriptions fit what you do with people's data?

Why we ask. These are the screening criteria European regulators use (EDPB guidelines WP248 rev.01) to decide whether a Data Protection Impact Assessment is needed under GDPR Art. 35; meeting two or more normally means one is expected.

Where the answer lives. The DPIA itself where one exists, or the pre-DPIA screening your data protection officer runs. Note separately that the Autoriteit Persoonsgegevens publishes a national list of processing operations for which a DPIA is always mandatory under Art. 35(4); Landfall does not model that list, so check it yourself.

In plain language. How many people work for the organisation as a whole, counting everyone, not just this product team?

Why we ask. GDPR Art. 30(5) lets an organisation employing fewer than 250 people skip the records-of-processing duty - but only if none of its carve-backs apply, so the number on its own is not the answer.

Where the answer lives. The organisation's own personnel figures for the whole legal entity, not the department. For a ministry, a province or a municipality the number is far above 250 and the derogation never applies.

In plain language. Do you handle people's data only now and then, rather than as a routine part of how the service runs?

Why we ask. GDPR Art. 30(5) takes the small-organisation exemption away as soon as processing is 'not occasional', and regulators read that narrowly - a customer list or an HR file is routine, not occasional.

Where the answer lives. The process description. A statutory task carried out continuously is routine by definition, so for a public body the answer is normally no.

In plain language. Could this processing create a risk to the people whose data you handle?

Why we ask. Article 30(5) uses a risk threshold, which is broader than the high-risk DPIA test. A small organisation cannot rely on that exemption merely because it has no DPIA flags.

Where the answer lives. The documented assessment of this processing activity's risks to people. Ask the privacy lead to resolve the Article 30 test; a negative DPIA pre-scan alone is insufficient.

In plain language. Do you process any of the listed special categories, including data received or inferred?

Why we ask. Processing Article 9(1) data removes the small-organisation records exemption for that processing.

Where the answer lives. The data inventory and process description, including information received from others or inferred by the system. Confirm the classification with the privacy lead.

In plain language. Do you handle personal data about criminal convictions, offences or related security measures?

Why we ask. Article 30(5) expressly includes Article 10 data as a reason the records exemption is unavailable; it is a separate category from Article 9.

Where the answer lives. The processing inventory, casework specification and any background-check data flows. Record uncertainty until the Article 10 classification has been resolved.

Context questions asked of every project. They shape how the backlog items are written; none of them changes the AI Act risk tier. For an internal government system most of them are simply 'no'.

In plain language. Which description best fits what your service is?

Why we ask. Service type shapes which safety and content rules are most relevant — social and messaging services carry heavier online-safety duties.

Where the answer lives. The project start document or the business case. For an internal government system the closest operational description is enough: this answer shapes how the backlog items are worded, never the risk tier.

Feeds. Nothing in the classification — this answer only shapes how the backlog items are written.

In plain language. Can users post or share their own content that others can see?

Why we ask. User-generated content is the trigger for most online-safety duties (UK OSA, DSA), because it creates exposure to harmful material.

Where the answer lives. The functional design. For a casework or scoring system used inside the organisation the answer is normally no; the question is asked of every project because the answer parameterises the backlog.

Feeds. Nothing in the classification — this answer only shapes how the backlog items are written.

In plain language. Can users send private messages to each other?

Why we ask. Whether people can message one another privately decides how much moderation and reporting work the backlog generates, and whether message content is personal data you hold. It does not change the AI Act classification.

Where the answer lives. The functional design. Normally no for an internal government system.

Feeds. Nothing in the classification — this answer only shapes how the backlog items are written.

In plain language. Can users create profiles that other people or the public can see?

Why we ask. A profile other people can see is an exposure surface, so the answer decides how much default-visibility and data-minimisation work the backlog generates. It does not change the AI Act classification.

Where the answer lives. The functional design. Normally no for an internal government system.

Feeds. Nothing in the classification — this answer only shapes how the backlog items are written.

In plain language. How do you find and deal with harmful or inappropriate content?

Why we ask. Online-safety regimes expect moderation proportionate to risk; the DSA and UK OSA ask how content is reviewed and removed.

Where the answer lives. The moderation policy or the terms of use. Where the system carries no public content at all, 'None' is the accurate answer rather than a gap.

Feeds. Nothing in the classification — this answer only shapes how the backlog items are written.

The classification questions. Q24 opens the section, and Q25 to Q29 and Q32 to Q34 are only asked once Q24 is Yes. Between them they decide the risk tier, the FRIA duty, the registration duty and the Art. 5 prohibited-practice check.

In plain language. Do you use or embed AI systems in your service as part of running your business?

Why we ask. The EU AI Act calls this being a 'deployer' and attaches duties such as human oversight and transparency to it.

Where the answer lives. The architecture description and the supplier's product documentation — and, decisively, the codebase scan, which pre-fills this question from the machine-learning frameworks, model-provider SDKs and model artefacts it finds in production code. If the algorithm is already published in the Algoritmeregister, that entry answers it too.

In plain language. Do you build or provide a general-purpose AI model that others can use for many tasks?

Why we ask. Chapter V of the EU AI Act puts duties on the provider of a general-purpose AI model (Art. 3(63)) that exist whatever the model is later used for — technical documentation, downstream information, a copyright policy and a public training-data summary under Art. 53. They are separate from the high-risk duties, so a 'no' here does not lighten the rest of the assessment and a 'yes' does not make the model high-risk.

Where the answer lives. The model card, contracts, development and market-placement records. Assess Article 3(3) provider status for the specific model and release, including whose name or trademark is used. Merely buying access is not enough; training or fine-tuning alone also does not settle all role and scope facts. Document the basis for modified models and refer uncertainty for review.

In plain language. Is this model's provider established in a third country?

Why we ask. For Article 54, assess whether the provider is established outside the Union. An in-scope third-country provider must appoint a Union-established authorised representative before placing the model on the Union market, unless the Article 54(6) exception applies.

Where the answer lives. Provider incorporation and establishment records, model placement and the representative's written mandate. Assess the actual provider, not a reseller's address.

In plain language. Does this model fall within the AI Act's Union-market scope?

Why we ask. Assess the particular GPAI model, provider and Union-market placement under Article 2(1)(a), including the applicable model exclusions in Article 2(3), (6) and (8). Merely selecting the EU framework or deploying an AI system does not establish model scope.

Where the answer lives. The model-provider role assessment, release and market-placement records, intended purpose and documented Article 2 exclusions. Assess each model version; selecting a framework is not proof of scope.

In plain language. Has this model been assessed as a GPAI model with systemic risk?

Why we ask. Assess Article 51 high-impact capabilities and Commission designation under Article 52. Training compute greater than 10^25 FLOPs creates a presumption; equality does not, and lower compute does not rule out classification. A provider's unaccepted rebuttal does not establish an exemption. Use Unknown until the relevant assessment or Commission outcome is established.

Where the answer lives. The Article 51 capability/benchmark and cumulative-compute assessment, Article 52 notification and any Commission designation or response. Historical Q22 compute-only answers do not populate this assessment.

In plain language. Does the model release meet all the free and open-source conditions?

Why we ask. Check that the licence permits access, usage, modification and distribution, and that parameters including weights, architecture information and usage information are public. A model being described as open source alone is insufficient. Articles 53(2) and 54(6) provide no exception for systemic-risk models; the engine separately checks that classification.

Where the answer lives. The release licence and public weights, model architecture and usage documentation. Record evidence for every condition. Systemic-risk classification is checked separately.

In plain language. Roughly how much total compute did training use, in FLOPs?

Why we ask. This estimate is contextual evidence for Article 51(2), not an automatic classification. The presumption applies above 10^25 FLOPs, not at equality. Article 52(1) notification concerns Article 51(1)(a) high-impact capabilities and is due without delay, within two weeks after the requirement is met or is known to be forthcoming. Assess capabilities, designation and any Commission response separately.

Where the answer lives. The training run's own records: cluster hours multiplied by the accelerators' throughput, or the figure the research team already reports in the model card. Where the model was fine-tuned rather than trained from scratch, record both the base model's compute (from the supplier's documentation, where it is published) and your own — Art. 51(2) speaks of cumulative compute.

In plain language. Did you build the AI system and put your name on it, or are you using one that somebody else built?

Why we ask. The EU AI Act gives providers and deployers very different duties (Art. 3(3) and 3(4)), so almost every later question depends on which hat you wear.

Where the answer lives. The procurement file. A system you buy and run unchanged makes you a deployer (gebruiksverantwoordelijke); a system your own team trained, or one you put your name on or substantially modified, makes you a provider (aanbieder) as well. The contract and the conformity documentation the supplier hands over settle it.

In plain language. What are the AI systems actually used for? Pick any of these areas they touch.

Why we ask. Annex III to the EU AI Act lists the uses that make a system high-risk, and Art. 6(2) turns that list into the classification; high-risk brings the heaviest duties, so this is the question that sets the tier.

Where the answer lives. The purpose description in the project start document and the statutory task the system serves — for a Dutch public body normally named in the DPIA and in part 1 of the IAMA ('Waarom'). Deciding on benefits, allowances or other essential public services is Annex III point 5(a).

In plain language. Are these systems used only for defence or national security, or only for research?

Why we ask. The EU AI Act simply does not apply to systems used exclusively for military, defence or national-security purposes (Art. 2(3)), or developed and used solely for scientific research and development (Art. 2(6)) — claiming an exclusion that does not fit is the main way this assessment goes wrong.

Where the answer lives. A written scope decision, not a habit: the exclusion is narrow and self-declared. In practice it sits in the mandate or the decision that established the system, and it has to say 'exclusively'. A system a defence organisation also uses for ordinary personnel administration does not qualify.

In plain language. Is the organisation running these systems a public authority, a private organisation delivering a public service, or neither?

Why we ask. EU AI Act Art. 27(1) requires a fundamental-rights impact assessment from deployers that are public-law bodies or private entities providing public services, and Art. 49(3) adds a registration duty for public authorities.

Where the answer lives. Your own constitutional position, which the legal department can state in one line. A ministry, an agency, a province, a municipality or a water authority is a body governed by public law; a privately run school, care provider or social-housing corporation is a private entity providing a public service.

In plain language. Do people talk to the system, does it read their emotions or faces, or does it generate content that could pass for real?

Why we ask. EU AI Act Art. 50 requires you to tell people they are dealing with AI, or to label AI-generated content, whatever risk tier the system sits in.

Where the answer lives. The functional design and the interface itself: is there a chat window, does the system read faces or voices, does it produce text or images shown to the public? The codebase scan pre-fills emotion recognition where it finds such code.

In plain language. Does what the system produces get used to decide something that matters about a person - even if one of your staff signs it off?

Why we ask. EU AI Act Art. 86 gives the affected person a right to an explanation whenever a decision is taken on the basis of a high-risk system's output; unlike the GDPR's Art. 22, it does not require the decision to be automated end to end.

Where the answer lives. The casework instruction. If a caseworker reads the score before granting or refusing, the answer is yes even though a person decides.

In plain language. When you score or rank people, does the score travel into decisions it has nothing to do with, or land harder on someone than what they did warrants?

Why we ask. EU AI Act Art. 5(1)(c) bans social scoring outright, and the ban turns on these two consequences rather than on scoring as such; without them the report can only ask you to attest that you do not do it.

Where the answer lives. The data lineage of the score: which sources feed it, and which decisions read it. A score built only from data relevant to the decision at hand, and used only there, is neither of the two.

In plain language. Even though the use is on the Annex III list, is the system doing something narrow enough that it does not really shape the outcome for anyone?

Why we ask. EU AI Act Art. 6(3) is the only route out of high-risk for an Annex III use, and it is narrow: the provider has to document the assessment before the system is used and register it, and it is unavailable where the system profiles people.

Where the answer lives. Only a written Art. 6(3) assessment answers this. Where no such assessment exists, 'None of these apply' is the honest answer: claiming a derogation you have not documented makes the position heavier, not lighter, because Art. 6(4) requires the documentation before the system is put into service.

In plain language. Does the system only write an answer for someone to read, or can it go and do things by itself - call other software, change records, send messages - without anyone pressing 'go' each time?

Why we ask. EU AI Act Art. 14 requires human oversight to actually work, and what that takes depends on what the system can do on its own: a model that only writes an answer is overseen by reading it, while one that calls tools and changes records also needs a stop button, a list of the actions it is allowed to take, and a log of what it did.

Where the answer lives. The system's technical design or solution architecture, and the supplier's documentation where the system was bought in: which tools, APIs or connectors it may call, and whether any of its actions run without a person confirming them. Where an integration list exists, it is usually the fastest place to check.

One absence is deliberate and worth stating, because a reader who expects it will otherwise think something is missing — and one presence is worth stating for the same reason.

• The child-safety questions. An AI-system pre-scan is never asked for the youngest age of its users, parental involvement or age-verification method. Those questions belong to a child-online-safety project and Landfall leaves them out entirely when minors are not in scope.
• General-purpose AI model questions ARE asked. Q21 (do you provide a general-purpose AI model), Q22 (systemic risk) and Q23 (training compute) are part of the AI Act pre-scan and are listed above. They drive the Chapter V provider duties row on the report — Art. 53 documentation, copyright policy and training-data summary, and Art. 55 where the model carries systemic risk. They do NOT change the Art. 6 risk tier: a general-purpose model used in no Annex III area still reports as limited or minimal risk while owing those Chapter V duties, which is exactly why the two are shown separately.

Anything you answer with "Unsure" is not silently resolved: it becomes a review item, and the report says so where it limits the verdict.