Detective Reyes has twelve hours of recorded interview audio from a major fraud case. Three suspects, four sessions each, a mix of recorded phone calls and in-person interviews. The transcripts alone run to 400 pages. His supervisor wants a summary of the key admissions and contradictions by Thursday. There is no way to do that manually in time. So the agency's new AI analysis tool ingests all twelve hours, processes the transcripts, and produces a 22-page summary with what it calls the key statements from each subject, organized by topic. Reyes reads through it, recognizes most of it, finds it coherent and well-organized, and almost submits it directly to his supervisor. He pauses on page 14. The summary attributes a statement to the second suspect, a specific phrase about a bank account number, that he does not remember hearing. He pulls the original transcript. The phrase is not there. The AI constructed it from context, from the surrounding conversation, from the kind of thing that would make sense to say in that moment. It was plausible. It was coherent. It was fabricated. If that phrase had appeared in a case summary submitted to a prosecutor, it would have been a Brady problem, a Giglio problem, and potentially a case-ending error. Understanding why that happened, technically, not because the AI "lied" but because of how these systems actually work, is the foundation of every verification habit in this program.

What a Language Model Actually Is

Most of the AI systems a public safety professional will encounter in 2026, the report-drafting tools, the interview summarizers, the call-transcription platforms, the translation assists in dispatch, all of them are built on or closely related to large language models (LLMs). Understanding what an LLM is, not in a computer science sense but in a practical working sense, is the single most useful piece of technical knowledge for a first responder who uses AI tools.

A language model is a system that has been trained to predict the next most probable piece of text given everything that came before it. That is the entire core of what these systems do. They are extraordinarily sophisticated probability estimators for text. They were trained on enormous collections of human writing: books, articles, websites, legal documents, police reports, academic papers, and much more. During training, the system learned patterns: what words tend to follow what other words, what sentences tend to follow what other sentences, what kinds of text tend to appear in what kinds of contexts. After training, when you give the model a prompt, a starting piece of text, it generates a continuation that it estimates is the most probable and coherent continuation given everything it was trained on and everything in the current conversation.

This is a profound capability. It is also the source of every major failure mode in AI-assisted public safety work. Here is why: the model generates text that is probable and coherent. It does not generate text that is verified against the source material. It does not know the difference between text it generated from facts that are present in the document you gave it and text it generated to fill a gap because that text is what would probably appear in this kind of document. Both outputs come out with the same tone, the same fluency, and the same apparent authority.

Tokens: The Atomic Unit

The model does not work with words in the way humans do. It works with tokens. A token is roughly a word, but sometimes a word fragment, sometimes a punctuation mark, sometimes a short common phrase treated as a single unit. When the model generates text, it is choosing the next token, then the next, then the next, based on the probability estimates it has developed from its training. For a sentence like "The suspect stated that he was at home," the model chose each of those tokens in sequence based on what a high-probability continuation of what came before it would look like.

This token-by-token generation process is why models can produce fluent, grammatically correct, contextually appropriate prose that is nevertheless factually wrong. Grammatical and contextual correctness is a function of how probable each next token is given the previous tokens. Factual accuracy would require checking each generated token against the source material, and that is not how the generation process works. The model does not go back to the source document and verify each claim as it generates. It generates based on patterns.

Training: What the Model Learned From

The training data shapes everything about how the model behaves. A model trained on a large corpus of police reports will have strong patterns for how police report narratives are structured, what language is used for different incident types, and what kinds of details typically appear in different sections of a report. When the model is generating a draft from body-camera audio, it is not just transcribing the audio into report format. It is generating a narrative that follows the statistical patterns of police report narratives it was trained on, applied to whatever it understood from the audio.

This is powerful and useful when the audio is clear, the incident is straightforward, and the narrative patterns the model learned are appropriate for this specific incident. It becomes a problem when the audio is unclear, when the incident has details that do not fit the patterns, or when the model fills a gap with a detail that fits the pattern of this type of incident but was not present in this specific incident. That gap-fill is not malicious. It is the model doing exactly what it was designed to do: generate the most probable and coherent text. The problem is that "most probable for this type of incident" is not the same as "what actually happened in this specific incident," and in a sworn police report, the distinction is everything.

Why Confident Output Is Not Verified Output

The most important operational fact about language models for a working officer is this: the confidence of the output tells you nothing about its accuracy. A language model produces its fabrications and its accurate extractions in the same confident, professional tone. There is no asterisk, no hedging, no change in style. A draft narrative that accurately reflects the body-camera footage reads the same way, stylistically, as a draft narrative with a gap-fill detail that was not in the footage.

