ปัญหา Data Readiness ใน Enterprise AI

โครงการ AI มักติดขัดไม่ใช่เพราะเรียกใช้โมเดลไม่ได้ แต่เพราะองค์กรยังตอบไม่ได้ว่าข้อมูลหมายถึงอะไร ทันสมัยเพียงใด ระเบียนใดเป็นแหล่งอ้างอิง ใครมีสิทธิ์ลงมือ และจะวัดผลอย่างไร เราจึงตรวจหกด้านก่อนเลือกโมเดล: provenance, freshness, duplicates, baseline, action rights และ outcome measurement

โมเดลมักไม่ใช่ข้อจำกัดแรก

ระบบปฏิบัติการจริงประกอบด้วยแหล่งข้อมูล ตัวระบุ นิยาม สิทธิ์ คิวตรวจสอบ เส้นทางเขียน และ feedback งานวิจัย RAND ระบุข้อมูลไม่เหมาะสม โครงสร้างพื้นฐานไม่พร้อม และโจทย์ธุรกิจไม่ตรงเป็นสาเหตุซ้ำ ๆ ส่วน Stanford AI Index 2026: Economy แสดงการนำ AI ไปใช้มากขึ้น แต่ adoption ไม่เท่ากับผลลัพธ์ที่วัดได้

เริ่มด้วย decision contract

ระบุการตัดสินใจ ผู้รับผิดชอบ action ที่อนุญาต เวลา หลักฐาน และ outcome ให้ชัด งาน lookup, threshold และ reconciliation ที่แน่นอนควรเป็นกฎ ส่วน AI ใช้กับ input ที่กำกวมหรือไม่มีโครงสร้าง

Gate 1: Provenance

เก็บ source system, extraction time, key, transformation version และการแก้ไขของคน คำแนะนำต้องย้อนกลับถึงหลักฐานได้ workflow การสกัดข้อมูลที่ทำซ้ำได้ ต้องบันทึก request, response และ failure เพื่อไม่ให้ตีความข้อมูลที่หายเป็นศูนย์

Gate 2: Freshness

กำหนดอายุข้อมูลสูงสุดตามการตัดสินใจ แยกเวลาเกิดเหตุ เวลา source บันทึก และเวลา workflow ใช้ เมื่อเกิน budget ต้องเตือน abstain fallback หรือบล็อก write ชั้น data warehouse และ ingestion จึงเป็นส่วนหนึ่งของผลิตภัณฑ์การตัดสินใจ

Gate 3: Duplicates และ Identity

กำหนดว่าเมื่อใดสอง record คือ entity เดียวกัน เก็บ raw ID, canonical ID, วิธี match และ confidence ใช้ deterministic key ก่อน และส่ง match ที่ไม่แน่ใจให้ตรวจสอบ การเป็นเจ้าของข้อมูลปฏิบัติการอย่างครบถ้วน ช่วย reconcile และ replay เมื่อระบบต้นทางเปลี่ยน

Gate 4: Baselines

วัด error, cycle time, review effort, coverage, exceptions และ outcome ก่อนเปลี่ยนงาน หลักฐานภายในที่เป็นความลับใช้ดัชนี Baseline = 100 โดยเก็บค่าจริงไว้ในระบบที่ได้รับอนุญาต ประชากร ตัวหาร และช่วงเวลาต้องคงเดิม

Gate 5: Action Rights

สิทธิ์อ่านไม่ใช่สิทธิ์เขียน ทุก action ต้องมี system of record, actor, approval, limit, segregation และ rollback เริ่มจาก read-only หรือ recommend ต่อด้วย dry-run และ approved write ใช้ least privilege, แยก read/write, idempotency และ correlation ID

Gate 6: Outcome Measurement

เชื่อม input → recommendation → review → action → outcome ด้วย ID ที่คงที่ รวม abstention และ rejection กำหนด outcome หลักและ guardrails เช่น severity, override, complaint, latency และภาระงานที่ถูกย้ายไปทีมอื่น

Scorecard ที่ใช้ได้จริง

สถานะ	ความหมาย	ผลต่อ release
Unknown	ยังไม่มีหลักฐาน	ห้ามอ้างผลเชิงปฏิบัติการ
Defined	มี owner นิยาม และ test	offline evaluation เท่านั้น
Verified	ผ่านบนข้อมูลตัวแทน	controlled pilot
Monitored	มี threshold และ response	ขยายแบบจำกัดได้

Gate ที่อ่อนที่สุดและก่อความเสียหายได้เป็นตัวกำหนดระดับ release

จัดลำดับการลงทุนก่อนเลือกโมเดล

แก้ identity ก่อน capacity, context ก่อน prediction, rights ก่อน agent และ baseline ก่อนเปลี่ยน process จากนั้นจึงเทียบ task success, calibration, latency, privacy และ cost ทุก gate ต้องมี owner, monitoring และ response

คำถามสำหรับผู้บริหาร

อย่าถามเพียงว่าใช้โมเดลใด แต่ให้แสดงสายโซ่จาก source evidence ไปสู่ authorized action และ measured outcome หากทำซ้ำไม่ได้ ความสามารถของโมเดลที่เพิ่มขึ้นจะเพียงเร่ง process ที่ยังไม่ผ่านการตรวจสอบ