AI
An acceptable use policy for generative AI should govern data, not tools
What a generative AI acceptable use policy must cover, what it should leave alone, and how to keep it from going stale.
Whether agency staff will use generative AI is not an open question. They will, and if the agency has approved nothing, they will use consumer accounts on personal devices with no contract, logging, or retention terms. A policy written to stop that will be ignored. A useful one tells an employee in under a minute whether what they are about to do is allowed, and what to do when it is not.
We keep an acceptable use policy for AI tools inside HQT and rewrite it as the tools change. What follows is the structure we would use for a public agency, what we would leave out, and the maintenance that keeps it current.
Govern the data, not the tool
The durable rule in an AI use policy is about information, not products. Product names and feature sets change constantly; data classifications do not. If the agency already sorts information into public, internal, and confidential, attach the AI policy to that scheme rather than invent a parallel one.
The practical form is a short grid. Public information may go into any tool on the approved list. Internal information may go only into tools the agency has contracted for, under terms that address training on agency data and retention. Confidential categories are prohibited or confined to a named environment. Those categories already carry their own legal regimes: HIPAA for health information, FERPA for student records, the FBI's CJIS Security Policy for criminal justice information, and state law for personally identifiable information. The AI policy should not restate those rules, only say which tools may touch the data they cover.
What the policy has to cover
- Scope. Employees, contractors, interns, and volunteers. Agency devices and personal devices used for agency work. AI features embedded in software the agency already licenses, which are easy to overlook and often on by default.
- Approved tools and how to add one. A register of approved tools, a request path, a named approver, and a response time. A policy that never explains how to get approval guarantees unapproved use.
- Human accountability. The employee who uses an output owns it. Nothing reaches a decision, a public communication, a legal filing, or production code without review by someone competent to judge it.
- Decisions about people. Eligibility, benefits, discipline, hiring, licensing, and enforcement need a documented human decision maker and a record of the basis. States and localities increasingly regulate automated decision systems, and their definitions vary, so counsel should map what applies.
- Records and retention. Depending on the jurisdiction, prompts and outputs can be public records and subject to retention schedules. Say where AI-assisted work is stored and logged instead of leaving staff to guess.
- Security handling. No credentials, keys, or security configuration in prompts. Treat model output as untrusted input, especially when a tool can browse, read mail, or act on content the agency did not write.
- Disclosure. State whether AI-assisted material that reaches the public is labeled, and how.
- Reporting mistakes. Give staff a route to report a bad output or an accidental disclosure that does not begin with discipline.
What it should not try to ban
Policies lose credibility when they forbid ordinary work. Drafting, summarizing documents the agency already publishes, rewriting notices in plain language, explaining unfamiliar code, and generating synthetic test data are low risk. Naming them as permitted does more than another prohibition.
Three over-restrictions to avoid. A tool blocklist as the core of the policy ages quickly and pushes use underground. Pre-approval for every individual use gets sought once and then skipped. A blanket ban on personal devices is unenforceable; the enforceable version states what data may never leave the approved environment, whatever the device.
Make it checkable in the moment
One page of rules, one page of examples. The rules collapse into three questions: Is this information approved for this tool? Can I review the output competently? Does this touch a decision about a person? The examples should come from the agency's own work with a yes or no attached: a code enforcement letter, an evaluation sheet for an open solicitation, a constituent email with a case number. In our internal exercises, the examples draw the questions.
Keep it current
- Name an owner and a review cadence. Quarterly is realistic; annual is not.
- Put a version number and date on the document, and keep the tool register separate so adding a tool does not require amending policy.
- Log exceptions. Recurring exceptions are the agenda for the next revision.
- Align the vocabulary with a recognized reference such as the NIST AI Risk Management Framework and its generative AI profile, both voluntary, so the policy connects to risk work already underway. Federal agencies work under separate OMB direction; state and local agencies do not inherit it.
- Revisit when a vendor changes a model or turns on a feature by default, because the assumptions behind an approval may no longer hold.
What this means for an agency
Publish a short version 1 in weeks rather than a comprehensive one next year. Anchor it to the data classifications already in use, keep the tool register outside the policy, train on examples rather than definitions, and set the review date now. A policy that is slightly too permissive and actually followed protects an agency better than a strict one that departments quietly route around.