What a court AI policy has to cover before it can operate

Adoption is the smaller half

A court AI policy usually arrives as a document. It is drafted, reviewed by counsel, approved by a presiding judge or a judicial council, circulated, and filed. That is real work, and it is the smaller half of the job.

The document commits the court to things that only exist if somebody maintains them: a list of tools staff are allowed to use, a way to get a new tool onto that list, a record of what was used and when, and training for the people expected to comply. None of that is produced by adopting the policy. It has to be built, assigned to a person, and given a review date.

This is a checklist for that second half. It assumes your court has adopted a policy, or has decided to prohibit generative AI for now, and needs the operating layer underneath the decision. Nothing on the list requires new software.

What the rules require

California Rules of Court, rule 10.430 was adopted on July 18, 2025 and took effect on September 1, 2025. It required courts that permit the use of generative AI to adopt a use policy by December 15, 2025. A court that prohibited generative AI was not required to adopt one.

That distinction is worth getting right before it is repeated in a briefing. The obligation followed the decision to permit, and prohibition remained available. A statement that every California court had to adopt an AI policy is wrong, and the people in the room who have read the rule will know it.

The New York Unified Court System took a different route. Its interim policy restricts use to tools the court system has approved, and requires training for judges and nonjudicial employees. Both approaches put their weight on the same two things a document cannot do by itself: keeping a list current, and getting people trained.

Your own state may have a rule, an administrative order, an interim policy, or nothing published yet. The checklist below applies in all four cases, because it describes what an operating policy needs rather than what any one rule requires.

The operating layer, item by item

Each item below is a thing that exists or does not exist. If it exists, someone can produce it within a few minutes and say who owns it.

• An approved-tool list, with an owner and a review date. Named owner, a published location staff can find in under a minute, and the date it was last reviewed. The common failure is not a rogue chatbot. It is a vendor turning on an AI feature inside software the court already licenses, while the list, written about chatbots, never mentions it.
• A vetting rubric, written once and applied every time. The same questions asked of every tool: what data may be entered, whether inputs are retained or used for training, who processes them and where, whether output is logged, whether it meets WCAG 2.2 AA, what the contract says, and who at the court approves. The rubric ends in a written decision with a date and a name, so the reasoning can be explained a year later by somebody who was not in the room.
• A short, specific list of material that never goes near a tool. Sealed records, juvenile matters, confidential health information, juror personal information, anything under a protective order. This list is short, it is written in your own record types rather than in general categories, and it belongs to your counsel.
• Disclosure, split into two separate questions. What staff must disclose internally, and what the public is told about a tool that faces them. A self-help chat service and a clerk drafting internal correspondence are not the same disclosure question. Courts answer them differently, and both answers should be written down rather than assumed.
• Logging and retention that could survive a question. If a judge asks what a tool did on a matter last March, what could the court produce, from which system, and how long is it kept? Settle this against your records retention schedule and with the counsel who handles public records requests, before the first question arrives rather than after.
• Training, by role, on a calendar. The bench, chambers staff, clerks at the counter, self-help staff, IT, and procurement each need a different half hour. New York requires training for judges and nonjudicial employees; treat it as an operating requirement even where no rule compels it. Untrained staff do not stop using these tools. They stop telling you.
• A review date, and the events that pull it forward. A new AI feature in a product you already own, an incident, a rule change, a vendor changing its data terms. Name the person who convenes the review and the date it happens by default.

Five questions that tell you whether it is operating

These can be answered in an hour, by one person, without a project. They are also the questions an oversight committee or a reporter would reach within about ten minutes.

• Can someone name the currently approved tools without hunting for the file for more than a minute?
• Who approved the most recent addition to the list, and where is that decision written down?
• When was the list last reviewed, and what is the next review date?
• Where does a clerk go with "am I allowed to use this", and how long does an answer take?
• If a judge asked what a tool did on a specific matter last March, what could the court produce?

Four or five clear answers means the policy is operating. One or two means the court has an adopted policy and an unwritten practice, which is where most courts are, and which is worth naming plainly in front of an executive committee before somebody else names it.

What you should not pay anyone for

The National Center for State Courts publishes AI readiness material for state courts at no charge, and the California Judicial Council published a model policy a court could adopt or adapt without paid help. If the policy document itself is what is missing, start there and keep the money.

The hard part is elsewhere: the inventory of what is already running inside licensed products, the data questions the rubric has to ask, the logging that must come out of systems nobody designed for this, and a training calendar that reaches the counter as well as the bench. That work is specific to your systems, and no published model policy performs it.