Prompt Governance in Public Administration

Why governing prompts matters in the public sector

Language models (LLMs) are increasingly used in municipal tasks: case file summaries, drafting reports, citizen service assistance, and regulatory checks. But the practical value of an LLM depends as much on the prompts that feed it as on the model itself. Prompts are the "operational interface" and, without governance, they introduce real risks: leakage of personal data, unreproducible decisions, outputs that don't comply with regulations (ENS, GDPR, EU AI Act), and difficulties auditing or justifying results to internal and external stakeholders.

This article provides a practical —not theoretical— approach to establishing prompt governance in a municipality or public entity.

Specific risks that prompt governance covers

• Exposure of personal data in prompts (GDPR): accidental inclusion of names, case files, or sensitive information.
• Lack of traceability: inability to reconstruct why a model produced a specific result (EU AI Act — logging and documentation obligations).
• Operational variability: changes in prompts or parameters (e.g., temperature) that alter results without control.
• Legal liability and ENS RD 311/2022 compliance: security, traceability, and availability requirements for public services.
• Vendor lock-in without contractual clauses about prompt behavior and access to logs.

Operational principles for governing prompts

• Catalog: identify use cases that use LLMs and their impact on citizens' rights.
• Risk classification: low / medium / high depending on whether the prompt supports decisions affecting rights, access to benefits, or processing of personal data.
• Standardize and version: prompt templates, version control, and formal review before deployment.
• Log and audit: minimum logging per interaction to meet transparency and audit requirements.
• Minimize personal data: design prompts to avoid including identifiable information unless strictly necessary.
• Human-in-the-loop: define human intervention points and escalation criteria.

Technical and compliance checklist (what to record and how)

For each prompt execution, record at a minimum:

• Interaction identifier (UUID) and timestamp.
• Invoking user or system (internal id), role, and justification for use.
• Full prompt (text) and template version.
• Inference parameters: model, version, temperature/top-p, and others.
• External sources consulted (RAG): corpus identifiers and version.
• Model output (text) and hash/identifier.
• Results of automated validations (e.g., PII detection, format checks).
• Human review: reviewer id, decision, and comments.
• Retention and legal basis for keeping the record (linked to GDPR/ENS).

Retention and access policies:

• Apply the principles of ENS RD 311/2022 for protection and access control.
• Define retention periods compatible with administrative obligations and audit requirements; avoid keeping personal data longer than necessary (GDPR).
• Access control and encryption at rest/in transit.

Designing secure and reproducible prompts (practices)

• Parameterized templates: separate instructions (system prompt) from concrete data (slot filling). Example: a fixed instruction for drafting a report + municipal fields populated by the automated system.
• Pre-sanitization: automated filters that detect and anonymize personal data before sending it to the model.
• Minimize historical context: send only the information strictly necessary.
• State explicit usage limits: system prompts that set restrictions (do not generate definitive legal advice, always cite sources, etc.).
• Regression tests: automate tests that compare outputs when prompts or models change.

Roles and organizational governance

• Prompt owner / steward: responsible for each template, its versioning, and its documentation.
• Security/privacy team: assesses GDPR and ENS risks; participates in approving medium/high-risk prompts.
• Technical audit committee: validates logs, reviews incidents, and coordinates internal testing.
• Training: hands-on sessions for staff with examples and counterexamples of unsafe prompts.

Contractual clauses and procurement

When procuring solutions that allow prompts:

• Require access to logs and export capability (for auditing).
• SLA on model version and prior notification of significant changes.
• Portability rights for prompts, templates, and records.
• Guarantees on data processing (GDPR) and ENS measures where applicable.

90-day plan to get started (clear actions)

1. Inventory (days 1–15): list use cases that employ prompts; classify risk.
2. Define critical templates (days 16–30): create and version 5 priority templates.
3. Minimum logging (days 31–45): deploy basic logging according to the checklist.
4. Privacy controls (days 46–60): implement automatic sanitization and retention rules.
5. Approval procedure (days 61–75): establish the prompt owner role and approval workflow.
6. Internal audit and training (days 76–90): test 3 scenarios and deliver team training.

Conclusion and takeaway

Prompt governance is an operational and legal necessity to deploy LLMs in the public sector with security and traceability. Immediate action: start the inventory of use cases and apply the logging checklist within your first 90 days. Implementing these measures helps meet ENS, GDPR, and EU AI Act transparency obligations, and reduces operational risks from the first pilot.

At OptimTech we integrate prompt control and traceability into municipal solutions to facilitate compliance and auditing, but the measures described are applicable regardless of the vendor.