CJIS-Compliant AI: Deploying AI on Criminal Justice Data

Any AI system that touches Criminal Justice Information is in scope for the FBI's CJIS Security Policy — there is no AI exemption, and the same encryption, access-control, audit, and personnel-screening controls that govern a records management system govern your LLM, your RAG index, and your prompt logs.

Public-safety agencies want the same things every enterprise wants from AI: faster report drafting, smarter records search, better triage. But criminal justice data is regulated at the federal level, and a single careless design decision — a prompt logged to a third-party API, an embedding store outside a physically secure boundary, an unscreened contractor with cleartext access — turns a productivity win into a policy violation and an audit finding. Gain America staffs and deploys the engineers who build these systems inside the boundary from day one: forward-deployed AI engineers, MLOps teams, and public-sector-ready talent who treat CJIS controls as architecture, not paperwork.

What the CJIS Security Policy covers and why AI gets no exemption

The Criminal Justice Information Services (CJIS) Division of the FBI publishes the CJIS Security Policy, the binding baseline that every state, local, tribal, and federal agency — and every contractor acting on their behalf — must meet to access CJI. CJI includes criminal history records, fingerprint and biometric data, computerized criminal history (CCH), and derived data from systems like NCIC and III. The policy is organized into policy areas covering access control, identification and authentication, encryption, auditing and accountability, personnel security, incident response, and configuration management, and the current v6.0 baseline maps tightly to NIST SP 800-53 controls.

The critical point for AI teams is scope. CJIS attaches to the data, not the application category. If CJI flows through a system, that system inherits CJIS obligations regardless of whether it is a mainframe, a mobile app, or a large language model.

CJIS does not have an "AI mode." A retrieval-augmented generation pipeline that indexes arrest records is a CJI system. A summarization endpoint that receives a rap sheet in its prompt is a CJI system. The controls follow the data.

That reframing matters because AI introduces data paths that traditional systems never had: prompts, completions, embeddings, retrieval stores, evaluation datasets, and model telemetry. Each is a place CJI can land, and each must be treated as an in-scope CJI store.

Where CJI shows up in public-safety AI: RMS, predictive policing, and pretrial risk

CJI surfaces in nearly every high-value public-safety AI use case:

• Records management (RMS) copilots that draft incident reports, summarize case files, or answer natural-language questions over historical records pull directly from CJI-laden systems.
• Records and evidence search built on enterprise RAG architecture that indexes criminal histories, field interviews, and case narratives into a vector store — turning that store into a CJI repository.
• Predictive and analytics tooling that ingests historical incident and arrest data to surface patterns.
• Pretrial risk and decision-support tools that consume criminal history to inform recommendations, where both the input data and the audit trail are sensitive.

In every one of these, the AI layer is not a bystander. It reads CJI, transforms it, caches it, and often logs it. Agencies frequently discover in an audit that their "AI feature" quietly created three new copies of CJI — in the retrieval index, in the model's context cache, and in an observability platform — none of which were designed as CJI stores. The reasons public-sector AI projects fail are rarely the model quality; they are these unmanaged data paths.

LLM and RAG data-handling risks: prompt logs, retrieval stores, and model hosting

Three AI-specific risk surfaces cause the most CJIS trouble.

Prompt and completion logs. Most LLM platforms log inputs and outputs by default for debugging, safety, and abuse monitoring. When the input is CJI, those logs are CJI stores — often replicated to regions and third parties an agency never authorized. Any AgentOps observability stack must be configured so traces, prompts, and completions containing CJI stay inside the CJIS boundary, encrypted and access-controlled, never shipped to a general-purpose SaaS analytics tier.

Retrieval stores and embeddings. Embeddings are derived from CJI and, in practice, can leak the underlying content; they must be treated as CJI and encrypted with FIPS 197 (AES) when stored outside a physically secure location. The retrieval database, its backups, and its snapshots are all in scope.

Model hosting. This is the decisive architectural choice. Public LLM APIs typically retain data, route it across jurisdictions, and have not executed a CJIS Security Addendum — so sending real CJI to them violates policy. The defensible pattern is to self-host open models or use CJIS-eligible government cloud model endpoints where the agency controls the boundary. The RAG-versus-fine-tuning decision carries its own CJIS weight: fine-tuning bakes CJI into model weights, which then must be protected and access-controlled as a CJI artifact for the life of the model.

