AI Agent ควรขออนุมัติเมื่อไหร่? บทเรียนจากระบบที่ผมใช้จริง

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

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

ทำไม AI Agent ที่เก่งถึงยังต้องขออนุมัติ?

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

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

ถ้ายังสับสนระหว่าง agent ที่ลงมือทำได้กับ chatbot ที่แค่ตอบ ลองอ่าน AI Agent กับ Chatbot ต่างกันยังไง ก่อนครับ พอ agent ต่อกับเครื่องมือจริง คำถามเรื่องสิทธิ์และความรับผิดชอบจะสำคัญขึ้นทันที

ผมแบ่งงานให้ AI ทำเองและงานที่ต้องถามคนยังไง?

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

ชั้นแรกคืออ่านและสรุป: เปิด log เช็กสถานะ service สรุป ticket หรือจัดกลุ่มงานค้าง ทำได้เต็มที่ เพราะมันยังไม่เปลี่ยนโลกภายนอก ชั้นสองคือทำงานซ้ำตาม runbook เช่น สร้าง draft, เตรียมไฟล์, หรือลอง recovery ที่มีเงื่อนไขชัดและรันซ้ำอย่างปลอดภัย ชั้นสุดท้ายคือการเปลี่ยนแปลงที่กระทบคนอื่น เช่น deploy production, เปลี่ยนข้อมูลบัญชี, ส่งข้อความจำนวนมาก, แตะ billing หรือยกสิทธิ์ลูกค้า อันนี้ต้องให้ผมกด approve ครับ

หลักนี้สอดคล้องกับงานที่ผมให้ AI ช่วยเฝ้าระวังระบบ: มันรวบรวมหลักฐานและเสนอทางเลือกได้ แต่ไม่ได้ถือกุญแจ production ทุกดอก อ่านเคสตัวเลขจริงต่อได้ใน บทความ AI Agent เฝ้าระวังระบบ

เคสจริง: ทำไมผมไม่ปล่อยให้ AI กู้ระบบลูกค้าเองทุกครั้ง?

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

มีช่วงหนึ่งระบบ provision server ของ Newton ค้างระหว่าง restart ลูกค้ากดสมัครแล้วเครื่องถูกสร้าง แต่ขั้นตอนส่งรหัสผ่านไม่จบ ผมย้อนดูข้อมูล 109 เครื่อง: เวลาปกติ median อยู่ที่ 1.4 นาที และ p90 อยู่ที่ 1.7 นาที เลยตั้ง threshold ว่าเกิน 15 นาทีให้ AI เตือนและตรวจ id, email, IP กับสถานะก่อน จากนั้น recovery ที่กำหนดไว้ทำได้เพียงครั้งเดียว

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

จุดอนุมัติทำให้ workflow ช้าลงไหม?

ไม่จำเป็นครับ ถ้าให้ AI ทำทุกอย่างก่อนถึงจุดที่ต้องตัดสินใจ คนจะเห็นเฉพาะสรุป หลักฐาน และปุ่มเลือกทาง ไม่ต้องเริ่มคิดจากศูนย์

สิ่งที่ทำให้ช้าจริงคือโยนงานมาถามคนแบบไม่มี context เช่น “จะทำต่อไหม?” โดยไม่บอกว่าอะไรเกิดขึ้น กระทบใคร มีทางเลือกอะไร ผมอยากให้ agent ส่งมาประมาณนี้มากกว่า: เคสไหน, ข้อเท็จจริงที่ยืนยันแล้ว, สิ่งที่มันทำไปแล้ว, ความเสี่ยงของแต่ละทาง และสิ่งที่ต้องการให้ตัดสินใจ แค่นี้คนอนุมัติใน 20 วินาทีก็ยังเร็วกว่าให้คนเปิด log ไล่เอง 20 นาทีครับ

