CJIS Security Policy Requirements for AI in Law Enforcement

CJIS Security Policy version 6.1 governs how law enforcement agencies handle criminal justice information, and it does not carve out any exception for artificial intelligence. If a system touches CJI, whether it's a records management platform built years ago or a large language model deployed last month, the same 178 controls apply, and confused vendor marketing doesn't change that. The FBI's CJIS Security Policy Resource Center hosts the current 473-page document, dated June 25, 2026, publicly and without restriction, so there's no excuse for agencies or vendors claiming they didn't know the rules existed. What follows is a breakdown of who has to comply, what the timeline actually looks like, which controls matter most for AI specifically, where the most common failure happens, and what a compliant deployment looks like in practice.

Who must comply and why AI has no exemption

CJI is a broad category by design. It covers fingerprint records, criminal histories, biometric identifiers, active warrants, arrest records, and any personally identifiable information tied to a criminal case. That data gets pulled from systems including NCIC, the Interstate Identification Index, NICS, N-DEx, NGI, and UCR. Within that larger category sits Criminal History Record Information, or CHRI, a restricted subset that carries its own additional handling rules under a dedicated set of federal regulations. Agencies running employment background checks answer to both the CJIS policy and Compact Council rules simultaneously, and that dual accountability is why compliance gaps appear first in background-check workflows.

Scope runs wide across the criminal justice ecosystem. State, local, tribal, and federal law enforcement agencies are in it, obviously, but so are courts, prosecution offices, correctional facilities, and 911 dispatch centers. State IT organizations that provide shared services fall under the policy too, and so do government contractors, including any vendor with unescorted physical access to a facility handling CJI. CJIS Management Agreements, the legal instrument that binds noncriminal justice entities to these same standards, now apply to criminal justice agencies in 47 states plus the District of Columbia, a footprint spanning nearly the entire country. That's not a small footprint.

There is no AI exemption anywhere in the 20 policy areas. A predictive policing platform, a pretrial risk assessment tool, a records management assistant built on a language model, a dispatch system with an AI triage layer, all of it falls under the same rules that govern a mainframe from decades past. The encryption standards, the access controls, the audit logging, the personnel screening requirements: none of that changes because the system doing the processing happens to be a neural network instead of a SQL database. Under the policy's own logic, an LLM that reads CJI, a retrieval-augmented generation index built on CJI, and the prompt logs generated by an officer's query all count as CJI-touching infrastructure, regardless of whether the vendor's engineering team thought of it that way when they built the product.

The compliance timeline agencies are currently navigating, including a deadline that already passed

Version 6.0, released December 27, 2024, represents the biggest restructuring of CJIS in more than a decade. It expanded the policy from 13 policy areas to 20 and rebuilt the whole framework around a widely used federal control-family standard, which brought CJIS into closer alignment with how the rest of the federal government thinks about security controls. Version 6.1, dated June 25, 2026, is a corrections release. It folds in the calendar year 2025 changes, including Spring 2025 Advisory Policy Board papers and Security and Access Subcommittee changes approved November 14, 2025. Anyone comparing guidance documents from different years needs to know which version they're reading, because the two are structured differently enough that a control number in v5.9.5 doesn't map cleanly onto v6.1.

The 178 controls in the current structure aren't all being enforced on the same schedule. Only 22 are classified Priority 1, and those became immediately auditable and sanctionable back on October 1, 2024, alongside everything that existed in the policy before modernization. The remaining Priority 2 through 4 controls are what the FBI calls a zero cycle, meaning agencies are expected to work toward them but aren't yet facing audit findings for gaps, running until September 30, 2027.

Then there's the deadline that just passed. September 21, 2026 was the final active day before an older tier of encryption validation certificates moved to the Historical list under the government's certification program for cryptographic testing, as it transitioned to a newer standard. Current FBI CJIS guidance states FIPS 140-2 certificates are no longer acceptable for CJIS purposes after that date. Any agency or vendor still relying on FIPS 140-2 validated encryption modules for CJI protection is, as of this writing, out of step with the policy on cryptography, one of the more mechanical but consequential requirements in the entire document.

The real cliff edge further out is October 1, 2027. That's when the zero-cycle grace period ends and Priority 2 through 4 controls enter normal audit and enforcement treatment, meaning full compliance becomes expected from every agency bound by the policy starting September 30, 2027. Agencies that have spent the past few years treating modernization as a distant deadline have less runway than they think. The FBI has also picked up its release pace: updates are now expected roughly every 6 to 12 months rather than the multi-year gaps of the past. CJIS is no longer a document an agency reads once, files away, and revisits at the next audit cycle. CJIS is no longer a document an agency reads once, files away, and revisits at the next audit cycle; it now changes on a rolling basis.

The technical controls in v6.1 that AI deployments directly implicate

Not all 20 policy areas carry equal weight for an AI deployment. A handful do most of the work, so they're worth walking through individually rather than treating the policy as one undifferentiated wall of requirements.

Access Control, Policy Area 2, built on the NIST AC family, requires least-privilege access: users get only what they need, nothing more, with role-based permissions and periodic access reviews. AI system accounts don't get a pass here. A service account that lets a language model query a records database needs the same scoping discipline as a human analyst's login. Agencies building AI tools have to think about machine identities with the same rigor they'd apply to a new hire.

