Data Handling Obligations in API Integration Agreements

Not anymore. Third-party integration through APIs creates shared responsibility for privacy compliance, and that responsibility can't be managed through a policy document sitting in a shared drive. It has to be assigned, tool by tool, in a contract that says who is liable for what.

That's a bigger shift than it sounds like at first pass. APIs became the connective tissue holding SaaS infrastructure together over the last decade, linking billing systems to support desks to marketing platforms in ways no single team fully maps. As that connective tissue spread, the agreements governing it took on the same role for data governance. An API agreement now functions as a contract of record for data governance. It's the rulebook for who owns a mistake when customer data ends up somewhere it shouldn't.

The regulatory floor under API agreements, 2023 to 2027

Two regulatory currents, moving independently, converged to sink the old minimalist API agreement. The first is the collapse of the B2B exemption, the once-comfortable idea that business contact data (a work email, a job title, a company phone number) sat outside the reach of privacy law. California ended that idea on January 1, 2023, when its B2B exemption expired and the California Consumer Privacy Act began fully covering the personal information of business contacts. Texas followed with its own Data Privacy and Security Act, effective July 1, 2024, applying to any entity processing personal data in Texas regardless of revenue or data volume, which in practice means almost every SaaS startup with a Texas customer is on the hook. State by state, through 2026, this pattern kept repeating.

The second current is the EU Data Act (Regulation (EU) 2023/2854), applicable from September 12, 2025, which imposes mandatory transparency and switching obligations on every provider of data processing services, IaaS, PaaS, or SaaS, regardless of where that provider is headquartered, as long as EU customers use the service. Germany and France have specified penalty structures of up to 4-5% of global turnover for non-compliance, and where personal data is involved, parallel GDPR enforcement is also triggered.

The Data Act rolls out on a fixed calendar, and each date changes what a contract has to contain. September 12, 2025 brought the main obligations into force: data access rights, cloud switching rights, and mandatory contract terms. September 12, 2026 adds "data access by design" requirements for connected products entering the market after that date, plus stronger interoperability rules for cloud services. January 12, 2027 bans charges for switching between data processing services entirely. September 12, 2027 brings full data portability standards into effect, and extends the unfair-terms rules to contracts signed on or before September 12, 2025, if those contracts run indefinitely or expire on or after January 11, 2034.

Any agreement signed before September 12, 2025, that's indefinite or long-running isn't grandfathered in forever, and it falls under the same compliance countdown as the rest. Agreements signed before September 12, 2025 that are indefinite or long-running are on a compliance countdown, since the EU Data Act's unfair-terms obligations are deferred until September 12, 2027 for indefinite-duration or qualifying long-term contracts.

Healthcare has its own parallel clock running. CMS has mandated FHIR API implementation, with patient data access requirements due by January 2026 and prior authorization API enhancements due by January 2027. Between US state privacy law and the EU Data Act, there's no jurisdiction left where a thin, boilerplate API agreement is a safe bet.

Required contents of a data processing services contract under the EU Data Act

The Data Act doesn't leave the specifics to interpretation. It names the clauses a contract must have, and a contract missing them is non-compliant by omission, not just by poor drafting.

Switching terms come first. A contract has to spell out the client's rights and the provider's obligations if the client wants to leave, including a maximum two-month notice period and a maximum 30-day transitional window for the actual migration, extendable to seven months if the switch turns out to be technically difficult. During that window, the provider has to actively support the move, not just unlock an export button and wish the client luck.

Transparency on international data transfers is next. Providers have to publicly state which jurisdictions house their infrastructure and describe how they protect non-personal data from unlawful government access abroad, and the contract has to point to those disclosures rather than leave them buried in a separate policy page.

Switching fees are being phased out on a set schedule. From January 11, 2024 through January 12, 2027, a provider can charge for switching, but only at direct cost, and after January 12, 2027, switching has to be free. Any contract still carrying a flat switching fee or a lock-in penalty is going to need a redline before that date arrives.

