What a town hall of 20,000 residents can do with AI

AI for local government: which processes are worth automating with open models, and how

The town hall we have taken as the example for this article has 20,600 residents, a municipal secretary and a comptroller who sign off on everything that comes in and everything that goes out, ten administrative staff and one full council session a month. This one, specifically, has two people on IT and support.

It has had an e-government portal since 2018, an IT company from the district that comes over when something breaks, and zero people dedicated to rolling out AI or anything like it.

It is a perfectly ordinary town hall. And that is exactly why it is a good place to talk about artificial intelligence.

A small town hall has little to do with AI labs, its own models, or servers full of GPUs. Its problem is a different one: taking repetitive work off a small team without losing control over the data or over the decisions.

So the useful question is this one:

Which of the town hall's work is worth handing to a machine, and which must a person keep doing?

That is the question we put to them in an interview about their use case, and the answer is fairly encouraging given how public administration has evolved these past years. Classifying documents. Transcribing council sessions. Searching by-laws. Watching for grants. Preparing drafts. Extracting data from invoices.

Paperwork. Boring, tedious and repetitive.

And that is precisely what makes it interesting, because it allows for a lot of automation.

This is the case of a small town hall, but today Helmcode is used by councils of 10,000, of 30,000 and of 220,000 residents. Size changes the volume, but for many of them the type of work is the same.

AI for local government: where to start

We asked them how they started rolling AI out. Ideas about building a citizen chatbot came up at the beginning, but the reality is that day-to-day work buries them and leaves no room to worry about improving things around the municipality.

So they started with tasks that meet four conditions: they come in decent volume, they follow relatively stable rules, they eat the time of qualified staff, and they let a person review the result before it has consequences.

The idea behind those rules is plain: no important decision is taken without a person reviewing the result. That filter rules out some of AI's most spectacular demos, but it lands on a good share of the work that actually takes up hours in a small administration.

We put together this table of common use cases, their risk, and how much room there is to bring AI in.

| --- | --- | --- | --- |

There is one important idea before going on: the AI prepares and the civil servant decides. In the cases that follow, that is the rule. Let us look at some of them in detail.

1. Incoming filings: could somebody please stop classifying PDFs by hand

Every morning filings come in through the e-government portal: a noise complaint, an application for a minor works permit, a formal objection, a terrace licence renewal. Somebody has to open them, work out what they are about, identify the applicant, put the information into the case management system and send them on to the right department.

Here the AI does not have to take any administrative decision. It does the first pass: it classifies the type of procedure, extracts the applicant, the subject and the references, identifies the attached documentation, proposes the destination department and returns structured data to the case management system. The civil servant checks the proposal and corrects it where needed.

The architecture is simple: e-government portal → document → model → structured data → case management system → human review.

And the model does not need to be enormous: classification and extraction are exactly the tasks where small models do best per euro. In this case they are doing it with Gemma4.

This town hall classifies an average of 30 filings a day. Around 11,000 a year.

Not all of it is automatic and pretty. Where does it fail? In the places that are already hard for a person. A crooked scan in a PDF will still be a crooked scan, and a filing written in ambiguous language will still be ambiguous. Those go to the human queue.

2. Council minutes: from transcribing to reviewing

Ask a municipal secretary how long it takes to turn a two-hour council session into a draft set of minutes. The answer will probably start with "it depends" and end in a few hours of the working day. And the problem does not stop at the full session: there are the governing board meetings, the committees and the procurement panels, all of which have to be documented too.

The flow has two pieces. First, an open speech recognition model such as Whisper turns the audio into a transcript. Then a language model structures that transcript following the town hall's template: attendees, agenda, summarised interventions, motions, resolutions and the outcome of the votes.

The result is a draft set of minutes. The secretary checks names, interventions and votes, corrects what needs correcting, and files it into the procedure.

The usual errors they have run into: voices talking over each other, local proper names, local terminology, and attributing who said what, which is never perfect.

It works as assistance in drawing up the minutes rather than as closed automation. You have to review, cut things, or improve the transcript where it did not come out right. But it is a matter of 10 minutes.

Getting started takes little: decent room microphones, the minutes template, and the habit of recording. Many council sessions are already streamed, so the audio exists; what was missing was what to do with it so it ended up recorded and findable.

3. Public notices and communications: one piece of information, five formats

On Thursday the water goes off on the high street from 9 to 14 because of building work. That is three facts, and somebody has to turn them into an official notice, a news item for the website, a post for social media, a short alert for WhatsApp and, in many municipalities, a second version of all of it in the co-official language.

Here it makes sense to use a generative model very directly. You give it the facts and a template with the institutional style, and it returns the different versions in one go, with the co-official language in the same pass. The person responsible reviews, corrects what is needed, and publishes.

And if the four channels are connected, it publishes to all of them with one click.

What takes an hour today can be done in ten minutes.

