The interesting question about artificial intelligence in Asia-Pacific is no longer whether organisations will use it. It is why so many well-funded programmes produce a demonstration and never a change in headcount, cycle time or error rate.
Having reviewed deployments that worked and several that quietly stopped, the difference is almost never the model. It is the scope of the first use case, the state of the data underneath it, and whether anyone wrote down in advance what failure would look like.
Where the value actually shows up
Value concentrates in processes that are high-volume, bounded, and cheap to check. Four patterns recur in our client work:
| Pattern | Why it works | Typical first metric |
|---|---|---|
| Document-heavy back office — onboarding packs, KYC files, invoices, purchase orders, standard contracts | High volume, consistent structure, an experienced reviewer can tell a good output from a bad one in seconds | Minutes per document; percentage needing rework |
| Service desk and enquiry triage | Repetitive intent classification, drafting support with a human able to edit before sending | First-response time; escalation accuracy |
| Software delivery — test generation, code review assistance, documentation | Fast feedback loop, errors are caught by existing tests and pipelines | Cycle time; escaped defect rate |
| Data extraction and reconciliation from unstructured sources | Work that was manual and tedious, with a numeric answer that can be verified | Touch time; reconciliation exceptions |
Where it does not pay
Low volume and high ambiguity are the two conditions that kill a business case. If a process runs twenty times a month and the correct answer depends on judgement and relationship history, a language model adds a review step rather than removing one. Two further anti-patterns are worth naming: automating a process that is broken — you get the same wrong answers faster — and choosing a use case because it is visible to the board rather than because it is measured.
Five questions before you approve a pilot
- Is the process high-volume and bounded? If you cannot describe the correct output in a page, you cannot evaluate the system that produces it.
- Do we have the data, and are we allowed to use it? Both halves matter. Available data that you have no right to repurpose is a liability, not an asset.
- Who is accountable for the output? The answer must be a role inside the company. “The model” is not an accountable party in front of a client or a regulator.
- What does failure cost? A drafting error in an internal note and a wrong figure in a regulatory filing are not the same risk, and should not share a control design.
- What is the baseline? Time, cost, error rate, today. Without a baseline, month three arguments about whether it worked cannot be settled with evidence.
The Hong Kong data protection angle
This is the part that most often stalls a pilot after it has been built, because it is addressed last. Under the Personal Data (Privacy) Ordinance (Cap. 486):
- Purpose and notice (DPP1). Data collected to serve a customer is not automatically available to train or improve a vendor’s model. That is a new purpose, and it needs a lawful basis and, in practice, a notification.
- Use limitation (DPP3). Confirm in writing whether the vendor uses your inputs to improve its service. Many do by default, and the terms are often in a sub-processor annex rather than the main contract.
- Security (DPP4). You remain responsible for personal data in a processor’s hands. The obligation is to bind them contractually, not merely to hope.
- Retention (DPP2). Prompt and output logs quietly become a shadow archive. Decide how long they live before the first prompt, not after the first audit.
- Access and correction (DPP6). If a customer exercises their rights, can you retrieve, correct or delete what went into the system?
- Cross-border. If the model runs offshore, personal data leaves Hong Kong. Consider the transfer, the vendor’s location and what the contract says about it.
Vendor questions that separate a vendor from a reseller
| Question | What a good answer sounds like |
|---|---|
| Do you train on our data by default? | A clear yes or no, with the contract clause that says so and the setting that controls it. |
| Where is our data processed and stored? | Named regions, named sub-processors, notice before any change. |
| How do we find out the model changed? | A version and change-notification commitment, not “improvements are automatic”. |
| What is your evaluation evidence? | Measured accuracy on a task resembling ours, not benchmark scores or a customer logo wall. |
| What happens at exit? | Export format, deletion certificate, a stated timeline. |
Governance in proportion
You do not need a forty-page AI policy to be defensible. You need a one-page register of AI tools in use with an owner for each, an approval gate before a new tool touches customer or employee data, a short list of prohibited uses, disclosure to clients where AI contributes to a deliverable they receive, and a scheduled review. The register is what makes the rest possible: most organisations that believe they have five AI tools in use discover, on inventory, that they have twenty.
A 90-day pilot you can defend
- Days 1–15 — baseline and data check. Measure the current process, confirm you may use the data, decide the kill criteria in writing.
- Days 16–60 — build narrow, keep a human in the loop. One workflow, one team, output reviewed by the person who owns the work today.
- Days 61–80 — measure against the baseline. Time, quality, rework rate. Compare like with like, on the same work.
- Days 81–90 — decide to scale, change or stop. A pilot that cannot be stopped was never a pilot. Write up what you learned either way; the second use case is where most of the value sits.
The organisations getting real returns are not the ones with the most ambitious proofs of concept. They are the ones whose first use case was boring, measured, and finished.