AI Development & Automation in New Zealand

Bring a job, not a capability

The AI projects that work start from a sentence like this: "Two people spend fifteen hours a week reading supplier PDFs and typing the numbers into our system, and about one in twenty gets keyed wrong."

That can be quoted. It has a cost today, a measurable success test, and an obvious failure mode to design around. "We want to use AI in the business" cannot be quoted, and the proposals it attracts tend to be expensive workshops that end with a recommendation to do the first thing anyway.

If you are not sure which job to pick, look for work that is repetitive, text-heavy, currently done by people you would rather deploy elsewhere, and tolerant of a human checking the output.

What the technology is genuinely good at

• Reading unstructured text. Invoices, applications, emails, reports — pulling out the fields you need. This is the strongest and most reliably profitable category.
• Answering from material you supply. Your policies, manuals, product data. Grounded in your documents, with citations, so answers can be checked.
• Drafting. A first version a person edits — responses, summaries, descriptions. Useful precisely because a human is still in the loop.
• Sorting and routing. Deciding which pile something belongs in, at volumes people find tedious.

And what it is bad at: guaranteeing correctness without a check, arithmetic that has not been handed to a calculator, and knowing when it is wrong. Design around that last one and most projects go fine; ignore it and you get a system nobody trusts after the first embarrassing answer.

Decide what "good enough" means before you build

This is the question that separates projects that finish from projects that drift.

If the system reads invoices at 95% accuracy and a person reviews everything it flags as uncertain, that is a clear win over full manual entry. If it must be 100% correct with nobody checking, you are describing something that cannot be built with this technology, and it is much cheaper to learn that in the first meeting than in month five.

Ask each developer how accuracy will be measured on your own data, and what the review step looks like. "We'll test it" is not an answer. "We'll take 200 of your real invoices, have a person key them, and compare" is.

The bill grows with use

Unlike ordinary software, AI has a per-use cost that continues forever. A pilot processing fifty documents costs almost nothing, which tells you nothing.

Ask for projected monthly cost at your real volume, and ask what happens if volume triples. Ask, too, whether cheaper models were tested for the task — a lot of production work does not need the largest model, and the difference at volume is substantial. A developer who has run these systems will already have that number.

Where your data goes

Three questions, and get the answers in writing:

• Who processes it? Which provider, under which agreement.
• Is it used for training? On the major providers' business tiers it is not, but the default consumer terms differ.
• Where, geographically? If you hold personal or health information, the Privacy Act has things to say about sending it offshore.

A developer who has not thought about this is a developer who has not put one of these into production in a business that cared.

Most of an "AI project" is ordinary software

The interesting part is small. Getting documents in, handling the ones that fail, showing a person the uncertain cases, writing results into the system that matters, keeping an audit trail, and monitoring quality over time — that is normal engineering, and it is most of the budget.

This is good news: it means the work is predictable and the risk is manageable. It also means you should ask which parts of the proposal are AI and which are plumbing, and be suspicious of a quote where the whole thing is described as if the model does everything.

Start with something you can throw away

For most first projects, a small proof of concept on your real data is the right opening move. Not a demo on sample data — yours, with its inconsistencies and its scanned-at-an-angle pages.

Budget $8,000 to $25,000, agree the accuracy test up front, and agree that the code may be discarded. What you are buying is an answer to "does this work well enough on our material?", and either answer is worth the money.

What to compare across quotes

• The accuracy test, defined on your data.
• Failure handling. What happens on a wrong answer, and who notices.
• Monthly usage cost at real volume.
• Data handling, in writing.
• AI versus plumbing, split out.
• Something in production. Not a demo — a system a business has relied on for a year.

Describe the work, not the tool

Do not arrive asking for a chatbot or an agent. Describe the task, who does it today, how long it takes, what it costs when it goes wrong, and what "good enough" would look like. Developers who have shipped this work will tell you which part AI should do — and the honest ones will tell you when the answer is a better form and a database.