Your employees are already using AI at work, with or without your approval. IBM's 2025 Cost of a Data Breach Report found that 13 percent of organizations had a breach involving AI models or applications, with 97 percent of those lacking proper AI access controls. One in five organizations suffered a breach specifically due to shadow AI, and 63 percent of breached organizations had no governance policy for AI in place at all.

An AI policy is the document that closes that gap. It tells everyone in the organization which AI tools are approved, what data is allowed into them, what uses are off limits, and what happens when the rules are broken. In 2026 the absence of one is treated by regulators, auditors, insurers, and enterprise customers as a governance failure. The major frameworks now require it: ISO/IEC 42001 Clause 5.2 obliges senior leadership to establish and maintain an approved AI policy, the NIST AI RMF Govern function calls for the same, and the EU AI Act has required AI literacy across staff since February 2025.

This guide gives you two things: the sections an effective enterprise AI policy has to cover, and a ready-to-adapt template built around the four areas that matter most — acceptable AI use, employee guidelines, third-party AI usage, and large language model use. If you have already set up your governance frameworks and risk process, this is the document that turns them into rules people can follow.

What Is an Enterprise AI Policy?

An enterprise AI policy is a written set of rules that governs how an organization and its people use artificial intelligence. At minimum it defines which tools are sanctioned, what data may be entered into them, which uses are prohibited, who is accountable for outputs, and how the policy is enforced and reviewed.

It helps to separate two related documents. An AI acceptable use policy (often shortened to AUP) is the employee-facing rulebook for day-to-day behavior, covering which tools people may use and what they may do with them. An AI governance policy is broader and program-level, covering risk assessment, vendor review, model inventory, and committee structure. The acceptable use rules are the operative core, and for most enterprises the AUP sits inside the wider governance program. This article focuses on the policy and template that employees actually read and sign.

Why every enterprise needs one comes down to exposure. Without a documented policy there is no legal basis to enforce AI rules or take disciplinary action, no way to assess liability when an AI-related incident occurs, and no answer for an auditor who asks how AI risk is managed. A policy also protects the upside. Clear rules let people use AI productively instead of either avoiding it or quietly routing company data through unapproved tools.

What an Effective AI Policy Must Cover

A complete policy is built from a consistent set of sections. The table below is the structural checklist. The template that follows turns each one into usable language.

Two design principles run through all of it. Avoid blanket bans, because a rule that says "never put company data into AI" is unenforceable and drives usage underground where you lose all visibility. And avoid vague aspiration, because "use AI responsibly" is not a policy. People need specific, actionable lines they can see.

The AI Policy Template

The template below is written to be copied and adapted. Replace every placeholder in [brackets] with your own details. Keep the approved tools list and data rules in an appendix you can revise on their own, since those change faster than the rest of the document. Distribute the final version for employees to acknowledge in writing, and have legal review it before adoption.

1. Purpose, Scope, and Definitions

Purpose: This policy governs the use of artificial intelligence tools and services by everyone acting on behalf of [Organization Name]. Its objectives are to enable productive and responsible AI use, protect company and customer data, meet legal and regulatory obligations, and reduce legal, security, and reputational risk.

Scope: This policy applies to all employees, contractors, consultants, and temporary workers, referred to here as Users, who access AI tools using [Organization Name] systems, networks, accounts, or data, whether on company or personal devices and whether on site or remote. It covers all AI-powered tools, including AI writing and chat assistants, code generation tools, image and audio generators, AI analytics, and AI features embedded inside other software such as Microsoft 365, Salesforce, or similar platforms. It does not cover internally developed AI models that are subject to [Organization Name]'s separate model risk management process.

Definitions:

• Artificial intelligence refers to engineered systems that generate outputs such as predictions, recommendations, content, or decisions.
• Generative AI refers to systems that create new text, code, images, or audio.
• A large language model (LLM) is a generative AI model trained on text, such as the models behind ChatGPT, Claude, Gemini, and Copilot.
• Automated decision-making refers to AI that makes or materially informs a decision affecting a person.
• Sensitive data refers to any information classified as Confidential or Regulated under Section 2.

2. Acceptable AI Use

This section is the operative heart of the policy. It sets out what Users may and may not do, which tools they may use, and what data those tools may see.

Approved tools: Users may only use AI tools that appear on the approved list in Appendix A. The list places each tool in one of three tiers:

