Most “AI policy templates” you’ll find online are written for one purpose: telling employees which chatbots they’re allowed to paste company data into. That’s a real need, and if that’s all you’re after, our AI Acceptable Use Policy Template covers it directly.
But if you run a SaaS company — especially one selling into Spain or the broader EU — an employee-use policy alone leaves a gap. You’re not just an AI user. If your product develops or substantially modifies an AI system and places it on the market, you may also be acting as an AI provider under the EU AI Act, with obligations that go well beyond employee tool use.
This guide gives you a full AI policy template built around that distinction, organized using what we call the SaaS AI Policy Stack™ — a five-layer structure that maps your policy to a risk-based approach instead of a flat, generic checklist.
Quick answer: A SaaS AI policy should cover your internal AI use, any AI built into your product, your provider/deployer status under the EU AI Act, risk classification for each AI system, data protection obligations, vendor controls, human oversight, incident response, training, and a review cadence. The free template further down gives you a starting structure to adapt — not a substitute for legal review.
What Is an AI Policy Template?
An AI policy template is a structured document that sets the rules for how a company develops, deploys, procures, and oversees artificial intelligence — covering everything from which tools staff can use to how AI-driven product features are assessed before launch.
It’s broader than an acceptable use policy (which governs day-to-day employee tool use) and narrower than a full governance framework (which covers organizational structure, oversight bodies, and long-term strategy). It’s the operating document that sits between the two.
AI Policy vs. AI Governance Framework vs. Acceptable Use Policy
If you’re not sure which document your company actually needs, start here:
| Attribute | AI Policy | AI Governance Framework | AI Acceptable Use Policy |
|---|---|---|---|
| Scope | Company-wide rules for building and using AI | Organizational structure, oversight bodies, long-term strategy | Day-to-day rules for employees using AI tools |
| Covers product AI? | Yes | Yes | No |
| Covers employee tool use? | Yes | Indirectly | Yes, in detail |
| Best for | Most SaaS companies as a single core document | Larger orgs needing committee-level oversight | Companies that only need tool-use rules, no product AI |
| Read next | This article | AI Governance Checklist | Acceptable Use Policy Template |
If you’re a small team with no AI product features, the Acceptable Use Policy alone may be sufficient. If you’re building AI into your product and selling into the EU, you likely need the fuller AI Policy below — and if you’re scaling toward a dedicated AI governance committee, the AI Governance Checklist is your next step up.
Why Generic AI Policy Templates Fall Short for Cross-Border SaaS
Here’s the gap most AI policy templates miss: they assume your company only uses AI. If your engineering team ships a feature that scores leads, personalizes pricing, moderates content, or generates customer-facing text, your company may also be building AI — and the EU AI Act can treat that differently depending on the circumstances.
The Act distinguishes between roles, broadly:
- Deployer — you use an AI system built by someone else (ChatGPT, Copilot, a sales-enrichment tool) under your own authority. Obligations generally center on oversight, instructions for use, and keeping usage within the system’s intended purpose.
- Provider — you develop, or substantially modify, an AI system and place it on the market or put it into service, including in some cases embedding third-party AI into your own SaaS product. Provider obligations can extend to risk classification, technical documentation, and, for certain systems, conformity assessment and post-market monitoring.
A company can be both at once — using AI internally for support tickets while also shipping an AI-powered feature to EU customers. Which role applies to a given system, and what it actually requires, depends on the specific facts and the Act’s definitions — this article is a starting structure, not a legal determination. For the primary source, use the official EU AI Act text on EUR-Lex rather than a summary site, and treat anything here as a starting point for your legal team, not a substitute for it.
If your company serves EU or Spanish customers, document which EU AI Act and GDPR provisions apply to your specific activities rather than assuming that customer location alone determines every obligation — territorial scope depends on the relevant provisions and what your company actually does, not simply where your customers are based.
The SaaS AI Policy Stack™
Rather than listing sections in no particular order, this framework builds your policy in five layers, each depending on the one before it:
| Layer | Key question | Output |
|---|---|---|
| 1. AI System Inventory | What AI are we actually using or building? | A complete list of AI systems and tools |
| 2. Role Classification | What is our role with each system? | Deployer / provider / both designation |
| 3. Risk Classification | What level of regulatory and business risk exists? | Risk category per system |
| 4. Control Mapping | What safeguards apply at each risk level? | A control set matched to risk |
| 5. Governance Operations | Who maintains this, and how often? | Owner, training, and review process |
Most competing templates only cover what we’re calling Layer 5, dressed up as a full policy. Layers 1–4 are what make this one operational rather than aspirational.
Core Policy Components
1. Purpose and Scope
State plainly why the policy exists and who it binds — employees, contractors, and any third party building on your behalf. Name the technologies covered: internal AI tools, embedded product AI, and AI-assisted decision-making. If you sell into the EU or Spain, note that here and reference the applicable jurisdictions your legal team has identified for your specific activities.
2. AI System Inventory (Layer 1)
Before you can classify anything, list it. A simple inventory table is the foundation the rest of the policy depends on:
| AI System / Tool | Owner | Purpose | Vendor | Data Used | Internal / Customer-Facing |
|---|---|---|---|---|---|
This is also the section that turns “we have an AI policy” into “we actually know what AI we’re governing” — and it’s usually the first thing a security reviewer or diligence process asks to see.
3. Role Classification (Layer 2)
For each system in your inventory, determine whether your company is acting as a deployer, a provider, or both. This is what separates a SaaS-specific policy from a generic HR template, and it’s one of the areas auditors, enterprise customers, and security reviewers are likely to examine closely.
4. Risk Classification (Layer 3)
The EU AI Act takes a risk-based regulatory approach. For practical policy design, we organize it into four broad buckets — prohibited practices, high-risk systems, specific transparency obligations, and lower-risk applications. These are TrusteraAI’s practical groupings for building a working policy, not four formally equal statutory risk tiers, and the Act’s specific conditions and exemptions still govern any individual case:
- Prohibited practices — certain uses (such as social scoring or manipulative techniques) are banned outright. Confirm none of your use cases fall here.
- High-risk systems — AI used in employment decisions, access to essential services, creditworthiness, education, and other Annex III contexts may be classified as high-risk, subject to the Act’s specific conditions and exemptions. This isn’t automatic — a hiring-adjacent tool isn’t necessarily high-risk on its own, and the classification depends on the actual function.
- Transparency obligations — certain AI systems that interact directly with people, generate synthetic content, or fall under other Article 50 scenarios carry specific disclosure requirements. This is narrower than “tell users any customer-facing tool is AI” — the obligations attach to specific categories and circumstances.
- Lower-risk applications — internal productivity tools like drafting assistants or code completion generally carry the fewest specific obligations under the Act, though your own internal risk assessment may still flag them if they touch sensitive data.
For scoring individual systems in more depth, pair this section with our AI Risk Assessment Checklist.
Control mapping (Layer 4): match your controls to the classification above rather than applying one rule set to everything:
| Risk / Role | Minimum Controls |
|---|---|
| Internal, lower-risk AI | Approved tool list, data-input restrictions, employee training |
| Customer-facing AI | Human oversight, applicable transparency disclosures, monitoring, vendor controls |
| Potentially high-risk AI | Formal risk assessment, documentation, human oversight, testing, legal review |
| Prohibited use | Do not deploy or use |
5. Acceptable and Prohibited Use
Set concrete rules: approved tools and the process for requesting new ones, prohibited inputs (customer PII, source code, unreleased financial data), and prohibited outputs (unreviewed AI content published under the company name, AI-generated legal or medical guidance to customers).
6. Data Handling and GDPR Alignment
This is where cross-border SaaS companies need the most precision. Cover:
- Data minimization for any AI system processing customer or employee data
- The applicable GDPR lawful basis for each processing activity — such as consent, contract, legal obligation, vital interests, public task, or legitimate interests, documented per use case rather than assumed
- For each AI vendor, determine whether it acts as a processor, sub-processor, independent controller, or another role, and document the corresponding requirements — including Article 28 processor terms where that role applies
- Cross-border transfer safeguards if AI processing happens outside the EU
For the underlying compliance detail, link out to your Spain GDPR Checklist for SaaS rather than duplicating it here.
7. Vendor and Third-Party AI Tools
Every AI tool you didn’t build in-house — from an embedded API to a full SaaS subscription — needs vetting before adoption: data processing terms, model training practices (does the vendor train on your inputs?), security certifications, and sub-processor disclosure. Third-party AI tools can introduce significant security, privacy, compliance, and supply-chain risk, so run new vendors through the full AI Vendor Risk Assessment before they’re approved, and reference that process here rather than rewriting it.
8. Human Oversight and Accountability
Name who owns AI governance (a single accountable role, even at a five-person startup), which decisions require mandatory human review before acting on an AI output, and how employees can escalate or override an AI-driven decision they believe is wrong.
9. Incident Response
Define what counts as an AI-related incident — a model producing harmful output, a data leak through a third-party AI tool, an automated decision that appears to have discriminated against a user — and route it into your existing response process rather than inventing a parallel one. Link directly to your AI Incident Response Plan here.
10. Training and Enforcement
Training frequency should be proportionate to your company’s AI use, risk profile, and applicable legal requirements — onboarding plus periodic refreshers may be appropriate for many startups, though higher-risk use cases can call for more frequent training. State consequences for violations clearly, tied to severity, matching whatever process already exists in your employee handbook.
11. Review Cadence
As an internal governance best practice — not a stated legal minimum — we recommend reviewing this policy at least every six months, plus an ad hoc trigger any time you ship a new AI-powered feature or a regulator issues new guidance. AI regulation is still being phased in through 2027, so treat this as a living document.
Step-by-Step: Building Your Policy
- Inventory every AI system across the company — internal tools and product features alike. You cannot classify what you haven’t listed.
- Determine your role for each system: deployer, provider, or both.
- Assess risk for each system using the categories above, noting that classification depends on specific facts, not just the tool’s category.
- Map controls to each risk level using the table above rather than a one-size-fits-all rule set.
- Assign an owner for ongoing governance — this doesn’t need to be a dedicated hire early on, but it does need to be one named person.
- Circulate for legal review, particularly the GDPR, provider/deployer, and vendor sections if you process EU personal data or embed AI in your product.
- Publish and train — a policy nobody has read isn’t a policy, it’s a document.
- Set your review trigger dates and put them on a calendar now, not “when we get to it.”
The Free AI Policy Template
Copy the structure below directly into your policy document. Bracketed items are yours to fill in.
[Company Name] AI Policy
Effective date: [date] | Owner: [name/role] | Next review: [date]
1. Purpose
This policy governs the responsible development, procurement, and use of artificial intelligence at [Company Name], including AI embedded in our products and AI tools used internally.
2. Scope
Applies to all employees, contractors, and third parties acting on [Company Name]’s behalf. Covers internal productivity tools, customer-facing AI features, and AI-assisted decision-making. This policy applies globally, with specific reference to EU AI Act and GDPR provisions applicable to our EU and Spain-based customer activities.
3. AI System Inventory
| AI System | Owner | Purpose | Vendor | Data Used | Internal / Customer-Facing |
|---|---|---|---|---|---|
| [system] | [name] | [purpose] | [vendor] | [data types] | [designation] |
4. Role Classification
| AI System | Role (Deployer / Provider / Both) | Basis for Classification |
|---|---|---|
| [system] | [role] | [brief reasoning] |
5. Risk Classification
| System | Category | Rationale |
|---|---|---|
| [system] | [Prohibited / Potentially High-Risk / Transparency Obligation / Lower-Risk] | [reason] |
6. Approved and Prohibited AI Tools
Approved tools: [list]. Prohibited systems: [list]. New tools must go through [approval process] before use.
7. Acceptable Use
AI tools may be used for: [list — e.g., drafting internal documents, summarizing meeting notes, code completion].
8. Prohibited Use
AI tools may not be used to: process customer PII without approval, generate unreviewed external communications, make final hiring or termination decisions without human review, or [company-specific prohibitions].
9. AI Procurement and Vendor Change Management
New AI vendors must complete [Company Name]’s AI Vendor Risk Assessment before approval. Material changes to an approved vendor’s model, training data practices, or sub-processors trigger re-review.
10. Data Handling and GDPR Compliance
All AI systems processing personal data of EU or Spain-based individuals must: minimize data collected, document the applicable GDPR lawful basis, determine each vendor’s role (processor, sub-processor, controller) and document corresponding requirements, and undergo legal review before deployment.
11. AI-Generated Content Disclosure
Where applicable under the EU AI Act or other relevant law, customer-facing AI-generated or AI-assisted content is disclosed to users using [method].
12. Testing, Monitoring, and Documentation
Higher-risk or customer-facing AI systems are tested before deployment and monitored on an ongoing basis. Documentation of purpose, data sources, and known limitations is maintained for each system in the inventory.
13. Human Oversight
[Named role] is accountable for AI governance. The following decisions require mandatory human review before action: [list].
14. Incident Response
Suspected AI-related incidents (harmful output, data exposure, discriminatory outcomes) must be reported to [role/channel] within [timeframe] and follow [Company Name]’s incident response process.
15. Training
Training is proportionate to role and AI use. All employees complete AI policy training at onboarding, with periodic refreshers.
16. Enforcement
Violations are addressed under [Company Name]’s standard disciplinary process, scaled to severity.
17. Exceptions
Exceptions to this policy require approval from [role] and are documented with a rationale and expiration date.
18. Review
This policy is reviewed at least every six months as an internal governance practice, and after any material AI product launch or regulatory change.
SaaS AI Policy Builder Worksheet
Use this quick worksheet per AI system to feed directly into Sections 3–5 of the template above:
AI system:
Purpose:
Owner:
Vendor:
Internal or customer-facing:
Provider, deployer, or both:
Personal data involved (Y/N, type):
Regulatory basis / applicable requirement:
Risk category:
Human oversight required (Y/N, describe):
Approved controls:
Review date:Run every system in your inventory through this worksheet once, then keep it updated as you add new AI tools or features.
Common Mistakes When Writing an AI Policy
- Treating it as an employee-only document. If your product has AI features, your policy needs a provider-side section, not just deployer rules.
- Skipping risk classification entirely. A flat list of dos and don’ts can’t demonstrate proportionate controls if a regulator or enterprise customer asks how you assessed risk.
- Writing it once and never touching it again. AI regulation is still being phased in, and most companies’ review cycles haven’t caught up.
- Leaving vendor AI out of scope. Third-party AI tools carry meaningful risk that an internally-built-systems-only policy will miss.
- Blurring legal requirements with internal best practice. Be explicit about which parts of your policy reflect a legal obligation and which reflect your own governance choices — it protects the company and keeps the document defensible.
- No named owner. A policy with no accountable person attached rarely survives its first year.
FAQs
Do startups actually need an AI policy, or is this only for enterprises?
Any company using AI tools with customer or employee data — even a two-person startup — benefits from a written policy. Enterprise customers and investors increasingly ask for one during due diligence, and having one in place before an incident happens is far cheaper than writing one after.
Is an AI policy legally required under the EU AI Act?
No single document called “AI policy” is generally mandated by name. But depending on your role and the systems involved, the Act can require specific documentation, risk management processes, human oversight measures, and records. A written AI policy can provide a practical way to organize, document, and communicate how those requirements are being addressed.
How is this different from a data protection policy?
A data protection policy governs personal data broadly under GDPR. An AI policy is narrower and specifically addresses how AI systems are developed, procured, and used — though the two should reference each other, particularly in the data handling section above.
How often should we update our AI policy?
As an internal governance best practice, review it at least every six months, plus immediately after launching any new AI-powered feature or when regulatory guidance changes — the EU AI Act’s obligations are still being phased in through 2027.
What’s the difference between “deployer” and “provider” under the EU AI Act?
Broadly, a deployer uses an AI system someone else built, under its own authority. A provider develops or substantially modifies an AI system and places it on the market or puts it into service. A SaaS company can be both — using ChatGPT internally (deployer) while shipping an AI-powered feature to customers (potentially provider) — and which applies depends on the specific facts, not just the presence of AI in the product.
Related Resources
- AI Governance Checklist for SaaS — the broader governance framework this article builds on
- AI Acceptable Use Policy Template — narrower, employee-focused version
- AI Vendor Risk Assessment — vetting process referenced in Section 9
- AI Risk Assessment Checklist — for scoring individual systems
- AI Incident Response Plan — the process referenced in Section 14
- Spain GDPR Checklist for SaaS — underlying GDPR detail
Sources referenced:
Primary regulatory sources — EU AI Act (EUR-Lex) · GDPR (EUR-Lex) · AEPD (Spanish Data Protection Authority)
Complementary frameworks — NIST AI Risk Management Framework · OECD AI Principles
This article provides a general governance framework and is not legal advice. Consult qualified legal counsel to confirm how the EU AI Act and GDPR apply to your specific business.