You Added an AI Vendor to Your SaaS. Your Customer Contracts May Already Require Notice.

Your engineering team shipped an AI feature last sprint. Somewhere in that work, the product started sending customer data to a third-party model provider. Where that provider processes personal data or other customer data on your behalf, it will often fall within the definition of “subprocessor” in the customer DPA — which may trigger notice and objection provisions in agreements you have already signed.

This is not merely a future diligence issue. Depending on the terms already signed, putting the feature into production may have triggered a notice obligation, an update to a subprocessor list, or another customer-contract commitment. The gap between “we shipped it” and “we told our customers” is where the problem lives.

Key takeaways

• An AI vendor that processes customer data on your behalf will often be treated as a subprocessor under the applicable customer agreement, not merely as a tool. What the contract calls it matters less than what it does with the data.
• Notice obligations may already be in your signed DPAs. Common terms require advance notice before a new subprocessor is added, often on a defined timeline.
• Objection rights may include a termination right. If the objection cannot be resolved, a customer may have a contractual right to end the affected services.
• “Do not train on our data” needs a contractual and operational basis. A customer commitment needs to be supported by the relevant vendor terms and product configuration.
• Several other documents quietly go stale at the same moment: the published subprocessor list, security questionnaire answers, data-residency commitments, and audit or certification scope.

When an AI Vendor May Be a Subprocessor, Not Just a Tool

Teams often categorize an AI provider the way they categorize a code library or a monitoring tool — part of the stack, not part of the data story. The distinction that usually matters in a data processing agreement is narrower than that: does the third party process personal data, or customer data, that you hold on behalf of your customer?

If customer content is transmitted to a model provider for inference, that provider will often meet the applicable agreement’s subprocessor definition — even if the provider does not retain the content, and regardless of the internal label for the integration. Retention, training use, and residency are separate questions that affect how serious the issue is. They do not usually change whether processing occurred.

The practical test is not the vendor’s marketing category. It is whether data that belongs to your customer left your environment and went somewhere new.

What Your Existing DPAs Likely Already Require

Data processing agreements vary, but enterprise SaaS DPAs commonly include some combination of the following. These are contract terms you agreed to, not new regulatory developments:

• Advance notice of new subprocessors, commonly on a stated timeline and often before the subprocessor begins processing.
• A maintained subprocessor list, sometimes published at a URL or made available through another agreed notice process.
• A right to object within a defined window, sometimes limited to reasonable grounds relating to data protection.
• A consequence if the objection is not resolved — which may include a right to terminate the affected services and, in some agreements, a refund of unused prepaid fees.
• Flow-down obligations that may require contractual protections for the subprocessor that are no less protective, substantially similar, or otherwise specified by the DPA.
• A provision allocating responsibility for subprocessors, often making the SaaS provider contractually responsible to the customer for the subprocessor’s processing, subject to the agreement’s liability terms.

Read together, these terms often mean the sequence runs the other way from how features normally ship. Where the DPA requires advance notice and provides an objection period, the intended sequence is notice first, then the applicable objection process, before the new subprocessor begins processing.

The first step is not drafting anything. It is reading what you already signed. Enterprise customers frequently negotiate bespoke subprocessor terms, so the obligations may differ meaningfully from one agreement to the next.

The “Do Not Train on Our Data” Commitment

Enterprise customers increasingly require a commitment that their data will not be used to train models. Many SaaS companies have already given that commitment — in a DPA, in a security exhibit, in a negotiated side letter, or in a completed security questionnaire.

That promise creates a chain. If you told a customer that its data would not be used to train models, you need a contractual and operational basis for honoring that commitment in the relevant vendor relationship and product configuration. That basis may appear in the vendor agreement, an enterprise addendum or order form, or a documented product setting, depending on how the service is purchased and configured. Points worth confirming:

• whether the vendor’s default terms permit training on submitted content, and whether a different tier or setting changes that;
• whether the setting is applied at the account, project, or API-key level, and whether every code path uses the correct one;
• whether the vendor can change the default in future, and what notice you would receive;
• whether retention for abuse monitoring or safety review is separate from training, and whether your customer commitment covers it;
• whether any human review of submitted content is permitted, and by whom.