ในงาน support ผมใช้หลักคล้ายกัน: AI จบเรื่องทั่วไปได้ราว 84% แต่ถ้าลูกค้าบอกว่าปัญหาเดิมยังไม่หาย ระบบต้องหยุดตอบวนและส่งต่อคนดูแล ไม่ใช่ให้มันเขียนขอโทษฉบับที่สาม อ่านรายละเอียดได้ที่ AI Agent ตอบลูกค้าซ้ำไม่หาย แก้ยังไง

งานอะไรที่ผมไม่ให้ AI ตัดสินใจเอง?

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

ตัวอย่างง่าย ๆ คือให้ AI ร่าง broadcast ได้ คัด segment ได้ และเตือนว่าลิงก์ไม่มี UTM ได้ แต่การยิงหาคนจริงต้องเป็นคนกด เพราะข้อความเดียวอาจไปถึงลูกค้านับพันคน หรือเรื่องการตั้งราคาก็เหมือนกัน AI ช่วยคำนวณและเสนอแพ็กเกจได้ แต่ไม่ควรแก้ราคา live เองจาก prompt สั้น ๆ

อีกกลุ่มคือคำสั่งทำลาย เช่น ลบ file, ล้าง data, ย้าย record หรือ restart ระบบที่มีลูกค้าใช้งานอยู่ ผมไม่ได้ห้าม AI แตะเลย แต่ต้องทำให้มันบอก target ชัด, แสดงสิ่งที่จะเปลี่ยน, มี backup หรือทาง rollback แล้วจึงให้คน approve ความปลอดภัยที่ดีไม่ใช่ “AI ทำอะไรไม่ได้” แต่คือ “AI ทำได้แค่สิ่งที่เราอธิบายความเสี่ยงได้”

ธุรกิจเล็กเริ่มตั้งกติกา approval แบบไหนได้บ้าง?

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

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

ถ้าอยากเรียนวิธี map งาน จัดสิทธิ์ และสร้าง automation แบบไม่เริ่มจากของเล่น ผมสอนไว้ที่ คอร์ส LearnAI ครับ สิ่งที่อยากให้ได้กลับไปไม่ใช่ prompt เท่ ๆ แต่เป็นระบบที่คุณกล้าปล่อยให้มันทำงานต่อได้จริง

จะรู้ได้ยังไงว่าตั้งกติกาเข้มเกินไปหรือหลวมเกินไป?

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

ผมชอบเริ่มแบบ conservative ก่อน ให้มันอ่านข้อมูล ทำ draft และเสนอ action แล้วเก็บ log ว่าคน approve หรือ reject เพราะอะไร ผ่านไปสักพักจะเห็น pattern ว่างานไหนคนกดผ่านเกือบทุกครั้ง งานนั้นค่อยย้ายไปเป็น auto ได้ ส่วนงานที่คนแก้บ่อย แปลว่า context หรือกฎยังไม่พอ อย่าแก้ด้วยการเพิ่มสิทธิ์ ให้แก้ด้วยข้อมูลและขอบเขตก่อน

นี่คือวิธีที่ผมใช้กับ agent ในธุรกิจตัวเอง: ขยายความอิสระจากหลักฐาน ไม่ใช่จากความตื่นเต้นเวลาเห็นมันทำเดโมสำเร็จหนึ่งครั้ง 555

AI ควรส่งอะไรมาให้คนอนุมัติบ้าง?

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

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

เช่นระบบเจอการ provision ค้าง ข้อความที่ดีไม่ใช่ “เครื่องลูกค้าค้าง จะ retry ไหม” แต่ควรบอกว่า “บัญชี A สร้างเครื่องเมื่อเวลาใด, สถานะค้างเกิน 15 นาที, id/email/IP ตรงกัน, ยังไม่เคย retry, การกู้ครั้งนี้จะทำอะไรและไม่ส่งเมลซ้ำ” คนเห็นแล้วเลือกได้ทันทีว่าจะเดินต่อหรือส่งให้ทีมเช็กเพิ่ม

ผมชอบบังคับให้ agent แยกประโยคว่าอะไรคือ fact และอะไรคือ assumption ด้วยครับ เพราะ AI เขียนคำอธิบายให้ฟังมั่นใจเก่งมาก ถ้าไม่บังคับแยก เราอาจเผลออนุมัติจากเรื่องเล่าที่ลื่นแทนที่จะเป็นหลักฐานจริง

