AI contracts: what companies lose in the fine print

AI agreements are no longer about licences and subscription fees. They decide who controls your data, who can profit from your intellectual property and what survives after the vendor relationship ends.

Picture a company that spent years building proprietary technology and a customer database to match, then discovers its AI vendor is contractually permitted to use part of that information to improve its own products. The vendor has breached nothing. The agreement allowed it from the start.

This is the shape of the problem facing companies adopting AI. Organizations are deploying assistants, wiring large language models into internal databases and building products on generative AI, while the contracts governing those relationships carry assumptions from an earlier kind of software. A poorly negotiated agreement can expose confidential information, weaken IP protection, create unexpected liability and leave sensitive assets unrecoverable when the relationship ends.

Writing in The Licensing Journal in October 2026, attorney Matt Kohel examines why traditional software agreements are increasingly inadequate for AI systems. The implications reach past the legal department: procurement, technology leadership, security and AI governance teams all hold part of the answer.

Why traditional software agreements fall short

Conventional software agreements were built for deterministic systems, where static code processes defined inputs and returns predictable, repeatable outputs. A company subscribed, uploaded data and received results. Boilerplate covering confidentiality, data ownership, availability and termination addressed most of the risk, because IP exposure was bounded and data flows were easy to draw on a whiteboard.

Generative AI breaks that model. A single application may process sensitive documents, pull information from corporate databases, generate new intellectual property and act on external systems. Depending on its architecture and the permissions buried in the contract, it may also use what it sees to improve models or other services.

Consider an assistant connected to an internal knowledge base. Employees interact with a chat box, but the system underneath may reach financial forecasts, source code, customer records, legal documents and strategic plans. The information at stake extends far beyond whatever someone types into the prompt. A workable AI agreement has to account for the full flow: what the system reaches, what it produces and what the vendor may keep or reuse.

The hidden risk in "we don't train on your data"

Most enterprise AI vendors will promise that customer information is not used to train their models. It sounds like the end of the conversation and it rarely is. The same agreement often permits the vendor to use customer data to "operate, maintain, enhance, and improve the Services". That language was low-risk in traditional SaaS, where it covered telemetry, bug fixes and monitoring. In an AI system it is anything but.

Kohel calls this the "improve the services" trap and the mechanics are worth stating plainly: a vendor can use the content of a prompt, along with prompt patterns and semantic structures and characterise the activity as service improvement instead of formal model training. A covenant against training becomes close to meaningless if the vendor keeps that parallel right.

The second gap is the word training itself. Machine learning updates extend well past the initial training run and several of them can exploit customer material without meeting a narrow technical definition:

• Fine-tuning on customer documents or interactions
• Model optimization and distillation
• Reinforcement learning from user feedback and corrections
• Evaluation and benchmarking against customer material
• Aggregation, de-identification or anonymization, which can expose structure, patterns and metadata

So the question to put to a vendor is not whether it trains models on your information. It is whether the vendor may use any part of that information, directly or indirectly, to develop, optimize, evaluate or improve AI systems for any purpose beyond delivering the service you are paying for. The same restriction needs to bind subcontractors and third-party model providers, or it leaks at the first hop.

Your data is more than what you upload

Traditional SaaS contracts tend to define customer data as information uploaded to or stored within the software, which is too narrow for the way AI systems reach information. A retrieval-augmented generation (RAG) application connected to a document repository retrieves what it needs at runtime to ground its answers, without necessarily altering the model's parameters. No employee uploaded a thing and the system is reading corporate records all the same. Agents and Model Context Protocol (MCP) integrations widen this further, letting applications touch databases, files, APIs and external tools.

A definition that holds up should cover:

Anything excluded from that definition may not inherit the ownership, confidentiality, retention and deletion protections negotiated everywhere else in the agreement. The wording of one definition can decide how much control an organization keeps over its own intellectual property.

Who owns AI-generated work?

