The moment a project involves sending customer data to a third-party AI model or service, the privacy conversation changes shape, and it needs to happen before development starts, not after a feature is already built and someone asks about compliance. We've made this an explicit step in every AI-related project now, rather than an assumption that gets addressed later.
The questions we ask before writing any code
First: what data is actually being sent to the AI provider, and is any of it something the business is contractually or legally obligated to keep from leaving its own systems? Health information, financial details, and anything covered under a client's existing data processing agreements with their own customers all need a hard look here — sending that data to a third-party API without checking those obligations first can create real legal exposure the client didn't sign up for.
Second: what does the AI provider actually do with the data once it's sent? Some providers retain inputs for model training by default unless a business account with different terms is set up specifically to opt out. That's a meaningfully different privacy posture from a provider that processes the request and discards it immediately, and it needs to be checked against the provider's actual current terms, not assumed from general reputation — these terms change, and they vary a lot between a consumer-tier plan and a business or enterprise tier from the same company.
What we build in as standard practice
Where possible, we anonymize or strip identifying information before it reaches a third-party AI service, sending only what the feature actually needs to function rather than a full customer record by default. A support ticket summarization feature needs the ticket content, not the customer's full account and billing history sitting alongside it in the same request.
We also update the client's own privacy policy and, where relevant, get explicit consent flows in place before an AI feature touching customer data goes live — not as a formality, but because customers increasingly do ask what's happening with their data when they notice a new AI-powered feature, and “we hadn't documented that yet” is not an answer that holds up well, to a customer or to a regulator.
Why this is worth the extra step
None of this is exotic — it's mostly diligence that should apply to any third-party data sharing, AI or otherwise. What's changed is how casually AI features get proposed and shipped, often without the same scrutiny a business would apply to, say, choosing a new payment processor. We treat it with the same level of care, because the underlying risk — customer data leaving a business's direct control — is the same either way, regardless of how the feature is marketed.
Documenting the decision, not just making it
Beyond the technical and contractual checks, we've started keeping a written record of the privacy reasoning behind every AI feature we build — what data goes to a third-party provider, why, what alternative was considered and rejected, and what the provider's actual retention policy says at the time the decision was made. Provider terms change, sometimes without much notice, and having a dated record of what was true when a feature was built makes it far easier to audit later, whether that's for the client's own peace of mind, a customer's data request, or a genuine change in the provider's policy that needs reassessing.
This is a small amount of extra process for what's ultimately a significant category of risk, and it's the kind of documentation that's easy to skip when a feature is being built quickly under deadline pressure — which is exactly why we've made it a required step rather than an optional best practice, the same way we treat security review for anything handling payment data.
What we tell clients who want to move fast anyway
Sometimes a client wants to ship an AI feature quickly and treats this diligence as a delay rather than a safeguard. In those cases we separate the conversation into two parts: what's genuinely required before launch — the provider terms check, the anonymization pass, the updated privacy policy language — versus what can reasonably follow shortly after, like a fuller documentation process. That split usually gets a feature shipped on a realistic timeline without skipping the parts that would create real exposure if skipped.
None of this is about slowing innovation down for its own sake. It's about making sure the speed of shipping an AI feature doesn't quietly outpace the speed of thinking through what happens to a customer's data along the way — a gap that's easy to open under deadline pressure and genuinely costly to close after the fact.
