AI Agent Contract Risks: What Companies Should Review Before Signing or Renewing

5. IP ownership includes more than generated output

The second March article examined a common weakness in enterprise AI contracts: the assumption that “the customer owns all output” resolves the IP problem.

It does not.

A complete IP review should cover:

• customer prompts and instructions;

• uploaded documents;

• generated outputs;

• custom templates;

• evaluation datasets;

• feedback;

• fine-tuned weights;

• adapters;

• agent workflows;

• configurations;

• embeddings;

• derived data; and

• vendor-created improvements.

Output ownership also does not guarantee copyright protection. Depending on the facts and applicable law, protection may depend on the level of human contribution. Prompting, selection, editing, arrangement, and review should be documented where the output has material commercial value.

The IP indemnity gap

A vendor may provide an infringement indemnity for its software but exclude content generated through the AI service. That leaves the customer exposed if the system produces code, text, images, or other material that infringes a third party’s rights.

A more balanced agreement should include a targeted indemnity for claims arising from:

• the vendor’s model;

• its training datasets;

• the architecture of the service; or

• the vendor’s operation of the AI system.

The indemnity may reasonably exclude infringement caused by customer-provided material, unlawful instructions, unauthorized combinations, or use outside the agreed service parameters. But the exclusions should not remove the very model-level risk the vendor controls.

Liability caps, defense control, settlement rights, replacement obligations, and mitigation costs also require careful review. A broad indemnity inside a narrow cap may offer little practical protection.

6. The Model Exit Clause: reclaim the company’s AI footprint

The second March article introduced the Model Exit Clause. Its purpose is to protect more than ordinary customer files when an AI relationship ends.

The clause should address four categories of exit assets.

Fine-tuned models and adapters

If the vendor fine-tunes a model using the customer’s proprietary data, the contract should define ownership and transfer rights for the resulting weights, adapters, parameters, and related files.

The customer should know:

• which assets are customer-specific;

• what export format will be provided;

• whether the files can run on another infrastructure;

• what technical documentation accompanies the transfer;

• how quickly the transfer must occur; and

• when the vendor must destroy its copies.

The vendor’s pre-existing foundation model should be distinguished from the customer-specific layer built through customization.

RAG embeddings and semantic indexes

A RAG system may convert corporate documents into embeddings and store them in a vector database. These embeddings are not harmless technical residue. They may preserve information about the customer’s confidential documents and can remain useful for retrieval even after the source files are removed.

The contract should classify vector embeddings, semantic indexes, retrieval databases, and RAG caches as confidential information or personal data where applicable.

Conversation history and long-term memory

Agentic systems may retain user preferences, past conversations, task history, and operational context. Those records should be subject to defined retention and deletion rules.

The PCPD’s August 2026 guidance specifically calls for timely erasure of personal data in conversation histories, cache data, and long-term memory.

Proof of destruction

A vendor should provide more than an email saying that deletion is complete.

The exit process should include:

• a defined deletion deadline;

• destruction of active and backup copies;

• treatment of legal holds;

• deletion logs;

• a certificate of destruction;

• continuing confidentiality obligations; and

• a time-bound right to review relevant evidence.

The company should be able to show a regulator, auditor, board, or court what was deleted, when it was deleted, and how the vendor verified the result.

7. Change management: the contract must cover silent expansion

AI capabilities can change without a new order form.

A vendor may introduce a new model, add a subprocessor, enable an agent, expand data grounding, change retention practices, or revise its acceptable-use terms through updated online documentation.

The customer should ask:

• What counts as a material AI change?

• How much notice must the vendor provide?

• Can the customer reject or disable the change?

• Can the vendor add a new model provider?

• Can a new connector access existing enterprise data?

• Does a material change create a termination right?

• Can the customer retain an earlier version for a transition period?

The agreement should not allow the vendor to transform a drafting assistant into an autonomous system while continuing to describe the service as the same product.

For material AI capabilities, release notes may be insufficient. The customer may need a contractual notice, updated data-flow documentation, revised security information, and an opportunity to test the change before production use.

8. Internal AI policies are part of the control environment

Vendor diligence cannot compensate for an organization that has no rules for its own employees.

The PCPD’s compliance-check findings emphasized internal AI policies, employee training, incident response, and continuous review. The PCPD also maintains a checklist intended to help organizations develop internal guidelines for employee use of generative AI.

An internal AI policy should address:

• approved and prohibited tools;

• permitted data categories;

• confidential information;

• personal data;

• prompt and output handling;

• review of generated content;

• source-code restrictions;

• human approval;

• incident reporting;

• records retention;

• use of personal accounts; and

• consequences for bypassing controls.

The policy should distinguish between public AI tools, enterprise AI tools, internally hosted systems, and vendor-embedded features. Employees may assume that an AI function inside a familiar platform is automatically approved. It may not be.

Training should also cover agentic behavior. Staff need to understand that an AI system with access to email, documents, calendars, or business applications can create risks even when the user did not intentionally upload a sensitive file.

9. If the vendor will not negotiate, reduce authority and document the risk

Large software providers may refuse customer-specific AI terms. A buyer may still reduce exposure through configuration and governance.

The practical response is to:

• disable unnecessary generative and agentic features;

• restrict API scopes;

• mask sensitive fields;

• separate high-value IP from general business data;

• limit connectors and plugins;

• use read-only access where possible;

• require approval before consequential actions;

• configure retention and memory settings;

• test permissions in a controlled environment; and

• document the residual risk and its owner.

These measures do not replace a strong contract. They reduce the consequences of a weak one.

The buyer should also preserve the vendor’s written responses, including any refusal to provide no-training terms, deletion commitments, model-provider transparency, or audit rights. That record helps demonstrate that the risk was identified and addressed through a deliberate decision rather than accepted without review.

For a structured renewal review, readers should see LexGuard’s related article, “AI Vendor Risk: What to Review Before Renewing Enterprise Software,” which explains how to examine embedded AI features, model providers, subprocessors, data access, change management, and disablement controls across the enterprise software supply chain.