Suppose your teams use AI to generate code, build financial models, design products or produce research. It is tempting to assume that paying for the service means owning everything it produces and the legal position is considerably more awkward than that.

US copyright law treats human authorship as a bedrock requirement. In Thaler v. Perlmutter, the D.C. Circuit held that works created exclusively by AI systems are ineligible for copyright protection and the Supreme Court denied certiorari in March 2026. Copyright Office guidance adds that prompt engineering and iterative generation are generally not enough on their own. Patent law draws a parallel line: in Thaler v. Vidal, the Federal Circuit held that only natural persons can be inventors and presenting a problem to a system or asking it for a solution does not qualify.

This creates a gap between contractual ownership and statutory IP rights that no amount of drafting closes. A vendor can assign whatever rights it holds in an output, but a contract cannot manufacture copyright where the law declines to recognise it. Two practical consequences follow.

Contractual protection carries more weight than usual, so agreements should spell out ownership and permitted use of outputs, including whatever rights the vendor can lawfully assign and whether it keeps any ability to reuse, redistribute or commercialise outputs derived from your information. Where outputs hold commercially valuable confidential material, trade secret protection and confidentiality obligations may do work that copyright cannot. To preserve patentability, teams need contemporaneous records showing how people formulated hypotheses, defined parameters and developed the inventive concept before the machine was involved.

The overlooked value of metadata and usage patterns

Not every IP risk involves a document leaving the building. An organization using AI to analyse acquisition targets, evaluate suppliers or develop products generates a trail of query patterns, file structures, workflows and usage history and that trail can be read. Someone who never sees the underlying documents can infer priorities, timing and direction.

The difficulty is that AI systems produce technical artifacts constantly and the sensitive ones are mixed in with the mundane: token usage statistics, document schemas, vector embeddings, tool execution records. Some of it is ordinary platform telemetry that vendors genuinely need to run the service, monitor performance, investigate incidents and calculate usage-based billing. Those operational needs are legitimate and they are not a reason to hand over unrestricted rights to analyse or commercialise customer-derived information. The agreement should draw the boundary explicitly, because no one will draw it after signing.

Buying AI and building AI need different contracts

Licensing a commercial assistant and commissioning a custom model trained on your proprietary data are different transactions with different failure modes.

Custom development is where the real value changes hands. Imagine a financial services firm hiring a development partner to build a system fine-tuned on its internal risk methodology: the resulting model embodies years of proprietary expertise. If the agreement does not allocate ownership and reuse rights clearly, the developer may retain rights to components of it and may be free to reuse them, potentially for competitors.

Three arrangements come up in these negotiations. Customer ownership is the cleanest. Developer ownership paired with an exclusive customer licence can work, provided the contract establishes a field-of-use or industry-specific commercial silo and bars the developer from re-licensing deliverables or functionally equivalent configurations to competitors.

Joint ownership is the one to watch, because it looks like a fair compromise and behaves like gridlock. A vendor co-owner may be able to license the technology to your competitors without consent or royalty sharing unless the contract says otherwise. Enforcement against an infringer may require both owners to join the suit, so a developer unwilling to sue its other clients can paralyse your remedies. Co-ownership can also undercut trade secret status, by handing a defendant the argument that you failed to take reasonable measures to preserve secrecy. Kohel's assessment is blunt: joint ownership is almost always the worst commercial outcome and customers should prefer sole ownership with defined vendor usage and retention restrictions.

AI agents introduce a different category of risk

Traditional AI applications generate responses. Agentic systems take actions: retrieving records, modifying files, calling external APIs, initiating transactions, operating business applications. That shift raises a question contracts rarely answer: who is responsible when an agent does something it should not have?

An agent might send confidential information to an external application, alter sensitive records, or trigger a transaction no one approved. Technical controls matter here and they do not settle the allocation of responsibility. The agreement should define which operations are authorized, what access limits apply and where human approval is mandatory, then set expectations for audit trails, incident notification, investigation and liability. As agents gain autonomy, those obligations need to track what the systems can do, not how they are marketed.

