Cybersecurity · Contributor

Nobody Reads the Terms of Service. That Is Exactly How AI Vendors Want It

This article goes inside the specific clauses that matter most, training data rights, liability caps, IP provisions, data retention, and sub- rocessor governance and gives every founder and legal team the questions to ask before the next AI vendor contract lands on their desk.

By
Stella Ojiuba
Published
September 30, 2026
Issue
09 · September 25 – October 8, 2026
Read
8 min
Nobody Reads the Terms of Service. That Is Exactly How AI Vendors Want It
Submitted by Stella Ojiuba · Build With Her Magazine

Somewhere between the third slide of the demo and the moment the sales rep sent over the contract, you fell in love with the product.

It was fast and intuitive. It did in four minutes what your team had been spending four hours doing. The ROI was obvious and the integration was clean. The vendor's security page had the right logos, SOC 2, ISO 27001, GDPR compliant and their responses to your security questionnaire were confident and thorough.

You signed, everyone does. What almost nobody does in the rush of the demo high, the pressure of the procurement timeline, the quiet confidence that the logos mean what they imply is read the terms.

Not skim them or send them to legal with a note that says "let me know if anything looks off." You have to read them. Every section, definition and every clause buried in the exhibit that starts on page thirty-seven and governs what the vendor can do with the data your organisation submits to their AI systems.

That clause, the one on page thirty-seven, is the one that matters most. And it almost certainly says something your leadership team would not have agreed to if it had been explained in plain language before the contract was signed.

The Document Your Legal Team Does Not Have Time to Read

There's something about enterprise AI vendor contracts that most organisations discover too late.

They are long by design, not because the legal complexity genuinely requires three hundred pages of dense provisions but because length is a strategy. A document that takes eleven hours to read properly is a document that will not be read properly. The provisions that benefit the vendor are not hidden in the sense of being illegible. They are hidden in the sense of being unreachable, buried under enough preceding clauses that the reader who started with genuine intention has lost the will to continue by the time they arrive at the part that matters.

This is not accidental. The teams that draft these contracts are sophisticated. They know exactly where to place the provisions that would generate friction if surfaced early in the conversation. They know that the procurement pressure your organisation feels, the timeline, the budget cycle, the business case already approved by the leadership team works in their favour. They know that "let me know if anything looks off" is not a legal review, it is a wish. They know that once you have signed, the leverage has shifted entirely to them.

What AI Vendor Contracts Actually Say, The Provisions That Should Stop You Cold

Let me take you inside the specific provisions that most organisations never reach, the ones that govern the relationship between your data and your vendor's AI systems.

  • Training Data Rights

Many AI vendor contracts include provisions that grant the vendor the right to use data submitted to their platform to train, fine tune, or improve their AI models. Read that sentence again.

The prompts your team submits. The documents they upload. The customer data they process through the platform. The proprietary code your engineers paste in. The strategic memos your executives draft. All of it potentially becoming training data for a model that will be used by the vendor's other customers including your competitors.

Some vendors offer an opt out. Some offer enterprise tiers where training data rights are excluded. While some have tightened these provisions in response to regulatory pressure and customer scrutiny. But the default, the baseline that applies to every customer who does not specifically negotiate otherwise often includes training rights that most organisations would never have agreed to if they had been presented with them directly.

The question is not whether your vendor has this provision. The question is whether you have read it, understood it, and made a deliberate decision about it rather than discovering it after the fact when the question of what your data trained is no longer theoretical.

  • Liability Caps That Protect Everyone Except You

AI systems make mistakes. They hallucinate and produce outputs that are confidently wrong. They generate content that, in the wrong context, creates legal, reputational, or compliance exposure for the organisations that rely on them.

Most AI vendor contracts include liability caps that limit the vendor's financial responsibility for these errors to a fraction of the annual contract value. Some cap liability at a single month's fees. Some exclude liability entirely for outputs generated by the AI system, on the grounds that the outputs are the product of a model rather than a direct service.

What this means in practice is that when your organisation acts on an AI generated output that turns out to be wrong in a financial model, a legal document, a medical summary, a compliance assessment, the vendor's liability for the consequences is constrained to an amount that bears no relationship to the actual cost of the error.

Your liability, as the organisation that deployed and relied on the system, is not similarly constrained. The risk of AI error sits primarily with you. The contract should reflect that reality, most do not.

  • Intellectual Property Provisions That Are Not What They Appear

There is a question most organisations have not answered clearly, who owns the outputs of the AI work your team does?

Most AI vendor contracts include provisions about output ownership and most of them say, in one form or another, that the customer owns the outputs generated through their use of the platform. That sounds reassuring but it is not the whole picture.

What those provisions typically do not address clearly is the underlying IP embedded in the model that generated the outputs. If your team uses an AI system to generate a product description, a software architecture, or a legal brief, and that system was trained on data that included copyrighted material, the output may carry IP entanglement that the ownership provision does not resolve.

Several ongoing legal cases are currently working through precisely this question. The outcomes will shape the IP landscape for AI generated content in ways that no current vendor contract fully anticipates. What this means for your organisation is that the confident assertion of output ownership in your vendor contract may be worth significantly less than it appears and the legal exposure it leaves unaddressed is real.

  • Data Retention Provisions That Outlast the Relationship

How long does your vendor retain your data after the contract ends?

This question has a specific and important answer in most enterprise software contracts. In AI vendor contracts, the answer is often more complicated because the data your organisation submitted may have been used in model training, and trained model weights are not the same as raw data that can be cleanly deleted.

