Sweden's employment agency is under scrutiny for its AI tool

An AI tool built to help is now being investigated

Sweden's employment agency, Arbetsförmedlingen, built an AI tool meant to match job seekers with opportunities ^[1]. This week, the country's data protection authority, IMY, announced it has opened supervision to check whether the tool's use of personal data is lawful and necessary ^[1].

The investigation follows Aftonbladet's critical reporting on the system. IMY has not yet said what specific concerns triggered the supervision, but the authority's statement makes clear that it will look at whether the handling of personal data meets GDPR's requirements.

Think of it this way: GDPR works a bit like the principle behind packing for a trip. You're supposed to bring what you need, not everything you own. Article 5(1)(c) says personal data must be "adequate, relevant and limited to what is necessary" for the purpose ^[2]. That principle is called data minimisation, and it is often where AI systems run into trouble.

What GDPR says about using personal data

GDPR has applied since 25 May 2018 ^[2]. It covers anyone handling personal data in the EU. Two of its core principles matter here.

First, data minimisation: you collect only what you need ^[2]. Second, integrity and confidentiality: you protect data against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical and organisational measures ^[2].

When an AI system assesses people, both principles come into play. The system needs data to work, but not every piece of data an organisation holds is necessary for every decision. The line between useful and excessive is often drawn during an investigation like this one.

Why AI on people is hard to get right

AI systems that assess job seekers, credit applicants or benefit claimants are what the AI Act calls high-risk ^[3]. High-risk AI in these areas will have to meet detailed requirements from 2 December 2027, including data governance, automatic logging and human oversight ^[3].

But GDPR already applies, and it asks a simple question: why did you need that data point? If the answer is "the model might find it useful", that's not enough. The purpose has to be specific, and the data has to be necessary for it.

That is hard when the model's workings are opaque, even to the people running it. A system might score someone lower because of a factor nobody thought was being used. Six months later, when the person asks why, the organisation needs to be able to show what went in and what came out.

What happens during supervision

IMY's role is to check compliance, not to decide political questions about whether the tool should exist. The authority will look at the legal basis for processing, the categories of data used, and whether the agency can show that the data collection was necessary.

If IMY finds shortcomings, it can order the agency to bring the processing into line with GDPR, limit it or stop it. In serious cases, it can issue administrative fines, though fines against public bodies are less common than against private companies ^[2].

The outcome will matter beyond this one tool. Other public agencies are building or buying AI systems to help with decisions about people, and they are all watching to see what IMY says is enough and what is too much.

A digital witness makes the record checkable

This is a case where a digital witness fits, but only for one part of the problem.

The thing to seal is the record of what data the model used for each assessment: which version of the model ran, which data points it was given, what it output and, if there was one, which human reviewer saw it. That record is sealed as it is written to the log, using WitniumChain.

Sealing takes a fingerprint of the record, not the data itself, so nothing sensitive leaves the agency's systems. If someone questions a decision months later, the agency can show the record to its data protection officer, to IMY or to the person affected, and any of them can check that it is exactly what was written on the day.

What a witness doesn't do is decide whether the data collection was lawful or necessary in the first place. That is a question of purpose and proportionality, and it sits with the data controller. A sealed log just makes the "what happened" part a shorter conversation than it would otherwise be.

How it would work

1. Each time the model runs, the system writes a record: applicant reference, model version, input features and output score.
2. That record is sealed as it is written, giving it a witness ID.
3. When a decision is questioned, the agency shares the record and the witness ID. The recipient calculates the fingerprint and checks it against the sealed one. If it matches, the record hasn't changed.

What this means for you

If you are building or running AI that assesses people, these are the questions to ask now, before an investigation starts:

• Can we list every data point the model uses, and explain why each one is necessary?
• Can we show, for a decision made six months ago, what data went in and what came out?
• Do we log model versions, so we know which version made which decision?
• If someone asks why they got a particular outcome, can we give them an answer that GDPR calls an explanation?

The first question is about design. The others are about records. Neither expensive technology nor a blockchain is required, but the records do need to exist and to be trustworthy when they are needed.

What to watch

IMY has not said when the investigation will conclude. Supervision can take months, and the authority tends to publish its decisions once they are final.

The AI Act's high-risk requirements for employment and recruitment AI apply from 2 December 2027 ^[3]. Public agencies using such systems will need to meet those requirements on top of GDPR, including technical documentation, human oversight and the logging duty in Article 12. Getting the data governance right under GDPR now makes that transition less painful later.