If your customer commitment is not supported by the vendor terms and the applicable product configuration, your company may be exposed to a contractual gap; the vendor has not assumed that customer-facing obligation simply because you made it.

What Else Goes Stale the Same Day

Where the applicable agreement requires advance notice, the subprocessor notice may be the obligation with a clock on it. Several other artifacts may need updating at the same time and tend to surface later, usually during a renewal or a security review:

• The published subprocessor list, if you maintain one, may now be incomplete. Customers and their auditors may review these lists during diligence, renewals, or security reviews.
• Security questionnaire answers already returned to customers may no longer be accurate, particularly answers about third-party data sharing, subprocessors, and AI use.
• Data-residency commitments may no longer align with the product’s actual data flow if a model provider processes data in regions restricted by the customer agreement.
• Audit and certification materials may need review to determine whether and how they address the new component, which becomes a live question when a customer asks whether the AI feature is in scope.
• Insurance and vendor-risk records may need updating if the integration creates a materially different data flow.
• Your own privacy notice may need to describe the new category of recipient.

None of these individually is a crisis. Together they are the difference between a clean enterprise renewal and a month of remediation questions from someone else’s security team.

Sequencing It Before You Ship, Not After

The workable version of this is a short gate in the release process rather than a standalone workstream. Before an AI integration reaches production:

• Confirm whether customer data or personal data will reach the vendor, and which fields.
• Check the subprocessor and notice terms in the customer agreements that cover the affected accounts — including any negotiated variations.
• Confirm the vendor terms match every commitment you have made about training, retention, residency, and human review.
• Where the applicable agreement requires advance notice and provides an objection period, send the required notice and follow the applicable objection process before processing begins.
• Update the subprocessor list, the privacy notice, and the standard security questionnaire responses at the same time.
• Record the decision and the date, so the next security review has an answer.

Doing this in advance is ordinary product hygiene. Doing it after a customer’s auditor asks is a different and more expensive conversation.

If the Feature Has Already Shipped

Many companies find this out after the fact. That is a common position, but the response should be deliberate:

• establish what data has actually flowed to the vendor, and since when;
• identify which customer agreements have subprocessor terms and what each requires;
• determine whether any commitment about training or retention was inconsistent with the vendor’s actual terms;
• decide on notice — timing, wording, and to whom — with counsel, before sending anything;
• correct the standing artifacts so the position is accurate going forward.

Notice sent carelessly can create problems that the underlying gap did not. This is worth scoping before it is worth drafting.

What to Check Before Your Next Enterprise Renewal

• Does the subprocessor list reflect every AI vendor currently in the data path?
• Was notice given for each, and can you show when?
• Do the vendor terms match every training, retention, and residency commitment in the customer agreement?
• Are your standard security questionnaire answers still accurate about AI use and third-party sharing?
• Does your privacy notice describe the current recipients?
• If a customer asked today for evidence that the subprocessor terms in its agreement were met, could you produce it without a scramble?

How Accord & Shield Legal Helps

This is a contract problem before it is anything else. It turns on what your existing customer agreements say, what your vendor agreements say, and whether those two sets of documents agree with each other and with how the product actually behaves.

If you are adding AI to a product that already has enterprise customers, Accord & Shield Legal can review the subprocessor and notice terms in your existing agreements, compare them with your AI vendor terms, and help you assess and plan the appropriate notice process. You can also explore our commercial contracts services and outside general counsel support for companies that need this handled as part of an ongoing relationship.

Related reading: Your Product Uses AI: What Your Customer Contract Must Say; 7 AI Vendor Contract Questions Before You Connect Your Systems; Enterprise SaaS Agreements: MSAs and DPAs; AI Governance in Contracts.

This article provides general information, not legal advice. Subprocessor, notice, and data protection obligations depend on the specific agreements a company has signed, the categories of data involved, the relevant data flows and vendor configuration, the customer base, and the laws applicable to those customers. Reading this article does not create an attorney-client relationship. For guidance on a specific situation, consult qualified counsel.