What happens when the contract ends

Termination gets less attention than it deserves and AI makes it harder than it used to be. Traditional agreements offer a standard window to return or delete customer information. In an AI system, the original documents are only part of what exists: there may be vector embeddings, search indices, caches, logs and fine-tuned artifacts derived from your data. Deleting the source does not necessarily remove the derivatives.

Where information was absorbed into a model through training or fine-tuning, removing its influence is harder still. Machine unlearning techniques exist and reliable, complete removal is not something to assume in a negotiation. That is the argument for prevention over cure: an organization should not rely on deletion rights at the end if the agreement already permits its data to be folded into reusable models at the beginning.

For deployments involving proprietary or sensitive data, termination provisions should cover deletion or return of data and derived artifacts, any retention exceptions and their justification, verification that deletion took place and the survival of confidentiality and IP obligations. Custom builds need more: what becomes of model checkpoints, custom weights and specialized datasets. An exit strategy only works if it is designed before signing.

Contract review belongs in AI governance

These agreements are usually negotiated by legal and procurement, with security reviewing the technical schedules. The gap is that several of the risks above cannot be assessed from the contract language alone. Judging whether a training restriction holds requires knowing how models are developed and updated. Assessing a deletion commitment requires understanding the architecture and its data flows. Evaluating an agent's obligations requires visibility into its integrations and permissions.

That is governance work and it depends on having a reliable inventory of AI systems and vendors, named ownership for each use case, documented risk assessments and a process for revisiting contractual obligations across the lifecycle. An AI vendor assessment should go beyond a cybersecurity questionnaire to ask how customer data is used, whether models can be improved with it, what the vendor discloses about training data provenance and how proprietary assets are handled at the end.

Review also has to be continuous instead of a one-off procurement formality, because vendors ship new AI features, change subcontractors, expand integrations and update their terms. Each of those can move your risk exposure even when the original agreement was negotiated carefully.

Questions to answer before signing

Not every AI contract needs to be treated as a fresh legal problem, but each one needs a review that reflects the technology. Start by establishing the business purpose and the information the system will process, then work through the following with legal, procurement, security and governance in the same room:

• What can the system access, including anything retrieved automatically from connected services?
• Can the provider use customer information, outputs or derived data for training, optimization or product improvement and does that restriction bind subcontractors and model providers?
• Who owns the outputs and any custom-developed components?
• What rights does the vendor retain after termination?
• What protections apply if training data or generated outputs trigger third-party IP claims and does indemnification flow through to cover them?
• How are confidential information, embeddings and model artifacts isolated from other tenants?
• Can you verify that your information and its derived assets were deleted?

For organizations running several AI vendors, consistency is its own control. Standard contractual requirements with a documented exception process stop important protections from being negotiated away differently in each department.

Protecting IP starts before deployment

AI gives businesses room to automate operations, accelerate research and build things that were not practical before. It also changes how proprietary information moves between an organization and its technology providers.

The most serious risks here are not breaches or obvious misuse. They are permissions granted knowingly but without a full reading: a provider allowed to reuse information for model improvement, a development partner holding rights to customized technology, sensitive metadata sitting outside the definition of customer data, information believed deleted that survives in derived artifacts.

The goal is to make sure an organization knows what it is giving away, what it is protecting and what it will hold once the relationship ends. As AI becomes part of critical business infrastructure, contractual governance stops being a peripheral legal concern and becomes a core part of managing enterprise AI risk.

---

Further reading

This article draws on Matt Kohel, Contractual IP Protection in the Age of AI: Structuring Deployment and Development Agreements, published in The Licensing Journal, October 2026.

Read the original paper (PDF)

This article is provided for general informational purposes and does not constitute legal advice. Intellectual property rights and contractual obligations depend on applicable law and the specific agreement.