Many AI vendor contracts include data deletion provisions that apply to the raw data submitted to the platform. Fewer clearly address what happens to the model weights that were updated using that data. Fewer still provide any mechanism for verifying that deletion has actually occurred.

The consequence is that the end of your vendor relationship may not mean the end of your data's presence in the vendor's systems in a form that cannot be easily identified, audited, or deleted.

  • Sub Processor Chains That Your DPA Does Not Fully Govern

I wrote in a previous article about the sub processors behind the vendor you trust. AI vendors add a specific dimension to this problem. The AI model powering your vendor's product may be developed and maintained by a separate organisation, a foundation model provider whose own terms of service govern the data processing that happens at the model level. The vendor you contracted with may have limited ability to guarantee the data handling practices of the foundation model provider and their DPA may not extend meaningfully to that layer of the stack.

This means that the data governance commitments in your vendor contract may not cover the part of the system where the most significant AI processing actually happens. The DPA you signed governs the relationship with your vendor. It may not govern the relationship between your vendor and the foundation model on which their product is built.

The Three Questions You Should Have Asked Before You Signed

I am not writing this to tell you that you made a mistake. I am writing this because the information needed to ask the right questions is not always available before the demo ends and the contract arrives.

These are the three questions that matter most, the ones to ask before the next AI vendor contract lands on your desk.

  • Does this contract include training data rights over the content we submit, and if so, what is the process for opting out?

The answer to this question, and the ease or difficulty of the opt out process, will tell you more about the vendor's data practices than any compliance logo on their website. A vendor that makes the opt out easy and defaults to data protection is a different kind of partner than one that buries training rights in exhibit C and makes opting out an enterprise tier feature.

What is the liability framework for AI errors, and does it reflect the actual risk our organisation carries when we act on AI generated outputs?

This question will not make you popular with the vendor's sales team. Ask it anyway. The answer will determine whether your contract gives you any meaningful recourse when the AI system produces an error with material consequences or whether the risk sits entirely with you regardless of what went wrong and why.

What is your data deletion process when the contract ends and does it cover model weights updated using our data?

The vendor who can answer this question clearly, specifically, and in writing is the vendor who has thought through their data obligations at the level that your organisation's data deserves. The vendor who cannot answer it or who answers it with confident vagueness is telling you something about the depth of their data governance programme.

What to Do About the Contracts You Have Already Signed

Most organisations reading this have already signed AI vendor contracts. Some of them were signed before these questions were being asked in procurement conversations. Some were signed by teams that did not know what to look for. Some were signed under time pressure that did not allow for the level of review they deserved.

The question is not what you should have done. The question is what you do now.

Conduct a contract audit of your current AI vendor agreements. Focus specifically on training data rights, liability provisions, IP ownership, data retention, and sub-processor governance. Build a summary of what each contract actually says, not what you assumed it said and present it to your legal and leadership teams.

Where contracts include provisions that your organisation would not knowingly have agreed to, use the first available opportunity, contract renewal, expansion negotiation, or a direct conversation with the vendor to renegotiate. Vendors who want to keep your business at scale have more incentive to negotiate than their sales process suggests.

Where renegotiation is not possible, implement compensating controls. If your vendor retains training data rights and you cannot negotiate an opt out, implement a data classification programme that prevents sensitive data from being submitted to that system. If liability caps are immovable, ensure your organisation's cyber insurance reflects the actual risk exposure the contract creates.

And for every new AI vendor relationship going forward, read the contract. Specifically, carefully, before the signature. Not as a formality, as the first line of defence between your organisation's data and the provisions of a document that was not written with your interests as the primary consideration.

The Conversation That Needs to Happen in Every Boardroom

AI adoption is accelerating faster than AI governance in most organisations. The business case for AI tools is clear, compelling, and championed by the teams that use them. The governance case the case for understanding what the contracts actually say before signing them is slower, less exciting, and easy to dismiss as the legal team being cautious.

That dismissal is expensive. The organisations that will navigate the AI vendor landscape most effectively over the next five years are not the ones that adopted the most tools the fastest. They are the ones that built the governance infrastructure, the contract review capability, the data classification framework, the vendor assessment process that allows them to adopt tools at speed without accumulating the legal, compliance, and IP exposure that unreviewed AI contracts create.

That infrastructure starts with a simple decision, to treat AI vendor contracts as the significant legal documents they are, rather than the formalities they are designed to appear to be.

The terms of service are not fine print. They are the actual agreement.

Read them like they matter.

Because they do.

About the contributor
Stella Ojiuba
Cloud Security Analyst · Build With Her Magazine

Stella Ojiuba writes about engineering culture, infrastructure, and the people behind the systems we all depend on.

Conversation

0 comments on “Nobody Reads the Terms of Service. That Is Exactly How AI Vendors Want It”

Comments from signed-in readers are published immediately. Keep it professional.

Sign in to join the conversation.

Keep Reading

More from Cybersecurity

This story is part of the archive behind Impossible to Overlook, Build With Her's first editorial report.

Read the report →
A Note From The Editors

Every story we publish is a reminder that more women are building than the world often sees.

Build With Her exists to document women who are building, leading, learning, surviving, creating, and becoming visible.

If this article resonated with you, maybe your story belongs here too.

You do not need to have everything figured out. You do not need a perfect title, a perfect company, or a perfect journey.

You only need a story worth sharing.