สรุปจากคลิป ดูคลิปต้นฉบับ

AI Agent ไม่ควรคุยผ่านแชตอย่างเดียว ถ้าอยากใช้ทำงานจริง

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

นี่คือประเด็นหลักจากคลิป “Agents need more than a chat” บนช่อง AI Engineer ที่ Jacob Lauritzen, CTO ของ Legora พูดไว้น่าสนใจมาก โดยเฉพาะสำหรับเจ้าของธุรกิจและคนทำงานที่กำลังคิดจะเอา AI ไปใช้จริงในงานซับซ้อน ไม่ใช่แค่ถามตอบหรือสั่งให้สรุปเอกสารเป็นครั้งคราว

สิ่งที่น่าสนใจคือ Jacob ไม่ได้โฟกัสแค่ว่า model เก่งขึ้นแค่ไหน แต่ชี้ไปที่คำถามที่สำคัญกว่า คือ ถ้าเราอยากให้ AI ทำงานยาวๆ ที่มีหลายขั้นตอน มนุษย์ควรเข้าไปแทรกตรงไหน และควรใช้หน้าตาแบบไหนในการร่วมงานกับมัน มุมนี้สำคัญมาก เพราะหลายทีมในไทยกำลังติดกับดักเดียวกัน คือหวังให้ AI ทำงานระดับ “ผู้ช่วยงานจริง” แต่ยังยัดทุกอย่างไว้ใน chat box

สารบัญ

• Step 1: เริ่มจากยอมรับก่อนว่าแชตไม่เหมาะกับงานซับซ้อน
• Step 2: เข้าใจให้ชัดว่า bottleneck ของงานวันนี้ไม่ใช่ “การลงมือทำ”
• Step 3: ใช้แนวคิด Verifier’s Rule เพื่อแยกงานที่ AI ควรทำ
• Step 4: สร้าง “ความเชื่อใจ” ด้วยการทำให้งานตรวจง่ายขึ้น
• Step 5: เพิ่ม “การควบคุม” ด้วยการออกแบบการร่วมงานใหม่
• Step 6: เปลี่ยนจาก “คุยกับ AI” เป็น “ทำงานกับ AI บน artifact ที่จับต้องได้”
• Step 7: แปลแนวคิดนี้ให้เข้ากับธุรกิจไทยแบบไม่ต้องเป็น developer
• Step 8: Actionable Insights ที่หยิบไปทำได้เลย
• Step 9: Troubleshooting เมื่อเริ่มใช้ AI Agent ในงานจริง
• Step 10: การต่อยอดสำหรับองค์กรที่อยากไปไกลกว่า chatbot
• Step 11: สรุป Checklist ทั้งหมด

Step 1: เริ่มจากยอมรับก่อนว่าแชตไม่เหมาะกับงานซับซ้อน

ภาพที่ Jacob ยกขึ้นมาเห็นชัดมาก เราสั่ง agent ให้ไปค้นข้อมูล ร่างสัญญา อ่านเอกสาร เปิด sub-agent ค้นเว็บ เขียนไฟล์ แล้วทำต่อไปเรื่อยๆ ผ่านไปครึ่งชั่วโมง มันส่งงานกลับมา เราอ่านแล้วเจอว่าบางจุดไม่ถูก ต้องให้แก้อีก

ปัญหาคือหลังจากงานยาวมากๆ agent มักเริ่ม “ลืม” สิ่งที่ทำมาก่อน เพราะเจอข้อจำกัดเรื่อง context และการย่อข้อมูลระหว่างทาง พอให้กลับไปแก้ clause เดียว เราเองก็ไม่แน่ใจแล้วว่ามันแก้เฉพาะจุดนั้น หรือไปกระทบอย่างอื่นด้วย

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

• สั่ง AI ให้ช่วยทำ proposal ยาว 20 หน้า แต่พอขอแก้หน้าที่ 7 เนื้อหาหน้าอื่นเปลี่ยนตาม
• สั่งให้สรุปรายงานหลายฉบับแล้วทำตารางเปรียบเทียบ สุดท้ายแก้แค่คอลัมน์เดียว ตารางส่วนอื่นเพี้ยน
• สั่งให้ร่าง SOP จากข้อมูลหลายแหล่ง พอถามย้อนว่าทำไมถึงเขียนแบบนี้ ก็ไล่เหตุผลกลับได้ไม่ครบ

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

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

