In my previous article, ChatBot della PA, I addressed the role of artificial intelligence in the relationship between government and citizens. I argued that public information should be made accessible through authoritative, structured and queryable sources, rather than by multiplying conversational assistants on institutional portals.
The same approach can be extended to the internal processes of local authorities, where the growing availability of information systems has not eliminated a significant amount of manual work devoted to interpreting, classifying and transferring information. A municipality may have a document registry, a document management system, and tax, financial and demographic applications, and still employ staff to connect data and documents that belong to the same procedure but reside in different systems.
This situation depends partly on the still incomplete interoperability of applications and partly on the nature of the information being handled. Traditional integrations work effectively when data have known structures and operations can be described through deterministic rules. They become more complex when it is necessary to interpret communications, reports, applications and documents written in natural language.
Language models and document processing technologies now make it possible to tackle some of these activities without developing a specific model for each administration. The introduction of artificial intelligence can therefore be designed as an evolution of the organization's information architecture, in which interpretation and classification capabilities are made available to existing systems through shared services.
For this approach to be sustainable, however, the probabilistic capabilities of the models must be separated from the rules that govern procedures, authorizations and application operations. Building that separation is the technical and administrative problem on which this article focuses.
Automation opportunities in local authorities
The repetitive tasks found in municipal offices offer many possible applications, especially when information systems already have integration interfaces or can be adapted to provide them.
- Document management and administrative activities. Classification of incoming communications, suggested routing to offices, extraction of data from attachments, search for related documents, identification of deadlines, comparison of versions of acts, drafting of documents and assisted creation of the resulting tasks.
- Taxes, budget and contracts. Classification of applications, recognition of cadastral and tax information, document comparison, preliminary checks on the completeness of files, matching of supporting documents to contracts, extraction of obligations and deadlines, and assisted consultation of regulations and tender specifications.
- Building, urban planning, property and public works. Analysis of technical reports, preliminary document checks, consultation of urban planning rules, organization of opinions, reading of minutes, monitoring of project schedules, classification of reports and linking of maintenance activities to buildings.
- Personnel, demographic, educational and social services. Search of operating instructions, organization of administrative requests, drafting of informational communications, document management of applications, assistance in checking attachments and updating of internal tasks, with controls proportionate to the sensitivity of the information and the effects of the processing.
- Management, planning and monitoring. Extraction of requirements from funding acts and documents, organization of evidence, comparison of progress reports, preparation of summaries, identification of tasks still to be completed and monitoring of contractual and organizational obligations.
These applications share one characteristic. The AI model interprets information, produces structured representations or retrieves relevant content, while administrative systems continue to govern the operations that belong to their own domain.
The technical possibility of automating a function does not automatically make it admissible. A system that organizes documents raises different issues from one that takes part in evaluating people or determining benefits. Moreover, not all repetitive tasks require artificial intelligence. When data are structured and rules are known, traditional automation generally offers greater predictability and simpler error control.
The analysis of opportunities should therefore focus on the specific contribution AI can make, avoiding replacing with probabilistic processing operations that can be performed through ordinary application rules.
1. From process mapping to administrative governance
The design should start with a survey of processes, systems and data processing activities, coordinated within the organization's digital governance. Before evaluating models and vendors, the administration must know which operations it intends to automate, which information is needed, who is responsible for it and what consequences an incorrect result could have.
The Head of Digital Transition (Responsabile per la Transizione al Digitale), to whom Article 17 of the CAD entrusts the organization's transition to digital operation, coordinates the technology strategy by working with senior management, the heads of information systems, the owners of administrative functions and the professionals responsible for data protection. The organization must keep the responsibility for the technology infrastructure distinct from that for the procedures that will use AI capabilities.
The survey must produce a catalog of services and their dependencies, in which each possible automation is associated with a purpose, the systems involved, the categories of information processed and the level of autonomy required. This analysis also makes it possible to identify services that can share the same technological capabilities, avoiding the purchase of multiple solutions for substantially equivalent tasks.
The project should then be brought into the digital planning process and authorized through the acts appropriate to the organization's structure and the nature of the initiative. When external services or supplies are needed, the procurement path must be defined in accordance with the Public Contracts Code, distinguishing functional requirements from the characteristics of a specific commercial product.
At this stage the GDPR requires defining the legal bases for processing, verifying the necessity of the information used and identifying appropriate protective measures. Any impact assessment required under Article 35 must be carried out when its conditions are met, without treating local execution of the model alone as a sufficient safeguard.
The European framework also requires the system to be classified under the AI Act. Not all AI applications used by an administration are high-risk, as that classification depends on the intended use and the conditions set out in the regulation.
Regulation (EU) 2026/1744, published on July 24, 2026 and in force since July 27, amended the AI Act's implementation timeline, postponing to December 2, 2027 the application of obligations for the high-risk systems of Annex III and to August 2, 2028 those for high-risk systems linked to the regulated products of Annex I. The obligations of Article 27 on the fundamental rights impact assessment, where they apply, likewise follow the timeline applicable to the relevant category of systems.
In Italy, Article 14 of Law 132/2025 recognizes the use of AI to improve administrative efficiency and service quality, while keeping its role instrumental and supportive to decision-making, with responsibility for decisions remaining with the individual. The provision also requires ensuring that the functioning of the system is knowable and that its use is traceable.
Administrations can also use AgID's AI documents as methodological references, though they should distinguish their adoption status. The guidelines on adoption, published with Determination 17/2025 and put out for consultation from February 18 to March 20, 2025, are still going through the final stages of the process. The guidelines on development and procurement, the subject of Determination 43/2026, were put out for consultation from March 12 to April 11, 2026 and do not yet appear to have been definitively adopted.
At the end of the administrative phase, the organization should have a formally defined perimeter, with purposes, responsibilities, permitted processing, operational limits and evaluation criteria. These elements are architectural requirements, not mere paperwork to be completed after the software has been built.
2. Building the architecture on APIs and interoperability
An AI system intended to operate across municipal services must integrate with existing applications without taking over their responsibilities.
The prerequisite is the availability of application interfaces through which information can be retrieved and operations requested in an authenticated and verifiable way. Direct database access should be avoided when domain APIs exist, because bypassing the logic of the management systems means giving up the controls, rules and safeguards implemented by the systems that own the information.
For the Italian public administration, this path must be consistent with the Interoperability Model, ModI, and with AgID's guidelines on technical interoperability and API security. The model defines principles and tools for building documented, versioned and protected interfaces, promoting integration between systems without making them dependent on their internal implementations.
APIs are the boundary through which a system exposes functionality and data under controlled conditions. An AI gateway should therefore not develop arbitrary integrations with application data stores, but use services that comply with explicit contracts, providing for authentication, authorization, traceability and error handling.
The Piattaforma Digitale Nazionale Dati (PDND) can play an important role when automation requires information made available by other administrations through e-services. PDND enables interoperability relationships between participating entities, through mechanisms for identification, authorization and consumption of APIs.
It is necessary, however, to distinguish internal integrations from interactions between administrations. PDND is not the mandatory channel through which all calls between a municipality's applications and its AI gateway must pass. The gateway can use internal APIs for the organization's systems and, when necessary and authorized, access external e-services through the methods provided by the interoperability ecosystem.
The existence of an API, even when technically accessible, does not automatically grant the right to use its information for any purpose. Authorizations for consumption, the legal basis for processing and the limits of use must be verified in the context of the application.
In the design phase it is advisable to adopt application contracts that are independent of individual language models, described using standards such as OpenAPI and formalized data schemas. Operations should be organized by capability, distinguishing queries from persistent changes.
For asynchronous flows, in which processing may take longer than a synchronous HTTP call allows, application events and persistent queues can be used. The system must maintain correlation identifiers that make it possible to reconstruct the relationship between the request, the AI processing and the subsequent operation.
This structure makes it possible to use AI as a component of the application architecture, keeping data in the competent systems and reducing the risk of creating new, ungoverned parallel repositories.
3. The AI gateway as a component of the information system
Connecting every application directly to an AI provider is simple to implement, but hard to sustain as the number of services grows. Each integration ends up embedding credentials, specific formats, data rules, configurations and error-handling methods, making it difficult to apply uniform policies and to replace the technologies in use.
A shared AI gateway makes it possible to separate these responsibilities through a common access layer to models and processing capabilities.
The architecture must distinguish the control plane, in which the administration defines identities, authorizations, policies and permitted models, from the processing plane, in which requests are actually executed. This distinction makes it possible to change technology destinations without rewriting the rules that determine whether processing is permitted.
The gateway must receive requests from authenticated applications and identify their operational context. An application token, for example one obtained through OAuth 2.0-based mechanisms and verified for audience, authorization scopes and validity, can let the service know the identity of the caller. When the application acts on behalf of a person, the user's actual permissions must also factor into the evaluation.
Access to AI capabilities should be governed through formalized rules, not through instructions entrusted solely to the language model.
One possible architecture includes a Policy Decision Point, responsible for evaluating the conditions of the request, and a Policy Enforcement Point, which concretely applies the decision by preventing the invocation of unauthorized models or tools.
The decision takes into account the purpose of the service, the origin and classification of the information, the available permissions, the characteristics of the providers and the operations requested. The classification declared by the client should not be accepted without checks when the system has more reliable information about the nature of the data.
Only after this verification can the gateway choose the model to use, possibly optimizing the selection on the basis of measured quality, latency, availability and cost.
The fundamental principle is that model optimization takes place within the set of permitted destinations, and cannot change the conditions that make the processing admissible.
A more powerful cloud model must not automatically become the substitute for an unavailable local model when the information cannot be transmitted to the external provider. In these circumstances the system must stop the processing or use an authorized alternative path.
The gateway could expose services for classification, structured extraction, constrained generation, document search and controlled use of tools, maintaining a catalog of models and providers that records the technical and contractual characteristics of each destination.
PA Router, a project I am developing to govern, through policies, access to local models, cloud services and agentic tools, also fits this perspective and could evolve into a shared gateway usable by the applications of local authorities.
The gateway must not, however, replace the engine that governs the administrative process. Transitions, human interventions, operations on management systems and completion conditions remain the responsibility of domain applications or workflow systems.
For each AI request, the gateway therefore identifies the service, verifies authorizations, applies data policies, chooses an admissible destination, performs the processing and validates the output. Only afterward does the application system decide whether to use the result to continue its own process.
This separation is also essential for operational continuity. An outage of the gateway should not prevent the operation of procedures that can be handled through ordinary administrative systems.
4. Local models, European cloud and data sovereignty
The choice of models must depend on the characteristics of the tasks and the data, avoiding the assumption that a single generative model is suitable for all the organization's needs.
For narrowly scoped classifications, document extraction and interpretation of short content, smaller models run on local infrastructure or dedicated services can be considered. Technologies such as Ollama and vLLM make it possible to build inference environments accessible through APIs, while families of open-weight models, such as Qwen and Mistral, make it possible to compare different solutions without necessarily depending on a proprietary service.
The choice should depend on measured results, not on the number of parameters. For some tasks, traditional classifiers or embedding models may be more appropriate, while linguistically complex processing may require greater generative capabilities.
A local environment offers direct control over the inference infrastructure, but requires hardware resources, maintenance, model updates and protection of interfaces. Running on the organization's own server does not automatically rule out the presence of logs, persistent memory or external connections that could lead to further processing.
The cloud, on the other hand, can provide access to more powerful models and elastic capacity without directly maintaining the entire computing infrastructure. For a public administration, however, the use of a European region does not by itself prove that the service guarantees data sovereignty.
It is necessary to verify the actual location of processing, the handling of logs and metadata, access by subcontractors, retention periods, deletion conditions and any international transfers. For Italian public bodies, it is also necessary to consider the classification of data and services and the ACN rules on cloud infrastructure and services.
Sovereignty also includes the ability to replace a vendor, export information and configurations, retain control over keys and prevent data from being used for unauthorized purposes.
A hybrid architecture can meet different needs, directing some processing to local models and other processing to cloud services permitted by policy. The gateway makes this distinction operational without shifting to individual applications the responsibility of deciding on their own where to send information.
A further issue concerns the construction of the knowledge bases used by the models. RAG architectures make it possible to retrieve relevant content from authorized repositories, reducing dependence on the knowledge embedded in the model and making it possible to trace answers back to their sources.
Retrieval must, however, respect the permissions of the original documents and their versions. Indexing must not turn confidential information into a resource that any application using the gateway can consult indiscriminately.
Embeddings also require care, because a vector transformation does not automatically anonymize the source information. It is necessary to assess whether the representations can be linked back to documents or whether personal information can be derived from the retrieval system.
This issue should be distinguished from that of the anonymity of models trained on personal data, addressed by the European Data Protection Board in Opinion 28/2024. The EDPB clarifies that a model's anonymity cannot be presumed and that the assessment requires concretely considering the possibility of obtaining personal information through the model itself. The methodological principle is also relevant to the design of knowledge bases, even though they are technically different components.
5. Orchestration, security and accountability of operations
Integrating models with administrative processes introduces a problem distinct from that of data access. A model can produce useful information, but its output remains the result of probabilistic processing and cannot be equated with a validated application transaction.
Applications should request results through structured contracts, using formal schemas and constraints on permitted values whenever possible. Constrained generation can improve compliance with the requested format, but it does not guarantee the substantive correctness of the information produced.
The receiving system must therefore verify references, data consistency, domain rules and the necessary authorizations before proceeding. A formally valid classification may be semantically wrong, just as correctly extracted information may be irrelevant to the procedure.
Operations that change the state of systems require further controls. A reliable workflow must handle unique identifiers, repeated executions, interruptions, connector errors and possible duplicates. When tasks involve multiple systems, persistent queues, idempotency mechanisms and compensation procedures for genuinely reversible operations may be needed.
The introduction of agents increases complexity, because a model can choose to invoke tools to obtain information or request actions. Protocols such as MCP can make it easier to expose functionality, but they do not give the model the right to use it.
Authorizations must be verified by independent components, following the principle of least privilege. A service authorized to consult documents should not have the credentials needed to modify them, and a model tasked with producing classifications must not be able to perform arbitrary operations on information systems.
Particular attention must be paid to prompt injection attacks, in which external information contains instructions designed to alter the model's behavior. Documents, messages and retrieved content must be treated as untrusted data as far as instructions are concerned, regardless of their apparent authority.
Protection requires separating instructions from content, limiting the available tools and verifying actions through controls external to the model. It is not enough to include in the prompt a ban on following malicious instructions.
From a legal standpoint, Article 22 of the GDPR must also be considered, concerning decisions based solely on automated processing that produce legal effects or similarly significantly affect individuals. The provision allows for exceptions and specific conditions, but it prevents individual decisions from being treated as freely automatable merely because the system is technically able to produce them.
Any human intervention must be substantive. A purely formal confirmation, given without the means to understand and challenge the result, is not necessarily an effective control.
The level of oversight should therefore be designed according to the effects of the operation, its reversibility and the ability to detect errors. Informational activities and low-impact processing may allow more autonomous modes of operation, while decisions with significant consequences require the safeguards provided by the legal framework and the administrative organization.
6. Scientifically testing the platform and governing its lifecycle
Adopting a shared AI platform requires an evaluation system that distinguishes the quality of the models from the overall reliability of the architecture.
A model can classify a document correctly and, at the same time, be used by a system that applies incorrect authorizations or handles interruptions inadequately. The evaluation must therefore consider both the language capabilities and the behavior of the infrastructure that makes them available.
For each capability, representative datasets, reference results and metrics established before the evaluation must be defined. Classifiers can be compared using precision, recall, F1 scores and confusion matrices, while document processing requires measures of the correctness of extracted fields, completeness and fidelity to sources.
The ability to recognize conditions of uncertainty plays a key role. A system that abstains when it lacks sufficient information can be more reliable than one that always produces a result.
I would not automatically use the confidence level declared by the model as a criterion for authorizing operations. This value is not necessarily a calibrated probability of correctness. Its reliability must be verified through empirical methods, distinguishing behavior across different categories of requests.
This approach is consistent with the NIST AI Risk Management Framework, which organizes risk management across the entire lifecycle of the system.
Validation should use data separate from those used to configure or optimize the models, preventing later changes to the prompts from producing an artificial fit to the test sample.
Alongside functional performance, latency, throughput, availability, resource consumption and cost per operation must be measured. For local systems, behavior under concurrent requests must also be evaluated, while for cloud services, contractual limits and variable costs must be checked.
Policy testing requires specific tests designed to show that the gateway actually blocks unauthorized destinations, that credentials do not allow operations unrelated to the service and that any unavailability does not cause data transfers incompatible with the rules.
A shadow mode phase, in which AI processing runs in parallel with ordinary processes without changing their state, makes it possible to compare results with operators' work and observe behavior under realistic conditions.
The move to production should be authorized on the basis of documented evidence, including test results, known limitations, security requirements, error-handling procedures and conditions for restoring the previous operating methods.
Maintenance also requires versioning of models, inference configurations, prompts, policies and information sources. A model update can change the system's behavior even when the APIs remain unchanged, making regression tests necessary before release.
From an organizational standpoint, the organization must identify who administers the policies, who authorizes new services, who handles incidents and who periodically reviews the results. Monitoring must produce enough information to reconstruct technical behavior without leading to the indiscriminate retention of the content processed.
Cost must also be considered across the entire lifecycle. Hardware, cloud services, integrations, maintenance, updates, security checks and oversight all contribute to the overall cost of automation. A local model with a free license can be expensive to maintain, while a cloud service that looks inexpensive can become economically unfavorable as processing volumes grow.
The assessment of the benefit should therefore compare the overall cost of the previous process with that of the modified process, including errors, corrections and control activities. Token consumption or the number of requests processed describes how the infrastructure is working, but does not by itself demonstrate an administrative improvement.
7. From the shared platform to the organization's capability
Once the infrastructure components have been verified, the administration can gradually introduce new capabilities into its information systems, maintaining an authorization and evaluation path proportionate to the nature of the activities.
The existence of the gateway reduces the need to build new integrations with each provider, but does not eliminate the design work on individual processes. Each new function must be associated with an authorized purpose, reliable information sources, execution rules and criteria for measuring the result.
This approach can be particularly interesting for administrations that share IT infrastructure or services. A gateway used by several organizations can enable management savings and a concentration of expertise, provided the architecture guarantees the separation of information, identities and responsibilities of the different entities.
Sharing infrastructure must not be confused with indiscriminately sharing data. Authentication and authorization mechanisms must preserve the context of the requesting administration, preventing a service from accessing resources belonging to another organization without the necessary conditions being met.
For small municipalities, which rarely have staff specialized in managing multiple models and providers, the availability of shared components could be an important condition for introducing AI without multiplying technical burdens.
The sustainability of this evolution will nonetheless depend on the availability of organizational skills, the quality of the interfaces of the management systems and the ability to keep policies up to date. No gateway can on its own make up for the absence of formalized administrative rules or the impossibility of accessing the necessary information in a controlled way.
Conclusions
In my previous article I proposed making public administration information available to digital assistants through official, queryable sources, overcoming the fragmentation produced by the proliferation of institutional chatbots.
Applying the same principle to internal processes means building a common capability for interpretation and automation, usable by the organization's different systems without tying them to a single language model or vendor.
Shared infrastructure is only one part of the solution. To achieve verifiable results, the administration must know its own processes, have interoperable interfaces, define responsibilities and authorizations, govern the flow of information and measure the effects of automation.
The quality of AI adoption in local authorities will depend on the ability to integrate these elements into a coherent architecture, in which technology can evolve without compromising administrative safeguards.
The citizen-facing chatbot remains one possible interface of this ecosystem. The most significant contribution of artificial intelligence, however, may develop inside the offices, where automating repetitive tasks can reduce the work needed to organize information and give time back to the functions that require expertise, judgment and accountability.
Legal and technical references
Regulation (EU) 2024/1689, AI Act and Regulation (EU) 2026/1744, Digital Omnibus.
Regulation (EU) 2016/679, GDPR, with particular reference to Articles 22 and 35.
Law No. 132 of September 23, 2025, Article 14.
AgID, documentation on artificial intelligence in the PA, including Determinations 17/2025 and 43/2026 and the related documents in the adoption process.
European Data Protection Board, Opinion 28/2024.