The Kraków-Krowodrza Municipality Office launches a chatbot for resident services. After six weeks, it handles 300-400 queries daily, reduces first-contact time from 48 to 4 hours, and relieves staff of routine questions about registration procedures, waste collection schedules, and application deadlines. No administrative decision is made by the model. This is a realistic scenario, not a promise, because the boundary between informational assistance and administrative decision is strict and cannot be crossed without breaking the law.
Below, I describe where this boundary lies, what requirements the AI Act and GDPR impose on local government units, and how to build an architecture that is compliant, transparent, and maintainable by a typical office without dozens of IT specialists.
What AI can do in a government office: three safe applications
#The public sector has limited room for maneuver, but it is not useless. Three categories of applications are technically feasible and legally safe with the right architecture.
Information from a knowledge base. A RAG agent indexed on official documents (regulations, Public Information Bulletin, form templates, FAQs, schedules) answers residents' questions in natural language with source citations. The model does not generate content from imagination but searches and paraphrases publicly available documents. With appropriate guardrails, the system refuses to answer questions outside the documentation scope and escalates to a staff member. Example questions: "What documents do I need for registration?", "When can I submit applications for the 500+ benefit?", "Where can I report uncollected waste?"
Case routing. A classifier determines the correct department and urgency based on the case description. A resident describes the matter in a single form, and the system assigns it to the technical, financial, social, or legal department without staff involvement in the first step. This is structured output with a tight schema: {department: enum, urgency: 1-3, category: string, requires_verification: bool}. The final routing decision is made by a human; AI only suggests.
Prefilling applications. Based on session data (e.g., address from a previous interaction) or information provided by the resident, the system prefills form fields. The resident verifies each field and approves before submission. The model does not submit the application for the resident: it helps prepare it. This is a typical agent tool-use with a fill_field action, without a submit_form action without human confirmation.
What AI cannot do: the hard boundary of administrative decisions
#An administrative decision under Article 104 of the Administrative Procedure Code is a unilateral resolution by an authority that shapes the rights or obligations of a party. Permits, refusals, orders, prohibitions, fee impositions. None of these actions can result from an autonomous AI system decision, even if technically possible.
There are two reasons. Legal: the Administrative Procedure Code requires that the decision be signed by an authorized employee or authority who bears legal responsibility. AI is not a legal entity. Ethical and regulatory: the AI Act, in Annex III, points 1 and 5, classifies AI systems used for decisions on access to public services, social benefits, and legal risk assessment as high-risk. For such systems, the requirements are strict: technical documentation, audit logs, human-oversight as an operational condition, and explainability upon request.
Practical examples of the boundary:
- A chatbot can say, "To apply for a benefit, you need documents X, Y, Z." It cannot say, "Your application is rejected."
- A routing agent can suggest a department. The employee decides whether the case goes to that department.
- A prefill system can enter a PESEL from session data. The resident verifies and approves before submission.
AI Act requirements for the public sector in 2026
#The AI Act treats the public sector with heightened vigilance. Public administration bodies using AI systems in areas listed in Annex III have the status of high-risk system deployers with a full set of obligations.
Key deployer obligations for local government units:
AI systems register. Every high-risk system must be entered into a register maintained by the authority. For systems used with residents, this includes, among others, application assessment systems, service access scoring, and public space monitoring.
Technical documentation. The deployer must possess the system's technical documentation provided by the supplier. In public procurement, it is worth requiring suppliers to provide AI Act-compliant documentation (Article 11 and Annex IV) already at the tender specification stage.
Human oversight. Article 26(1) of the AI Act: the deployer implements "appropriate technical and organizational measures" to ensure that designated oversight personnel have the ability to intervene, understand the system's limitations, and can stop it.
Transparency toward individuals. Article 50 of the AI Act: if an AI system interacts with individuals (e.g., a resident service chatbot), it must disclose that it is an AI system. Failure to disclose is a violation regardless of whether the system makes decisions or only provides information.
Details on classification and obligations are described in the article on AI Act and GDPR 2026 for businesses and high-risk systems.
Citizen data and GDPR: what a government office must do before launch
#Processing personal data with an AI system in a government office requires several steps that must precede production deployment.
Legal basis for processing. For local government units, the basis is most often Article 6(1)(e) of GDPR (task carried out in the public interest or in the exercise of official authority). Important: the basis must correspond to the specific purpose. A chatbot collecting information about a resident's case to classify it falls within this scope. Profiling residents for other purposes may not.
Data processing agreement. If the AI system is provided by an external supplier (SaaS or on-premise with an external model), the office, as the data controller, must sign a data processing agreement compliant with Article 28 of GDPR with the supplier. Launching the system without this agreement is a GDPR violation.
DPIA. A Data Protection Impact Assessment is mandatory when processing may result in high risk. In practice, for local government units: systems assessing benefit applications, chatbots collecting residents' personal data (even in descriptive form), monitoring systems with image analysis, and systems processing sensitive data (health, disability, social status). The Polish Data Protection Authority recommends a proactive approach: if in doubt, conduct a DPIA. The cost of preparing a DPIA for a simple system is a few days' work; the cost of a GDPR violation is many times higher.
PII masking. Residents' personal data should not be sent to an external model in plain text. Architecture: a PII masking module before sending the query to the model, with unmasking when displaying the response to the user. With self-hosting of a local model (data-residency in the office's infrastructure), the problem is smaller but still requires log management.
Information on processing (Articles 13/14 GDPR). A resident interacting with an AI chatbot must be informed about the processing of personal data: controller, purpose, legal basis, rights. This requirement overlaps with the AI Act's transparency requirement (disclosing that it is an AI system).
Table: task vs. permitted vs. requirement
#| AI Task | Permitted | Key Requirement |
|---|---|---|
| Answering a question about a procedure from the Public Information Bulletin | Yes | Disclosure that it is AI (AI Act Article 50); query logs without PII |
| Routing a case to a department | Yes, as a suggestion | Human gate before transfer; system register if Annex III area |
| Prefilling an application | Yes, with resident confirmation | Resident approves each field; no automatic submission |
| Assessing application completeness | Yes, as a list of missing items | Employee decides on a request for supplementation |
| Issuing an administrative decision | No | Decision requires the signature of an authorized employee (Administrative Procedure Code Article 104) |
| Scoring residents for benefits | No without human gate | High-risk system under AI Act Annex III; DPIA mandatory; human-oversight |
| AI monitoring of public spaces | Limited (ban on real-time biometrics under Article 5) | Ban on biometric identification in public spaces in real-time |
Deployment architecture: from pilot to production
#Local government units rarely have their own AI teams. Deployment through an external integrator while maintaining the office's data sovereignty is possible but requires appropriate clauses in the contract.
Pilot in shadow mode. For the first 4-8 weeks, the AI system operates in parallel with the current process: it answers queries, but a staff member verifies each response before it reaches the resident. You collect data on quality (what the model gets wrong, which questions exceed its scope) without operational risk.
Knowledge base scope. RAG on public documents (Public Information Bulletin, regulations, form templates) is safe. Indexing residents' personal data (case history, registry data) requires legal analysis and is only an option for the office's own infrastructure with an appropriate legal basis.
Public guardrails. A government chatbot should have built-in limitations: refusal to answer questions outside the office's scope, refusal to provide other people's personal data, blocking questions attempting to extract data from the system, and a mandatory closing sentence in each response informing about the possibility of contacting a staff member. The guardrails pattern is described in the article on AI governance in business.
Monitoring and reporting. Log: number of queries, escalation rate to staff, query topics (without PII), resident quality ratings. For high-risk systems, the AI Act requires audit logs to be stored for a period sufficient to demonstrate compliance. In practice: 24 months for administrative systems. Deployment planning tools: agent blueprint and ROI calculator.
Try it live
#Describe your deployment or planned AI project in a local government unit, and the model will indicate specific legal requirements, autonomy boundaries, and recommended architecture:
FAQ
#Does a chatbot in a government office have to identify itself as AI?
#Yes, this is an absolute requirement. Article 50 of the AI Act imposes on deployers of AI systems interacting with individuals the obligation to disclose that the interlocutor is an AI system, unless it is obvious from the context. In the case of a resident service chatbot, obviousness from context is not sufficient: the office should clearly label the system as an "AI assistant" or "chatbot" in the interface and at the start of each session. Failure to disclose is a violation of the AI Act regardless of whether the system makes decisions.
Can an administrative decision be supported by AI?
#Supported, yes; made by AI, no. An AI system can prepare a draft decision based on case files, indicate missing documents, identify similar precedents in the jurisprudence database, and suggest the content of the justification. However, a decision under Article 104 of the Administrative Procedure Code must be signed by an authorized employee or authority who bears legal and administrative responsibility for it. Human-oversight is not optional here: it is a condition of legality.
Which AI systems in local government units require a DPIA?
#A DPIA is mandatory when processing personal data may result in high risk. In practice, for local government units: systems assessing benefit applications, chatbots collecting residents' personal data (even in descriptive form), monitoring systems with image analysis, and systems processing sensitive data (health, disability, social status). The Polish Data Protection Authority recommends a proactive approach: if in doubt, conduct a DPIA. The cost of preparing a DPIA for a simple system is a few days' work; the cost of a GDPR violation is many times higher.
What must a contract with an AI system supplier for a government office include?
#Legal minimum: a data processing agreement compliant with Article 28 of GDPR (purpose, scope, duration, supplier obligations), a data location clause (where data is stored and processed, obligation to maintain data-residency in the EEA or the office's infrastructure), the supplier's commitment to provide technical documentation required by the AI Act if the system is classified as high-risk, and a clause allowing audits by the office or supervisory authority. In public procurement, it is worth including these requirements already in the tender specification to avoid the need for renegotiation after signing the contract.
How should a government office communicate to residents that AI processes their data?
#Through two channels simultaneously. First: a GDPR information clause (Article 13) visible at the first interaction with the AI system, containing the data controller, purpose and legal basis for processing, resident rights (access, objection, erasure). Second: labeling the interface as an AI system in accordance with AI Act Article 50. Both requirements can be combined in a single chatbot welcome message. It is also worth placing a summary of the information in a visible place in the interface throughout the session, not just at the start. Both the GDPR clause and AI labeling should be available in Polish without legal jargon.