AI Contract Clauses That Reduce Vendor, Data, and Liability Risk

Thu, 12 Mar 2026 00:00:00 +0000

How to Buy AI Systems Without Buying Hidden Risk

Most AI procurement failures start with a simple mistake.

The buyer focuses on the demo. The vendor focuses on the pitch. Procurement focuses on commercials. Legal focuses on contract language. Security focuses on controls. Compliance focuses on obligations. Nobody pulls those pieces together into one disciplined buying process tied to the business problem the AI system is supposed to solve. That is how organizations end up with tools that look strong in workshops and weak in real operations.

A strong AI procurement process needs more than a vendor comparison sheet. It needs clear business goals, industry-fit assessment, security and compliance scrutiny, bias and explainability review, robust contract terms, and a practical operating model for updates, support, drift, and exit. This post shows you how to build that process using a structured AI procurement control checklist that lawyers, procurement teams, compliance staff, and business owners can actually use.

Understanding the Core Framework for AI Procurement

AI procurement is the process of selecting and contracting for an AI system in a way that protects business value, legal compliance, operational fit, and long-term control.

The framework I use has four layers. Business fit, supplier assurance, contractual protection, and post-award governance. If one of these is weak, the deal usually creates more friction than value.

1. Business fit

This layer asks whether the vendor actually understands the business problem and whether the AI system fits the use case the organization is trying to solve.

A vendor may have a capable product and still be a poor fit if they do not understand the industry, data constraints, workflow realities, or user needs. AI procurement should begin with the business goal, not the tool category.

Implementation tip: Ask vendors to restate your use case in their own words and explain how their product addresses it. This quickly reveals whether they understand the problem or are pitching a generic story.

2. Supplier assurance

This layer checks whether the supplier is capable, credible, secure, and compliant. It includes track record, certifications, model governance maturity, security controls, privacy handling, explainability support, and bias management.

This is where many AI procurement processes stay too shallow. A vendor may have references and still fail on transparency, security integration, or update discipline.

Implementation tip: Evaluate the supplier’s operating maturity, not just the product feature list. Products are easier to improve than weak vendor practices.

3. Contractual protection

This layer turns procurement promises into obligations. It covers model rights, support commitments, audit rights, performance reviews, non-compliance remedies, drift management, exit rights, and pricing terms.

Without strong contract structure, even a good vendor relationship becomes fragile when something changes or goes wrong.

Implementation tip: Translate each key procurement concern into a contract clause, a reporting obligation, or an operational review point. Otherwise the concern will fade after signature.

4. Post-award governance

This layer makes sure the procurement decision stays valid after implementation. It includes reviews, updates, concept drift handling, support quality, retraining behavior, and adjustment to changing business needs.

A lot of procurement teams stop once the contract is signed. For AI systems, that is too early.

Implementation tip: Treat supplier performance review as part of procurement, not a later operations issue. AI services evolve too quickly to separate them fully.

Why AI Procurement Often Breaks Down

The most common issue is buying capability without buying accountability.

The vendor explains impressive functionality, but the buyer does not secure enough detail on data use, decision transparency, support, performance drift, or contract exit. The product may work. The governance does not.

Another issue is weak problem framing. Organizations sometimes ask vendors for “an AI solution” without a clear business objective, success metric, workflow boundary, or deployment context. That makes vendor selection noisy and contract requirements vague.

There is also a third-party risk gap. Some vendors rely heavily on subcontractors, external models, or layered cloud services, but the customer only reviews the top-level brand. That creates hidden dependency and resilience risk.

Implementation tip: Build the procurement review around the real operating model of the service, including subcontractors, third-party models, and underlying infrastructure where material.

Stage 1: Define the Business Goals Before You Issue Requirements

A good AI procurement process starts with internal clarity.

The responsible parties are the business sponsor, product owner, procurement, legal, AI governance, and relevant operational leads. Security, privacy, and compliance should be consulted early where the use case is sensitive or regulated.

The critical artifacts are the business objective statement, use case summary, success metrics, scope statement, and evaluation criteria. These should be ready before vendor conversations get too far.

What to implement: Define your business goals clearly and align them with the AI capabilities you want to procure. Describe the problem to be solved, the users involved, the workflow context, the expected outcomes, and the constraints that matter most. This helps you compare vendors on relevance instead of presentation style.

This stage should also identify what kind of AI capability is actually needed. Classification, summarization, predictive analytics, retrieval, ranking, automation support, recommendation, or generative output all create different procurement questions.

Without this clarity, the buying process becomes vulnerable to feature overload. Vendors will naturally emphasize breadth. You need to know what depth matters.

Implementation tip: Separate mandatory requirements from desirable features before the vendor evaluation begins. This keeps flashy extras from distorting the decision.

Stage 2: Assess the Vendor’s Industry Fit and Delivery Credibility

Not all strong AI vendors are strong for your context.

The responsible parties are procurement, the business owner, product, vendor management, and AI governance. Domain experts should review the vendor’s understanding of the business problem and workflow.

The critical artifacts are the vendor questionnaire, references, case studies, solution fit assessment, and implementation track record review.

What to implement: Assess the provider’s understanding of your industry and ask how the AI solution addresses your specific needs. Verify the provider’s track record with similar implementations. Request case studies, references, and practical examples of deployment in environments like yours.

This is also the point to challenge vague claims. Ask what data conditions the solution assumes, what user behavior patterns it expects, what level of configuration is required, and what measurable outcomes the vendor has achieved elsewhere. Generic claims such as “improves efficiency” or “works across industries” should not carry much weight without evidence.

A provider with a good technical product can still be a poor partner if they do not understand the operational reality of your environment.

Implementation tip: Use scenario-based vendor questioning. Ask how their system would handle one or two realistic edge cases from your workflow. That reveals depth quickly.

Stage 3: Review Security, Privacy, and Regulatory Readiness in Detail

This is where many AI buying decisions become serious.

The responsible parties are security, privacy, compliance, legal, procurement, and vendor risk teams. The product owner and business sponsor should stay involved because these decisions affect usability and deployment scope.

The critical artifacts are the security questionnaire, privacy review, regulatory compliance assessment, data flow diagram, incident response summary, and certification evidence.

