What the AI Act pre-scan is

You are about to put an algorithm into use, or you already have one running, and someone has asked whether the EU AI Act applies to it and whether a data protection impact assessment is needed. Four people usually share that question inside a Dutch public body:

• the policy officer or product owner who knows what the system is for;
• the data protection officer, who owns the DPIA and the register of processing activities;
• the CISO or information-security adviser, who owns what may leave the organisation;
• the engineer or supplier manager, who knows what the system actually does.

The pre-scan is written so that all four can read the same document. It takes about an hour of one person's time when the underlying paperwork already exists, and considerably longer when it does not — which is itself a useful finding.

A pre-scan project produces one report, available as HTML or JSON at any project status, and — for a public-sector project — a Dutch Algoritmeregister draft beside it. The report has a fixed shape:

• A risk tier with a numbered rationale, where every step carries an article citation.
• A prohibited-practice check under Art. 5, separating corroborated findings from items you simply attest to.
• A duties table: the fundamental-rights impact assessment (Art. 27), registration in the EU database, the GDPR Art. 35 DPIA and the Art. 36 prior consultation. Every row prints the basis it was derived from.
• The obligation list with each item's human-review state.
• The AI components found in the codebase, as file and line references.
• A register entry draft — the Algoritmeregister shape for a public body, a plain inventory entry for anyone else.
• Provenance: the assumption count and version, the scan id, branch and commit, the source-document versions of the obligations, and the project profile.

The classification is computed, not written by a model. The same answers always produce the same tier. A model is only ever asked for an optional explanatory paragraph, which is fenced off and labelled as model-generated, and the report is complete without it.

The pre-scan is a screening instrument. It is explicit about its own limits, and reading it as more than that is the main way it can do harm.

• It is not legal advice and it is not a legal opinion. Every export carries that statement, and it means it.
• It does not complete your DPIA or your IAMA. It tells you whether one is indicated and what it must cover; the assessment itself is human work.
• It does not fill in your register entry. Fields it cannot derive come out as the literal placeholder rather than a plausible guess, because a register published to citizens with a guess in it is worse than an empty one.
• It does not settle a scope exclusion. Claiming that a system is used exclusively for defence or national security is a decision your organisation records and defends; the pre-scan honours the claim, says out loud that it is narrow and self-declared, and keeps reporting the data-protection duties that survive it.
• It does not approve anything. Approval is a person pressing a button in the product, recorded with their name.

Where Landfall's own reasoning is a choice rather than a rule, it says so in the report itself rather than presenting it as settled law.

Two kinds of sign-off matter, and they are not the same thing.

Inside Landfall. Each obligation mapping carries a human-review state: none, pending, approved or rejected. The report prints that state next to every obligation, and a verdict resting on mappings nobody has approved is labelled a draft. The CI gate refuses to pass a high-risk system whose Art. 6, Art. 27 or Art. 49 mappings are unapproved. Approval is done by a user with the approver role, and the creator of a mapping cannot approve their own.

Inside your organisation. Landfall does not know your mandate rules. In practice the responsible official for the process signs the classification, advised by the data protection officer, and the IAMA or FRIA is adopted by whoever is empowered to adopt it. Record that person in the assessment record, not in the tool.

A Dutch public body deploying an algorithm normally has three obligations pointing at the same system, and the worst outcome is three separate documents that disagree.

• The IAMA (Impact Assessment Mensenrechten en Algoritmes) is the Dutch instrument, structured in four parts: Waarom, Wat, Hoe and Mensenrechten.
• The FRIA is the AI Act's fundamental-rights impact assessment under Art. 27, required of a public-body deployer of a high-risk system.
• The DPIA is the GDPR Art. 35 assessment, structured by the EDPB guidance.

Landfall treats these as one record with a section map rather than three documents. The generated ticket for the Art. 27 assessment carries that instruction, and the evidence checklist asks for the IAMA record's identifier, because the Algoritmeregister expects the IAMA reference. Two places the instruments do not overlap are called out rather than glossed: the IAMA's fundamental-rights sweep is wider than data protection, and the IAMA has no step corresponding to the Art. 27(3) notification of the market surveillance authority — that stays a separate action.

