AI MSA Addendum: Turn Vendor Promises Into Testable Duties

An AI vendor can promise enterprise security in a sales response while the master services agreement stays silent about model substitution, prompt retention, customer-accessible logs and evidence after termination. The addendum has to carry those claims into enforceable duties. I treat it as an operating schedule: every material promise gets a named service, delivery channel, deadline, owner and test.

TL;DR

• Define the exact AI service, approved uses, data classes, model providers, hosting regions and subprocessors covered by the addendum.
• Convert claims about training, retention, deletion, security, incidents and model changes into dated duties with acceptance evidence.
• Require request-level event fields and export access for customer-routed LLM traffic, then test delivery before signature.
• Keep legal interpretation with counsel. The runtime control record proves observed traffic, while the contract governs supplier duties and remedies.

Scope the purchased AI service by name

Start with the order form, service name, plan and deployment mode. Record every AI feature in scope and every approved use case. Add the customer data classes the service may process, the users allowed to invoke it, model providers, hosting regions and material subprocessors. A broad reference to "AI functionality" leaves too much room when a vendor adds a summarizer, an agent or a new upstream model six months later.

The NIST AI Risk Management Framework treats third-party software, hardware and data as a distinct risk-management problem. GOVERN 6 calls for policies and procedures covering third-party AI risk and contingency processes for failures or incidents in high-risk third-party data or AI systems. MAP 4.2 calls for internal controls over third-party AI components to be identified and documented.

The addendum should attach a service schedule with stable identifiers. One line might identify svc-support-summary-prod, the approved customer-support summarization use, EU hosting, one named model family and the permitted ticket fields. Those identifiers should also appear in the risk register and route configuration. The procurement governance guide owns the wider supplier process. This article focuses on the signed schedule and its acceptance evidence.

Counsel should adapt the terms to the governing law and transaction and provide the legal advice. This guide supplies the engineering and evidence pattern.

Data terms need measurable states

The addendum should state which customer inputs and outputs the supplier may use to provide the service. Address training, fine-tuning, evaluation, human review and service improvement separately. Define retention for prompts, responses, attachments, embeddings, logs and backups. Specify deletion triggers and evidence, along with legal-hold handling and any survival period.

Subprocessor language needs the same precision. Require a current list, the data and function assigned to each subprocessor, processing location and notice period for material changes. Give the customer a defined review and objection process where counsel determines it is appropriate. A generic right to update a web page offers little control if the customer learns about a new model provider after production traffic has moved.

Turn each term into a testable state:

• Training restriction: supplier representation tied to the named service and plan, plus configuration evidence where a customer control exists.
• Retention: stated duration for each data class, backed by configuration or service documentation and a timed retrieval test.
• Deletion: request channel, completion deadline, scope of deletion and certificate or job result.
• Residency: approved regions and a notice rule for movement.
• Subprocessors: versioned list, change notice and customer disposition record.

I dislike contract language that says data is deleted "promptly." Put a number beside the duty. A reviewer should be able to open the addendum on a conference-room screen, read the deadline and compare it with the supplier's completion timestamp.

Model and service changes need a review trigger

A customer-facing feature name can stay fixed while the model, retrieval source, safety layer or hosting region changes. Define material change by its effect on the approved service rather than by the vendor's release label. Covered changes can include foundation model substitution, a new model provider, expanded data use, a new processing location, a material subprocessor, reduced log fields, altered retention and a change to an agreed security control.

The supplier should provide notice through a named channel with enough detail for review. The notice should identify the current and proposed state, effective date, affected services, security or privacy impact, available test evidence and customer action required. Set a response path for acceptance, restricted deployment, postponement, compensating control or termination where negotiated.

The AI RFP template moves accepted claims into contract language. The MSA addendum should preserve the same requirement IDs so the evaluation record, negotiated clause and production test are connected. If requirement LOG-04 won full credit because the vendor exported caller identity and model destination, the signed schedule should name those fields and the post-signature acceptance test should request them again.

