Shared AI Service Between Municipalities: Operating Model and Governance

Collaboration between municipalities to provide common AI services is a practical response to the lack of technical and legal resources in small and medium-sized administrations. However, sharing an AI service is not just a technical matter: it requires a clear design for governance, contracting, security and responsibilities. This post presents an actionable operating model and a practical checklist to launch a shared service, with key regulatory references (ENS RD 311/2022, Law 9/2017, Law 38/2003, GDPR, EU AI Act).

Why a shared service?

• Lowers unit costs and avoids duplicated development efforts.
• Makes it possible to build specialized teams (DevOps, compliance, security).
• Enables a single audited and maintained version of the model/service. But it requires explicit agreements on data, legal responsibilities, costs and exit strategies.

Operating model: roles and responsibilities

• Host partner (technical operator): hosts and runs the service (infrastructure, deployments, backups, patches).
• Inter-municipal governance committee: decides on the roadmap, access criteria and feature prioritization.
• Joint data controller (under the GDPR) or separate data controllers: define who is responsible for processing and to what extent.
• Compliance and security team (ENS): handles audits, controls and incident reporting.
• Support and training: user support for municipal staff and change management.

Action: formalize these roles in a framework agreement with signatures and minutes that document functions and limits of responsibility.

Contracting and legal frameworks

• Choose the appropriate legal instrument: collaboration agreement, consortium, delegated management, or provision of services via a public contract under Law 9/2017.
• If there is external funding or grants, review the constraints of Law 38/2003.
• Include specific clauses:
  • Ownership and title of models and artifacts.
  • Audit rights and access to records (logs, decision traceability).
  • SLAs, KPIs and quality metrics.
  • Exit plans and portability of data and models.
• Align tender specifications and contracts with the EU AI Act requirements for high-risk systems (if applicable) and with ENS RD 311/2022 controls.

Action: prepare a standard contractual annex with clauses on interoperability, portability and audit rights.

Data protection and shared data models

• Define the categories of data that may be uploaded to the service (personal data, special categories, anonymized data).
• Establish legal bases for processing (Art. 6 GDPR) and mechanisms for exercising rights.
• Implement minimization and access governance: roles and authorizations by municipality.
• Legal status of anonymization: document processes and tests (to demonstrate that data are no longer personal).
• Consider collaborative models that avoid moving sensitive data (federation, API queries, processing at the data perimeter).

Action: create a joint record of processing activities and a protocol for responding to GDPR requests.

Security and ENS (RD 311/2022)

• The provider/operator must comply with ENS if they deliver services to public bodies: classify information and define technical and organizational measures.
• Minimum requirements: access control, encryption in transit and at rest, identity management, incident monitoring.
• Include regular testing (pentesting) and a procedure for notifying incidents to the competent authorities and affected entities.

Action: include a Security Plan and an annual ENS compliance report as deliverables from the provider/operator.

Technical architecture and data sovereignty

• Prefer a modular architecture: municipal front-end, orchestration layer and a centrally managed model layer.
• Hosting and sovereignty: decide whether to host in a public cloud, private cloud or municipal data center; document compliance with sovereignty and continuity requirements.
• Versioning and model catalog (model cards): for each model document training data, usage limits and performance metrics.
• Deployment strategy: staging and test environments, canary releases and automatic rollback.

Action: define an initial catalog of APIs and models with their model cards and a version repository.

Operation, SLAs and financing

• Clear SLAs: availability, response times, incident resolution times, maintenance windows.
• Financing and cost-sharing: fixed fee + pay-per-use; define an annual adjustment mechanism and budget governance.
• Operational KPIs: availability, latency, false positive/negative rates (depending on the service), municipal user satisfaction.

Action: agree on a quarterly KPI review cycle and the cost-sharing formula.

Risk management and exit

• Contingency plan: degraded services, failures, and a data recovery plan.
• Exit strategy: exportability of data and models in open formats, transfer to another entity or operator.
• Liability insurance and indemnity clauses in contracts.

Action: include an "exit kit" with data exporters, instructions to rebuild the environment and an inventory.

Pilot and scaling

• Start with a limited pilot (2–3 municipalities, 6 months): validate data flows, SLAs and governance.
• Document lessons learned, adjust contracts and then scale by functional modules.
• Use user acceptance testing (UAT) with real cases and failure scenarios.

Action: design a pilot with SMART objectives, test cases and acceptance criteria.

Conclusion — takeaway

For a shared AI service between municipalities to succeed you need more than technology: a robust legal agreement, clear governance rules, ENS and GDPR compliance, and an architecture that enables portability and control. Start by formalizing roles, defining the scope of data and launching a short pilot with 2–3 municipalities. If you want a validated modular approach for governance and operations, consider platforms designed for the public sector (for example, OptimGov) and adapt contracts and controls to your local context.

Immediate recommended action: convene a 4-hour meeting with technicians, lawyers and municipal stakeholders to approve the role scheme and a 6-month pilot plan.