Customer Terms for AI Automation Agencies in New Zealand

If you run an AI automation agency in New Zealand, your customer terms do much more than set out price and scope. They decide who carries the risk when an automation fails, what happens if a client feeds personal information into a workflow, and whether you are stuck honouring promises your sales call never meant to make.

The common mistakes are usually the same: using generic IT terms that do not deal with AI outputs, relying on a proposal alone, and accepting vague statements like “we’ll guarantee results” or “the tool is fully compliant”.

That is where founders often get caught. A client expects a business outcome, the agency thinks it only promised a technical setup, and the contract does not bridge the gap. This guide explains what customer terms for AI automation agency work should cover in New Zealand, the legal issues to check before you sign, and the clauses that help you avoid expensive disputes later.

Overview

Good customer terms for an AI automation agency set expectations early, allocate risk clearly, and match the reality of how AI systems behave. In New Zealand, they should also line up with your obligations around fair marketing, privacy, service quality, and any third party platforms you use.

• Define exactly what services you will provide, and what is out of scope.
• State how AI outputs should be used, reviewed, and approved by the client.
• Deal with data ownership, privacy responsibilities, and security limits.
• Set payment terms, change request rules, and project assumptions.
• Limit liability in a way that is reasonable and clearly drafted.
• Cover intellectual property in custom workflows, prompts, documentation, and deliverables.
• Address third party tools, platform outages, and vendor terms you do not control.
• Explain termination rights, handover obligations, and what happens to client data at the end.

What Customer Terms for AI Automation Agency Means For New Zealand Businesses

Customer terms for AI automation agency work are the contract rules that govern your relationship with each client. They are usually the main document that says what you will build, how the client can use it, what you are not promising, and who is responsible if something goes wrong.

For many agencies, the work sits somewhere between software services, consulting, systems integration, and managed services. That mix creates legal grey areas if your terms are too short or copied from another business model. A web design template usually will not deal properly with AI hallucinations, model drift, prompt engineering, API dependency, workflow errors, or client-side approval obligations.

In practice, your terms should reflect the way AI automation projects are actually sold. A client may ask for an internal chatbot, lead qualification automations, invoice extraction, customer service triage, document summarisation, sales email workflows, or reporting pipelines. Each of those uses carries different levels of risk.

A low risk project might simply route information between tools. A higher risk project might create outputs that staff rely on for finance, HR, legal, medical, or compliance decisions. Your contract should not treat those two projects as if they are the same.

Why the contract matters more for AI work

AI systems are not deterministic in the same way as basic software rules. The output can vary, models can change without notice, and third party providers can suspend or alter functionality. Your customer terms need to say this clearly.

If you do not deal with that point, clients may assume your agency is guaranteeing accuracy, uptime, performance improvements, legal compliance, or a particular return on investment. That can create a mismatch between what was sold and what was actually intended.

How New Zealand law shapes these terms

New Zealand businesses also need to think about the legal standards sitting behind the contract. Your terms do not exist in a vacuum.

The Fair Trading Act 1986 matters because your sales process, proposals, and statements about what the automation can do must not be misleading or deceptive. If your pitch deck says the system will “eliminate errors” or “guarantee compliance”, those claims can create legal risk even if your fine print says something else.

The Consumer Guarantees Act 1993 may also be relevant in some cases, especially if you are dealing with a client that is not acquiring the services in trade. Most AI automation agencies work business to business, and many B2B contracts will seek to contract out of the Act where the law allows. That only works if the parties are both in trade and the clause is properly drafted and fair.

The Privacy Act 2020 is another major issue. If your agency handles personal information, accesses a client database, builds automations that process employee or customer records, or uses offshore AI tools, privacy responsibilities need to be addressed in both your operating process and your contract. The client will want to know who is doing what with the data, where the data may go, and who is responsible for security steps.

What these terms usually include

Most customer terms for AI automation agency services should cover at least the following:

• the services, deliverables, milestones, and assumptions
• client responsibilities, including timely approvals, access, testing, and lawful data use
• fees, deposits, billing timing, late payment consequences, and treatment of scope changes
• intellectual property ownership and licence rights
• privacy, confidentiality, and data handling rules
• warranties, disclaimers, and limits on business outcome promises
• liability caps and excluded losses
• termination, suspension, and post-termination assistance
• dispute resolution and governing law in New Zealand