This is fundamentally different from the other tools officers use. A database that cannot find a record returns a "no results" message. A GPS that loses signal shows a red indicator. A radio with a dead battery stops working. These systems communicate their own failures. A language model generating a hallucination looks identical to a language model generating accurate output. The only way to catch the error is to have a human with access to the source material read every claim and verify it against that source.

Consider what this means practically for a patrol officer using a report-drafting tool. The draft comes back. It covers the main facts of the call. It reads well. It sounds like something the officer would write. There is a paragraph describing the sequence of events at the door of the residence, including a sentence that says "Subject stated he had not been home that afternoon." The officer pauses. Did the subject say that? The officer remembers something along those lines being said, but the specific phrasing is not crisp in memory. The officer pulls up the BWC footage. The subject actually said "I was out most of the afternoon," which is different from "I had not been home." In most contexts, this is a minor phrasing difference. In a case where the subject's whereabouts that afternoon are at issue, it is not minor. The AI produced the more legally pointed statement because that kind of statement, direct denial of presence, is the kind of statement that appears frequently in police report narratives about this type of incident. The model generated what was probable. The officer's verification caught what was actually said.

A language model generates what is probable. A sworn report requires what is accurate. The gap between those two standards is where every AI-related legal problem in public safety lives.

The Three Failure Modes That Matter in Report Work

There are many ways a language model can generate inaccurate text, but in a public-safety context three failure modes are especially important because each one creates a distinct legal problem. Later lessons in this program go deep on each one. Here, the goal is to understand the mechanism that produces them.

The Gap-Fill Detail

The gap-fill is the most common failure mode in AI-drafted police reports. It occurs when there is a moment in the recording that the model could not extract clearly, and instead of flagging the gap, the model fills it with a plausible detail. The audio was muffled. The officer stepped away from the subject. There was background noise. The model cannot generate accurate text from unclear audio, so it generates probable text: the kind of detail that typically appears in this section of a report for this type of incident.

The gap-fill detail may be true. The officer may have done or said the thing the model described, and the unclear audio just did not capture it. Or the gap-fill may be fabricated. There is no way to know without checking the footage. The verification habit for gap-fill is to ask, for every factual claim in the draft: "Is this on the recording? Can I point to the moment?" If the answer is no, the detail either needs to come from the officer's independent recollection and notes or it needs to be removed from the report. A fact that cannot be verified from the source material has no place in a sworn narrative.

The Softened Fact

The softened fact occurs when the model generates a less forceful or less specific version of what was actually recorded. The subject "appeared agitated" instead of "stated he was going to kill me." The officer "attempted to de-escalate" instead of "deployed a control hold." These softenings can happen because the model is calibrated toward professionally neutral language, because the training data contains more examples of the softened version, or because the model is generating based on probability and the softened version is more probable in this linguistic context.

Softened facts in police reports are a problem in the same direction as invented details but different in character. An invented detail that incriminates a subject is a Brady problem: it is a false statement in a document that must be disclosed to the defense. A softened fact that makes an officer's use of force sound less forceful than it was is a different kind of problem: it creates a gap between the report and the footage that a defense attorney will surface in cross-examination, making the officer appear either to have lied in the report or to have signed off on an AI account without reading it carefully. Neither is a good answer in a deposition.

The Invented Quote

The invented quote is the most dangerous failure mode because quotation marks in a police report carry a specific evidentiary weight. A quote is, by convention, what was actually said. When the AI attributes a statement to a subject that the subject did not actually say, or produces a close paraphrase under quotation marks, the officer who adopts that report has placed false words in the subject's mouth in a sworn document. In a case that goes to trial, that false quote is an impeachment opportunity, a Brady problem, and potentially grounds for suppression of other evidence. In a civil rights lawsuit, it is evidence that the officer fabricated statements.

The verification habit for quotes is strict: every direct quote in an AI-drafted report must be verified against the recording. The exact words must match. If the model produced a paraphrase, it must be either corrected to the verbatim statement or rewritten without quotation marks to reflect that it is a paraphrase. There is no middle ground on this one.

How Context Windows and Grounding Change the Picture

The picture of AI failure described above is not the whole picture. Modern AI systems used in public safety work are typically configured with a "context window," a block of source material, the transcript, the CAD entry, the footage summary, that is given to the model along with the drafting instruction. The model is told, in effect, "draft this report based on this specific material." This is called grounding: tying the model's output to a specific document or source rather than allowing it to generate from patterns alone.

