Citizen services chatbot (public administration)

Citizens struggle to find the right office, form or deadline among thousands of administrative pages, and call centres and front desks are overloaded with routine questions. A retrieval-grounded assistant answers in the citizen's language 24/7, cites the official source, links to the online service and hands over to staff for anything individual. The decisive design rule: it informs and guides, it does not decide cases.

Problem & value

• Today: information is spread over websites, PDFs and service portals written in administrative language. Citizens phone or visit for simple questions (opening hours, required documents, fees, responsible office), and staff answer the same questions repeatedly. Search boxes on authority sites perform poorly on natural-language questions.
• AI value: natural-language access to the service catalogue, answers in many languages and plain language, availability outside office hours, relief for service centres, and analytics on what citizens actually ask (content gaps, unclear forms).
• Reported evidence: the UK GOV.UK Chat pilots (more than 10,000 participants, about 26,000 questions) report accuracy rising from 76% to 90% against published guidance, with partial answers as the main remaining error; 73% of surveyed app users found it useful and 64% were satisfied [1][2]. German municipalities report launches such as Kreis Barnim (March 2026, 100 languages and Leichte Sprache, individual case assessment explicitly left to staff) and shared municipal services in Saarland; these are mostly press or vendor statements, with no independent outcome studies seen [3][4].
• Policy driver: the EU Single Digital Gateway and national digitisation laws (e.g. Germany's OZG) require findable, understandable online administrative services; a conversational front door complements them [5].

Variants

• Municipal website assistant (services, waste, registration, events) - most common.
• Agency-specific assistant (tax, social insurance, employment, immigration) - deeper procedures, closer to case data, higher risk.
• Voice front-end for out-of-hours calls (CONV-002); Märkischer Kreis reported one [6].
• Internal caseworker assistant over the same knowledge base (KNOW-002) - lower risk, often the better first step.
• Private use: not applicable; general assistants are not authoritative for local rules.

How it works

1. citizen question (web/app/voice)
2. AI disclosure + language detection + input guardrails (PII masking, prompt-injection, off-topic)
3. intent routing (information | appointment | status | complaint | emergency/crisis | human)
4. retrieval over curated administrative knowledge (hybrid search + reranker, per-municipality scope)
5. answer generation with citations, "as of" date, fixed refusal when no source is found
6. output checks (grounding, no legal advice on individual cases, tone, language level)
7. action: deep link / appointment API / hand-over to staff with summary
8. logging, feedback, content-gap report to editors

• Knowledge base: the quality of answers depends on maintained, canonical sources: service catalogue entries, official web pages, fee schedules. Content is versioned, with a named owner per topic and an expiry date. Chunks carry metadata (authority, validity area, last review).
• Retrieval-first design: the model must answer only from retrieved passages; anything else is declined with a pointer to the responsible office. Multi-tenant setups scope retrieval per municipality so that answers do not leak across jurisdictions.
• Tool use: read-only actions by default (appointment slots, office locations, opening hours). Writing actions (booking, submitting a form) need explicit user confirmation. Case-status look-ups require strong authentication (eID or BundID/service account) and are the point where GDPR and risk grow sharply.
• Human-in-the-loop: visible escape to a human at all times; escalation on low retrieval confidence, negative feedback, vulnerable-user signals or topics on a block list (asylum decisions, benefit denials, legal remedies); editors review unanswered-question logs weekly.

Data preparation

The chatbot is only as good as the content behind it: service descriptions, forms, fee schedules, opening hours, local statutes and FAQs. In an authority this lives in the CMS or portal, the Leistungskatalog (e.g. LeiKa), intranet and wiki pages, PDFs on file shares, and in the heads of caseworkers. Typical gaps: outdated or contradictory pages, scanned PDFs, bureaucratic language, duplicated content across departments, no owner per page and missing easy-language versions.

Preparation steps: (1) inventory content sources and name an owner per topic (PREP-004, GUIDE-003); (2) curate one authoritative knowledge base and remove duplicates (PREP-013); (3) restructure and tag documents (PREP-009, PREP-010); (4) rewrite key pages in plain language (PREP-014) and add a synonym list for citizen vocabulary (PREP-015); (5) collect real citizen questions into a test set (PREP-018); (6) set a review cycle and feedback loop (PREP-017, PREP-021). OCR scanned PDFs (PREP-006, DOC-014). Tools: CMS exports, Paperless-ngx or OCR pipelines, Qdrant or pgvector for indexing. Data work is the largest share, often 50 % or more, and content upkeep continues after go-live.

Implementation paths

Which path for whom

• Public: Path B on a sovereign EU or German cloud (or via a regional IT service centre), because procurement rules and sovereignty favour controlled hosting while answers must be built on the authority's own verified content; buy (Path A) only certified, EU-hosted products.
• Enterprise: Path A, because municipal utilities and similar companies use a commodity customer-service function that mature EU vendors cover.
• Developer: Path C, because integrators serving many authorities can share one open-source platform across customers (Baukasten effect).

Path A - Buy

• DACH/EU public-sector vendors: e.g. Bürger-Chat, frag.kim, convaise, entrecode, plus portal/CMS vendors; regional IT service centres such as eGo-Saar procure jointly. Also Parloa and Cognigy (German, voice and chat), Rasa (on-prem option), Microsoft Copilot Studio for Microsoft-standardised authorities.
• Check: EU hosting, no training on citizen inputs, citations, easy language, accessibility (BITV/EN 301 549), exit clauses; use sample tender specifications [7].

Path B - Build on cloud APIs

• Models: Mistral (EU provider), other EU-hosted offerings, or frontier APIs (Claude, Gemini, GPT) in EU regions with acceptable contracts.
• Retrieval: Azure AI Search/OpenSearch/Elastic or Qdrant (EU); multilingual embeddings (BGE-M3, multilingual-e5) plus reranker. Orchestration with LangGraph or Haystack (deepset, EU); guardrails via NeMo Guardrails and Presidio; golden-set evaluation.

Path C - Self-host (open source)

• Models: Mistral Small, Qwen3, Llama, Gemma via vLLM/Ollama; Qdrant or pgvector; Open WebUI; Whisper and Piper for voice.
• Hardware: HW3 for 30-70B models with many users; HW2 suffices for small municipalities. A regional IT service centre sharing one cluster is the realistic model.

Path D - Custom training

Rarely justified. Tune an intent classifier or embedding model once thousands of anonymised citizen questions exist; retrieval quality and content upkeep matter more.

State of the art (2026)

• RAG with citations and refusals is standard. GOV.UK reports 90% accuracy and 508 of 508 jailbreak attempts blocked, but also about 10.7 s average latency and persistent partial answers [1][2].
• Multilingual and easy-language output is feasible, but smaller languages and Leichte Sprache need testing with native speakers.
• Agentic features (booking, form pre-filling, status checks) emerge behind authentication and confirmation steps; voice agents work out-of-hours but misrecognise names and addresses.
• Failure modes: outdated or contradictory pages yield confident wrong answers; omitted exceptions or deadlines; confusion between neighbouring municipalities; over-trust; prompt injection via indexed content.

Shared resources & combinations

• Same stack as CONV-001 (customer service chatbot), KNOW-002 (RAG over documents) and KNOW-011 (knowledge-base maintenance): one retrieval platform, one guardrail layer, one evaluation harness.
• Combines with: CONV-003 (appointment booking), CONV-002 (voice front-end), LANG-009 and SPEECH-003 (translation and interpreting), LANG-010 (plain language), DOC-016 (document-based rule checks, e.g. building permits) for back-office support.
• Boundary: assessing eligibility or fraud risk for benefits is not this use case; see ANOM-019 and the high-risk safeguards there. Emergency call handling is CONV-021.

Effort, cost & KPIs

• Effort: A weeks to months; B 3-6 months; C 4-9 months. Largest cost driver is knowledge-base curation, then portal integration and evaluation.
• KPIs: expert-rated accuracy on a golden set, resolution without human contact, escalation rate, unanswered-question rate, satisfaction, call/counter volume on covered topics, citation validity, time to fix content gaps.

People & change

Involve the mayor or head of administration for the decision, then department heads whose services the bot answers, IT and information security for hosting and the BSI baseline, and the data protection officer. Caseworkers are key: they supply and approve content and receive escalated cases. Works council: depends. The chatbot itself serves citizens, but usage logs, escalation statistics or handling-time metrics may be suited to monitor staff, which triggers the staff council (Personalrat) under BPersVG or the state law; the private-sector equivalent is §87(1) no. 6 BetrVG, plus information duties under §90(1) no. 3 and an AI expert under §80(3). Agree up front that data is not used for individual performance assessment.

Data protection: citizen inputs can contain personal data, so a DPIA (Art. 35 GDPR) is advisable, with an AVV (Art. 28 GDPR) for every processor and no training on inputs. Transparency under Art. 50 AI Act applies since 2 August 2026, so label the bot clearly. AI literacy: under Art. 4, take measures to support staff literacy, especially for editors and caseworkers. Pilot with two or three high-volume services, always offer a human contact, and address staff worries about job loss by stressing relief from repetitive questions. See GUIDE-008, GUIDE-004 and GUIDE-010.

Risks, regulation & compliance

• EU AI Act: typically limited risk. Art. 50 requires telling people they interact with AI; it applied from 2 August 2026 and the Digital Omnibus did not postpone it (it delayed mainly high-risk duties, Annex III to 2 December 2027) [8][9]; verify against the Official Journal. High-risk if used to assess eligibility for essential public benefits or for migration/asylum decisions (Annex III) - keep the bot on the information side. Art. 5: no social scoring and no manipulation of vulnerable people. AI literacy (Art. 4) applies to staff.
• GDPR: legal basis usually Art. 6(1)(e); DPIA where authentication or case data is involved; mask PII, limit retention, processor contracts, no training on citizen inputs. Art. 22 limits automated decisions.
• Administrative law and accessibility: answers are non-binding information with source dates; widget must meet EN 301 549/BITV and a non-AI channel stays available.
• Mitigations: retrieval-only answers with refusal, golden-set regression tests per content release, guardrails, no write access without authentication.

Getting started

1. Pick 20-50 high-volume topics from call and search logs; assign content owners and clean the pages.
2. Write a golden set of 200+ real questions with approved answers before choosing a tool.
3. Pilot via Path A or a shared platform with citations, refusals, AI disclosure and human hand-over.
4. Test with staff and citizens (easy language, non-German users); finish DPIA and accessibility check.
5. Go live with weekly review of unanswered questions; add appointments once accuracy is stable.

Sources

1. GOV.UK Chat completes public pilot - https://www.ukauthority.com/articles/gov-uk-ai-chat-completes-public-pilot
2. Civil Service World, GOV.UK AI chatbot achieves 90% accuracy - https://www.civilserviceworld.com/professions/article/govuk-ai-chatbot-achieves-90-accuracy
3. Behörden Spiegel, KI-Chatbot für saarländische Kommunen (2025-11-03) - https://www.behoerden-spiegel.de/2025/11/03/ki-chatbot-fuer-saarlaendische-kommunen/
4. Kommune21, Chatbot hilft durch Verwaltungsdschungel - https://www.kommune21.de/k21-meldungen/chatbot-hilft-durch-verwaltungsdschungel/
5. European Commission, Single Digital Gateway - https://single-market-economy.ec.europa.eu/single-market/single-digital-gateway_en
6. Meerbusch, "Meerlin" KI-Chatbot im Bürgerservice - https://meerbusch.de/aktuelles/nachrichten/details/meerlin-neuer-ki-chatbot-verbessert-den-buergerservice-der-stadtverwaltung
7. Muster-LV KI-Assistent für den Bürgerservice (vendor-neutral sample tender, IT-Leistungsverzeichnisse) - https://it-leistungsverzeichnisse.de/produkte/muster-leistungsverzeichnisse/lv-ki-assistent-buergerservice
8. Jones Walker, EU approved a high-risk AI delay, but most transparency obligations remain - https://www.joneswalker.com/en/insights/blogs/ai-law-blog/yes-august-2-still-matters-the-eu-approved-a-high-risk-ai-delay-but-most-trans.html
9. Regulation (EU) 2024/1689 (AI Act), Art. 5, 50, Annex III - https://eur-lex.europa.eu/eli/reg/2024/1689/oj