4. Grant calls: probably the case with the most return

This is the least directly useful case for residents, but it may be the most profitable one indirectly. Small municipalities live to a good extent on grant calls: provincial councils, regional governments, central government and European programmes.

And the problem usually starts before the application: somebody has to find them, read them, check whether they fit, look at the deadline and decide whether preparing an application is worth it.

A call can appear on a Tuesday with twenty days to run, and if nobody spots it in time that is money the municipality is losing.

Here it makes sense to build a small "watchman" pipeline. Every week the system goes through the state gazette, the regional gazette, the provincial gazette and the portals of the awarding bodies, and sorts every call into three piles against the municipality's profile: fits, does not fit, review.

For the ones that fit, it extracts amount, eligible applicants, deadline, requirements, documentation and scoring criteria, and leaves a first outline of the application memo started with what it already knows about the town hall.

The person responsible still decides, but they start from a short list of opportunities instead of hundreds of pages to read. A single recovered call worth 30,000 or 40,000 euros pays for the platform for years.

5. Looking up by-laws without digging through twenty PDFs

Another far more everyday scenario: a technical officer needs to know what deposit the public-space occupation by-law sets, until what time terraces may operate, or what documentation a particular licence requires. The information exists, but finding it is the problem.

A RAG system indexes the by-laws, the regulations and the internal documentation, and lets you ask in natural language. With one condition: the answer has to show its source. A document search engine that understands natural language.

Then there is the problem of versions. A by-law may have its original 2009 text, an amendment from 2014, another from 2018, and several documents published in different places. Feed all of that in unsorted and the system will retrieve old versions. AI does not fix poor document management; it can even make it easier to hide. That is why preparing the corpus (the data, the documents) is part of the project.

Does that citizen-facing chatbot or RAG make sense?

They did not do it as the first project. They are trying it internally first, and only once the town hall has its documentation in order, its versions under control, its answers evaluated and a procedure for correcting mistakes will they consider a citizen-facing interface.

With one fundamental difference from a general-purpose chatbot: every answer must be able to take the citizen to the source, and must always offer a way to talk to a person. On top of that, the transparency obligations in Article 50 of the AI Act have applied since 2 August 2026, and in July the European Commission adopted the guidelines for applying it . So the citizen has to know they are interacting with an AI system.

The advantage here is in the phone calls avoided: every query about opening hours or paperwork that the AI assistant resolves at nine at night is one fewer call at nine the next morning.

6. Financial control: a lot of extraction work and very little magic

The financial control office has another bundle of tasks tailor-made for this: extracting invoice data, comparing quotes, structuring budget information, preparing draft memos, summarising documentation, locating information inside case files.

Here again the model does not need to decide anything; it turns messy documents into structured information. Three quotes in PDF → extraction → comparison table → review. An invoice → structured fields → validation. What today is basically copying cells across.

The principle is the same as with incoming filings: the AI does the mechanical work, and the public employee checks the result and takes the decisions that are theirs to take.

Where putting AI into a town hall makes no sense

Knowing the off-limits areas matters almost as much as knowing the permitted ones: many civil servants are not familiar with the law that applies to AI, but having this under control is what lets you defend the project in front of the secretary, the DPO and the full council. The general rule:

The more directly the result affects a person's rights, benefits or situation, the higher the bar for security, oversight and justification.

Not for automated administrative decisions (Law 40/2015, Article 41)

Spanish Law 40/2015 expressly addresses automated administrative action in its Article 41 : where it exists, the bodies responsible for definition, programming, maintenance, oversight and quality control must be designated in advance, along with the body answerable for appeals.

A model wired to an API does not by itself turn a procedure into automated administrative action under that regime, because the review and the decision always sit with a human. That is why this article talks about drafts and assistance.

Do not put a model in charge of what directly affects people (high risk under the AI Act)

The AI Act treats as high risk, in its Annex III, certain systems used by public authorities to evaluate people's eligibility for essential services and benefits.

Open model, ChatGPT, a foreign API or your own server?

This is probably the question that comes up after reading all of the above. The answer is that it depends on the data, the provider, the processing and the service.

But for a small town hall we usually frame it like this:

| Option | Our assessment |

| --- | --- |

| A consumer tool (for example ChatGPT) for municipal data | Not as general policy |

| An external provider's API (Claude, Gemini, and so on) | It depends: processing, transfers, retention and contract all need review |

| An open model on European infrastructure | Yes, the most interesting option |

| A model trained by the town hall itself | Makes no sense in most cases |

| Buying GPUs and running your own infrastructure | Usually not either |

One of the most important things open models bring: technological sovereignty does not mean operating a data centre. A town hall of 30,000 residents is not going to hire somebody to maintain GPUs and run inference.

It can use open models deployed on managed infrastructure, as long as the provider explains where the information is processed, what is retained, for how long, and how the service fits the applicable security requirements. The model is only one piece.

