When an AI project outgrows the quote

AI projects rarely drift in abstract ways. More often, the pressure point is specific: a client adds another dataset, asks for cleaning that was assumed complete, raises the benchmark, or wants the tool connected to a live system after the quote has already been accepted. When that happens, the real issue is not just whether the team can do the work. It is whether the original price, timing and acceptance criteria still match the job now being requested.

The safest response is usually to go back to the written baseline, classify the request properly, and record any change in a way the right client contact can actually approve. That is especially important in AI matters because data changes can affect testing, delivery risk, deployment effort and privacy responsibilities, not just build hours.

In a New Zealand AI project, the contract baseline, approval authority and revised acceptance tests should stay aligned. When a new dataset includes personal information, review the planned use against the IPPs. The Privacy Commissioner recommends using and updating a Privacy Impact Assessment to identify privacy risks; account for that review in the project plan. This guidance is general information only and is not legal advice.

Check what the original price actually covered

Before answering a change request, pin down the original commercial baseline. In AI projects, scope drift often starts because everyone agrees on the goal but not on the assumptions behind it.

Your baseline may sit across a quote, proposal, scope of work document, onboarding notes, purchase order and project messages. Those documents can play different commercial roles from deal to deal. In practice, the safest approach is to check what your written terms say, what assumptions were recorded, and what both sides have communicated about changes.

For an AI build, the original price should usually be tied to specific assumptions about:

• the problem the model or workflow is solving
• the deliverables included, such as a prototype, workflow, integration, dashboard or deployment support
• the data the client will provide, including format, quality and volume
• whether training, validation or test datasets are already prepared
• which systems need to be connected
• how success will be checked, such as an agreed benchmark or acceptance test
• what the client must do, including access, approvals, subject matter input and testing
• what is excluded, such as major data cleaning, extra environments, retraining cycles or production hosting

Business.govt.nz guidance encourages businesses to be clear about scope, exclusions, price, responsibilities, quality measures and who pays for specification changes. That is useful baseline guidance. It is not the same as the specific terms your business and the client negotiated for this project.

If you quoted to build a retrieval assistant using the client's tagged knowledge base, and the client later supplies a large batch of unstructured files that need cleaning and labelling, that may change the work materially. The issue is not only more hours. It can affect tooling, testing, delivery risk and handover.

Classify the request before you say yes

Not every mid-project request is a true variation, and not every tweak needs a formal reset. But you should classify the request before promising anything.

A practical sequence is to:

1. describe the request in plain language
2. compare it with the original assumptions and exclusions
3. estimate the effect on price, timing, resourcing and dependencies
4. check whether it raises data, privacy, IP or security issues
5. confirm who on the client side can approve the commercial change
6. confirm the agreed position in writing using the process set out in your contract
7. update the delivery record, backlog, milestones or scope document so the team is working from one current version

In AI work, scope usually shifts when the client asks for something like:

• a new dataset or a much larger dataset
• data cleaning, labelling or enrichment that was meant to be done already
• a new performance target or a different way of measuring success
• an extra integration with another business system
• new governance steps such as explainability reporting or human review
• a move from internal proof of concept to customer-facing production use
• expanded acceptance testing across more scenarios or user groups

Some of these requests may already sit within contingency, support work or a broad agile retainer. Others may not. The point is to make an active call, not an accidental one.

Describe the change so someone can actually approve it

If the work has changed, describe it precisely enough for budget and delivery approval. Vague wording causes the same problem twice: once when you try to price it, and again when you try to finish it.

A useful change description for an AI project usually covers:

• which deliverable is changing
• what new or changed data is involved
• how the change affects training, evaluation or output behaviour
• any new integration points or environments
• the revised price or pricing method
• the effect on milestones, dependencies and final timing
• the revised acceptance test
• which assumptions, exclusions and client responsibilities still apply
• who is authorised to approve the change

For example, "add another data source" is too loose. A stronger version would say that the provider will ingest one additional customer support dataset in CSV format, map agreed fields, perform up to an agreed level of cleaning, retrain the classification workflow, and rerun evaluation against an updated test set supplied by the client. It should also say whether this changes a milestone, the budget or the client's review obligations.

Approval authority matters. In practice, AI providers often receive requests from a product lead, operations contact or technical stakeholder who can guide delivery but may not be able to approve extra spend, a deadline extension or changed acceptance criteria. As an operational matter, ask who can sign off those items and follow the contract variations process set out in the contract if there is one.

The same caution applies to project paperwork. A quote, estimate, purchase order or statement of work can help define the working arrangement, but none of those labels should be treated as having one fixed effect in every deal. The safer course is to make sure the current scope and approval path are clearly recorded and consistent with the agreed terms.

Why AI scope changes often affect more than build hours

Clients sometimes treat scope change as a small development add-on. In AI projects, changes to data, evaluation and deployment can reshape the project itself.

