Right now, your employees are almost certainly using AI tools that expose company data — and most have no idea they're doing anything risky. Pasting client contracts into a chatbot for a summary. Running financial projections through an AI assistant. Drafting proposals with proprietary pricing inline. None of it malicious. All of it convenient. An AI optimization project isn't creating risk from zero — it's adding structure to risk that's already there. That reframe matters: the project is your chance to audit what's already happening, build the controls that should exist, and come out materially more secure than you started.
Start here: your risk assessment drives everything
Before you decide what safeguards to build, what vendor to choose, or what architecture to use, answer one foundational question: what data are you actually putting at risk, and what does it cost you if that data is exposed?
Not every company needs the same solution. A company processing public marketing data through an AI tool faces a fundamentally different risk profile than a law firm running confidential client contracts through the same tool. The safeguards that make sense — and the budget that justifies them — follow directly from that assessment.
You wouldn't put a Ferrari security system on a commuter car — but you also wouldn't protect a Ferrari with a bicycle lock. The question isn't "what's the maximum security we could build?" It's "what protection is proportionate to what we're actually protecting, and what does a breach actually cost?"
A small logistics firm using AI to optimize routes, processing no PII: a basic DPA and standard enterprise tier may be entirely sufficient. A financial services firm analyzing client portfolios with SSNs and investment strategies: PII masking, egress monitoring, sandboxing, annual independent controls validation, a full-time governance owner. Most companies sit in between. The risk assessment tells you where.
The assessment doesn't need to be lengthy. It needs to answer four questions honestly:
1. What data will the AI system touch? List it specifically — customer PII, financial records, contracts, employee data, proprietary processes.
2. What is the cost of exposure? Regulatory fines, client contract liability, reputational damage, competitive harm. Put numbers on it where possible.
3. What data is critical versus manageable? Identify what would cause serious harm if exposed versus what's inconvenient but recoverable.
4. What controls are proportionate to that cost? This is where budget gets decided — driven by the risk, not by what a vendor is selling.
Why existing protections often fall short
Most companies entering AI aren't new to data protection. They have NDAs, vendor agreements, IT policies. The issue isn't carelessness — it's that those protections were designed for a different vendor relationship, one where data goes in, a service comes out, and the vendor retains nothing meaningful in between.
AI doesn't work that way. A standard NDA says the vendor won't disclose your confidential information. It says nothing about whether your data trains a model that then serves the vendor's other customers. Nothing about sub-processors. Nothing about what survives after the contract ends, even when raw data is deleted.
Traditional vendor contracts protect against disclosure of your data. AI engagements require agreements that also address training use, model retention, sub-processor chains, and what survives data deletion. Most standard templates don't cover these — and most companies don't realize it until they specifically look.
What "data used for training" actually means
Consider a mid-size law firm using an AI tool to draft contracts. Attorneys paste in client names, deal terms, acquisition prices, confidential structures. The tool is on a standard tier whose terms permit using inputs to improve the model. Six months later a competitor's attorney uses the same tool and gets suggestions suspiciously specific to the first firm's client situation. Nobody disclosed anything directly — the model simply absorbed thousands of inputs and can't trace any output to its source. The NDA said "don't disclose confidential information." It never addressed training use.
What would have prevented it: a signed Data Processing Agreement on an enterprise tier explicitly prohibiting training use — a few hundred dollars a month versus, potentially, the client relationship and litigation. The category of data changes across industries — a manufacturer's process specs, an HR team's performance records — but the mechanism of risk is identical.
The five questions to ask every AI vendor
"Is our data used to train or improve your models — including models operated by your sub-processors?"
Ask explicitly, get it in writing. "We take privacy seriously" is not an answer. The prohibition needs to be in the signed DPA and extend to every sub-processor. If they can't answer with specifics, assume training use is permitted until proven otherwise.
"Who are your sub-processors, where are they located, and do your data obligations extend to them contractually?"
Your data rarely stays with just the vendor — it flows through cloud infrastructure, model hosting, logging tools, sometimes human review. Each is an exposure point. If your negotiated terms don't flow down to each, your protections stop at the first handoff.
"Who has access to production data during development, debugging, and maintenance — and where are they located?"
AI products are often built by teams in countries with different privacy laws and accountability frameworks. A legitimate cost decision — but a risk question when those teams access production data without equivalent controls. Ask who has access, whether it's logged and auditable, and what your recourse is across the jurisdiction gap.
"Where are you incorporated, which jurisdiction governs our contract, and what is your dispute resolution mechanism?"
If a vendor is incorporated offshore with arbitration in a neutral jurisdiction and indemnity capped well below potential breach liability, the path to recovery after an incident is long and uncertain. Your clients hold you accountable for what your vendors do — that runs upstream regardless of your internal contract.
"Do you carry cyber liability or professional indemnity insurance, and does coverage extend to sub-processor incidents?"
This reveals the gap between stated commitments and actual financial accountability fastest. Many AI vendors carry limited coverage relative to the data they handle. Ask for documentation. If they can't produce it, there's no meaningful financial backstop behind their commitments.
Safeguards: match the control to the risk
This table maps each safeguard to the risk level that justifies it — the cost-versus-benefit framework in practice. Your risk assessment tells you which row you're in; that row tells you what to build and what to defer.
| Safeguard | Risk level | Cost | What it addresses |
|---|---|---|---|
| Signed Data Processing Agreement | All levels | Low | Training use, deletion, breach notification |
| Data minimization policy | All levels | Low | Limits exposure at source |
| Internal AI tool inventory | All levels | Low | Surfaces shadow AI use by employees |
| Written incident response procedure | All levels | Low | Defines response before it's needed |
| Egress monitoring & access logging | Medium & high | Medium | Real-time visibility, self-owned audit trail |
| PII masking & tokenization | Medium & high | Medium | Vendor never sees real identities |
| Data validation & sandboxing on return | Medium & high | Medium | Blocks malformed or malicious returned data |
| Designated AI governance role | Medium & high | Medium | Owns monitoring, alerts, vendor oversight |
| Periodic internal controls self-testing | Medium & high | Low | Confirms controls actually work, not just exist |
| On-premise hardware deployment | High only | High | Data never leaves your network |
| Independent third-party controls audit | High only | High | Independent validation for clients and regulators |
A few worth expanding: PII masking replaces real identifiers with anonymous tokens before data leaves — if the vendor is breached, the attacker gets tokens that map to nothing outside your system. Sandboxing on return addresses the risk most companies never consider: not what leaves, but what comes back. Egress monitoring is owned by you, run by you — it's your visibility into your own data flows, not a vendor watching you. And periodic self-testing is a fire drill, not an audit: did the alert fire when it should have, did tokenization catch every PII field — it converts theoretical controls into verified ones.
Every company deploying AI needs a designated governance role
This is the piece most companies miss entirely — and it's where informal AI adoption turns into a managed, auditable, defensible program. It doesn't need to be a new hire or a full-time position at lower risk levels. It almost certainly shouldn't be a traditional IT manager focused on network maintenance — that's a valuable skill set, but it isn't data governance.
Receives and reviews real-time alerts from egress monitoring — because privacy incidents need response in hours, not the next ticket cycle. Owns the vendor DPA review and the AI tool inventory. Reviews validation and exception reports on a schedule. Is the point of contact when a vendor reports an incident. Has authority to pause a vendor or restrict employee access when a risk appears. Reports to senior leadership, not just to IT.
In many organizations this person already exists under another title — a compliance manager, a senior operations director, a CFO who already owns vendor risk. The gap isn't headcount. It's formal assignment, defined scope, the right alerts configured, and the authority to act. Because when your team uses AI informally — which they're doing right now — no one currently owns knowing which tools are in use, what data they see, or whether any of them is a material exposure. The governance role closes that gap.
This is an opportunity, not just a checklist
The companies that come out of an AI governance project strongest aren't the ones that treated it as compliance. They're the ones that used it as the forcing function to finally audit their existing data practices and build controls that protect them across every vendor relationship — not just the AI one.
Most of these safeguards aren't AI-specific — they're sound data governance for any vendor relationship involving sensitive data. The AI project is the reason to finally put them in place, and the payoff extends well beyond it. The internal audit that precedes a well-governed deployment routinely uncovers what was already there: contracts unreviewed in years, employee access exceeding job requirements, outbound data flows through tools never formally approved. The AI project is the trigger; the security improvement is lasting.
Not sure where your organization sits on the risk spectrum?
The risk assessment is where everything starts. The AI Governance Readiness Assessment is a focused, independent review: no downtime, no committee. If your situation is low-risk and a basic DPA is sufficient, I'll tell you that. If gaps need closing, I'll tell you that too — with specifics, not a sales pitch.
Independent by design. I don't build or sell these systems, so I've no reason to tell you yours is fine when it isn't.
Request an assessment
This article is for general educational purposes only. It is not legal advice, technical consulting advice, or a formal governance audit. For formal audits, legal compliance opinions, or implementation decisions, engage qualified professionals in your jurisdiction. Monte Fisher's CPA license is retired and inactive. Facilitation fees on AI partner introductions are always disclosed before any introduction is made.