How to Create an Employee AI Usage Policy

Most employee AI usage policy templates read like a legal checklist: list your approved tools, ban sensitive data, add a review clause, done. That's a reasonable skeleton, but it misses the harder question underneath it, which is how you actually decide what counts as sensitive, what an approved tool should be required to prove about itself, and what happens when the tool you built your policy around suddenly becomes unavailable. A few operators building AI-heavy products and internal systems have worked through these questions in detail, and their answers are worth building into a real policy rather than a generic one.

Treat privacy as a technical problem, not just a legal one

Cillian, founder of the data governance company Ethica, built his approach to this starting from consulting work with Heineken before GDPR took effect. His core insight was that privacy law, read from an engineer's perspective rather than a lawyer's, breaks down into a small number of concrete technical questions: what kind of data you actually have, where it came from and what jurisdiction that implies, what laws apply to it, what risks it carries, and whether you can actually enforce controls on it in practice.

This matters directly for an employee AI usage policy because most policies stop at the legal layer, a list of rules, without ever answering the technical layer underneath it: can your organization actually verify, in real time, what data a given AI tool is touching and why. Ethica's platform, called Astralis, pairs a regulatory model with what Cillian calls purpose-based access control, a system that decides in real time what data an AI agent can access for a specific stated purpose, rather than granting broad access and hoping employees use good judgment. The framing he uses for this is deliberately not "guardrails," which he says sounds purely restrictive. He prefers "harness and blinders," the idea that the goal isn't slowing a system down but directing its performance in one safe direction, the way blinders keep a racehorse focused forward rather than boxing it in.

For a policy document, the practical translation is this: don't just write a rule that says sensitive data can't go into unapproved tools. Build a system, even a simple one, that can actually answer what data a given tool touched and why, because a rule nobody can verify is a rule that quietly stops being followed.

Use allow lists to define what "approved" actually means

Jason Li, CTO of the legal and accounting timekeeping company Laurel, described a concrete mechanism worth borrowing directly for an employee AI usage policy. Laurel's product monitors employee activity across tools like Zoom, Teams, and Outlook to build a timeline for automated timekeeping, which means the company had to solve the sensitive-data problem for real, not just on paper. Their approach is governed entirely by user and firm-configured allow lists: specific apps and websites are explicitly included or excluded from what gets tracked, rather than a blanket policy that monitors everything by default.

This is a more usable model for an employee AI usage policy than a simple prohibited-data list, because it puts the decision at the tool level instead of relying on every employee correctly judging, in the moment, whether a specific piece of information counts as sensitive. An allow list defines the boundary once, at the system level, and then holds regardless of whether an individual employee remembers the rule that day.

Don't build critical processes on a single rented model

OneDigital's Mike Sullivan and Vinay Gidwaney raised a governance risk that belongs directly in an employee AI usage policy but rarely shows up in generic templates: what happens when the AI tool your policy is built around simply becomes unavailable. They pointed to the real, live example of Anthropic's Fable model being paused amid a government and security review as a case study in exactly this risk, arguing it's a reason to refuse building critical business processes on a single rented, meterable model in the first place. Their point isn't really about Anthropic specifically. It's that a vendor can throttle or revoke access at any time, and a policy that assumes continuous access to one specific tool is building a governance gap into itself from day one.

A practical version of this for a policy document: name your approved tools, but also require that any process depending heavily on a single AI vendor have a documented fallback, even a manual one, so a sudden access change doesn't stall a business-critical workflow outright.

Build the policy around what can actually be verified

Put together, these three examples point toward the same underlying principle for an employee AI usage policy: rules only hold up if they can be checked. A purpose-based access system like Astralis, an allow list like Laurel's, and a documented fallback for vendor dependency all share the same shape. Each one turns a policy statement into something a system or a process can actually enforce, rather than something that depends entirely on an employee remembering and correctly interpreting a written rule in the moment.

When you're drafting your own employee AI usage policy, it's worth running every clause through that same test: is this something you could actually verify happened, or is it just something you're hoping employees will follow. The clauses that fail that test are usually the ones worth rebuilding as an actual system control instead of a sentence in a document.

Keep learning from how real teams handle this

The technical and governance approaches behind a working employee AI usage policy are coming from people actually building these systems, not just from compliance templates. Subscribe to The AI Report for ongoing, firsthand coverage of how organizations are actually governing AI use, straight from the people building it.

‍