Officers are already drafting incident reports with AI. Analysts are already summarizing case files with it. For agency leadership, the question is no longer whether staff will use these tools. It is what CJIS compliance requires before criminal justice information touches an AI tool at all. The short answer: CJIS Security Policy v6.0 does not prohibit AI, and it does not need to. It asks of AI what it asks of any system that handles CJI, which is controlled access and an audit record the agency can produce on demand. Most agencies today can produce neither for their staff’s AI use.
Can police use ChatGPT?
Nothing in the CJIS Security Policy names ChatGPT, and nothing in it bans generative AI. The policy is written around the data, not the software. So the real question is narrower: does criminal justice information enter the tool, and do the required controls hold when it does. If an officer pastes a case narrative containing names, dates of birth, and record identifiers into a personal chatbot account, CJI has left the agency’s boundary and reached a provider the agency does not control, with no record of what crossed. That is not an AI problem. It is an unauthorized disclosure with extra steps.
Whether AI use is defensible depends on what the agency had in place before the paste: was the access authorized, was the content controlled, and was the event recorded. A consumer account fails all three. A per-seat agreement with the provider helps with the first and does little for the other two, which is worth spelling out.
What CJIS Security Policy v6.0 actually requires
Version 6.0 of the CJIS Security Policy, published in December 2024, restructured the policy to map directly to NIST SP 800-53 revision 5 controls. The audit obligations live in the AU family, audit and accountability. In plain terms: agencies must define which events are auditable, generate records with enough content to establish who did what and when, protect those records from change, and retain them for at least one year.
The policy also set a clock. Its controls are phased by priority, and the remaining priority controls become fully auditable by October 1, 2027. AI use that becomes routine in a department this year will be inside audit scope, on a pathway the department may never have treated as auditable at all: the traffic between a staff member’s device and an AI provider.
The questions a state auditor will ask
Applied to AI, the AU family reduces to five questions. They are the same questions auditors already ask about CAD and RMS access, pointed at a new channel.
- Who accessed CJI through an AI tool, and when.
- What was sent: the prompt, the pasted content, the attached file.
- Where did it go: which provider, which service, sanctioned or not.
- Can you produce the record today, for an event from months ago.
- Can you show the record has not been altered since it was made.
An acceptable-use memo answers none of these. A policy document describes what staff were told to do; an audit record shows what actually happened. The gap between the two is where findings come from.
Why a per-seat provider agreement does not answer the audit question
Per-seat provider agreements are worth having. Good ones commit the provider not to train on your inputs, define retention, and add contractual confidentiality. But an agreement governs what the provider does with your data after it arrives. The audit questions above are about what your agency can show about the data before and as it left. Those are different problems, and the second one is yours.
| The audit question | What a per-seat agreement provides |
|---|---|
| Who sent CJI to an AI tool | A list of who holds a seat, not who sent what |
| What content was sent | Nothing the agency holds; any content record sits with the provider |
| Where the data went | An answer for the sanctioned tool only |
| A record you can produce a year later | A dependency on the provider’s systems, not a record you hold |
There is also a coverage problem. The agreement covers the tool the agency bought. Staff use the tool that is closest at hand, and unsanctioned use does not route itself through the sanctioned seat.
Report writing is already the mainstream case
None of this is hypothetical. AI-assisted report drafting is common enough that the Department of Justice COPS Office published a piece on using AI to write police reports in January 2025. Agencies across the country have piloted or deployed draft-generation tools, many of them built on commercial models.
Legislatures are converging on the same point auditors will: the record is the requirement. California’s SB 524, signed in October 2025 and effective January 1, 2026, requires agencies to disclose AI use on the face of a report, retain the AI’s first draft for as long as the report itself, and maintain an audit trail identifying who used AI to create it. The direction of travel is consistent: the use is permitted, and the record is mandatory.
What defensible looks like
Strip away the acronyms and a defensible posture has two properties. First, the policy decision happens before CJI leaves the device. Not in a quarterly review, and not in a provider’s dashboard after the fact. The request an AI tool is about to send is intercepted on the device and decided against agency policy: allow it, redact the identifiers, or block it. Once the data reaches the provider, the decision has already been made and cannot be unmade.
Second, every decision produces a record the agency holds. A tamper-evident one: each entry signed on the device and chained to the one before it, so any alteration is visible, retained for at least the one year the AU controls require, under keys the agency controls rather than the provider. That structure is what an AI audit trail is, and it is the difference between telling an auditor what your policy said and showing what your fleet did.
If CJI can reach an AI tool, two things need to exist first: a policy enforced before the data leaves the device, and a tamper-evident record of what crossed that the agency can produce a year later.
Where Verillian fits
Verillian is runtime governance and evidence for regulated AI, built for exactly this gap. A sentinel on each device governs any AI tool or agent that reaches a provider, with no per-tool integration. It intercepts requests before they leave the device, decides them against agency policy, and redacts or blocks CJI before a provider sees it. Detection is best-effort, not a guarantee that every value is caught, and the record shows what was done either way. Every captured interaction is signed on the device and hash-chained into an append-only record, with retention aligned to the CJIS Security Policy v6.0 audit requirements of one year, and the server stores only ciphertext under keys the agency holds.
The architecture is CJIS-ready: aligned to CJIS Security Policy v6.0, not certified, because CJIS compliance is validated through state-agency audit rather than a product certificate. Our compliance mappings show the controls the platform is designed to support, the audit trail page shows what the record contains, and the law enforcement section of the industries page covers what deployment looks like for an agency. Governance is a meeting; enforcement is what Verillian does.