What a County Should Ask an AI Vendor About Public Records Law

The checklist that answers the wrong question

Your county is evaluating an AI tool. Somebody in IT found a vendor questionnaire online, the kind that ranks for this search, and it runs to fifty questions. Where is the data stored. Has the vendor had a third-party audit in the last twelve months. What is the incident response SLA. Is customer data used to train the model. One line, somewhere around question thirty-eight, mentions retention.

Those are real questions. You should ask them. None of them is the one that will cost you.

The question that will cost you is whether the tool creates a public record, and the answer is almost always yes. The prompt an employee types is a record. The draft the model hands back is a record. The log of which documents the system retrieved to build that draft is very likely a record. Each of those is subject to a retention schedule, discoverable in a records request, and in your custody whether or not it sits on your servers.

The vendor questionnaire frames all of this as a privacy and security problem. That is the vendor's frame, because privacy and security are things the vendor can promise. Records law is a custody problem, and custody is not something a vendor can take off your hands.

This is no longer hypothetical

In 2025, KNKX and Cascade PBS filed public records requests with nearly a dozen Washington cities seeking two years of employee ChatGPT logs. Everett and Bellingham produced them. Most of the content was mundane: staff drafting emails, formatting spreadsheets, summarizing meeting notes, writing speeches and press releases.

Some of it was not. One Bellingham log showed a staffer asking ChatGPT to write contract requirements that would favor a preferred vendor and exclude a competitor "without explicitly saying so". The city opened an independent investigation. Another log contained GIS code for tracking homeless encampments that had to be heavily redacted for security reasons before release.

Two details from that reporting matter more for procurement than the headline does.

First, several logs end with the employee asking ChatGPT how to export their chat history. That is what a records request looks like from the inside when nobody planned for it: individual employees, on their own accounts, working out on deadline how to pull records out of a product that was never set up to produce them.

Second, the mayor of Bellingham said her chats were not saved because she was not logged in. Notice what that means. Whether a public record existed was decided by a session setting, not by a retention schedule.

California's public agency counsel has drawn the same conclusion from the statute side. Liebert Cassidy Whitmore's analysis of the California Public Records Act puts it plainly: prompts are prepared by employees, outputs are used in agency business, and logs may be retained even when stored by third-party vendors. AI content used in agency business will likely fall inside the definition.

Possession is not the test you think it is

The instinct in most counties is that a record held by the vendor is the vendor's problem. It is not.

The UNC School of Government, which advises North Carolina local governments and sells nothing, walks through the point. Under North Carolina law, prompts and outputs created in the course of government work are public records "regardless of physical form or characteristics." A 2023 Court of Appeals ruling held that actual or constructive possession is enough. If your employee can reach the conversation through an account the county pays for, the county has it.

State law varies, and your county attorney should confirm how yours reads. But the published guidance in both California and North Carolina points the same way: the record follows the business purpose, not the server.

Which turns the vendor relationship inside out. You are not buying a tool that might touch your records. You are buying a records system, one you did not design, whose retention behavior was set by a product manager optimizing for something else entirely.

Retention is decided by content, and the tool cannot see content

Here is where the questionnaire falls short.

Retention schedules are written by record type. A draft letter is often transitory and can go once the final is issued. A citizen complaint has a schedule. A personnel decision has a much longer one. The UNC analysis makes exactly this point: an AI-assisted analysis supporting a personnel action, or a complaint received through a chatbot, needs to be kept far longer than a reworded email.

An AI product, meanwhile, has one retention behavior. Thirty days. Ninety days. Until the user deletes it. Forever. Whatever the setting is, it applies the same way to the email rewrite and to the disciplinary memo, because the product has no idea which is which.

So when you ask a vendor about retention and they answer with their data deletion policy, listen carefully to what they have told you. They have told you they think this is a privacy question. A deletion policy is a promise to destroy data. A retention schedule is an obligation to keep it, for a defined period, and then destroy it on a defined trigger. Those are opposite instincts, and a product built around the first one will quietly violate the second.

The failure runs both ways. Delete too early and you have destroyed a public record, possibly one already responsive to a pending request. Keep everything forever and you have built a discoverable archive of every half-formed thought your staff typed into a text box, which is its own kind of exposure. Either one is a records management failure that your clerk, not the vendor, answers for.

The question to ask

Ask the vendor to name the retention schedule their product satisfies.

Not their security certifications. Not their deletion policy. The schedule. Your state's general records schedule for local government, by name, and how their product lets you apply it by record type.

Most vendors will not have an answer, and that is fine. It is not a disqualifier. It is information. What you are listening for is whether they understand the question. A vendor that says "we have not mapped to your state's schedule, but here is how an administrator exports a user's full history with metadata, here is how a legal hold suspends deletion, and here is how you can set retention per workspace" is a vendor you can work with. A vendor that says "data is encrypted at rest and deleted after thirty days" has answered a different question, and is telling you their product will destroy records on a timer you did not set.

There are three follow-ups we would not skip:

• Can the county produce a complete record without the employee's cooperation? If producing a log depends on the user logging in and clicking export, your response to a records request depends on every individual employee, including the ones who have left.
• Can the county stop deletion? A pending records request or a litigation hold freezes destruction. If the product cannot do that, the county is out of compliance the moment a request arrives.
• What does the retrieval log contain? For tools that search your documents to build an answer, the list of what was retrieved may itself be responsive. Find out whether that list exists before a requester asks for it.

None of these requires a technical evaluator. They require someone who knows the records schedule to be in the room when the tool is chosen. In most counties that person is the clerk or the records officer, and in most AI procurements they are not invited.

Who owns this inside the county

That last point is the actual finding. AI procurement in local government is usually run by IT, sometimes with legal review of the contract terms. The records officer hears about the tool after it is deployed, often when the first request lands.

This is the same pattern we described in how a records request backlog compounds: the cost of a records problem arrives late, arrives with interest, and lands on the people with the least say in how it was created. An AI tool chosen without a records review does not create a backlog on day one. It creates thousands of unscheduled records, quietly, and the bill arrives with the first broad request for "all AI usage logs" from a reporter who has read the Washington coverage.

The other half of the problem is shadow use. The Washington logs came largely from individual subscriptions and free accounts. If the county does not provide a tool with sane records behavior, staff will use one without it, and the county will still be the custodian. The UNC guidance recommends requiring work accounts precisely so that records are not mixed in with personal ones. That is a policy decision, but it only works if the sanctioned tool is good enough that people use it, a problem we have written about in why internal AI chatbots go unused.

There is a dry irony in all this. The single most useful thing an AI vendor can offer a county is a good export button. Not exactly the future anyone pitched, but it is the one that keeps the clerk out of court.

What this is not

This is not an argument against AI tools in county government. Most of what the Washington logs showed was ordinary, defensible work done faster. The argument is narrower: the evaluation framework most counties are borrowing was built for a different risk, and the risk it misses is the one with a statutory deadline and attorney fees attached.

It also does not replace the general discipline of evaluating an AI vendor when you are not an engineer. Ask the security questions. Then ask the custody question, and put the person who owns the retention schedule in the room to hear the answer.

Where to go from here

If your county already has AI tools in use, sanctioned or not, the useful first step is not a policy memo. It is finding out what records those tools have already created, where they sit, and whether you could produce them in response to a request that arrives tomorrow. If you are about to buy, the question is whether your evaluation includes anyone who can tell a deletion policy from a retention schedule.

Either way, that is a conversation about your state's law, your schedules, and the tools your staff are actually using. Talk to us before the first request for your AI logs arrives, not after.