AI Vendor Due Diligence: A Practical Guide for Thai Enterprises

องค์กรที่กำลังซื้อ AI มักเริ่มจากการเปรียบเทียบความสามารถ ราคา และตัวอย่างสาธิต แต่เครื่องมือที่ทำงานได้ดีในห้องประชุมอาจสร้างปัญหาเมื่อเชื่อมต่อข้อมูลจริง ผู้ซื้อจึงต้องรู้ว่าใครรับผิดชอบข้อมูล คำตอบ และเหตุการณ์ผิดพลาดตลอดอายุสัญญา ไม่ใช่ดูเฉพาะคะแนนจากการสาธิต

AI vendor due diligence คือการตรวจสอบความเหมาะสมของผู้ให้บริการต่อ use case เฉพาะ โดยรวบรวมหลักฐานด้านข้อมูล ความปลอดภัย ประสิทธิภาพ การกำกับดูแล และเงื่อนไขสัญญา บทความนี้เป็นกรอบการทำงานสำหรับผู้บริหารและทีมข้ามสายงาน ไม่ใช่คำวินิจฉัยทางกฎหมายหรือใบรับรองว่าผู้ให้บริการรายใดปลอดภัยเสมอไป

1. Define the decision the AI will influence

Before asking which model is used, state whether the AI drafts documents, retrieves knowledge, recommends a decision, or acts automatically. These uses carry different risks. An internal summarizer reviewed by staff needs different assurance from a system that answers customers directly or informs decisions about people.

Write a one-page scope: who uses the tool, where inputs come from, who receives outputs, who approves them, and which event would stop operation. This becomes the basis for vendor questions, tests, and contract terms. If the team cannot describe who is affected by one wrong answer, comparing vendors is premature.

2. Map data flows and permitted uses

Request a flow diagram from ingestion to deletion, including prompts, attachments, logs, outputs, and subprocessors. Ask where data resides, who can access it, how long it remains, whether it trains or improves models, and how that use can be disabled. Answers should apply to the actual product tier and settings being purchased, not a different edition.

Where personal data is involved, involve the data owner and legal team to review roles, contractual duties, lawful use, and transfers in the organization's context. Do not treat a marketing claim of “PDPA ready” as evidence. Translate data classifications and prohibited inputs into enforceable settings and practical employee instructions.

3. Examine the provider and its dependencies

Ask for evidence on access management, encryption, tenant separation, logging, incident notification, and service recovery, together with the relevant subprocessor list. If the product depends on another model or cloud provider, determine how changes upstream affect quality, cost, and processing location.

Certificates and audit reports help screening but do not replace testing the organization's use case. Check each document's scope, date, and exclusions. In particular, ISO/IEC 42001 addresses an AI management system; it does not guarantee that every answer from a product will be correct.

4. Test with representative cases before deciding

Build a test set from real workflows while removing sensitive information as needed. Include ordinary, ambiguous, and refusal-or-escalation cases. Measure accuracy, completeness, source attribution, response time, and repeatability. Do not let the provider choose only favorable examples.

Have domain experts and end users score results separately. Record unacceptable failures such as cross-permission disclosure, unsupported advice, or confidently wrong answers. The pilot should use production-intended settings and explicit stop criteria for serious events.

5. Convert promises into contract rights

The agreement should address permitted data uses, model-training restrictions, subprocessor changes, incident notice, audit rights, and responsibility for correcting failures. Check whether the provider may change model versions or material features unilaterally and whether the buyer can retest before accepting those changes.

Plan exit before purchase: identify export formats for data and logs, deletion timing for copies and backups, portability of prompts and workflows, and transition support. A poor exit path can make switching costs larger than first-year savings.

6. Score risk against business outcomes

Use a short decision matrix with non-negotiable gates separate from scored criteria. Gates may cover essential data protections, named accountability, and passing critical test cases. Scored criteria can cover task quality, integration effort, total cost, and auditability. A low price should not offset failure of a mandatory data control.

The outcome should be one of three choices: approve within scope, run a constrained pilot with conditions, or decline for now. Record evidence, rationale, and residual-risk owner in one register so procurement, business, IT, and executives work from the same decision.

7. Govern after purchase, not just once

After launch, monitor quality, customer impact, cost per transaction, data incidents, and vendor changes. Reassess when the model, features, data categories, or user groups change; the original approval only covered its original scope.

NIST's AI RMF calls for ongoing monitoring of third-party risks, while ISO/IEC 42001 provides a structure for organizational policy and accountability. Use these frameworks as reference points, then translate them into named owners, measurable thresholds, and a practical review cadence for the enterprise.

Conclusion: Buy AI on evidence, not promises

Good AI vendor selection is not a search for a tool that can answer everything. It matches a capability to a workflow, its data, and the organization's risk appetite. When evidence, testing, contracts, and ownership connect, buyers can scale AI without trading transparency for speed.

Framework references

• NIST AI RMF Generative AI Profile
• ISO/IEC 42001 overview

Evaluate AI vendors against your enterprise needs

Explore Data & AI Consulting Contact us

Frequently asked questions

What should an AI vendor assessment start with?

Start with the use case and a data-flow map: users, outputs, owner, and prohibited inputs. Then send questions specific to the product and configuration under consideration, rather than relying on generic marketing claims.

Is ISO/IEC 42001 certification enough?

Not on its own. The standard concerns an AI management system. Check the document's scope and test the actual product for the intended workflow, alongside contract, data, and incident review.

Should a pilot use production data?

Begin with synthetic or de-identified representative data. If real data is necessary, set clear scope, access, retention settings, and data-owner approval appropriate to the use case.

What if the vendor changes its model after signing?

Require notice of material changes, retesting rights, and a rollback path in the agreement. Recheck quality, data handling, cost, and controls before broadening use.

Who should approve an enterprise AI purchase?

A business owner should own outcomes and residual risk, with procurement, data, security, IT, and legal reviewing their respective areas. Approval level should rise with the use case's impact.