ถ้าคนไม่กด approve ทันเวลา AI ควรทำยังไง?

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

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

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

ถ้าต้องตั้ง automation เอง ให้คิดย้อนจากเหตุการณ์แย่ที่สุดเสมอ: ถ้าไม่มีใครตอบทั้งวัน ระบบทำอะไรแล้วความเสียหายน้อยที่สุด? คำตอบนั้นควรเป็น default action ของคุณ ไม่ใช่คำตอบที่ทำให้ dashboard ดูว่างานครบเร็วที่สุด

ต้องเก็บ log การอนุมัติไว้ทำไม?

เพราะ log บอกได้ทั้งว่าใครตัดสินใจอะไร และกติกาของเราควรปรับตรงไหนครับ โดยเฉพาะเมื่อ AI เริ่มทำงานหลายขั้นและหลายคนใช้ระบบเดียวกัน

ผมอยากให้เก็บอย่างน้อย request เดิม, หลักฐานที่ AI ใช้, action ที่เสนอ, คนที่ approve หรือ reject, เวลา และผลที่เกิดขึ้นหลังรัน ไม่ใช่เพื่อจับผิดคน แต่เพื่อย้อนดูได้ว่า AI เข้าใจผิดเพราะข้อมูลอะไร หรือคนกดผ่านงานแบบไหนเป็นประจำ

ประโยชน์ที่เห็นเร็วที่สุดคือการปรับ workflow อย่างมีหลักฐาน สมมติว่าเดือนหนึ่งมีคำขอให้ restart service 40 ครั้ง และคน approve 39 ครั้งโดยไม่แก้ข้อความเลย นั่นคือสัญญาณว่า runbook ชัดพอจะย้ายงานนี้ไปเป็น auto แบบมี guardrail ได้ แต่ถ้า 10 ครั้งมีคน reject 4 ครั้งเพราะ target ไม่ตรง ก็รู้ว่าไม่ใช่เวลาขยายสิทธิ์ ต้องแก้การระบุตัวตนก่อน

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

เริ่มทำ approval workflow วันนี้ต้องทำอะไรก่อน?

เลือกงานเดียวที่คุณทำซ้ำบ่อยและเสี่ยงพอจะไม่อยากให้ AI กดเอง แล้วเขียนกติกาแบบภาษาคนก่อนครับ นั่นพอสำหรับจุดเริ่มต้นแล้ว

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

แล้วลองใช้กับเคสจริงสักสิบครั้ง อย่ารีบเชื่อว่ามันดีจากเคสสมมติ สังเกตว่าคนต้องถามอะไรซ้ำ, หลักฐานไหนหาย, และมี action ไหนที่ระบบเสนอผิด จากนั้นแก้กติกาทีละจุด วิธีนี้เรียบมาก แต่ดีกว่าเริ่มจากต่อทุก app แล้วค่อยหาวิธีคุมทีหลังเยอะครับ

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

คำถามที่พบบ่อย

AI Agent ควรขออนุมัติเมื่อไหร่?

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

ให้ AI Agent ทำงานเองทั้งหมดได้ไหม?

ได้เฉพาะงานที่ขอบเขตแคบ มีข้อมูลตรวจสอบได้ และมีวิธีย้อนกลับ ไม่ควรให้ทำงานสำคัญทั้งหมดเองเพียงเพราะมันทำได้ในเดโม

Human approval ทำให้ AI ช้าจนไม่คุ้มไหม?

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

ธุรกิจเล็กควรเริ่มตั้งจุดอนุมัติอย่างไร?

เริ่มจากลิสต์งานที่ทำซ้ำ แล้วแยกผลกระทบเป็นต่ำ กลาง สูง ให้ AI ทำงานผลกระทบต่ำเอง ส่งสรุปให้คนอนุมัติงานกลาง และบังคับให้คนทำงานสูง

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

— Pond