The Story of Municipality Transparantstad
How a municipality discovered they didn't know what algorithms they were actually using — and how the registration process became an eye-opener
Fictional scenario — based on realistic situations
The Trigger
How it started
The obligation was clear: governments must register their algorithms in the national Algorithm Register. Municipality Transparantstad wanted to lead the way. But when they started, the team ran into a fundamental question: what actually is an algorithm?
The deadline was approaching. Parliament had pushed for transparency. Citizens wanted to know which systems were making decisions about them. And the municipality had no idea where to start.
"How many algorithms do we use?" The answer varied from 3 to 300, depending on who you asked.
The Questions
What did they need to find out?
What counts as an "algorithm" that needs to be registered?
The team started with a simple question to department heads: "What algorithms do you use?" The answers were confusing. IT said: "Everything is an algorithm." Policy said: "We don't use AI." Factually, both were right — and wrong.
💡 The insight
The definition turned out to be crucial. An algorithm in the context of the register is not every calculation, but specifically: systems used in decision-making about individuals. The sort function in Excel doesn't count. A system that determines who gets a parking permit does.
🌍 Why this matters
The Algorithm Register focuses on algorithms with impact on citizens. Publication categories range from "impactful" (mandatory to publish) to "other" (voluntary). But the boundary isn't always clear — and that's exactly where many organizations struggle.
How do you find algorithms that have been running invisibly for years?
The team realized that many algorithms were "hidden". In spreadsheets that had been used for ten years. In software once made by an intern. In licenses that automatically made decisions without anyone knowing.
💡 The insight
The inventory required a combination of top-down and bottom-up. Management knew which major systems existed. But daily users knew which "little helpers" were used in practice. Both were needed for a complete picture.
🌍 Why this matters
Research shows that most organizations underestimate the number of algorithms in their processes. "Shadow IT" — systems used outside IT's sight — is a common phenomenon. Registration forces visibility.
What exactly do you document — and for whom?
The first registrations were technical jargon. Nobody outside the department understood what it said. The team realized: the register isn't for us, it's for citizens.
💡 The insight
Good registration requires translation. What does the system do? Who does it affect? What data does it use? How can you object? The challenge was: technically accurate and understandable at the same time. The team developed templates that combined both.
🌍 Why this matters
The Algorithm Register prescribes standard fields, but the quality of registrations varies enormously. Some organizations publish sentences full of jargon. Others are transparent and accessible. The best registrations answer the questions a citizen would ask.
How do you make registration part of your work processes?
After three months of intensive inventorying, the team had a nice register. But now what? New systems were being purchased. Existing systems were being modified. If registration remained a one-time project, the register would be outdated within a year.
💡 The insight
Registration had to be embedded in existing processes. With every procurement: is this an algorithm? With every system change: does the registration need updating? The team developed checklists and made algorithm registration part of the procurement process.
🌍 Why this matters
The AI Act doesn't just require registration, but lifecycle management. High-risk systems must be monitored, audited, and updated when needed. Registration is the beginning, not the end.
The Journey
Step by step to compliance
The kickoff
A civil service working group was assembled with representatives from IT, legal affairs, procurement, and the main departments. The assignment: map which algorithms we use.
The definition discussion
For two weeks the team debated what was and wasn't an "algorithm". Eventually they chose a pragmatic definition: systems that influence decisions about individuals.
The inventory sprint
Each department received a questionnaire. IT pulled a list of all applications. Procurement dove into vendor contracts. After six weeks, the team had identified 47 candidate algorithms.
The surprises
Some findings were unexpected. An Excel file from 2015 still used daily for social care allocations. A prediction model in the parking system nobody knew about. Three overlapping systems for debt assistance.
The risk classification
Each algorithm was classified: high, limited, or minimal risk. Five systems turned out to be potentially high-risk under the AI Act. Those needed extra attention.
The documentation
For each algorithm, a registration form was filled out. The team developed a standard format that met both Algorithm Register requirements and AI Act documentation requirements.
The Obstacles
What went wrong?
✗ Challenge
Departments didn't know which systems counted as "algorithms"
✓ Solution
Practical workshops with examples: "If your system does X, then it's probably an algorithm in the sense of the register."
✗ Challenge
Vendors didn't want to share details about how their systems worked
✓ Solution
Referring to contractual obligations and the AI Act. New contracts got standard clauses about transparency.
✗ Challenge
The register quickly became outdated due to new systems and changes
✓ Solution
Integrating registration into existing processes: procurement, change management, and annual reviews.
We started with the question: what do we need to register? We ended with the question: what do we actually do with data and decisions? The register was the beginning of a larger conversation.
The Lessons
What can we learn from this?
Start with a workable definition
The question "what is an algorithm?" can go on forever. Focus on what's practically relevant: systems that influence decisions about people.
Inventorying is discovering
Most organizations don't know what they're using. The registration process is also an inventory process — and that has value in itself.
Write for the citizen, not for yourself
The register isn't internal documentation. It's an attempt to tell citizens how decisions about them are made. Write as if you're explaining it to your neighbor.
One-time inventory isn't enough
Systems change. New software comes. Registration must be an ongoing process, embedded in how you work.
Does your organization also need to register algorithms?
Discover how to set up an inventory and which algorithms fall under the registration requirement.
Ga verder met leren
Ontdek gerelateerde content