IACP’s Technology Conference in Fort Worth was supposed to be a showcase of innovation. Instead, it felt like a sales floor for something more consequential: the quiet replacement of human judgment with automated steps that sit inside the legal process—steps that, once automated, become harder to challenge, harder to audit, and easier to scale.
Thousands of attendees packed into the conference orbit around the International Association of Chiefs of Police (IACP), where vendors, consultants, and agency leaders traded promises about “the future of policing in the digital age.” Press were restricted from entering the main event spaces, but conversations outside the gates made one theme hard to miss. Many of the products being pitched weren’t framed as dramatic “AI policing” in the way people imagine—no cinematic robots, no sci‑fi surveillance takeover. The pitch was subtler and, arguably, more powerful: automate routine tasks that law enforcement already does every day, then let those automated outputs flow into investigations, reports, and decision-making workflows that ultimately affect arrests, charges, and courtroom narratives.
That is the business model now. Not just selling software, but selling operational infrastructure—systems that become embedded in how cases are built.
And because the tasks are described as routine, the ethical and legal stakes often get treated as secondary. That’s where the danger lives.
What vendors are really selling: legal-process plumbing
In policing, “routine” doesn’t mean “unimportant.” It means the work is repetitive enough to standardize, document, and measure. It also means it happens early—before a case becomes a formal narrative, before a supervisor signs off, before a prosecutor decides what to file, before a judge ever sees the evidence.
At IACP, the most common pitch patterns clustered around three categories:
1) Intake and triage automation
Calls, incident reports, and initial documentation are often the first point where information becomes structured. Vendors offer tools that convert messy text, audio, and free-form descriptions into standardized fields. Some systems summarize incidents; others suggest report language or generate draft narratives. The goal is speed: reduce backlog, reduce clerical burden, and make it easier for agencies to “get to the next step.”
2) Evidence and documentation workflows
Once an incident is logged, evidence management begins. Vendors promote AI-assisted tagging, transcription, and search across body-worn camera footage, dashcam video, audio recordings, and documents. These tools can identify objects, detect events, and help analysts locate relevant segments faster than manual review.
3) Investigative support and decision support
This is where the marketing language can shift. Some products avoid the phrase “decision-making,” preferring “assistive analytics.” But even when framed as support, the output can influence who gets investigated, what leads are pursued, and how quickly cases move. Network analysis, risk scoring, and predictive tools are often presented as ways to prioritize limited resources.
Across these categories, the common thread is that the systems don’t merely store information. They transform it—turning raw inputs into structured outputs, summaries, tags, and recommendations. Those transformations then become part of the case record.
When that happens, the AI isn’t just a tool. It becomes part of the evidentiary chain.
The “automation” argument—and why it’s not enough
Vendors frequently argue that automating routine steps improves accuracy and consistency. If a system drafts a report, it can apply a consistent template. If it transcribes audio, it can reduce missed details. If it tags video, it can surface relevant moments faster.
But consistency is not the same as correctness. A standardized output can still be wrong—just wrong in a repeatable way. And when the output is produced by a system that is difficult to inspect, the error may be difficult to contest.
There’s also a structural issue: policing is not a purely technical environment. It’s a legal environment. The difference matters because legal scrutiny depends on transparency, explainability, and the ability to reproduce or verify what happened.
If an AI system generates a summary of an incident, questions follow:
What data did it use?
What model produced the summary?
What confidence thresholds were applied?
Were there human edits, and if so, who made them?
How should a defense attorney challenge the summary’s accuracy?
If the system tags video segments, questions follow:
How were the tags generated?
What training data shaped the model’s behavior?
What is the false positive rate for the tags that matter most?
How does the agency validate performance over time?
In many deployments, these answers are either not provided clearly or are buried in vendor documentation that agencies may not fully control. That creates a mismatch between how the technology is used and how the legal system demands accountability.
The hidden power of “drafts”
One of the most overlooked aspects of AI adoption in policing is the role of drafting. Many systems are positioned as “assistants” that produce first drafts: report language, incident summaries, evidence indexes, and investigative timelines.
Drafts sound harmless. They’re not final decisions. But drafts shape the final record. In practice, a drafted narrative can become the backbone of a report, especially when staffing is tight and time is limited. Even if officers review and edit, the structure and phrasing of the draft can steer what gets emphasized and what gets omitted.
This is where the legal stakes intensify. Courts and prosecutors rely on the written record. If the record is influenced by automated summarization, the defense may need to challenge not only the underlying facts but also the process that produced the narrative.
Yet the process is often treated as proprietary. The model may be a black box. The vendor may claim trade secrets. The agency may say it cannot disclose internal parameters. The result is a system that can influence outcomes while remaining difficult to interrogate.
That tension—between operational convenience and legal transparency—is at the heart of the current debate.
Why the “routine tasks” framing is so effective
The reason vendors focus on routine automation is strategic. Dramatic claims about “predicting crime” or “automatically identifying suspects” trigger public backlash and regulatory scrutiny. Routine automation is easier to sell because it sounds like administrative modernization.
It also aligns with procurement realities. Agencies often have urgent needs: backlogs in evidence processing, overwhelmed records units, staffing shortages, and pressure to reduce response times. AI tools promise to relieve those pressures quickly.
But once a system is integrated into workflows, it becomes part of the agency’s operating rhythm. Even if the original intent was efficiency, the system’s outputs can become embedded in case files and decision processes.
In other words, the technology doesn’t just automate tasks. It changes institutional habits.
And institutions, once habituated, rarely revert.
The data problem: garbage in, confident out
AI systems are only as good as the data they learn from and the data they receive. Policing data is not neutral. It reflects historical patterns of enforcement, reporting practices, and institutional priorities. It also reflects the uneven quality of documentation across jurisdictions.
At IACP, vendors often emphasize that their systems are “trained on large datasets” and “validated for accuracy.” But validation can mean different things depending on what is measured and what is excluded.
A system might perform well on a narrow benchmark—say, detecting certain objects in controlled footage—while failing in real-world conditions: poor lighting, camera angles, occlusions, background noise, or unusual scenarios. It might also behave differently across contexts, such as different body camera models, different recording practices, or different community environments.
Even when performance is strong overall, the distribution of errors matters. In policing, errors are not evenly distributed. They can cluster around specific types of incidents, specific locations, or specific demographic contexts—especially when the system’s training data reflects biased patterns.
The most troubling scenario is not simply that the AI makes mistakes. It’s that the AI makes mistakes in ways that are hard to detect and easy to rationalize after the fact.
When an AI output is treated as authoritative, the burden shifts to humans to prove it wrong. That is a high bar, particularly when the system’s internal logic is opaque.
Accountability gaps: who is responsible when the system is wrong?
Another theme that emerged from conversations around the conference: responsibility is often blurred.
If an officer uses an AI-generated tag to locate a video segment, and that tag is wrong, who is accountable? The officer? The agency? The vendor? The system designer? The procurement office that approved it?
In theory, agencies remain responsible for their actions. In practice, accountability becomes complicated when the system’s outputs are treated as “assistance” rather than evidence. If the AI is framed as a tool, agencies may argue that it does not determine outcomes. But if the AI’s outputs are used to build the case record, the tool effectively shapes evidence.
This is why governance matters. Governance isn’t just policy language. It’s the operational reality of how systems are tested, monitored, and corrected.
Key questions include:
Are there documented performance metrics before deployment?
Are there ongoing audits after deployment?
Are there procedures for contesting AI outputs?
Is there a clear record of when AI was used and how it influenced decisions?
Are officers trained to understand limitations and failure modes?
Without these safeguards, AI becomes a convenient scapegoat or a convenient authority—depending on which narrative is more useful at the moment.
Procurement as a turning point
The business of selling AI to police is booming partly because procurement has become a competitive arena. Vendors offer pilots, discounts, and “rapid deployment” packages. Agencies want results quickly, and vendors know that speed sells.
But procurement is also where the most important decisions are made:
What exactly is being purchased—software, services, or both?
What data will the system ingest?
Who controls the model updates?
What documentation will be provided?
What are the terms for data retention and sharing?
What happens if the system fails?
In many cases, agencies may not have the technical capacity to negotiate these terms effectively. Vendors may provide assurances, but assurances are not the same as enforceable requirements.
A pilot can also create momentum. Once a