Policy on Paper, Practice in the Dark: Why Most AI Rules Die in the Intranet

Somewhere in your organization right now, an employee is pasting a customer contract into a public chatbot to 'summarize the key terms.' And somewhere else, a policy document — twelve pages of legalese titled 'Acceptable Use of Generative Artificial Intelligence' — sits unread, last updated during a compliance sprint two quarters ago.

These two facts are related. The policy failed not because employees are reckless, but because it was written for the wrong reader. It was drafted to protect the company in a deposition, not to help a procurement analyst make a good decision at 4:45 on a Thursday.

The Disclaimer Problem

Most AI policies in American enterprises follow a familiar template: broad prohibitions, vague carve-outs, and a signature line. 'Do not input confidential information into unauthorized AI tools.' What counts as confidential? Which tools are authorized? What should the employee do instead? The document doesn't say, because it wasn't written to be operational. It was written to be defensible.

The result is predictable. Employees either ignore the policy entirely or interpret it so conservatively that productivity gains evaporate. Both outcomes are failures. A policy that bans everything is as ineffective as one that permits everything, because neither gives people a decision framework they can apply at the moment of use.

The companies getting this right — and there are more of them in the US mid-market than in the Fortune 500, where legal review cycles move slower — treat AI policy less like a contract and more like a constitution: a living set of principles that gets amended as the technology and the organization's experience evolve.

Start With Data Boundaries, Not Tool Lists

The first mistake is organizing policy around tools. ChatGPT gets approved, then a better model launches, and the approval memo is obsolete. Tools change quarterly; data classifications don't.

Effective policies start with a three-tier data boundary that any employee can memorize:

• Green: Public information, internal drafts without customer data, general research. Any approved tool, minimal oversight.
• Yellow: Internal business data — financials, roadmaps, HR matters. Enterprise-grade tools with contractual data protections only, outputs reviewed before external use.
• Red: Customer PII, regulated health or financial data, anything covered by contractual confidentiality. Off-limits to general-purpose AI, full stop, unless a specifically sanctioned and audited workflow exists.

A regional insurance carrier in the Midwest we worked with condensed its entire policy to a single laminated card built on this model. Usage of approved enterprise tools went up 60% in a quarter — and policy violations, measured by their DLP tooling, went down. Clarity enabled compliance.

Write for the Role, Not the Workforce

A software engineer using a coding assistant and a customer success manager drafting client emails face entirely different risk profiles. A single uniform policy serves neither.

Role-specific annexes do the heavy lifting. For engineering: generated code requires the same review as human-written code, license provenance matters, and secrets never enter a prompt. For marketing: AI-assisted content requires human editorial sign-off and factual verification, and brand voice remains a human accountability. For finance and legal: red-tier data by default, and no AI output enters a filing or contract without documented human review.

This structure also creates natural accountability. When the annex for a role is unclear, the department leader owns fixing it — not a central compliance team that has never done the job.

Disclosure Norms: The Missing Middle

Most policies are silent on the question employees actually ask: do I have to tell people I used AI? The answer shouldn't be a blanket yes or no. It should be contextual.

A workable norm: disclose when the output carries consequence or when provenance matters. A first-draft internal memo? No disclosure needed. Client-facing deliverable? The client may have a right to know — check the contract. Code in production? The review process should treat provenance as relevant. Candidates' resumes run through an AI screen? Absolutely disclosed, both to candidates and internally, both for ethical and emerging regulatory reasons.

Getting ahead of disclosure norms now also positions US companies for the regulatory environment taking shape — from state-level AI hiring laws in Illinois and New York to the growing expectation of AI transparency in federal contracting.

Review Checkpoints Make Policy Real

A constitution without amendments is a relic. Build review into the operating rhythm: a quarterly policy review tied to tool evaluation, an incident log for AI-related near-misses treated with the same seriousness as security events, and an annual attestation that takes employees fifteen minutes rather than an hour of training-video theater.

One practical mechanism worth borrowing: a standing 'AI council' of eight to twelve people drawn from engineering, legal, HR, and frontline operations, empowered to approve tools and update annexes between formal review cycles. Speed of governance matters as much as its content. A policy that takes five months to approve a tool guarantees shadow usage for five months.

The Standard You Walk Past

Ultimately, an AI usage policy is a leadership document. Employees will calibrate their behavior not to what the intranet says but to what their managers do. If an executive forwards AI-drafted material to the board without review, the policy is dead regardless of its wording.

The organizations that will lead the next decade of digital transformation aren't the ones with the most sophisticated AI tools. They're the ones whose people know exactly where the lines are — because someone took the time to draw them clearly, in language the workforce actually speaks.