What CJIS Actually Requires When AI Touches Criminal Justice Data

The CJIS Security Policy does not use the word AI. No section tells you whether a transcription model, a retrieval pipeline or a case-summarization tool is permitted, and that silence is where the confusion starts. It is also the answer. Nothing in the policy grants AI an exemption, so the moment criminal justice information passes through a model, the control families that govern any other system holding CJI apply to that model, to the hardware serving it, to the index it retrieves from, and to the logs it writes.

Everything below cites CJIS Security Policy v6.1, dated 06/25/2026, by control identifier. The policy is modular and revised often, so check the control text against the version your CJIS Systems Agency is auditing against before you quote it in a solicitation.

The useful question is therefore not whether a tool is approved for CJIS, because no such status exists. It is whether personnel screening, encryption, access control, auditing, physical protection and incident response stay satisfiable once a model sits in the data path, a question the wider guide to running AI inside infrastructure you control puts in architectural context. Some AI designs satisfy those controls without much strain. Others break them quietly, and the break surfaces during an audit, at the point where somebody asks who saw a particular record and the system cannot say.

What counts as CJI, and when an AI feature starts touching it

CJI covers information originating from or derived from the FBI CJIS systems and the state systems connected to them, with criminal history record information the most tightly held subset and biometric, identity, biographic, property and case data around it. Agencies usually have a clear mental model of CJI while it sits in the records management system and a fuzzier one once it has been copied, transformed, summarized or indexed. AI transforms constantly, so it produces derived copies at every step.

The last two rows escape boundary drawing most often, because the vector index and the prompt log get provisioned by whoever stands up the AI service rather than by whoever governs CJI. On the vector index the research settles the argument. Vec2Text recovered 92% of 32-token passages exactly from their embeddings, and against clinical notes it recovered 94% of first names and 95% of last names. The attack needs query access to the same embedding model and falls away as passages get longer, so it is bounded rather than total. It is still more than enough to make a vector store built from case files a copy of those case files, and names extracted from criminal justice records at those rates are CJI under any reading of the policy.

The policy anticipates the derived-data problem in its own words. SC-28 states that "metadata derived from unencrypted CJI shall be protected in the same manner as CJI", which is the sentence to put in front of anyone arguing that an index of vectors is merely metadata.

Personnel screening covers everyone who could reach unencrypted CJI

The policy's personnel security requirements attach to access to unencrypted CJI, and that phrasing does the work. They are not limited to sworn officers or to named users of the records system. They reach contractor and vendor personnel, and the instrument that binds them is the CJIS Security Addendum, described in the policy as "a uniform addendum to an agreement between the government agency and a private contractor, approved by the Director of the FBI, acting for the U.S. Attorney General, as referenced in Title 28 CFR 20.33 (a)(7)". Only the FBI can modify it, and every private contractor performing criminal justice functions signs its certification page.

The screening requirement is PS-3, and it is more specific than most summaries suggest. State-of-residency and national fingerprint-based record checks are both required, with the national check conducted "pursuant to an FBI approved authority such as a federal statute or a state statute approved pursuant to Public Law 92-544". Where any criminal history record exists, access is withheld pending review. Where "a felony conviction of any kind exists, the agency shall deny access to CJI", subject only to a variance the agency may request on severity and elapsed time. PS-3 also requires the agency to maintain a list of everyone authorized unescorted access to unencrypted CJI and to hand that list to the CSO on request, which is a question worth asking a vendor directly: are your engineers on it?

Training is AT-2, which requires security and privacy literacy training "as part of initial training for new users prior to accessing CJI and annually thereafter", plus retraining within 30 days of a security incident for those involved. States differ in how strictly they read the same clauses, so your CSO's office is the authority here rather than any vendor's compliance page.

