Plataformas urbanas de inteligencia artificial

The Smartest Municipal AI Project May Be the One a City Delays

Photo by Sean Foster (@fosterious) on Unsplash

Municipalities are under pressure to introduce AI assistants, automated case processing and citizen-facing chatbots, yet many still struggle with more basic questions: which department owns a dataset, whether two registers describe the same person consistently, or whether information submitted through an online form reaches the responsible system without being copied manually. Adding AI to that environment does not modernise the administration. It merely gives unreliable data a faster route through it.

Before a municipality deploys another model, it needs to know whether its records are accurate, accessible and legally reusable across departments. Processes must be documented, responsibilities assigned and interfaces created between systems that were often purchased at different times for entirely different purposes. Without that foundation, AI projects remain demonstrations rather than administrative infrastructure. The most useful municipal AI programme may therefore begin without an AI tool at all, starting instead with corrected addresses, reconciled property records, standardised case categories and a clear decision on which register is authoritative when two systems disagree.

AI cannot decide which municipal record is correct

A model can summarise a case file, classify an incoming request or suggest a response, but it cannot reliably determine which source should be trusted when municipal systems contradict one another. A resident may appear under slightly different names in separate databases, while a property can have one address in the tax system, another in the planning register and an outdated designation in utility records. The same organisation may be identified by a registration number in one department and entered manually under several different names in another.

Employees often resolve these inconsistencies through experience. They know which colleague to call, which spreadsheet contains the latest version and which system has not been updated since a previous reorganisation. This informal knowledge keeps the administration functioning, but it cannot support dependable automation. An AI assistant connected to all available records may produce an answer that sounds precise without recognising that the underlying sources conflict, whereas an experienced employee would have treated the same information cautiously.

The first requirement is therefore not wider access to data, but an agreed hierarchy of data. Every core item should have an authoritative source, whether it concerns an address, the status of a permit or the validity of a payment. Other systems may reuse that information, but they should not silently maintain competing versions. AI can work across several datasets only after the municipality understands what each one represents and who is responsible for correcting it.

A chatbot cannot repair a broken process

Citizen-facing AI is attractive because it appears to solve an immediate problem. Residents struggle to find information, while municipal teams spend time answering recurring questions, so a chatbot offering permanent availability and lower support costs seems like an obvious improvement. Its value remains limited, however, when the service behind it is unclear.

A resident may ask which documents are required for a permit and receive an answer based on the municipal website. If the responsible department applies additional requirements in practice, the chatbot has not solved the problem; it has made the inconsistency more visible. The same applies when rules differ between public guidance, internal instructions and older documents that remain online. A language model can retrieve and combine those sources, but it cannot establish which version represents current practice unless someone has already resolved the contradiction.

Before automating answers, the authority should ask why residents need to ask the question in the first place. The application instructions may be incomplete, two departments may use different terminology or the process may have changed without all public information being updated. Correcting those weaknesses improves the service for everyone, including residents who never use the chatbot. AI should therefore be introduced only after the municipality has established a clear legal basis, documented procedure and reliable source material. Otherwise, it is automating uncertainty rather than reducing it.

Data ownership is an administrative responsibility

Municipal data is often treated as a technical asset managed by the IT department, although its quality depends primarily on the departments that create, interpret and update it. IT teams can maintain servers, interfaces and access controls, but they cannot decide whether a planning status has been classified correctly or whether a social-service case should remain active. Those decisions belong to the administrative units responsible for the underlying process.

Each important dataset therefore needs a business owner as well as a technical custodian. The owner defines what the data represents, when it must be updated, which quality standards apply and who may use it. The technical custodian ensures that the system remains available, secure and interoperable. Without this division of responsibility, data problems are passed between departments: administrators assume that IT will correct them, while IT lacks the subject knowledge and authority to determine what the correct record should be.

AI makes this ambiguity more consequential because the municipality must be able to explain not only what a system recommended, but also which information supported that recommendation and who was responsible for its accuracy. A model cannot become the owner of the data it consumes.

Decisions should be standardised before they are automated

