The general counsel for a mid-sized metropolitan police department was sitting across from the city manager the morning after a local journalist filed a public-records request asking for every document the agency held about its AI-assisted report writing program. There was no single document. There was a vendor contract, a memo from the chief endorsing the pilot, a training slide deck that referenced an 82% reduction in report-writing time, and a chain of email approvals that had never been assembled into a coherent policy. The general counsel knew, as she sat there, that the agency's exposure was not the AI tool. The exposure was the absence of a document that said, in plain enforceable language, what the tool was authorized to do, who was accountable for its output, how officers were trained to verify it, and what happened when something went wrong. She had three hours before the press asked the same questions publicly. The policy she needed had never been written.

Why an Enterprise AI Policy Is Different

Most agencies that have deployed AI-assisted tools in public safety have some form of written guidance. A training memo. A vendor implementation guide. A standard operating procedure written by the IT division for data security. What those documents almost never add up to is an enterprise AI policy: a single, integrated document that governs AI use across all functions, at the executive level, and that every AI-touched decision in the agency can be checked against.

The distinction matters for several reasons that become visible at the worst possible time. When a defense attorney files a motion challenging the integrity of an AI-drafted report, the question the court will ask is not "did the officer use AI?" The question is "what policy governed that use, was the officer trained on it, and was it followed?" When the EFF (Electronic Frontier Foundation, a nonprofit focused on digital civil liberties and privacy rights) raises public concerns about an agency's AI practices, the question city council will ask is not "is AI useful?" The question is "what safeguards did you put in place before you deployed it?" When a CJIS (Criminal Justice Information Services, the FBI division that sets federal security standards for criminal justice data) audit finds that criminal justice information is being processed through a vendor cloud environment without appropriate controls, the question the FBI field office will ask is not "did you know the rules?" The question is "where is your written policy implementing them?"

An enterprise AI policy is not a formality. It is the foundational governance document that makes every other safeguard enforceable and every other training program meaningful. Without it, verification standards exist only in the training, not in the policy. Disclosure requirements exist only in the vendor contract, not in the agency's own governance. Accountability for AI-assisted output rests only on custom and assumption, not on written obligation. A policy transforms those assumptions into requirements.

Who the Policy Serves

An enterprise AI policy written at the executive level serves four audiences simultaneously, and the document must be legible to all four. The first audience is the patrol officer, dispatcher, or records specialist who consults the policy when they have a question about whether a particular use of AI is authorized. The policy must answer that question clearly, without requiring a call to legal or IT. If an officer cannot find an answer in the policy, the policy has failed in its most basic function.

The second audience is the prosecutor who is deciding whether to charge a case in which AI-drafted reports are part of the evidentiary record. The King County, Washington, prosecutor's office barred AI-written police reports from charging packages, creating a teachable governance line: when an agency cannot demonstrate that its AI-assisted reports meet an evidentiary standard the prosecutor can stand behind, the prosecutor draws the line themselves. An enterprise policy with clear verification and disclosure requirements gives the prosecutor the documentation they need to proceed with confidence rather than issuing a blanket prohibition.

The third audience is the oversight body: the civilian oversight board, the city council, the inspector general, or the federal monitor. That body needs to know that the agency has written rules governing AI use, that those rules are enforced, and that there is a documented record of compliance. An enterprise policy with built-in audit requirements produces that record as a byproduct of normal operations rather than as a scrambled response to an investigation.

The fourth audience is the vendor. Bundled, multi-year, sole-vendor contracts in the range of 45 million dollars or more, covering cameras, drones, cloud infrastructure, and AI tools, are being signed by agencies that have not yet written a policy governing the tools those contracts deliver. An enterprise policy establishes the agency's own standards and makes those standards a contractual requirement. The vendor's performance obligations flow from the agency's policy, not the reverse.

The policy comes before the contract, not after. When a multi-year vendor relationship defines what the agency can and cannot require, the agency has allowed the vendor to write its governance by default.

The Seven Core Elements of an Enterprise AI Policy

An enterprise AI policy for a public-safety agency is not a free-form document. It has a specific structure because it needs to address specific legal, operational, and governance requirements. The following seven elements are not suggestions. Each one addresses a failure mode that has already occurred in the field.

1. Authorized Uses

