Practical Explainability of AI Systems for Municipal Staff

The demand for explainability is not an academic wish: it's an operational and legal requirement when AI supports administrative decisions. The EU AI Act imposes obligations for transparency and documentation for risky systems, the GDPR conditions automated processes that affect people’s rights, and the ENS (Royal Decree 311/2022) requires security and traceability measures in public administration systems. Here we explain how to turn those requirements into practical explanations that municipal teams and citizens can actually use.

Who is the explanation for and why?

Before designing explanations, define audiences and objectives. At minimum distinguish three profiles:

• Citizens: need clear, brief answers focused on appeal/follow-up.
• Technical/operational staff (managers, controllers): need details on variables, model versions and limits.
• Audit/legal: require full traceability: input data, transformations, model version, logs.

Designing for everyone at once creates noise. Use stratified explanations (see next).

Operational pattern: stratified explanations (3 levels)

Applicable to grant files, bid evaluations, urban proposals, etc.

1. Level 1 — Citizen summary (1–2 sentences)

   • What decision the AI helped make and the outcome.
   • Main reason in non-technical language.
   • Indication of remedies to appeal or request review.

   Example: "Proposal A ranked second with a technical score of 82/100. Key factors: team experience and price. If you want more information or wish to file an appeal, you may do so within 15 days."

2. Level 2 — Operational justification (for managers)

   • Most relevant variables (top 3–5) with their relative contribution.
   • Applied thresholds and model version.
   • Short note on uncertainty (e.g., confidence intervals or cases where the model shows low certainty).

   Example: "Total score 82/100. Contributions: experience 40%, technical solution 30%, price 20%, administrative compliance 10%. Model v1.3 (trained on 2018–2025 data). High uncertainty for proposals with atypical formats."

3. Level 3 — Audit record (for audit and legal)

   • Exact input data (hashes/IDs or non-personal extract), applied transformations, model version, seed/environments, parameters, date/time, human operator.
   • Technical rationale: explanation method used (SHAP, LIME, extracted rules) and known limitations.

   Example: "Input ID 2026-0456; normalized variables: price_z, experience_years; transformations: median imputation; explanation generated with SHAP v0.42. Logs stored in repository X."

Methods and when to choose them

Not every method suits every audience.

• Rule-based / linear models: easy to explain quantitatively (coefficients). Useful when the logic must be transparent from the start (e.g., award criteria).
• Local explainers (SHAP/LIME): suitable to explain individual decisions in complex models; require Level 2–3 detail.
• Simple counterfactuals: show minimal changes that would lead to a different result (useful for citizens seeking an appeal or improvement).
• Narrative templates: combine the above elements in natural language for Level 1.

Choose the method based on risk, legal requirements and operational capacity.

Practical templates (ready-to-use text)

• Citizen (rejection/denial): "Your application has been denied. Main reason: [brief reason]. If you believe this is an error, you may file an appeal within [timeframe] providing [documents]. To request a technical explanation, contact [contact]."
• Manager (internal evaluation): "Result: [score]. Key factors: [X: +Y pts], [Z: -W pts]. Model: [id, version]. Notes: [uncertainty/missing inputs]."
• Audit (record): "Case ID, inputs (hash), transformations, model (hash), explanation (method + output), user who validated, timestamp."

Embed these templates in the UI/case file and in tender documents when outsourcing AI.

Practical integration and testing

• Test with real users: validate that Level 1 is understandable with usability tests (5–8 users).
• Define disclosure limits: for security or privacy, decide which technical details will not be published but will remain in the audit record.
• Automate explanation generation but require human review for sensitive decisions (EU AI Act: high-risk systems require mitigation measures and human oversight).
• Include contract clauses requiring provider support to generate logs and explain results (explainability SLA).

Quick checklist for municipal teams

• Classify the system under the EU AI Act (is it high-risk?).
• Design explanations by audience (3 levels).
• Select an appropriate explanation method.
• Prepare citizen and operational templates.
• Implement logs with traceability in line with ENS and GDPR.
• Test with users and document results in the case file.

Conclusion and recommended action

Make a concrete decision this week: pick a pilot process (e.g., grant evaluation or scoring of applications) and define the three explanations (citizen, manager, auditor) using the templates above. Document the explanation method in the tender or in the AI governance roadmap (OptimGov can integrate it into its assessment), and schedule a validation session with at least five officials and three end users. That minimum test will provide the practical evidence to meet transparency requirements, reduce appeals, and satisfy legal obligations.

Takeaway: explainability is not just technical; it's communication design. Designing three levels of explanation, with templates and traceability, enables compliance with the EU AI Act, GDPR and ENS without paralyzing operations.