CJIS Doesn't Have an AI Chapter Yet. Public Safety Tech Vendors Need One Anyway.

If you're building tech for public safety agencies and your AI governance framework is a separate document from your CJIS compliance program, you have a gap your next audit is going to find.

The CJIS Security Policy is one of the most demanding regulatory frameworks any vendor selling to law enforcement has to satisfy. It governs how Criminal Justice Information is stored, accessed, transmitted, and disposed of. The current version is detailed across encryption, identity management, physical security, personnel screening, and incident response.

What it does not yet have is a dedicated section on artificial intelligence and machine learning. There is no "Chapter 5.X: Generative AI and Machine Learning" telling vendors what is in scope when their product uses an LLM to summarize body-cam footage, runs inference on license plate data, or assists with evidence triage. The policy is being updated. The AI section is not there yet.

This is creating a quiet crisis for public safety tech vendors.

What AI looks like in public safety tech right now

The vendors selling to law enforcement and public safety agencies have been quietly building AI into nearly every product line over the past two years. A non-exhaustive list of where AI is now operating on Criminal Justice Information:

• Body-camera analytics. LLM-based summarization of long body-cam clips. Automatic redaction of bystanders, license plates, and minors. Tagging of behavioral cues for review. Translation of multi-language audio.
• License plate recognition. ML-based plate matching against hot lists. Computer vision for partial-plate inference. Anomaly detection on travel patterns.
• Evidence triage and management. AI-assisted prioritization of digital evidence in major cases. Audio enhancement and transcription. OCR-plus-summarization for document caches seized in investigations.
• Computer-aided dispatch. ML-driven call prioritization. Predictive resource allocation. Anomaly detection on dispatch patterns.
• Records management systems. Search ranking using LLMs. Automatic incident report generation from voice notes.
• Predictive analytics. Crime trend forecasting. Officer wellness pattern detection. Use-of-force review aids.
• Court technology. Real-time transcription. Translation services for non-English speakers. Document analysis for discovery review.

Every one of these touches Criminal Justice Information. Every one of them is therefore in scope for CJIS. And every one of them is currently being deployed by vendors who, when asked "what does your AI governance program look like?", point to a separate document maintained by a separate person from the CJIS compliance lead.

The two wrong approaches vendors take

When the AI capabilities started shipping faster than the regulatory frameworks could keep up, public safety tech vendors fell into one of two patterns. Both are wrong.

Approach 1: Treat AI as "just another feature" inside the existing CJIS controls

The thinking here is straightforward. CJIS Security Policy covers data at rest, data in transit, access controls, audit logging, and incident response. AI is just another consumer of that data. So if the existing CJIS program is solid, the AI features should be covered by default.

This approach quietly hopes that auditors will not ask the next set of questions. Questions like: "When your LLM summarizes a body-cam clip, where does the inference run? On your servers? In a cloud AI service? Does the model see the full clip or a transcript? What happens to that intermediate data? Is it retained? Does it train your model? Does it train someone else's model?" The CJIS controls do not specifically address any of these questions because they were written for a world where the data was processed by deterministic software, not stochastic models.

When auditors start asking these questions, and they are starting to, the "just another feature" approach has no specific answers.

Approach 2: Spin up a parallel AI governance program

The thinking here is also reasonable. AI is genuinely new. It deserves its own governance approach. NIST has the AI Risk Management Framework. ISO has 42001. Multiple states are passing AI-specific laws. So vendors stand up a separate AI Governance Committee, write separate AI policies, run separate AI risk reviews, and maintain a separate AI audit trail.

The problem is that the people running this parallel program are usually not the people running the CJIS compliance program. The AI committee includes the data science leads, the product manager, maybe legal, maybe a security architect. The CJIS committee includes the operational compliance lead, the security operations team, and the agency liaison.

These two committees rarely talk. They produce two different sets of documents that drift apart over time. And when an auditor asks "how does your AI governance integrate with your CJIS program?", the answer is usually a long pause followed by the realization that nobody owns the integration.

