Writing a generative AI use policy for agency staff

Reference article · 5 min read

Most agencies arrive at this task the same way. Someone notices staff pasting draft language into a chatbot, or a board member asks what the rules are, and IT or the clerk gets a short deadline to publish something. The first instinct is a blanket prohibition. Bans are quick to write and hard to keep: staff have these tools on their phones and inside software the agency already licenses, so a prohibition mostly moves the activity out of view.

A workable policy is narrower than a ban and more specific than a statement of principles. It names which tools may be used, draws a line around what data may be entered, says who is accountable for the output, and explains what happens when someone works around it. Requirements differ by state and by agency and keep changing, so confirm specifics with your records officer, your security and privacy staff, and counsel before adoption.

Scope and definitions

State what the policy governs: tools that generate text, images, code, audio, or video from a prompt, whether standalone products or features inside software the agency already owns. The embedded ones deserve explicit mention, because meeting summarizers, email assistants, and code completion arrive through routine upgrades and staff do not always recognize them as the thing the policy covers. Say who is covered: employees, temporary staff, interns, and volunteers belong here, while contractors are normally handled through contract language the policy can point to.

Approved tools and how the list changes

Keep product names out of the adopted policy text, because products change faster than a policy can be revised. Have the policy set categories and name an owner who maintains the list.

• Approved for general use. Tools the agency licenses under an enterprise agreement, with administrative controls, documented data handling terms, and logging in place.
• Approved for limited use. Free or consumer tools cleared for narrow, non-sensitive work such as general drafting, with the data rules below still applying.
• Not approved. Everything else by default, including new features switched on inside products the agency already uses.
• A request route. An intake form, a named reviewer, and a target turnaround. Without a realistic path to yes, staff will route around the policy.

What data may and may not be entered

Write this section as examples, not categories alone. It is the part staff will actually read.

• Never. Criminal justice information, protected health information, student records, tax data, Social Security numbers, and anything whose exposure would trigger breach notification.
• Not without approval. Personnel matters, security documentation such as network diagrams and vulnerability findings, attorney-client material, active procurement records including bids and evaluation notes, and predecisional drafts.
• Generally acceptable. Information the agency has already published, general professional questions, and work with no identifiable person or protected record in it.

Give staff one rule of thumb: assume anything typed into the tool could be retained by the provider, produced in a records request, and read in litigation. Where an enterprise agreement prohibits training on agency inputs, say so, and note that personal accounts carry no such protection.

Review before output leaves the agency

Accountability rests with the person who used the tool, not with the tool. Make that explicit, then set proportionate review.

• Verify before use. Facts, figures, citations, statutory references, names, and dates. These tools produce fluent text that is confidently wrong, and legal citations are a known failure point.
• Second review for higher-risk output. Public communications, council or board materials, legal filings, responses to records requests, and code destined for production.
• Human determination required. No eligibility, benefit, enforcement, discipline, or hiring decision should rest on model output. A person makes the determination and signs it.

Disclosure, attribution, and records

Draw the line at substance. Tightening wording or fixing grammar does not usually warrant disclosure, much as a spelling checker does not. Drafting a report, an analysis, or a public-facing narrative usually does. Decide the rule and show the wording staff should use. Prompts and outputs created in agency business may also be public records subject to retention and disclosure, which is harder to satisfy when the conversation lives in a personal account.

Personal accounts and unapproved tools

Prohibit conducting agency business in personal accounts, and give the reason in one sentence: the agency cannot preserve, search, or protect what it cannot reach. Then plan for the fact that it has already happened. A short amnesty at rollout, with instructions for reporting prior use, surfaces more than an enforcement posture does. Treat a first instance as a training matter unless protected data was exposed, in which case incident response applies. Blocking consumer endpoints reduces casual use, but new tools appear constantly, so the written rule is what scales.

Publishing a first version

1. Draft two pages of policy, a separate tool list, and a one-page set of examples. Long documents do not get read.
2. Circulate to counsel, the records officer, HR, and security at once rather than in sequence.
3. Pilot with one department and fold their questions into the examples.
4. Train briefly, collect written acknowledgment, and set an annual refresh.
5. Put a review date on the policy, no longer than a year out.

When evaluating a tool for the list, ask the vendor whether agency inputs or outputs train models, where data is stored and for how long, how deletion and export work, which subprocessors and model providers are involved, and what administrative controls and audit logs exist. Put what matters into the contract: a no-training clause, retention and deletion terms, notification obligations, and the right to export logs and content.

HQT works with state and local agencies on AI governance and the systems work that follows.

Frequently asked questions