Take a few examples. If the client changes the target from general usefulness to a measurable precision threshold, you may need more annotation work, more tuning or a different model approach. If they add handwritten PDFs to a workflow priced for clean text exports, extraction and validation effort may rise sharply. If they want to connect the tool to a live customer process instead of a sandbox, logging, access control, monitoring and rollback planning may become part of the job.

The delivery risk goes beyond developer time. Check what the request does to:

• data preparation and reliability
• model selection or architecture
• testing effort and benchmark design
• security and access controls
• user review and governance processes
• deployment risk and support load

Acceptance testing deserves special attention. If the original deal said the project would be accepted when the system processed sample prompts and returned a structured output, and the client later wants a stricter business threshold or coverage across new edge cases, that should be treated as a scope discussion, not left to assumption.

When the new dataset contains personal information

Privacy can turn into a scope issue very quickly. If a new training or test dataset contains personal information, do not treat it as a routine file swap.

The Office of the Privacy Commissioner says the Privacy Act applies to everyone using AI tools in New Zealand, and the Information Privacy Principles apply across the lifecycle of building and using those tools. Its Artificial Intelligence and the IPPs guidance addresses issues such as training data, accuracy, security, sharing and whether the intended use fits the purpose for which personal information was originally collected.

That does not mean every data change creates the same legal duty or produces the same answer. It does mean you should pause and assess the impact of the new data on the project. Practical questions often include:

• does the dataset contain personal information at all
• why was that information originally collected, and is the proposed use aligned with that purpose
• do handling instructions, access controls or supplier arrangements need to change
• does the client need updated notices, approvals or internal sign-off
• will using the data change how accuracy or fairness needs to be tested

The Privacy Commissioner recommends doing a Privacy Impact Assessment before using AI tools with personal information and updating it regularly. In a project setting, that can affect timeline, client responsibilities and cost. If personal information is introduced after scope was agreed, capture the privacy assessment work openly as part of the change discussion rather than letting it disappear inside the original price.

How to respond when the client wants unpriced work mid-sprint

You do not need to choose between a blunt refusal and doing the work for free. A better approach is to separate immediate triage from final approval.

Start by acknowledging the request and saying whether the team can safely continue current in-scope work while the new item is assessed. Then state clearly that the added dataset, benchmark or integration is being reviewed for scope, timing and price impact. That helps avoid the impression that silence means acceptance.

If the request is urgent, you may be able to offer practical options instead of a flat no. For example, you might pause the current sprint and replan around the new priority, finish the current scope and schedule the change next, run a short paid discovery phase to define impact, or swap out another feature so the budget stays flat but deliverables change.

The key is to show the trade-off. If price does not move, then scope, timing or priority may need to move instead.

Be careful if work has already started. If your team has investigated, designed around or partly built the new request, do not pretend nothing happened. Record what was done, why it was done and whether it was emergency triage, work at risk or approved extra work. Then move quickly to written confirmation using the project's agreed contract process.

A practical response can be simple: the team can continue today's in-scope backlog, but the added dataset and revised benchmark need sign-off on the updated scope, budget and milestone dates before they are folded into delivery.

Keep the record practical and contract-led

Change control does not need to become heavy administration. But it does need a reliable record.

For many small and mid-sized AI projects, the useful record will show:

• the original baseline document or scope reference
• the requested change and when it was raised
• the assessed impact on cost, timing and dependencies
• whether privacy, IP or security review is needed
• who approved, deferred or rejected the change
• what the team should now deliver and test against

Check the variation and approval mechanism your contract actually requires before choosing a format. New Zealand Government Procurement guidance tells public agencies to follow the contract process, obtain the appropriate approval and keep a record of the change. That is a useful process example, not a rule binding a private AI project.

Depending on the agreed mechanism, the record might be a signed variation, a revised statement of work, a project order or another form the contract permits. The practical goal is that delivery, invoicing and client approvals all point to the same current scope. If you are still setting up that process, an IT service agreement is one related document to consider.

If scope changes are repeatedly hurting margin, the fix often starts before the next quote is sent. AI providers usually benefit from making assumptions and dependencies more visible upfront, especially around data quality, data volume, included cleaning work, integrations, evaluation method, client inputs, approval authority and what happens if those inputs change.

Key Takeaways

• Start with the original commercial baseline, including the written scope, assumptions, exclusions, data inputs, integrations and acceptance test.
• Classify a mid-project request before agreeing to it, then assess the impact on price, timing, resourcing and dependencies.
• Describe any change precisely enough for approval, including revised deliverables, data work, milestones, pricing method and acceptance criteria.
• Treat privacy as a live scope issue where new datasets may include personal information, because added assessment work can affect cost and timing.
• Keep the change record practical but consistent with the contract's variation and approval process so delivery, invoicing and sign-off stay aligned.

If your AI project has outgrown the original quote, Sprintlaw New Zealand's legal team can help with service agreements, statements of work, change request processes and privacy-related scope issues. Call 0800 002 184 or email team@sprintlaw.co.nz.