The Question
Your organization needs an AI security policy. You know this because employees are using AI tools without guidelines, because regulators are beginning to ask about AI governance, and because your legal team has raised concerns about liability exposure from uncontrolled AI use.
The challenge is writing a policy that actually works — one specific enough to be enforceable, practical enough that the business will not immediately route around it, and comprehensive enough to satisfy legal review without being so comprehensive that it becomes shelfware nobody reads.
AI security policy directly addresses OWASP LLM02: Sensitive Information Disclosure and LLM06: Excessive Agency — the two risk classes most frequently triggered by uncontrolled employee AI use and misconfigured AI deployments.
Why This Matters Now
In early 2023, Samsung discovered that three separate employees had submitted proprietary source code and internal meeting notes to ChatGPT within a single month. Samsung had no AI security policy at the time. There was no guidance prohibiting the submission of proprietary data to external AI services. The employees were not acting in bad faith — they were using available tools to do their jobs more efficiently.
Samsung's response — a blanket ChatGPT ban — illustrated the failure mode of policy-by-incident: a restrictive prohibition issued in reaction to an event, with no positive guidance on what employees should do instead. Blanket bans do not address the underlying need that drove Shadow AI adoption. They drive it underground.
The Air Canada case of the same year illustrated a different failure mode: no policy governing what AI systems were permitted to commit to on the company's behalf. Air Canada's chatbot made representations about bereavement fare policies that were factually incorrect. A Canadian tribunal ruled that Air Canada was liable for those commitments. The chatbot was operating without a policy that defined the scope of its authority.
Both failures — uncontrolled employee AI use and unscoped AI system authority — are policy failures that a well-constructed AI security policy would have prevented.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Security CURVE™ Report covers the AI Governance & Compliance vendor category — Credo AI, Zenity, Arthur AI, OneTrust, and others — which includes policy management platforms and compliance frameworks relevant to AI security policy development.
The leading AI security policy frameworks available in 2026 include the NIST AI Risk Management Framework 1.1, the EU AI Act's governance requirements for high-risk AI systems, and the OWASP AI Exchange's guidance on organizational AI security controls. Each provides a framework; none produces a ready-to-implement policy for your specific environment.
The full governance vendor landscape is in the 2026 AI Security CURVE™ Report — free to download.
What the CURVE™ research consistently found: the enterprises with effective AI security policies had built them collaboratively — security, legal, HR, and business unit leadership involved in drafting — rather than having security write a technical policy in isolation. Policies written without business input are routinely bypassed; policies written with business input are more likely to reflect actual workflows and receive genuine compliance.
The Gap Most Buyers Miss
Most AI security policies fail in one of two directions.
Too vague — "Employees must use AI responsibly and protect company data." This satisfies the checkbox that a policy exists. It provides no actionable guidance, creates no enforceable standard, and would not have prevented the Samsung incidents because it does not specify which data types cannot be submitted to which AI systems.
Too restrictive — a blanket prohibition on AI tool use without approved alternatives. This policy fails on contact with the business. Employees who found AI tools valuable will continue using them through personal devices, personal accounts, and undisclosed workarounds. The policy creates a compliance theater rather than actual risk reduction.
The policy that works sits in the specific middle ground: it defines which data types are prohibited from which AI systems, provides approved alternatives for common use cases, and includes enforcement mechanisms that are proportionate and technically feasible. Specific, not sweeping. Enabling, not purely prohibitive.
Five elements every AI security policy needs:
1. Data classification mapping — specify which data categories cannot be submitted to external AI tools. Source code, personally identifiable information, protected health information, non-public financial information, M&A-related content. The list should be specific and tied to your existing data classification framework. "Sensitive data" is not a policy; "Tier 1 confidential data as defined in the Data Classification Standard" is.
2. Approved AI tool register — maintain a list of approved AI tools for specific use cases, with the data types each is permitted to process. Employees who know what is approved are more likely to use approved tools than to seek unapproved alternatives. The register also gives security visibility into AI tool usage patterns.
3. Agentic AI authority scope — define the limits of authority for AI systems operating on the organization's behalf. Which systems can send communications? Which can modify records? Which can execute financial transactions? The authority scope should be defined at the system level, not inferred from technical permissions.
4. Incident reporting obligation — require employees to report suspected AI security incidents — anomalous AI behavior, suspected data exposure through AI tools, AI outputs that appear to reflect internal data inappropriately. Employees who encounter AI security incidents and do not know they should report them create silent failure modes.
5. Policy review cadence — AI capabilities and risk profiles change faster than annual policy cycles. Commit to a defined review cadence — quarterly for the approved tool register, semi-annual for the full policy — and designate an owner responsible for keeping the policy current.
Questions Your Buying Team Should Be Asking
1. Does your AI security policy reference your existing data classification framework? AI security policy should not create a parallel classification system. It should map AI-specific restrictions onto the data classification framework your organization already operates.
2. Have you involved HR and legal in the policy drafting process? HR owns the enforcement mechanisms that make policy violations consequential. Legal owns the liability exposure that uncontrolled AI use creates. Both need to be in the drafting process, not reviewing the output after security has written it.
3. Does your policy address AI systems operated on your behalf, not just employee use of AI tools? The Air Canada liability case was not about employee tool use — it was about an AI system the company operated making commitments the company was held to. Your policy needs to address both the supply side (what AI your employees use) and the demand side (what AI systems you deploy that interact with customers, partners, or the public).
4. How will you enforce it? A policy without enforcement mechanisms is aspirational documentation. Identify the DLP controls, monitoring capabilities, and HR consequences that give the policy teeth before you publish it.
5. What is the approved alternative for each prohibited behavior? For every restriction in the policy — every prohibition on submitting certain data to certain AI tools — there should be a stated approved alternative. "You cannot submit source code to ChatGPT; the approved tool for code assistance is [X]." Without the alternative, the prohibition creates friction without reducing risk.
The Stackcurve Take
AI security policy is not primarily a legal document. It is a risk management tool that happens to have legal form. The measure of a good AI policy is not whether it would survive legal review — it is whether it would have prevented the Samsung incidents, the Air Canada liability case, and the dozen similar incidents that did not make headlines.
Write the policy to address specific, documented risk scenarios rather than to satisfy a compliance checklist. The Samsung scenario (employee submits proprietary data to external AI) and the Air Canada scenario (AI system makes unauthorized commitments) are your test cases. A policy that would have prevented both is a good policy. A policy that passes legal review but would not have prevented either is documentation.
The collaborative process is not optional. Security teams that write AI policy in isolation produce documents that the business routes around. The business units that use AI most heavily are your policy design partners — not because you need their permission, but because their participation produces a policy that reflects actual workflows and has a realistic chance of genuine compliance.
The 2026 Stackcurve AI Security CURVE™ Report covers the AI Governance & Compliance vendor landscape for organizations building formal AI policy and compliance programs. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.