Step 2: เข้าใจให้ชัดว่า bottleneck ของงานวันนี้ไม่ใช่ “การลงมือทำ”

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

สิ่งที่กลายเป็นคอขวดแทนคือ

• การวางแผนงาน
• การกำหนด requirement ให้ชัด
• การตรวจทานผลลัพธ์

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

ตัวอย่างในบริษัทไทยที่เห็นได้บ่อยคือ ทีมผู้บริหารอยากใช้ AI ทำงานเอกสาร ฝ่ายขายอยากให้ AI เขียนอีเมล การตลาดอยากให้ AI สร้างแผนคอนเทนต์ แต่สุดท้ายทุกอย่างมาติดตรงหัวหน้าต้องไล่อ่านเองทั้งหมด งานเลยเร็วขึ้นที่ปลายทาง แต่ช้าตรงโต๊ะอนุมัติ

ดังนั้น ถ้าจะใช้ AI ให้คุ้ม คำถามไม่ควรเป็นแค่ว่า “AI ทำได้ไหม” แต่ควรถามว่า

• งานนี้ตรวจได้ง่ายหรือยาก
• ถ้าผิดแล้วเสียหายแค่ไหน
• มนุษย์ควรเข้ามาตัดสินใจตรงช่วงไหน

Step 3: ใช้แนวคิด Verifier’s Rule เพื่อแยกงานที่ AI ควรทำ

Framework หลักที่ Jacob ใช้คือ Verifier’s Rule ถ้างานไหน “ทำได้” และ “ตรวจได้ง่าย” งานนั้นมีโอกาสสูงมากที่จะถูก AI ทำแทนหรือช่วยทำได้ดี

แนวคิดนี้ฟังง่าย แต่เอาไปใช้จริงได้เลย โดยเฉพาะสำหรับคนทำธุรกิจที่กำลังจัดลำดับ use case ของ AI ในองค์กร

ตัวอย่างจากสายกฎหมายที่เขายกมา

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

เมื่อลองแปลมาที่ธุรกิจไทย เราจะเห็นภาพชัดขึ้นมาก

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

ข้อดีของกรอบคิดนี้คือช่วยตัดอารมณ์ “อยากใช้ AI กับทุกอย่าง” ออกไป แล้วแทนด้วยการเลือกงานที่ชนะได้ก่อน

Step 4: สร้าง “ความเชื่อใจ” ด้วยการทำให้งานตรวจง่ายขึ้น

Jacob แยกเรื่องสำคัญไว้ 2 อย่างคือ trust และ control ถ้าไม่มี trust เราต้องตรวจทุกอย่างเอง สุดท้าย AI ก็กลายเป็นแค่เด็กฝึกงานที่ทำให้เรางานเพิ่ม

คำถามคือจะเพิ่ม trust ได้ยังไง เขาเสนอไว้หลายทางที่เอาไปคิดต่อได้ดีมาก

1) เปลี่ยนงานให้ตรวจได้ง่ายขึ้น

ในโลกโค้ด เขายกตัวอย่างว่าถ้าให้ AI เขียน feature แบบกว้างๆ จะตรวจยาก แต่ถ้ามี browser access มี test-driven development งานจะชัดและตรวจผ่าน test ได้

ในธุรกิจทั่วไป หลักเดียวกันใช้ได้ เช่น

• แทนที่จะสั่ง “ช่วยทำแผนขายไตรมาสหน้า” ให้เปลี่ยนเป็น “จัดทำแผนขายโดยอิงข้อมูลยอดขาย 4 ไตรมาสล่าสุด และสรุปเป็น 3 scenario”
• แทนที่จะสั่ง “ช่วยร่างสัญญา” ให้เปลี่ยนเป็น “ร่างจาก template ที่เคยใช้และเปรียบเทียบกับฉบับมาตรฐานของบริษัท”

2) ใช้ proxy แทนการตรวจแบบสมบูรณ์

จุดนี้สำคัญมาก เพราะงานหลายอย่างไม่มีทางตรวจแบบฟันธงได้ในทันที เขาใช้ตัวอย่าง “golden contracts” หรือสัญญาต้นแบบที่รู้ว่าใช้ได้ดี แล้วให้ agent เทียบว่าฉบับใหม่มีความใกล้เคียงแค่ไหน

ในบริษัทไทย เราอาจใช้แนวทางเดียวกันได้ เช่น