For an AI deployment, the set of people who can reach unencrypted CJI is larger than the set of people who log in. Whoever installs and patches the inference server can reach the process holding the model and whatever is in its memory. The support engineer who opens a remote session to debug a failing transcription job sees the audio or the transcript. Whoever administers the vector database can query it directly, outside the permission logic the application applies. An engineering team that receives crash dumps receives fragments of whatever was in memory when the crash happened.

This is where an offshore support or engineering model stops being a contract question and becomes a location question. SC-28 sets the geographic rule directly, and it is worth quoting rather than paraphrasing because the paraphrases circulating in procurement documents get it wrong. Storage of CJI "regardless of encryption status, shall only be permitted in cloud environments" that "reside within the physical boundaries of APB-member country" and are "under legal authority of an APB-member agency". The policy names those as the United States, US territories, Indian Tribes and Canada, with the Royal Canadian Mounted Police among the authorized agencies. Canada is inside the boundary, which surprises people who have been told the rule is United States only. Everywhere else is outside it, so a support organization staffed beyond that boundary cannot hold standing access to a system containing CJI, whatever the contract says about confidentiality. Two answers work. Either the vendor staff who can reach CJI are screened and adjudicated under the addendum, or no vendor staff can reach a running production system without an agency-approved, time-bound grant that is logged.

A vendor that answers that question with an assurance about employee trustworthiness rather than a description of an access mechanism has told you what you needed to know. The security questionnaire for AI vendors has the fuller version and the answers that should concern you.

Encryption in transit and at rest, and who holds the keys

The encryption requirement is one of the less ambiguous parts of the policy, and it now carries a deadline. SC-13 requires "cryptographic modules which are Federal Information Processing Standard (FIPS) 140-3 certified, or a FIPS validated algorithm for symmetric key encryption and decryption (FIPS 197 [AES]), with a symmetric cipher key of at least 256-bit strength for CJI in-transit", and states plainly that "FIPS 140-2 certificates will not be acceptable after September 21, 2026." SC-28 sets the matching requirement at rest for CJI outside physically secure locations, again at FIPS 140-3 with a symmetric key of at least 256-bit strength. So what you are checking is that the module carries a current validation certificate you can cite by number, and that the certificate is a 140-3 one or on a documented path to becoming one before that date. Any implementation can name an algorithm.

For an AI system the work is in covering the stores nobody drew on the architecture diagram. The source video is usually encrypted because it is obviously evidence, while the transcript cache, the vector database, the scratch directory a transcoder writes decoded frames into, the prompt log and the generated-output store are equally CJI at rest. Scratch space deserves a specific check, since media pipelines routinely write intermediate files to local disk and that volume is often the one nobody encrypted. The policy is more permissive about CJI held inside a physically secure location, which is part of why an on-premises deployment in a controlled area has an easier time here, though the obligation becomes a physical security one rather than disappearing.

Key custody is a separate question from encryption, and it decides how much the encryption is worth. If a hosting provider or a software vendor holds keys that can decrypt CJI, the data is not meaningfully outside their reach whatever the storage configuration says. Ask who can use the keys rather than who stores them, since a key in a vault that a vendor service principal is authorized to call is a key the vendor can use.

The policy attaches a concrete consequence to getting this right, which is the strongest practical argument for holding your own keys. Its worked example of an infrastructure-as-a-service deployment describes an agency that "maintains sole access to the encryption keys", and concludes that because "cloud service provider personnel have no logical or physical access to any information system resulting in the ability, right, or privilege to view, modify, or make use of unencrypted CJI", no fingerprint-based background checks are required for that provider's staff. Key custody is therefore not only a security control. It is what determines whether an entire population of vendor personnel falls inside PS-3 or outside it, which is a cost and schedule question as much as a compliance one.

Audit logging when the access event is a retrieval