What to implement: Evaluate the provider’s ability to comply with relevant regulations, including data protection and privacy laws. Ensure the provider has robust security protocols such as encryption, access controls, environment segregation, logging, and incident response plans. Request evidence of these controls, not only policy statements.

Third-party certifications can help here. Require certifications such as ISO 27001 where relevant, but do not treat them as a substitute for review. Certifications are useful signals. They are not proof that the specific AI service fits your risk profile.

Also examine data location, retention, model training rights, logging practices, subprocessors, and customer separation controls. If the service involves sensitive, regulated, or proprietary data, these details matter a lot.

Implementation tip: Ask one simple question in the security review. “What customer data can the provider access, keep, reuse, or expose during normal operation, troubleshooting, and model improvement?” The answer usually reveals the real risk posture.

Stage 4: Test Explainability, Bias Handling, and Responsible AI Maturity

AI procurement needs to assess how the provider manages the parts of AI that are hardest to evaluate from a product sheet alone.

The responsible parties are AI governance, compliance, legal, business owners, domain experts, and technical reviewers. Procurement should coordinate but not own the substance of this review.

The critical artifacts are the explainability statement, fairness and bias testing summary, model documentation, validation reports, and responsible AI controls overview.

What to implement: Require the provider to explain the system’s decision-making process and the level of transparency available to users, operators, and reviewers. This does not always mean full model interpretability, but it does mean the supplier should explain what the system is doing, what its major limitations are, and how users are expected to understand and govern its outputs.

Also assess the provider’s approach to bias. Ask how bias is tested, how representative data issues are handled, what mitigation methods are used, and how fairness concerns are surfaced after deployment. If the vendor cannot answer clearly, that is a real warning sign.

Responsible AI maturity also includes documentation, governance ownership, issue handling, and update discipline. A vendor that has no structured approach here will be harder to manage later.

Implementation tip: Require examples of real documentation such as model cards, system cards, risk summaries, or governance notes. A verbal explanation alone is usually too polished and too thin.

Stage 5: Use Contract Terms to Protect the Organization Over Time

This is where procurement becomes durable.

The responsible parties are legal, procurement, vendor management, privacy, security, AI governance, and the business sponsor. Product and operations should review terms that affect support, updates, and operational flexibility.

The critical artifacts are the main agreement, AI-specific addendum, data processing terms, security schedule, SLA, audit clauses, exit terms, and pricing schedule.

What to implement: Include clauses that require the provider to comply with relevant laws and undergo regular compliance audits where appropriate. Specify support, training, and update obligations so the system remains effective as your business evolves. Establish clear ownership terms for data and AI models, especially for provider insolvency, contract termination, or material service failure.

Outcome-based pricing can be valuable where the use case supports it, because it aligns incentives with business success. Still, it should be used carefully. AI outcomes can depend on both supplier and customer behavior, so the pricing model needs realistic attribution rules.

The contract should also include provisions for regular performance reviews, the ability to adjust terms for changing business needs, and clear escalation and remediation procedures for performance issues or non-compliance. This includes concept drift and data drift management where the AI system depends on changing input conditions.

Implementation tip: Build a short AI contract rider that covers data rights, model rights, support, update notice, audit rights, drift management, exit assistance, and non-compliance escalation. Standard SaaS clauses are usually not enough on their own.

Stage 6: Plan for Drift, Support, and Post-Signature Performance Management

Signing the contract is not the end of AI procurement. It is the start of supplier governance.

The responsible parties are vendor management, product owners, business operations, procurement, AI governance, and support teams. Security and compliance should stay in the loop where incidents or control reviews are possible.

The critical artifacts are the performance review calendar, support governance plan, drift management process, issue log, and contract adjustment workflow.

What to implement: Require the provider to have a plan for managing concept drift and adapting the AI system to new data and changing conditions. Define how support works, what updates are included, how performance is reviewed, and how the contract can be adjusted when the business changes.

This is especially important for AI because service quality can shift gradually. A strong procurement process should make room for regular performance reviews, service tuning, retraining support where appropriate, and contract updates if the use case expands or the risk profile changes.

Also make sure escalation and remediation procedures are clear. If performance degrades, if explainability is weaker than expected, or if compliance concerns appear, everyone should know what happens next.

Implementation tip: Schedule the first formal vendor performance review before the system goes live. Early review habits shape later accountability.

Set of Recommended AI Procurement Clauses

Note for the readers: These clauses are intentionally buyer-favorable. They should be adapted to:

the role of the supplier under the EU AI Act (provider, deployer, importer, distributor, product manufacturer, authorised representative);
whether the AI is prohibited, high-risk, limited-risk/transparency, GPAI/foundation model, or not regulated as such;
whether personal data is processed and whether a DPA/data processing agreement is required;
sector-specific laws (financial services, health, employment, public sector, critical infrastructure, etc.);
local law on liability, indemnities, and enforceability.

1. Definitions and Interpretation

1.1 Definitions

Clause Title: Definitions

Sample wording:

“AI System” means any machine-based system, model, service, feature, component, or functionality that infers from inputs how to generate outputs such as predictions, content, recommendations, decisions, scores, classifications, or other outputs capable of influencing physical or virtual environments.

“AI Laws” means all applicable laws, regulations, codes, standards, and regulatory guidance relating to artificial intelligence, automated decision-making, data use, privacy, cybersecurity, discrimination, product safety, consumer protection, and sector-specific compliance, including, where applicable, the EU AI Act and all implementing, delegated, or related measures.

“High-Risk AI System” means any AI system classified as high-risk under applicable AI Laws.

“Customer Data” means all data, content, prompts, inputs, instructions, records, personal data, confidential information, and other materials provided, submitted, transmitted, generated, or made available by or on behalf of Customer in connection with the Services.

“Output” means all content, results, predictions, recommendations, scores, decisions, classifications, analytics, reports, embeddings, code, text, images, audio, video, or other materials generated or returned by the AI System in response to Customer Data or Customer’s use of the Services.

“Personal Data” has the meaning given in applicable data protection law.

“Services” means the AI systems, models, APIs, software, support, professional services, updates, and related deliverables supplied under the Agreement.

“Subprocessor” means any third party engaged by Supplier to process Customer Data or otherwise provide material components of the Services, including model providers, infrastructure providers, annotation providers, and safety evaluators.