• ใช้ proposal ที่ปิดการขายได้จริงเป็นตัวอย่างอ้างอิง
• ใช้ FAQ ที่ผ่านทีมกฎหมายแล้วเป็นฐานให้ bot ตอบลูกค้า
• ใช้ playbook ฝ่ายขายที่ทีม top performer ใช้จริงเป็นเกณฑ์

3) ใส่ guardrails ให้ AI ขยับได้แค่บางพื้นที่

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

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

จุดที่เราเห็นด้วยกับคลิปนี้มากคือ หลายทีมคิดเรื่อง capability ก่อน governance ทั้งที่ในโลกธุรกิจจริง trust มักสำคัญกว่า demo ที่หวือหวา

Step 5: เพิ่ม “การควบคุม” ด้วยการออกแบบการร่วมงานใหม่

ถ้า trust คือการทำให้เรากล้าใช้ AI, control คือการทำให้เราส่งความรู้และวิจารณญาณของเราเข้าไปในงานได้ทันเวลา

Jacob อธิบายว่างานซับซ้อนของ agent มีลักษณะเหมือน tree หรือ DAG คือมีงานแตกแขนงเป็นหลายส่วน ไม่ใช่เส้นตรงเส้นเดียว ดังนั้นถ้าเรารอคุยกับ AI แค่ตอนเริ่ม กับตอนจบ เราจะคุมอะไรไม่ได้มาก

เขาแบ่งวิธีเพิ่ม control ไว้หลายแบบ ซึ่งมีประโยชน์มากสำหรับการออกแบบ workflow ในธุรกิจ

การวางแผนล่วงหน้า หรือ Planning

วิธีนี้คือให้ AI เสนอแผนก่อน แล้วคนค่อย approve แนวทาง ฟังดูดี เพราะช่วยให้เราตั้งทิศทางได้ตั้งแต่ต้น

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

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

การใช้ Skills เพื่อฝังวิธีคิดของคนเก่งลงไป

นี่เป็นส่วนที่น่าสนใจที่สุดในมุมธุรกิจ Skills ในที่นี้ไม่ใช่แค่ฟีเจอร์ของระบบ แต่คือการ encode วิธีทำงานของผู้เชี่ยวชาญลงไปในงานย่อย เช่น เวลาตรวจ clause ประเภทหนึ่ง ให้ตรวจด้วยเกณฑ์แบบนี้ ถ้าเจอกรณีพิเศษใน EU ให้ใช้กฎอีกแบบ

ถ้าแปลเป็นโลกธุรกิจไทย Skills อาจอยู่ในรูปแบบ

• เกณฑ์อนุมัติใบเสนอราคาของแต่ละกลุ่มลูกค้า
• แนวการตอบ complaint ตามระดับความรุนแรง
• วิธีเช็กความเสี่ยงคู่ค้าก่อนเซ็นสัญญา
• มาตรฐานการเขียนรายงานผู้บริหารของแต่ละแผนก

จุดนี้สะท้อนความจริงข้อหนึ่งว่า AI ที่ใช้ได้จริงในธุรกิจ ไม่ได้ชนะเพราะ model อย่างเดียว แต่ชนะเพราะเอา วิธีคิดขององค์กร ใส่เข้าไปได้มากแค่ไหน

การให้ AI ถามกลับเมื่อไม่แน่ใจ หรือ Elicitation

เมื่อไม่มี skill ครอบคลุมทุกสถานการณ์ AI ควรถามคนในจุดที่ไม่แน่ใจ แต่ Jacob เตือนชัดว่าอย่าให้มันถามแบบสุ่มไปเรื่อยๆ ในแชตยาวๆ เพราะคนจะตอบไม่ถูก ไม่มี context และสุดท้ายงานสะดุด

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

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

Step 6: เปลี่ยนจาก “คุยกับ AI” เป็น “ทำงานกับ AI บน artifact ที่จับต้องได้”

นี่คือข้อสรุปสำคัญที่สุดของคลิป: แชตเป็น input ที่ดี แต่ไม่ควรเป็นพื้นที่หลักในการร่วมงานกับ complex agent

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

Jacob เสนอว่ามนุษย์กับ agent ควรร่วมงานกันบน high-bandwidth artifacts ที่เป็นชิ้นงานถาวรและมีโครงสร้าง เช่น เอกสาร ตาราง หรือหน้าจอเฉพาะทางของแต่ละอุตสาหกรรม