The section map in the product is built from public government and university summaries of the IAMA's structure rather than a line-by-line reading of the official text. Verify the exact Dutch wording against the official IAMA before an assessment built on it is adopted.

The Algoritmeregister is publication, not assessment. Landfall drafts an entry in the national publication standard and can read a published entry back in, so a body that has already published this algorithm does not retype its answers.

Nothing in the classification requires a model. The questions worth asking are therefore narrow, and the answers are enforced in code rather than promised in a policy document.

• The codebase. Landfall reads one snapshot of the repository and keeps the findings — a pattern name, a file path, a line number and the matching line. Where outbound git access is not allowed at all, upload an archive instead: it is read once and then deleted, never extracted to disk, and never sent to a model.
• Model calls. The pre-scan's optional narrative receives the computed verdict — the tier, the rationale statements, the flag bases and counts. It does not receive file contents. The codebase scan's optional analysis receives finding titles, descriptions and file references, again not file contents.
• The residency policy. Each project carries a policy: any provider, an EU-hosted or locally run provider, or a locally run provider only. The check fails closed — a provider whose residency is undeclared satisfies only the first policy — and a blocked call returns an error rather than quietly falling back to another provider. Landfall also refuses to save a provider configuration that violates the project's own policy, so the contradiction surfaces at the moment you create it.
• The report can be shared without an account through a time-boxed, revocable link that opens the pre-scan and nothing else. The guest path never calls a model, never shows e-mail addresses, and every view is logged.

If AI features must make no outbound calls at all, the deployment can be run with a model inside your own infrastructure. Ask your CISO to confirm which of these applies before you connect a repository.

This matters more than any feature. The EU AI Act and GDPR obligations Landfall reasons over are seeded at the draft confidence tier: their verbatim source text has been taken from the official sources, but the interpretation, the trigger conditions and the enforcement dates are a founder and legal-review item that is open at the time of writing.

Specifically open, and stated here rather than buried:

• the enforcement dates as seeded assume no deferral of the Annex III timetable;
• the numbering of the registration duties for providers and for public-authority deployers under Art. 49;
• the scope of Art. 27, including whether its public-service limb binds every deployer;
• the screening derived from the European guidance for the Art. 35 DPIA, which fires on a single criterion rather than the usual two, deliberately over-including;
• the national list of processing operations for which the Autoriteit Persoonsgegevens always requires a DPIA, which Landfall does not model.

Treat the pre-scan as a well-sourced screening that tells you where to look, and have counsel confirm the provisions before anything is adopted or published.

Supervision of the AI Act in the Netherlands is spread across several market surveillance authorities by sector, with a coordinating role for the Autoriteit Persoonsgegevens and the Rijksinspectie Digitale Infrastructuur. The designation has been developing through successive government letters and legislation, so Landfall does not assert which authority supervises your system.

Establish that yourself before you rely on a supervisory route: check the current designation, and note that the Autoriteit Persoonsgegevens remains the supervisory authority for the data-protection side regardless of how the AI Act supervision is arranged.

The Woo (Wet open overheid) is a separate track again. Publication in the Algoritmeregister is not a Woo request and does not answer one; a Woo request about this system may ask for the assessment records themselves.

1. Create a project. Choose the use case AI system pre-scan and the sector Public sector / government. The EU AI Act and the GDPR are pre-selected because of that choice, with a note saying why.

2. Connect evidence. Link a repository (GitHub, GitLab or an uploaded archive) and run the scan, or import an existing Algoritmeregister entry. Both produce suggestions, never answers.

3. Confirm what was found, then answer the rest. The questionnaire states how many questions could not be inferred, so the value of step 2 is a number rather than a claim.

4. Review the classification and the obligations. Save the mappings, then have an approver review them.

5. Export the pre-scan report, and — for a public body — the Algoritmeregister draft. Share it with a colleague through a guest link if they have no account.

The questionnaire field guide covers step 3 question by question; the report guide covers steps 4 and 5.