Many municipal procedures combine fixed rules, professional judgement and local convention. Some checks can be automated safely, such as verifying whether a required field has been completed, whether an address exists in the official register or whether a deadline has passed. Other decisions require interpretation, proportionality or an assessment of individual circumstances. Problems arise when municipalities attempt to automate a process before identifying where that distinction lies.

If employees handle similar cases differently, an AI system trained on historical decisions may simply reproduce those inconsistencies. It may learn which outcomes occurred most frequently without understanding whether they reflected the law, operational habit or the preferences of individual caseworkers. Historical data should therefore not be treated automatically as a reliable expression of policy.

Before past cases are used to support future decisions, the municipality needs consistent categories, documented exceptions and a clear separation between outdated practice and current legal requirements. The objective is not to eliminate professional judgement, but to define where it is necessary and where routine work can be handled consistently. AI is most useful when it prepares a case, identifies missing information and directs attention to relevant rules. It becomes more problematic when the administration cannot explain whether its recommendation is merely advisory or effectively determines the result.

Fragmented procurement produces fragmented data

Municipal systems rarely form one coherent architecture. They accumulate over years through separate procurements for taxation, construction, social services, mobility, human resources and document management. Each supplier defines data differently, while interfaces may be limited, proprietary or expensive to build. Departments adapt their work to the software available, often creating spreadsheets and manual workarounds where systems do not connect.

An AI project placed over this landscape can create the appearance of integration without resolving the underlying problem. A model may search several systems through one interface, yet the data remains duplicated, updates do not move automatically and departments continue to maintain different versions of the same record. The municipality gains a new search layer but not a functioning information architecture.

Interoperability must therefore become a core procurement requirement rather than an optional technical feature. New systems should provide documented interfaces, standard export formats and a realistic route for moving data to another supplier. The municipality should retain control over its data definitions and be able to integrate the system without depending entirely on the original vendor. This does not require every department to use identical software, since specialist processes may need specialist tools, but those tools should still participate in a shared architecture.

The true cost of a municipal system is not only the licence fee. It includes the years of effort required to extract, reconcile and reuse the data it contains.

Smaller municipalities should share foundations, not repeat the same pilots

A smaller city may not have the budget or internal expertise to build an AI platform, establish data governance and maintain several secure integrations independently. Shared infrastructure can therefore be valuable, particularly for identity services, secure messaging, language-model hosting, logging and access control. Municipalities can also share templates for data inventories, risk assessments and procurement requirements while retaining responsibility for local decisions and resident information.

The problem is that collaboration often begins too late. Several municipalities commission separate pilots, encounter the same technical and organisational obstacles and only then consider whether the underlying infrastructure could have been shared. A stronger model separates the common layer from the local one from the beginning. The technology can be pooled where needs are comparable, while each authority remains responsible for interpreting its own data, deciding which services to automate and determining who may approve an outcome.

The aim is not to make every administration identical. It is to stop paying repeatedly for the same foundations while preserving local accountability.

AI readiness should be tested through one real service

Broad strategy documents can describe potential use cases, ethical principles and governance structures, but they do not reveal whether a particular service is ready for automation. A practical readiness audit should therefore follow one process from beginning to end.

A municipality might begin with a high-volume procedure such as a parking permit, business registration or building-related enquiry. It should identify where the application begins, how the applicant is authenticated, which information is requested and which systems receive the data. It should then examine where information is copied manually, where employees correct recurring errors and where the process depends on knowledge that exists only in personal notes or experience. The legal rules, local guidance and exception handling used to reach the final decision must also be documented.

This exercise often reveals that the best initial improvement is not an AI model. The municipality may discover that duplicate data entry, an obsolete internal form or inconsistent case categories create more delay than the task selected for automation. It may also find that AI could already assist with a narrow function, such as classifying requests or drafting standard correspondence, without being allowed to determine the outcome.

The use case should determine the technology, not the other way around.

Data quality is an operating discipline, not a one-time project

Municipalities sometimes treat data cleansing as a preliminary exercise that can be completed before the “real” digital work begins. In practice, data does not remain clean automatically. Residents move, organisations change names, properties are divided and regulations create new categories. Employees enter information under time pressure, while integrations fail or apply incompatible formats. A one-time correction may improve a database temporarily, but the same problems return if the process that created them remains unchanged.

