STAIR Assist

Municipality of Amsterdam

STAIR Assist helps local authority staff with their queries and plans. It ensures that these queries are directed to the correct procedure within the STAIR platform. The algorithm does not make decisions on behalf of members of the public, but helps staff to find the right steps and tools for their work.

Last change on 4th of August 2026, at 9:55 (CET) | Publication Standard 1.0

• Publication category: Impactful algorithms
• Impact assessment: Field not filled in.
• Status: In development

General information

Theme

Organisation and business operations

Begin date

2027-01

Contact information

[e-mail]

Responsible use

Goal and impact

STAIR Assist helps staff at the City of Amsterdam to quickly and accurately identify the correct compliance procedure within the growing landscape of integrated legislation (such as the GDPR, the AI Regulation, BIO 2.0, NIS2, the Public Records Act and the WOO). The employee asks a question in natural language and, based on that question, the algorithm suggests a suitable use case route, including the mandatory tools (DPIA, IAMA, DRAAI, QuickScan), relevant roles and compliance frameworks. The employee decides for themselves whether to follow the suggested route; the algorithm does not impose, override or automate any decision.

The intended effect is to make compliance accessible to staff without legal training, to free up time for experts (Privacy Officers, ISO) to focus on substantive work, and to ensure that all compliance processes are documented in an auditable manner. Members of the public do not interact directly with this algorithm; the effect on them is indirect, through the local authority’s more consistent adherence to privacy, security and transparency requirements.

Considerations

STAIR Assist is a support algorithm with no direct impact on citizens. The main risks are organisational and informational, rather than primarily relating to fundamental rights. Three risk categories have been identified.

Risk 1 — Incorrect routing with compliance implications: the algorithm proposes a UC route in which a mandatory compliance instrument is missing, resulting in an underlying project being put into operation incorrectly without a DPIA or IAMA. Mitigation: rule-based minimum requirements at route level (for example: when processing personal data, the DPIA step cannot be omitted), expert review at decision-making stages, periodic audit of executed routes against legal requirements.

Risk 2 — Over-reliance by an employee: an employee blindly follows a proposed route, losing their own judgement regarding compliance.  

Mitigation: the interface design makes it explicitly clear that this is a proposal and not a decision; mandatory confirmation at critical steps;  

Staff training emphasises individual responsibility;  

QA spot checks detect systematic patterns of blind compliance.

Risk 3 — Hallucination by language model: the language model invents information that sounds legal but is incorrect.  

Mitigation: RAG architecture restricts responses to retrieved context; output is validated against the PurpleFish knowledge base; structural fields (UC route ID, compliance framework) are drawn from a closed set, not generated freely; An audit trail enables retrospective tracing of which context was used.

Human intervention

Supervision is ensured at three levels. 

(1) Per interaction: the employee decides for themselves whether to follow the proposed UC route. The algorithm provides a recommendation, not an instruction. The employee may reject, amend or ignore any proposal.

(2) Per route: the final decision-making steps (decision blocks in a UC route — for example, GO/NO-GO by the Director of Data Protection, approval by the Privacy Officer) are always taken by authorised personnel, not by the algorithm. The algorithm provides the information; humans make the decisions. 

(3) At system level: a QA Manager assesses the routing quality on a random basis (at least 10 per cent of interactions). Findings are fed back to the development team via the IBH process (Information Security and Enforcement). Significant deviations are reported to the portfolio holder.

Risk management

STAIR Assist is a support algorithm with no direct impact on citizens. The main risks are organisational and informational, rather than primarily relating to fundamental rights. Three risk categories have been identified.

Three main categories:

(1) Incorrect routing: the algorithm suggests an incorrect UC route (process route), meaning that a mandatory compliance tool only comes into play at a later stage. The system guides staff through the compliance processes. Whereas everything is currently done manually and managed between staff via email or chat, STAIR automates this process, and there is a risk that the system may direct you to the wrong category. 

(2) Over-reliance: staff follow suggestions without carrying out their own checks, thereby diminishing human judgement.

(3) Misinterpretation: the language model generates information about legislation that sounds legal but is factually incorrect.

The algorithm supports internal staff with routine fact-finding work in a legally complex field. The alternative — requiring all staff to build up their own legal knowledge or to consult a Privacy Officer or ISO officer for every query — is practically unfeasible at the current scale (approximately 20,000 staff members, 45 directorates) and demonstrably leads to backlogs in compliance processes. The algorithm does not make decisions, does not replace experts, and does not alter data relating to citizens. The measure is proportionate because it reduces the harm caused by non-compliance without creating a new avenue for harm to citizens.

The measures

(1) Every routing decision can be reviewed by the staff member and is recorded in PurpleFish as an auditable trail (OSCAL format). 

(2) Advice, implementation, follow-up and mandatory tools within the proposed route (QuickScans, risk analyses, DPIA, IAMA) continue to be carried out by people, not by the algorithm.

(3) Substantive compliance decisions are always taken by authorised roles (Privacy Officer, ISO, Data Protection Director), not by the system.

(4) Periodic spot checks on routing quality by the QA Manager (at least 10 per cent of interactions).

(5) No data leaves the municipal infrastructure.

Legal basis

Article 6(1)(e) of the GDPR (task in the public interest) in conjunction with Article 160 of the Local Government Act. The algorithm supports compliance with BIO 2.0, the GDPR, the AI Regulation, NIS2, the Public Records Act and the WOO. 

Elaboration on impact assessments

The ethical package leaflet will be finalised in Q3 2026.

The DPIA process has been launched.

Operations

Data

No personal data is processed.

Legislation and regulations, as well as information from Quality Assurance, are processed.

Links to data sources

• GDPR: https://europa.eu/youreurope/business/governance-and-sustainability/digital-and-data-compliance/data-protection-gdpr/index_nl.htm
• BIO: https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/cybersecurity/bio-en-ensia/baseline-informatiebeveiliging-overheid/
• OSCAL: https://oscal.io/
• AI ACT: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

Technical design

STAIR is a platform where users log in and, via the interface, can complete the compliance process required to develop or procure IT within the local authority.

The user completes the compliance process in STAIR by answering questions and filling in open fields. In the background, an LLM processes the answers provided and links them to the relevant legislation and regulations (made machine-readable via OSCAL). In this way, the user is efficiently routed through the system in the correct manner, and answers are used only once (rather than being duplicated, as in the current process).

External provider

Developed in-house.