The Realization Came in Pieces
Late last year, I noticed our developers were using ChatGPT, Copilot, and Claude. Nobody had told them they could. Nobody had told them they couldn’t. They were using these tools because they were useful, and they assumed that if it wasn’t prohibited, it was allowed.
Around the same time, I realized the sales team was using AI too. Drafting outreach. Summarizing call notes. Generating proposal language. The same assumption was running there. Useful tools, no rules, must be fine.
As the security manager, I didn’t think either situation was fine. We had a data classification policy that defined what could leave the company and what couldn’t. We had a vendor risk management process that governed how we onboarded software. None of that had been applied to AI tools, because nobody had thought to ask.
That’s the gap most compliance-sensitive companies are sitting on right now. Not a policy gap exactly. An application gap. The controls exist. They just haven’t been pointed at this category of tool yet.
What I Was Actually Worried About
Two concerns drove the work.
The first was customer data exposure. We’re a SaaS company. We process compensation data for enterprise customers, which means we’re sitting on PII, financial records, and business logic specific to each customer’s environment. The fastest way to lose a customer in our industry isn’t a security incident. It’s a security incident that ends up on a vendor’s training data.
That risk doesn’t only live in the obvious places. Customer names. Schema details. Production query results. It also lives in places that don’t feel like “customer data” until you think about it. The prospect list in our CRM. The notes from a sales call. The architecture diagram of a customer integration that lives in someone’s OneDrive. The error log a developer pasted into ChatGPT to ask for help debugging. Every one of those is a potential vector.
The second concern was that we were doing this without a framework. We were making ad hoc decisions tool by tool, conversation by conversation. That works for a week. It doesn’t work as a security program.
The reframe that helped me was this. AI isn’t a new category of risk. It’s a new vector for existing risks. Customer data exposure, credential leakage, vendor data handling, and model behavior in production. All of these are problems my security program already addressed. The work wasn’t to invent AI governance from scratch. It was to extend what I already had.
That’s the same insight I had building the information security program. You’re rarely starting from zero. You’re formalizing what’s already there and pointing it at a new surface area.
You Already Have Most of What You Need
Before writing a single new policy, take inventory of what’s already on the books.
Your data classification policy tells you what data can leave the company. If “Customer Confidential” data can’t be emailed to an external party, it can’t be pasted into a public AI tool either. That’s not a new rule. It’s the same rule, applied to a tool that didn’t exist when the policy was written.
Your vendor risk management process tells you how to onboard third-party software. AI tools are third-party software. The same evaluation criteria apply. Data handling. Retention. Subprocessors. Contract terms. Training on customer data.
Your acceptable use policy tells employees what they can and can’t do with company systems. AI tools are systems. The same expectations apply.
Your secure SDLC governs how code gets reviewed, tested, and deployed. AI-generated code is code. The review requirements don’t change because a tool wrote the first draft.
Naming this out loud matters because it changes the shape of the project. You’re not building an AI governance program. You’re extending the security program you already have. Smaller scope, faster execution, less internal resistance.
What We Built
We ended up writing two policies, not one.
The first is the AI Usage Policy. It covers the general case. Who can use AI tools, which tools are approved, what data can and can’t go into them, and how AI agents that connect to our systems need to be governed. It pulls forward language from our data classification and vendor risk policies and applies it to AI as a category.
The second is the AI Coding Agent Policy. We separated this out because the risk profile is different. A developer using GitHub Copilot inline is one thing. A coding agent that can autonomously create files, run commands, and open pull requests is something else. We tiered the tools by autonomy. Tier 1 suggests. Tier 2 acts. The obligations scale with the tier.
For Tier 2, we added concrete operational controls. A pre-session checklist that asks whether the repo is off-limits, whether sensitive files are excluded, and whether GitHub Advanced Security is clean. File exclusions for credentials and config. Prompt injection awareness, because instructions embedded in code comments and third-party files can manipulate agents. A heads-up to the Security Manager before first use on a new project. Annotation of AI-assisted commits so they’re traceable in the git history. Dependency validation, because agents hallucinate packages and typosquats are real.
None of this is novel security thinking. It’s existing software supply chain hygiene applied to a new class of tool.
The Approved List Was Already Half-Built
We looked at ChatGPT, Claude, and Copilot.
Copilot was already approved. Had been for about two years, well before the AI policy work started. It got onto our approved tools list because of its integration with Microsoft 365 (Teams, Outlook, the rest of the stack), not as part of a deliberate AI governance decision. That’s worth saying out loud, because it’s probably how most compliance-sensitive companies ended up with their first AI tool. The vendor added AI features to a product you already use, and the AI got in through the side door.
That’s not a problem, but it’s worth treating as a signal. When a vendor adds AI features to an already-approved product, the approval doesn’t automatically extend. The data handling profile for Copilot generating a meeting summary differs from that for Teams hosting a call. The right move is to revisit the vendor under your AI policy and confirm the controls still hold. In our case, they did. The Microsoft enterprise agreement covers training opt-out and tenant isolation for the AI features. But that confirmation wasn’t free. It was work.
Claude and ChatGPT were the real evaluation. Both got looked at as part of the policy work, and the question for each was the same. Do we have a use case that justifies bringing in another vendor, and can we get contractual terms that protect our data?
Claude got approved. We needed an Anthropic Teams or Enterprise plan to get the right contractual terms. Personal claude.ai accounts wouldn’t meet our requirements. The reason we went through the process of approving Claude rather than just standardizing on Copilot is that our developers wanted it for coding tasks. The tools have different strengths, and forcing standardization on one tool would have produced exactly the shadow usage we were trying to eliminate.
ChatGPT didn’t make the approved list for development work. We allow it for general learning and writing assistance, subject to the same data restrictions that apply to all other public AI tools. Nothing about our environment, customers, schemas, or code goes in. That’s not because ChatGPT is uniquely risky. It’s because we have two tools that meet our needs on terms we’ve vetted, and a third doesn’t add enough value to justify the additional vendor relationship.
The principle behind the approved list is what I’d carry to any compliance-sensitive company. The decision isn’t “which AI tool is safe.” It’s “which AI tools have we vetted under our existing vendor risk process, and which contractual terms have we confirmed protect us.” That framing keeps you out of debates about model quality and into debates about data handling, which is where security ought to live.
The Customer Came Before the Standards
The compliance frameworks haven’t caught up to AI yet. They will. The standard control sets will add it, and audits will start testing for it. That’s coming.
Customers are already there. I recently completed a security questionnaire for one of our clients, and the notable part wasn’t that it included AI questions. It was that they were part of the client’s formal vendor management program, woven through the existing categories. How AI factors into vulnerability management. How it changes incident response. How we assess AI in third-party and supplier risk. Whether cyber insurance accounts for it.
That tells you something. For this customer, AI wasn’t a standalone topic bolted onto the end of the questionnaire. It was threaded through the whole security program, because that’s where the risk actually lives. And a change at the program level doesn’t happen casually. Someone upstream, a customer, an auditor, or an insurer, required them to assess AI risk across their vendors. So the requirement rolled downhill, and every vendor they use, including us, now gets the questions.
The pattern is the same one that played out with SOC 2 ten years ago. Customers ask before the frameworks do. The questionnaires get longer. Renewals start hinging on the answers. By the time the standards add AI to the expected control set, the companies that took it seriously early have a year of evidence to show. The companies that didn’t are scrambling to retrofit.
If you sell to compliance-sensitive customers and you haven’t been asked yet, you will be. Probably within the next renewal cycle. And it won’t be because you’re an AI company. It’ll be because your customer’s obligations just became your obligations. The right time to have a policy isn’t when the questionnaire arrives. It’s a few months before.
Where to Actually Start
If you’re sitting where I was a year ago, here’s the order I’d take it in.
- Find out what’s already in use. Talk to engineering. Talk to sales. Talk to operations. Don’t make it a witch hunt. People will tell you what they’re using if you make it clear you’re trying to support them, not catch them. You can’t govern what you can’t see.
- Classify your data and apply the existing policy to AI. If you have a data classification policy, your “this can’t leave the company” rule already covers most of what an AI policy needs to say. Make the connection explicit.
- Approve a small set of tools under enterprise agreements. Two are fine. Pick tools with contracts that prohibit training on your data, support enterprise identity and access controls, and align with the rest of your stack. Make those tools easy to access. Shadow usage thrives when sanctioned usage is hard.
- Write the policy in plain language. The goal isn’t to look impressive to an auditor. The goal is for your sales team to know they can’t paste a prospect list into ChatGPT, and your developers to know which tools are approved and what file exclusions to set. If the policy reads like a contract, nobody will read it.
- Separate coding agents from general AI use. The risk profile is different. So is the operating procedure. A combined policy ends up generic enough to be useless for either case.
- Plan for the customer questionnaire. Write your policy as if a customer will ask to see it next quarter, because they probably will. Map your controls to the questions they’re likely to ask. Data handling. Training opt-out. Tool inventory. Coding agent governance. If you can answer those four questions cleanly, you’ll be ahead of most of the market.
- Don’t try to ban it. Banning AI is a policy you can’t enforce. People will use these tools because they make the work easier, and prohibiting them just pushes the usage off-channel, where you can’t see it. Sanctioned access with clear rules is the only model that works.
The companies that get this right won’t be the ones with the longest policies. They’re going to be the ones who treat AI the same way they treat any other piece of software that touches their environment. Vet it. Document it. Govern it. Train people on it. Review it like everything else.
It’s not a different problem from the ones your security program already solves. It’s just one more place to point the work.