รีวิวหลักฐาน 4 ชั้นก่อนขยาย AI Pilot: Usage, Capability, Workflow Outcome และ Job Quality

ทำไม dashboard ของ AI pilot มักตอบผิดคำถาม?

ห้องประชุม pilot มักมีตัวเลขสวย: ผู้ใช้ active เพิ่ม prompt เพิ่ม และเวลาที่ตอบแบบสอบถามว่าประหยัดได้สูงขึ้น แต่คำถามของผู้บริหารคือควรขยายหรือไม่ ซึ่งตัวเลขเหล่านี้ยังตอบไม่ได้ เพราะคนอาจใช้บ่อยกับงานที่ไม่สำคัญ ประหยัดเวลาต้นทางแล้วเพิ่มเวลาตรวจ หรือสร้าง output เร็วแต่ทำให้ทีมปลายทาง rework มากขึ้น

ปัญหาไม่ใช่ usage metric ไม่มีประโยชน์ แต่ถูกใช้ผิดชั้น ยอดใช้บอกการเข้าถึงและพฤติกรรมเบื้องต้น ไม่ได้ยืนยัน value, quality หรือ safety เหมือนจำนวนคนเข้าห้องฝึกไม่เท่ากับทักษะที่ใช้ได้จริง

Evidence Stack จึงเรียงหลักฐานจาก input ไป outcome และ impact เพื่อให้แต่ละ metric ตอบคำถามของตน ก่อน scale ต้องไม่กระโดดจากชั้นแรกไปข้อสรุปสุดท้าย

Evidence Stack 4 ชั้นใช้เทียบ metric อย่างไร?

ชั้น 1 Usage ถามว่าใครเข้าถึงและใช้ตรงไหน ชั้น 2 Capability ถามว่าคนกับระบบทำงานได้ถูกและรู้ขอบเขตหรือไม่ ชั้น 3 Workflow Outcome ถามว่าผลลัพธ์ end-to-end ดีขึ้นหรือไม่ ชั้น 4 Job Quality/Risk ถามว่า value เกิดโดยไม่ผลัก harm ไปให้พนักงาน ผู้สมัคร หรือลูกค้าหรือไม่

เกณฑ์รีวิวมีห้าข้อ: metric ใกล้ outcome แค่ไหน, ตรวจซ้ำได้หรือไม่, แยกตามกลุ่มหรือเคสสำคัญได้หรือไม่, ถูก gaming ง่ายเพียงใด และมีเจ้าของตอบสนองเมื่อหลุด threshold หรือไม่ ไม่มี metric เดียวชนะทุกข้อ จึงต้องใช้ stack ที่หลักฐานชั้นบนตรวจสอบคำอธิบายจากชั้นล่าง

ตัวอย่าง AI ช่วยตอบนโยบายพนักงาน: active users อยู่ชั้นหนึ่ง, accuracy ของคำตอบและความสามารถผู้ใช้ในการรู้ว่าเมื่อไรต้องส่งต่ออยู่ชั้นสอง, first-contact resolution กับเวลาปิดเคสอยู่ชั้นสาม, privacy incident และความเป็นธรรมในการเข้าถึงอยู่ชั้นสี่

ชั้นที่ 1 Usage บอกอะไรและหลอกอะไร?

Usage เหมาะตอบ adoption funnel เช่น eligible, activated, weekly active, use case coverage และ drop-off แยกทีม ข้อมูลนี้ช่วยหาปัญหา access, onboarding หรือความเหมาะของ workflow หากทีมหนึ่งเข้าไม่ถึงเครื่องมือ อย่าเพิ่งสรุปว่า sceptical

แต่ usage ถูก gaming ได้ง่ายเมื่อผูก KPI คนจะสร้างกิจกรรมให้ครบโดยไม่เกิด value และยอดเฉลี่ยอาจซ่อนความกระจุก ตัวเลข active สูงอาจมาจาก champion กลุ่มเล็ก ควรรายงาน distribution และงานที่ใช้ ไม่รายงาน prompt ส่วนบุคคลหรือเนื้อหาที่เกินวัตถุประสงค์