• Approved: Vetted by IT and Security under an enterprise license, cleared for the data tiers stated next to it.
• Conditionally approved: Permitted for specific use cases with additional controls, requiring manager or Security sign-off before use.
• Prohibited: Banned on security, privacy, or compliance grounds and blocked where technically possible.

To request a new tool, submit it to [IT Security contact or process]. Do not use a tool for work before it is approved.

Data classification rules: What you may put into an AI tool depends on how the data is classified. The plain-language rule is simple: if you would not post it publicly on the internet, do not put it into a non-enterprise AI tool.

Tiered approval by use case: Not every use carries the same risk, so approval scales with it:

Prohibited uses: Regardless of tool or data tier, Users must never use AI to do any of the following:

• Enter Regulated data into any tool not explicitly cleared for it.
• Make a final decision about a person's employment, credit, or access to services without human review.
• Generate content that is discriminatory, harassing, deceptive, or unlawful.
• Misrepresent AI-generated content as solely their own original work where attribution matters.
• Bypass, disable, or alter the company's AI logging, data-loss-prevention, or security controls.

3. Employee Guidelines

These guidelines set the expectations every User is responsible for meeting.

Human accountability: AI output is the responsibility of the person who used it. Every AI-generated output, whether a contract summary, a customer email, a code commit, or an analysis, must be reviewed by a qualified human before it is used, sent, or published. Treat AI as a capable assistant whose work you check, not an authority you defer to.

Verify before you trust: AI tools, especially LLMs, can produce confident answers that are wrong or fabricated. Do not rely on AI output for facts, figures, legal points, or anything customer-facing without independent verification against a trusted source.

Protect data: Apply the data classification rules in Section 2 every time. Never paste credentials, API keys, customer records, or unreleased information into a tool that is not cleared for it. When in doubt, treat the data as more sensitive rather than less.

Be transparent: Disclose the use of AI where it matters, including where a customer, colleague, or regulator would reasonably expect to know that content or a decision was AI-assisted. Follow any sector-specific disclosure rules that apply to [Organization Name].

Intellectual property: Outputs created with approved company tools for company purposes are the property of [Organization Name]. Legal review is required before externally publishing AI-assisted material in any context where IP ownership or originality is material.

Report problems: If you discover an AI-related incident, a data exposure, a harmful output, or an unapproved tool in use, report it to [reporting contact] promptly. Reporting in good faith will not result in penalty.

Training: Users must complete [Organization Name]'s AI awareness training before using AI tools for work and at the cadence set by the company. This requirement supports the AI literacy obligations that apply under regulations such as the EU AI Act.

4. Third-Party AI Usage

Third-party tools and vendors are where a great deal of AI data exposure happens, often through features employees enable without realizing it. This section governs both the AI tools the company buys and the AI built into tools it already uses.

Vendor due diligence: No AI vendor or AI-enabled product may be adopted for work involving Internal, Confidential, or Regulated data until it has passed a due diligence review covering, at minimum, the questions below:

• Will our inputs, outputs, prompts, or metadata be used to train or fine-tune the vendor's models?
• Where is our data processed and stored, and how long is it retained?
• Which sub-processors and third-party AI services does the product rely on?
• What data isolation, encryption, and access controls are in place?
• Can the vendor provide a data processing agreement, a SOC 2 report, and a business associate agreement where health data is involved?
• What is the breach notification commitment?
• For consequential decisions, how is the model tested for bias, and can the vendor evidence it?

Contract requirements: Approved AI vendors must operate under a contract that prohibits the vendor from using company inputs, outputs, prompts, or metadata to train, fine-tune, or evaluate their models without written consent. Data processing agreements should be updated to include explicit AI training restrictions. A tool that offers only a consumer-grade opt-out rather than a contractual commitment is not approved for work involving non-public data.

Risk-tier your vendors: Assess AI vendors by the impact of their AI, not by brand. A tool that recommends restaurants is low risk. A tool that screens candidates or scores credit is high risk and warrants enhanced due diligence on the same level as a critical IT provider. Standardize on a small set of pre-vetted providers wherever possible to reduce both risk and review burden.

Embedded AI features: Many products add AI features through updates. Users must not enable AI features in third-party software for work involving non-public data until [IT Security] has reviewed the feature's data handling. IT will monitor vendor terms-of-service changes for new AI data-use provisions.

Ongoing monitoring: Vendor review is not a one-time event. Reassess high-risk AI vendors annually and on event triggers such as a security incident, a major product change, a new sub-processor, or a change to the vendor's data terms.

