บทที่ 57: จุดที่ต้องให้คนอนุมัติและการมอบอำนาจงานประจำ

ผลลัพธ์ของบทนี้

เมื่อจบบทนี้ คุณจะใช้โมเดลมอบอำนาจสี่ระดับเดิมจาก Part 0 โดยไม่เปลี่ยนชื่อหรือความหมาย แล้วประเมินงานแต่ละชิ้นด้วย “เมทริกซ์ความเสี่ยงแบบไม่ใส่เลขระดับ” เพื่อระบุว่างานใดต้องมีคนตรวจและงานใดห้ามเดินต่อโดยไม่มีการอนุมัติจากมนุษย์

สถานการณ์ใกล้ตัว

ระบบร่างโพสต์โปรโมชั่นได้ถูกใจทีม เจ้าของจึงอนุญาตว่า “ครั้งหน้าทำต่อได้เลย” หนึ่งสัปดาห์ต่อมา ราคาสินค้าเปลี่ยน แต่ข้อความเก่ายังอยู่ ระบบสร้างโพสต์รุ่นใหม่และส่งออกตามความเข้าใจว่าได้รับอนุญาตแล้ว ลูกค้าเห็นราคาที่ไม่ถูกต้องก่อนทีมตรวจพบ

ปัญหาเกิดเมื่อคำอนุญาตไม่มีขอบเขต ไม่มีวันหมดอายุ ไม่มีเงื่อนไขเมื่อข้อมูลเปลี่ยน และไม่มีประตูแยกระหว่าง “ร่าง” กับ “เผยแพร่” ความสะดวกจากการลดหนึ่งคลิกจึงแลกกับผลกระทบภายนอกที่ย้อนกลับไม่หมด ส่วนการมอบอำนาจแบบมีรั้วยังช่วยลดงานซ้ำได้

ศัพท์ใหม่ในบทนี้

• ขอบเขตอำนาจ: เส้นที่บอกว่าบทบาทหนึ่งทำ ตัดสินใจ หรือเปลี่ยนอะไรได้แค่ไหน
• นโยบายที่อนุมัติไว้ล่วงหน้า: กติกาที่มนุษย์กำหนดให้ระบบทำงานประจำบางอย่างได้ภายในเงื่อนไขจำกัด
• จุดที่ต้องให้คนอนุมัติ: จุดที่ผู้รับผิดชอบต้องตัดสินใจอย่างชัดเจนก่อนทำต่อ
• ร่องรอยตรวจย้อนหลัง: บันทึกว่าใครหรือกติกาใดอนุญาตให้ทำอะไร เมื่อไร และได้ผลอย่างไร
• เมทริกซ์ความเสี่ยง: ตารางประเมินผลกระทบ การย้อนกลับ ข้อมูล ระบบ และบุคคล โดยไม่ใช้เลขระดับซ้ำกับระดับมอบอำนาจ

ภาพเปรียบเทียบและขอบเขตของภาพ

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

อย่างไรก็ตาม การกระทำดิจิทัลบางอย่างดูย้อนกลับได้แต่ทิ้งสำเนา การแจ้งเตือน หรือผลต่อคนไปแล้ว การมีปุ่มย้อนการกระทำจึงไม่พอ ต้องประเมินผลกระทบภายนอก สิทธิ์ข้อมูล และความเสียหายหากข้อมูลผิดด้วย

แก่นของเรื่องแบบเป็นชั้น

ใช้โมเดลมอบอำนาจสี่ระดับจาก Part 0 โดยคงชื่อและความหมายเดิม:

ระดับเหล่านี้บอก วิธีที่ AI ช่วย ไม่ได้บอกระดับความอันตรายของการกระทำ เพื่อไม่ให้สับสน ให้ประเมินความเสี่ยงด้วยเมทริกซ์ที่ไม่มีหมายเลข:

การเทียบสองตารางโดยไม่ปนกัน