The policy must specify, precisely, which AI capabilities are authorized for use in which operational contexts. "AI-assisted report drafting is authorized" is not precise enough. The authorized use statement must identify the tool (Axon's Draft One, drafts police report narratives from body-worn camera audio, is the leading deployed example in 2026), the function it is authorized to perform (drafting a narrative for officer review), the functions it is not authorized to perform (making final determinations about facts, substituting for officer observation, classifying call types for dispatch without human review), and the data it is authorized to process (audio from the officer's own body-worn camera in connection with the specific incident being reported).

Authorized-use specificity does two things. It prevents scope creep: an officer who discovers that the AI can also summarize case files must know whether that use is authorized. And it creates an explicit prohibited-use list by implication: everything not on the authorized list is not authorized until a written amendment is added.

2. Authorship and Accountability

The policy must state, unambiguously, that the officer who submits an AI-assisted report is the author of that report and bears full accountability for its accuracy. "The computer wrote it" must be foreclosed as a response to any question about the report's contents, in any forum, including depositions, suppression hearings, and oversight investigations. The authorship clause in the policy is what makes that foreclosure real. It must be explicit, and officers must be trained to understand its implications before they are authorized to use any AI drafting tool.

The accountability chain must also be specified. The officer is accountable for verification and adoption. The first-line supervisor is accountable for confirming that the officer completed a verification pass before submission, through whatever audit mechanism the agency adopts. The shift commander is accountable for any pattern of verification failures within their unit. The AI program lead at the agency level is accountable for the integrity of the AI tools and the adequacy of the training. That chain must be in writing so that when something goes wrong, accountability does not dissolve into disagreement about who owned what.

3. Verification Requirements