เกณฑ์ผ่านชั้นหนึ่งไม่ใช่ทุกคนต้องใช้ แต่กลุ่มเป้าหมายเข้าถึงได้ มี use case ที่กำหนด และไม่มีช่องว่างพื้นฐานที่ทำให้ผลชั้นต่อไปตีความไม่ได้

ชั้นที่ 2 Capability ต้องวัดคุณภาพแบบใด?

Capability มีสองฝั่ง ฝั่งระบบวัด task success, factual error, exception detection, consistency และเวลาตรวจ ฝั่งคนวัดว่ากำหนด intent ตรวจ output รู้ข้อจำกัด และ escalate ได้หรือไม่ แบบทดสอบควรใช้ตัวอย่างงานจริงที่ de-identify แล้ว ไม่ถามจำคำศัพท์ AI

Microsoft วิเคราะห์บทสนทนา Copilot แบบ privacy-preserving มากกว่า 100,000 รายการและรายงานว่า 49% สนับสนุนงานเชิง cognitive ส่วนข้อมูล survey บอกว่าคนจำนวนมากทำงานที่ปีก่อนทำไม่ได้ สองสัญญาณนี้ช่วยตั้งสมมติฐานเรื่อง capability แต่ยังไม่แทนการประเมินคุณภาพในบริบทองค์กร

ควรเก็บ inter-rater agreement ของ reviewer, false accept, false reject และเวลาที่ใช้แก้ หากคนเร็วขึ้นเพราะลดการตรวจโดยไม่ตั้งใจ metric time saved จะดูดีในขณะที่ความเสี่ยงย้ายไป production

ชั้นที่ 3 Workflow Outcome ต่างจาก time saved อย่างไร?

Time saved เป็นค่าประมาณระดับ task และมัก self-report ส่วน workflow outcome มองตั้งแต่รับงานถึงผลปลายทาง เช่น cycle time ทั้งสาย, first-time-right, rework, backlog, SLA, cost per completed case และคุณภาพที่ผู้รับงานยืนยัน งานหนึ่งเร็วขึ้นสิบห้านาทีแต่เพิ่ม handoff สองครั้งอาจไม่สร้าง value

WEF ชี้ว่าการเปลี่ยนผ่านที่ scale ได้ขยับจาก isolated use cases ไป connected systems จาก episodic initiatives ไป continuous processes และจาก task automation ไป human value creation ดังนั้น unit of analysis ควรเป็น workflow และ outcome ไม่ใช่ feature

เก็บ baseline ก่อน pilot ใช้ cohort หรือช่วงเวลาเทียบที่เหมาะ และบันทึกสิ่งอื่นที่เปลี่ยนพร้อมกัน เช่น headcount, seasonality, policy หรือ volume หากไม่มี comparator ให้เขียนข้อจำกัดแทนการเติม causality ลงใน slide

ชั้นที่ 4 Job Quality และ Risk ต้องอยู่ใน gate ใด?

ชั้นนี้ตรวจว่า AI ทำให้ autonomy, workload, fairness, privacy, safety และ human connection เปลี่ยนอย่างไร OECD รายงานว่าคนทำงานใน finance และ manufacturing ที่เจอการเก็บข้อมูลด้วย AI จำนวนมากกังวล privacy และแรงกดดัน โดยตัวเลขแตกต่างตามภาค เช่น 62%/51% กังวล privacy และ 62%/56% รู้สึกแรงกดดันเพิ่มในสองภาคที่รายงาน

NIST Measure function แนะนำให้เลือก metric ตาม risk ที่ map ไว้ ทดสอบก่อน deploy และสม่ำเสมอระหว่างใช้งาน รวม feedback และ appeal จากผู้ใช้กับผู้ได้รับผลกระทบใน metric ของระบบ สำหรับ HR นี่แปลว่า incident, override, complaint, subgroup error และเวลาตอบ appeal ต้องอยู่บน dashboard เดียวกับ productivity