If your agency has a master services agreement plus statements of work, the main terms should still be readable on their own. Clients rarely remember verbal explanations after a dispute starts. The written terms will matter most.

Legal Issues To Check Before You Sign

The key legal question is whether the contract matches the real technical and commercial risk of the project. Before you sign a contract, make sure the terms deal with the specific way your automation service is being delivered.

1. Scope and deliverables

Scope is usually where disputes begin. If your proposal says “AI customer support automation” and the client assumes you will map all edge cases, train staff, monitor performance, and continuously optimise prompts, there is room for conflict.

Your customer terms should spell out:

• what you will build or configure
• which tools and integrations are included
• whether training, documentation, testing, and post-go-live support are included
• what the client must provide, such as system access, brand rules, sample data, and internal reviewers
• what is excluded, such as legal review of outputs, custom code beyond the proposal, or ongoing optimisation outside a support plan

This is especially important before you accept the provider's standard terms from a larger customer. Their paper may assume wider responsibilities than you priced for.

2. Accuracy, outcomes, and disclaimers

You should not leave performance promises vague. AI tools can assist decision making, but that does not mean they will always produce correct or appropriate outputs.

Your terms should deal with matters such as:

• whether outputs are suggestions rather than final advice
• whether human review is required before use in key business decisions
• whether you are promising a process, a deliverable, or a business result
• what assumptions sit behind any forecasted gains, time savings, or lead conversion claims

If you rely on a verbal promise like “this will cut admin by 80 percent”, expect trouble later unless that statement is carefully framed and documented.

3. Intellectual property

Ownership can become messy in AI projects because the work product may include prompts, workflow logic, templates, custom connectors, training materials, and generated outputs. The contract should separate pre-existing materials from bespoke deliverables.

You might keep ownership of your underlying methods, libraries, know-how, and reusable frameworks, while giving the client a licence to use them as part of the solution. The client may own the custom documents or specific workflow configuration created for its business. There is no single correct structure, but the contract drafting should be deliberate.

Check the contract treatment of:

• pre-existing agency IP
• customised deliverables created for the client
• client data and client brand material
• rights to use anonymised learnings or de-identified performance insights
• restrictions imposed by third party AI or software vendors

4. Privacy and data handling

If the automation touches personal information, privacy terms are not optional. They should say who controls the data, who processes it, and what safeguards are expected.

In many projects, the client remains responsible for collecting and using personal information lawfully, while the agency agrees to process data only for the contracted services and with appropriate safeguards. Where offshore providers are involved, the contract should be honest about that. Some clients will also want prior approval before certain vendors are used.

Privacy points often include:

• what categories of data are involved
• whether sensitive or regulated data is excluded
• where data may be stored or processed
• who handles privacy complaints, access requests, and correction requests
• what happens if a suspected privacy or security incident occurs

5. Third party tools and dependency risk

Most AI automation agencies rely on external platforms, APIs, and software subscriptions. You usually do not control their uptime, model behaviour, pricing changes, or terms of service.

Your customer terms should make that clear. If a third party changes functionality, blocks an integration, or introduces new fees, the contract should explain whether this is a change request, a client cost, or a termination trigger.

6. Liability caps and excluded losses

The main risk is open-ended liability for losses you cannot realistically insure or price. A client may try to pass through lost profits, regulatory issues, data correction costs, reputational loss, and downstream claims from its own customers.

Many agencies use a liability cap linked to fees paid over a set period. They also exclude indirect or consequential loss where appropriate. The wording needs care, because an overreaching clause can create negotiation problems or may not work as intended in every situation.

Do not assume a simple one-line cap is enough. Some matters may need separate treatment, such as confidentiality breaches, IP infringement claims, or intentional misconduct.

7. Term, termination, and exit

Projects often end awkwardly when expectations are not set upfront. Your terms should explain when either party can terminate, what fees remain payable, and what handover support is included.

That usually covers:

• termination for convenience, if allowed
• termination for breach or non-payment
• access to materials and credentials on exit
• short transition support periods, if applicable
• data return or deletion steps after the engagement ends

This matters before you spend money on setup or commit agency resources that are hard to redeploy.

Common Mistakes With Customer Terms for AI Automation Agency