• ระดับมอบอำนาจ ตอบว่า “AI ช่วยในรูปแบบใด”
• เมทริกซ์ความเสี่ยง ตอบว่า “การกระทำนี้กระทบอะไรและต้องหยุดที่ใคร”
• งานระดับ 1 ก็อาจเสี่ยงสูงได้ เช่น สรุปเอกสารสุขภาพที่มีข้อมูลส่วนตัว
• งานระดับ 4 ทำได้เฉพาะงานประจำที่เมทริกซ์ชี้ว่าความเสี่ยงต่ำ ขอบเขตแคบ ย้อนกลับได้ และมีนโยบายมนุษย์อนุมัติ
• หากงานแตะเงิน สิทธิ์ สุขภาพ กฎหมาย ข้อมูลส่วนตัว ระบบจริง หรือสาธารณะ การ “ช่วยมองเห็น” อาจยังทำได้ในขอบเขตปลอดภัย แต่การกระทำขั้นสุดท้ายต้องหยุดที่มนุษย์และผู้เชี่ยวชาญที่เกี่ยวข้อง

ไม่ว่าระดับมอบอำนาจใด งานใน Oracle V4 ยังเดินครบทั้งขาไปและขากลับ มนุษย์ส่งเรื่องให้ Earth AI จากนั้น Jan เลือก House และรายงานจะกลับผ่าน Jan กับ Earth AI จนถึงมนุษย์ การอนุมัติงานประจำไม่สร้างเส้นทางลัด และไม่ให้อำนาจ Earth AI เลือก House

สิทธิ์ระดับ 4 เกิดจากนโยบายที่มนุษย์ออกไว้ล่วงหน้า คำบอกของ AI ว่า “งานนี้ง่าย” ใช้แทนนโยบายไม่ได้ นโยบายควรตอบอย่างน้อยเจ็ดข้อ:

1. งานใดและผลงานใดอยู่ในขอบเขต
2. ใช้ข้อมูลใดและห้ามใช้ข้อมูลใด
3. ค่าหรือเงื่อนไขใดทำให้หยุด เช่น ยอดเกินเพดานหรือข้อมูลเกินอายุ
4. ระบบทำถึงขั้นใดและห้ามทำขั้นใด
5. บันทึกอะไรเพื่อให้ตรวจย้อนหลังได้
6. คืนสภาพเดิมหรือยกเลิกอย่างไร
7. ใครเป็นเจ้าของนโยบายและต้องทบทวนเมื่อไร

ในเส้นทาง Oracle V4, Jan จัด House ตามงาน แต่การจัด House ไม่ได้เพิ่มสิทธิ์ให้ House ข้ามประตู Earth AI เฝ้าดูว่าจุดที่ต้องให้คนอนุมัติถูกระบุและหลักฐานครบ แล้วส่งคำตัดสินกลับมนุษย์ ผู้อนุมัติอาจอนุมัติ “ทำร่างภายใน 10 รายการตามแม่แบบนี้” โดยไม่อนุมัติ “เผยแพร่ทุกครั้งในอนาคต” ทั้งสองอย่างเป็นคนละอำนาจ

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

หยุดก่อน

อย่าถามเพียงว่า “AI ทำได้ไหม” ให้ถามว่า “ถ้าทำผิด ใครได้รับผล เราหยุดทันไหม คืนสภาพได้จริงไหม และใครมีสิทธิ์อนุมัติ” การทำได้ทางเทคนิคไม่เท่ากับอำนาจทางธุรกิจ

กรณีศึกษาหรือตัวอย่างจำลองที่ปลอดภัย

ร้านเครื่องเขียนจำลองต้องการรายงานสินค้าคงเหลือทุกเช้า เจ้าของอนุมัติ ระดับ 4: รับช่วงงานประจำความเสี่ยงต่ำ ให้ระบบอ่านตารางจำลอง สร้างรายงานภายในจากแม่แบบ และติดธงรายการต่ำกว่าเกณฑ์ เมทริกซ์ระบุว่า “สั่งซื้อ” มีผลต่อเงินและสัญญา จึงอยู่นอกขอบเขต ระบบห้ามสั่งซื้อ ห้ามแก้จำนวนคงเหลือ และห้ามส่งรายงานออกนอกทีม

