AI Policy Should Govern Data, Not Tools

Executives will tell you their company has an AI policy. Very few can tell you the last time anyone opened it. The document is usually fine — drafted with care, circulated, acknowledged in the HR portal, filed. What went wrong is not the writing. It is that the policy was built to govern a world that has quietly stopped existing, and nobody scheduled a moment to notice.

That is a design problem, not a discipline problem, and it is worth understanding before you commission another draft.

The approved-tools list stopped describing reality

Nearly every AI acceptable-use policy written in the last two years shares one structure: a list of sanctioned tools, a list of prohibited ones, and a paragraph telling employees not to put confidential information into either. That structure rests on an assumption — that AI is a destination, a website someone consciously decides to visit.

It is not anymore. AI now arrives as a feature inside software your company already licenses. It shows up in the browser, in the meeting recorder, in the CRM sidebar, in the PDF reader, in the note-taking app someone installed on a personal phone, in the transcription service that joins the call uninvited. Capability appears by vendor update rather than by procurement decision. An employee can pass company information through several AI systems before lunch without once making a choice about AI.

This is the structural reason approved-tools lists decay. The list names vendors. The risk lives in features. By the time a policy names a product, that product has shipped capabilities the policy never contemplated, and a competing capability has surfaced inside a tool you already own.

Analysis, not prediction: the useful unit of governance has moved from the tool to the data. A policy organized around what may leave the building will outlive a policy organized around which logos are permitted.

A rule nobody can observe is a suggestion

There is a test that separates a working policy from a decorative one. Take each rule in the document and ask a single question of it: if someone broke this, how would we know?

Most AI policies fail on nearly every line. "Do not enter client information into public AI tools" is a reasonable sentence and an unobservable one, unless something in your environment is actually watching for it. Rules that cannot be observed are not rules. They are hopes with a signature block attached.

The remedy is not surveillance. It is honesty about which category each rule belongs to. Sort the policy into two columns.

• Technically enforced. Which AI features are on or off in your tenant. Which third-party apps can obtain consent to your data. Which accounts require phishing-resistant sign-in. What an assistant like Copilot can reach, which inherits the permissions already sitting on your files — meaning a badly shared folder becomes a badly answered prompt.
• Socially agreed. Judgment calls. When to disclose that a draft was AI-assisted. When a human must verify output before it reaches a client. When a request to move money deserves a callback to a known number, regardless of how convincing the voice on the line sounded.

Both columns are legitimate. Confusing them is what produces a document nobody follows, because employees work out quickly which sentences have teeth and mentally discard the rest — including the ones that mattered. If your first column is thin, the fix belongs in your Microsoft 365 configuration and your identity controls, not in a longer document.

Shadow AI is a latency problem first

The standard explanation for unsanctioned AI use is that employees are careless or indifferent to security. In our reading that explanation is usually wrong, and it sends executives toward the wrong intervention.

People route around the sanctioned path when the sanctioned path is slower. Picture an analyst at 4:40 on a Thursday holding a contract she needs summarized before she leaves. She will use whatever returns an answer in ninety seconds. If the approved route requires a ticket, an approval, and a wait until tomorrow, she is not filing the ticket. She pastes the contract into whatever is already open in her browser and goes home.

Reframe the executive decision accordingly. The question is not only what you forbid, but how fast the permitted route runs. Sanctioned capability that genuinely beats the shortcut does more for governance than any amount of policy language. Speed is a control.

The same logic explains why responsive IT support behaves as a security mechanism rather than a convenience line item. Someone who can get a real answer in minutes has no reason to invent a workaround. Someone who expects to wait a day builds a private toolchain, and you learn about it much later, usually from the wrong direction.

Write for data classes, then give people amnesty

A policy employees can actually apply names the data, not the vendor. Three classes are usually enough, and each needs an example drawn from the reader's real job rather than an abstraction.

• Never leaves sanctioned systems. Client financials, patient information, case files, credentials, unreleased results, employee records, anything under contract or regulation. For a medical practice this is the line where HIPAA compliance lives, and it should be written in that practice's own language.
• Sanctioned tools only. Internal documents, drafts, code, meeting content — proprietary but not regulated.
• Open. Published material, marketing copy, general research questions.

Then add the clause most policies omit: a no-blame reporting route. Somebody will paste the wrong thing into the wrong window. What decides the cost is whether they tell you in ten minutes or ten weeks. Promising punishment for honest error guarantees silence, and silence is the expensive outcome. State plainly that self-reported mistakes are handled as containment rather than discipline — then honor it the first time it is tested, because that first case becomes the real policy no matter what the document says.

One further clause deserves a line, and it is the genuinely new one for 2026. AI agents increasingly act with a user's credentials, reading mail and touching systems on someone's behalf. Acceptable use now has to cover what an employee may authorize software to do in their name. That is an identity question, and it belongs with the rest of your cybersecurity program rather than in an HR annex.

What to demand from the next draft

Your AI policy is not an HR artifact. It is an extension of identity and data governance, it should be owned by whoever owns those, and it needs a review date on the calendar, because the feature surface changes without consulting you.

Judge the next version by three things. It fits on two pages. Every rule is either technically enforced or explicitly labeled a judgment call. The permitted path is faster than the shortcut it replaces. Fail the third test and the document loses to convenience, as it already has in most companies.

Pro Link Systems has supported Los Angeles businesses from Woodland Hills since 1999. Our help desk is in-house and US-based, calls are answered live by that team, and average ticket first-response time is 15 minutes — the kind of latency that keeps a sanctioned path competitive with a shortcut. If you want the configuration work behind a policy like this handled properly, our managed IT services team is a reasonable place to begin.