Federated Learning Between Municipalities: Collaborating on AI Without Moving Personal Data

Why consider federated learning in local government

Municipalities often hold valuable data (land registry, procurement, incident reports, grants) that, when combined, can improve predictive models and anomaly detection. However, transferring personal data between public entities creates legal and technical risks: GDPR obligations, ENS requirements (RD 311/2022) and political resistance.

Federated learning lets you train joint models without centralizing data: each entity trains locally and only shares model updates. If designed with appropriate controls, it’s an option that balances collaboration and privacy.

Below is a practical approach: when to use it, essential legal and technical requirements, and operational steps for a safe pilot.

When to choose federated learning

Consider federated learning when:

• The model’s value clearly increases with data distributed across several entities (e.g., fraud detection in grants, identifying cadastral anomalies).
• The main constraint is legal or political about transferring personal data outside each organization.
• Data sources are relatively homogeneous (same schemas or easily mappable).
• There is no urgent need for very low-latency centralized inference.

It’s not recommended if:

• The data is extremely heterogeneous and a practical common schema can’t be standardized.
• The operational cost of maintaining local nodes outweighs the benefits (ENS infrastructure, staffing).

Legal and governance requirements (practical)

1. Assessment of processing and legal basis

   • Determine the legal basis under the GDPR (Art. 6). In many public-sector cases this will be performance of a task carried out in the public interest or compliance with a legal obligation.
   • Clarify whether entities act as joint controllers or if one acts as a processor. Formalize arrangements with agreements (collaboration agreements, responsibility and processing contracts).

2. DPIA (Data Protection Impact Assessment)

   • Carry out a DPIA before the pilot if the processing could pose a high risk to individuals’ rights and freedoms (for example, automated decisions with legal effects).
   • Document technical and organizational measures to mitigate risks (pseudonymization, encryption, access control).

3. ENS and security

   • Align the architecture with RD 311/2022: asset classification, access control measures, encryption in transit and at rest according to the required security level.
   • Ensure audit logs and incident response procedures.

4. Transparency and rights

   • Update privacy notices and mechanisms for managing data subject rights (access, rectification, cancellation, objection / right to be forgotten) where applicable.
   • If the model affects individual decisions, establish protocols for human oversight and explanations.

Essential technical controls

• Encrypted communications: TLS for traffic between nodes and the orchestration server.
• Secure aggregation: prevent the coordinator from reconstructing individual updates; use secure aggregation to sum gradients.
• Pseudonymization and minimization: keep data locally pseudonymized and limit processed attributes.
• Differential privacy: add calibrated noise to updates when re-identification risk is relevant.
• Validation and version control: each update should pass automated tests (sanity checks) before being incorporated into the global model.
• Monitoring and fairness metrics: log performance by data source to detect bias or localized degradation.
• Traceability logs: keep records of who trained what, when and with which configuration (compatible with transparency requirements).

Operational steps for a municipal pilot (30–90 days)

1. Define a narrow use case
   • Example: a classifier to flag anomalies in grant files (non-binding decisions).
2. Inventory and normalize data
   • Map fields and data quality across municipalities; agree on a minimum viable schema.
3. Test with synthetic data
   • Validate the pipeline with synthetic datasets to avoid exposing real data in early phases.
4. Agree on the legal framework and DPIA
   • Sign the collaboration agreement and complete the DPIA with identified technical measures.
5. Deploy local nodes and the orchestrator
   • Deploy nodes in ENS-compliant environments or in a local data center; use secure aggregation.
6. Run training rounds and validation
   • Define metrics, checkpoints and stopping criteria.
7. External audit and deployment plan
   • Review results, residual risks and prepare a plan for production or project closure.

Risks and how to mitigate them

• Local overfitting or heterogeneity: apply reweighting techniques and validate with shared holdout datasets (synthetic or cleaned).
• Leakage of information through model updates: use differential privacy and secure aggregation.
• Operational complexity and ENS costs: start with minimal nodes and a short pilot window to validate value before scaling.

Practical example (brief) — realistic and data-free

A group of five municipalities wants to improve detection of files with recurring errors that delay payments. Instead of sharing files, each municipality trains a local classifier to identify risk signals. A coordinator aggregates updates with secure aggregation and returns the global model. After three rounds, the global model improves identification of problematic files across all nodes without any personal data leaving the municipal offices.

OptimGov can be integrated into federated architectures as a modular orchestrator, reducing engineering effort needed for the pilot.

Immediate actions (takeaway)

• Carry out a DPIA for the pilot idea and sign a collaboration agreement between entities.
• Start with a narrow use case and synthetic data to validate the pipeline.
• Apply secure aggregation and, if appropriate, differential privacy; ensure ENS compliance (RD 311/2022) for local nodes.
• Define shared metrics and a governance plan: technical committee, data stewards and an audit procedure.

With these steps, municipalities can leverage collective knowledge without transferring sensitive data, while maintaining legal compliance and operational security.