{"id":184,"date":"2026-06-20T15:15:00","date_gmt":"2026-06-20T15:15:00","guid":{"rendered":"https:\/\/baecke.io\/?p=184"},"modified":"2026-06-20T15:15:00","modified_gmt":"2026-06-20T15:15:00","slug":"ai-procurement-problem-enterprise-ai-contracts-vendor","status":"publish","type":"post","link":"https:\/\/baecke.io\/?p=184","title":{"rendered":"The AI Procurement Problem: Why Most Enterprise AI Contracts Are Written for the Vendor"},"content":{"rendered":"<h2>The Asymmetry That Costs Enterprises<\/h2>\n<p>Enterprise technology procurement has a long history of vendor-favourable contracts. The standard software licence agreement is written by the vendor&#8217;s legal team to protect the vendor&#8217;s interests; the enterprise procurement process negotiates improvements at the margin while accepting the fundamental structure. For conventional software, this asymmetry is manageable: the licence terms that matter are well-understood, the negotiation leverage is quantifiable from the commercial relationship, and the enterprise has decades of experience knowing which terms to fight for.<\/p>\n<p>AI contracts are different. They introduce terms and risk allocations that have no precedent in conventional software procurement, in areas where enterprise legal and procurement teams have limited experience and the vendors have significantly more. The AI vendor&#8217;s legal team has drafted contracts for hundreds of enterprises. The enterprise procurement team is negotiating an AI contract for the first time, or the third time, against vendors whose contractual approach has been refined against every previous negotiation.<\/p>\n<p>The result is a population of enterprise AI contracts with terms that enterprise procurement would never accept in conventional software contracts, accepted because the enterprise did not know they mattered or did not have the leverage or expertise to change them.<\/p>\n<h2>The Terms That Are Most Consistently Unfavourable<\/h2>\n<p>The most consequential areas of vendor-favourable AI contracts fall into four categories.<\/p>\n<p><strong>Model change rights<\/strong> are the category where the gap between vendor sophistication and enterprise preparedness is widest. AI model vendors retain the right to change the model underlying their service at any time, with notice periods that range from 30 days to immediate. The enterprise application built around a specific model&#8217;s capability characteristics, output format, and behaviour may require significant modification when the model changes \u2014 changes that are not the enterprise&#8217;s choice and may not be predictable from the advance notice provided.<\/p>\n<p>The enterprise contracts I review most often contain no constraints on model changes beyond a notice obligation. The vendor can change the model, the enterprise must adapt its application, and the vendor bears no responsibility for the adaptation cost. A well-negotiated contract would include performance benchmarks that the updated model must meet, a parallel operation period during which both model versions are available, and compensation or remediation obligations if the model change requires material enterprise application modification.<\/p>\n<p><strong>Data usage rights<\/strong> are the category with the most significant regulatory risk for European enterprises. The AI vendor&#8217;s default data usage terms typically include rights to use the enterprise&#8217;s data to improve the model, to use inference inputs for safety monitoring, and to retain data for specified periods. For European enterprises subject to GDPR, NIS2, and sector-specific data regulations, these default terms may create compliance exposure that the enterprise legal team has not reviewed.<\/p>\n<p>The specific risk areas: does the vendor&#8217;s model improvement right include using personal data in ways that require explicit consent? Does the inference data retention policy create storage of personal data outside the EU without adequate transfer mechanisms? Does the safety monitoring use of inference data constitute processing for a purpose beyond the original processing purpose in a way that requires additional legal basis?<\/p>\n<p>These are GDPR questions that most AI contracts resolve in the vendor&#8217;s favour by default terms that the enterprise accepts without recognising the compliance implication.<\/p>\n<p><strong>Liability allocation<\/strong> for AI errors and failures is structured in vendor-favourable terms that are significantly more limiting than the liability terms in conventional software contracts. AI vendors typically disclaim liability for the accuracy, completeness, or appropriateness of AI-generated outputs. The enterprise that relies on AI-generated output for a business decision and suffers loss when that output is incorrect bears the full cost, regardless of the model&#8217;s systematic failure to perform as specified.<\/p>\n<p>For AI systems where the enterprise is using AI-generated output in consequential decisions \u2014 credit decisions, medical triage, legal document generation, financial advice \u2014 the liability allocation in the standard AI vendor contract transfers essentially all risk to the enterprise. A well-negotiated contract would include accuracy and performance warranties against specified benchmarks, liability for systematic failure modes, and remediation obligations when the AI system fails to perform as specified.<\/p>\n<p><strong>Exit and portability<\/strong> terms are structured in ways that create dependency without acknowledging it. The AI vendor&#8217;s standard contract does not include data portability obligations that allow the enterprise to export its fine-tuning data, its prompt libraries, its conversation history, and its custom configuration in a vendor-neutral format. The enterprise that has invested in building AI capability on a specific vendor&#8217;s platform discovers, at the point of considering an alternative vendor, that the capability is embedded in a way that makes migration significantly more expensive than the contract terms suggested.<\/p>\n<h2>The Procurement Process That Addresses the Asymmetry<\/h2>\n<p>The enterprise that wants to address the AI procurement asymmetry cannot do so with the conventional procurement process, because the conventional process is not equipped for AI-specific contract terms.<\/p>\n<p>The procurement process that addresses it has three additions to the conventional approach.<\/p>\n<p>AI-specific legal review by counsel with AI contract experience, not just commercial technology legal experience. The GDPR implications of AI data usage terms, the EU AI Act conformity implications of AI vendor liability disclaimers, and the model change risk implications for application architecture are specialised areas that general commercial lawyers address with varying levels of depth. The AI-specific legal reviewer knows which terms to look for and which arguments are credible in negotiation with AI vendors.<\/p>\n<p>Technical AI contract assessment that reviews the contract terms against the enterprise&#8217;s AI deployment architecture. The model change notice period matters differently depending on how deeply the enterprise application depends on model-specific behaviour. The data retention term matters differently depending on the sensitivity of the inference data. The technical assessment connects the contract terms to the architectural risk they create.<\/p>\n<p>Structured vendor comparison that includes contract terms alongside capability and pricing. The enterprise that compares AI vendor contracts across the candidate vendors can identify which vendors offer more favourable terms in each category, and can use this information both to select vendors with better baseline terms and to use competitive alternative terms as negotiating leverage.<\/p>\n<h2>The Leverage Position That European Enterprises Underuse<\/h2>\n<p>European enterprises have leverage in AI vendor negotiations that they consistently underuse: the regulatory compliance requirement that the AI vendor&#8217;s European enterprise clients must meet.<\/p>\n<p>The EU AI Act, GDPR, and sector-specific regulations create a clear specification of the contract terms that European enterprises need from their AI vendors to remain compliant. The enterprise that can articulate &#8220;we cannot sign this contract because the data usage terms create GDPR compliance exposure we cannot accept&#8221; is stating a non-negotiable requirement rather than a preference \u2014 and most AI vendors who want to serve the European enterprise market are willing to negotiate terms that address genuine regulatory compliance requirements.<\/p>\n<p>The leverage requires being specific: not &#8220;we have GDPR concerns&#8221; but &#8220;section 4.2 of your standard data usage terms creates processing of personal data for model improvement purposes that requires explicit consent we cannot obtain under GDPR Article 6, and we need an amendment that excludes personal data from this processing right.&#8221; The specificity converts a concern into a requirement and gives the vendor&#8217;s legal team something to respond to.<\/p>\n<p>The enterprise legal teams and procurement teams that develop this specificity in AI procurement are in a significantly better negotiating position than those that raise general concerns. And the contracts they produce are significantly more protective of enterprise interests than the contracts that emerge from procurement processes that are not equipped for AI-specific terms.<\/p>\n<p>The asymmetry is real. It is also addressable. The enterprises that address it are spending the same legal and procurement resource as those that do not \u2014 but getting materially better contracts.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Enterprise AI contracts are consistently structured in ways that favour AI vendors rather than enterprise buyers \u2014 not through deliberate unfairness but through the asymmetry between vendor legal sophistication and enterprise AI procurement maturity.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-184","post","type-post","status-publish","format-standard","hentry","category-executive-briefings"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=184"}],"version-history":[{"count":1,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/184\/revisions"}],"predecessor-version":[{"id":193,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/184\/revisions\/193"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}