SecurityTechInsider AI security & governance
EN/ NL
Governance

AI provider terms as a risk surface per tier

OpenAI, Google and Microsoft cap liability and handle training and indemnity differently per tier. Here is how to vet AI provider terms as an operational risk.

21 September 2026 4 min
Illustration for this article: AI provider terms as a risk surface per tier. The cut edges of a thick stack of blank paper, fanned slightly, raking light along the fibres.
Organisations must verify provider liability caps and training opt-out settings for each workflow, not assume they are safe by default. Image: SecurityTechInsider — original editorial illustration

You must treat AI provider terms as an operational risk specific to each workflow, not as a procurement decision made once at the outset. Liability caps, indemnity exceptions, training defaults and opt-out settings vary materially between consumer and business tiers, and between providers. Document which provider tier you use for each workflow and verify that the contractual defaults and data-handling settings match your obligations.

The prompt is an analysis of 21 September 2026 of liability caps and training opt-out settings across AI provider tiers, which argues that the contractual terms and data-governance defaults hidden behind the interface pose a distinct operational risk that most organisations overlook. The analysis examines how OpenAI, Google and Microsoft structure liability, indemnity and training consent differently depending on whether you use consumer or business terms. In our assessment, this matters because the ease of access to an AI service says little about the legal and data-governance defaults that apply to you as soon as you enter sensitive content, and because those defaults are not always the safest ones.

What liability limits do the standard terms impose?

OpenAI's consumer Terms of Use cap aggregate liability at the greater of fees paid in the preceding twelve months or 100 dollars, and exclude indirect, incidental, special, consequential and punitive damages. Under these terms, your potential recovery for harm is therefore very limited. Google's Terms of Service impose similar restrictions: liability is limited, indirect and consequential damages are excluded, and you may be required to indemnify Google against third-party claims arising from unlawful use. The pattern is consistent across providers and across tiers. The risk allocation between consumer and business terms is not symmetrical. OpenAI's Services Agreement, which applies to business customers, generally caps liability at total fees paid in the preceding twelve months, but crucially, indemnification obligations are excepted from that cap. This means that on business terms, your indemnity exposure sits outside the liability ceiling.

How do training defaults and opt-out settings differ by tier?

OpenAI distinguishes between consumer and business product tiers in its data-handling practices. On consumer terms, you can opt out of model training via Data Controls or the privacy portal, after which new conversations are no longer used to train the models. However, this opt-out depends on a setting and on the product tier you have selected, not on the interface itself. The standard configuration is not always the safest one, and the evidence of a deliberate choice rests with you. Training exclusion is therefore not automatic; it requires active selection, and that selection is available only on certain tiers.

Which concrete controls must you demonstrate?

  1. Document the provider tier and product line for each workflow — record which tier of which provider you use for each distinct use case, and retain evidence of that choice.
  2. Verify the liability cap and indemnity scope that applies — confirm the maximum recoverable damages and the scope of indemnification obligations for the tier you have selected.
  3. Confirm the training opt-out status before processing sensitive content — verify that model training exclusion is enabled for the workflow, and document the date and method of that verification.
  4. Route data according to the contractual defaults in place — design your data flows so that sensitive content reaches only provider tiers whose terms and settings match your obligations.
  5. Record the rationale for each tier selection — document why you chose that provider and tier for that workflow, and what contractual or data-governance requirement it satisfies.

What risks arise from the fragmentation of privacy information?

OpenAI's data-handling rules are split across multiple pages: the help page on data use, the privacy policy updated in September 2026, and the Data Controls interface itself. This fragmentation is itself a risk. A user who reads only the interface sees the option to opt out of training, but may not see the tier-dependent limitations on that option, or the liability caps that apply regardless. The contractual terms and the data-governance settings are therefore not transparent from the interface alone. You cannot rely on the default configuration to be the safest one. Nor can you assume that opting out of training on one tier gives you the same protection as opting out on another.

What can tooling do, and what remains your responsibility?

Data routing tools and workflow controls can help you enforce the tier-specific settings you have chosen and prevent sensitive content from reaching a tier whose terms do not match your obligations. They can also log which tier processed which data, and when. What they cannot do is determine which tier is appropriate for which workflow, or whether the contractual terms of a given provider meet your obligations. That judgement rests with you. The liability caps and indemnity rules are the concrete evidence that provider terms are not interchangeable, and that the choice of tier is not a one-off procurement decision but an operational control you must apply per workflow.

Sources: This article draws on reporting and guidance from OpenAI and Google.

Marit Halversen

Written by

Marit Halversen

Covers AI governance and regulatory design, with a focus on how compliance obligations land on architecture rather than on paperwork.