How the cookbook capabilities compose for a high-stakes public-service style AI assistant.
Citizen-facing LLM architecture
What it is
A citizen-facing LLM is an assistant exposed to people outside the organization for questions that may involve rights, obligations, benefits, documents, or public services. It is higher stakes than an internal productivity assistant because misunderstandings can affect real decisions.
Learning goal
Learn to compose model strategy, guardrails, evaluation, red-teaming, audit, privacy, escalation, and handover into one architecture instead of treating them as separate checkboxes.
Why it matters in production
Citizen-facing systems need a stricter operating model. Users may ask ambiguous questions, provide personal data, misunderstand the answer, or treat model text as official guidance. The architecture must make source boundaries, escalation, logging, and responsibility clear.
How I actually build it
The minimum architecture has these layers:
- EU-hosted application and data plane.
- Retrieval over approved source material.
- Model routing with local or EU-hosted options where the privacy boundary requires it.
- Guardrails for topic, instruction injection, personal data, and output tone.
- Evaluation dataset with normal, adversarial, Danish, and English prompts.
- Red-team report before launch.
- Audit log that records source, route, decision, and escalation.
- Human escalation path for uncertain or high-impact cases.
- Handover notes for operators and support staff.
Practice loop
- Choose one public-service scenario.
- Write the user journeys and the "must not answer" cases.
- Define approved sources.
- Decide what must escalate.
- Write the evaluation set before building the assistant.
- Sketch the audit and handover plan.
Proof artifact
A useful proof is an architecture note plus a small prompt dataset and a decision log: what is automated, what is refused, what escalates, what is logged, and who owns the system.
Current status
The architecture page is public as a learning target. The worked example exists as the place where this architecture is assembled and revised as the guardrail, evaluation, and red-team proofs land.
What worked, what didn't
What works is treating governance as part of the build, not as a policy review after the demo. What does not work is presenting a chatbot as the architecture. The chatbot is only the interface.
Next build
Keep the worked example current as each capability proof lands. The first real update should come after the guardrails slice.