# How Should Companies Review AI Vendor Contracts in 2026?

infonesia.fyi · October 2, 2026

> What Should an AI Vendor Contract Actually Cover? AI vendor contracts should allocate responsibility for the model, data, software, human decisions...

## What Should an AI Vendor Contract Actually Cover?

AI vendor contracts should allocate responsibility for the model, data, software, human decisions, security incidents, regulatory compliance, service availability, and commercial outcomes across the full vendor relationship. A standard software-as-a-service agreement is a starting point, but it is not designed to answer questions such as who owns prompts created by employees, whether a vendor may train a model on those prompts, what happens after a model generates discriminatory employment recommendations, or how quickly the supplier must notify the customer after a breach. The central issue is not simply whether the vendor is reliable; it is whether the written allocation of control matches the importance of the decisions the system will influence. For Indonesian and Southeast Asian teams, the contract should also account for cross-border processing, differing data-protection regimes, sector rules, local implementation requirements, and the possibility that a global group imposes stricter standards than local law requires.

**Also worth reading:** [What are the legal and operational risks of signing agentic AI vendor contracts in Indonesia as of September 2026?](https://infonesia.fyi/knowledge/what_are_the_legal_and_operational_risks_of_signing_agentic_ai_vendor_contracts_in_indonesia_as_of_september_2026.php) · [What Do Indonesian Companies Need to Know About AI Compliance in 2026?](https://infonesia.fyi/knowledge/what_do_indonesian_companies_need_to_know_about_ai_compliance_in_2026.php) · [Indonesia AI Governance Guide: What Should Companies and Public-Sector Teams Do by September 2026?](https://infonesia.fyi/knowledge/indonesia_ai_governance_guide_what_should_companies_and_public-sector_teams_do_by_september_2026.php)

A useful AI contract defines each role before defining each benefit. “Provider,” “customer,” “deployer,” “business user,” and “affected person” should not be used interchangeably because responsibility changes depending on whether the supplier creates a model, the customer operates a use case, and an individual receives a decision. A vendor may provide general-purpose software while the customer determines its purpose, access conditions, retention period, and escalation process. That division can work, but only if the agreement states it plainly. Generic promises that the vendor supplies a tool “for the customer’s purposes” often leave the hardest operational questions unresolved. A contract suitable for AI procurement should connect legal allocation to named controls, measurable service levels, and documented procedures rather than relying on broad statements of compliance.

## Why a Normal SaaS Contract Falls Short for AI

AI changes the risk profile of software because behavior can be probabilistic, outputs may become inputs to later decisions, and a system can create new personal or confidential information without an employee deliberately entering it. Conventional SaaS contracts commonly address uptime, source-code escrow, data deletion, and payment, but they may not address model updates, prompt logs, retrieval databases, fine-tuning datasets, generated content ownership, model memorization, red-teaming, or third-party model providers. The difference is particularly important when a customer’s operational process becomes dependent on outputs that appear authoritative but are occasionally incorrect. Ward and Smith’s analysis of AI vendor deals makes this central point: existing SaaS buying habits may underestimate the governance and contract terms required for systems whose outputs affect real decisions.

The contract must therefore cover the entire technical chain. The vendor should disclose whether the service uses its own foundation model, a third-party model, customer-specific fine-tuning, external APIs, or a combination of these. It should identify where inference occurs, where logs and embeddings are stored, which subprocessors receive data, and whether any component is supplied by an affiliated company. Changes to a foundational model provider or hosting region can alter security, latency, and regulatory exposure even when the customer’s commercial interface appears unchanged. If the supplier cannot provide this information, a low headline price is not an adequate substitute: the customer would be assuming unknown dependencies and cannot determine whether its controls are operating against the actual service.

| Contract topic | Ordinary SaaS treatment | AI-specific treatment |
| --- | --- | --- |
| Data use | Processing to provide contracted services | Processing plus express limits on training, fine-tuning, evaluation, and product improvement |
| Availability | Server and application uptime | Uptime, latency, model quality thresholds, incident response, and degradation procedures |
| Outputs | Limited functionality warranty | Accuracy limits, prohibited uses, disclosure of material model changes, and escalation rights |
| IP | Customer data and software licenses | Prompts, outputs, embeddings, fine-tuned weights, feedback, and generated artifacts addressed separately |
| Security | Baseline controls and breach notice | Model supply chain, prompt injection, poisoning, leakage, access logging, red-team testing, and subprocessor transparency |
| Termination | Access cessation and deletion | Deletion verification, transition assistance, model or log portability, and deletion of derived data |

## How to Review Data Rights, Model Behavior, and Ownership
The first substantive review is the data clause. A customer needs a clear prohibition on using its prompts, documents, recordings, feedback, or fine-tuning materials to train a shared or customer-specific model unless the contract provides a specific, lawful permission. “Improve our services” is too ambiguous when it could include generating embeddings, analyzing failure patterns, correcting responses, or training another model. The clause should distinguish data processed to provide the purchased service from data retained for security, billing, product analytics, and future model training. It should also state whether de-identified or aggregated information remains customer data, whether it can be used for benchmarking, and what happens when a user leaves an organization or is subject to a litigation hold.

Output ownership requires a similarly careful approach. A contract may promise that the customer owns its input data but remain silent about whether the customer owns generated text, code, designs, recommendations, or synthetic records. Broad intellectual-property warranties can be misleading if they do not account for the fact that generative outputs may resemble protected material or resemble material generated for another customer. The parties should state whether the vendor gives the customer rights to use, modify, commercialize, and store outputs, while also specifying the vendor’s responsibility for third-party claims arising from its model or contractual warranties. The customer should not assume that payment transfers copyright in every jurisdiction, so legal advice may still be needed for regulated or high-value output.

Model behavior should be described through measurable commitments. Depending on the use case, the agreement may require notice before a major model-version change, a right to test a replacement, an accuracy threshold on an agreed evaluation set, or suspension rights if a material regression creates unacceptable risk. Not every vendor can guarantee factual accuracy in an open-ended system, and a customer should be skeptical of warranties that promise perfection without defining testing conditions. Better language ties obligations to a documented evaluation dataset, acceptable tolerance, review frequency, and remedy. For consequential uses, the agreement should preserve the customer’s authority to keep a human in the decision loop rather than forcing automation to meet a service level.

## Which Security, Regulatory, and Accountability Clauses Matter?

AI security clauses should connect general compliance language to the vendor’s actual architecture. The parties should identify encryption in transit and at rest, privileged-access management, multi-factor authentication, logging, vulnerability management, penetration testing, backup, recovery, and geographic hosting arrangements. They should also address prompt injection, malicious documents in retrieval systems, training-data poisoning, model extraction, insecure tool use, secret leakage, and unauthorized agent actions. These threats differ from a conventional application defect, and simply saying the vendor follows “industry-standard security” does not establish whether it has tested for them.

Regulatory language should be specific about scope. The EU AI Act, whose obligations are being phased in from 2025 through 2027, distinguishes prohibited practices, high-risk systems, transparency duties, and general-purpose AI obligations. A vendor may be a provider of a general-purpose model, while a customer may become a deployer or otherwise assume duties based on how the system is used. Contracts in 2026 should therefore identify the intended role, provide technical documentation and logs where required, and allocate tasks for conformity assessment, registration, incident reporting, and cooperation with authorities. The parties should avoid promising that a certificate or vendor statement automatically resolves every customer obligation. Regulatory responsibility normally follows factual control and use, not just the label chosen in a contract.

Indonesian organizations must also apply the Personal Data Protection Law and its implementing rules, while checking the latest enforcement status and sector-specific requirements as of the contract and renewal dates. Cross-border transfers can trigger notification, contractual, consent, or other requirements depending on the data and applicable regime. The contract should name processing locations, international-transfer safeguards, and the vendor’s assistance with data-subject requests, impact assessments, regulator inquiries, and breach support. Organizations operating in Singapore, Malaysia, Vietnam, Thailand, or the Philippines may face overlapping obligations. A clause saying the vendor complies with “applicable privacy law” is useful only when paired with a defined change process, because the customer’s business, data flows, and use case can change faster than the agreement is renegotiated.

## How Should Pricing, Service Levels, and Remedies Be Structured?

AI procurement often has a layered cost structure: subscription fees, per-seat or usage charges, model inference, embedding storage, retrieval, tool calls, fine-tuning, human review, implementation, and premium support may be billed separately. A low platform fee can therefore be followed by variable costs that rise rapidly as usage grows. The agreement should define billable units, included volumes, rate cards, minimum commitments, overage calculations, price-review dates, and the effect of model or hosting changes on those charges. A customer should compare proposals on total cost over at least 24 or 36 months, not only on the first-year license price.

Service levels should include more than availability. Depending on the product, useful measures may include monthly uptime, response latency, successful completion rate, queue time, retrieval performance, and time to restore service. A 99.9% monthly uptime target permits roughly 43 minutes of unavailability in an average 30-day month, while 99.99% permits roughly 4.3 minutes. Customers should verify whether planned maintenance, third-party model outages, and severe degradation count toward those calculations. AI quality metrics may be included as reported indicators, but a service credit should not be the sole remedy where an error creates regulatory, employment, credit, health, or safety exposure.

Remedies should be proportionate to the harm. Credits, fee refunds, suspension, termination, indemnity, and corrective action can address different failure modes. The agreement should state whether credits are exclusive, whether repeated service failures trigger termination without penalty, and whether a customer may claim direct losses or third-party claims caused by the vendor. Caps and exclusions should be reviewed carefully: a cap based on 12 months’ fees may be inadequate if the vendor’s service processes regulated decisions, handles large volumes of sensitive data, or creates substantial rework for the customer. The negotiation is not about maximizing every remedy; it is about making the financial consequence match the vendor’s control and the customer’s realistic exposure.

## What Practical Review Process Should a Company Use in 2026?

A company should begin before selecting a final vendor and classify the intended use by its data sensitivity, decision impact, number of affected people, and regulatory status. It should create a cross-functional team involving procurement, legal, privacy, cybersecurity, product owners, information security, finance, and the business unit that will own the incident process. High-impact applications such as hiring, credit, insurance, medical support, essential services, or autonomous actions deserve more independent testing and stronger approval controls than an internal drafting assistant. The team should also define what the system must never do, where humans retain final authority, and which conditions will cause the project to pause.

Before signature, the parties should complete a data-flow map, subprocessor review, security questionnaire, architecture explanation, model-card or system-documentation review, and a test plan using representative but protected examples. A pilot should measure false positives, false negatives, hallucination or citation error rates, latency, analyst review time, and variance across languages and demographic groups. For Indonesian and wider Southeast Asian deployments, the test set should include local languages, local names, local addresses, local regulatory vocabulary, and realistic operational scenarios rather than relying only on English benchmarks. Contract language should attach the agreed technical controls and service reports as appendices, making them reviewable instead of leaving the promises in a general security policy that may change without notice.

Contract owners should set a renewal gate at least 90 days before a notice deadline, with an earlier internal checkpoint if the vendor introduces a major model, new subprocessor, new region, or material price increase. A 60-day review can expose issues, but a 90-day lead time gives legal, security, procurement, and business teams room to negotiate or prepare an exit. The agreement should also require advance notice of material changes, not merely notice after an adverse event. The objective is not to renegotiate every detail annually; it is to establish a repeatable process for deciding whether the vendor remains suitable as the technology, regulation, and internal use case evolve.

## What Common Mistakes Cause AI Contract Failures?

The most common mistake is treating AI as ordinary software with an impressive demonstration attached. A persuasive prototype can conceal weak access controls, unclear data rights, poor performance on local cases, and no credible incident process. Another common mistake is accepting undefined phrases such as “commercially reasonable,” “industry standard,” or “as appropriate” without evidence or an accountable owner. These phrases are not automatically invalid, but they create uncertainty when the customer cannot connect them to a benchmark, control, report, or remedy.

A second mistake is allowing the vendor to reserve broad rights to improve its models while the customer assumes responsibility for the resulting output. A useful negotiation can offer a limited, documented improvement right tied to de-identified feedback or opt-in customer-specific tuning, while preserving a ban on training on sensitive customer data. A third mistake is assuming a general indemnity covers regulatory fines, notification costs, data-subject claims, or reputational harm. Indemnity language should identify covered claims, exclusions, defense control, settlement consent, and the interaction with caps. Organizations also err by failing to verify the vendor’s subcontractors, by accepting a deletion promise without an exit plan, and by allowing employees to paste regulated data into an unapproved service while procurement is still evaluating a contract.

The final mistake is failing to plan an exit. A termination clause that says the customer may recover its prompts and documents is less useful if the vendor cannot provide those prompts in usable form, if retrieval indexes and fine-tuned artifacts remain inaccessible, or if service continues while migration is attempted. A workable exit plan specifies export format, retrieval assistance, transition period, deletion verification, remaining fees, and continued security. It should be tested before the relationship is operationally critical, because a data export is not a substitute for knowing which reports, logs, evaluations, and model versions are needed to reproduce an important decision.

## When Is Legal Advice or an Independent Review Worth the Cost?

Independent legal and technical review is worth the cost when the vendor will handle personal data, confidential business information, regulated records, large populations, or decisions affecting access to employment, credit, health, insurance, education, or public services. The cost of a focused contract review may be modest compared with remediating a misrouted dataset, delaying a launch, or disputing responsibility for a harmful output. However, an expensive assessment is not automatically a better one. Buyers should require reviewers familiar with the intended use case and the jurisdictions where data is processed, not simply a long generic checklist.

Smaller companies can reduce expense by using a shorter approval path for low-risk tools that do not retain prompts, make consequential decisions, or connect to production systems. A trial with synthetic data, disabled training, limited accounts, and a short term can reveal basic vendor behavior without pretending it establishes enterprise readiness. Even then, the team should document the product owner, permitted data, user population, incident contact, and removal date. As the tool expands, the review should become more formal. The right escalation point is not a fixed company-size threshold; it is the point at which the system’s influence, data sensitivity, or operational dependence makes informal governance unreliable.

As of 2 October 2026, companies should treat AI vendor contracting as an ongoing control rather than a one-time legal event. The best contract is not the one with the most restrictive terms; it is the one that makes responsibilities observable, responsibilities proportionate, and decisions reversible. For Indonesian and Southeast Asian teams, a contract that aligns vendor promises with local deployment realities is more useful than a global template copied without checking data flows, language performance, sector duties, and exit costs. A mature buyer negotiates for evidence, tests, notification, and remedies, then maintains those protections through renewal and material product change.

## Quick answers

### Are AI vendor contracts legally required to contain specific clauses?

There is no single universal AI contract form. Requirements depend on the parties, use case, data, and jurisdictions, but laws addressing AI, privacy, cybersecurity, consumer protection, and sector regulation can create mandatory documentation, transparency, and safety duties. Contract drafting should translate those duties into clear roles, evidence, procedures, and remedies rather than relying on a generic SaaS template.

### Can a customer prohibit a vendor from training on company prompts?

Usually, yes, if the customer negotiates a clear contractual restriction. The clause should cover prompts, uploaded files, feedback, logs, embeddings, recordings, and fine-tuning materials, and should distinguish service delivery from product training. A vendor may offer a separate opt-in arrangement for a defined improvement use, but the default permission should be unambiguous.

### What is a reasonable uptime commitment for an AI service?

The appropriate target depends on the use case, and 99.9% is not automatically sufficient for every application. A 99.9% monthly target permits about 43 minutes of unavailability in a 30-day month, while 99.99% permits about 4.3 minutes. Contracts should also address latency, quality, third-party dependencies, planned maintenance, credits, and termination rights for repeated failures.

### How should customers handle a vendor changing its underlying AI model?

The agreement should require notice before a material model or infrastructure change and define what qualifies as material. For higher-risk use cases, the customer may need a test period, evaluation results, a right to reject a replacement, or a termination right without penalty. The customer should compare performance on its own approved test set, not only the vendor’s aggregate benchmark.

### What should happen if an AI vendor experiences a serious incident?

The contract should define the incident scope, notification deadline, information to be supplied, evidence preservation, containment cooperation, and responsibility for remediation. It should cover prompt leakage, unauthorized access, model extraction, harmful outputs, compromised subprocessors, and supply-chain failures as applicable. The customer should not assume that a general breach clause automatically captures every AI-specific event.

Canonical: https://infonesia.fyi/knowledge/how_should_companies_review_ai_vendor_contracts_in_2026.php
Markdown: https://infonesia.fyi/knowledge/how_should_companies_review_ai_vendor_contracts_in_2026.php/index.md