Employee AI Usage Policies, in depth: tool tiers, a data-by-tier matrix, enforcement and a policy register in code

Most employee AI policies fail in one of two ways. Some are bans: the organisation forbids generative AI, employees use it anyway on personal accounts, and the security team loses all visibility into what data went where. Others are a page of principles ("use AI responsibly", "do not share confidential data") that nobody can apply to a real decision, such as whether a support agent may paste a customer ticket into a chatbot to draft a reply. Both leave the actual risk unmanaged.

A policy that works is short, specific and enforceable. It says which tools are approved, which data may go into which tool, which uses need extra review, and what to do when something goes wrong, and each rule maps to a control the security team can operate. This article builds such a policy from first principles: the risks it has to address, a tiering of tools, a data-by-tier matrix, rules for the uses that need them, an enforcement architecture, a policy register in code, and a worked example. It is engineering guidance, not legal advice; have counsel review the final text against the laws that apply to you.

The risks the policy must address

Start from what can actually go wrong when employees use AI tools, because each clause should trace back to one of these:

Data disclosure. Confidential, personal or regulated data is sent to a provider whose terms allow retention, human review or training on inputs. Consumer and enterprise plans of the same product often differ on exactly these points, and terms change, so the policy should name plans, not products.
Secrets in prompts. API keys and credentials pasted while debugging, or included in code sent to an assistant.
Unreliable output used as fact. Fabricated citations, wrong code, or confident errors that reach customers or decisions unchecked.
Consequential decisions. AI used to screen candidates, assess employees or decide on credit or benefits, where law may impose specific obligations.
Agents with permissions. Tools that can read mailboxes or drives, or act through connectors, extend what a prompt injection can reach.
Intellectual property. Uncertainty over ownership of generated output and over licences of generated code.

Tier the tools

Classify tools, specifically tool plus plan plus configuration, into three tiers. The tier is a decision made once, by security, legal and procurement together, and recorded with an owner and a review date.

Tier	Criteria	Examples of what qualifies
1: Approved	Contract or enterprise terms with no training on inputs, defined retention, SSO, admin audit logs, data residency where needed	The company's enterprise chat assistant; the licensed coding assistant with org policy set
2: Limited	Reviewed, acceptable terms, but weaker controls (no SSO, short-lived logs, or unclear retention)	A niche transcription or design tool for public or internal data only
3: Not approved	Not reviewed, consumer terms, or terms allowing training on inputs	Personal accounts on any service; browser extensions that read page content

Tiering by configuration matters because the same product can sit in two tiers: an enterprise workspace with data retention set by the organisation is Tier 1, while a personal account on the same service is Tier 3. Vendor review itself, including contract terms and monitoring for silent changes, is covered in managing third-party LLM vendors.

The data-by-tier matrix

The core of the policy is one table that answers "may I put this data into this tool?". Use the organisation's existing data classification rather than inventing one.

Data class	Tier 1	Tier 2	Tier 3
Public	Yes	Yes	Yes, but prefer Tier 1
Internal	Yes	Yes	No
Confidential (customer data, unreleased plans, source code)	Yes	No	No
Restricted (credentials, health, payment card, special-category personal data)	Only in tools approved for that class	No	No

Restricted data deserves its own rule because Tier 1 approval is usually a general one. Payment card data, health records or legally privileged documents may need contractual terms that a general enterprise agreement does not include, so approve them per tool and per class. Credentials are never acceptable input anywhere: there is no use case that needs a live secret in a prompt, and secret scanners can catch most of them before they leave.

Expect the question "if I remove the names, can I use a lower tier?" and answer it in the policy. Removing direct identifiers rarely makes data public: order numbers, rare job titles, dates and free-text descriptions often identify a person or a deal on their own, and the redaction is done by hand under time pressure. A safe rule is that de-identified data keeps its original class unless it went through an approved, tested de-identification process, and that synthetic or genuinely aggregate data, such as counts with no row-level detail, may be treated as Internal. That rule is simpler to follow than case-by-case judgement, and it removes the incentive to under-classify data in order to reach a preferred tool.

Rules for specific uses

Some uses need rules beyond the matrix. Keep this list short and concrete:

Coding assistants. Only the approved assistant, signed in through the organisation, with any available settings for code retention and public-code matching set by the admin. Generated code goes through the same review, tests and licence scanning as any other code. Never paste secrets or production data.
Agents and connectors. Connecting an AI tool to mail, drives, calendars or ticketing needs security approval per connector, with least-privilege scopes. Agent actions that send, delete, pay or publish need human confirmation.
Meeting recording and transcription. Announce it and get consent where law requires; do not use it in meetings covered by legal privilege or HR matters.
Customer-facing and published content. A named human reviews it before release, and facts, figures and citations are checked against sources.
Decisions about people. Hiring, performance, discipline, credit or eligibility uses go to a formal review with legal before any pilot, because these are the areas regulation targets most directly.

Enforcement architecture

Figure 1. SSO limits sign-in to approved tools; the egress proxy or CASB looks up the destination's tier; DLP inspects content for Tier 2; Tier 3 gets a coaching page. One register drives the written policy and the config.

Each clause should map to a control:

Identity. Approved tools are bought on enterprise plans, joined to SSO, and provisioned with SCIM so leavers lose access the day they leave.
Egress. A secure web gateway, CASB or forward proxy categorises AI destinations and applies the tier: allow Tier 1, inspect Tier 2, block or coach on Tier 3. A coaching page that names the approved alternative converts far better than a bare block. Design notes for proxies are in egress filtering for LLM traffic.
Content. DLP rules for credentials, card numbers, national ID formats and document classification labels, applied to uploads and pasted text bound for Tier 2.
Endpoints. Managed browser extension allow-lists, since extensions that read every page are an easy path for data to leave.
Logs. Record decisions (user, tool, tier, action, DLP rule hit), not prompt content, unless there is a defined reason and retention; a log of every prompt becomes the most sensitive dataset in the company.

The policy register as code

Keep tiers and rules in a version-controlled register. The written policy's tool list, the proxy categories and the DLP scope are generated from it, so they cannot drift apart, and every change has a reviewer and a date.

# ai_tools.yaml
tools:
  - id: corp-assistant
    domains: [assistant.example-vendor.com]
    plan: enterprise
    tier: 1
    max_class: confidential
    restricted_ok: false
    owner: it-collab
    review_by: 2027-03-31
  - id: transcribe-lite
    domains: [app.transcribe-lite.example]
    tier: 2
    max_class: internal
    owner: security
    review_by: 2026-12-31
default_tier: 3

from datetime import date

CLASS_RANK = {"public": 0, "internal": 1, "confidential": 2, "restricted": 3}

def decide(register, host, data_class, has_secret):
    tool = next((t for t in register["tools"] if host in t["domains"]), None)
    if has_secret:
        return "block", "credential detected"
    if tool is None:
        return "coach", "unreviewed tool: use corp-assistant"
    if date.fromisoformat(str(tool["review_by"])) < date.today():
        return "coach", f"{tool['id']} review overdue"     # fail closed on stale approvals
    if data_class == "restricted" and not tool.get("restricted_ok"):
        return "block", "restricted data not approved for this tool"
    if CLASS_RANK[data_class] > CLASS_RANK[tool["max_class"]]:
        return "block", f"{data_class} exceeds {tool['max_class']} for {tool['id']}"
    return "allow", tool["id"]

The same function backs a small self-service page where an employee picks a tool and a data class and gets an answer with the reason. Most policy questions are this one question, and answering it in seconds removes the main reason people route around the policy.

Intake, exceptions, reporting and training

Three processes keep the policy alive. Intake: a short form for requesting a new tool or a higher class for an existing one, with a target turnaround measured in days; if approval takes a quarter, people will not wait. Exceptions: time-boxed, owned, and recorded in the register with an expiry, never granted by email. Reporting: a plain instruction to report mistakes such as pasting customer data into a Tier 3 tool, routed to the incident process, with an explicit statement that prompt self-reporting is treated as a near miss, not a disciplinary matter. Early reports are what make containment possible: rotate a pasted secret, request deletion from the vendor, assess notification duties. Incident response for LLM systems covers the response side.

Training closes the loop. In the EU, the AI literacy duty in Article 4 of the AI Act has applied to providers and deployers of AI systems since 2 February 2025. The 2026 Digital Omnibus on AI softened its wording from ensuring a sufficient level of literacy to taking measures to support it, but did not remove it; check the current text with counsel. Whatever your jurisdiction, a short role-specific module (what the tiers mean, how to check output, how to report) is more effective than a general one, and completion records double as evidence.

Worked example: AI-drafted support replies

A support team asks to use AI to draft replies to customer tickets. Walk it through the policy. The data is customer correspondence with names, order details and sometimes addresses: Confidential, and occasionally Restricted if customers include card numbers or health details. The team's preferred tool is a consumer chatbot account: Tier 3, so not allowed. The company's enterprise assistant is Tier 1 with max_class: confidential, so it is allowed for most tickets.

The residual risks are restricted data inside tickets and unreviewed replies. Controls: a DLP rule that flags card-number and health-term patterns before submission; the policy clause that a human sends every reply; and a quarterly sample review of drafts for factual errors. If the team later wants the assistant connected to the ticketing system so it can read tickets directly, that is a connector request, with a read-only scope and no ability to send. The answer took one table lookup and two clauses, which is the test of whether a policy is usable.

Failure modes

Failure	What it looks like	Fix
Ban without alternative	Personal accounts on company data, no visibility	Provide a Tier 1 tool first, then restrict
Principles only	Every question escalates to security	Publish the matrix and a self-service check
Approval drift	Vendor changed terms, tier never revisited	Review dates in the register, fail closed
Prompt logging overreach	A log store full of customer data	Log decisions; retain content only with purpose
Slow intake	Requests queue for months, shadow use grows	Turnaround target, owner per request
Punitive reporting	Mistakes are hidden until discovered	Treat self-reports as near misses

Data that reaches a model through approved paths still needs lifecycle controls; data governance for LLM systems covers retention and deletion.

What to do next

Inventory AI tools in use from proxy logs and expense reports, including personal accounts.
Stand up at least one Tier 1 tool before restricting anything.
Create the tool register in git with tier, maximum data class, owner and review date.
Publish the data-by-tier matrix and the short list of special-use rules.
Configure SSO and SCIM, egress categories with a coaching page, and DLP for Tier 2 destinations.
Log decisions, not prompts, and define retention.
Launch intake, exception and reporting processes with named owners and turnaround targets.
Run role-specific training and keep completion records.

Key takeaway: An employee AI policy works when it answers real questions quickly and each rule has a control behind it. Tier tools by plan and configuration, publish one matrix of data class against tier, add a short list of rules for coding assistants, agents, published content and decisions about people, and enforce it with SSO, an egress proxy, DLP and decision logs driven from one register in git. Provide an approved tool before blocking others, and make reporting mistakes safe.