Identification and Authentication, Policy Area 8, is where multi-factor authentication lives, and MFA is a Priority 1 control, mandatory since October 1, 2024. It was downgraded from "recommended best practice" language in version 5.9.5 to an outright requirement, and that requirement follows the user regardless of interface. Querying CJI through a chat-style AI front end doesn't create some kind of authentication loophole; if a human is accessing CJI, MFA governs that access, full stop.

Audit and Accountability, Policy Area 4, under the NIST AU family, calls for a minimum one-year retention period on audit records and regular review of those logs. For AI systems specifically, that means every model call touching CJI needs to log the model version, the prompt template used, a hash of the input, the output produced, the accessing officer's PIV identifier, and a timestamp, all written into the agency's existing CJIS-compliant SIEM. This is not a small ask for teams used to treating LLM calls as ephemeral and stateless. The FBI CJIS Division audited 52 CSAs in fiscal year 2023, and encryption gaps and inadequate audit logging happen to be exactly the two areas where AI tools introduce the newest and least mature risk. The control families agencies already struggled with before AI showed up are the same ones AI stresses hardest.

Why routing CJI through commercial cloud AI APIs is the most common compliance failure

Most of the actual violations happen here, and it's rarely intentional. An agency or a vendor builds a tool that calls out to a commercial cloud AI API, and CJI ends up in that call as a prompt, a retrieval query, or the body of an API request. The moment that happens, the third-party provider has to meet CJIS requirements itself, because the data is now inside their infrastructure. Almost none of them do.

What counts as "touching CJI" is broader than a lot of engineering teams assume. Any prompt containing CJI counts, regardless of where it appears. CJI pulled into a RAG retrieval query counts. CJI sitting in an API request body counts. A prompt log stored on a vendor's servers, even briefly, counts too. Each of those is CJI being processed by a system outside the agency's authorized boundary, and that's the exact scenario the policy exists to prevent.

As of now, no major commercial LLM API provider has published the specific supplemental agreement the FBI requires from vendors handling CJI. SOC 2 Type II reports get waved around a lot in vendor sales conversations, but SOC 2 is not CJIS compliance, and security documentation that cites SOC 2 without addressing CJIS controls directly doesn't satisfy the policy no matter how thorough it looks. If a law enforcement AI tool is making calls to a commercial LLM with CJI sitting in the prompt, that tool is almost certainly out of compliance the moment it goes live, regardless of how good the model's accuracy is or how much the officers using it like the interface.

There's a data retention wrinkle that makes this worse, not better. When information gets typed into a cloud-based AI system, that data may get stored, processed, or in some cases used to help train future versions of the model, depending on the provider's terms. An accidental paste of CJI into a public AI tool, a mistake that happens when someone's trying to save time formatting a report, can create a genuine violation. One might argue this is an edge case, a slip rather than a systemic failure. But the policy doesn't distinguish between an architectural choice and an accident; CJI leaving the authorized boundary is the violation, regardless of intent.

Deployment architectures and vendor approaches that satisfy CJIS requirements for AI

So what does a compliant setup actually look like? The underlying principle is straightforward even if the engineering isn't, requiring the runtime, the model, and the data all to stay inside the agency's existing CJIS-authorized boundary. Not adjacent to it. Not connected to it through a well-documented API. Inside it.

Deployment model is the first filter to apply to any AI vendor pitch. Public SaaS LLM endpoints, the kind where an agency sends a request out to a shared multi-tenant cloud service, generally violate the policy the moment CJI enters the request. On-premises deployment, or deployment within a government cloud environment that sits inside the agency's authorized boundary, is the path that actually holds up under audit. For workloads that touch CJI, that typically means running open-weight models locally on agency-controlled GPU hardware, kept inside the authorized boundary end to end. Frontier-lab cloud APIs still have a role, but only for workloads that never touch CJI, routed through an agency-controlled proxy that can enforce that separation rather than trusting it to happen by convention.

Getting the deployment model right is necessary but not sufficient. The architecture also has to deliver on the specific controls discussed earlier, and each one maps to a concrete engineering decision. Encryption at rest needs to use FIPS 197 or AES standards, and encryption in transit needs FIPS 140-3 validated modules, both controlled by the agency rather than a vendor's infrastructure team. Audit logs need to be immutable and need to capture model version, prompt, input, output, officer identity, and timestamp, written directly into the agency's own CJIS-compliant SIEM rather than a vendor dashboard. MFA needs enforcement at the point of access to the system itself, not bolted on somewhere outside the authorized boundary where it does nothing for the actual data. Personnel screening applies to any vendor engineer with access to the system, unless the architecture is built specifically to prevent vendor engineers from ever seeing plaintext CJI in the first place, which is the more scalable answer for vendors serving multiple agencies. And supply chain documentation, covered under the agency's Supply Chain Risk Management plan, needs to identify and risk-assess every subprocessor touching the pipeline, including those beyond the primary vendor.

None of this is exotic. It's the same discipline CJIS has demanded of records management systems for years, applied now to a category of tool that a lot of agencies are adopting faster than their compliance teams can review it. The technology is new. The rulebook, as it turns out, was already built to cover it.