“Security Incident” means any actual or reasonably suspected unauthorized access to, acquisition of, disclosure of, loss of, destruction of, alteration of, or inability to access Customer Data, or any material compromise of the security, confidentiality, integrity, or availability of the Services.”

2. Scope of Supply and Order of Precedence

2.1 Scope of Services

Clause Title: Scope of AI Services

Sample wording:

“Supplier shall provide the Services, including all AI and non-AI components, strictly in accordance with the Agreement, the Specifications, the Service Levels, the Documentation, applicable AI Laws, and Customer’s written instructions. Supplier shall not materially change the architecture, core functionality, model family, hosting location, security posture, or risk profile of the Services without Customer’s prior written consent.”

2.2 Order of Precedence

Clause Title: Order of Precedence

Sample wording:

“In the event of conflict, the following order of precedence shall apply: (a) signed Order Form or Commercial Terms; (b) these core terms; (c) the Data Processing Agreement; (d) Security Schedule; (e) Service Level Agreement; (f) Statement of Work; (g) Supplier policies and click-through terms. No click-wrap, browse-wrap, online terms, or unilateral policy shall reduce Supplier’s obligations or Customer’s rights unless expressly agreed in writing by Customer.”

3. Regulatory Status, AI Classification, and Compliance

3.1 AI Act Status and Role Allocation

Clause Title: AI Regulatory Status and Role Allocation

Sample wording:

“Supplier represents and warrants that it has correctly assessed and documented the regulatory status of the AI System and its own role and Customer’s role under applicable AI Laws, including whether the AI System constitutes a prohibited AI practice, a high-risk AI system, a limited-risk AI system subject to transparency obligations, or a general-purpose AI model or system. Supplier shall provide Customer, before contract signature and on an ongoing basis, with accurate written information sufficient for Customer to understand and discharge its compliance obligations as a deployer or other regulated actor.”

3.2 Compliance with AI Laws

Clause Title: Compliance with AI Laws

Sample wording:

“Supplier shall, at all times during the Term, design, develop, train, test, validate, deploy, maintain, support, and provide the Services in full compliance with all applicable AI Laws. Supplier shall promptly implement any changes required by changes in law, regulatory guidance, harmonized standards, common specifications, or competent authority requirements, at no additional cost to Customer unless such change is demonstrably and exclusively caused by a Customer-specific non-standard use case.”

3.3 Prohibited AI Practices

Clause Title: No Prohibited AI Practices

Sample wording:

“Supplier represents and warrants that the Services do not include, enable, or require any prohibited AI practice under applicable AI Laws. Supplier shall not cause or permit Customer to use the Services in a manner that would constitute a prohibited AI practice and shall implement technical and contractual controls reasonably necessary to prevent such use.”

4. Documentation, Transparency, and Information Rights

4.1 Pre-Contractual Disclosure

Clause Title: AI Transparency and Disclosure

Sample wording:

“Before the Effective Date, and thereafter upon request, Supplier shall provide complete, accurate, and up-to-date documentation describing: (a) the intended purpose, limitations, and foreseeable misuse of the AI System; (b) model type, version, release history, and material changes; (c) training, validation, and testing methodologies; (d) known performance characteristics, confidence limitations, and failure modes; (e) human oversight requirements; (f) data sources categories and data governance controls; (g) safety, security, robustness, and bias mitigation measures; (h) applicable use restrictions; and (i) all information reasonably required for Customer’s legal, technical, procurement, governance, and risk assessments.”

4.2 Ongoing Transparency

Clause Title: Ongoing Notification of AI Changes

Sample wording:

“Supplier shall give Customer at least

\[30\]

days’ prior written notice of any material change to the Services, including any change to model version, model provider, fine-tuning approach, retrieval architecture, safety filters, hosting location, subprocessors, performance characteristics, interfaces, or security controls that could affect compliance, accuracy, explainability, interoperability, risk, cost, or Customer’s intended use. Customer may reject any such change that materially increases risk or reduces functionality.”

5. Performance, Accuracy, and Fitness for Purpose

5.1 Conformity to Specifications

Clause Title: AI Performance and Conformity Warranty

Sample wording:

“Supplier warrants that the Services shall perform materially in accordance with the Specifications, Documentation, agreed evaluation criteria, and service descriptions, and shall be fit for the purposes expressly disclosed by Customer and accepted by Supplier. Supplier shall not market or describe the Services in a misleading manner, including as to autonomy, accuracy, explainability, safety, compliance, or suitability for regulated use cases.”

5.2 Accuracy, Reliability, and Hallucination Controls

Clause Title: Reliability and Output Quality Controls

Sample wording:

“Supplier shall implement and maintain appropriate measures to reduce inaccurate, fabricated, misleading, biased, unsafe, or non-compliant Outputs, including testing, monitoring, guardrails, confidence signalling where appropriate, grounding controls, abuse detection, and escalation procedures. Supplier acknowledges that Output quality is a material contractual requirement where the Services are used in business-critical, regulated, or customer-facing workflows.”

5.3 Benchmarking and Acceptance Testing

Clause Title: Acceptance Testing and Performance Validation

Sample wording:

“Customer may conduct acceptance testing, pilot evaluations, red-team exercises, bias assessments, and technical validation against agreed criteria before production use and following any material change. If the Services fail to meet agreed acceptance criteria, Customer may reject the affected Services, require remediation at Supplier’s cost, suspend deployment, or terminate the relevant Order without penalty.”

6. Human Oversight and Use Restrictions

6.1 Human Oversight

Clause Title: Human Oversight and Review

Sample wording:

“Supplier shall design the Services to enable effective human oversight appropriate to the intended use and risk level, including the ability for authorized personnel to review, challenge, override, reverse, or disregard Outputs before or after reliance where reasonably required. Supplier shall provide clear instructions regarding when human review is mandatory and when Outputs must not be used without additional verification.”

6.2 Use Restrictions and Safe Deployment Conditions

Clause Title: Permitted Use and Deployment Conditions

Sample wording:

“Supplier shall identify in writing all prohibited, restricted, and high-risk uses of the Services and all deployment conditions necessary for lawful and safe operation. Supplier shall not impose use restrictions that prevent Customer from carrying out legally required testing, monitoring, security review, audit, incident investigation, or compliance verification.”

7. Data Governance and Data Rights

7.1 Customer Ownership of Data and Outputs