Data quality therefore requires continuous operating rules. Systems should validate entries where possible, prevent avoidable duplication and record who changed significant information. Departments need procedures for correcting errors and communicating those corrections to connected systems. Quality indicators can identify unusual records, missing values and inconsistent formats, but those indicators must be linked to responsibility. A dashboard showing that a dataset contains errors has little value when no department is required to resolve them.

AI can help detect anomalies or suggest matches between records, but it should not merge or overwrite sensitive information without appropriate controls. The objective is to build an administration that produces reliable data during its normal work, rather than one that periodically repairs a deteriorating database.

Employees must be able to see the evidence behind an answer

An AI assistant may produce a fluent summary in seconds, but the employee still needs to know whether it is complete and which source supports it. This is particularly important in public administration because decisions must often be explained, challenged and reviewed. A resident denied a permit or benefit is entitled to more than an assurance that a model generated the recommendation.

Municipal AI systems should therefore show the relevant source documents, rules and records behind their output. Employees must be able to distinguish between retrieved facts, generated text and inferred conclusions. When data conflicts or a source appears outdated, the system should make that uncertainty visible rather than silently selecting the most likely answer.

Training should focus on these practical distinctions. Employees do not need to become machine-learning specialists, but they do need to understand that fluent language is not evidence of accuracy. The better a model writes, the easier it becomes to overlook a weak foundation.

AI should remove work rather than create another layer

A pilot can appear successful while increasing the administrative burden. Employees may need to review every generated answer, document why they accepted or rejected it and then enter the final result into another system. The AI produces an additional output without replacing any existing step.

That may be acceptable during testing, but it is not a sustainable operating model. Before deployment, the municipality should identify which task will disappear, become faster or require less repetition, then compare that expected saving with the cost of supervision, technical maintenance, licensing and data preparation. A tool that saves two minutes per case but creates a new governance process may not be worthwhile at low volumes, while a modest automation applied to thousands of standard enquiries may deliver considerable value.

Success should be measured through processing time, error rates, completed applications, staff effort and resident satisfaction. The number of pilots says little about whether an administration has become more capable.

Security and access controls must follow the data

Connecting an AI system to municipal records creates a new access layer across information that may include personal, financial and legally protected data. The model should therefore receive only the information necessary for the task. A chatbot answering waste-collection questions does not need access to resident files, while an internal assistant supporting planning cases should not retrieve social-service records merely because both systems belong to the municipality.

Permissions must reflect employee roles, case responsibility and legal purpose. The fact that an AI tool can search several databases does not mean every user should be able to do so. Logging is equally important: the municipality should know which information was accessed, which output was produced and whether it contributed to an administrative decision.

The risk becomes greater when external providers process prompts or retain interaction data. Procurement must establish where the model operates, whether municipal information can be used for training and how data can be removed when the contract ends. Data governance is therefore inseparable from AI governance. A municipality that does not know where its information is stored or who can reuse it is not ready to connect that information to a model.

Municipalities need fewer demonstrations and stronger operating systems

AI pilots are popular because they create visible results quickly. A chatbot can be demonstrated within weeks, while a document assistant can summarise a case during a presentation. These projects make innovation tangible to political leaders and the public. Building usable municipal data is slower because it requires departments to agree on definitions, correct records and reconsider procedures that have been accepted for years. It also exposes organisational weaknesses that technology alone cannot solve.

That work is less attractive to announce, but it creates lasting capacity. Once data is reliable and systems can exchange it, online services become easier to complete, reporting improves, employees spend less time searching for information and residents are asked for the same details less often. AI can then become one tool within a functioning digital administration, helping to classify requests, prepare files, identify anomalies or draft communication because the records beneath it are sufficiently clear.

Municipalities do not need to wait until every dataset is perfect. They do need to know where the critical weaknesses are and whether those weaknesses affect the proposed use case. The question before an AI project should not be whether a model can perform a task in a demonstration, but whether the administration can supply accurate information, explain the result and integrate it into a process that works from beginning to end.

Where the answer is no, delaying the pilot is not a failure of ambition. It is evidence that the municipality understands what meaningful digitalisation requires.

  The Smartest Municipal AI Project May Be the One a City Delays