Grounding materially reduces hallucination. A model that is drafting from a clear transcript of the encounter, with the instruction to stay within what the transcript shows, will produce fewer gap-fills than a model generating from vague memory patterns. This is why the quality of the source material matters: a body-camera recording with clear audio, captured close to the subject and without excessive background noise, gives the model better material to work from. Better source material produces better drafts with fewer hallucinations. The verification work still needs to happen, but it is verifying a more accurate starting point.

The concept of grounding is also why the verification standard is not "is this consistent with what I remember about the call" but "can I find this in the footage." The footage and the CAD entry are the source materials the model was supposed to draft from. If something in the draft cannot be found in those source materials, it was either generated from patterns rather than from the specific source, or it was derived from a portion of the source the officer cannot verify independently. Either way, it needs review.

Understanding grounding also helps explain why the same model can be better or worse depending on how the product is configured. A report-drafting tool that gives the model the full transcript and explicit instructions to flag anything it is uncertain about will behave differently from a tool that gives the model the audio and asks it to draft a report. Vendors have made different choices about grounding, flagging, and quality control, and those choices affect how much hallucination occurs in the draft. But no configuration eliminates hallucination entirely, and no configuration relieves the officer of the verification obligation.

What This Means for CJIS and Data Handling

The Criminal Justice Information Services (CJIS) Security Policy, maintained by the FBI, governs how criminal justice data is handled, stored, and transmitted. When an AI system processes body-camera footage, interview transcripts, or case documents, that data is typically criminal justice information subject to CJIS policy. The agency's CJIS obligations do not transfer to the AI vendor because the vendor processes the data on the agency's behalf. The agency remains the responsible party.

This is not a technical footnote. It means that before an agency deploys an AI tool that processes CJIS-protected data, it needs to verify that the vendor's technical and operational controls meet CJIS requirements, that the data is processed and stored in CJIS-compliant infrastructure, and that the access controls, audit logging, and breach notification obligations are met. A vendor that is not CJIS-compliant is a vendor whose deployment could expose the agency to policy violations, regardless of how useful the AI tool is.

For the individual officer or dispatcher, the relevant CJIS concern is simpler: criminal justice data should not be processed through consumer AI tools, personal accounts, or unofficial cloud services. Using a personal ChatGPT account to summarize interview notes, or copying case file information into a consumer AI assistant to get a quick draft, is a CJIS violation and a potential chain-of-custody problem. The AI tools used for public safety work must be agency-approved, CJIS-compliant tools. If you are unsure whether a tool meets that standard, the answer is to check with your agency's information security officer before using it, not to assume it is fine.

Key Takeaways

• Large language models (LLMs), the technology behind report-drafting tools, interview summarizers, and dispatch-assist AI, work by predicting the next most probable piece of text. They generate language based on statistical patterns learned from training data, not by retrieving and verifying facts from source documents.
• LLMs process text as tokens, roughly words or word fragments, and generate each token in sequence based on probability. This produces fluent, contextually appropriate prose that can be factually wrong because probability and accuracy are different standards.
• The confidence of AI output tells you nothing about its accuracy. A hallucinated detail and an accurately extracted fact come out of the model in the same tone, the same style, and the same professional format. The only way to detect the difference is human verification against source material.
• The three most important failure modes in AI-drafted police reports are the gap-fill detail (a plausible invented fact to fill an unclear moment in the audio), the softened fact (a less forceful version of what was actually said or done), and the invented quote (a fabricated or paraphrased statement under quotation marks). Each creates a distinct legal problem.
• Grounding, giving the model specific source material to work from, reduces hallucination but does not eliminate it. The verification standard is always: every factual claim must be traceable to the footage, the CAD entry, or the officer's independent verified recollection.
• CJIS (Criminal Justice Information Services) policy governs the handling of criminal justice data. When AI systems process that data, the agency's CJIS obligations remain with the agency, not the vendor. Consumer AI tools and personal accounts must not be used to process case materials.
• Brady v. Maryland (1963) requires disclosure of exculpatory evidence. Giglio v. United States (1972) requires disclosure of evidence affecting witness credibility. A hallucinated incriminating detail in an AI-drafted report is a potential Brady problem. A softened fact that contradicts the footage is a Giglio problem. Understanding why the model can produce these errors is the first step toward preventing them.
• The same language model technology is behind every AI tool in the public-safety workflow: report drafting, interview summarization, call transcription, translation assist, and records summarization. The technical behavior, including the hallucination risk, is the same across all of these applications. Verification discipline is required for all of them.