Did the user agree to have their words sent to a model
The feature sent what users typed to a third-party model. The users had agreed to use the product. They had never agreed to that.
Did the user agree to have their words sent to a model
A product lead at a consumer company told me about a question from their privacy team that they had not been able to answer cleanly. The AI feature took what users typed and sent it to a third-party model to generate a response. Standard build. The privacy team asked whether the users had agreed to that specific processing, their input leaving the product and going to an outside model provider. The honest answer was that users had agreed to use the product, and had accepted a privacy policy written before the feature existed, but nobody could point to where they had agreed to this. The feature had introduced a new flow of the user’s own words to a third party, and the consent basis for that flow had never been established.
Consent is specific. Agreeing to use a product is not the same as agreeing to have your input sent to a particular third party for a particular purpose. When an AI feature routes user data to a model provider, that is a processing activity the user may need to have agreed to, and a general acceptance of an old privacy policy often does not cover it. The feature created a new use of the user’s data, and the question of whether the user consented to that use is one you should be able to answer before the feature ships, not after a privacy team asks.
Product consent is not processing consent
There is a difference between a user agreeing to use your product and a user agreeing to a specific way you process their data. The first is broad and general. The second is narrow and tied to a purpose and a recipient. Sending user input to a model provider is a specific processing activity with a specific recipient, and whether it is covered by what the user already agreed to depends on what they were actually told and what basis you are relying on.
The common gap is a privacy policy that predates the feature. Users accepted it, so it feels like consent is handled. But that policy described the processing that existed when it was written, and it may say nothing about sending data to a model provider, because that flow did not exist yet. Relying on it to cover the new use is relying on agreement to something the user was never actually told about.
This is sharper for the kind of data users put into AI features. People type freely into assistants, sharing context and sometimes sensitive things, precisely because the interface invites it. Sending that content to a third party is a meaningful use of their data, and doing it without a clear basis is exactly the kind of thing that erodes trust and draws scrutiny when it comes to light.
Establish the basis before the data flows
The fix is to know, before the feature ships, what your legal basis is for sending user data to a model, and to make sure users have been told what they need to be told.
What that involves:
- Identify the basis. Whether you rely on consent, on a contractual necessity, or on another basis, be clear which one covers sending user input to a model provider.
- Update what users are told. If your privacy disclosures predate the feature, update them so users know their data may go to a model provider, and for what.
- Get consent where it is required. For processing that needs the user’s agreement, obtain it specifically, rather than leaning on a general acceptance that never mentioned this.
- Match the disclosure to the reality. What you tell users about where their data goes should match what the feature actually does, including the third party in the loop.
The teams that get this right treat the new data flow as something users are entitled to know about and, where required, to agree to. That is a step taken before the feature ships, because the data starts flowing the moment it launches, and a consent basis you establish afterward does not cover what already went out.
How we approach it at Density Labs
In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we check the basis for sending user data to a model. Whether users have actually agreed to it, whether your disclosures reflect the new flow, and whether the consent you rely on covers the processing you do. It is a common gap, because the feature introduces a new use of the user’s data and the consent framework was built for the old ones. Establishing the basis early is straightforward. Explaining its absence after the data has flowed is not.
Agreeing to use your product is not agreeing to have every word sent to a third-party model. Establish the consent basis before the feature ships, because the data leaves the moment it does.