ตัวอย่างจาก Legora คือการทำงานบนเอกสารโดยตรง เราสามารถ

• ไฮไลต์ clause ที่ต้องการแก้
• คอมเมนต์เฉพาะจุด
• tag agent หรือผู้ร่วมงาน
• ส่งงานบางส่วนให้ agent เฉพาะทาง

อีกตัวอย่างคือมุมมองแบบตารางสำหรับ review สัญญาหลายฉบับพร้อมกัน ระบบจะ flag จุดที่อยากให้คนตัดสินใจ เราเลยไม่ต้องไถแชตยาวๆ เพื่อหาว่า agent สงสัยอะไรบ้าง

ถ้าเอาหลักนี้มาใช้กับธุรกิจไทย หน้าตาของ AI ที่ดีอาจไม่ใช่ chatbot เสมอไป แต่อาจเป็น

• แดชบอร์ดสรุปงานขายที่ให้ AI ปักธงดีลเสี่ยง
• ตารางเปรียบเทียบ supplier พร้อมคอลัมน์ที่ AI ขอความเห็น
• หน้าร่างเอกสารที่แก้เฉพาะย่อหน้าได้
• CRM ที่ให้ AI ช่วยร่างข้อความติดตามลูกค้าในแต่ละ stage

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

Step 7: แปลแนวคิดนี้ให้เข้ากับธุรกิจไทยแบบไม่ต้องเป็น developer

ถ้าเราไม่ใช่สายเทคนิค สิ่งที่ควรเก็บจากแนวคิดนี้ไม่ใช่คำศัพท์อย่าง DAG หรือ sub-agent แต่คือวิธีคิดเรื่องการออกแบบงานร่วมกับ AI

หลักที่ใช้ได้จริงมีอยู่ 4 ข้อ

1. เริ่มจากงานที่ตรวจได้ก่อน อย่าเพิ่งเอา AI ไปตัดสินใจงานคลุมเครือ
2. อย่าปล่อยให้ AI ทำยาวโดยไม่มีจุดให้คนแทรก ต้องมี checkpoint
3. สร้างแม่แบบและเกณฑ์อ้างอิง เพื่อให้ AI ทำงานเทียบกับมาตรฐานเดิมขององค์กร
4. ถ้างานเป็นเอกสาร ตาราง หรือระบบงานเดิม ให้ AI ไปอยู่ตรงนั้น ไม่ใช่บีบทุกอย่างเข้าแชต

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

Step 8: Actionable Insights ที่หยิบไปทำได้เลย

• เลือก 3 งานที่ตรวจผลง่ายที่สุด เช่น สรุปเอกสาร เปรียบเทียบข้อมูล หรือเช็กความครบถ้วน แล้วเริ่มจากงานพวกนี้ก่อน
• สร้าง “golden examples” ขององค์กร เช่น proposal ที่ดีที่สุด, อีเมลตอบลูกค้ามาตรฐาน, สัญญาต้นแบบ เพื่อใช้เป็นฐานให้ AI อ้างอิง
• ออกแบบ checkpoint ให้คนอนุมัติเป็นช่วง อย่ารอเห็นผลงานตอนสุดท้าย โดยเฉพาะงานที่มีความเสี่ยง
• เปลี่ยนจาก chatbot ไปสู่หน้าจองานเฉพาะ ถ้างานเป็นตาราง เอกสาร หรือฟอร์ม ให้ AI ทำงานบนหน้าจอนั้นเลย
• บังคับให้มี decision log ทุกครั้งที่ AI ต้องเดาหรือตัดสินใจเอง เพื่อให้ตรวจย้อนหลังได้

Step 9: Troubleshooting เมื่อเริ่มใช้ AI Agent ในงานจริง

- ปัญหา: AI ทำงานยาวแล้วแก้จุดหนึ่ง แต่จุดอื่นพังตาม

- สาเหตุ: ใช้งานผ่านแชตยาวๆ จน context เริ่มหลุด และไม่มีการแก้แบบเฉพาะส่วน

- วิธีแก้: แยกงานเป็นส่วนย่อย ใช้เอกสารหรือตารางที่แก้เฉพาะจุดได้ และตั้ง checkpoint ก่อนรวมงานกลับ

- ปัญหา: คนในทีมต้องตรวจทุกอย่างจนรู้สึกว่าใช้ AI แล้วงานเพิ่ม