Open interfaces round out the technical requirements. SaaS and PaaS providers must offer open interfaces at no charge, specifically to make interoperability and data portability possible. IaaS providers face a related but distinct obligation, functional equivalence, rather than the open-interface requirement.

Finally, the Data Act bars providers from imposing unilaterally unfair terms in B2B contracts, particularly around data access or use, and that rule applies immediately to anything signed on or after September 12, 2025. Germany and France have already put numbers on what happens if a provider ignores all this: penalty structures reaching 4 to 5 percent of global turnover, with GDPR enforcement stacking on top wherever personal data is involved. Many contracts currently in circulation were written before any of these clauses existed. A fair number of them will need surgery, not just a signature refresh.

Why the DPA decides liability for data handling

A classic failure pattern plays out often in procurement. A classic failure pattern: the MSA contains the line "Provider will not use Customer Data to train or fine-tune any AI model," and procurement flags it as protected. Legal reads it, likes it, signs off. Nobody goes back and reads the Data Processing Agreement, where the actual data handling terms live, and which in this scenario says something very different: "Provider may use aggregated and anonymized data to improve its services." Those two sentences contradict each other, and the DPA wins. The document procurement treated as boilerplate turns out to be the one that actually governs how customer data gets used.

That's not a hypothetical edge case. The most consequential data handling terms in an API integration are typically buried in a Data Processing Agreement that conflicts with, and governs over, the main service contract, and that structural problem is what most procurement reviews miss. Any prohibition on using customer data to train AI models needs to live in the DPA itself, and it needs to be specific: no training, fine-tuning, or improving any model, proprietary or third-party, using customer prompts, outputs, or usage logs, and that restriction has to survive termination of the contract.

Under GDPR, a DPA carries a specific job list. It has to establish that processing only happens on the controller's documented instructions, define the purpose and duration of that processing, specify the type of personal data and the categories of people it covers, require appropriate security measures, and restrict the use of sub-processors to cases where the controller has given prior permission. The controller, the SaaS company collecting the data in the first place, carries ultimate legal responsibility for it. A thin or missing DPA leaves that responsibility with the controller. It just means the controller ends up liable for processing it never actually authorized.

Each one needs a DPA that's actually been reviewed and executed instead of a terms-of-service box someone checked during onboarding.

The AI tool layer's sub-processor chain that escapes most DPAs

AI tools added a wrinkle that older contract templates were never built to handle. A third-party AI tool sitting on top of a foundation model carries its own data usage terms, separate from whatever the underlying model provider promises, and those terms often create processor liability nobody at the integrating company signed up for. A tool built on a foundation model API and sold through a third-party vendor is governed by that vendor's terms, not the model provider's terms, unless the integration contract explicitly states otherwise.

OpenAI's own API policy states that data submitted through the API isn't used to train or improve its models, a real and meaningful distinction from the consumer ChatGPT product, where conversations may be used for training unless a user opts out. That distinction evaporates the moment a third-party vendor builds a product on top of the OpenAI API, because that vendor's own terms govern what happens to the data, and those terms can be far more permissive than OpenAI's.

Microsoft 365 Copilot offers a useful, concrete illustration of how fast this chain can shift. Copilot is contractually excluded from training under the Microsoft Product Terms, with enterprise protections also spelled out in Microsoft's Data Protection Addendum. Then, in January 2026, Microsoft added Anthropic as a default sub-processor for Copilot, with Anthropic's processing folded into Microsoft's own Product Terms and Data Protection Addendum rather than a separate Anthropic agreement. EU, EFTA, and UK tenants had Anthropic disabled by default at the global sub-processor level. None of that reflects poorly on Microsoft or Anthropic. It reflects the reality that sub-processor relationships are live and can change on a vendor's own timeline, in ways that vary by region, without the controller necessarily seeing it coming.