The question auditors are starting to ask

I spent 13 years in law enforcement before I went into cybersecurity. I have sat on the agency-buyer side of the table for vendor reviews and on the cyber side for audit defense. The audit teams in this space are not adversarial. They are usually understaffed people trying to verify that vendors are doing what they said they would do.

The question they are starting to ask is straightforward: "Where does the criminal justice information go when your AI processes it?"

That single question maps to a chain of follow-ups:

1. What Criminal Justice Information does the AI feature consume?
2. Where is the inference happening (on-premise, private cloud, public AI API)?
3. Is the data logged as part of the AI request and response?
4. Is the model retraining on the inputs?
5. Are the prompts, completions, or intermediate states stored anywhere?
6. Who has access to those stored records?
7. Are those records subject to the same retention and destruction policies as the underlying CJI?
8. Are vendor sub-processors (such as your AI API provider) covered by your existing CJIS agreement?

A vendor with one integrated CJIS-plus-AI program can answer these questions in sequence. A vendor with two parallel programs has to call two different teams, neither of which has the full picture.

A five-point CJIS plus AI integration framework

The fix is not a new program. It is a small set of explicit integration points that connect your existing CJIS compliance work to the AI capabilities you have already shipped.

1. Document the AI data flow against your CJI inventory

Take your existing Criminal Justice Information data inventory. For every AI feature in your product, draw the line from CJI input through model processing to output and any persisted state. Identify the owners at each step. This document is the single artifact that ties your AI governance to your CJIS program.

2. Map every AI use case to specific CJIS controls

For each AI feature, write down which CJIS Security Policy sections apply. Encryption at rest. Audit logging. Personnel security. Cloud and managed services. Make this mapping explicit. Your audit team will thank you. The auditor will see that the integration is intentional.

3. One governance committee, not two

The AI governance committee and the CJIS compliance committee should be the same committee, with the data science lead and the operational compliance lead both at the table. If they cannot be the same, they must meet jointly at least quarterly with a written agenda that explicitly covers AI feature additions and changes.

4. Audit-ready logging from day one

Every AI inference touching CJI should log: input identifier (not the input itself), model version, output identifier, timestamp, requesting user, downstream action taken. This is not optional. It is the only way to answer the "where did the CJI go" question with evidence rather than assertion.

5. Vendor sub-processor clauses for your AI providers

If you use a public AI API (OpenAI, Anthropic, AWS Bedrock, Google Vertex), you have a sub-processor handling CJI. Your CJIS agreement with the agency must reference that sub-processor explicitly. The sub-processor must contractually meet the CJIS requirements your agency holds you to. This is the question that catches most vendors flat-footed.

Why this matters for sales cycles

Public safety agencies are increasingly asking AI-specific questions during procurement. The vendors who can answer them in detail, with documented integration to their existing CJIS program, are winning the deals where AI capability is part of the evaluation criteria. The vendors who fumble the answer or send the buyer to two different teams are losing.

This is not theoretical. Sheriff's offices, state police agencies, and federal partners are all building AI-readiness checklists into their procurement processes. A vendor whose answer is "we have a separate AI governance document and our CJIS program is over here" is signaling that they have not done the integration work yet. The vendor whose answer is "here is our CJI data flow with our AI features mapped against the relevant CJIS controls, audited last quarter" is signaling competence at the level the agency actually needs.

The gap is going to close. The question is whether you close it before your next agency renewal asks about it, or after.

Fractional CTO and CISO leadership for companies putting AI to work: strategy, governance, cost control, and risk in business terms. Our team has led cyber defense, compliance, and risk programs for 20+ years across 6 countries and multiple industries, including healthcare, fintech, retail, manufacturing, telecom and consulting, and delivered large-scale security and compliance programs at Accenture, Dell, EY, Booz Allen Hamilton and AT&T. Technology and security leadership in one seat, reported in business terms. Talk to us.