What you’ll learn: The exact questions to ask any AI vendor before allowing their tool to process client data, structured as a procurement checklist for C-suites and MIC-ITs.
The procurement gap
Most Hong Kong finance firms approach AI procurement the same way they approach software procurement. They evaluate features, price, and implementation timeline. AI vendors are happy to answer those questions.
The questions that matter are different for AI tools. The training data, the deployment model, and the audit infrastructure determine whether the tool is safe for regulated finance, and most procurement teams do not ask about them.
Here are the ten questions to ask.
1. Where is client data processed?
AI tools can process data in different locations: the vendor’s cloud, a dedicated private cloud, the firm’s own infrastructure, or a combination.
The regulatory answer for Hong Kong finance depends on the data type. Client portfolio data should stay within a closed-loop environment in Hong Kong or a jurisdiction with equivalent data protection. Cross-border data flows involving mainland China entities must comply with PIPL requirements in addition to Hong Kong’s PDPO.
If the vendor cannot tell you exactly which servers process your data and in which jurisdictions, the tool does not meet the baseline for regulated use.
2. Is our data used to train your model?
Some AI vendors train their models on all data that passes through their systems. If a compliance officer uploads a client transaction history to get a risk assessment, that data could become part of the model’s training set and could appear in outputs for other users.
The answer must be contractual. A verbal assurance that “we take privacy seriously” is not sufficient. The contract should state that your firm’s data is not used for model training, reinforcement learning, or any purpose beyond the immediate processing request.
Some vendors offer a “zero training data retention” guarantee. This is the minimum acceptable standard for client data.
3. Does the tool produce an audit trail?
Every AI action in regulated finance needs to be traceable. When was the model invoked? What input data was used? What output was produced? Did a human review and approve the output before it was used?
Some AI tools log nothing. They are black boxes that accept input and produce output without any record of the interaction. These tools cannot be used for any regulated activity because the compliance team cannot answer the question “what happened.”
The tool must log every execution with input, output, timestamp, and human approval status.
4. Can we deploy in a closed-loop environment?
A closed-loop deployment means the AI runs in an environment that is isolated from the public internet and from other customers’ data. The model processes only your firm’s data, and the data does not leave your controlled infrastructure.
Some vendors offer only a multi-tenant SaaS deployment where your data shares infrastructure with other customers. This is acceptable for low-risk, non-client-facing use cases. It is not acceptable for processing client portfolio data, compliance filings, or any regulated activity.
The vendor should offer a private cloud or on-premises deployment option.
5. How do you handle model updates?
AI models are updated frequently. A vendor might release a new version every week, every month, or every quarter. Each update changes how the model behaves: it might classify a transaction differently, generate different text, or apply different logic.
Regulated finance requires version control. If an SFC auditor asks why a particular transaction was flagged in March but not in April, the firm needs to know which model version was in use on each date.
The vendor should allow the firm to control when model updates are applied, or at minimum to lock a specific model version for a defined period.
6. What happens when the model is wrong?
All AI models produce incorrect outputs occasionally. The question is not whether errors occur (they do) but how the system handles them.
A well-designed AI tool includes confidence scoring, human checkpoints, escalation paths, and error logging. A poorly designed one assumes the model is always correct and passes errors downstream without detection.
Ask for the vendor’s documented error handling procedure. If they do not have one, the tool is not ready for regulated use.
7. Does the tool enforce human checkpoints?
The SFC’s circulars on AI risk management explicitly require human-in-the-loop controls for high-risk outputs. The tool must support checkpoints where a human reviews and approves the AI’s output before it is used.
Some tools offer this as an optional feature. Some do not offer it at all. Some offer it but make it easy to bypass. The correct answer for regulated finance is mandatory human checkpoints for any output that affects a client or a regulatory filing.
The tool should not allow the human checkpoint to be skipped or configured away.
8. How is access controlled?
AI tools that process client data need the same access controls as any financial system: role-based permissions, multi-factor authentication, session management, and access logging.
A surprising number of AI tools treat access as a binary setting. Anyone with the link can use it. This is not acceptable. The compliance team must be able to define who can invoke the AI, with which data sets, and for which purposes.
The tool should support the same access control model as your core financial systems.
9. Can we extract our data if we cancel?
Data portability is a procurement requirement, not an afterthought. If the firm decides to switch vendors or bring the AI workload in-house, the data that was processed by the tool, including any labelled data, corrected outputs, and fine-tuning data, must be exportable in a standard format.
Some AI vendors treat data portability as a premium feature or do not offer it at all. The data that your team has reviewed and corrected is an asset. Locking it into a proprietary format is a business risk.
The contract should include a data export clause that defines the format, timeline, and cost of data extraction.
10. Who is responsible if the AI causes a compliance breach?
This is the most important question and the one least asked. If the AI tool processes client data in violation of PDPO, PIPL, or HKMA requirements, who bears the regulatory liability?
Most AI vendors disclaim all liability in their terms of service. The firm using the tool bears full regulatory responsibility. This is standard in enterprise software procurement, but many first-time AI buyers do not realise it applies.
A vendor that refuses to discuss liability terms is not ready to serve regulated financial institutions.
Frequently Asked Questions
Yes, if the tool processes client data. For internal-only tools that handle anonymised data, questions 1, 3, 4, 7, 8, and 10 still apply. The threshold for compliance does not change based on whether the data includes client names.
Ask for the vendor's SOC 2 report, ISO 27001 certification, or equivalent third-party audit. Ask for a data flow diagram that shows exactly where data travels. Ask for a reference call with a regulated financial client who has deployed the tool.
Then build the AI capability in-house using open-source models deployed in your own infrastructure. The orchestration layer (n8n) and agent framework are available as open-source tools. A custom deployment gives you full control over every one of the ten criteria.