The same dynamic runs through the rest of a typical go-to-market stack. Enrichment platforms, intent data providers, and AI-powered outreach tools all inherit obligations as data processors under GDPR and as service providers under CCPA, and each one is a sub-processor event that needs disclosure and, where the DPA requires it, prior authorization from the controller. Enforcement against fourth-party AI infrastructure, cloud AI/ML platforms, external model API providers, and data annotation services, remains contractually murky, and the chain frequently cannot be audited in practice. The obligation exists in writing. Auditing the full chain in reality is another matter.

Healthcare shows what happens when this gap gets tested. HIPAA compliance hasn't been uniformly certified across the AI governance layers of workflow automation platforms, and healthcare organizations have faced real enforcement actions and costly forced migrations after patient identifiers moved through non-compliant integrations between patient portals and marketing automation tools.

What the sub-processor disclosure obligation requires in practice

A DPA that doesn't list its sub-processors, or require notice before adding new ones, leaves the controller with no real way to enforce anything the regulation asks of them. GDPR requires that a processor get prior written authorization, specific or general, before engaging a sub-processor. General authorization, a standing clause covering a class of sub-processors, is allowed, but only if the processor commits to notifying the controller before making changes, giving the controller a real chance to object.

A properly built DPA needs to state that customer data, including prompts, outputs, and usage logs, can't be used to train AI models for third parties or pooled with other customers' data for model training, and that this rule binds the vendor's sub-processors just as tightly as it binds the vendor. The minimum contractual mechanisms are a maintained, accessible sub-processor list, advance notice of additions or changes (typically 30 days), a controller right to object, and a process for the controller to exit if the objection is not accommodated.

None of that means anything without engineering behind it. A DPA clause banning the use of customer data for training is worthless if engineers are quietly logging full prompt-response pairs into a shared warehouse with no retention policy. Legal language and technical enforcement have to match. The DPA should require the vendor to prove the controls are working with evidence such as audit logs or attestation reports.

SOC 2 Type II attestation is how vendors typically demonstrate that proof. It confirms that controls are operating effectively over time, not just sitting well-designed on paper, and it has become a baseline requirement for enterprise API deals across North America. Think of it as an independent audit of the sub-processor chain, the equivalent of a building inspector checking that the fire exits actually open rather than just appear on the blueprint.

The EU Data Act's switching and interoperability mandates on vendor lock-in clauses

Lock-in has long been a quiet business strategy in SaaS: make leaving so expensive or technically painful that customers stay out of exhaustion rather than loyalty. The Data Act's switching rights take direct aim at that strategy, and any agreement still built around it is now facially non-compliant for EU customers. Latham & Watkins has described the Data Act as the most significant overhaul of European data law since GDPR, and arguably more disruptive to business operations than the EU AI Act, precisely because it reaches into commercial contract structures rather than staying confined to data processing practices.

The mechanics are specific. Customers can switch providers with a two-month notice period, the provider must complete switching within a maximum 30-day transitional period, followed by a separate minimum 30-day data retrieval window, with data delivered in open, machine-readable formats. Switching fees follow their own countdown: reduced, direct-cost-only fees are permitted through January 12, 2027, and after that date, switching has to be free. Any contract still charging early termination penalties tied to data migration, or leaning on proprietary file formats to make leaving harder, needs a rewrite before that deadline lands.

Open interfaces close off the last technical escape hatch. SaaS and PaaS providers must offer them free of charge, and paired with mandatory data portability, that combination removes the technical version of lock-in as a viable business model. A vendor can still win on product quality, price, or service. Locking customers in by making their own data hard to retrieve is no longer an option on the table.

The unfair-terms prohibition backs all of this with a broad net, barring providers from imposing unilaterally unfair B2B terms around data access or use, a category wide enough to sweep in a lot of standard SaaS boilerplate that predates the Data Act entirely. Contracts written under the old assumptions, that switching should be slow, that formats should be proprietary, that leaving should cost something, are the ones with the most rewriting ahead of them.