How to Draft a SaaS Master Services Agreement Under Texas Law for AI-Powered Customer Support Tools (2026)
A Texas-governed SaaS Master Services Agreement (MSA) for AI customer-support tools should cover at least 12 core issues—data rights, security, uptime, and AI risk allocation among them. Because these platforms process personal data and business confidential information at scale, small drafting gaps can create outsized liability. This article explains a 2026-ready Texas-law drafting framework, including clauses and examples tailored to AI-powered support tools.
Why AI-powered support tools change the “standard” SaaS MSA under Texas law
Traditional SaaS MSAs assume a predictable software workflow: the customer inputs data, the vendor processes it, and the software returns deterministic outputs. AI-powered customer support tools—chatbots, agent-assist copilots, ticket triage models, summarization and sentiment engines—break that assumption. They generate probabilistic outputs, may rely on third-party model providers, and can create new regulatory and commercial risk: hallucinations, defamation, IP contamination, and unauthorized disclosure of customer data.
Texas law generally enforces clear, negotiated risk allocation in commercial contracts, including limitations of liability and warranty disclaimers, particularly between sophisticated parties. The drafting objective is to translate AI-specific operational realities into enforceable contractual obligations and remedies: (1) define what the AI is allowed to do, (2) define what data it can touch, (3) define what “good performance” means (SLA plus model governance), and (4) allocate losses in a way that matches control.
Deal architecture: MSA + Order Form + DPA + Acceptable Use + Security Exhibit
For AI support SaaS, a clean structure prevents internal conflicts and makes compliance auditable:
Recommended document stack
MSA (master terms): legal and risk framework—warranties, indemnities, limits, confidentiality, dispute resolution, audit rights, insurance, assignment, etc.
Order Form(s): commercial terms—subscription fees, term, user counts, support tiers, usage limits (including token or API call limits), and the SLA level purchased.
Data Processing Addendum (DPA): privacy roles, processing instructions, cross-border transfers (if any), subprocessors, security measures, and incident notice windows.
Security Exhibit: technical/organizational measures (encryption, access controls, logging, vulnerability management), evidence packages (SOC 2), and pen-test cadence.
Acceptable Use Policy (AUP): prohibited content (e.g., unlawful discrimination, deceptive communications), restrictions on prompt injection attempts, and rate-limit abuse.
Under Texas contract interpretation principles, you want a clear order-of-precedence clause so the DPA or Security Exhibit governs security/privacy issues if there is a conflict, and Order Forms govern pricing and scope.
Define the AI service precisely: scope, model stack, and “human-in-the-loop” reality
AI disputes often turn on “what exactly did you promise?” Your definitions section is not boilerplate—it’s your first risk-control tool.
Key definitions to include
“AI Features” (e.g., auto-drafting responses, summarizing tickets, routing, knowledge-base generation).
“Customer Content” (tickets, chat transcripts, attachments, knowledge base articles, customer PII).
“Output” (responses, summaries, classifications, recommendations).
“Model” and “Third-Party Models” (identify if the service uses OpenAI/Anthropic/others; reserve right to swap models with notice, subject to security equivalence).
“Agent Assist vs. Autonomous Mode” (whether outputs are suggestions to human agents or can be sent directly to end users).
Draft the statement of work / service description so it states what channels are supported (email, webchat, SMS, voice), what integrations exist (Salesforce, Zendesk, HubSpot), and what the vendor will not do (e.g., “not a replacement for legal, medical, or financial advice”).
Data rights and AI training: the clause that most often drives negotiations
In 2026, customers are highly sensitive to whether their data trains the vendor’s models. Texas law won’t supply the answer; your contract must.
Drafting choices: “no training,” “opt-in,” or “limited improvement”
Option A: No training on Customer Content. Vendor may use Customer Content only to provide the services and to meet legal/security obligations.
Option B: Opt-in training. Customer may affirmatively opt in (by Order Form checkbox), often with price concessions or enhanced features.
Option C: Limited improvement using de-identified/aggregated data. Vendor can use de-identified, aggregated telemetry to improve performance, security, and reliability, but not to create a model that can output Customer Content or re-identify individuals.
Be explicit about ownership: Customer owns Customer Content; vendor owns the platform; and the parties clarify who owns Output. Many deals grant the customer ownership of Output as between the parties, while the vendor retains rights in underlying models and general know-how. If you represent the customer, ensure Output ownership does not implicitly grant the vendor a license back to reuse sensitive outputs.
Example clause concept (plain English)
“Vendor may not use Customer Content to train or fine-tune any model used for other customers. Vendor may use de-identified usage statistics to improve service reliability and detect abuse.”
Privacy, DPA alignment, and Texas-specific consumer privacy considerations
Even when Texas law governs the contract, the data may be subject to multiple privacy regimes (e.g., Texas consumer privacy, other state laws, sectoral rules). Your MSA should not pretend the MSA alone “solves privacy.” Instead, pair a robust DPA with operational commitments.
Key DPA items for AI support SaaS
Roles: Customer typically acts as “controller/business,” vendor as “processor/service provider.”
Processing instructions: limit processing to providing support automation and analytics requested by customer.
Subprocessors: list model providers, hosting (AWS/Azure/GCP), observability tools, ticketing integrations; include notice and objection process.
Retention and deletion: define transcript retention, backup retention, and deletion timelines after termination.
Cross-border transfers: if data leaves the U.S., address mechanisms and customer approval.
Sensitive data: prohibit or require additional safeguards for PHI, payment card data, minors’ data, or other regulated content unless expressly supported.
Security and incident response: make it measurable and enforceable
AI support tools centralize high-value data (credentials, account details, complaint narratives). Under Texas law, vague “reasonable security” promises can be hard to enforce. Convert security into specific commitments.
Security exhibit must-haves
Access controls: SSO/SAML, MFA, RBAC, least privilege, admin logging.
Encryption: in transit (TLS 1.2+), at rest (AES-256 or equivalent), key management.
Segregation: tenant isolation, secrets management, production data access procedures.
Secure SDLC: code review, dependency scanning, SBOM availability, vulnerability remediation timelines (e.g., critical in 7 days).
AI-specific controls: prompt-injection defenses, output filtering, jailbreak detection, and guardrails for tool use (e.g., restricting the AI from making refunds without human approval).
Incident clause details
Define “Security Incident” precisely and set notice windows (e.g., “without undue delay and in any event within 48 hours after confirmation”). Include cooperation, forensic preservation, and allocation of costs. Consider who pays for notifications and credit monitoring depending on fault and whether the incident impacted Customer Content.
Service levels (SLA) for AI: beyond uptime
Uptime alone is not performance for AI. A well-drafted SLA for AI support includes reliability and controllability metrics.
Common SLA components
Availability: e.g., 99.9% monthly uptime, with defined maintenance windows and clear exclusions.
Latency: response time targets for chat or agent-assist.
Support response: priority-based ticket response times.
Quality controls: while vendors resist guaranteeing “accuracy,” you can contract for process metrics: evaluation reports, drift monitoring, and the ability to tune policies/guardrails.
Service credits: define as the customer’s sole and exclusive remedy for SLA breaches—unless the breach also constitutes a security incident or willful misconduct.
Warranties and disclaimers: manage “hallucinations” and regulated advice risk
Texas courts commonly enforce warranty disclaimers if conspicuous and not inconsistent with express warranties. For AI support tools, vendors typically disclaim that outputs are error-free. Customers should still insist on a baseline warranty that the service will materially conform to documentation and that the vendor will use commercially reasonable efforts to prevent harmful output patterns.
Balance points to negotiate
Vendor warranty: service performs materially per documentation; security controls as described; no known malware; vendor has rights to provide the service.
AI disclaimer: outputs may be inaccurate; customer is responsible for reviewing outputs before sending if using “agent assist.”
Regulated advice carve-out: prohibit using the tool to provide legal/medical/financial advice to end users unless specifically approved and configured.
Indemnities: IP, privacy, and “AI output claims”
Indemnity is where AI risk gets priced. Under Texas law, indemnity provisions are enforced according to their text; be explicit about covered claims and procedures.
Vendor indemnities to consider
