AI adoption inside security teams is now near-universal. Tines' Voice of Security 2026 report found that 99% of SOCs use AI in some capacity. What hasn't kept up is the policy that's supposed to govern it. ISACA's 2026 AI Pulse Poll found 56% of digital trust professionals don't know how quickly they could shut AI down after a security incident. The policy was supposed to handle this.
Many teams start by adapting existing compliance and governance documents. That instinct fails. A generic acceptable use policy (AUP) governs employee behavior. It doesn't govern an AI agent acting on a hidden prompt, an approved platform's AI feature exfiltrating data nobody knew it could touch, or an AI tool deleting production resources through a credential it shouldn't have had.
This article provides a 12-section AI policy template with reusable language and shows how to turn it into running workflows that put governance into practice in production.
What is an AI policy?
An AI policy is the document that governs how an organization uses, monitors, and controls AI systems. Most are written for employees, like "don't paste customer data into ChatGPT." A security AI policy is written for the controls underneath that rule. It specifies the DLP that catches the paste, the monitoring that flags it, the incident response when both fail, and the vendor risk assessments that govern which AI platforms enter the environment in the first place.
NIST AI RMF 1.0 frames this as the GOVERN function: a cross-cutting requirement that supports every other risk management activity across an AI system's lifespan.
This distinction between behavioral rules and technical controls is why security teams need a policy of their own.
Why security teams need their own AI policy
Generic corporate AI policies leave gaps that security teams are expected to fill, but rarely have documented authority to own. A policy can describe acceptable use. An incident demands more than that. It requires clear ownership, defined escalation paths, decision authority, fallback options, and procedures that have been tested before the moment they're needed.
Security teams own monitoring, controls, incident response, and vendor risk. None of that lives in an AUP. A generic policy doesn't address AI agent governance, model change management, shadow AI discovery, or AI-specific incident classification. Each one is a different failure mode, and security is expected to handle them whether or not the policy formally assigns the work.
The pattern repeats across the breaches that make headlines. A company has a policy, an employee bypasses it, and no technical control catches the bypass. The governance document is the least important artifact, while the technical control layer is the most.
In Tines' Voice of Security 2026 report, 66% of teams with formalized AI policy said they were "very optimistic" about AI's impact, and 92% said an intelligent workflow platform would be extremely or very valuable to their team. Governance is not the brake on adoption. For security teams, it's what makes faster adoption survivable.
These gaps define the scope of what an AI policy must actually cover.
What an AI policy should cover
A security-focused AI policy must cover the full surface area where AI intersects with organizational risk.
AI tools employees use directly: ChatGPT, Claude, Gemini, Copilot, and the tools that arrive faster than the security review can keep up.
Internal models and agents the organization builds: Custom RAG pipelines, fine-tuned models, internal agents wired into production systems.
Third-party AI embedded in existing platforms: The AI features added to tools you already approved, like Microsoft 365 Copilot or Salesforce Einstein.
Data flows into and out of AI systems: What's submitted, what's retained, what's used for training, and what gets logged.
Logging and monitoring of AI interactions: Prompts, outputs, model decisions, and the records that let you reconstruct what happened.
Incident response for AI failures: What happens when any of the above breaks, leaks, or behaves outside its guardrails?
The scope extends beyond what most teams initially consider. AI features keep getting added to platforms you already approved, and that's where the next class of governance failures will land. Tines' internal data shows 302% year-over-year growth in customer LLM usage. The pattern is consistent: AI usage outpaces the review process designed to govern it.
AI governance turns on a single question: not "can AI do this?" but "should AI do this?" The policy is how you answer it before the agent runs. Through an intelligent workflow platform, security teams can handle deterministic rules, agentic reasoning, and human approval in one governed environment. The same model also applies outside security.
Core sections of an AI policy template
Every security team needs an AI policy. Each section below addresses a distinct governance failure mode. The framework references map to NIST AI RMF 1.0 and ISO/IEC 42001:2023, and also draw on OWASP guidance for LLM application risks.
1. Purpose and scope
This section establishes what the policy governs and who it applies to. NIST AI RMF GV 1.1 and GV 1.2 require that legal, regulatory, and trustworthiness requirements be documented and integrated into organizational policies.
2. Roles and responsibilities
Ownership of AI risk should be clearly defined. Most organizations use a Responsible, Accountable, Consulted, Informed (RACI) matrix to assign roles. Without one, the conversation about AI accountability happens for the first time during an incident, which is the moment governance fails.
The matrix should specify which roles own which controls: CISO and security teams for access policies and monitoring, compliance and risk for framework mapping, AI and engineering for model changes, HR and legal for acceptable use.
3. Data classification and handling rules for AI tools
Existing data classification tiers should map to AI ingestion permissions. Data classified as Confidential, Restricted, personally identifiable information (PII), or protected health information (PHI) should not be submitted to AI systems in unmasked form. The policy must specify how classification applies to retrieval-augmented generation (RAG) architectures, prompt caching, and fine-tuning.
4. Approved, tolerated, and prohibited tools register
A living registry works better than a static list. Three tiers work in practice: approved (security-reviewed, contractually governed), tolerated (known, monitored, not yet fully reviewed), and prohibited (blocked at the network layer).
Static lists go stale within a quarter, but a registry that updates with every new tool request stays current.
5. Human-in-the-loop and verification requirements
This section covers which AI outputs require human verification before action and which AI agents require human approval before execution. OWASP's LLM Top 10 2025 puts the principle directly: human approval for high-risk actions, human-in-the-loop controls for privileged operations. The follow-up rule matters as much as the rule itself: the human must be qualified and instructed, and the workflow must protect against approval fatigue.
6. Logging, monitoring, and audits
The policy should specify what gets logged (prompts, outputs, model decisions, data flows), where logs are stored, and who reviews them. Three monitoring signals matter most: inference refusal tracking, model drift detection, and prompt and output logging. Together they give you the audit trail you need when something goes wrong, and the early warning when something is about to.
7. Incident reporting and response for AI events
An AI-specific incident classification taxonomy separates model-layer failures (training data poisoning, prompt injection, RAG manipulation) from application-layer failures. Incident response plans must account for vendor AI supply chain incidents, where the failure originates outside the perimeter but the impact lands inside it.
8. Access control and authentication for AI systems
Access to AI systems, APIs, training datasets, and AI-generated outputs shall be governed by role-based access control (RBAC) and the principle of least privilege. Multi-factor authentication (MFA) shall be required for all AI platforms and administrative interfaces.
9. Encryption, masking, and retention
Data in transit to and from AI systems shall use TLS 1.2 or higher. Data at rest, including training datasets, model weights, and prompt logs, shall use AES-256 encryption. Data classified as Confidential, Restricted, PII, or PHI shall be masked before submission to any AI system.
10. Vendor risk and model change management
Vendors should provide advance written notice before implementing material changes to model versions, training data, capabilities, or data handling practices. The policy should treat any silent model swap as a security event, not a routine update.
11. Exception requests and approval process
A tiered approval structure handles the range of exception risk levels. All exceptions are time-bound and require business justification, a named accountable owner, and risk mitigation measures. No exception runs forever.
12. Review cadence and update triggers
A policy that updates annually is already outdated. Calendar-based reviews matter less than trigger-based ones: vendor model updates, AI security incidents, new regulation effective dates, and confirmed shadow AI deployments all force out-of-cycle review. Two dates that should already be in your calendar: the EU AI Act's Annex III high-risk requirements take effect August 2, 2026, and Colorado's AI Act takes effect June 30, 2026.
The template language that follows turns these twelve sections into adoptable clauses.
Reusable AI policy template language
The four sections teams struggle with most benefit from skeletal language they can adapt directly.
A note before you copy this language: these clauses are starting points, not legal advice. Adapt to your jurisdiction, your existing policy stack, and the controls your legal and compliance teams sign off on. These are starting points. Have your legal and compliance teams review before adopting.
Data classification for AI tools: "Prior to submission to any AI system, data shall be classified per the organization's data classification policy. Data classified as [Confidential/Restricted/PII/PHI] shall not be submitted to AI systems in unmasked form. DLP controls shall enforce classification-based access rules at AI ingress points. Violations shall be treated as security incidents."
Approved tools register: "The security team shall maintain a registry of AI tools classified as Approved, Tolerated, or Prohibited. Approved tools have completed security review and contractual governance. Tolerated tools are known and monitored but await full review. Prohibited tools are blocked at the network layer. The registry shall be reviewed monthly."
Incident reporting: "AI security incidents shall be classified using the organization's AI incident taxonomy, which distinguishes model-layer failures (prompt injection, training data poisoning, RAG manipulation) from application-layer failures and vendor supply chain incidents. All AI incidents shall be reported within [timeframe] to [designated role]."
Exception handling: "Exception requests for prohibited AI platform use shall include: business justification, data types involved, proposed duration, risk mitigation measures, and named accountable owner. Section 11 defines who approves each exception tier. No exception shall be granted for longer than 90 days without re-review."
Policy language without technical controls is a document nobody reads. The next section shows how to turn these clauses into running workflows.
PDFs don't shut down agents
Bridging the gap between policy and execution means mapping every section to a control, then mapping every control to a workflow. In a 2025 Forrester study commissioned by Tines, 88% of respondents said that without orchestration, AI stays fragmented. That is exactly what a static policy produces. The three states a policy must handle (rules, judgment, exceptions) map directly to three workflow execution styles:
Deterministic workflows handle predictable rules: An AI access request lands in a form, the workflow checks it against the approved registry, and low-risk requests provision automatically. Intercom collapsed 15 separate workflows into one and cut build time from 2 months to 2 hours using this pattern.
Agentic workflows handle variable investigations: When a SIEM flags an AI usage anomaly, an AI Action reads the alert, queries historical patterns, and drafts a recommended response inside guardrails the team configured. Brex runs this under a strict bring-your-own-key policy and suppresses up to 90% of weekly alerts automatically.
Human-in-the-loop workflows handle judgment calls: An exception request lands in a form, the workflow assembles the risk context, and the approver gets an Approve/Deny prompt in Slack. Every decision lands in Cases, Tines' built-in ticketing and incident-management surface, for the audit trail.
Tines is the intelligent workflow platform built to run all three styles in one governed environment. Every story produces the audit trail compliance teams ask for, every AI Action runs inside the guardrails you define, and every exception, approval, and incident lands in the same system of record.
Your AI policy should be the artifact that's hardest to ignore, not hardest to find. If you're ready to turn yours from a PDF nobody reads into workflows that run, book a demo with Tines.
Frequently asked questions about AI policy
What is the difference between an AI policy and an acceptable use policy?
An AUP governs employee behavior: don't paste customer data into ChatGPT. A security AI policy specifies the DLP controls that apply that rule, the monitoring that detects violations, the incident response procedures when those controls fail, and the vendor risk assessments that govern which AI platforms enter the environment.
How often should an AI policy be updated?
Calendar-based reviews matter less than trigger-based ones. Vendor model updates, AI security incidents, new regulation effective dates, and confirmed shadow AI deployments all force out-of-cycle review. Most teams that get this right run a quarterly cadence with on-demand triggers layered on top.
What frameworks should an AI policy align to?
Commonly referenced AI governance and risk frameworks include NIST AI RMF 1.0, NIST AI 600-1 (the Generative AI Profile), ISO/IEC 42001:2023, and the OWASP Top 10 for LLM Applications. NIST IR 8596 targets security teams specifically and maps AI risk to CSF 2.0 controls.