AI in debt collection: what the Dutch DPA study means for your municipality

Picture this: you are the privacy officer at a Dutch municipality. The collections team hands unpaid claims to a debt collection agency. That agency's website says it does "smart collection with AI". In your own system, a set of rules decides who gets a reminder after how many days and who is passed on. Do you know what the agency does with your residents' data, and what your own rules actually decide?

On 29 October 2026 the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) published a study of algorithms and AI at debt collection agencies. It is about the sector, but the lessons apply to every organisation that collects claims or has them collected.

What the AP studied

The AP selected 29 agencies from the register under the Dutch Debt Collection Services Quality Act (Wet kwaliteit incassodienstverlening): 17 because their website said they use AI, 12 because it said nothing about it. In its news item and research report of 29 October 2026 (in Dutch) the AP describes what it found. The agencies collect for businesses, institutions and public authorities, among other things for medical bills, traffic fines, student debts and bank claims.

The AP itself calls the outcome the most favourable scenario: agencies not in the register did not take part, while they are probably more likely to breach the GDPR as well. Notably, in half of the cases the survey answers did not match the privacy notice on the website.

Why this concerns your municipality too

An agency collecting on behalf of your municipality works with data you supply. Its role under the GDPR, processor or independent controller, depends on who determines the purposes and means (Article 4(7) and (8) GDPR). If it is a processor, you may only use a party that provides sufficient guarantees (Article 28(1) GDPR), and you remain responsible for what happens to your residents' data. If the agency is a processor, the duty to inform and Article 22 rest on the municipality as controller. If the agency determines purposes and means itself with its own algorithms, it is a controller for that part. And the software your own team uses to decide who gets a reminder when falls under the same rules.

Lesson 1: a debt is personal data, and so is a score

Some agencies saw only name, address and place of residence as personal data. Not the debt itself, and not the output of a system. The AP is clear: anything that says something about an identifiable person is personal data (Article 4(1) GDPR), so the amount owed and a score are too.

The agencies also said they process no special categories of data. But debtors write and speak freely, for example about their health, and some agencies have AI analyse those messages and calls. The AP therefore considers it highly likely that special category data is processed, which is prohibited save for limited exceptions (Article 9 GDPR).

For your municipality: include debt amounts, scores and what residents say in contact in your agreements with the agency and in your own record of processing.

Lesson 2: a favourable automated decision is covered by Article 22 too

One agency said it only decides automatically on payment arrangements when the outcome favours the debtor; a refusal would always go to a person. The AP: the intended outcome makes no difference to the prohibition. Article 22 covers every decision based solely on automated processing that produces legal effects or similarly significantly affects someone (Article 22(1) GDPR), even if it turns out favourably.

The AP also points out that an intermediate step, such as calculating a risk score, can already be a decision. It refers to the Court of Justice's SCHUFA judgment (C-634/21). There a credit information agency calculated a score, and that score was a decision because a third party drew strongly on it in deciding whether to establish, implement or terminate a contract with the person. The AP applies this to intermediate steps in an organisation's own process.

An exception is possible, for example where the decision is necessary for a contract with the data subject (Article 22(2)). With that exception, and with explicit consent, the debtor must at least be able to obtain human intervention, express their point of view and contest the decision (Article 22(3)). For a Dutch municipality the statutory route is narrow: Article 40 of the Dutch GDPR Implementation Act (UAVG) makes an exception for automated decisions necessary to comply with a legal obligation or to perform a task in the public interest, other than on the basis of profiling. The municipality must then take suitable measures (Article 40(2)).

Lesson 3: a person in the process only counts if they really look

Many agencies build in a person. The AP doubts whether that is always meaningful or merely a formal step with no influence on the outcome. Some agencies only involve a person when the debtor asks. Anyone using human intervention to stay outside Article 22 must make sure that intervention is meaningful, for example through enough time, good instructions and a system that does not steer the employee. The AP refers to its guidance on meaningful human intervention (in Dutch); how to set that up in practice is covered in meaningful human oversight in practice.

For your municipality: record for each step in collection what the employee sees, how much time they have and how often they depart from the system's proposal. If nobody ever departs from it, that is a warning sign.

Lesson 4: inform actively, at the latest at first contact

All agencies have a privacy notice on their website, but only a few include a link at first contact. Few notices explain which algorithms are used. Where the data do not come from the debtor but from the creditor, and are used to contact the debtor, the information must be given at the latest at the first communication (Article 14(3)(b) GDPR). In any case it must be given within one month of obtaining the data (Article 14(3)(a)). Where the organisation takes decisions within the meaning of Article 22, it says so, with meaningful information about the logic involved and the significance and envisaged consequences (Article 14(2)(g)). According to the AP, this must not get lost in a long list of all processing operations.

For your municipality: ask the agency what text your residents receive with the first letter, and check that your own reminders point to clear information on how you select.

Lesson 5: enriching files and detecting vulnerability need a legal basis

Agencies have systems look for extra information in registers and online, such as bank details or social media activity. They use algorithms to estimate how vulnerable someone is, or how likely a debt is to be paid. The AP says that enriching files and detecting vulnerability raise fundamental questions about lawfulness, and sees them, together with the chance of collection, as possible profiling. The AP writes that profiling is prohibited unless an exception applies, and recommends without qualification that agencies stop processing that amounts to profiling of the debtor.

