Guides › AI acceptable use policy template

AI Acceptable Use Policy Template for Sensitive Data

Most AI acceptable use policies are a list of banned tools and a sentence about confidentiality, and the shadow AI numbers show how well that works. The policy below is written the other way around: it is organized by data class rather than by tool, it says what may be entered where and through which route, it covers connectors, projects and agents because those are where data now moves, and it names the logging and review that make it enforceable. Copy it, replace the bracketed terms, delete what doesn't apply, and have counsel read it against your obligations. Notes on why each clause is there follow the policy.

How to use this template

Three decisions have to be made before the text is useful. Decide your data classes; the template uses five, from public to restricted, and most organizations can map existing classification onto them. Decide which tools are approved at which tier, because the policy refers to an approved list rather than naming products, so that the list can change without a policy revision. And decide whether a governed route exists for regulated data, meaning a layer that scopes retrieval to the asker and substitutes identifiers before a third-party model; if it does, the policy can permit regulated use through that route, and if it does not, the policy has to prohibit it. The is it safe to put company data in AI page is the plain-language version of the same decisions for people who will read the policy.

The policy

Bracketed terms are placeholders. Section numbers are for cross-reference.

1. Purpose and scope

This policy governs the use of generative AI tools, assistants and agents by [Organization] workers, contractors and systems, in any setting where [Organization] data may be entered, uploaded, connected or retrieved. It applies to approved tools and to any other AI tool a worker might use for [Organization] work, on any device and any account. It supplements [Organization]'s information security, data classification and acceptable use policies and takes precedence where they conflict on AI use.

2. Data classes

Data is classified in five classes, defined in [Data Classification Standard] and summarized here. Public: approved for external release. Internal: not for external release, no personal or regulated content. Confidential: business-sensitive, including contracts, pricing, roadmaps, financials and source code without embedded secrets. Regulated: personal data, health information, financial records, controlled unclassified information, export-controlled technical data, and any data subject to a contractual confidentiality obligation that names it. Restricted: credentials, keys, tokens, connection strings, and any data designated restricted by [Security]. Where a document contains more than one class, the highest applies.

3. Approved tools and tiers

[Security] maintains the Approved AI Tools list, which names each approved tool, the plan tier under which it is approved, the data classes permitted in it, and the routes permitted (entry, upload, connector, agent). Only tools on the list may be used for [Organization] work. Consumer tiers of any tool are not approved for any data class above Public. A tool's presence on the list does not change the data class rules in section 4.

4. What may be entered, uploaded, connected or retrieved

Workers may enter, upload or connect data to an approved tool only as permitted for that data class and route in the table in this section. Regulated data may reach a third-party model only through the governed route described in section 5, in which retrieval is limited to the worker's own entitlements and identifiers are replaced before the data leaves [Organization]'s environment. Restricted data may not be entered, uploaded, connected or retrieved by any AI tool by any route. Workers must remove restricted data from any file before it is uploaded or connected.

5. Connectors, projects, custom assistants and knowledge features

Connecting a data source, uploading files to a project, custom assistant, notebook or similar knowledge feature, or creating a custom assistant that others may use, creates a copy or a live path to [Organization] data and is subject to this section. Connectors may be enabled only by [Platform Administrators] and only for sources listed in the Approved Sources register, after the source's permissions have been reviewed under [Access Review Procedure]. Uploads to a project or custom assistant are limited to the data classes permitted for that tool, and the project or assistant may be shared no more widely than the most sensitive document in it allows; organization-wide sharing is permitted only for Public and Internal content. The governed route for Regulated data is [Data Layer], which limits retrieval to the asking worker's entitlements, substitutes identifiers before content reaches a third-party model, and records every retrieval. Regulated data may be connected only through it.

6. Agents, tools and automation

AI agents, tool integrations and MCP servers that read [Organization] data or take actions on [Organization] systems may be deployed only from the Approved Agents and Tools catalog maintained by [Security], run under a documented identity with the least privilege the task requires, and chain only the tool combinations approved for that agent. An agent that can write, send, post or delete requires [Approver] sign-off and human approval for each such action unless an exception is recorded. Workers may not add unreviewed servers, tools or custom assistants against non-Public data.

7. Personal accounts and devices

[Organization] data of any class above Public may not be entered into, uploaded to or connected with an AI tool through a personal account, on any device. Approved tools are provided to every worker who needs them under [Organization]'s accounts; a worker who lacks access to an approved tool should request it through [Request Process] rather than use a personal alternative. Use of approved tools on personal devices is permitted only where [Device Policy] allows.

