The data agreement that never mentioned AI

The contract governed how customer data could be used. It was written before the AI feature existed, and it did not permit the new thing the feature was doing with that data.

The data agreement that never mentioned AI

A legal lead at a B2B company told me about a mismatch that surfaced during a customer renewal. The customer’s team reread the data processing agreement, the one that governed what the company was allowed to do with their data, and noticed something. The agreement described specific permitted uses. It had been written before the AI feature existed. And the AI feature was using the customer’s data in a way the agreement did not cover, sending it to a model provider, deriving new things from it, processing it for a purpose the contract never contemplated. The agreement was not violated on purpose. It simply predated the feature, and nobody had checked whether the new use fit the old permissions before shipping it.

A data processing agreement is a promise about what you will and will not do with someone’s data. It lists purposes, permitted processing, and often the parties involved. When you add an AI feature, you frequently introduce a new purpose, a new kind of processing, and a new party, and unless the agreement already allowed for those, the feature is doing something you did not have permission to do. The contract governs the data whether or not the engineers who built the feature ever read it, and a use it does not authorize is a use you should not be making.

The old agreement did not know about the new use

Data agreements are written against the uses that exist when they are signed. They describe the processing you do, the purposes you do it for, and the third parties involved, and they bind you to that description. That works fine until you add a materially new use, at which point the question is whether the existing terms stretch to cover it. For AI features, the honest answer is often no.

The new uses AI introduces are exactly the kind agreements tend not to anticipate. Sending data to a model provider is a new third party and a new transfer. Using data to derive embeddings, or to fine-tune, is a new kind of processing. Making automated decisions is a new purpose. Any of these can fall outside what the agreement permitted, and if it does, the feature is processing data beyond the scope you agreed to, which is a real problem regardless of intent.

The gap opens because the feature is built by people who are not reading the data agreements, and the agreements are owned by people who are not in the build. So the feature introduces new uses, and nobody checks those uses against the terms that govern the data, until a customer does it during a renewal or an audit.

Check the feature against the terms

The fix is to compare what the AI feature does with data against what your agreements actually permit, before the feature ships.

What to check:

  • New purposes. If the feature uses data for something the agreement did not list, that purpose may not be permitted, and the agreement may need to change before the feature can.
  • New processing. Deriving embeddings, training, and automated decisions are kinds of processing your terms may not cover.
  • New parties. A model provider is a new recipient of the data, and the agreement may require that recipients be authorized or disclosed.
  • The gap between contract and reality. Where the feature outruns the terms, either the feature scope or the agreement has to move, and that is a decision to make deliberately, not discover later.

The teams that get this right connect the build to the contract, so that a new use of data prompts a check against the terms that govern it. That check either confirms the feature is within bounds or flags that the agreement needs updating first. Either way, the use and the permission stay aligned, instead of drifting apart until a customer notices.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we compare what the AI feature does with customer data against what your agreements permit. New purposes, new processing, new recipients. When the feature has outrun the terms, we flag it before a customer’s legal team does. Aligning the use with the permission early is a small conversation. Discovering the gap during a renewal, with a deal on the line, is not.

Your AI feature may be using customer data in ways the agreement governing it never authorized. Check the feature against the terms before it ships, because the contract binds you whether the engineers read it or not.