The records supervisor had run the report three times before she called the IT director. The query she ran was routine: which vendor personnel had accessed agency body-worn camera (BWC, the recording devices worn by officers on patrol) footage in the last 90 days for the purpose of AI model processing. The answer, when it finally came, was not from the vendor's access log. It came from a legal rider in the contract, page 47, clause 12(c), which stated that the vendor reserved the right to access anonymized incident data for product improvement purposes. The records supervisor had been the agency's CJIS (Criminal Justice Information Services, the FBI's framework governing how agencies handle criminal justice information) compliance coordinator for six years. She knew what that clause meant: the vendor had potentially accessed data governed by CJIS Security Policy, and the agency had no audit trail showing who, when, and under what controls.

Why CJIS Obligations Stay With the Agency

The most important governance fact in this lesson is also the most consistently misunderstood in public-safety AI procurement: CJIS Security Policy obligations stay with the agency, not the vendor. A vendor can certify their systems meet CJIS technical requirements. A vendor can submit to CJIS audits and provide documentation of their compliance controls. What a vendor cannot do is assume the agency's CJIS obligations. The agency remains legally responsible for ensuring that criminal justice information (CJI) is handled correctly at every point in its lifecycle, including within systems operated by the vendor.

This is not a legal technicality. It is the structure of the CJIS Security Policy itself. The FBI's Criminal Justice Information Services Division publishes the CJIS Security Policy, currently in version 5.9.3 as of 2026, which establishes minimum security requirements for access to and protection of CJI. The policy applies to any entity that accesses, processes, stores, or transmits CJI, including state and local law enforcement agencies and their contractors. The critical word is "their." When an agency contracts with a vendor to process CJI through an AI tool, the vendor becomes a CJIS-covered entity by virtue of that access. But the agency's obligation to ensure compliance does not transfer. The agency must verify that the vendor meets CJIS requirements, must audit the vendor's compliance, and must maintain oversight of the vendor's data handling throughout the contract term.

An agency that signs a contract with an AI vendor and treats the vendor's self-certification of CJIS compliance as the end of the agency's obligation has misunderstood the policy. If the vendor's systems fail to meet CJIS requirements and a breach or audit finding results, the agency bears the legal and regulatory consequences. The vendor's certification is evidence that the vendor represented compliance. It is not evidence that compliance existed. The agency's obligation is to verify, not to accept.

The vendor's CJIS certification is a starting point for the agency's compliance verification, not the end of it. The obligation to ensure CJI is handled correctly never leaves the agency.

What CJIS Actually Governs in an AI Deployment

Understanding CJIS compliance in the context of a public-safety AI deployment requires understanding what constitutes CJI and how AI processing pipelines interact with it. The CJIS Security Policy covers a broad range of data categories, including biometric data (fingerprints, facial images, voice recordings), identity history data (criminal records, arrest records), case and incident information, and the systems that store and transmit this information. In a law enforcement AI deployment, CJI typically flows through multiple processing points, and each point is a potential compliance obligation.

The BWC Footage Pipeline

When an officer's BWC footage is uploaded from the camera to the cloud evidence locker, processed through an AI transcription engine, converted to text that is fed into an AI report-drafting model, and the resulting draft is uploaded to the RMS (records management system, the platform storing and managing police reports and case files), each step in that pipeline potentially touches CJI. The footage itself contains biometric data (faces, voices), case information, and information about identifiable individuals who may or may not be involved in criminal activity. The transcription output contains personally identifiable information. The AI draft contains case narrative that will eventually become a sworn report.

At each step, the CJIS Security Policy's requirements apply: access controls (who can access the data and under what conditions), encryption requirements (data must be encrypted in transit and at rest to specific standards), audit logging (access to CJI must be logged with sufficient detail to reconstruct who accessed what data and when), and personnel security requirements (individuals who access CJI must undergo a CJIS-compliant background check). For a multi-vendor or cloud-based AI deployment, each vendor and each system component in the pipeline must meet these requirements, and the agency must verify that they do.

The Model Training Question

The most challenging CJIS question in a public-safety AI deployment is the model training question: does the vendor use the agency's data to train or improve the AI model, and if so, does that use constitute access to CJI that requires CJIS compliance controls beyond the core processing pipeline?

Many AI vendor contracts include a data use clause that permits the vendor to use anonymized or aggregated agency data for product improvement. On its face, anonymization appears to remove the CJIS obligation: if the data no longer identifies individuals, it may no longer constitute CJI. In practice, this analysis is more complex. Anonymization of law enforcement data is not a binary condition. A patrol report that has been stripped of names still contains incident descriptions, location data, call type data, and officer identifiers. In many cases, this data can be re-identified by combining it with other available information. The CJIS Security Policy's requirements apply to data that is linked or linkable to an individual; highly specific incident data may remain linkable even after nominal anonymization.

The agency's CJIS compliance coordinator, in consultation with legal counsel and, where necessary, the relevant CJIS Systems Agency (CSA, the state-level entity that oversees CJIS compliance for local agencies in that state), should conduct a written analysis of whether the vendor's data use clause authorizes access to data that remains subject to CJIS requirements. If it does, the vendor must demonstrate CJIS compliance for the model training pipeline, not only for the operational processing pipeline. Many vendors have not built CJIS compliance controls into the model training environment because they treat model training as separate from criminal justice operations. That distinction does not hold up under a careful reading of the policy if the training data remains linkable to criminal justice information.

Building the Agency-Side CJIS Compliance Program

Because CJIS obligations stay with the agency, the agency must build and maintain a CJIS compliance program that covers the AI deployment specifically, not just the agency's traditional systems. An AI deployment changes the surface area of the agency's CJIS obligation: it adds new data flows, new access points, new processing environments, and new personnel (vendor engineers, data scientists, cloud infrastructure operators) who may access CJI. Each of these changes requires a compliance response.

The CJIS Compliance Assessment for AI Deployments

Before deploying any AI tool that touches CJI, the agency should conduct a written CJIS compliance assessment covering the following elements: a data flow map showing every point at which CJI enters, is processed, is transmitted, or is stored within the AI deployment; an access control inventory identifying every role and every individual (including vendor personnel) who has access to CJI at each point in the data flow; an encryption compliance review confirming that data is encrypted at rest and in transit to CJIS standards at each processing point; an audit log review confirming that access to CJI is logged at each point with the detail required by the policy; a background check verification confirming that all personnel with access to CJI have undergone CJIS-compliant background checks; and a written analysis of any vendor data use clauses that may authorize access to CJI for non-operational purposes.

The assessment should be conducted before the contract is signed, not after deployment. Post-deployment compliance assessments are more difficult because the data flows are already in operation and remediation requires operational disruption. A pre-deployment assessment is the agency's opportunity to identify compliance gaps in the vendor's proposed system, require the vendor to address them before go-live, and document that the compliance obligation was taken seriously from the outset.

The Vendor CJIS Agreement

Any vendor whose systems access CJI must execute a signed CJIS Security Addendum, a document that binds the vendor to the same CJIS compliance requirements as the agency. The CJIS Security Addendum is not optional and it is not a formality. It is the contractual mechanism by which the agency extends its CJIS compliance obligations to the vendor, and it creates a specific legal basis for the agency to audit the vendor's compliance and to terminate the contract if the vendor fails to maintain compliance.

The Security Addendum should be accompanied by a vendor-specific compliance plan that describes: which CJIS controls the vendor is responsible for implementing, which controls the agency retains responsibility for implementing, how the vendor will demonstrate ongoing compliance (through annual audits, real-time access logs, or other mechanisms), what notification protocol the vendor will follow if it identifies a CJIS compliance issue or potential breach involving the agency's data, and how the vendor will handle law enforcement requests (subpoenas, court orders) directed at agency data held in the vendor's system.

Personnel Security in an AI Deployment

One of the most commonly overlooked CJIS compliance gaps in AI deployments is personnel security. The CJIS Security Policy requires that all personnel who access CJI have undergone a fingerprint-based background check through the FBI's Next Generation Identification system. For agency personnel, this is a standard part of the hiring process. For vendor personnel who may access agency data as part of implementation, maintenance, or model improvement work, it is often not.

AI vendors typically employ engineers, data scientists, and cloud infrastructure personnel who are not law enforcement employees and who have not undergone law enforcement-grade background checks. When these personnel access agency data for implementation purposes, model training, or system maintenance, they are accessing CJI, and CJIS requires that their access be restricted to personnel who have undergone the required background checks. An agency that deploys an AI tool without verifying that all vendor personnel with CJI access have met this requirement has a CJIS compliance gap that the agency, not the vendor, is responsible for.

The practical approach is to require in the vendor CJIS Security Addendum that vendor personnel who will access CJI are identified by name and role before any data access begins, that background check documentation is provided to the agency for verification, and that any change to the personnel list (new hires, contractor substitutions) requires advance notification and documentation. This is operationally inconvenient for the vendor. It is required by the policy.

Data Governance Beyond CJIS

CJIS compliance is the floor of the agency's data governance obligation in an AI deployment, not the ceiling. Above the CJIS floor, the agency must address a broader set of data governance questions that AI deployment raises and that no federal policy resolves on the agency's behalf.

Data Retention and the AI Audit Trail

An AI-assisted report-writing deployment creates a new category of data that the agency must govern: the AI audit trail. The AI audit trail includes the original AI-generated draft before officer review and correction, the correction log showing what the officer changed and what the final report reflects, the disclosure documentation showing that AI was used and how the report was reviewed, and the AI model version information showing which version of the AI tool produced the draft.

None of these data types are covered by most agencies' existing data retention policies, because existing policies were written before AI-assisted report writing existed. The agency must write new retention policies that address: how long the original AI draft is retained, whether it is retained indefinitely as part of the case file or for a defined period, how the correction log is stored and whether it is stored in the same system as the final report, how disclosure documentation is generated and retained, and whether the AI model version information is captured as part of the case record or tracked separately.

The Brady and Giglio implications of AI audit trail retention are significant. As previously discussed in this program, Brady v. Maryland (the Supreme Court ruling requiring prosecutors to disclose exculpatory evidence to the defense) and Giglio v. United States (the ruling requiring disclosure of evidence that could impeach a witness's credibility) create disclosure obligations that may extend to the original AI draft. If the original AI draft contained a detail that the officer removed during correction, that removed detail may be exculpatory information the defense is entitled to receive under Brady. If the audit trail shows the officer corrected multiple AI drafts across many cases, that pattern may be Giglio material bearing on the officer's credibility. The agency's data retention policy must be designed with these obligations in mind, not retrofitted after a defense attorney raises them in a specific case.

Third-Party Access and Open Records

AI audit trail data is also subject to open-records and public-records statutes in most jurisdictions. If the original AI draft and the correction log are retained as part of the case file, they may be subject to public-records requests. An agency that retains this data but has not thought through the redaction and release implications may face a public-records request for the AI draft that it was not prepared to respond to.

The questions an agency must answer before data governance decisions are made: Is the original AI draft a public record in this jurisdiction? Is the correction log? Is the disclosure documentation? If they are, what information within them must be redacted before release (officer personnel information, information about third parties captured on footage, information about ongoing investigations), and what must not be redacted (the existence of AI use, the nature of corrections made, the tool version)? The redaction standard for AI audit trail data has not been fully resolved by statute or case law in most jurisdictions as of 2026, which means the agency's legal counsel must develop a position before it is tested in a public-records proceeding.

Bias Auditing and Governance

AI systems trained on historical law enforcement data can encode and amplify existing disparities in how police activity was recorded and described. An AI report-drafting tool trained on historical patrol reports will reflect the language patterns, emphasis choices, and characterization conventions of those reports. If those conventions include systematic differences in how certain communities or individuals were described, the AI tool may reproduce and amplify those differences in its output.

The CJIS Security Policy does not address this risk because it is a security policy, not an equity policy. But the agency's data governance program should include periodic review of AI output for demographic patterns that suggest the tool is reproducing systematic description disparities. This review is not primarily a technical task. It requires comparison of AI-drafted narratives across incident types and community contexts, with attention to whether the characterization language the tool uses for similar incidents varies in ways that correlate with the demographic characteristics of the individuals involved. Agencies that have deployed AI tools at scale and have not built this review into their governance program are running a risk that the CJIS Security Policy does not require them to address but that community trust, civil rights law, and basic fairness require them to manage.

When Things Go Wrong: Breach Response and Incident Protocols

Every agency deploying AI that touches CJI must have a documented breach response protocol that covers the specific failure modes of AI deployments: unauthorized access to CJI through the AI processing pipeline, model training data exposure, vendor data handling failures, and loss or corruption of AI audit trail data. Each of these failure modes has different detection signals, different notification requirements, and different remediation steps.

The CJIS Security Policy requires that the agency notify the relevant CSA and, through the CSA, the FBI CJIS Division when a breach of CJI occurs. The notification must be timely (the policy specifies notification requirements that are strict and non-negotiable) and must include a description of the data involved, the number of individuals potentially affected, and the steps taken to address the breach. For a vendor-side breach involving the agency's data, the notification obligation remains with the agency. The agency must have a documented protocol for receiving breach notifications from the vendor (a requirement that should be in the vendor's CJIS Security Addendum) and for translating those notifications into the required reports to the CSA and the FBI.

Breach response protocols for AI deployments also need to address a scenario unique to AI systems: what happens when the AI model itself is compromised. An AI model that has been tampered with, that has been trained on poisoned data, or that has been subjected to an adversarial attack may produce systematically incorrect output without any obvious breach signal. The detection mechanism for this type of compromise is the agency's ongoing accuracy review and correction-log analysis. A sudden change in the type or frequency of errors in AI-drafted reports, without a corresponding change in the incident types being processed, is a signal that something has changed in the model's behavior, which may warrant investigation of whether the model has been compromised rather than simply updated.

The Governance Document Stack

A complete data governance program for a public-safety AI deployment requires a specific set of documents that the agency must produce, maintain, and be able to produce on demand to an auditor, a prosecutor, or a court. These documents are not optional and they are not merely good practice. For an agency that has deployed AI tools touching CJI, they are the evidentiary record of the agency's exercise of its CJIS compliance obligations.

The governance document stack for an AI deployment includes: the pre-deployment CJIS compliance assessment (showing the agency evaluated the data flows, access controls, encryption, audit logging, and personnel security before deployment), the vendor CJIS Security Addendum (showing the vendor is contractually bound to CJIS compliance), the vendor compliance plan (showing which controls the vendor is responsible for and how compliance will be demonstrated), the AI-specific data retention policy (showing the agency has addressed the retention of AI drafts, correction logs, and audit trails), the AI disclosure policy (showing how officers document AI use in reports and how that documentation is retained), the bias review protocol (showing the agency has a documented process for reviewing AI output for demographic disparities), and the breach response protocol (showing the agency can respond to and report a CJIS breach involving the AI system).

An agency that can produce all of these documents on demand is an agency that has taken its data governance obligations seriously. An agency that cannot produce them is an agency whose AI deployment may be creating CJIS compliance exposure that compounds with each week the deployment operates without documented oversight.

Key Takeaways

• CJIS (Criminal Justice Information Services) Security Policy obligations stay with the agency, not the vendor. A vendor's CJIS certification is a starting point for the agency's verification, not the end of the agency's obligation. The agency must audit vendor controls, not accept self-certification.
• In a public-safety AI deployment, CJI flows through multiple processing points including BWC footage upload, AI transcription, AI report drafting, and RMS storage. Each point carries CJIS compliance obligations for access control, encryption, audit logging, and personnel security that apply to vendor personnel as well as agency staff.
• The model training question is the most challenging CJIS question in an AI deployment: vendor data use clauses that authorize use of anonymized agency data for product improvement may still involve access to data that remains linkable to individuals and therefore subject to CJIS requirements. The agency's CJIS compliance coordinator must conduct a written analysis before execution of any such clause.
• Personnel security is one of the most commonly overlooked CJIS compliance gaps in AI deployments. All vendor personnel who access CJI must have undergone fingerprint-based background checks through the FBI's Next Generation Identification system. The agency must verify this requirement is met for every vendor employee and contractor with CJI access.
• The AI audit trail (original AI draft, correction log, disclosure documentation, model version) is a new data category that existing agency retention policies were not written to address. Brady v. Maryland and Giglio v. United States create disclosure obligations that may extend to the original AI draft, requiring the agency to retain and be able to produce it in discovery.
• AI output must be periodically reviewed for demographic patterns that suggest the tool is reproducing systematic description disparities from historical training data. CJIS does not require this, but civil rights law, community trust, and basic fairness do.
• The governance document stack for an AI deployment (CJIS compliance assessment, vendor CJIS Security Addendum, vendor compliance plan, AI data retention policy, AI disclosure policy, bias review protocol, and breach response protocol) is the evidentiary record of the agency's exercise of its compliance obligations. It must be produced and maintained before deployment, not assembled in response to an audit finding or a court order.
• Breach response protocols for AI deployments must address vendor-side breach notification as a contractual requirement, the agency's CJIS notification obligations to the relevant CJIS Systems Agency and the FBI, and the unique AI failure mode of model compromise, which may be detectable only through the ongoing accuracy review and correction-log analysis rather than through conventional breach detection signals.