Part 1 of this series laid out why the risk landscape around generative AI, confidentiality exposure, hallucination risk, and vendor risk, makes a written AI Acceptable Use Policy an urgent priority rather than a nice-to-have. In Part 2, I want to walk through what actually needs to be in that policy for it to function as a real governance tool rather than a document nobody reads after the day it’s signed.

Start With Ownership, Not Rules

The instinct when building a new policy is often to jump straight to a list of dos and don’ts. Resist that instinct. The first thing an effective AI policy needs to establish is clear ownership: who actually has authority to approve or deny a new AI tool, who owns the technical and security review, who assesses the regulatory and privacy implications, and who serves as the final escalation point when someone has a question about permitted use. Without clearly assigned roles, an AI policy becomes a set of aspirational statements that nobody is actually accountable for enforcing.

A practical structure that works across organizations of different sizes designates an AI Governance Lead or committee, often general counsel paired with the chief information security officer in smaller organizations, or a cross-functional committee spanning legal, IT security, privacy, and a business-side representative in larger ones, with clearly defined responsibilities for IT/security, compliance or privacy, department leaders, and rank-and-file personnel underneath that governance function. The point is not the specific org chart. The point is that every employee should know exactly who to go to with a question, and every approval decision should have a clearly accountable owner.

Build a Real Vendor Due Diligence Process, Not a Rubber Stamp

The single most consequential operational element of any AI policy is the vendor approval process, because this is the mechanism that actually prevents Shadow AI from taking root. A genuine due diligence process needs to go well beyond checking whether a vendor “seems reputable.” At minimum, it should examine whether the vendor uses customer inputs or outputs to train its models and whether that can be contractually and technically disabled; the vendor’s security certifications, such as SOC 2 Type II or ISO 27001; where data is stored and processed, and what subprocessors or underlying foundation model providers the vendor relies on; whether a data processing agreement with confidentiality, audit rights, and breach notification terms is in place; and the vendor’s financial stability and what happens to your organization’s data if the vendor relationship ends or the vendor is acquired.

Critically, this diligence process cannot be a one-time gate. Approved vendors need reassessment at least annually, and immediately upon any material change in ownership, security posture, subprocessors, or a reported breach. AI vendors are a fast-moving space; a vendor’s practices at the time of initial approval are not a permanent guarantee of that vendor’s practices two years later.

Tie Data Classification Directly to Tool Approval

One of the more sophisticated elements a strong AI policy needs is a direct link between data classification and tool approval, meaning the policy specifies, for each approved tool, the maximum sensitivity of data that tool is permitted to receive. A tool approved for public or low-sensitivity internal use is not automatically approved for confidential client information or personal data, and free or consumer-grade versions of otherwise-approved products generally should be treated as unsuitable for confidential or privileged material unless IT or security has specifically confirmed in writing that the particular plan and configuration in use does not retain or train on submitted data. This granularity matters because a blanket “approved tools list” without data-classification limits creates a false sense of security: employees may reasonably assume that if a tool appears on an approved list, it’s fine to use for anything, when in fact the approval was scoped much more narrowly.

Build Verification Into the Workflow, Not Just the Policy Language

Every AI policy should state that AI-generated output must be independently verified before being relied upon. But stating that requirement is not the same as building it into how work actually gets done. The most effective policies specify concrete verification steps: every material fact, citation, quotation, statistic, and reference in AI-assisted work must be checked against a primary or otherwise reliable source before it appears in any external-facing deliverable, and high-stakes outputs, such as litigation filings, regulatory submissions, board materials, or financial disclosures, should require a documented second-person review in addition to the preparer’s own verification. That documentation requirement matters: a policy that says “verify before use” without any record of verification having occurred is difficult to enforce and even harder to demonstrate compliance with after the fact, whether to a regulator, a court, or a client asking hard questions.

Treat Incident Reporting as a No-Blame Safety Valve

No AI governance program will prevent every mistake. Confidential information will occasionally get pasted into the wrong tool. A hallucinated fact will occasionally slip through review and go out the door. The question is not whether these incidents will happen but whether your organization finds out about them quickly enough to contain the damage. That means the incident-reporting provisions of an AI policy matter just as much as the preventive provisions, and they need to include an explicit no-retaliation commitment: employees should never face adverse consequences for reporting a suspected AI incident in good faith, even one they personally caused. An organization that punishes self-reporting will simply drive incidents underground, which is the exact opposite of what effective governance requires. A structured incident-report process capturing what happened, what data or matters were potentially affected, what immediate containment steps were taken, and what notification obligations may apply gives the organization the information it needs to respond quickly and, where necessary, meet its own disclosure obligations to clients or regulators.

Don’t Let This Policy Live in Isolation

Finally, an AI Acceptable Use Policy should never be built as a standalone document disconnected from an organization’s existing governance infrastructure. It needs to explicitly connect to existing information security policy, data privacy policy, confidentiality policy, records retention policy, and code of conduct, with a clear rule for which policy controls when there’s a conflict, generally the more restrictive provision. It also needs a genuine annual review cycle, with faster updates triggered by material legal or regulatory change, a significant shift in the organization’s AI tool stack, or a significant AI incident. Technology and regulatory guidance in this space are moving quickly enough that a policy adopted today and never revisited will be stale within a year.

The Bottom Line

A good AI Acceptable Use Policy is not a document you write once and file away. It is a living governance structure: clear ownership, a real vendor vetting process tied to data sensitivity, verification steps built into actual workflows, and a no-blame incident reporting channel that surfaces problems while they’re still manageable. Organizations that build this infrastructure now, before a serious incident forces the issue, will be in a dramatically better position than those still treating AI governance as someone else’s problem.