The policy must specify the verification standard that applies to every AI-assisted output before it is submitted as a sworn document. The verification standard is not "review the draft carefully." The standard is the footage-grounded verification pass: every factual claim in the AI-drafted narrative is checked against the body-worn camera (BWC, the recording device worn on the officer's uniform) footage, the CAD (computer-aided dispatch) entry, and field notes before the report is adopted as a sworn account. That standard, stated explicitly in the policy, makes it a policy requirement rather than a best practice. A best practice can be skipped under pressure. A policy requirement cannot.

For AI tools used in dispatch, the verification requirement is different in content but identical in principle: every AI-assisted classification or summary must be reviewed by the telecommunicator before it is acted on. For AI tools used in records and redaction, the verification requirement is human review of every redaction decision before release. Each functional area has its own verification standard, and the policy must specify each one.

4. Disclosure Requirements

The policy must specify what must be disclosed, to whom, and in what form, whenever AI assisted in the creation of a document that will be used in any legal, administrative, or public proceeding. Brady v. Maryland (the 1963 Supreme Court case establishing that prosecutors must disclose exculpatory evidence to the defense) and Giglio v. United States (the 1972 Supreme Court case establishing that impeachment evidence about witnesses, including officers, must be disclosed) frame AI use as a constitutional-disclosure matter. If AI was used to draft a report, that is material to the defense's assessment of the report's reliability. The policy must specify that AI assistance is disclosed in the report itself (a standard notation in the report footer or header), in the discovery package, and to the prosecuting attorney at the time of submission.

The King County prosecutor's ban on AI-written reports was, at its core, a disclosure failure: prosecutors did not trust that they could represent the reliability of AI-assisted reports to courts that had not seen the verification standard. An agency that builds disclosure into policy gives the prosecutor what they need to make an affirmative representation, rather than issuing a defensive prohibition.

5. Prohibited Uses

The prohibited-use list is as important as the authorized-use list. It must be explicit. Common prohibited uses in a well-written enterprise policy include: using AI to make final determinations in any proceeding without human review and adoption; using AI to classify a 911 call as a specific call type without telecommunicator confirmation; using AI to generate a suspect description, predictive risk score, or investigative lead without documented human review and a clear notation that the AI output is a starting point, not a finding; using any AI tool on criminal justice information in a cloud or vendor environment that has not been cleared under the CJIS Security Policy; and using AI to draft any document in a case where the agency's own kill-criteria list applies (officer-involved shootings, in-custody deaths, sensitive investigations, cases involving known wrongful-conviction risk factors).

The prohibited-use list is not primarily about limiting the technology. It is about identifying the contexts in which the evidentiary stakes and the civil-liberties risks are high enough that the default must be human authorship without AI assistance, and where any departure from that default requires explicit written authorization from the agency's AI program lead and legal counsel.

6. Training and Authorization

The policy must specify that no officer, dispatcher, or records specialist is authorized to use an AI tool in the course of their duties until they have completed an agency-approved training program that covers, at minimum: how the tool works and what its failure modes are; the agency's verification standard for AI-assisted output; the agency's disclosure requirements; the authorship and accountability rules; and the prohibited-use list. Completion of training must be documented and that documentation must be maintained in a personnel record that is retrievable in the event of a legal challenge or an oversight investigation.

The training authorization requirement serves a second function: it defines who has supervisory responsibility for ensuring the training is current. AI tools change. A tool that was trained on one data set in 2024 may behave differently after a model update in 2026. The policy must specify that training is not a one-time event but a continuing requirement, refreshed whenever the tool is materially updated and at minimum annually.

7. Audit and Incident Reporting

The policy must specify how compliance is audited and what constitutes a reportable incident. Audit frequency, audit scope (percentage of AI-assisted reports reviewed, reviewed by whom, evaluated against what criteria), and the chain of reporting for audit findings must all be in writing. The audit requirement makes verification a documented practice, not just a policy statement.

The incident reporting requirement is equally important. When an AI-assisted report contains an error that is discovered before submission, that is a verification success: the process worked. When an AI-assisted report contains an error that is discovered after submission, that is a reportable incident: the process failed, and the agency needs to know why. The incident report documents what the AI produced, what the officer submitted, when the error was discovered, and what remediation was taken. That documentation is what transforms an individual failure into organizational learning rather than into individual discipline and organizational denial.

The Policy Writing Process: Who Owns It

The enterprise AI policy cannot be written by a single function and stamped by leadership. It requires genuine input from operations (patrol commanders who know what the tool actually does in the field), legal counsel (who knows what Brady, Giglio, and the discovery rules require), records and IT (who know what CJIS requires and where the data actually flows), labor relations (because in a unionized environment, a policy that changes working conditions without notice has its own legal complications), and community liaison (because the community's legitimate interest in transparency is a governance input, not an afterthought).

The drafting process should begin with a gap analysis: what AI tools are currently in use or under procurement, what written governance currently applies to each, and what the gaps are between current governance and the seven core elements described above. That analysis will almost always reveal that tools are being used under guidance that was written for a different purpose (an IT security policy is not an AI use policy), that the chain of accountability has not been specified, and that the disclosure requirements have been delegated to the judgment of individual officers rather than stated as policy requirements.

The Policy Writing Timeline

A realistic timeline for writing, reviewing, and adopting an enterprise AI policy from a standing start is approximately 90 days for a preliminary draft and 180 days for a fully vetted, adopted policy that includes union review, legal sign-off, and community input. That timeline is not comfortable if the agency has already deployed AI tools without written governance. But the alternative, continuing to deploy tools under informal guidance while the policy is being written, creates exposure that grows with every AI-assisted document submitted in the interim.

The interim risk-management step is to issue a temporary operational directive while the policy is being drafted. The directive does not need to be the full policy. It needs to specify, at a minimum, the verification standard that applies immediately, the disclosure notation that must appear on every AI-assisted document, and the prohibited-use cases that apply in the interim. That directive, adopted and signed by the chief, closes the most immediate exposure while the full policy is being developed.

Making the Policy Enforceable

A policy that is written but not enforced is worse than no policy in some respects: it demonstrates that the agency was aware of the requirement and chose not to meet it. Enforceability requires three things: the policy must be specific enough to create a clear standard, violations must be identifiable through the audit process, and the consequences of violation must be proportionate and defined.

Specificity is the most common failure point. "Officers must verify AI-assisted reports before submission" is not specific enough to enforce. "Officers must complete a footage-grounded verification pass, checking each factual claim in the AI draft against the BWC recording and the CAD entry, before submitting any AI-assisted report as a sworn document, and must document that verification in the report submission log" is specific enough to enforce. The difference is the difference between a standard that a supervisor can check and one that depends on each officer's interpretation of "verify."

The audit function creates identifiability. If the agency audits a sample of AI-assisted reports monthly, comparing the submitted report to the AI draft and looking for unverified claims, the audit results will identify patterns: which units are following the verification standard, which are not, and what the nature of the verification failures is. That information allows the agency to address problems through training and supervision rather than discovering them through a court challenge.

The consequences framework must distinguish between inadvertent errors caught through the verification process (which are training opportunities), systematic verification failures (which require supervisory intervention and additional training), and deliberate circumvention of the policy (which are disciplinary matters). A framework that treats all three the same way will suppress reporting of inadvertent errors, which are the information the agency needs to improve the system.

Policy without enforcement is decoration. Enforcement without a clear standard is arbitrary. The document that makes the program governable is the one that specifies both.

The Policy as a Living Document

An enterprise AI policy written in 2026 will need revision before 2028. AI tools in public safety are not static. Axon's Draft One, which drafts narratives from BWC audio and produced the widely cited 82% decrease in report-writing time in testing, is already being updated to incorporate new model versions and new data. Drone-as-first-responder programs are adding real-time AI analysis layers. Predictive analytics tools are being integrated into dispatch platforms. Each new capability requires a policy update before deployment, not after.

The policy should specify a review cadence: the policy is reviewed and updated annually at minimum, reviewed and updated immediately whenever a new AI tool is adopted or an existing tool is materially updated, and reviewed and updated within 30 days of any reportable incident that reveals a gap in the existing policy. That review cadence ensures that the policy remains a living governance document rather than a one-time compliance exercise.

The review process must include the same stakeholders who participated in drafting: operations, legal, records, IT, labor relations, and community liaison. An annual review that is conducted only by IT and signed by the chief without operational or community input is a review in form but not in substance. The policy is the governance document for an enterprise-wide program. Its review must be enterprise-wide as well.

Vendor Contract Alignment

Every AI tool the agency deploys is governed by a vendor contract as well as by the agency's own policy. Those two governance documents must be aligned, and where they conflict, the agency's policy must prevail. This requires legal counsel to review every vendor contract before signature and to flag any provision that conflicts with the agency's policy requirements: data handling requirements that would not comply with CJIS, liability limitations that would leave the agency holding accountability the vendor created, audit access provisions that would prevent the agency from reviewing AI-generated outputs, and model update provisions that would allow the vendor to materially change the tool's behavior without notice or agency consent.

The approximately 45-million-dollar, up-to-10-year bundled contracts being signed in the public-safety market are not just technology procurement decisions. They are governance decisions that will shape what AI tools the agency can use, what data the vendor holds, and what the agency can require of the vendor for the duration of the contract. A policy that is not embedded in the contract is advisory at best. A policy that is embedded in the contract is enforceable against the vendor as well as against agency personnel.

Key Takeaways

• An enterprise AI policy is not a memo or a training slide. It is the single governance document that every AI-touched decision in the agency can be checked against, covering patrol, dispatch, records, investigations, and command functions in one integrated document.
• The seven core elements are authorized uses, authorship and accountability, verification requirements, disclosure requirements, prohibited uses, training and authorization, and audit and incident reporting. A policy that omits any of these elements has a governance gap that will be visible at the worst possible moment.
• The King County prosecutor's ban on AI-written reports and EFF's transparency concerns both stem from the same failure: agencies deploying tools without written governance that prosecutors and oversight bodies can evaluate. An enterprise policy with clear verification and disclosure requirements closes that gap before the ban or the complaint.
• Brady v. Maryland and Giglio v. United States frame AI disclosure as a constitutional obligation. The disclosure requirements in the policy must be specific enough to satisfy a prosecutor who is deciding whether to charge a case built on AI-assisted reports.
• CJIS Security Policy obligations stay with the agency, not the vendor. The policy must specify how criminal justice information is protected in every AI processing environment, and vendor contracts must reflect those requirements.
• Policy without enforcement is decoration. The audit and incident-reporting requirements must be specific enough to create identifiable standards, and the consequences framework must distinguish between inadvertent errors, systematic failures, and deliberate circumvention.
• The enterprise AI policy must be adopted before vendor contracts are signed, not after. A contract that does not embed the agency's policy requirements allows the vendor to define the agency's governance by default.
• The policy is a living document. A review cadence of at minimum annually, with immediate review triggered by new tool adoption, material tool updates, or a reportable incident, keeps the policy current as the technology and the legal landscape evolve.