The most common mistake is using contracts that describe ordinary software or consulting work, but not the actual risks of AI-enabled services. When the wording is too generic, the dispute usually lands on the question of what the client thought it bought.

Using proposals as the only contract

A proposal is useful, but it rarely deals properly with liability, IP, privacy, termination, and third party tools. If the client signs only a quote or email chain, there may be no clear legal framework once the project changes direction.

A better approach is to make sure the commercial proposal and your standard customer terms work together. The proposal should define the job. The terms should define the legal rules.

Promising business outcomes instead of service outputs

Agencies often sell based on outcomes, which is understandable. But phrases like “guaranteed efficiency gains” or “fully compliant automated responses” create legal exposure if the client reads them literally.

Your contract should distinguish between:

• what the system is designed to do
• what assumptions the design relies on
• what the client must review, test, or approve
• what you are not guaranteeing

Ignoring client responsibilities

Clients often need to provide clean data, internal subject matter expertise, access credentials, policy settings, and approval decisions. If that is not written down, delays and errors may still be blamed on the agency.

This is where founders often get caught after a rushed sales cycle. The client says the rollout failed because the automation underperformed. The agency knows the underlying data was inconsistent or the review process never happened. The contract should say those client-side obligations clearly.

Leaving privacy clauses too light

Many agencies include a single confidentiality clause and assume that is enough. It usually is not. Confidentiality and privacy are related, but they are not the same thing.

If personal information is involved, your customer terms should address who is responsible for lawful collection, instructions for handling the data, security expectations, and breach notification. You may also need a privacy notice and related internal policies and operational procedures behind the scenes.

Accepting enterprise paper without checking the details

Larger customers often send their own master agreement. Those documents may include broad warranties, unlimited indemnities, aggressive service levels, and ownership terms that capture your underlying tools and methods.

Before you sign, review points such as:

• whether you are promising compliance with all laws in a way that is too broad for the project
• whether the indemnity shifts all third party risk to your agency
• whether the liability cap is removed or carved back too heavily
• whether payment terms are too slow for the project profile
• whether the IP clause lets the client take ownership of pre-existing agency materials

Not matching the contract to support arrangements

Some agencies build an automation and step away. Others provide monitoring, retraining, prompt tuning, bug fixes, and monthly reporting. Your terms should not blur those two models.

If ongoing support is optional, say so. If response times only apply during a paid support period, make that explicit. If changes in third party models require paid rework, the contract should reserve that position.

FAQs

Do AI automation agencies in New Zealand need special customer terms?

Usually, yes. General consulting terms often miss issues such as AI output quality, human review, third party model dependency, data processing, and ownership of prompts or workflow logic.

Can we contract out of the Consumer Guarantees Act?

Sometimes. In business to business deals where both parties are in trade, contracting out may be possible if the clause is properly drafted and fair. You should get the wording checked as part of a contract review for your circumstances.

Who owns the workflows and prompts we create for a client?

That depends on the contract. Many agencies keep ownership of pre-existing methods and reusable materials, then license them to the client, while assigning or licensing project-specific deliverables on agreed terms.

Are we responsible if the AI tool gives a wrong answer?

It depends on what your contract says and how the system was presented. Clear terms can say outputs require client review and that you are not guaranteeing accuracy or legal compliance, especially where third party tools are involved.

What if the client wants to use personal information in the automation?

You should deal with privacy responsibilities expressly. The contract should cover lawful use instructions, security steps, vendor involvement, incident handling, and whether certain categories of sensitive data are excluded.

Key Takeaways

• Customer terms for AI automation agency work should do more than confirm price and scope, they should allocate risk for AI outputs, data use, third party tools, and changing project assumptions.
• New Zealand agencies should align their terms with the Fair Trading Act, relevant Consumer Guarantees Act issues, and the Privacy Act where personal information is involved.
• The contract should clearly define deliverables, client responsibilities, IP ownership, payment rules, support boundaries, liability caps, and exit arrangements.
• Generic consulting or software templates often leave major gaps for AI services, especially around accuracy disclaimers, human review, and vendor dependency.
• Before you sign a contract, check whether the wording matches the real technical and commercial risk of the project, not just the sales summary.

If you want help with scope drafting, liability caps, privacy clauses, and intellectual property terms, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.