Auditing is where AI systems most often fail a policy written for databases. The requirement is that access to CJI is recorded, that the record shows who did what, when, and from where, and that logs are kept. AU-11 puts the floor at "a minimum of one (1) year or until it is determined they are no longer needed for administrative, legal, audit, or other operational purposes", and its discussion explicitly ties retention to FOIA requests, subpoenas and law enforcement actions, which for an AI system means the log has to outlive the case rather than the fiscal year. The difficulty is that the policy's model of an access event assumes a person opened a record, and in a retrieval-augmented system nobody opened anything.

A user asks a question in plain language. The system embeds it, searches an index, pulls back passages drawn from case files the user may never have opened, assembles them into a prompt, and returns an answer that names none of its sources unless it was built to. If the audit trail says only that a user ran a query at a given time, the agency cannot answer the question an auditor or a defense attorney will ask, which is which records were disclosed and to whom.

A retrieval log that meets the intent of the policy records the requesting user, the query as submitted, every passage the retrieval step returned, the subset that actually entered the model's context, the model and version that generated the answer, the answer itself, and the timestamp. Two properties matter as much as those fields. The log has to be tamper-evident, so that alteration is detectable rather than merely discouraged, and it has to export into the agency's own audit tooling rather than living inside a vendor console.

The related control that gets missed is authorization at retrieval time. An index built once under an administrator's permissions will serve passages from sealed, juvenile, expunged or otherwise restricted records to any user whose question happens to match them. Retrieval has to be filtered by the requesting user's rights at the moment of the query, and the index has to stay in step with the source system as records are sealed, expunged, reclassified or destroyed. An agency that cannot describe how that filtering works has not finished evaluating the system.

Where the processing may physically occur

Processing location is the requirement that most often forces a deployment decision, because it is the one an architecture cannot argue its way around. Under SC-28, cloud storage of CJI is permitted only inside an APB-member country and under the legal authority of an APB-member agency, on infrastructure the agency has authorized, administered by screened personnel. A model API hosted outside that boundary is prohibited outright. Where the endpoint is hosted domestically, the provider becomes a party with access to CJI, which brings the addendum, screened staff, agency audit rights, and written commitments on retention and on training. Most general-purpose model providers will not accept those terms for a single agency.

That leaves two workable shapes. Processing runs inside the agency's own boundary, on-premises or in a private cloud tenant it controls, or it runs in a government cloud region under an agreement that supports the policy. The choice usually comes down to whether the agency wants to own hardware and patching, and private cloud digital evidence management for law enforcement works through that tradeoff for evidence workloads.

VIDIZMO is CJIS Security Policy-aligned, which in precise terms means the agency holds the CJIS compliance obligation and VIDIZMO's controls support it. In on-premises and air-gapped deployments, all AI processing stays inside the agency boundary, with generation running against self-hosted models on agency hardware rather than an external API, and Microsoft Azure Government supports CJIS-aligned hosting for agencies that prefer a government cloud to their own racks. Audit logs are held in append-only Azure SQL ledger tables that are tamper-evident, so any modification is cryptographically detectable, and are archived under a locked time-based WORM retention policy. VIDIZMO staff hold no standing access to customer environments, with break-glass access only, time-bound, MFA-enforced and logged.

How these requirements turn into an authorization boundary on a diagram, and what an assessor expects to see documented, is the subject of the sovereign AI compliance architecture guide.

Why no vendor holds a CJIS certification

Because no body issues one. The FBI CJIS Division publishes the policy and audits the state CJIS Systems Agencies, and the CSAs audit the agencies beneath them. Nobody in that chain certifies a product. What the policy establishes instead is an audit obligation flowing downward: contractors performing criminal justice functions "shall be subject to the same extent of audit review as are local user agencies", and agencies must "at a minimum, triennially audit all external service providers which have access to the information system in order to ensure compliance with applicable statutes, regulations, and policies". A vendor is therefore a component of the agency's environment, audited on a three-year cycle as part of it. That is why the obligation never transfers, and why a certification badge for this policy describes something that does not exist. Put the triennial audit obligation in the contract, because it is yours to perform and the vendor has to be contractually willing to submit to it.