Clause Title: Customer Ownership of Data and Outputs

Sample wording:

“As between the parties, Customer retains all right, title, and interest in and to Customer Data. To the maximum extent permitted by law, Customer shall own all Outputs generated specifically for Customer through Customer’s use of the Services. If any Output or related right does not vest automatically in Customer, Supplier hereby assigns, and shall procure the assignment of, all such right, title, and interest to Customer upon creation. Supplier retains ownership only in the pre-existing Supplier Materials and underlying models, excluding Customer Data and Customer-specific Outputs.”

7.2 Limited License to Process Customer Data

Clause Title: Limited License for Service Delivery Only

Sample wording:

“Customer grants Supplier a non-exclusive, non-transferable, revocable, limited license to process Customer Data solely to provide, support, secure, and maintain the Services for Customer in accordance with the Agreement. No other rights are granted by implication, estoppel, or otherwise.”

7.3 No Training on Customer Data

Clause Title: Prohibition on Training and Model Improvement Using Customer Data

Sample wording:

“Supplier shall not, and shall ensure that its affiliates, subprocessors, and underlying model providers do not, use Customer Data or Outputs to train, retrain, fine-tune, evaluate, validate, calibrate, augment, improve, or otherwise modify any general model, foundation model, or other AI system, nor for benchmarking, product development, or benefit of any third party, except where Customer has given specific prior written consent in a signed amendment expressly describing the permitted use, data scope, retention period, security controls, and opt-out rights.”

7.4 Data Segregation

Clause Title: Segregation and Tenant Isolation

Sample wording:

“Supplier shall logically and, where appropriate, physically segregate Customer Data from data of other customers and from Supplier’s own development, testing, and training environments. Supplier shall maintain effective tenant isolation and shall not commingle Customer Data in a manner that creates unauthorized access, leakage, memorization, or inference risk.”

7.5 Data Quality and Governance

Clause Title: Data Governance Controls

Sample wording:

“Supplier shall maintain appropriate data governance measures in relation to data used to develop, train, validate, test, and operate the AI components of the Services, including documented controls relating to data provenance, relevance, representativeness, error detection, labeling quality, bias identification and mitigation, lawful sourcing, minimization, and retention.”

8. Privacy and Data Protection

8.1 Data Protection Compliance

Clause Title: Privacy Compliance

Sample wording:

“Supplier shall comply with all applicable data protection laws in connection with the Services. To the extent Supplier processes Personal Data on behalf of Customer, the parties shall enter into a compliant Data Processing Agreement, and Supplier shall process Personal Data only on Customer’s documented instructions.”

8.2 International Transfers

Clause Title: Data Location and International Transfers

Sample wording:

“Supplier shall not transfer, access, host, or process Customer Data outside the approved jurisdictions specified by Customer without Customer’s prior written consent. Any international transfer of Personal Data shall be supported by a valid transfer mechanism and supplementary measures where required by law.”

8.3 Data Subject and Regulatory Assistance

Clause Title: Assistance with Privacy and AI Rights Requests

Sample wording:

“Supplier shall promptly provide reasonable assistance, at no additional charge for standard assistance, to enable Customer to respond to data subject requests, regulatory inquiries, audits, impact assessments, and legal obligations relating to automated decision-making, profiling, explainability, contestability, and human review.”

9. Security, Robustness, and Resilience

9.1 Security Measures

Clause Title: Information Security and AI Security Controls

Sample wording:

“Supplier shall implement and maintain appropriate technical and organizational measures to protect the Services and Customer Data against unauthorized access, disclosure, alteration, loss, destruction, poisoning, prompt injection, model extraction, data exfiltration, privilege abuse, adversarial manipulation, and other AI-specific and information security risks. Such measures shall include encryption, access controls, logging, patching, vulnerability management, environment segregation, secrets management, secure development practices, and incident response capabilities.”

9.2 Security Standards and Testing

Clause Title: Security Standards and Independent Assurance

Sample wording:

“Supplier shall maintain an information security program aligned with recognized industry standards and, upon request, provide current independent assurance reports, certifications, penetration test summaries, vulnerability remediation status, and AI security testing results reasonably sufficient to demonstrate compliance with the Agreement.”

9.3 Business Continuity and Resilience

Clause Title: Business Continuity and Operational Resilience

Sample wording:

“Supplier shall maintain and test business continuity, disaster recovery, backup, and service resilience plans appropriate to the criticality of the Services. Supplier shall ensure continuity arrangements for any critical third-party model, cloud, or infrastructure dependency and shall notify Customer without undue delay of any material risk to service continuity.”

10. Bias, Fairness, Explainability, and Risk Management

10.1 Bias and Discrimination Controls

Clause Title: Bias Monitoring and Non-Discrimination

Sample wording:

“Supplier shall implement reasonable and proportionate measures to identify, test for, monitor, prevent, and mitigate unlawful bias and discriminatory effects in the Services and Outputs, including periodic assessments appropriate to the intended use and affected populations. Supplier shall promptly notify Customer of any material bias, fairness, or discrimination issue and provide a remediation plan.”

10.2 Explainability and Traceability

Clause Title: Explainability, Traceability, and Audit Logs

Sample wording:

“Supplier shall provide functionality and documentation sufficient to enable Customer to understand the basis, limits, and context of Outputs to a degree appropriate for the intended use. Supplier shall maintain traceability records, model/version logs, decision logs where applicable, and event records sufficient to support auditability, incident investigation, legal defense, and regulatory compliance.”

10.3 Risk Management System

Clause Title: AI Risk Management System

Sample wording:

“Supplier shall establish, document, implement, maintain, and update a risk management system for the AI components of the Services, including procedures for identifying, analyzing, evaluating, mitigating, and monitoring reasonably foreseeable risks to health, safety, fundamental rights, non-discrimination, privacy, security, and business continuity throughout the lifecycle of the Services.”

11. High-Risk AI-Specific Obligations

11.1 High-Risk AI Compliance Support

Clause Title: High-Risk AI System Obligations

Sample wording:

“If any part of the Services is or becomes a High-Risk AI System, Supplier shall ensure full compliance with all applicable high-risk requirements and shall provide Customer with all documentation, instructions for use, technical information, logs, conformity materials, post-market monitoring information, and assistance reasonably necessary for Customer to lawfully deploy and use the High-Risk AI System.”

