Why AI Risk Is Now Surfacing in Ordinary Boilerplate The hardest redlines across commercial agreements are no longer centred on price or service levels. Increasingly, they arise where legacy boilerplate meets day-to-day AI-enabled workflows. Standard terms drafted for an earlier technology environment are now being tested against drafting tools, coding assistants, knowledge retrieval systems, and automated support built into ordinary business operations. That disconnect matters because familiar clauses can create immediate breach risk, expand a vendor’s rights over commercially sensitive information, narrow indemnity protection, and frustrate meaningful oversight. In many negotiations, the real question is not whether AI is being used at all, but whether the contract accurately reflects how the work is actually being done. Originality Warranties and the “Wholly Original” Problem Originality language often looks routine. A service provider may warrant that all deliverables are “original and solely created by Vendor.” In an AI-assisted workflow, that representation can become inaccurate the moment a team uses a large language model to help prepare code, documentation, summaries, or other work product. The issue is less about whether the output is useful and more about whether the warranty remains true. How De-Identified Data Rights Become Backdoor Training Rights The clause that most consistently creates friction is the vendor’s broad right to use aggregated, anonymized, or de-identified customer data. In a traditional SaaS agreement, that wording may once have been read as ordinary service analytics. In an AI deployment, the same language can operate as a backdoor training right, especially where it is broad enough to capture prompts, outputs, workflow patterns, or deal logic. The concern is not limited to re-identification. The more difficult risk is that customer information may influence model parameters, evaluation datasets, or product functionality in ways that cannot later be isolated or unwound. That is why sophisticated customers increasingly press for precise restrictions on training, fine-tuning, evaluation, human review, and reuse by subprocessors or underlying model providers. IP Indemnities That Read Broadly but Protect Narrowly AI suppliers frequently present infringement indemnities as a meaningful comfort point. The difficulty is that the protection often narrows quickly in the exclusions. A defence that sounds broad at headline level may disappear if the output was generated from the customer’s prompt, modified by the customer, or combined with other software or data. Small drafting differences can materially shift where the risk sits in practice. When Audit Rights Meet Black-Box and Trade Secret Objections Audit rights create a similar tension between commercial expectation and technical reality. Customers want meaningful visibility into compliance controls, data handling, and decision logic. Vendors, by contrast, often argue that model weights, internal routing, and related architecture are protected trade secrets. The practical answer is rarely unfettered access; it is a realistic transparency framework that gives customers useful assurance without pretending every black-box system can be opened in full. What to Negotiate Instead The answer is not to prohibit AI tools outright. For most organisations, that is neither realistic nor commercially efficient. The better approach is to replace outdated representations with bounded, workable terms that reflect actual workflows and allocate risk with greater precision. First, contracts should expressly permit defined AI-assisted use in preparing deliverables while preserving the vendor’s responsibility for the final work product. That removes the false comfort of absolute originality language and replaces it with a representation the vendor can realistically stand behind. Second, prompts, outputs, embeddings, uploaded materials, and similar inputs should be treated as confidential customer information unless the contract expressly states otherwise. Leaving those categories inside broad, generic data-use language is what allows routine service-improvement wording to become something much more expansive. Third, de-identified data rights should be limited to tightly defined operational telemetry and usage analytics that do not reveal customer content, business logic, or deal patterns. This is often the most important drafting move because it draws a clear line between legitimate service administration and impermissible model development. Fourth, the agreement should prohibit the use of customer data to train or improve shared or third-party models unless the customer gives informed, express consent. That restriction should also address prompt-data reuse, evaluation activities, and human review workflows, not only formal model training. Fifth, the same restrictions should flow through to subprocessors and underlying model providers. Protections negotiated with the immediate vendor lose much of their value if they do not travel across the full delivery chain. Sixth, output ownership, risk allocation, and indemnity language should be aligned with real-world use. Clearer rules around modification, combination, downstream reliance, and defence obligations can materially reduce disputes when AI-assisted output is later challenged. Finally, compliance and transparency obligations should be realistic. Businesses should ask for meaningful information about data handling, governance controls, incident response, and compliance posture, while treating deletion obligations separately from the distinct question of model unlearning. The contract should also make clear that prohibited customer data is not to enter model weights in the first place. A Practical Takeaway for Business Leaders Businesses do not reduce risk by assuming AI is absent from the workflow. They reduce risk by ensuring their contracts reflect how work is actually being performed. For founders, owners, and senior executives, the immediate task is not to ban the technology, but to make sure standard terms are updated before legacy boilerplate quietly reallocates the risk. This content is not legal advice. Please obtain advice based on your specific circumstances before relying on it