Access control, encryption, personnel screening, and audit for CJIS AI

Four control families do the heavy lifting for AI systems.

Access control and authentication. CJIS requires multi-factor authentication for CJI access, and MFA became fully auditable and sanctionable as of October 1, 2024. Authenticators must meet FIPS 140 requirements, phishing-resistant methods are preferred, and re-authentication is required at least every 12 hours and after 30 minutes of inactivity. For AI, this means the RAG UI, the model endpoint, the vector store admin console, and the pipeline's service accounts all sit behind compliant authentication — human and machine identities. This is where agentic AI security becomes a CJIS problem: an agent that autonomously queries CJI needs a scoped, auditable identity, not a shared key.

Encryption. FIPS 140-validated modules for CJI in transit; FIPS 197 (AES) for CJI at rest outside a physically secure location, with AES-256 the expected standard. If the agency retains sole control of encryption keys and CJI stays encrypted in transit, at rest, and in use, screening requirements for some cloud personnel may be reduced — a meaningful design lever for gov-cloud deployments.

Personnel screening. Anyone with access to unencrypted CJI must pass fingerprint-based state and national background checks and complete CJIS Security Awareness Training. For AI delivery, that includes the engineers who debug pipelines against real data, the MLOps staff who manage the model host, and any contractor who can view retrieval results.

Auditing and accountability. CJIS requires comprehensive audit logging of CJI access, retained for at least one year, with regular review. An AI system must therefore log who asked what, what CJI was retrieved, and what the model returned — and that audit trail is itself CJI that must be protected. Building this into agent evals and production monitoring from the start is far cheaper than retrofitting it after an audit finding.

The fastest way to fail a CJIS audit with an AI system is to build it like a commercial SaaS product first and bolt on compliance later. The data paths multiply faster than the controls.

On-prem and gov-cloud hosting patterns for CJIS AI

There are two defensible deployment patterns, and the on-prem versus cloud AI deployment tradeoff maps cleanly onto CJIS boundaries.

On-premises / agency-controlled. Self-hosted open-weight models running inside the agency's physically secure, CJIS-audited data center keep CJI from ever leaving the boundary. This is the strongest posture and often the simplest to defend in an audit, at the cost of standing up and operating GPU inference infrastructure and a private model-serving stack.

CJIS-eligible government cloud. AWS GovCloud (US) and Azure Government both support CJIS workloads and will execute CJIS Security Addendums, giving agencies FedRAMP High and CJIS-aligned environments without owning hardware. The pattern is to run inference on isolated gov-cloud model endpoints, keep the vector store and logs inside the same boundary, control encryption keys, and ensure an Addendum is in place for every state whose CJI the system touches — cross-jurisdiction data sharing is a common audit gap. This layers naturally on the same FedRAMP compliance controls and, at the state level, StateRAMP and GovRAMP alignment that broader government AI deployment programs already require.

The wrong pattern — routing CJI to a public commercial LLM endpoint and hoping a data-processing addendum covers it — is not CJIS-compliant regardless of the vendor's other certifications.

Staffing engineers who understand public-safety data constraints

CJIS-compliant AI is not a product you buy; it is a delivery discipline. The gap most agencies hit is talent: teams that can build a great RAG assistant but have never designed to keep CJI inside a FIPS-encrypted, audited, MFA-gated boundary — and vendors who understand CJIS on paper but cannot ship a production model-serving stack. Closing that gap is exactly the enterprise AI talent problem, sharpened by a federal security baseline.

This is where Gain America operates. We staff and deploy the engineers behind public-sector AI — forward-deployed AI engineers who embed with an agency and design the system inside the CJIS boundary from the first commit, plus MLOps and data-center teams who run compliant model hosting. Our public-sector delivery model, detailed in forward-deployed engineers for government, pairs engineers who can build LLM and RAG systems with the discipline to keep CJI encrypted, logged, access-controlled, and audit-ready. For agencies weighing whether to build the capability internally or bring it in, the staff-augmentation-versus-hiring analysis usually favors embedded specialists for a first CJIS-scoped deployment, precisely because the cost of a policy violation dwarfs the cost of the right engineer.

The agencies that succeed treat CJIS not as a blocker but as the specification. Every control — encryption, screening, audit, boundary — is a design requirement you can meet with the right architecture and the right people building it.