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 whichever answer feels least likely to generate a phone call.
All three are understandable. Only one of them survives a follow-up question, and follow-up questions are becoming standard.
Why this appeared, and why it isn’t going away
Insurers don’t add questions for interest. They add them when a category of risk starts showing up in the data.
This one showed up in the breach data. In IBM’s 2026 Cost of a Data Breach Report, shadow AI was involved in 43% of the breaches studied, up from 20% the year before. From an underwriting perspective that’s a straightforward risk signal, and the cheapest way to price it is to ask a yes or no question on the application.
The same question now arrives through other doors, and for most SaaS companies those doors open far more often than the renewal does. Enterprise customers’ security questionnaires ask it. Vendor reviews ask it, often right next to the questions about where customer data goes and which subprocessors touch it. Due diligence for a funding round or an acquisition asks it. And if you’re SOC 2 audited, the AI tools that touch customer data sit inside the vendor management and data handling controls your auditor already tests. What started as one line on a renewal form has become something your company gets asked about routinely.
The document is the easy half. What makes it defensible is everything attached to it.
Why a downloaded template usually fails
A template is better than nothing and it’ll get you past the checkbox. It tends not to survive contact with someone who reads it.
The weakness is specificity. A generic policy doesn’t name a single tool your team actually uses, so it’s silent on the ones genuinely in circulation. It doesn’t match your data classifications, so your team can’t tell whether a customer’s support transcript or a production data export falls inside or outside the rule. And it carries no evidence of enforcement, which is the second question anyone asks after the first one.
An underwriter or a customer’s security team isn’t really asking whether you have a document. They’re asking whether your company has made a decision about AI and can demonstrate it. A template answers the first question and not the second.
The four parts of an answer that holds up
1. Tool tiering, with names in it
Three tiers is enough. Sanctioned, meaning approved for use, including with customer data, under stated conditions. Permitted, meaning allowed for internal work that involves no customer data. Prohibited, meaning not to be used for company work at all.
The tiers must contain actual product names. A policy that describes categories without naming anything leaves every practical decision to the individual, which is the situation you started in.
2. Data classification in plain language
This is where most policies quietly fail. The controlling question is never which tool, it’s which data. Write out the categories your company handles and give each one an explicit rule. Customer personal data. Support transcripts and account records. Contracts and anything covered by an NDA or a DPA. Source code and credentials. Internal working documents that contain no customer data at all.
Write it so a new hire reads it once and knows what to do. If a policy needs interpretation, it’ll be interpreted generously by whoever is under deadline pressure.
3. Acknowledgment, signed and filed
A policy nobody signed is a draft. Everyone on the team acknowledges it in writing, the acknowledgments are stored somewhere retrievable, and the document joins your onboarding checklist so the next hire signs it in week one without anyone having to remember. If you already collect policy acknowledgments for SOC 2, this one rides along with them.
This is the part that converts a claim into evidence. When a questionnaire or an auditor asks how the policy is enforced, the signature file is the answer.
4. A named owner and a review date
Tools change faster than documents. A policy written this quarter describes a landscape that’s already shifting, because your vendors keep switching on new AI features. Name a person, set a review interval, and put the next review on a calendar rather than in an intention.
This is also the part that turns a document into governance, which is the word the people asking the question are actually using.
On legal review. An operational AI policy isn't legal advice and shouldn't pretend to be. It covers which tools are sanctioned, what data may enter them, and how your team acknowledges the rules. Your counsel should read it, along with whoever owns your customer contracts and DPAs. Write it well and that review is quick and inexpensive rather than a rewrite.
The mistake worth avoiding
The most common failure isn’t a weak policy. It’s a prohibition policy.
Banning AI outright is the easiest document to write and the fastest to be ignored. Your team uses these tools because they get the work done, and a rule that makes their week longer will lose to the queue every time. What a ban actually produces is the same activity, relocated to personal devices where the company has no visibility at all.
The objective isn’t less usage. It’s usage that’s visible, bounded, and written down. A tiering that says yes under conditions gets followed. A blanket no gets worked around, and the workaround is worse than what you were trying to prevent.
What to do this week
- Find the renewal application or security questionnaire that asked the question and read the exact wording. The specific phrasing tells you what standard you’re being measured against.
- List the AI tools you can name from memory. Then check that list against what your team reports, because the two differ in almost every company.
- Write your data categories down before you write any rules. The categories are the hard part and the rules follow from them quickly.
- Decide who owns the document. Without a name, the review never happens and the policy goes stale without anyone noticing.
None of this is a large project. It’s a few focused hours and one team conversation. What it buys is the ability to answer a question that’s going to keep being asked, without the pause that currently comes before your answer.