Government

AI Policy for Local Government: Start With What Staff Already Do

A workable AI policy starts with the work employees already do. Map the data, protect it before it leaves the agency, plan for public records, and give staff a sanctioned tool they will actually use.

By Roshnee Sharma · CEO, Autessa

Most conversations about AI policy in local government start with a list of approved and banned tools. That is usually the wrong starting point.

Start with the work employees are already doing. A staff member asks a chatbot to rewrite an email, summarize a complaint, translate a notice, or clean up meeting notes. The output may look harmless. The input, the uploaded files, the prompt, and the resulting conversation history can carry sensitive information, and they may create records your agency needs to retain or produce.

In short: a workable AI policy maps real employee behavior, protects data before it leaves the agency, accounts for public records obligations, and gives staff a sanctioned tool they will actually use.

What is your agency already sending to AI tools?

The simplest AI use case is often a request like "Can you make this email sound more professional?" But an email is rarely just an email.

It may include a resident's name, address, case number, health situation, or account details. It may reference a personnel issue, a pending procurement, a legal matter, or an enforcement action. If the employee uploads an attachment, the tool may receive the entire document, not only the paragraph the employee wanted to revise.

The prompt matters too. Consider the instruction "Rewrite this so the council member does not realize we missed the deadline." That sentence reveals information about the agency that does not appear anywhere in the draft itself.

AI can also create new analysis. Asking a tool to summarize a complaint, assess a vendor proposal, or explain what a resident "really means" produces reasoning that did not exist before. If that reasoning informs agency work, it may matter in a records request, a dispute, or a later review of how a decision was made.

What one AI request can carry A single request to rewrite an email is broken into five parts. The prompt can reveal intent the draft never states. The pasted draft can contain resident names, addresses, and case numbers. An attachment sends the entire document. The AI output is new analysis that may inform a decision. The chat history is a saved record that may be requestable. WHAT THE EMPLOYEE SENDS WHAT IT CAN CARRY The prompt Intent the draft never states, such as a missed deadline. The pasted draft Resident names, addresses, health details, and case numbers. The attachment The entire document, not only the paragraph that needed edits. The AI output New analysis that may shape how a decision gets made. The chat history A saved record that may be subject to a records request.
A request to polish one email can send far more than the email. Map every part of the request before deciding what the policy should allow.

Before writing rules, map the work. Ask each team these questions:

  • What tasks are you using AI for today?
  • What data appears in the prompt, the attachments, and the conversation history?
  • Does the task involve information about residents, employees, vendors, students, patients, or law enforcement?
  • Where does the data go after someone presses enter?
  • Can the agency locate, retain, export, and delete those interactions when it is required to?

This exercise reveals more than a tool inventory. It shows where agency data is already moving.

Can AI chats and prompts become public records?

Yes, they can. Public agencies carry a responsibility that private companies do not face in the same way, because transparency laws can apply to the content of the work and not just to the system used to create it.

Prompts, uploaded files, conversation histories, and AI-generated drafts related to public business may be subject to public records requests, retention schedules, litigation holds, or disclosure in a legal matter. In California, for example, the state Supreme Court held in City of San Jose v. Superior Court (2017) that communications about public business can be public records even when they sit in an employee's personal account. Your records officer and legal counsel should determine how the laws in your jurisdiction apply to specific AI interactions.

The practical lesson is clear. An AI chat is not necessarily a private scratchpad.

Imagine a supervisor who drafts an angry message about an employee, pastes it into an AI tool, and asks for a more measured version. The polished draft is sent, but the original wording may still sit in the chat history. A tool that was meant to improve tone has created a record of language the supervisor never intended to share.

The same issue applies to experimentation. Employees who test a new tool with real data, try half-formed ideas, or draft and discard language can create a trail of agency work. That is not a reason to avoid useful tools. It is a reason to use them with the same judgment staff already apply to email, shared drives, and official documents.

A practical policy classifies AI interactions together with your records team. Some interactions may be transitory. Others, especially AI-assisted analysis that supports a decision, may require longer retention. The systems you approve need to support that distinction, including the ability to preserve records under a litigation hold. We covered this in more depth in How to Iterate Safely with AI: A Guide for Public Agencies.

Why do outright AI bans create shadow AI?

When agencies see the privacy, records, and accuracy risks, a full ban can feel like the safest response. The instinct is understandable, but a ban is often ineffective.

Public employees work under deadlines, and consumer AI tools are available on every personal device. If agency technology cannot meet a real need, people may turn to a personal phone or an unapproved account to get the task done.

That creates shadow AI, which is work happening outside agency visibility, outside approved contracts, and outside the retention and security controls the agency relies on. The risk has not disappeared. It has moved somewhere that is harder to find, manage, and respond to.

A better policy creates a sanctioned path for low-risk work and adds stronger safeguards as the stakes rise.