11.2 Conformity Assessment and CE/Registration Support

Clause Title: Conformity and Registration

Sample wording:

“Where required by applicable AI Laws, Supplier shall complete and maintain any required conformity assessment, technical documentation, declarations of conformity, CE marking, registration, and related obligations before making the relevant AI System available to Customer. Supplier shall provide evidence of the same upon request.”

11.3 Post-Market Monitoring

Clause Title: Post-Market Monitoring and Corrective Action

Sample wording:

“Supplier shall maintain a post-market monitoring process proportionate to the nature of the AI System and shall promptly investigate, document, and remediate any serious incident, malfunction, degradation, non-conformity, or reasonably foreseeable misuse. Supplier shall notify Customer without undue delay and provide all information necessary for Customer’s own reporting and mitigation obligations.”

12. Third-Party Components, Open Source, and Supply Chain

12.1 Third-Party and Subprocessor Controls

Clause Title: Supplier Responsibility for Third Parties

Sample wording:

“Supplier remains fully responsible for all acts and omissions of its affiliates, subprocessors, subcontractors, underlying model providers, data providers, and infrastructure providers as if they were Supplier’s own. Supplier shall not engage or replace any material subprocessor or underlying model provider without prior written notice to Customer and, where the change is material, Customer’s prior written consent.”

12.2 Open Source and Third-Party Licensing

Clause Title: Third-Party Materials and Open Source Compliance

Sample wording:

“Supplier warrants that all third-party software, models, data, and other materials incorporated into or used to provide the Services are properly licensed and that Customer’s authorized use of the Services will not require Customer to disclose source code, license proprietary materials on unfavorable terms, or accept additional restrictions not expressly set out in the Agreement.”

13. Intellectual Property and Infringement Protection

13.1 Supplier IP Ownership

Clause Title: Supplier Retained IP

Sample wording:

“Supplier retains ownership of its pre-existing technology, models, software, methods, and Documentation, excluding Customer Data, Customer-specific configurations paid for by Customer where agreed, and Customer-owned Outputs.”

13.2 IP Infringement Indemnity

Clause Title: Intellectual Property Indemnity

Sample wording:

“Supplier shall defend, indemnify, and hold harmless Customer, its affiliates, and their respective personnel from and against any claim, action, damage, loss, liability, settlement, cost, or expense, including reasonable legal fees, arising from any allegation that the Services, Outputs as supplied by the Services, or Customer’s authorized use thereof infringe, misappropriate, or otherwise violate any intellectual property or proprietary right of any third party.”

13.3 Infringement Remedies

Clause Title: IP Claim Remedies

Sample wording:

“If the Services or any Output are, or are likely to be, subject to an infringement claim, Supplier shall, at its own expense and without limiting Customer’s rights: (a) procure for Customer the right to continue using the affected item; or (b) replace or modify it so that it becomes non-infringing while maintaining materially equivalent functionality, compliance, and performance. If neither option is commercially reasonable in Customer’s judgment, Customer may terminate the affected Services immediately and receive a pro rata refund of prepaid fees and reimbursement of reasonable replacement costs.”

14. Confidentiality

14.1 Confidentiality

Clause Title: Confidentiality of Customer Information

Sample wording:

“Supplier shall keep Customer Data, Outputs, Customer business information, security information, evaluation results, and all non-public information relating to Customer strictly confidential and shall not use or disclose such information except as necessary to perform the Agreement. Supplier shall apply at least the same degree of care it uses to protect its own most sensitive information, and in no event less than reasonable care.”

14.2 Confidentiality of Prompts and Outputs

Clause Title: Prompts and Outputs as Confidential Information

Sample wording:

“For the avoidance of doubt, all prompts, system instructions, retrieval context, Customer workflows, model settings selected by Customer, and all Outputs generated for Customer shall be deemed Customer Confidential Information.”

15. Audit, Inspection, and Assessment Rights

15.1 Audit Rights

Clause Title: Audit and Compliance Verification

Sample wording:

“Customer, its internal or external auditors, regulators, and professional advisers may, on reasonable notice, audit Supplier’s compliance with the Agreement, including AI governance, security, privacy, subprocessors, service levels, and regulatory obligations. Supplier shall provide access to relevant records, personnel, systems information, policies, logs, test results, and facilities, subject to reasonable security controls.”

15.2 Assessments and Questionnaires

Clause Title: Ongoing Risk and Compliance Assessments

Sample wording:

“Supplier shall complete Customer’s reasonable due diligence questionnaires and periodic reassessments relating to AI compliance, privacy, security, resilience, ethics, and procurement risk management, and shall promptly notify Customer of any material change affecting prior responses.”

16. Service Levels, Support, Maintenance, and Change Control

16.1 Service Levels

Clause Title: Service Levels and Availability

Sample wording:

“Supplier shall meet the service levels set out in the SLA, including uptime, latency, response time, support response, incident resolution, model availability, throughput, and recovery targets. Chronic failure to meet service levels shall constitute material breach.”

16.2 Support and Expertise

Clause Title: Support and AI Competence

Sample wording:

“Supplier shall provide adequately trained support personnel with appropriate technical, legal, and compliance knowledge relating to the Services and applicable AI Laws. Supplier shall provide timely assistance for incidents involving inaccurate, unsafe, biased, or non-compliant Outputs.”

16.3 Change Control

Clause Title: Change Management

Sample wording:

“No material change to the Services, including retraining, fine-tuning, tuning of thresholds, safety systems, prompt templates, retrieval sources, or model replacement, shall be implemented without documented change control, impact assessment, rollback capability, and prior notice to Customer. Customer may require re-testing or re-approval following material changes.”

17. Warranties and Representations

17.1 Core Warranties

Clause Title: Supplier Warranties

Sample wording:

“Supplier represents, warrants, and undertakes that throughout the Term:
(a) it has full right, power, and authority to enter into and perform the Agreement;
(b) the Services will comply with the Agreement, Documentation, Specifications, and applicable laws;
(c) the Services will be provided using personnel with appropriate skill, care, diligence, and expertise;
(d) the Services will not contain malicious code, hidden functionality, unlawful surveillance capability, or unauthorized access mechanisms;
(e) Supplier will not knowingly provide false, incomplete, or misleading compliance, performance, or risk information; and
(f) Supplier will maintain the policies, procedures, and records reasonably required to demonstrate compliance with this Agreement and applicable AI Laws.”

