If you are building an AI product that sends any customer data to a model provider such as OpenAI, Anthropic, or Google, there is a contract you almost certainly need and may not have. It is called a Data Processing Agreement, usually shortened to DPA, and its absence is one of the most common issues found when an enterprise buyer reviews an AI startup.

This article explains what a Data Processing Agreement actually is, why your AI product needs one, what happens without it, and how to put the right agreements in place before a buyer or a regulator asks.

What a Data Processing Agreement actually is

A Data Processing Agreement is a legally binding contract between two parties that sets out how personal data will be handled when one party processes that data on behalf of another. Under data protection law, including the UK GDPR and the EU GDPR, this agreement is not optional when personal data is involved. It is a legal requirement.

The agreement defines who is responsible for what. It names the party that decides why and how data is processed, known as the controller, and the party that processes that data on their instructions, known as the processor. It sets out the obligations of each, the security measures required, what happens in the event of a breach, and what occurs when the relationship ends.

In simple terms, whenever you hand personal data to another company to process for you, the law expects there to be a DPA governing exactly how they may handle it.

Why your AI product almost certainly needs one

Here is the part many founders miss. The moment your AI product sends customer data to a third party model provider, you are sharing personal data with another company that processes it on your behalf. That triggers the need for a Data Processing Agreement with that provider.

Consider what actually happens in a typical AI product. A user enters information, your application sends some of that information to a model API to generate a response, and the provider processes it on their servers. If any of that information relates to an identifiable person, and it very often does, then personal data has just left your control and been processed by a third party. Without a DPA in place, that transfer may be unlawful.

This is why enterprise buyers ask about it directly. When their security team sees that your product calls an external model, one of their first questions is whether you have a Data Processing Agreement with that provider. If you cannot answer yes, it signals that personal data may be flowing out of your product without the legal protections the law requires.

The good news about the major providers

The major model providers understand this requirement and offer Data Processing Agreements to their business customers. The practical issue is rarely that an agreement is unavailable. It is that founders do not realise they need to actively put it in place, and assume that simply using the service is enough.

In most cases you need to take specific steps to have the agreement apply to your account, and you often need to configure your usage correctly so that data is handled under the terms you expect. The following are the kinds of things that matter.

• Whether you have actually accepted or signed the provider's Data Processing Agreement, rather than assuming it applies automatically.
• Whether your data is excluded from being used to train the provider's models, which usually requires using the correct tier or settings.
• Where the data is processed geographically, since default routing may send it outside your permitted region.
• How long the provider retains the data you send, and whether that retention is acceptable for your obligations.

Getting these details right is what turns a vague assurance into a defensible answer when a buyer asks.

What happens without one

Operating without the Data Processing Agreements you need creates risk on several fronts at once, and all of them can surface at the worst possible moment.

• Legal exposure. Processing personal data through a third party without the required agreement may breach the UK GDPR or EU GDPR, which carries the risk of regulatory action and significant fines.
• Lost deals. Enterprise buyers check for this specifically. A missing DPA with your model provider is a clear red flag that can pause or end a procurement process.
• Broken commitments. If you have promised your own customers that their data is handled lawfully, a missing DPA in your chain may mean you are not meeting the commitments you have already made to them.

The difficulty is that none of this is visible until someone looks. Your product works, the data flows, and everything appears fine, right up until a buyer's security team or a regulator asks the question you cannot answer.

How this fits into the wider picture

A Data Processing Agreement is one specific piece of a larger requirement to handle personal data lawfully across your AI product. It sits alongside understanding your obligations under GDPR more broadly, knowing where your data is processed, and being able to show how data flows through your system from the moment a user enters it to the moment a model returns a response.

It is also closely tied to the questions an enterprise security review will put to you, because data handling is one of the areas buyers probe most carefully when the product is built on AI. Having your Data Processing Agreements in order is one of the clearest, most concrete ways to show that you take that responsibility seriously.

The honest takeaway

A Data Processing Agreement is not the most exciting part of building an AI product, but it is one of the easiest things to get wrong and one of the simplest to put right once you know it matters. The providers offer the agreements. The law requires them. The buyers check for them. The only thing standing between most founders and compliance here is awareness.

If your AI product sends data to any third party model provider, treat this as something to confirm now rather than discover later. Check which agreements you have actually put in place, how your data is configured, and whether you could answer a buyer's question about it today with a confident yes.