A tiered AI policy instead of a ban A ban pushes work onto personal phones, personal accounts, and unapproved apps, where the agency has no visibility and no retention. A tiered policy instead sorts AI work by stakes. Low-risk drafting of public content runs in an approved tool with guardrails. Work that touches internal or personal data adds redaction and supervisor review. High-impact work that affects residents' rights, eligibility, safety, or access requires testing, documented human accountability, and governance review. A BAN The work does not stop. It moves somewhere the agency cannot see. Personal phones Personal accounts Unapproved apps NO VISIBILITY NO RETENTION A TIERED POLICY Low risk Drafting public content runs in an approved tool with published guardrails. GUARDRAILS Sensitive data Work with internal or personal data adds automatic redaction and supervisor review. REDACT AND REVIEW High impact Eligibility, enforcement, hiring, and safety work requires testing, a named accountable person, and governance. FULL GOVERNANCE
A ban moves AI use out of sight. A tiered policy keeps low-risk work easy and saves the heavy review for decisions that affect residents.

Rewriting a public newsletter is not the same as helping evaluate benefit applications, rank enforcement priorities, review permit submissions, or support hiring decisions. A tiered policy can allow lower-risk drafting with clear guardrails. It can then require additional review, testing, documented human accountability, and governance for work that affects residents' rights, eligibility, safety, or access to services.

The employee who sends, publishes, or acts on AI output remains accountable for it. AI can help draft, but it cannot own a public decision.

How can agencies protect data before it leaves?

Training is the first control. Employees need practical guidance that is based on the tasks they actually perform.

Staff should know what sensitive information looks like in their agency, why raw drafts and prompts matter, when a task should not involve AI at all, and how to spot an inaccurate summary or a fabricated citation. They should also know that regulated information can carry additional rules, including law enforcement data, health information, student records, tax information, and state privacy requirements.

Training alone cannot catch every mistake, which is where technical controls matter.

Automated redaction and data loss prevention can inspect information before it is sent to an AI model. These controls can detect and remove or mask names, addresses, Social Security numbers, case identifiers, health information, and other sensitive values.

This approach changes the risk profile. Staff still get help with a drafting or summarization task, while sensitive details never leave the agency environment. It is far easier to protect data that never leaves than to negotiate over data that has already been shared with a third party.

Agencies should also limit what AI agents can access and do. A tool that can only revise a selected block of text presents a very different risk than one that can read an inbox, search shared drives, browse the web, or take action in another system. Security teams should be involved before anyone grants those permissions.

What should you ask AI vendors before approval?

Every AI product is a chain of services. The interface your employees use may depend on a separate model provider, a cloud host, an analytics service, and other subprocessors. Each link is another place agency data can travel.

Ask direct questions during procurement and security review:

  • Can the model run in your own cloud account or tenant?
  • Does the provider retain prompts, files, or outputs, and for how long?
  • Is agency data used to train any model?
  • Who are the subprocessors, and where does the data reside?
  • Can the agency export logs for records requests and retention obligations?
  • Can the provider preserve relevant data for a litigation hold?
  • Can the agency delete records when the applicable retention period ends?
  • What access can the tool receive, and what actions can it take?

Then look beyond standalone chatbots. AI features are increasingly added to office suites, video conferencing tools, CRMs, permitting systems, help desks, and other software agencies already use. A routine update can open a new path for agency information to leave the systems you govern.

Maintain an inventory of AI-enabled systems, including features that are turned on by default. Review each one through the same lens: what data enters, where it goes, how long it stays there, and whether your agency can explain those practices clearly to residents.

What else should a public-sector AI policy cover?

A useful policy also addresses the operational realities of government.

Decisions affecting residents. Set stronger requirements for AI used in eligibility, enforcement, permitting, hiring, public safety, or other high-impact work, and require human review with documented accountability.

Meetings and recordings. AI notetakers and transcription tools can raise issues under open meetings laws, recording consent requirements, and records retention rules. A summary of a closed session needs particular care.

Accessibility and language access. AI can help draft plain-language materials and translations, but resident-facing content needs human review for accuracy, accessibility, and appropriate language.

Labor relations. Changes to how work is performed may trigger bargaining or meet-and-confer obligations. Involving labor representatives early reduces friction and improves adoption. Our post on the human side of AI governance covers this in more detail.

Governance and incident response. Name who approves tools, who handles an incident, how employees report concerns, and how often the policy is reviewed. The technology will keep changing, so the policy should be revisited at least once a year. The NIST AI Risk Management Framework is a useful reference for structuring that review.

What should your agency do next?

Good AI policy is not a yes-or-no decision about a tool. It is a practical operating model for how your agency uses AI without losing control of its data, records, and accountability.

Start with the work people are already doing. Map the data moving through those tasks, and teach employees what they are sharing. Give them an approved path that is useful enough to choose. Then put controls in place so sensitive information is removed before it reaches a third party.

Autessa gives agencies a governed AI environment where data stays in their control and sensitive information can be redacted before it is sent to an AI model. If you are drafting or revising an AI policy, we would be glad to show you how that works in practice.

This post is general information, not legal advice. Records, privacy, and retention obligations vary by agency and jurisdiction, so set your policies with your own counsel.

Sources