Digital twins of citizen demand: using synthetic agents to test municipal services

Why use synthetic agents to test municipal services

Municipalities must ensure continuity and quality in services that face unpredictable surges: call centers, requests intake, permit processing, emergencies. Testing these systems with real users is expensive, hard to control and poses privacy risks. Demand digital twins — sets of "synthetic agents" that mimic citizen behavior — allow you to:

• Recreate scenarios (spikes, partial failures, regulatory changes) without exposing personal data.
• Validate integrations, queues, SLAs and breaking points in preproduction environments.
• Train operational procedures and coordinate staff before real incidents occur.

Below I outline a practical approach, compliant with the GDPR, ENS (RD 311/2022) and the obligations of the AI Act where applicable.

Practical design: steps for a useful simulation

1) Define objectives and KPIs

Before generating agents, clarify what you want to measure. Example objectives and KPIs:

• Objective: verify call center capacity during a wave of incidents. KPIs: average wait time, % of calls answered in <60s, abandonment rate.
• Objective: test the online application queue after a campaign. KPIs: form error rate, time to resolution, rate of required corrections.

2) Choose source data and ensure compliance

Use aggregated patterns or anonymized histories to build demand profiles. Rules to follow:

• Avoid using personal data: apply anonymization techniques or generate 100% synthetic data from aggregated distributions.
• Document the technique used for anonymization or synthetic generation (for example, generative models or statistical rules).
• Apply ENS controls (RD 311/2022) to the environment where the simulation runs: separate environments, access controls, logging and encryption.

3) Build the synthetic agents

Each agent should be a profile with attributes relevant to the service (preferred channel, complexity of the procedure, active hours). Recommendations:

• Base profiles on real distributions (schedules, types of procedure, probability of error).
• Introduce variability: human delays, form mistakes, retries and abandonment.
• Include "adversarial" agents that simulate atypical inputs (badly formatted files, mass requests) to test robustness.

4) Model demand arrival

To make the simulation realistic:

• Use stochastic processes (Poisson for independent arrivals, non-homogeneous processes for predictable peaks).
• Integrate external events (for example, publishing a call for applications that generates a spike) for stress testing.

5) Run in test environments and measure

Connect agents to preproduction services or to mocks that replicate production behavior. Monitor:

• Technical metrics (CPU, latency, errors).
• Process metrics (queues, wait times, rejection rates).
• Decision metrics (if AI makes decisions, log inputs/outputs for traceability and auditability).

6) Analyze, prioritize and act

After the simulation:

• Compare results against acceptable KPIs.
• Identify bottlenecks and propose countermeasures (horizontal scaling, queue optimization, process changes).
• Repeat the simulation after applying improvements.

Regulatory and governance considerations

• GDPR: do not use personal data of real citizens unless there is a clear legal basis and minimization measures. Prefer synthetic or aggregated data.
• ENS (RD 311/2022): the environment where tests run must meet security controls appropriate to the protection level of the systems under test.
• EU AI Act: if the simulation includes AI models that influence administrative decisions or risk management, determine whether the use is high-risk and apply transparency, documentation and risk assessment requirements in accordance with the Act.
• Documentation: keep a record of the simulation design, data sources, synthetic generation techniques and results — this supports audits and improves reproducibility.

Quick practical examples

• Call center: generate 10,000 agents over a 3-hour window with a mix of 70% informational calls, 20% technical incidents, 10% complaints; measure abandonment and IVR saturation.
• License applications: create 2,000 profiles with varying levels of attached documentation (0–4 files), including some corrupted uploads to test validations and correction rates.
• Emergencies: simulate geo-localized spikes to test resource routing and unit arrival times.

Recommended tools and techniques

• Load generators (locust, k6) for APIs and web forms.
• Scenario repositories (YAML/JSON) versioned in Git for reproducibility.
• Observability: distributed traces, centralized metrics and logs; build dashboards with the KPIs.
• Integration with canary deployments to validate fixes that mitigate issues.

Quick checklist before running a simulation

• Objectives and KPIs defined.
• Data sources validated and free of personal data.
• Test environment complies with ENS and security controls.
• Scenario and profiles documented.
• Monitoring and traceability configured.
• Action plan for negative results.

Call to action (1 clear step)

In the next 90 days: identify a critical service (call center, registry or a specific processing workflow), extract aggregated patterns from historical demand, and run a controlled peak simulation in preproduction. Document the results and plan corrective measures. This exercise will provide operational evidence to prioritize investments and improve resilience without risking citizen data.

OptimGov Ready can provide scenario templates and governance controls adapted to municipalities; use these resources as a reference, but design simulations with the technical and legal controls described to ensure compliance and operational usefulness.