You have decided that some part of your business should be automated, and you have started looking for someone in Vietnam to build it. The search is harder than it should be, because almost every software company in the country added "AI" to its homepage in the last two years and the websites have converged on the same vocabulary.

This is a guide to telling them apart. It is written for the person signing the contract rather than for a technical team, and it assumes you are buying from abroad or from outside the industry — which means you cannot assess the code and have to assess everything else.

First, be clear about what you are buying

Very few businesses need a model built. The models already exist, they are rented by the million-tokens from a handful of providers, and the part a vendor builds for you is the plumbing around them: the connection to your accounting system, the rules about what gets escalated to a person, the screen where somebody approves the output, the audit trail, the thing that pages someone when it breaks at two in the morning.

That plumbing is ordinary software engineering. It is unglamorous, it is most of the cost, and it is where projects fail. A company that talks at length about models and briefly about integration is describing the easy ten per cent.

So the question to open with is not "do you do AI". It is: what will you connect this to, and how? If you have not yet worked out which of your systems can be connected at all, start there — it changes what you should be asking for.

The five questions that separate them

1. What happens when it gets something wrong?

Ask this first and listen to how quickly the answer comes. A vendor who has shipped this kind of system before will answer immediately and in detail, because the exception path is the thing they spent most of their time on. A vendor who has only demonstrated this kind of system will talk about accuracy percentages.

Accuracy percentages are close to meaningless on their own. Ninety-five per cent accuracy on invoice extraction sounds excellent until you process two thousand invoices a month, at which point it means a hundred wrong ones. The right question is what the system does with the hundred — whether it knows it is unsure, whether it routes them to a person, and what that person's screen looks like.

2. Can I see the part where a person intervenes?

Ask for a demonstration of the review queue, not the happy path. Every vendor can show you a document going in and clean data coming out. Far fewer can show you the screen where a human sees the three fields the system flagged, fixes them in four seconds, and moves on.

If that screen does not exist in the demonstration, it does not exist in the product, and you will be paying to have it built after you have already signed.

3. What does it cost to run, not to build?

Model usage is billed per use. A system that reads two hundred documents a day costs real money every day, forever, and that cost scales with your business rather than with the project.

A serious proposal states the expected monthly running cost and what drives it. A proposal that quotes only a build price has moved a recurring cost off the page you are reading and onto an invoice you will receive in month four. Ask for the number. Ask what happens to it if your volume doubles.

4. Who holds the keys, and whose account is it on?

There are two arrangements. Either the model provider's account is in your name and the vendor builds on top of it, or the account is the vendor's and you are billed through them.

The first is better for you in almost every case. It means you can see your own usage, you are not paying an undisclosed margin on it, and if the relationship ends you still have the account, the history and the configuration. The second is not automatically bad, but it should be a deliberate choice rather than something you discover at the end.

The same applies to source code and to the server. Ask where it will run, in whose account, and what exactly you receive if you stop working together. "You own the code" is a sentence; a repository you can log into is an asset.

5. What will you need from my side?

A vendor who says "nothing, we handle everything" is either not being straight with you or has not done this before. Integration work needs access to systems, decisions about edge cases, and somebody internal who knows how the process actually runs — which is usually not the person who described it to you.

The useful answer sounds like a list: read access to this system, a test account on that one, four hours a week from whoever owns the process, and a decision from you about what happens to documents the system cannot read. That answer is a sign they have thought about the project rather than about the sale.

What Vietnamese law now requires of them

This changed recently and a lot of websites have not caught up. Vietnam's Law on Personal Data Protection (Law No. 91/2025/QH15) took effect on 1 January 2026, replacing the 2023 decree that most published guidance still refers to. It is structurally similar to the GDPR, with some local differences that matter to you.

Three practical consequences when you are hiring:

  • Consent is narrower than you may be used to. It must be explicit, specific and easy to withdraw, and the "legitimate interest" basis that European businesses lean on is drawn much more tightly in the Vietnamese law. If your automation touches customer or employee records, the lawful basis is a question your vendor should raise before you do.
  • Data leaving Vietnam needs an assessment. A Cross-Border Transfer Impact Assessment must be filed with the Ministry of Public Security within sixty days of the transfer beginning. This is not an approval you wait for, but it is a document somebody has to produce — and if your automation sends data to a model hosted outside Vietnam, which most of them do, it applies to you.
  • There is a data protection officer requirement, with a five-year deferral for smaller companies that does not apply where sensitive data is involved.

You are not hiring a law firm, and a software vendor should not be giving you legal advice. But a vendor who has never heard of the CBTIA is telling you something about how recently they last read anything.

How to structure the first engagement

Do not buy the whole programme. Buy one narrow, paid, time-boxed piece of work with a number attached to the end of it.

The shape that works: pick the single most repetitive process you have, agree what "working" means in a measurable way before anyone writes code, and commission that one thing. Four to six weeks. A fixed price you are comfortable losing.

"Working" has to be a number. Not "automates invoice processing" but "reads ninety per cent of invoices from our twelve largest suppliers without a human touching them, measured over two weeks of real post". Agree how you will measure it and who measures it. A vendor who resists putting a measurable definition in the document is telling you they expect to argue about it later.

What you learn in those six weeks is worth more than the software: whether they communicate in a timezone and a language that works for you, whether they raise problems early or at the deadline, and whether the thing they delivered survives contact with your actual data rather than the sample you sent.

Five things that should give you pause

  • A fixed price for a process nobody has looked at. Anyone quoting before seeing your data is quoting a number designed to win the work, and it will be revised.
  • A proposal with no running cost in it. See above. It is not an oversight.
  • Client logos with no work attached. A logo wall tells you nothing. One paragraph describing a problem, what was built and what the measurable outcome was tells you a great deal — including, if they cannot write it, that there may be no such project.
  • Reluctance to name the model provider. There is no proprietary advantage being protected. Either they are reselling something with a markup they would rather not discuss, or the architecture is less settled than the proposal suggests.
  • Enthusiasm for automating a process you have not written down. If three people in your company do returns three different ways, automating returns means freezing one of those ways into software. A good vendor will tell you to define the process first, even though that delays their invoice.

What to put in the brief

If you want comparable quotes, send every vendor the same page. It should contain:

  • The process, written as the steps a person currently performs, in order.
  • The volume — documents or transactions per month, and the seasonal peak.
  • The systems involved, named. Not "our accounting system" but "MISA AMIS" or "SAP Business One" or "an Excel file on a shared drive".
  • What a mistake costs you, honestly. This determines how much review the design needs and it is the single most useful sentence in the brief.
  • Who internally will be available, and for how long per week.
  • Three sample documents, with the sensitive parts removed.

That page takes an afternoon to write and it will change the quality of the responses more than anything else you do. It also filters, quietly: the vendors who read it carefully and come back with questions are a different population from the ones who return a template within an hour.

A note on what not to expect

Automation pays for itself in processes that are high-volume, repetitive, and tolerant of a human check. We have written separately about what this technology is and is not good at, and the list is shorter than the sales decks suggest. It does not pay for itself in work you do nine times a year, in judgement calls, or in anything where being confidently wrong is expensive. A vendor who agrees with that is more useful to you than one who agrees with everything.

If you would like to talk through a specific process before you go to market, we are happy to be a sounding board, including when the honest answer is that the process is not worth automating yet.