วันหนึ่งข้อมูลมีหน่วยปนกันระหว่าง “กล่อง” กับ “ชิ้น” เงื่อนไขหยุดในนโยบายทำงาน ระบบจึงไม่สร้างคำแนะนำการสั่งซื้อ แต่ส่งสถานะติดขัดให้ Jan, Earth AI รายงานเจ้าของ และมนุษย์แก้หน่วยก่อนเริ่มรอบใหม่ นี่คือการมอบอำนาจที่ดี: ระบบทำงานประจำได้ แต่ไม่ใช้ความเร็วเป็นเหตุผลเดาเรื่องที่กระทบเงิน

กิจกรรมทดลองอย่างปลอดภัย

เขียนงานสมมติหกข้อ เช่น ร่างอีเมล สรุปรายงาน แก้คู่มือ ส่งข้อความลูกค้า เผยแพร่หน้าเว็บ และอนุมัติค่าใช้จ่าย จากนั้นทำสองรอบ: รอบแรกเลือกระดับมอบอำนาจ 1-4 ตามความหมายเดิมจาก Part 0 รอบสองทำเครื่องหมายมิติความเสี่ยงโดยไม่ให้คะแนนหรือหมายเลข พร้อมผู้อนุมัติและวิธีกู้คืน

• ก่อนเริ่ม: ใช้เหตุการณ์และตัวเลขจำลอง ไม่เชื่อมอีเมล ระบบขาย หรือช่องทางเผยแพร่จริง
• ผลที่คาด: ตารางที่แยก “AI ช่วยแบบไหน” ออกจาก “งานกระทบอะไร” และไม่มีงานกระทบภายนอกถูกมอบเป็นงานประจำโดยไร้มนุษย์
• หยุดและถามคนเมื่อ: อธิบายวิธีย้อนกลับไม่ได้ ไม่รู้ผู้รับผลกระทบ หรือไม่รู้ว่าใครมีอำนาจอนุมัติ
• วิธีกู้คืน: ลดระดับมอบอำนาจกลับเป็น “ช่วยมองเห็น” แยก “เตรียม” ออกจาก “ลงมือจริง” และกำหนดเจ้าของจุดที่ต้องให้คนอนุมัติตามมิติความเสี่ยง

ระวังความเข้าใจผิด

• “มนุษย์อยู่ในวงจร” ไม่พอ ถ้าคนไม่เห็นหลักฐาน ไม่มีเวลาตรวจ หรือปุ่มอนุมัติรวมหลายการกระทำเกินไป
• การอนุมัติครั้งหนึ่งไม่ใช่สิทธิ์ถาวร ต้องมีขอบเขต เงื่อนไข และวันทบทวน
• การขึ้นระบบจริง การเปลี่ยนโครงสร้างข้อมูล การเผยแพร่ และงานสุขภาพเป็นจุดที่ต้องให้คนอนุมัติขั้นต่ำที่เอกสาร V4 ระบุ แต่รายการความเสี่ยงจริงกว้างกว่านี้ตามธุรกิจและกฎหมาย

สามเรื่องที่ควรจำ

1. สิ่งที่ AI ทำได้ไม่เท่ากับอำนาจที่ได้รับ
2. งานประจำทำต่อได้เฉพาะภายใต้นโยบายที่มนุษย์กำหนดและตรวจย้อนหลังได้
3. แยกการเตรียมออกจากการกระทำที่กระทบระบบ คน เงิน และสาธารณะ

คำถามชวนคิด

ในธุรกิจของคุณ มีคำอนุญาตใดที่พูดว่า “ครั้งหน้าทำได้เลย” แต่ยังไม่มีขอบเขตหรือเงื่อนไขหยุด

สะพานไปบทถัดไป

แม้กำหนดอำนาจชัด งานก็ยังสะดุดได้เมื่อเปลี่ยนวัน เปลี่ยนรอบสนทนา หรือเปลี่ยนผู้รับช่วง บทต่อไปจะสร้างใบส่งต่องานที่พกสถานะ เหตุผล และจุดที่ต้องให้คนอนุมัติไปพร้อมผลงาน