What a municipal AI project actually looks like

A simple implementation has five pieces:

The model, which does the task.
The infrastructure, which decides where it runs and where the data travels.
The integration, through which information arrives from the portal, the case management system, email or the archive.
The data, meaning documents, by-laws, templates and the context the system needs.
The governance, which sets who may use it, what data they may put in, what gets logged, who reviews the results and what happens when the model fails.

In many projects the first piece gets talked about endlessly and the other four barely at all. In a town hall the model may be the easy part. The hard part is the integration and the data.

GDPR and municipal AI: where does data protection come in?

What about residents' personal data?

The first thing is to look at the use cases through that lens, because they have little in common with each other. Public notices, grant watching and the internal by-law search barely touch personal data: a water outage carries no ID numbers, official gazettes are public information, and by-laws carry no names either.

With those you could start tomorrow without opening any legal can of worms.

Incoming filings, on the other hand, are personal data in its purest form: every filing carries a name, an ID number and an address, and sometimes special categories (a complaint can reveal health data; an application for social assistance certainly carries it). Minutes too: the voice in a council session is personal data, and residents appear in the interventions by name. Invoices carry supplier data, and when the supplier is a sole trader that is a natural person. And the citizen chatbot has a problem of its own: even if you do not ask for data, people type it in.

The data-heavy cases are still the same old GDPR question, applied to a new processor. The town hall is the controller and the inference provider is a processor: with no data processing agreement ( Article 28 GDPR ) there is no project.

But it is important to understand the processor's role properly:

What does the inference provider, in this case us, retain of each request? Helmcode retains nothing.
Is the data used to train models? No.

In practice we recommend anonymising citizen data by substituting tokens or something equivalent, clearing context between sessions, and strict user access control. It can be done safely.

Municipal AI does not need to be spectacular

There is an understandable temptation to start with the showy part: the chatbot that talks to citizens, the agent that does things on its own.

But a small town hall gets far more value out of something a good deal less sexy: one person no longer opening 40 PDFs every Monday. Nobody having to listen to two hours of a council session to find where a particular item was voted on. A 40,000-euro grant call not slipping past because nobody had time to read the gazette that day. Municipal AI done well gives the team back time for the work a machine should not be doing.

You do not need a grand artificial intelligence strategy to start, either.

You need a simpler question: which repetitive task is eating the hours of people we need for something else? And a short path: measure how much time it takes, check what risk it carries, decide which part a machine can do, keep human review where it belongs, choose where and how the data will be processed, run it for 90 days and measure the result.

If it works, scale it; if it does not, change it.

At Helmcode we work in exactly that layer: running open models on European infrastructure so that an organisation can use different models without building and maintaining a whole inference stack.

In a public-sector setting that layer matters as much as the model: where the information is processed, what is retained, and how the service can be controlled. The detail on compliance, models and deployment is on the public sector page .

A town hall of 5,000, of 10,000 or of 20,000 residents, with one secretary-comptroller and three administrative staff, can use the same technology today as a provincial capital.

The questions a town hall should really be asking

Can I use ChatGPT in a town hall?

Ahead of the brand, what matters is what data you put in, what processing the provider carries out, where it happens, what safeguards exist and for what purpose. Drafting a text with no personal data in a consumer tool is one thing; sending a filing containing a resident's data to an external service is quite another. For municipal data the analysis is about the specific processing and the provider, rather than about the name of the model or the tool.

Can AI sign or decide a case file?

Automated administrative action has its own regime in Article 41 of Law 40/2015, with responsibilities and controls defined in advance, and wiring an LLM to an API does not meet that regime by itself. In the use cases in this article the AI drafts, classifies, extracts, summarises or proposes; the administrative decision remains the responsibility of whoever holds it.

Do I need an enormous model?

No. For classifying filings, extracting fields, transcribing audio or transforming documents, a small model can be more than enough; the large ones make sense when the task calls for more reasoning or more context.

What if my town hall has no IT staff?

Like almost none under 20,000 residents. The three realistic routes: the IT company that already runs your systems, a govtech that integrates it into its product, or your provincial council's support service.

Does it work in Valencian, Catalan, Galician or Basque?

Yes, though performance depends on the model and on the specific task. Spain also has public initiatives such as ALIA , which develops open models and resources for Spanish and the co-official languages. For a bilingual town hall, the sensible thing is to evaluate the model against real municipal documentation before choosing it.

What should I ask a provider for?

At a minimum:

where it runs the models;
where the data is processed;
what information it retains and for how long;
who has access;
what sub-processors it uses;
how it deletes data;
what security measures it applies;
what documentation it can supply for the Spanish national security framework (ENS);
which models it uses;
and how you can change model or provider in future.

That last question matters too: public administration should not build unnecessary technological dependence around a single provider.

If you want the detail of what the AI Act asks of you by profile, it is in the checklist and in our AI Act guide .