The clause in the provider's terms nobody read
The AI feature depended on a model provider, and the relationship was governed by terms the team had clicked through. One clause in there would have changed how they built it.
The clause in the provider’s terms nobody read
A CTO at a mid-market company told me about a discovery that arrived at the worst time, during a customer’s security review. The customer’s legal team had read the model provider’s terms, which the CTO’s own team had accepted without reading closely, and they had found a clause that mattered. It touched how the provider could handle data, what it committed to, and what it disclaimed. The clause was not hidden. It was in the terms everyone had clicked through to get started. The team just had not read it, and now a customer had, and the conversation had shifted from selling to explaining why they had built on terms they did not know.
When your AI feature depends on a model provider, that provider’s terms are part of your product’s foundation, whether you read them or not. Those terms govern what the provider does with your data, what it promises about availability and quality, what liability it accepts, and what it disclaims. Any of those can shape how you should build, what you can promise your own customers, and what risk you are quietly carrying. Clicking through them does not make them go away. It just means you accepted them without knowing what you agreed to.
The terms are load-bearing, read or not
A model provider is not a neutral utility. It is a vendor with a contract, and that contract allocates risk in ways that affect you directly. The terms say whether the provider can use your data and how. They say what happens when the service is down, whether anything is owed to you, and what you are on your own for. They say who bears responsibility when the model produces something harmful. They often disclaim far more than a first-time reader expects.
These are not abstractions. They flow straight into decisions you make. If the terms let the provider use your data in a way your customers would object to, that changes what you can put in a prompt. If the provider disclaims availability, that changes how much fallback you need to build. If liability sits entirely with you, that changes how much you rely on the model for anything consequential. Building without reading the terms means making all of those decisions blind.
The reason this gets skipped is speed. You accept the terms to start building, because reading them feels like a lawyer’s job and the point is to ship. Then the terms sit under your product, load-bearing and unexamined, until a customer’s lawyer reads them for you and asks why you did not.
Read the terms before you build on them
The fix is to treat the provider’s terms as an input to the architecture, reviewed before you commit to building on them.
What to look for:
- Data handling. What the provider may do with your prompts and outputs, how long it retains them, and whether that fits what you promise your customers.
- Availability and quality. What, if anything, the provider commits to, so you know how much resilience you have to build yourself.
- Liability and indemnity. Who bears responsibility when the model causes harm, because the answer shapes how much you should depend on it.
- Change rights. What the provider can change unilaterally, including the model itself, so you are not surprised by a shift you did not choose.
The teams that get this right read the terms with the same seriousness they bring to any critical dependency, because that is what a model provider is. The terms are going to govern the relationship regardless. The only choice is whether you understand them before you build or after a customer points them out.
How we approach it at Density Labs
In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look at the provider relationship your feature depends on, including what the terms actually say about data, availability, and liability. When a team has built on terms they never read, we surface the clauses that should have shaped the architecture. Reading the terms early is cheap. Explaining an unread clause to a customer’s legal team, mid-deal, is not.
Your model provider’s terms are part of your product whether you read them or not. Read them before you build, because your customer’s lawyer will read them before they buy.