That sentence is broader than the GDPR. The GDPR does not prohibit profiling as such: profiling needs a legal basis (Article 6 GDPR), may only serve a specified purpose and not go beyond what is necessary (Article 5(1)(b) and (c)), and where it rests on a task in the public interest or a legitimate interest, the data subject can object (Article 21(1)). What is prohibited is a decision based solely on automated processing, including profiling, where no exception applies. We therefore read the recommendation as: stop profiling without a legal basis, and profiling on which a decision within the meaning of Article 22 is based. The report itself does not draw that distinction.

Detecting vulnerability can be well meant, to steer someone to help sooner. But if the signal points to health, you are processing special category data. The AP's DPIA list includes profiling, credit scores and financial situation among the processing operations that require a DPIA (see when a DPIA is required).

Lesson 6: agree terms with the supplier and check them

Most agencies buy their software. Suppliers approach agencies actively, and sometimes an AI feature suddenly appears in existing software. There is not always a processing agreement: sometimes the supplier is not a processor, sometimes the agency believes, rightly or possibly wrongly, that no personal data goes into the system. The AP: find a supplier you can make good arrangements with, put them in writing and check at procurement that you can comply with the GDPR.

For your municipality: ask the agency about the suppliers it uses itself, and include in the contract that a new AI feature must be reported first.

Lesson 7: link measures to the risks you name yourself

Many agencies named discrimination as a risk, but no measure against it. The risk of staff using AI tools for decisions on their own initiative was also named, without a measure. Several agencies considered their risk low because they use simple rules and little data. The AP: even a simple algorithm can have major consequences. Notably, the agencies that use no algorithms had mapped the risks best.

What the AI Act adds

The AI Act only covers AI systems, not every fixed if-then rule. A system that calculates a probability with a trained model will quickly qualify, though.

• Creditworthiness. An AI system that evaluates the creditworthiness of natural persons or establishes their credit score is high risk (Annex III point 5(b)), except where it is used only to detect financial fraud. According to the AP this also covers a system that assesses whether someone is willing to meet payment obligations. Because such a system profiles people, the exemption in Article 6(3) is not available.
• Reclaiming benefits. For your municipality point 5(a) also counts: AI systems used by or on behalf of public authorities to evaluate eligibility for essential public assistance benefits, or to grant, reduce, revoke or reclaim them. An AI system used in the decision to reclaim overpaid social assistance can therefore be high risk.
• Fundamental rights impact assessment. A municipality deploying such a system must assess the impact on fundamental rights beforehand; so must every deployer of a system under point 5(b), such as a bank or a debt collection agency (Article 27). You may refer to your DPIA for what it already covers; see also the FRIA for municipalities.
• Phone calls. A system that infers emotions from the voice is an emotion recognition system: high risk (Annex III point 1(c)), and the municipality or agency, as deployer, informs the people exposed to it of its operation (Article 50(3), applicable since 2 August 2026). If the system infers the emotions of your own staff, for example for coaching sessions, that is prohibited (Article 5(1)(f), since 2 February 2025), unless it is put in place for medical or safety reasons. According to the AP, agencies use call analysis precisely for coaching sessions with staff as well. A sentiment score based only on the text of a call uses no biometric data and falls outside the definition (Article 3(39)).
• Chatbots. The provider must design a chatbot so that people know they are talking to AI (Article 50(1), applicable since 2 August 2026). Check this at procurement.
• Human oversight is something else. The AP points out that human oversight of a high-risk system is different from human intervention under the GDPR: it also covers monitoring operation, recognising automation bias and knowing the system's limits (Article 14(4)(a) and (b)). The deployer assigns competent people to it (Article 26(2)).

The high-risk obligations apply to new systems from 2 December 2027. A system placed on the market or put into service before 2 December 2027 is only covered after a significant change in its design. Providers and deployers of systems intended to be used by public authorities must comply by 2 August 2030 at the latest (Article 111(2)); that also applies to the municipality's fundamental rights impact assessment. AI literacy (Article 4) already applies: anyone providing or deploying AI systems takes measures that support the AI literacy of the people working with them. A specific level per person does not have to be guaranteed.

For a bank and a school

A bank that manages arrears itself with a model predicting the chance of payment is right in the middle of this study: Article 22 GDPR, transparency at first contact and, if it is an AI system, Annex III point 5(b) with a mandatory fundamental rights impact assessment.

A vocational college or university that has overdue tuition fees collected has the same questions for the agency as the municipality: which role, which agreements, what information does the student receive at first contact.

What to do now

1. List every step in collection that a system takes or proposes, and note for each step whether a decision with consequences for the resident follows.
2. Record for each decision who takes it, how much time they have and how often they depart from the system.
3. Check what information residents receive at first contact, from you and from the agency.
4. Ask the agency in writing which algorithms and AI it uses, which data it adds and from which suppliers.
5. Carry out a DPIA where profiling or scoring takes place, and note in it whether the system is an AI system and whether Annex III point 5 applies.
6. Make sure the people working with these systems know how they work and where they can go wrong.

To check which GDPR and AI Act obligations apply to a system of your own, use the free case check. Recent decisions and reports of the AP are collected under GDPR enforcement.

What remains open

• Is a collection probability score covered by Annex III? The AP reads point 5(b) broadly. The European Commission's guidelines on classifying high-risk systems have not yet been adopted; until they are, this is a defensible but unsettled reading.
• Is collecting a reclaimed amount covered by point 5(a)? The decision to reclaim clearly is. Whether collecting a claim that has already been established is covered too, is unsettled.
• Which exception fits an automatic payment arrangement? The AP states that favourable decisions are covered by Article 22 too, but does not address when the contract exception applies.
• Dialogue with the sector. The AP holds a round table with the debt collection sector on its findings on 2 December 2026.