By Prakhar Rai, Founder, My Legal Pal. Advocate, Bar Council of India. LL.B, NLSIU Bangalore. Master of Business Laws.
Quick answer: Agentic AI as a service (you will also see GaaS, AgaaS and AaaS) sells outcomes, not software access. The contract has to change with it. You define what the agent may do, price what it delivers, measure results instead of uptime, accept liability for the actions it takes within its authority, keep logs a customer can audit, and split data and training rights clearly. No country has a single statute for this yet. Contract formation, agency, data protection and AI rules from the US, UK, EU and India all apply at once, so your terms need to be written for that mix.
Key takeaways
- A SaaS agreement licenses a tool a human operates. An agentic agreement delegates tasks to software that acts, so the scope of authority becomes the core clause.
- Per-seat pricing breaks down. Outcome, per-task and hybrid pricing need agreed definitions of what counts, or you will argue about invoices.
- Availability SLAs are not enough. Customers will ask for accuracy, timeliness and escalation commitments.
- Blanket “as is” disclaimers are a red flag for serious buyers. Bounded warranties, tiered caps and clear carve-outs close deals faster.
- Logs, human approval points and change control are now contract terms, not engineering details.
- Dates and rules are moving. The EU AI Act timetable was changed in 2026 and Colorado replaced its AI law, so build change-in-law wording into the contract.
Most SaaS agreements were written for one picture: a person logs in, uses a tool, and decides what to do with the result. An agent breaks that picture. It reads the inbox, issues the refund, updates the CRM, orders the stock or sends the email. By the time a human looks, the action has happened.
When a SaaS company adds an agent feature, the product usually ships before the paperwork does. The usual result is a 2019-era terms of service sitting under a product that now acts on a customer’s behalf. Fixing that gap before the first enterprise questionnaire arrives is much cheaper than fixing it during one.
This guide is the contract view of that shift, for providers building agents and for businesses buying them. It is deliberately not a deep dive on every sub-topic. Where a topic has its own article, we link to it once and keep this page focused on what changes. For the narrower question of who pays when an agent causes harm, see our separate piece on AI agent liability.
What “agentic AI as a service” means
An AI agent is software that pursues a goal across several steps, using tools and data, with limited human involvement at each step. “Agentic AI as a service” is selling that capability as a managed offering. The terminology is not settled. You will see GaaS, AgaaS, AaaS and “agent-as-a-service” used for roughly the same idea, and some vendors use them for slightly different things, so define your own term in the contract rather than relying on the label.
The legal difference is simple to state. SaaS is closer to a licence to use a product. Agentic AI as a service is closer to a service: the provider is, in effect, doing work through software.
| Traditional SaaS | Agentic AI as a service | |
|---|---|---|
| What you sell | Access to a tool | Completed tasks or outcomes |
| Who acts | The customer’s user | The agent, within delegated authority |
| Typical price | Per seat, per month | Per outcome, per task, usage or hybrid |
| SLA focus | Uptime, support response | Accuracy, speed, escalation, uptime |
| Risk story | Software defects, data loss | Wrong or unauthorised actions, cascading errors |
| Key new clause | Licence scope | Authority and permitted-actions schedule |
| Evidence | Access logs | Action and decision logs with reasoning steps |
The contract stack: what changes where
You do not need to rewrite everything. You need to know which document carries which change.
| Document | What to change for agents |
|---|---|
| Master agreement or SaaS agreement | Service definition, authority schedule, warranties, liability, audit, change control |
| Order form or statement of work | Outcome definitions, pricing metrics, volume tiers, human-approval settings |
| SLA | Outcome-based metrics, escalation times, service credits |
| Data processing agreement | Agent purposes, sub-processors (model providers), automated decision duties |
| Terms of service for end users | Disclosure that users interact with an AI, limits on reliance, acceptable use |
| Internal policy | Who inside the customer can configure the agent and sign off on new tools |
1. Define the service and the agent’s authority
This is the biggest change. A SaaS definition of “Service” describes a hosted platform. An agentic definition should describe a set of tasks, the systems and data the agent can reach, and the actions it can and cannot take.
A practical way to do it is an authority schedule attached to the contract:
- Permitted actions: for example, draft and send replies under a set value, issue refunds up to a set amount, update records.
- Prohibited actions: deleting data, changing security settings, editing audit logs, moving money above a threshold, signing contracts.
- Systems and data: which databases, APIs and third-party tools the agent can touch.
- Escalation triggers: what makes the agent stop and ask a human, such as low confidence, unusual values or a request outside its scope.
- Change process: who can grant or withdraw authority, and how it is recorded.
Pair contractual limits with technical ones. A sentence in a prompt telling an agent not to spend more than a set figure is weaker than a payment control that refuses the transaction. Courts and counterparties tend to look at what the system actually allowed.
If your agent can sign or accept anything, treat it like a signatory question and read our guide on who can sign a contract for a company. The safest default for most providers is that the agent never executes binding agreements without human approval.
2. Pricing: outcome-based means define the outcome
Per-seat pricing fits poorly when one agent does the work of many seats. Providers are moving to outcome-based (pay per resolved ticket, qualified lead or processed invoice), per-task or per-action, consumption (tokens or compute), and hybrids with a platform fee plus usage.
The contract problems are predictable:
- What counts as an outcome? A “resolved” ticket needs a definition. Is it closed by the agent, not reopened in 7 days, or confirmed by the customer?
- Who measures it? Name the data source and the reporting method.
- Disputes: set a short window to challenge counts and a process for resolving them.
- Cost swings: the provider’s model costs can move with usage. Consider spending caps, committed-use discounts or minimum fees.
- Early termination: if the provider invested up front, a termination-for-convenience right can wipe out its return. Use minimum terms or termination fees.
Once the metric is agreed, ordinary payment mechanics still apply: invoicing dates, late fees and set-off.
3. SLAs and acceptance: measure results, not just uptime
An uptime SLA says the platform was running. It does not say the agent did the job well. Agentic contracts increasingly measure:
- Accuracy: a defined error rate on a defined test set or sample of real tasks.
- Timeliness: time to complete a task or to escalate to a human.
- Containment and escalation: how often the agent handled it alone versus handed it over, and whether it handed over when it should have.
- Customer-side quality: satisfaction scores, if both sides can measure them fairly.
Add acceptance testing before go-live, with AI-specific criteria: edge cases, refusal of prohibited commands, behaviour when the data is wrong. Add a change-control clause for model updates. If a provider can swap the underlying model overnight, the customer needs advance notice, a right to test, and a rollback option for material changes.
4. Warranties and disclaimers
Many first-generation AI terms say the output is provided “as is” and may be wrong. That works for a chat assistant. It looks weak when you sell a service that acts. Sophisticated buyers read a blanket disclaimer as a sign you do not trust your own product.
A more workable middle ground:
- Warrant what you control: that the service will be performed with reasonable skill and care, that the agent will operate within the configured authority, that you will test and monitor it, and that you will fix defects.
- Do not warrant what you cannot: perfect accuracy, or that outputs are unique or free of similarity to other customers’ outputs.
- Be careful with the label “professional services.” It can bring a “reasonable skill and care” standard with it. Decide on purpose whether you want that.
5. Liability caps, indemnities and insurance
This is where agentic deals get stuck. Standard SaaS caps (often tied to twelve months of fees) may bear little relation to what a runaway agent can cost a customer. Providers cannot offer unlimited exposure either.
Approaches that are being used in practice:
| Approach | How it works |
|---|---|
| Tiered caps | Normal cap for ordinary claims, a higher cap for agent-caused third-party claims, data breach or confidentiality |
| Super-cap | A separate, higher cap for specific risks. See our guide to the supercap |
| Carve-outs | Provider carries risk for actions within the authority schedule; customer carries risk for misconfiguration, bad input data or actions a human approved |
| Duty-based liability | Provider accepts liability for failing controllable duties: monitoring, testing, re-calibration, patching |
| Insurance requirement | Technology errors and omissions and cyber cover, with limits set to the cap |
Indemnities need rethinking too. A provider might indemnify third-party claims arising from the agent’s autonomous actions within scope, while the customer indemnifies claims caused by its own configuration or data. Our article on indemnity clauses explains how indemnities work in general.
Check that your insurance actually covers agent-caused loss. Some policies were written before agents existed and may exclude automated decision errors. This needs a conversation with your broker, not an assumption.
6. Logs, audit rights and human oversight
If an agent does something wrong, the first question is what it did and why. Without records, neither side can prove anything.
Put these in the contract:
- Decision and action logs: what the agent did, when, with which tool, and the reasoning steps where available.
- Retention: a stated period.
- Customer access: the right to inspect logs, on request and for incidents, ideally near real time for high-risk uses.
- Human-in-the-loop points: actions that need approval before they run.
- Incident duties: notify within a stated time, contain, investigate and report.
- Regulator support: where the customer must show a regulator how a decision was made, the provider supports that.
7. Data, IP and training
Split data into three buckets and say what happens to each:
- Customer input data: what the customer gives the agent.
- Outputs: what the agent produces for the customer.
- Training and improvement data: whether anything is used to improve models.
Customers increasingly expect that their data is not used for training without consent. Outputs usually go to the customer, but two cautions apply. First, AI-generated material may not attract copyright in some countries without enough human authorship, so promising “ownership” can overpromise. Second, similar prompts can produce similar outputs for different customers, so avoid promising exclusivity you cannot deliver. The provider should keep its models, tools and pre-existing materials expressly. For code-related ownership questions, see who owns your vibe-coded app.
If personal data crosses borders, the transfer tools matter. Our guide to standard contractual clauses covers the EU mechanism.
8. Security: prompt injection and tool access
An agent that reads emails, web pages and documents can be manipulated by hidden instructions in them. This is called prompt injection. The contract should require the provider to apply security controls for it, to restrict the agent’s tool access to what the authority schedule allows, to treat credentials carefully (single-use or scoped credentials where possible), and to report security incidents. Treat the agent’s tool inventory as a controlled configuration with named sign-off before new tools are added.
Can an AI agent bind a company?
This is the question every customer asks. The honest answer is that the law is unsettled, and it differs by country.
| Country | Where the law stands |
|---|---|
| United States | UETA and E-SIGN allow contracts to be formed through electronic agents, even if no person reviewed the action (UETA section 14). Neither says who is responsible when an agent behaves unexpectedly, so ordinary agency and contract rules fill the gap. A Quinn Emanuel client alert from 2026 notes it knows of no reported US decision resolving whether a generative AI agent’s conduct binds the business that deployed it. |
| United Kingdom | No AI-agent statute. Contract formation and agency rules apply: authority that was actual or apparent, and reasonable reliance by the other side. |
| European Union | Contract law is national, so the answer depends on the member state. The AI Act and GDPR add overlapping duties on top. |
| Canada | Moffatt v Air Canada (British Columbia tribunal, 2024) held an airline responsible for what its website chatbot said. It is a small-claims decision, not binding elsewhere, and it was about information, not a negotiating agent. |
| India | The Information Technology Act, 2000, section 10A confirms that contracts formed by electronic means are not invalid only for that reason. Whether an AI agent’s act binds its deployer follows general Contract Act and agency principles. |
Two practical points apply everywhere. A software program is not a legal person, so it cannot itself be a principal or agent, and the business that deployed it usually carries the consequence. And retaining the benefit of an unauthorised deal can be read as accepting it, so customers should act quickly when an agent exceeds its authority.
A related US decision shows courts are still working through the basics. In Amazon v. Perplexity (9th Cir., 4 August 2026), the court vacated an injunction against an AI shopping agent, reasoning that under the Computer Fraud and Abuse Act the user, not the agent, is the one accessing the site. It decided the meaning of “access” under that statute only. It did not decide contract or tort liability, and it left room for websites to enforce their terms against agents.
A regulation map for providers
Obligations stack, and they depend on what your agent does and where your users are. Treat the following as a checklist of what to look at, not a verdict on your product.
| Area | What to check |
|---|---|
| EU AI Act | Whether your use falls in a prohibited, high-risk, transparency or general category. Human oversight and transparency duties sit in Articles 14 and 50. Dates were changed by the Digital Omnibus on AI, published in July 2026: Article 50 transparency from 2 August 2026 (with a later date, 2 December 2026, for marking certain synthetic content already on the market), Annex III high-risk from 2 December 2027, Annex I high-risk from 2 August 2028. Confirm against the Official Journal before relying on these. |
| GDPR and UK GDPR | Article 22 limits solely automated decisions with legal or similarly significant effects. In the SCHUFA case (C-634/21, December 2023), the EU Court of Justice treated an automated credit score as a decision when third parties rely heavily on it, which matters for any agent that produces scores others act on. The UK has reformed its automated decision rules, so check the current text. |
| US states | A patchwork. Colorado repealed and replaced its AI Act with SB 26-189, signed 14 May 2026 and set for 1 January 2027, focused on automated decision-making technology; enforcement has been caught up in litigation, so check the current status. California has disclosure and training-data transparency laws with dates in 2026 and 2027. Federal preemption efforts are ongoing. |
| India | The Digital Personal Data Protection Act applies to personal data processing; see our article on DPDP contract compliance. There is no AI-specific statute for agents. |
| Elsewhere | Singapore, the UAE, Brazil, Canada and others have guidance or draft rules at different stages. For a worldwide map of privacy laws, see our overview of data protection laws around the world. |
Since this area moves fast, add a change-in-law clause: say whether compliance changes are included in the fees, chargeable, or shared, and avoid open-ended compliance promises you cannot support.
A checklist before you launch or buy
If you are the provider
- Write an authority schedule with permitted and prohibited actions.
- Define outcomes and how they are measured, in the order form.
- Replace pure uptime SLAs with accuracy, speed and escalation metrics.
- Offer bounded warranties instead of a blanket disclaimer.
- Set tiered caps and agree carve-outs for misconfiguration and human-approved actions.
- Commit to logs, retention and incident notification you can actually deliver.
- Say what you do and do not do with customer data for training.
- Add change control for model updates and a change-in-law clause.
- Check your insurance covers agent-caused loss.
If you are the buyer
- Ask for the authority schedule and test the refusal of prohibited actions.
- Keep human approval on money movement, deletion and external commitments.
- Get log access and a right to audit.
- Push for a liability cap that reflects the real exposure, plus insurance evidence.
- Require notice and rollback for model changes.
- Confirm training rights over your data in writing.
- Record who inside your company can add tools or widen the agent’s permissions.
Common mistakes
- Reusing an old SaaS agreement and adding “AI” to the definitions.
- Promising outcomes without defining them.
- A blanket “as is” disclaimer on a service that takes actions.
- No logs, so nobody can prove what happened.
- Letting model updates roll out with no notice.
- Quoting a regulatory date from a blog post (including this one) instead of the official text.
If you are moving a SaaS product to an agentic model, or negotiating an agent contract, our technology lawyers for SaaS and AI platforms can help with drafting, and our contract negotiation service helps when the other side’s paper is the problem. If you work with counterparties in the US, see our contract lawyers in the USA page.
Quick answers
What is agentic AI as a service? It is the sale of AI agents that carry out tasks or deliver outcomes for a customer as a managed service. You will also see it called GaaS, AgaaS, AaaS or agent-as-a-service, and the terms are not standardised.
How is an agentic AI contract different from a SaaS contract? A SaaS contract licenses software. An agentic contract delegates work, so it needs a defined authority schedule, outcome-based pricing and metrics, higher or tiered liability terms, action logs and audit rights, and clear data and training rules.
Who is liable when an AI agent makes a mistake? Mostly whoever the contract and the facts point to. The deploying business often carries the first consequence to third parties, and the contract then allocates loss between provider and customer. Carve-outs for misconfiguration and human-approved actions are common.
Can an AI agent legally sign or accept a contract? Laws such as UETA and E-SIGN in the US allow contracts to form through electronic agents, but the software has no legal personality. Whether it binds the business depends on authority and agency rules. Most providers keep human approval on anything that commits the customer.
Does the EU AI Act apply to my AI agent? It can, depending on what the agent does and who it affects. Transparency and human oversight duties are the usual starting points, and timelines were amended in 2026. Check the current Official Journal text for your category.
How should outcome-based pricing be written? Define each outcome, the data used to measure it, who reports it, how disputes are raised, and what happens with minimums, caps and early termination.
A note on who we are
My Legal Pal is an international team of contract lawyers with US law experience. We aren’t a US law firm, and we aren’t a local firm in every country mentioned above. This article is general information and not legal advice on your facts. Have a lawyer qualified in the governing jurisdiction check the details before you act.
About the author. Prakhar Rai is an advocate enrolled with the Bar Council of India and the founder of My Legal Pal. He holds an LL.B from NLSIU Bangalore and a Master of Business Laws, and works on contract drafting, review and disputes for founders and businesses across borders. Full profile
