Business practice
AI use policy.
Answer the AI question your enterprise customers, SOC 2 auditor and cyber insurer are all asking, with one document your team has actually signed. You get an AI acceptable use policy built for SaaS and AI companies: tools tiered, data classes in plain language, a named owner and a review date.
The security questionnaire asks whether you have a written AI acceptable use policy. There's no box for "we're working on it."
The question showed up without warning, and now it's everywhere: enterprise customers' security questionnaires and vendor reviews, your SOC 2 audit, the DPA a customer's legal team sends over, and your cyber insurance renewal. It's usually a yes or no field. Answering no doesn't fail you on the spot. It moves you into a category with more questions, a longer review, a slower deal and, at renewal, sometimes a different premium.
Within a few weeks the answer is yes, and it holds up when someone reads past the first page. Tools are tiered, data classes are defined, everyone on your team has acknowledged the policy in writing, and you can hand the whole thing to a security reviewer, an auditor or an underwriter without a cover note. The dread attached to that question goes away, and it stays away, because the policy has an owner and a review date.
The approach
Tier, classify, sign.
Tier.
Tools land in one of three tiers: sanctioned, permitted with conditions, and prohibited. A policy that bans everything gets ignored, and an ignored policy is worse than none, because it proves the rule is optional.
Classify.
The real question is never which tool. It's which data. Customer data, support tickets and call recordings, contracts and pricing, source code and API keys, and internal documents each get an explicit rule, written in language a new hire understands on the first read.
Sign.
A policy nobody acknowledged is a draft. Everyone on the team signs, the acknowledgments are filed where your auditor can find them, and the policy goes into onboarding, so the next hire signs it in their first week without anyone remembering to ask.
Recognize this
The question is already in your inbox.
- An enterprise customer's security questionnaire asked about AI use, and you answered carefully.
- You have a policy template saved somewhere that nobody has finished or circulated.
- Your SOC 2 auditor asked how AI use is controlled, and the honest answer lives in a Slack thread.
- Your team asks which tools are allowed and gets a different answer depending on who they ask.
- A customer has started adding AI terms to their DPA or contract redlines.
The work
Four parts, and none of them optional.
The written policy
Scope, definitions, permitted and prohibited uses, review obligations, and what happens when the rule is broken. Written for your company, your customer contracts and your obligations, not a template with the name swapped in. Short enough that people finish it.
Tool tiering
A named list of the tools you sanction, the ones permitted under conditions, and the ones that aren't to be used with customer data. The list has an owner and a review date, because vendors change their terms and features all the time, and a tiering nobody revisits goes stale.
Acknowledgment and rollout
A signature page, a filing process, and a working session with the team so the policy is understood rather than merely distributed. Adoption is the deliverable. A signed page from someone who didn't read it protects nobody.
The review cadence
A named owner and a scheduled review date, so the policy stays accurate as tools change. This is the part that turns a document into governance, and it's the part most companies leave out.
Related reading.
All insights Governance
The AI policy your insurer and your customers will ask about
Most companies meeting the AI policy question for the first time do one of three things. They answer no and hope it doesn't matter. They answer yes on the strength of a template somebody downloaded and never circulated. Or they leave it, come back to it, and eventually submit
Governance
Shadow AI is already in your company. Here's the map
Ask a CEO how many AI tools are in use across the company and you'll usually hear about the ones on the invoice. Ask the team anonymously and the list gets longer: free chatbot accounts, browser extensions, meeting notetakers, and AI features switched on inside software you
Questions
Asked before, answered plainly.
No, and we say so on the first call and inside the policy itself. It's an operational policy: which tools are sanctioned, what data may go into them, and how your team acknowledges the rules. Have your counsel review it. It's written so that review is quick and inexpensive rather than a rewrite.
You can, and a template is better than nothing. The difference shows up in the follow-up question. A generic policy doesn't name your tools, doesn't match your data classes, and doesn't survive the moment a security reviewer, an auditor or an underwriter asks how it's enforced. The document is the easy half. Tiering, acknowledgment and a review date are the half that makes it defensible.
Good, because a prohibition policy fails. The tiering exists so useful work keeps going under conditions that are safe and written down. The goal is to move usage from invisible to sanctioned, not to remove it. Ban it outright and the same activity moves to personal devices and personal accounts, where nobody can see it.
It's not required, and it makes the policy a lot better. Rules written for tools you haven't confirmed are in use end up aimed at the wrong things. That's why we usually suggest the shadow AI exposure review first. Its findings become the tiering list.
The policy and the tiering come together quickly. The gate is acknowledgment, because you can't claim a policy is in force before your team has signed it. Schedule the rollout session promptly and you can be answering yes within a few weeks, with the signature file to back it up.