A change register is beside the contract. Record notice date, requirement IDs affected, reviewer, risk decision, conditions and production effective date. Procurement can track the supplier commitment, while engineering and security assess the technical effect.

Security and incident duties should name evidence

Security clauses should identify the controls that matter to the approved service. Cover identity and administrative access, tenant separation, encryption, secrets, vulnerability handling, availability and business continuity according to the use case. For customer-routed LLM calls, define route authorization and data handling. Avoid claiming that one supplier control covers model development, endpoint activity and every downstream business action.

The NIST Generative AI Profile gives procurement teams unusually direct contract guidance. Action GV-6.1-004 calls for contracts and service-level agreements covering content ownership, usage rights, quality standards, security requirements and content provenance expectations. GV-6.1-006 calls for clauses that allow the organization to evaluate third-party generative AI processes and standards. The profile also recommends vendor-contract terms for incident response, response times and critical support.

Define a security incident for the service and state the notification clock. Specify the notice recipient and required initial facts, update cadence, preservation duties, cooperation, root-cause report and corrective-action evidence. The contract should distinguish a preliminary notice from the completed investigation so the supplier can notify quickly without pretending to know the final cause.

Ask for one synthetic incident packet before signature. Put a red sticker on the first page if that helps the meeting. The packet should show the event ID, affected service and model, time window, data scope, containment state, customer action and next update time. A clause that promises incident cooperation is much more useful after the parties agree on the artifact.

Audit events need a defined schema and delivery path

"Audit logging available" is too vague for an addendum. Name the events and required fields. For LLM requests under the customer's control, useful fields include authenticated caller or agent, application and use-case ID, model destination, request and response classification, active policy version, decision, reason code, timestamp and correlation ID. Record administrative changes and evidence-export access separately.

State the export format, API or portal, retention period, delivery frequency and availability target. Address integrity protection and access to records during an incident. Define which events the customer receives directly and which are supplier-internal. If a field is unavailable, the risk owner should see that limitation before signature.

Acceptance should include at least one allowed route and one denied route, followed by a timed export. Revoke an identity and confirm the next request is denied. Submit a synthetic restricted-data marker and confirm the agreed policy result. Break a policy dependency in a controlled environment and test the failure mode. Preserve the event IDs and exported records with the contract file.

The procurement lead AI risk checklist covers the handoff after award. The addendum should assign the first evidence due date and the person who follows up when delivery fails.

Remedies, continuity and exit belong in the same schedule

Each material duty needs a consequence determined by counsel and the commercial team. Options can include remediation, service credit, restricted processing, suspension, termination, reimbursement or another negotiated remedy. Counsel chooses the legal language for the transaction. Every mandatory requirement still needs an explicit disposition when the supplier misses it.

Continuity terms should identify recovery objectives and customer communication for the purchased service. Address access to configuration and logs during disruption. If the AI service supports a regulated process, document the customer's manual or alternate route and the supplier evidence needed to activate it.

Exit requires more than deleting customer content. The customer may need historical request logs, incident records, model and subprocessor history, configuration exports, policy identifiers and deletion evidence. Define format, delivery window, access period and assistance. State which retention and investigation duties survive termination. Run an export rehearsal during the contract term rather than discovering a proprietary format on the final Friday.

Keep the signed addendum, service schedules, approved exceptions, acceptance results, change notices and recurring evidence in one indexed file. Stable requirement IDs should connect every artifact.

DeepInspect

DeepInspect can supply the customer-controlled runtime evidence for authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates the identity context supplied by the application, prompt and response classification, model destination and active policy before the traffic proceeds. A per-decision record can preserve the route, policy version, outcome, reason and timestamp for the acceptance tests written into the addendum.

That record verifies observed traffic at the routed boundary. Contractual rights, supplier-internal model development and vendor-managed routes that bypass the proxy are with counsel, procurement and supplier governance. Book a technical deep dive at deepinspect.ai.