5. LLM Policy

Large language models deserve their own rules because they are the most widely used and the most easily misused category of AI tool. This section sits on top of the general rules above.

Enterprise versus consumer tiers: The line that matters is the contract, not the brand. Enterprise licenses of tools such as ChatGPT, Copilot, or Gemini typically include a data processing agreement and a commitment not to train on your data. Free and consumer tiers usually do not, and may use your inputs to train models. Users may only use enterprise-licensed LLMs for any work involving Internal, Confidential, or Regulated data. Consumer-tier LLMs are limited to Public data.

Training opt-out is mandatory: Every approved LLM must be configured so that company data is excluded from model training. Where a vendor changes its default to train on user data, as happened with consumer tiers of at least one major coding assistant in 2026, that tool drops to prohibited for non-public data until an enterprise configuration is in place.

Data into prompts: Apply Section 2 to every prompt. Do not paste Regulated data into any LLM that is not explicitly cleared for it. Do not paste proprietary source code into a non-enterprise LLM. Where the company provides anonymization or redaction tooling, use it for prompts that include borderline data.

Logging and oversight: LLM interactions through approved enterprise tools may be logged for security and audit purposes. Users will be informed of monitoring during onboarding. High-severity decisions informed by LLM output require human sign-off.

AI-assisted code: AI coding assistants are subject to extra rules. All AI-generated code must pass human review and testing before it reaches production. AI must not be used to write authentication, authorization, cryptography, or payment-processing code without senior engineer sign-off. AI logging and secrets-scanning controls must not be disabled.

6. Monitoring, Enforcement, and Review

Monitoring: [Organization Name] monitors AI tool usage through network logs, DLP controls, access audits, and usage reports from approved platforms. Monitoring practices are disclosed to Users during onboarding and training.

Enforcement: Violations of this policy may result in disciplinary action up to and including termination, applied consistently by [HR or the relevant function]. Technical controls support the policy, including allowlisting of approved tools, network-level blocking of prohibited tools, and data-loss-prevention rules that flag sensitive data sent to AI services.

Ownership and review: This policy is owned by [named owner or committee]. It is reviewed at least quarterly and out of cycle whenever a tool is approved or banned, a vendor changes its data terms, the data classification scheme changes, a material AI incident occurs, or a regulation such as the EU AI Act reaches a new milestone. Each version records a version number, review date, and owner.

How to Roll Out and Enforce the Policy

A policy that sits in a shared drive protects no one. The most common failure mode for AI policies is rollout, not drafting. Four things turn the document into a working control:

1. Get acknowledgment: Have every employee and contractor read and sign the policy during onboarding and after each material update. Track the acknowledgment rate as a metric.
2. Back every rule with a control: A clause that says do not paste regulated data into a public LLM does nothing without a way to enforce it. Pair the policy with allowlisting, network blocking, and data-loss-prevention that inspects prompts in real time. A wall with no gate is not security.
3. Train people on the why: Employees follow rules they understand. Explain the risks behind the rules, not just the rules, and run training that satisfies AI literacy obligations.
4. Build the review cycle in: AI tools and vendor terms change monthly, and regulations phase in through 2027 and beyond. Set explicit triggers that override the scheduled review so updates actually happen.

Avoid the predictable mistakes. Being too restrictive drives AI underground and destroys visibility. Being too vague leaves employees guessing. Skipping enforcement turns the policy into a suggestion. And forgetting the update cycle leaves you defending last year's rules to this year's regulator.

How CogitX Helps Enforce Your AI Policy

Writing the policy is the easy half. Enforcing it across dozens of tools, agents, and teams is the hard half, and that is what CogitX is built for.

CogitX is an enterprise AI platform that lets large organizations build, deploy, and manage AI agents with policy controls in the platform rather than bolted on afterward. The rules in a policy like the one above - data classification limits, approved-tool boundaries, human oversight on high-severity actions, and full audit logging - become enforceable controls when AI runs through a governed layer instead of a sprawl of unmanaged tools. Teams across customer support, HR, finance, IT, manufacturing, and supply chain get a place to use AI within the rules, while CIOs and compliance leaders get the usage records and evidence that ISO 42001, the NIST AI RMF, and the EU AI Act all expect. The policy stops being a document people sign and forget, and becomes the way AI actually operates.

Frequently Asked Questions