- สาเหตุ: งานที่เลือกให้ AI ทำยังตรวจยากเกินไป หรือไม่มีเกณฑ์เทียบที่ชัด

- วิธีแก้: เริ่มจากงานที่ verify ง่าย สร้าง template มาตรฐาน และให้ AI เทียบกับตัวอย่างที่ดีที่สุดของทีม

- ปัญหา: AI ถามกลับเยอะมากจน workflow สะดุด

- สาเหตุ: ไม่มี skill หรือกฎตัดสินใจสำหรับสถานการณ์ที่เจอบ่อย

- วิธีแก้: รวบรวมคำถามที่เกิดซ้ำ ทำเป็น playbook แล้วให้ AI ตัดสินใจชั่วคราวพร้อมบันทึก decision log

- ปัญหา: ผู้บริหารไม่กล้าปล่อยให้ AI แตะงานสำคัญ

- สาเหตุ: ไม่มี guardrails และไม่รู้ขอบเขตสิทธิ์ของ AI ชัดเจน

- วิธีแก้: จำกัดแหล่งข้อมูล จำกัดประเภทงานที่แก้ได้ และเริ่มจาก sandbox หรือข้อมูลที่เสี่ยงต่ำก่อน

- ปัญหา: ทีมบอกว่า AI ไม่เข้าใจวิธีทำงานของบริษัท

- สาเหตุ: ความรู้ขององค์กรยังอยู่ในหัวคนเก่ง ไม่ได้ถูกแปลงเป็นกฎ ตัวอย่าง หรือ workflow

- วิธีแก้: ดึงวิธีคิดของคนเก่งออกมาเป็น checklist, template และเกณฑ์รีวิว เพื่อเปลี่ยนเป็น skill ของระบบ

Step 10: การต่อยอดสำหรับองค์กรที่อยากไปไกลกว่า chatbot

• สร้าง AI workspace ตามแผนก เช่น ฝ่ายขาย ฝ่ายบุคคล ฝ่ายกฎหมาย โดยแต่ละส่วนมี artifact และเกณฑ์รีวิวของตัวเอง
• ทำ decision log เป็นคลังความรู้ ใช้คำตัดสินย้อนหลังมาฝึกทีมและปรับ workflow ให้รอบต่อไปถามน้อยลง
• ออกแบบ human-in-the-loop ตามระดับความเสี่ยง งานทั่วไปให้ AI เดินเองได้มาก งานมูลค่าสูงหรือเสี่ยงสูงให้มีชั้นอนุมัติเพิ่ม

Step 11: สรุป Checklist ทั้งหมด

• ☐ เลิกมองว่า AI agent ต้องอยู่ในแชตอย่างเดียว
• ☐ แยกให้ออกว่างานไหน “ทำได้” และ “ตรวจได้ง่าย”
• ☐ เริ่มจาก use case ที่ตรวจผลง่ายและเสี่ยงต่ำ
• ☐ สร้าง golden examples ขององค์กรให้ AI ใช้อ้างอิง
• ☐ ใส่ guardrails จำกัดขอบเขตที่ AI แตะได้
• ☐ ออกแบบ checkpoint ให้คนเข้าไปตัดสินใจระหว่างทาง
• ☐ แปลงวิธีคิดของคนเก่งเป็น skill, playbook หรือ checklist
• ☐ ให้ AI บันทึก decision log ทุกครั้งที่ตัดสินใจเอง
• ☐ ถ้างานเป็นเอกสารหรือตาราง ให้ AI ทำงานบน artifact นั้นโดยตรง
• ☐ วัดผลจากภาระการตรวจทานที่ลดลง ไม่ใช่แค่ว่า AI สร้าง output ได้เร็วขึ้น

สรุปแล้ว แก่นของคลิปนี้ไม่ใช่แค่เรื่อง UI หรือประสบการณ์ใช้งาน แต่คือการเตือนว่า ถ้าเราอยากใช้ AI agent ทำงานจริงในธุรกิจ เราต้องออกแบบการร่วมงานใหม่ทั้งระบบ งานที่ซับซ้อนต้องการทั้ง trust, control, มาตรฐานอ้างอิง และพื้นที่ทำงานที่เหมาะกับตัวงาน ไม่ใช่โยนทุกอย่างลงในกล่องแชตแล้วหวังว่ามันจะจัดการเองได้หมด

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