8. Logging, retention and monitoring

Use of approved tools under [Organization] accounts is logged by the tool's administrative audit facilities and, for connected sources, by [Data Layer]'s retrieval telemetry, which records which records were retrieved for which worker under identifiers that contain no sensitive content. Workspace retention for each approved tool is set by [Platform Administrators] to [Retention Period] and recorded on the Approved AI Tools list. [Security] may review logs to verify compliance with this policy, in accordance with [Monitoring Policy] and applicable law.

9. Outputs

AI-generated output used in [Organization] work is the responsibility of the worker who uses it. Output that will be relied on for a decision, sent externally, or incorporated into a deliverable must be reviewed by the worker for accuracy and for the inadvertent inclusion of data the recipient is not entitled to. Output containing restored identifiers from a governed route carries the data class of the underlying records.

10. Incidents

A worker who enters, uploads or connects data in a way this policy does not permit, or who observes such use, must report it to [Security Contact] within [Hours] hours. Reports made promptly and in good faith are treated as a control working. [Security] assesses each report against [Incident Response Procedure], including whether the disclosure triggers notification obligations.

11. Enforcement

Violations are handled under [HR Policy]. Enabling an unapproved connector, deploying an unreviewed agent against non-Public data, or entering Restricted data into any AI tool are treated as serious violations.

12. Review

[Owner] reviews this policy, the Approved AI Tools list, the Approved Sources register and the retention settings at least [Quarterly], and whenever an approved provider changes its data policy or an approved tool adds a route for data to move.

Notes on the clauses

Section 2 is organized by data class because a tool list goes stale monthly and a data class does not; the shadow AI data in the DLP and shadow AI guide is largely a record of policies that banned products and said nothing about data. Section 3 refers to a list rather than naming tools so that the list can change without a policy revision, and names the tier because consumer and enterprise tiers of the same product are different contracts, as the provider comparison sets out. Section 5 exists because connectors, projects and knowledge features are where data now moves, and a policy that covers only typing misses the high-volume route; the platform knowledge features page is the reference for what each feature does. Section 6 reflects the NSA's 2026 guidance that tool-connected AI is a distinct security problem, covered on the connector and MCP security page. Section 7 pairs the prohibition on personal accounts with a promise of provisioning, which is the only version of that clause the data suggests works. Section 8 is the clause that makes the rest enforceable; a policy without a record of what was retrieved for whom cannot be audited. Section 10 treats prompt reporting as a control rather than a confession, because nearly half of workers would rather hide AI use than ask.

Where Hardshell sits

Hardshell is the [Data Layer] the template refers to in sections 5 and 8. It connects to the systems where data already lives without migrating them, inherits their permissions and limits each retrieval to what the requesting worker is entitled to see, substitutes stand-ins for real identifiers before content reaches a third-party model, and records every retrieval under opaque IDs. It is what lets a policy permit Regulated data through a governed route instead of prohibiting the use people most want, and it deploys as a cloud service, in a private cloud or as an offline bundle.

Frequently asked questions

Should an AI acceptable use policy ban specific tools?

It should ban tiers and routes, and keep the tool list outside the policy. Consumer tiers for anything above Public, personal accounts for anything above Public, and unreviewed connectors and agents against non-Public data are the durable prohibitions. Product names change too fast to live in policy text.

Can the policy allow customer or patient data in ChatGPT or Claude?

Only if a governed route exists: an enterprise tier under contract, retrieval limited to the worker's entitlements, and identifiers substituted before the data leaves your environment. With that route, section 5 permits it. Without it, the honest policy prohibits it and the data moves to personal accounts anyway, which is why building the route is usually the better decision.

What frameworks does this policy map to?

NIST AI RMF's Govern function asks for exactly this kind of documented policy; ISO/IEC 42001 asks for an AI policy, roles and documented decisions, which sections 1, 3, 11 and 12 supply; the EU AI Act's obligations on deployers of high-risk systems are addressed through the approval and review clauses where they apply. The framework crosswalk covers the technical controls the policy refers to.

How often should it be reviewed?

Quarterly at minimum, and on every provider policy change or new route. Provider defaults, retention windows and feature sets changed several times in 2025 and 2026; a policy reviewed annually will be wrong for most of the year.

Who should own it?

Security owns the text and the approved lists, with legal review against the data classes' obligations and IT ownership of the platform settings the policy references. The retrieval record in section 8 should be owned by whoever would answer an auditor's question about what an assistant showed people.