กำหนด non-compensating guardrail: value สูงไม่สามารถชดเชย privacy breach, discrimination, unsafe workload หรือการไม่มีผู้รับผิดชอบได้ เมื่อชน red line ให้หยุดหรือจำกัด use case ไม่เฉลี่ย harm กับเวลาที่ประหยัดได้

ควรให้คะแนนเพื่อขยาย แก้ หรือหยุดอย่างไร?

ใช้ decision gate แทนคะแนนรวมเดียว ชั้นหนึ่งและสองเป็น readiness gate ต้องมี access, task quality และ operator competence พอ ชั้นสามเป็น value gate ต้องดีขึ้นจาก baseline ใน metric หลักโดยไม่ซ่อน rework ชั้นสี่เป็น trust gate ต้องผ่าน guardrail และมี incident response, appeal, override กับ owner

• Scale: value metric ผ่านช่วงที่กำหนด ผลคุณภาพคงที่ในเคสสำคัญ guardrail ไม่หลุด และทีมรองรับ monitoring หลังขยาย

• Revise: usage หรือ capability ยังต่ำ, outcome บางจุดดีแต่ rework ย้ายทีม, หรือมีปัญหาที่แก้ได้ใน design โดยยังไม่ชน red line

• Stop: ไม่มี lawful/legitimate data path, ไม่มี accountable owner, subgroup harm เกิน tolerance, incident สำคัญซ้ำ หรือผู้ได้รับผลกระทบไม่มีช่องทาง appeal

• Hold for evidence: sample เล็ก seasonality สูง comparator ไม่เหมาะ หรือ metric definition เปลี่ยนกลาง pilot จนสรุปไม่ได้

ตั้ง Data Contract ใน 30 วันอย่างไร?

สัปดาห์แรกเขียน metric contract ทุกตัว: ชื่อ คำถาม นิยาม numerator/denominator แหล่งข้อมูล owner ความถี่ threshold และ action เมื่อหลุด สัปดาห์สองทำ baseline กับ quality sample สัปดาห์สามเชื่อม usage, workflow และ incident ด้วย use-case ID เดียวโดยไม่เก็บข้อมูลส่วนบุคคลเกินจำเป็น

สัปดาห์สี่ทำ decision review โดยให้ Process Owner, HR/People Analytics, IT/Data, Privacy/Risk และตัวแทนผู้ใช้ดูหลักฐานชุดเดียวกัน บันทึก metric ที่ยังวัดไม่ได้ตามแนว NIST แทนการทำช่องว่างให้ดูเหมือนศูนย์

เริ่มเล็กได้: ต่อหนึ่ง pilot ใช้ metric หลักชั้นละหนึ่งถึงสองตัว พร้อม guardrail สองถึงสามตัว ดีกว่า dashboard สามสิบช่องที่ไม่มีใครรับผิดชอบเมื่อสัญญาณเปลี่ยน

ข้อจำกัดและรายการที่ Admin ต้องตรวจคืออะไร?

Evidence Stack เป็นกรอบสังเคราะห์ ไม่ใช่มาตรฐานรับรอง และไม่กำหนด threshold สากล Microsoft เป็น vendor research, OECD survey ครอบคลุมบางภาคและบางประเทศ ส่วน NIST AI RMF เป็น voluntary framework ที่กำลังอยู่ระหว่างปรับปรุง Admin ควรตรวจวันและสถานะของ NIST ก่อนเผยแพร่

ตรวจตัวเลข OECD กับหน้า source โดยระบุภาคให้ครบ ตรวจว่าไม่มีข้อความใดอ้างว่าความสัมพันธ์เป็นเหตุและผล และตรวจ internal links ว่าเปิดได้ ภาพ hero เป็นภาพสร้างใหม่ ไม่ hotlink กราฟหรือภาพจาก Microsoft, WEF, OECD หรือ NIST