17.2 No Degradation of Protection

Clause Title: No Reduction in Safeguards

Sample wording:

“Supplier shall not materially reduce the security, privacy, compliance, auditability, explainability, interoperability, or data protection features of the Services during the Term without Customer’s prior written consent.”

18. Incident Management and Regulatory Cooperation

18.1 Incident Notification

Clause Title: Security, Safety, and AI Incident Notification

Sample wording:

“Supplier shall notify Customer without undue delay, and in any event within

\[24\]

hours, after becoming aware of any Security Incident or any material AI incident, including serious malfunction, material degradation, unauthorized model behavior, unsafe Output pattern, bias event, legal non-compliance, or suspected breach of applicable AI Laws affecting the Services or Customer’s use thereof.”

18.2 Cooperation and Remediation

Clause Title: Incident Cooperation and Corrective Action

Sample wording:

“Supplier shall immediately take all necessary containment, correction, and mitigation measures, keep Customer regularly informed, preserve relevant evidence and logs, perform root cause analysis, and implement corrective actions at Supplier’s expense. Supplier shall not notify regulators, affected individuals, or third parties regarding Customer-specific incidents without Customer’s prior written approval unless prohibited by law.”

18.3 Regulatory Cooperation

Clause Title: Cooperation with Regulators and Authorities

Sample wording:

“Supplier shall provide all reasonable assistance, records, and technical information necessary for Customer to respond to requests, inspections, investigations, audits, or enforcement actions by competent authorities relating to the Services.”

19. Indemnities

19.1 Compliance Indemnity

Clause Title: AI and Regulatory Compliance Indemnity

Sample wording:

“Supplier shall defend, indemnify, and hold harmless Customer and its affiliates from and against all losses, liabilities, fines, penalties, costs, and expenses arising out of or in connection with Supplier’s breach of applicable AI Laws, data protection laws, cybersecurity obligations, or sector-specific legal requirements, except to the extent directly caused by Customer’s use of the Services in material breach of Supplier’s written instructions.”

19.2 Data and Security Indemnity

Clause Title: Data Breach and Security Indemnity

Sample wording:

“Supplier shall defend, indemnify, and hold harmless Customer from and against all losses, damages, claims, costs, and expenses arising from any Security Incident or confidentiality breach caused by Supplier or its subprocessors.”

19.3 Output Harm Indemnity

Clause Title: Indemnity for Harm Caused by Defective or Non-Compliant AI Outputs

Sample wording:

“Supplier shall indemnify Customer against third-party claims and direct losses arising from materially defective, unlawful, infringing, biased, misleading, or unsafe Outputs to the extent caused by Supplier’s breach of the Agreement, negligence, failure to implement agreed safeguards, or non-compliance with applicable law.”

20. Limitation of Liability

20.1 Buyer-Protective Liability Structure

Clause Title: Liability Cap and Exclusions

Sample wording:

“Supplier’s total liability under or in connection with the Agreement shall be no less than

\[three to five times\]

the total fees paid or payable under the Agreement in the preceding

\[12\]

months, provided that the foregoing cap shall not apply, or shall apply to a separate higher cap, to liability arising from: (a) breach of confidentiality; (b) infringement or misappropriation of intellectual property rights; (c) breach of data protection obligations; (d) Security Incidents; (e) fraud, fraudulent misrepresentation, wilful misconduct, or gross negligence; (f) death or personal injury; (g) breach of AI Laws; or (h) indemnification obligations.”

Buyer note: For critical AI procurement, buyers often seek uncapped or super-capped liability for privacy, security, IP, and regulatory breaches.

21. Fees, Payment Protections, and Audit of Charges

21.1 Fee Transparency

Clause Title: Pricing Transparency and Consumption Controls

Sample wording:

“Supplier shall provide transparent pricing for licenses, usage, tokens, compute, storage, support, overages, professional services, model tiers, and third-party pass-through charges. Supplier shall implement usage controls, budget alerts, and hard caps at Customer’s request. Customer shall not be liable for charges caused by Supplier error, unauthorized access, defective metering, or unapproved usage.”

21.2 Audit of Charges

Clause Title: Billing Audit Rights

Sample wording:

“Customer may audit Supplier’s invoices, usage calculations, token counts, and other charges relevant to the Services. Supplier shall retain supporting records for at least

\[7\]

years and promptly refund any overcharges.”

22. Term, Suspension, and Termination

22.1 Suspension Rights

Clause Title: Customer Suspension Rights

Sample wording:

“Customer may immediately suspend use of any affected Services, without liability, where Customer reasonably believes that continued use may create legal, regulatory, security, safety, discrimination, confidentiality, or operational risk. During suspension, Supplier shall cooperate fully in investigation and remediation.”

22.2 Termination for Cause

Clause Title: Termination for Cause

Sample wording:

“Customer may terminate the Agreement or any affected Order immediately upon written notice if Supplier: (a) materially breaches the Agreement and fails to cure within

\[10/15/30\]

days; (b) suffers a repeated service level failure; (c) breaches confidentiality, data protection, security, or AI Laws; (d) makes a material adverse change to the Services without consent; or (e) exposes Customer to unacceptable legal, operational, or reputational risk.”

22.3 Termination for Convenience

Clause Title: Termination for Convenience by Customer

Sample wording:

“Customer may terminate the Agreement or any Order for convenience on

\[30/60/90\]

days’ written notice. Upon such termination, Customer shall pay only undisputed fees for Services properly provided up to the effective date of termination, and Supplier shall refund any prepaid unused fees.”

23. Exit, Transition, and Data Return

23.1 Exit Assistance

Clause Title: Exit Assistance and Transition Support

Sample wording:

“Upon expiration or termination, Supplier shall provide all reasonable transition assistance necessary to migrate Customer to Customer’s replacement supplier or internal solution, including continued access for a transitional period, data export, technical cooperation, documentation, knowledge transfer, and assistance with reconfiguration or migration, at rates no higher than those stated in the Agreement or, if termination is caused by Supplier breach, at no additional charge.”

23.2 Data Return and Deletion

Clause Title: Return, Portability, and Deletion of Data

Sample wording:

“Promptly upon termination or upon Customer’s request, Supplier shall return Customer Data and Outputs in a structured, commonly used, machine-readable format, together with relevant metadata, logs, and configuration information reasonably necessary for continuity. Supplier shall thereafter securely delete all Customer Data and certify deletion in writing, except to the extent retention is required by law.”

23.3 Model/Configuration Portability

Clause Title: Portability of Customer-Specific Configurations

Sample wording:

“Supplier shall provide Customer with a copy of Customer-specific prompts, workflows, retrieval configurations, policies, templates, model parameters to the extent customer-specific and exportable, evaluation datasets provided by Customer, and other artifacts reasonably necessary to reduce vendor lock-in.”

24. Publicity, Reference Use, and Disclosure

Clause Title: Publicity Restrictions

Sample wording:

“Supplier shall not name Customer, use Customer’s trademarks, or describe Customer’s use of the Services in any marketing, case study, benchmark publication, or public statement without Customer’s prior written consent.”

24.2 No Use of Customer for Benchmarking

Clause Title: Restriction on Benchmarking Using Customer Data

Sample wording:

“Supplier shall not use Customer Data, Customer use patterns, or Customer-specific results for public or private benchmarking, leaderboards, comparative marketing, or product claims without Customer’s explicit prior written consent.”

25. Governing Law, Dispute Resolution, and Interim Relief

25.1 Governing Law

Clause Title: Governing Law

Sample wording:

“This Agreement shall be governed by the laws of

\[Jurisdiction\]

, excluding conflict of laws principles.”

25.2 Dispute Resolution

Clause Title: Dispute Resolution

Sample wording:

“The parties shall first seek to resolve disputes through good faith escalation between senior representatives. If unresolved, either party may pursue litigation in the courts of

\[Jurisdiction\]

/ arbitration under the rules of

\[institution\]

. Nothing in this Agreement shall prevent Customer from seeking injunctive or other urgent relief in any court of competent jurisdiction.”

26. General Provisions Especially Important in AI Deals

26.1 Assignment

Clause Title: Assignment

Sample wording:

“Supplier may not assign, subcontract, transfer, novate, or otherwise dispose of the Agreement, in whole or in part, without Customer’s prior written consent, except to an affiliate that is demonstrably capable of performing the obligations and assumes them in writing. Any permitted assignment shall not relieve Supplier of liability.”

26.2 Subcontracting

Clause Title: Subcontracting Controls

Sample wording:

“Supplier shall remain fully liable for all subcontracted performance and shall ensure that all subcontractors are bound by obligations no less protective than those in this Agreement.”

26.3 Amendment

Clause Title: Amendments and No Unilateral Changes

Sample wording:

“No amendment, policy update, online term, or product notice shall modify the Agreement unless expressly agreed in writing by Customer. Continued use of the Services shall not constitute acceptance of any unilateral change.”

26.4 Survival

Clause Title: Survival

Sample wording:

“Provisions relating to confidentiality, data protection, security, audit, intellectual property, indemnities, liability, payment, dispute resolution, and exit assistance shall survive termination to the extent necessary to give them effect.”

Optional AI-Specific Clauses Often Added in Practice

These are not always in every contract, but are often highly valuable.

A. AI Governance Committee

Clause Title: Governance and Review Meetings

Sample wording:

“The parties shall establish a governance process, including periodic review meetings, to address performance, incidents, regulatory changes, model changes, fairness metrics, security risks, and roadmap impacts.”

B. Red Teaming and Adversarial Testing

Clause Title: Adversarial Testing Rights

Sample wording:

“Customer may perform, or appoint a third party to perform, reasonable adversarial testing, prompt injection testing, abuse case testing, and validation of safety controls in a non-production or approved environment.”

C. Kill Switch / Feature Disablement

Clause Title: Emergency Disablement

Sample wording:

“Supplier shall provide Customer with the ability, where technically feasible, to disable specified AI features, model endpoints, automated actions, or integrations immediately if Customer reasonably determines they create unacceptable risk.”

D. Recordkeeping

Clause Title: Recordkeeping and Retention

Sample wording:

“Supplier shall maintain complete and accurate records relating to model versions, training provenance categories, evaluations, incidents, changes, approvals, and compliance activities for at least

\[6–10\]

years or such longer period as required by law.”

Practical buyer comments on a few points from your reference text

Some of the wording in the reference you provided is not buyer-optimal and should usually be reversed or tightened:

Ownership of AI outputs
Your reference says the provider retains all rights in outputs.
Buyer-protective position: Customer should own, or at minimum have a broad perpetual right to use, modify, commercialize, and sublicense outputs generated from its use.
User input data license
Your reference grants the provider an irrevocable, perpetual, sublicensable right over user inputs.
Buyer-protective position: This is usually unacceptable. The supplier should get only a limited license strictly necessary to deliver the service.
Liability for AI outputs
Your reference largely disclaims provider liability.
Buyer-protective position: For enterprise procurement, especially under regulated or sensitive use cases, supplier should bear responsibility for non-compliant, infringing, unsafe, or defective outputs to the extent caused by its system or breach.
Prior consent for AI features
This is a very strong clause and often useful where AI is embedded in broader software.
Buyers should require no AI features without prior written consent, especially where the original procurement was for non-AI software.

A Practical AI Procurement Control Checklist

A useful AI procurement control checklist should help lawyers, procurement staff, compliance officers, and business owners assess vendors in a structured way.

At minimum, it should ask these questions.

Does the vendor understand the business problem and the industry context?

Can the vendor show relevant implementation experience and references?

Can the vendor demonstrate security, privacy, and regulatory readiness?

Can the vendor explain the system’s outputs, limitations, and bias controls?

Are support, update, audit, drift, and exit terms contractually defined?

Is there a clear process for performance review, escalation, and remediation?

This checklist should be used early and updated as the deal progresses. It should also be shared across procurement, legal, security, and business teams so the review stays integrated.

Implementation tip: Keep the checklist short enough to use in real vendor reviews and deep enough to expose meaningful risk. Long questionnaires that nobody reads carefully are false comfort.

PracticalTips in AI Procurement and Due Diligence

These tips apply across the full buying process.

Tip 1: Buy against the operating reality, not the demo

Demos are controlled. Operations are not.

