How your SAAS MSA governing AI provisions could be over-engineered on one respect and under-engineered in another
1. Your MSA may get notably right
A. AI training/data rights are substantially ahead of ordinary SaaS drafting
The default position is effectively no training on identifiable Customer Data, unless separately authorised. It could expressly capture:
- foundation-model training;
- proprietary-model retraining;
- improvement of public AI systems;
- commercial training datasets;
- licensing training datasets; and
- unrelated commercial products.
It could also create a separate AI Training Schedule with dataset, purpose, model, duration, retention, geography, security, audit and withdrawal parameters.
That could be a sophisticated risk allocation because it has separated service delivery from secondary AI exploitation of customer information.
B. The MSA could understand that AI output rights and model ownership are different questions
Customer rights in Outputs are separated from Provider ownership of models/infrastructure.
That distinction is commercially important. The contract can avoid the common drafting error of giving the customer “ownership of AI” when what the parties actually negotiated was a right to use generated outputs.
C. AI security is not merely conventional cybersecurity with an “AI” label
You MSA could expressly address:
- prompt injection;
- model inversion;
- adversarial inputs;
- model extraction;
- data poisoning; and
- unauthorised disclosure through AI processing.
That is a meaningful incorporation of the newer AI threat model rather than simply saying “Provider shall maintain appropriate security.”
D. The MSA could recognise model evolution as a contractual risk
The Provider can retain the ability to update, retrain, replace and retire models, but material adverse changes trigger:
- notice;
- documentation updates; and
- transition measures.
That is a sensible response to the fact that an AI SaaS product can materially change without a conventional software release being characterised as a “new product.”
E. AI transparency is integrated without requiring disclosure of trade secrets
The MSA could balance between:
customer/regulatory transparency
and
protection of model weights, source code, algorithms and security architecture.
That is commercially much more workable than an unrestricted “explainability” obligation.
2. But, Your MSA could deliver these gaps
Third-party AI supply-chain transparency
The MSA could say that the Provider may use third-party foundation models and must exercise commercially reasonable diligence.
That is good, but modern enterprise customers increasingly care about:
- identity/categories of material AI subprocessors;
- where inference occurs;
- whether provider data is retained by the underlying model provider;
- whether the underlying provider trains on inputs/outputs;
- material changes to the AI supply chain;
- security and privacy obligations flowing down; and
- customer objection rights for material changes.
The MSA’s general Sub-processor regime helps, but it is primarily privacy-oriented, not a complete AI supply-chain governance mechanism.
The AI performance governance may be mostly qualitative.
The MSA requires governance, monitoring and risk management but does not establish measurable AI performance criteria.
For higher-risk enterprise deployments, the commercial questions increasingly become:
- What constitutes material degradation?
- What happens if a model’s accuracy materially changes?
- How are model changes evaluated?
- What testing is performed before deployment?
- What happens when a model becomes unsafe or unreliable?
- Is there a rollback/fallback mechanism?
Your MSA could give transition assistance, but not a true AI change-control/evaluation framework.
AI-specific business continuity
Your MSA could require general business continuity and disaster recovery.
That is necessary but not necessarily sufficient for AI-dependent services.
For example, an AI service can be technically “available” while its underlying model provider is unavailable, degraded, rate-limited or materially changed.
However, the MSA may not establish:
- fallback model procedures;
- degraded-mode operation;
- model-provider substitution;
- recovery expectations for AI dependencies; or
- notification of prolonged model-provider degradation.
Regulatory AI risk classification
The MSA may use a risk-based governance concept, which is good.
But it may not create an explicit hierarchy such as:
low-risk AI → enhanced-risk AI → high-impact/high-risk use case
with corresponding controls.
That matters because the appropriate contractual obligations can vary dramatically depending on whether the AI is:
- productivity assistance;
- recommendation;
- customer-facing generation;
- employment-related;
- credit/insurance related;
- healthcare-related;
- safety-critical; or
- used for legally consequential automated decisions.
The current language may put much of that responsibility on the Customer through human-review provisions.
One important commercial asymmetry
Your MSA may say, “Provider is responsible for operation, security and governance”, but may also say “Customer remains responsible for determining suitability of AI Outputs.”
That allocation is commercially understandable.
But then the MSA could also say that neither party is liable for decisions independently made based upon AI Outputs except as expressly provided.
That could create a risk-allocation gap.
Suppose the Provider’s AI system has:
- a documented defect;
- a known systematic failure;
- inadequate safeguards; or
- a security/privacy failure,
and the Customer subsequently relies upon the output.
The Provider could potentially argue that the ultimate decision was the Customer’s independent decision.
The existing AI indemnity/security provisions mitigate this in certain circumstances, but the interaction between AI failure → output → customer decision → liability cap/exclusion should be tested carefully.
This is exactly the sort of issue that a conventional keyword review could miss because each individual clause looks commercially reasonable.
That is why – Your MSA could be over-engineered in one respect—and under-engineered in another
Over-engineered – The MSA may contain extensive AI language covering:
- governance;
- training;
- output;
- confidentiality;
- security;
- transparency;
- change management;
- warranties;
- indemnity;
- liability.
That is a strength, but there could some duplication – The same concepts—human oversight, probabilistic outputs, model evolution and responsibility—may appear multiple times.
Under-engineered – The corresponding operational machinery is thinner:
- measurable AI controls;
- AI supplier governance;
- model-change records;
- model-performance evidence;
- fallback/continuity;
- cross-document control;
- version governance.
So the MSA is stronger on principles than on operational verification.
That distinction is important because the trend material expressly moves toward computable and verifiable contractual obligations rather than purely textual promises.