What an agency should require instead is evidence at the level of individual controls. Ask for a mapping that states, control family by control family, which requirements the product satisfies, which the agency retains, which the two share, and which are inherited from a hosting provider. Ask for a signed Security Addendum and the list of individuals it covers. Ask for the independent evidence the vendor does hold, such as an ISO 27001 certificate with its number and scope, a penetration test summary, a documented patching cadence, or the audit report covering the cloud region in use. Ask for a written inventory of every outbound connection the deployed system makes.

Requirement language you can lift

Adapt the wording to your CSA's terminology and drop it into a solicitation.

1. All processing of criminal justice information, including transcription, optical character recognition, embedding generation, retrieval and model inference, shall occur on infrastructure located within the physical boundaries of an APB-member country and under the legal authority of an APB-member agency as required by CJISSECPOL SC-28, and inside the authorization boundary approved by the agency, with no transmission of CJI or CJI-derived content to any external model provider or third-party API.
2. The vendor shall execute the CJIS Security Addendum and shall ensure that every individual with logical or physical access to unencrypted CJI, including support engineers, administrators of inference and vector storage hosts, subcontractor personnel, and anyone able to receive diagnostic bundles from the deployed system, has completed state-of-residency and national fingerprint-based record checks adjudicated by the agency or its CJIS Systems Agency under CJISSECPOL PS-3, holds current literacy training under AT-2, and appears on the access list PS-3(a)(7) requires the agency to maintain.
3. All CJI shall be encrypted in transit and at rest using cryptographic modules certified under FIPS 140-3 with a symmetric cipher key of at least 256-bit strength as required by CJISSECPOL SC-13 and SC-28, noting that under NIST's Cryptographic Module Validation Program FIPS 140-2 certificates shall not be accepted for new deployments after 21 September 2026, and the vendor shall state in writing which party holds the decryption keys and which parties are technically able to use them.
4. The system shall record an auditable event for every access to CJI, including retrieval performed by AI components on a user's behalf, identifying the requesting user, the records or passages returned, the timestamp, and the model and version that produced any generated output, and shall retain those records for no less than the one-year minimum in CJISSECPOL AU-11, or longer where needed for legal or investigative purposes, in a tamper-evident store exportable to the agency's audit system.
5. Retrieval and generation shall enforce the requesting user's access rights at query time, including sealing, expungement, juvenile restrictions and case-level need-to-know limits, and the index shall be resynchronized with the source system whenever a record's status changes.
6. The vendor shall document every outbound network connection the deployed system makes, including telemetry, license validation, model and container updates and crash reporting, and shall provide a supported configuration in which the system operates with all outbound connections disabled.

Writing a defensible requirement rather than a checkbox

A checkbox asks whether a vendor meets a policy that certifies nobody, and any vendor can answer it yes. A defensible requirement names the control, names the evidence that proves it, names the party who carries it, and names how it will be demonstrated. That last split matters most, because at audit the agency has to show which controls it holds itself, which the vendor holds, which the two share, and which are inherited from a hosting provider. A requirement written without it produces a contract where every party assumes somebody else did the work.

Two failure modes are worth guarding against in opposite directions. Under-specifying produces a requirement that a general-purpose cloud AI service can answer yes to, because the question never asked where inference happens or what the logs contain. Over-specifying costs money for nothing, and the common form is demanding an air-gapped deployment where a government cloud region would satisfy the obligation, which then buys a manual update process and an offline model evaluation burden nobody scoped. Write to the obligation you actually carry, confirm the reading with your CJIS Systems Agency before the requirement goes out, and ask for the evidence rather than the adjective.

The last piece of advice is procedural. Put the audit questions into the evaluation rather than the contract annex, and make the vendor demonstrate them on a running system. Ask it who accessed a specific record last month, and ask which model version produced a summary now attached to a case. A system that answers both on screen has told you more about its fitness for CJI than any document it could send you.