Choosing an AI Development Partner: A Buyer's Ebook

Who this ebook is for

This ebook is for owners, operations leads and technical managers who are about to hire an outside team to build an AI system, such as a retrieval-based assistant, a custom agent or an automation connected to company data. It gives you questions to ask, red flags to watch for and a scorecard you can fill in. It does not name or rank any supplier.

It is written by a supplier, Zunkiree Labs, so read it with that in mind. Where a statement comes from a published source it is cited in the Sources section. Where it is our own view we say so. If your first question is whether to build, buy or outsource, start with our build vs buy whitepaper and return here once you have decided to commission a partner.

1. Be clear about what you are buying

Many software companies now say they do AI. Some of that work is a thin layer over a general-purpose model API, such as a chatbot added to an existing product. Other work is built around your own data and workflows: a retrieval pipeline built against your real documents, agents that can call real internal tools, and a data foundation clean enough that the AI is not guessing. Both can be legitimate, but they are different products with different prices.

The practical risk is a mismatch. A team that delivers a generic chatbot when you expected something wired into your order system, support queue or data pipeline has not necessarily failed. The scope was never agreed. Write down, in one paragraph, what the system must read, what it must change, and who must be able to trust its output. Every question below is easier to answer once that paragraph exists.

2. Questions to ask before you sign

Use these in the first two calls. A partner who has built this kind of system before can answer them in plain terms and with examples.

• Can you show a system that reads and writes to a live data source, not only a chat interface over static documents?
• Do you discuss my data pipeline and integration points before you discuss which model to use?
• What happens when the underlying model changes or is withdrawn? Can the model layer be swapped without rebuilding everything above it?
• What does the system do when it is uncertain: guess, defer to a person, or fall back to a safe answer?
• Which AI systems have you taken into production, and what is your longest-running one?
• How do you monitor quality after launch, and what is the process when answers drift or data changes?
• Who exactly will work on my project, and how are scope changes handled?
• What do I receive at the end: code, documentation, deployment instructions and a handover session?

These come from the buyer guidance in our blog posts on choosing an AI partner, listed in Sources.

3. Red flags

None of these proves a partner is poor, but each is a reason to ask more questions before you continue.

• Claims of expertise in all areas of AI, with no specific systems to show.
• A demo built on sample data, and no discussion of your real data.
• Technical choices that cannot be explained in plain language.
• No experience with production deployments, only prototypes.
• A fixed timeline or price promised before anyone has looked at your data or workflows.
• A price far below other quotes with no explanation of what is left out.
• No discussion of maintenance, monitoring or what happens after launch.
• Answers about security and data handling that stay at the level of general assurances.

The same advice appears in our guide to choosing an AI development company, which also suggests that guaranteed timelines and unusually low prices deserve scepticism.

4. Test their thinking about data and accuracy

Most AI projects succeed or fail on data, not on the model. Two pieces of published research make the point and give you something concrete to ask about.

First, the Spider 2.0 benchmark, published by Lei and colleagues at ICLR 2025, tested models on real enterprise database tasks. Its databases average 812 columns, against 27 in the earlier Spider 1.0 benchmark. The authors report that o1-preview solved 21.3% of tasks in their agent setting, compared with 91.2% for the older benchmark. Their error analysis found that 27.6% of failures came from linking to the wrong tables or columns. These results come from the 2024 and 2025 models the authors tested and later systems score higher on the project leaderboard, so treat the figures as a warning about messy business data, not as a current score. The paper is at arXiv.

Second, a July 2024 Nature paper by Shumailov and colleagues found that models trained repeatedly on content generated by earlier models lose information, starting with rare cases. It is about training, so it matters most if a partner proposes to generate synthetic data or fine-tune a model. Their advice is to keep real, human-produced data in the mix and to track where data came from (Nature).

Questions that follow from this:

• How will you check that the system picks the right records and fields in my data?
• Will you test on my own questions, with answers I can verify, before launch?
• If you plan to generate training data, how will you keep real data in the mix and record where each piece came from?
• Who on my side is responsible for the numbers that drive decisions?

5. Security, location and the contract

AI systems often process sensitive data, so your partner needs a clear security position. Ask to see evidence rather than accept a statement. In the UK, the National Cyber Security Centre describes Cyber Essentials as "the minimum standard of cyber security recommended by the Government for organisations of all sizes." It covers five controls: firewalls, secure configuration, security update management, user access control and malware protection, and comes in two levels, Cyber Essentials and Cyber Essentials Plus. Other countries have their own schemes. The point is to ask which certifications a supplier holds and to see the certificate and its scope.

• Where will my data be stored and processed, during development and in production?
• Who can access my systems and data, and how is that access removed when people leave?
• Who owns the code and the data, and what happens to them if the relationship ends?
• What does the contract say about personal data, sub-contractors and breach notification?
• Who handles security updates after launch?

Location matters mainly for law. The engineering work, such as data pipelines and agent orchestration, can be done remotely. But if a supplier in another country will handle personal data of people in the UK, the ICO says each restricted transfer must be covered by adequacy regulations, by appropriate safeguards together with a transfer risk assessment, or by an exception, and "if you can't identify an appropriate exception, you must not make the transfer." See the ICO guide linked in Sources. This is general information, not legal advice, and other jurisdictions have their own rules. Ask any supplier, including us, which of these apply to your project. Zunkiree Labs is based in Nepal, and we do not claim UK certification on this page.

6. Timeline, price and ownership

Compare the whole cost, not the day rate: discovery, build, hosting, model usage, monitoring, maintenance and the time your own people spend managing the work. A cheaper rate can cost more if a vague brief leads to rework.

Our own suggestion, not a finding from the sources: treat any fixed timeline as credible only after the supplier has seen your data. In our blog guide we give rough ranges, such as 4 to 6 weeks for a simple FAQ chatbot, 6 to 10 weeks for a custom retrieval pipeline and 3 to 6 months for a full AI product. These are our own planning estimates, not an industry benchmark, and your project may differ.

Agree in writing that you own the code and data, that documentation and deployment instructions are included, and how support continues after launch. Our build vs buy whitepaper covers these terms in more detail.

7. The scorecard

Score each shortlisted partner from 1 to 5 on every row, multiply by the weight and add up the results. Our own suggestion, not a finding from the sources: the weights below reflect a typical business project, so change them if, for example, security matters more to you than anything else.

Do not choose on price alone. A failed project usually costs more than the saving from a cheaper supplier.

8. A selection process you can follow

• Define the requirement. The business problem, success measures, available data, budget and must-have features.
• Shortlist three to five suppliers.
• Hold exploratory calls and use the questions in section 2.
• Request written proposals that answer your specific requirement.
• Have a technical person review the proposed approach, especially the data and integration plan.
• Check references from similar projects.
• Run a small pilot with a written success test before committing to the full engagement.

If you would like to talk through a requirement with us, you can schedule a call. If your project is a custom agent, see our custom AI agent service. Use the same questions with us as with any other supplier.

Sources

• National Cyber Security Centre: Cyber Essentials overview
• Information Commissioner's Office: International transfers, a guide, checked 28 October 2026
• Lei et al., Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows, ICLR 2025, revised March 17, 2025
• Shumailov et al., AI models collapse when trained on recursively generated data, Nature 631, July 24, 2024
• Zunkiree Labs, Choosing an AI Development Partner: A Global Buyer's Guide (our own guidance)
• Zunkiree Labs, Choose an AI Development Company: 8 Things to Look For (our own guidance, including the timeline ranges)
• Zunkiree Labs, Choosing a Software Development Partner in the UK

What you get:

• Eight questions to ask any AI development partner
• A list of red flags to watch for in proposals
• How to test a partner's approach to data and accuracy
• Security, data location and contract questions
• A weighted scorecard and a seven-step selection process