Software Development Agreements For AI Features

Maya runs a Wellington SaaS startup. She hires a developer to add an AI feature that summarises customer support tickets, and everything looks exciting until she asks a simple question: who actually owns the feature, the model prompts and the training data?

The developer says they used their own code library, a paid AI API and some open-source tools. Maya's investor asks for proof that the company owns the product. Suddenly, a clever feature has become a contract problem.

If you're engaging someone to build AI-enabled functionality, your software development agreement needs to do more than describe the build. It should protect your IP, data, confidentiality, testing process and launch position from day one.

Do You Own The AI Feature If A Developer Builds It?

Not automatically - if a contractor builds your AI feature, they may own the copyright in the code unless your contract assigns it to your business.

Under New Zealand copyright law, the starting point is that the creator owns copyright, unless an exception applies or there's a written assignment. If the developer is your employee and they create the work as part of their employment, the position can be different. But if you're using an external developer, agency or technical consultant, don't assume payment equals ownership.

Your agreement should clearly separate:

• Background IP: anything the developer already owned before the project, such as reusable code, libraries, tools, templates or methods.
• Project IP: the new code, prompts, workflows, documentation and other deliverables created for your business.
• Third-party IP: anything owned by someone else, such as open-source software, model provider technology, API tools or licensed datasets.
• Your business materials and rights: your brand and existing IP, product concepts, business logic, datasets, customer data and confidential information. Some of these may be IP, while others are data or confidential information that your contract should control carefully.

For most startups, the contract should say your company owns the project IP once you've paid the agreed fees. If the developer needs to keep using their background IP, you may need a software licence that lets your business use it as part of the product without interruption.

If your AI product also has a name, logo or distinctive brand, consider trade mark protection through IPONZ. A trade mark protects your brand identity, not the software code itself. If the product is owned by your company, keep the IP in the company name rather than a founder's personal name where possible. That makes fundraising, licensing and future growth much cleaner.

What Should Your AI Software Contract Say About Data?

Your contract should say exactly what data the developer can use, where it comes from, what they can do with it and what happens to it when the project ends.

AI features often need examples, prompts, test data, customer records or usage logs. That creates a few extra risks compared with a standard software build, especially if personal information is involved.

Under the Privacy Act 2020, your business needs to handle personal information in line with the information privacy principles. For an AI development project, that usually means thinking carefully about collection, use, storage, security, access, correction and overseas disclosure. If there's a notifiable privacy breach, you may need to notify the Privacy Commissioner and affected people as soon as practicable.

Your agreement should cover:

• Whether the developer can access real customer data or only anonymised or synthetic data.
• Whether the data can be uploaded into third-party AI tools.
• Whether the data can be used to train, fine-tune or improve any model.
• Where the data will be stored, including whether it may be processed overseas.
• Your information security policy, security standards, access controls and who can view the data.
• What the developer must delete, return or retain at the end of the project.

Be especially careful with customer data. If you tell customers their data will only be used to provide your service, then use it to train a new AI feature in a way they wouldn't reasonably expect, you may create privacy and Fair Trading Act 1986 issues. Your privacy policy, customer terms, developer agreement and data processing terms should work together.

Can Your Developer Use Third-Party AI Tools?

Yes, your developer can use third-party AI tools if your contract allows it, but you should control which tools are used and what risks they bring into your product.

AI development often relies on external tools. That might include hosted model APIs, open-source models, vector databases, code assistants, image generators, speech-to-text tools or analytics services. These tools can be useful, but they can also create ownership, security, cost and compliance issues.

Your contract should require the developer to disclose any third-party tools before they're used in the build. For each tool, ask:

• What does the tool do?
• What licence or terms apply?
• Can the tool provider use your inputs or outputs to train its own systems?
• Are there usage limits, commercial restrictions or attribution requirements?
• Where is the data processed and stored?
• What happens if the tool is discontinued or the pricing changes?

Open-source tools need particular care. Some licences are fine for commercial products. Others may require you to share source code, include notices or comply with strict distribution rules. If your developer quietly uses a tool with licence terms that don't suit your business model, you may only find out when an investor, enterprise customer or acquirer reviews your product.

It's also worth dealing with AI-generated outputs. The contract should say who owns deliverables that include AI-assisted work, what checks the developer must run, and whether the developer gives any warranties about originality, non-infringement and compliance with tool terms. Because copyright protection for AI-generated material can be fact-specific, don't rely on assumptions here.

How Do You Manage Testing, Acceptance And Launch Risk?

You manage launch risk by writing clear testing, acceptance and warranty clauses before development starts, not after the feature is nearly ready.

AI features can behave differently from ordinary software because the output may vary. A chatbot might answer correctly most of the time, but occasionally provide a strange response. A recommendation engine might perform well on test data but poorly with real users. Your contract should avoid vague promises and focus on measurable acceptance criteria.

A Worked Example

