If AI Is Built Into Public Safety Software, Vendors Should Have to Say So

I’m not sure what I expected going into Government Technology’s AI Is Here. Is Your CJIS Data Strategy Ready? webinar. It was aimed more at public safety agencies than vendors, but I still found it valuable. It made me look at the same questions from the vendor side.

Morgan Wright moderated the discussion with Gerard Gallant , founder and CEO of 2G Advisory, and Ryan Reynolds , State and Local Government Verticals Leader at AWS. AWS sponsored the webinar.

AI is already present in more systems and applications than many agencies realize. It may look like search, summarization, transcription, data entry, or a workflow improvement in the background.

The current FBI Criminal Justice Information Services (CJIS) Security Policy, version 6.1 is written to be independent of specific device or architecture choices. In practical terms, it is technology agnostic. It does not include a dedicated section for generative AI, and I am not sure it needs one.

The way I understand it, AI does not change CJIS, and CJIS does not become a different policy because AI is involved. AI is another component that may process, transmit, or store criminal justice information (CJI). At the end of the day, the questions are familiar: Where is the data? Who can access it? Is it encrypted? What gets logged and retained? Can the answers be audited? AI may make the data path harder to see, but the obligation to secure and audit CJI remains the same.

CJIS does not require GovCloud

One misconception I hear fairly often is that CJIS requires GovCloud. It does not. The policy explicitly accounts for government and commercial datacenters. The architecture and its controls matter more than the cloud label.

Commercial cloud is not automatically compliant, though. Under control SC-28, cloud storage of CJI is limited to what the policy calls an Advisory Policy Board (APB)-member country: the United States, U.S. territories, Indian Tribes, and Canada. Agencies and vendors must account for CJI and derived data wherever it is stored or copied, including prompts, logs, embeddings, and backups. State laws, local policies, agency rules, and contracts may be stricter.

For a commercial cloud deployment, I would expect at least these basics:

• Map and constrain every location where CJI or derived data is processed or stored, including prompts, logs, replicas, and backups.
• Encrypt CJI in transit and at rest, control the keys, and restrict access using least privilege and required authentication. Provider personnel who can access unencrypted CJI may also face screening, training, and agreement requirements.
• Generate, protect, retain, and review the required logs. Maintain workable incident response and data destruction processes, and support required compliance audits.

That is a starting point, not a complete checklist. The applicable CSA, state, agency, and contract requirements still have to be evaluated. In other words, the normal CJIS work still applies.

The webinar also included an informal attendee poll about whether agencies have a unified strategy connecting AI adoption and CJIS compliance. About 48% selected “no strategy yet,” while only 9% reported having a documented and adopted strategy. No sample size or audience makeup was published, so it is only a directional signal.

Trust is not a control

I submitted a question asking whether public safety software companies should disclose AI use or agencies should assume it is present.

The panel advised agencies to make that assumption, ask vendors where AI is used, and understand the risk. That is good operational advice.

I don’t think it can be the entire answer, though. Trust is not a control. A vendor saying it uses AI safely is not the same as showing where the data goes, who can access it, and what prevents inappropriate access.

The question also points back toward vendors, including my own industry: Are we disclosing this clearly enough? An agency should not have to dig through a product before learning that CJI is being sent through a feature that uses AI. “You should have asked” is not convincing after an incident.

Vendors are in the best position to know what they built, which providers are involved, and when that architecture changes. Disclosure should start with them.

What I would expect a vendor to disclose

At a minimum, I think an agency should be able to get clear written answers to three groups of questions:

• What is using AI? Identify the feature, what it does, whether it is optional, and which model or outside provider supports it.
• What happens to the data? Explain whether the feature handles CJI, prompts, outputs, logs, embeddings, or other retained data; where processing and storage occur; whether the model owner, provider, or their personnel can access it; and how long it is kept.
• What changes after purchase? Explain how customers can disable the feature and how they will be notified if the model, provider, location, retention rules, or other material behavior changes.

That information affects procurement, security reviews, audit evidence, incident response, and sometimes whether an agency can use the feature at all. The NIST AI Risk Management Framework can help agencies organize their governance and risk questions, but a framework cannot supply details that only the vendor knows.

Requiring disclosure does not prevent vendors from adding useful AI capabilities. It gives agencies enough information to make an informed decision and enough time to review changes before they affect sensitive data.

Public safety agencies should inventory the features using AI in their environments and make AI disclosure a standard part of vendor reviews. Vendors should not wait to be asked. If AI is built into the software, say so clearly.

A few terms used here

• CJIS: Criminal Justice Information Services, the FBI division and security policy framework discussed here.
• CJI: Criminal justice information, the data protected by the policy.
• APB: Advisory Policy Board. In SC-28, “APB-member country” includes the United States, U.S. territories, Indian Tribes, and Canada.
• GovCloud: A cloud environment designed for government workloads. The name alone does not establish CJIS compliance.