Government · · 4 min · Desh Deepak
Six questions decide whether a municipal AI pilot happens. They are asked in the same order every time, and a vendor who cannot answer the first two rarely gets to the third.
An innovation director does not decide whether a municipal AI pilot happens. They decide whether to forward the proposal. The person who decides is the Data Protection Officer, and by the time the proposal reaches them they have usually already read the vendor's website.
Here are the six questions they ask, in the order they ask them, and the answers we give.
Not "is it GDPR compliant." That question has no useful answer. The question is where in the pipeline personal data ceases to exist, and whether that boundary is enforced by architecture or by policy.
Our answer: at ingestion. Identifiers are stripped or pseudonymised at the ingestion boundary and no individual-level record reaches the AI processing layer. It is enforced at the pipeline level, which means a developer cannot bypass it by writing a different query. A policy that says "we do not look at individual records" is a promise. A pipeline that cannot produce one is a control.
The follow-up is always the same: show me. So the data flow diagram, marked with where the boundary sits, is a published page rather than an annex we send on request.
This is the question that separates DPOs who have done this before from ones who have not, and it is the best question on the list.
Aggregated output is only anonymous if it stays aggregated. A dashboard that reports at neighbourhood level but allows filtering by age band, by service type, and by month can produce a cell containing one person. Nobody intended it. The filters did it.
Our answer: a minimum cell size is configured per deployment and applied at query time, across every filter combination, including exports. The floor is in the query layer, not in the interface, so it cannot be evaded by hitting the API directly or by exporting to a spreadsheet and joining two exports together.
The wrong answer here is a single classification for the whole platform. It is inaccurate and a procurement panel notices.
The modules are not equivalent. Employment-related matching touches decisions about access to work, and we treat it under the high-risk obligations: risk management, data governance, logging, human oversight, transparency, and accuracy documentation. The civic analysis modules produce advisory decision-support for an institution, at cohort level, with no individual output and no automated decision.
Both classifications, and the reasoning behind each, are versioned in the repository and ship with the release. A DPO can read the reasoning, not just the conclusion, which matters because the conclusion is the part they are least able to take on trust.
The platform ranks, explains, and projects. A qualified human makes every hiring decision and every policy decision.
That is easy to say and the DPO will test it. The test is: can the system be configured to auto-reject, auto-advance, or present a score as a verdict? If the answer is "not by default", the answer is yes and the control is a setting rather than a constraint.
Ours is a constraint. There is no automatic rejection, no auto-advance, and no ranking a recruiter cannot see the basis for. The human decision is an explicit action, logged against the deciding user's identity, and the log is exportable for labour inspection.
Retention is configured per data source. Deletion runs as an automated job with a verifiable log, and it includes indexes and backups within the stated window.
The word doing the work in that sentence is "indexes". A vector index built from a dataset is a derivative of that dataset. Deleting the source rows and leaving the index in place is not deletion, and a DPO who has seen a few AI deployments will ask specifically about it.
The best question and the one most vendors have not prepared for.
Indicators below the confidence threshold are shown as below-threshold in the interface and in every export. They are excluded from the composite index, with a visible note saying which ones and why. There is no configuration that suppresses this, because the moment such a setting exists, somebody will turn it on before a council meeting.
When we get a published number wrong, we correct it in the same channel it appeared in, visibly, with the date of the correction. That is a policy rather than an architectural control, and we say so.
Two reasons.
The first is straightforwardly commercial. A DPO who finds these answers on a public page before the first meeting arrives at that meeting with harder and better questions, and the conversation starts two steps further along.
The second is that the questions are good. They are the right questions to ask any vendor putting an AI system near municipal data, including ones who are not us. A procurement process where they get asked every time produces better systems than one where they do not.
Follow the work
We publish when there is something to publish, which is roughly monthly. If you would like the next piece, write to hello@humaniwork.com with the word Signals. No list, no automation, no sequence. One of us adds you and one of us sends it.
Field brief
15 JUL 2026 · 4 min
The interval between a neighbourhood signal appearing in administrative data and the point where a response still changes the outcome is about six weeks. Most municipalities are working eighteen months behind it.
Dr. Krishna Hari Pushkar
Data
30 JUN 2026 · 4 min
More than a quarter of Catalonia’s residents were born outside Spain. The figure is accurate, widely quoted, and almost useless for planning a service, because the thing it averages away is the thing you need.
Dr. Krishna Hari Pushkar
Case study
22 APR 2026 · 4 min
We took the diagnostic requirements of a live Catalan funding instrument and checked each one against what a municipality can actually produce from published sources today. Roughly half are answerable. The unanswerable half is consistently the operational half.
Dr. Krishna Hari Pushkar