Say Nia runs an Auckland SaaS platform for customer support teams. She asks a developer to build an AI tagging feature for $30,000 plus GST. The contract says $10,000 is payable upfront, $10,000 after the first demo and $10,000 after acceptance.

The acceptance criteria say the feature must process 1,000 anonymised historical tickets, assign the correct top-level category at least 90% of the time, avoid storing personal information in debug logs, and return a response within 3 seconds for 95% of test requests.

If the feature misses those standards, the developer has 10 business days to fix it before Nia has to approve the final milestone. That gives both sides a clear process and avoids an argument about whether the feature is good enough.

Your agreement should also include warranties from the developer that:

• the deliverables will materially match the agreed specification;
• the developer has the right to provide the code and deliverables;
• the work won't knowingly include malware or hidden access tools;
• third-party tools have been disclosed and used within their licence terms;
• reasonable skill and care will be used; and
• security and privacy requirements will be followed.

If your AI feature will be used by customers, check your customer terms too. The Consumer Guarantees Act 1993 may apply if you supply services to consumers, and the Fair Trading Act 1986 affects what you can say about accuracy, automation and product capability. Your developer contract should give you enough protection if a technical issue creates a customer-facing problem.

Can You Use A Software Development Contract Template In New Zealand?

Yes, you can use a template as a starting point, but an AI feature usually needs tailored clauses that standard software templates miss.

If you're searching for a software development contract template in NZ, look for one that deals with more than payment and deadlines. AI projects need extra detail around data use, model inputs, third-party tools, confidentiality, testing and ownership of outputs.

Use this outline as a planning tool only. A lawyer should tailor the final document before you use it, because the right wording depends on your product, data flows, customers and developer relationship.

1. Parties: Name your company and the developer, using the correct NZBN or Companies Office details where relevant.
2. Project Scope: Describe the AI feature, deliverables, integrations, technical assumptions, software development process and what is outside scope.
3. Milestones And Fees: Set payment dates, milestone triggers, GST treatment and what happens if scope changes.
4. IP Ownership: Assign project IP to your business and deal with background IP, third-party IP and AI-generated outputs.
5. Data And Privacy: Set rules for training data, personal information, storage, security, deletion, overseas processing and any data sharing.
6. Third-Party Tools: Require disclosure and approval of APIs, open-source software, model providers and licences.
7. Confidentiality: Protect product plans, prompts, datasets, customer information, source code and business know-how.
8. Testing And Acceptance: Set measurable test criteria, review periods, fix periods and acceptance steps.
9. Warranties And Support: Include performance, non-infringement, security, bug-fix and handover obligations.
10. Termination: Explain when either side can end the project and what happens to code, data, access and unpaid fees.

A free template may be fine for early thinking, but it often won't reflect how your AI feature actually works. An online fixed-fee service can suit startups that want a tailored contract without open-ended hourly billing. A traditional firm billing by the hour may be appropriate for larger or more complex AI products, especially where there are enterprise customers, regulated data or major integrations.

What If The Developer Is A Contractor, Not An Employee?

If the developer is a contractor, your written agreement should make that relationship clear, but the practical reality of how you work together still matters.

Many startups engage individual developers as contractors because it's flexible and project-based. That can work well, but don't treat the label as the whole answer. New Zealand employment law looks at the real nature of the relationship, not just the wording on the front page of the contract.

The Employment Relations Act 2000, including the Employment Relations Amendment Act 2026 changes, introduced a contractor gateway test for certain independent contractor arrangements. At a high level, the gateway test requires a written agreement saying the person is an independent contractor or not an employee, the ability to work for others except while performing the agreed work, the ability to choose when to work or subcontract in the permitted way, the ability to decline additional work without the arrangement ending for that reason, and a reasonable chance to get independent advice before signing. If the gateway isn't met, the usual common law employee versus contractor assessment can still apply.

For an AI development project, your contractor agreement should deal with:

• the project-based nature of the work;
• control over methods, hours and location;
• whether the developer can work for other clients;
• whether sub-contracting is allowed and on what conditions;
• who provides equipment, tools and licences;
• confidentiality and restraint around competing products; and
• IP assignment and data handling obligations.

If you're controlling the developer like a staff member, requiring set hours every week and making them work only for you, get tailored advice before relying on a contractor setup. Misclassification can create employment, holiday pay and tax-related complications, even if both sides originally wanted a contractor arrangement.

Key Takeaways

• If a contractor builds your AI feature, you need a written IP assignment so your business owns the project deliverables.
• Your agreement should control training data, personal information, model inputs, outputs and deletion obligations.
• Third-party AI tools, APIs and open-source software should be disclosed and approved before they're used in your product.
• Clear acceptance testing helps avoid arguments about whether an AI feature is ready to launch.
• Templates can help you plan, but AI software contracts work best when they're tailored to your product and data flows.
• If your developer is a contractor, make sure the agreement and the working relationship line up with New Zealand employment law.

If you'd like help with your AI software development agreement, IP ownership clauses, data and confidentiality terms, or contractor documents, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.