AI and SaaS projects rarely fail because of a single dramatic event. More often, commercial expectations, technical assumptions and operational responsibilities drift apart over time. A customer believes that a system has been purchased to achieve a business outcome; the provider believes it has agreed to deliver specified functionality. Project teams discuss changes informally, data quality problems emerge, acceptance is postponed, and invoices become disputed. By the time lawyers are involved, the parties may no longer agree on what the project was supposed to deliver.
A well-designed contract cannot eliminate implementation risk. It can, however, make risk visible, allocate decision-making authority and preserve a workable path when performance becomes contested. The following seven provisions deserve particular attention.
1. Define the use case, scope and assumptions
The contract should connect the technical description of the service with the intended business use. A list of features is not always enough. The parties should identify material assumptions about integrations, user volumes, data sources, languages, jurisdictions and customer dependencies.
For AI-enabled services, the agreement should distinguish between deterministic functionality and probabilistic output. It should also state which use cases are included, restricted or excluded. This matters because an AI tool that performs adequately in one context may not be suitable for another. A clear scope is therefore both a delivery mechanism and an evidence baseline.
2. Use measurable acceptance and performance criteria
Terms such as “production ready”, “accurate” or “industry standard” can become dispute generators when they are not tied to a test. The contract should specify the acceptance environment, test data, responsible persons, timetable, severity categories and consequences of failure.
In an AI project, performance may depend on the selected metric, the quality of the evaluation set and the acceptable error distribution. A single headline accuracy percentage may hide material weaknesses. The parties should agree how performance will be assessed, who controls the test data and whether thresholds are warranties, targets or service levels.
3. Establish disciplined change control
Technology projects change. The contractual problem is not change itself but change without a reliable record of its effect on price, timing, architecture and responsibility. A practical change-control clause should identify who can request and approve a change, what information a change request must contain, and whether work can begin before commercial approval.
The process should also address urgent security or regulatory changes. Informal messages and meeting discussions may be operationally useful, but they should not silently rewrite the project. A short, usable approval mechanism is usually more effective than an elaborate process that teams avoid.
4. Allocate data responsibilities
AI and SaaS performance often depends on customer data, provider data pipelines and third-party infrastructure. The contract should allocate responsibility for data quality, lawful access, formatting, migration, retention, deletion and security. It should also address whether customer data may be used to train or improve a model and on what conditions.
Swiss data-protection law applies to AI-supported processing and places importance on transparency, purpose and the protection of individuals’ control over their data. For high-risk processing, a data-protection impact assessment may be required. Cross-border projects may also engage EU rules or other national regimes. Contract language should therefore reflect the actual data flows rather than relying on generic privacy wording.
5. Clarify intellectual-property and output rights
The agreement should distinguish pre-existing materials, project-specific deliverables, configurations, prompts, fine-tuned models, training data, documentation and generated outputs. It should identify which elements are owned, licensed or subject to third-party terms.
Particular care is needed where the customer expects exclusivity but the provider relies on reusable methods or shared infrastructure. The parties should also address infringement claims, open-source components and restrictions imposed by upstream model or cloud providers. Ambiguity in this area can impair both deployment and future investment due diligence.
6. Create an evidence and governance framework
A contract should not only prescribe outcomes; it should help the parties understand what happened. Useful provisions may require decision logs, version records, test results, incident records, change approvals and service reports to be retained for an appropriate period.
Governance should identify operational and executive contacts, meeting frequency, escalation triggers and authority levels. For higher-risk AI uses, documentation, monitoring and human oversight may also support regulatory compliance. The EU AI Act, for example, contains transparency, documentation, monitoring and logging duties for defined categories of systems and actors. The precise obligations depend on the system, role and territorial scope.
7. Design escalation and dispute resolution for the project
A dispute clause should fit the commercial relationship. A live SaaS service may require rapid technical escalation and interim arrangements before a final legal process. The clause can provide for a project-level meeting, executive escalation, without-prejudice negotiation or mediation, followed by arbitration or court proceedings where necessary.
The clause should address governing law, seat, language, number and expertise of decision-makers, confidentiality and the availability of urgent relief. In technology disputes, subject-matter expertise can materially reduce the time spent explaining architecture, delivery methods and technical evidence.
From drafting to project discipline
The strongest contract is one that project teams can actually use. Schedules, acceptance plans, responsibility matrices and change templates should be aligned with the legal agreement and introduced during project mobilisation—not retrieved only after a disagreement begins.
AryaTech assists technology providers, customers, founders and investors with contract design, AI and data-governance questions, and dispute-prevention frameworks. Early review is generally most valuable before commercial expectations harden into conflicting positions.
This article provides general information and does not constitute legal advice. Appropriate provisions depend on the transaction, technology, data flows and applicable law.