Implementation tip: Evaluate the AI system using your workflow conditions, your user expectations, your governance rules, and your data sensitivity profile. That is the real buying environment.

Tip 2: Treat explainability and support as procurement issues

These are often pushed to later project stages. They belong in vendor selection and contracting.

Implementation tip: Ask vendors how operators, reviewers, and support staff are supposed to understand and troubleshoot the system in practice.

Tip 3: Plan for exit before the relationship gets comfortable

AI vendor dependence becomes harder to manage over time.

Implementation tip: Define data return, deletion, transition support, and model or configuration portability early. Exit planning is much easier before problems arise.

Tip 4: Keep procurement, legal, and technical reviews connected

AI risk often sits between functions.

Implementation tip: Hold at least one joint review session with procurement, legal, security, privacy, product, and the business owner before final vendor selection. That one meeting often surfaces the real blockers.

References for AI Procurement

If you want a stronger AI procurement process, anchor it in recognized governance, security, and contract frameworks.

Here are the references I would use.

ISO/IEC 42001, AI management systems
ISO/IEC 42005, information to include in an AI impact assessment
ISO/IEC 23894, AI risk management
NIST AI Risk Management Framework 1.0
ISO/IEC 27001 and 27002 for supplier security controls and information security management
Vendor risk management and procurement standards
Data protection, confidentiality, and sector-specific legal requirements relevant to the use case
Internal contract review, architecture review, and third-party risk workflows
AI-specific SLA and model documentation expectations for transparency and performance governance

If your organization already has strong procurement and vendor risk functions, adapt them for AI instead of creating a separate process from scratch. The key is adding the AI-specific controls that standard technology procurement often misses.

Why AI Procurement Fails When Treated as a Vendor Selection Exercise

When teams treat AI procurement as a vendor selection exercise, they compare features, pricing, and references, then move quickly to signature. The harder questions stay underexplored. How does the vendor handle drift. What rights do they have over customer data. How transparent is the system. Who supports the tool when outputs degrade quietly. What happens if the provider changes direction, gets acquired, or fails to meet compliance expectations.

When teams treat AI procurement as a control process, the purchase becomes stronger. The chosen vendor fits the business goal, the contract reflects the real risks, the support model is clearer, and the organization keeps more control over future performance and change.

A strong AI procurement process works because it buys operational fit and accountability, not just software access.

If you reviewed your current AI vendor pipeline today, which gap would worry you most first: weak business-fit evaluation, weak security and privacy review, thin explainability checks, weak contract protections, or poor post-signature performance governance?

About the Author

The frameworks, tools, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution. If you like the content, please like the article and share it.

Prof. Huwyler serves as AI GRC Consultancy Director, AI Risk Manager, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe and globally.

Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance landscapes.

His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at . His ongoing writing on Governance, Risk Management and Compliance appears on his blogger website at (more than 500k views).

Connect with Prof. Huwyler on LinkedIn at to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.

If you’re building an AI governance program, standing up an AI risk function, preparing for EU AI Act compliance, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.

Third-Party-Controls |

AI Contract Clauses That Reduce Vendor, Data, and Liability Risk

How to Buy AI Systems Without Buying Hidden Risk

Understanding the Core Framework for AI Procurement

1. Business fit

2. Supplier assurance

3. Contractual protection

4. Post-award governance

Why AI Procurement Often Breaks Down

Stage 1: Define the Business Goals Before You Issue Requirements

Stage 2: Assess the Vendor’s Industry Fit and Delivery Credibility

Stage 3: Review Security, Privacy, and Regulatory Readiness in Detail

Stage 4: Test Explainability, Bias Handling, and Responsible AI Maturity

Stage 5: Use Contract Terms to Protect the Organization Over Time

Stage 6: Plan for Drift, Support, and Post-Signature Performance Management

Set of Recommended AI Procurement Clauses

1. Definitions and Interpretation

1.1 Definitions

2. Scope of Supply and Order of Precedence

2.1 Scope of Services

2.2 Order of Precedence

3. Regulatory Status, AI Classification, and Compliance

3.1 AI Act Status and Role Allocation

3.2 Compliance with AI Laws

3.3 Prohibited AI Practices

4. Documentation, Transparency, and Information Rights

4.1 Pre-Contractual Disclosure

4.2 Ongoing Transparency

5. Performance, Accuracy, and Fitness for Purpose

5.1 Conformity to Specifications

5.2 Accuracy, Reliability, and Hallucination Controls

5.3 Benchmarking and Acceptance Testing

6. Human Oversight and Use Restrictions

6.1 Human Oversight

6.2 Use Restrictions and Safe Deployment Conditions

7. Data Governance and Data Rights

7.1 Customer Ownership of Data and Outputs

7.2 Limited License to Process Customer Data

7.3 No Training on Customer Data

7.4 Data Segregation

7.5 Data Quality and Governance

8. Privacy and Data Protection

8.1 Data Protection Compliance

8.2 International Transfers

8.3 Data Subject and Regulatory Assistance

9. Security, Robustness, and Resilience

9.1 Security Measures

9.2 Security Standards and Testing

9.3 Business Continuity and Resilience

10. Bias, Fairness, Explainability, and Risk Management

10.1 Bias and Discrimination Controls

10.2 Explainability and Traceability

10.3 Risk Management System

11. High-Risk AI-Specific Obligations

11.1 High-Risk AI Compliance Support

11.2 Conformity Assessment and CE/Registration Support

11.3 Post-Market Monitoring

12. Third-Party Components, Open Source, and Supply Chain

12.1 Third-Party and Subprocessor Controls

12.2 Open Source and Third-Party Licensing

13. Intellectual Property and Infringement Protection

13.1 Supplier IP Ownership

13.2 IP Infringement Indemnity

13.3 Infringement Remedies

14. Confidentiality

14.1 Confidentiality

14.2 Confidentiality of Prompts and Outputs

15. Audit, Inspection, and Assessment Rights

15.1 Audit Rights

15.2 Assessments and Questionnaires

16. Service Levels, Support, Maintenance, and Change Control

16.1 Service Levels

16.2 Support and Expertise

16.3 Change Control

17. Warranties and Representations

17.1 Core Warranties

17.2 No Degradation of Protection

18. Incident Management and Regulatory Cooperation

18.1 Incident Notification

18.2 Cooperation and Remediation