ก่อนให้ AI Agent เข้าถึงระบบจริง องค์กรต้องผ่าน 7 ด่านอะไรบ้าง

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

ด่านไหนยังไม่ผ่าน ให้ Agent อ่านได้อย่างเดียว

Chatbot ตอบคำถาม ส่วน Agent ลงมือทำงานในระบบ

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

AI Agent ต่างออกไปตรงที่ลงมือเองได้ แนวปฏิบัติการใช้ปัญญาประดิษฐ์อย่างมั่นคงปลอดภัย (AI Security Guidelines) ของ สกมช. ที่เผยแพร่เมื่อ 30 กันยายน 2568 นิยาม Agentic AI ว่าเป็น "ผู้กระทำ" ที่เชื่อมต่อและสั่งการระบบอื่นเพื่อทำภารกิจให้สำเร็จได้โดยอัตโนมัติ เมื่อ Agent เรียก API ได้ อ่านฐานข้อมูลได้ และสั่งงานระบบอื่นต่อได้ คำตอบที่ผิดจะไม่หยุดอยู่ที่หน้าจออีกต่อไป มันกลายเป็นรายการที่ถูกแก้ อีเมลที่ถูกส่ง หรือคำขอที่ถูกอนุมัติไปแล้ว

OWASP เรียกความเสี่ยงนี้ว่า Excessive Agency และจัดไว้เป็นข้อ LLM03 ใน OWASP Top 10 for LLM Applications 2026 โดยแยกต้นเหตุไว้สามอย่าง อย่างแรกคือ Agent เข้าถึงเครื่องมือเกินกว่างานที่ต้องใช้ อย่างที่สองคือได้สิทธิ์ในระบบปลายทางมากเกินไป อย่างที่สามคือทำงานที่มีผลกระทบสูงได้เองโดยไม่มีใครอนุมัติ ด่านทั้งเจ็ดด้านล่างคือการปิดสามช่องนี้ทีละชั้น และจำกัดความเสียหายเมื่อยังมีอะไรหลุดรอดไปได้

ด่านที่หนึ่ง Agent ต้องมีตัวตนของตัวเอง ไม่ยืมบัญชีคน

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

OWASP Top 10 for Agentic Applications 2026 ข้อ ASI03 (Identity and Privilege Abuse) อธิบายจุดนี้ไว้ว่า ถ้า Agent ไม่มี identity ของตัวเองที่มีการกำกับดูแล จะเกิดช่องว่างที่ระบุไม่ได้ว่าใครเป็นผู้กระทำ และการจำกัดสิทธิ์ตามหลัก least privilege จะทำไม่ได้จริง

คำถามทดสอบ: ถ้าวันนี้ต้องปิด Agent ตัวเดียวทันที คุณปิดได้โดยไม่กระทบบัญชีของคนหรือระบบอื่นหรือไม่

ขั้นต่ำก่อนผ่าน: Agent แต่ละตัวมีบัญชีหรือ workload identity แยกของตัวเอง มีเจ้าของที่ระบุตำแหน่งได้ และ credential ของมันอยู่ในบัญชีผู้ให้บริการคลาวด์ขององค์กรเอง เรื่องบัญชีคลาวด์ต้องอยู่ในมือองค์กร เราเคยเขียนไว้ใน เงื่อนไข TOR ที่ทำให้ระบบดูแลต่อได้ หลักเดียวกันใช้กับ identity ของ Agent ด้วย

ด่านที่สอง ให้สิทธิ์เท่าที่งานนั้นต้องใช้ และมีวันหมดอายุ

Agent ที่มีหน้าที่ร่างรายงานประจำเดือนจากข้อมูลในระบบ ERP ต้องการสิทธิ์อ่านตารางที่เกี่ยวข้อง มันไม่ต้องการสิทธิ์แก้ไขหรือลบ แต่เครื่องมือที่ต่อเข้าไปมักมาพร้อมความสามารถเกินกว่านั้น OWASP ยกตัวอย่างไว้ในข้อ LLM03 ว่า เครื่องมือที่ตั้งใจให้อ่านข้อมูลอย่างเดียว กลับเชื่อมต่อฐานข้อมูลด้วย identity ที่มีสิทธิ์ UPDATE, INSERT และ DELETE ด้วย

ด่านนี้ตรวจด้วยคำถามสามข้อ Agent เรียกได้เฉพาะเครื่องมือที่งานต้องใช้หรือไม่ เครื่องมือแต่ละตัวทำได้เฉพาะฟังก์ชันที่จำเป็นหรือไม่ และสิทธิ์ในระบบปลายทางแยกการอ่านออกจากการเขียนหรือไม่ ใน checklist ของ สกมช. ข้อ DSG-07 ให้จำกัดขอบเขตการดำเนินการ (Action Space) ของ Agentic AI ตามหลักสิทธิ์น้อยที่สุด และข้อ DEP-03 ให้กำหนด IAM Roles ใน Production ตามหลักเดียวกัน

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

ด่านที่สาม กำหนดให้ชัดว่า Agent เห็นข้อมูลชั้นไหนได้

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

คำถามทดสอบของด่านนี้คือ องค์กรมีการจัดชั้นข้อมูล (data classification) ที่ใช้งานได้จริงหรือยัง ถ้ายังไม่มี คุณจะตอบไม่ได้ว่า Agent ควรเห็นตารางไหน และข้อมูลที่ Agent ส่งออกไปนอกองค์กรมีอะไรบ้าง ในทางปฏิบัติ เราแนะนำให้เริ่มจากรายการตารางหรือโฟลเดอร์ที่ Agent เข้าถึงได้แบบ allowlist แทนการไล่ปิดทีละจุด

ถ้าข้อมูลที่ Agent เข้าถึงมีข้อมูลส่วนบุคคล คำถามว่าต้องทำอะไรตาม PDPA ควรให้ฝ่ายกฎหมายหรือเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ขององค์กรเป็นผู้ตอบ โดยอ้างอิงแนวทางของสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) บทความนี้ไม่ได้ให้คำแนะนำทางกฎหมาย

ด่านที่สี่ ทุก API ที่ Agent เรียกต้องมีประตูของตัวเอง

API ภายในหลายตัวถูกออกแบบโดยคิดว่าคนเรียกคือระบบที่ทีมเขียนเอง จึงไม่มีการจำกัดจำนวนครั้ง และไม่ได้ตรวจค่าที่ส่งเข้ามาอย่างเข้มงวด Agent เปลี่ยนสมมติฐานนั้น เพราะค่าที่ Agent ส่งไปมาจากการตีความข้อความ และข้อความนั้นอาจมาจากอีเมลหรือเอกสารภายนอกที่มีคำสั่งแฝงอยู่ (prompt injection)

checklist ของ สกมช. ข้อ DSG-06 กำหนดให้ API ทุกตัวมีค่าเริ่มต้นที่ปลอดภัย เช่น บังคับ Authentication และ Rate Limiting ส่วน OWASP แนะนำหลัก complete mediation คือให้การตรวจสิทธิ์อยู่ในตรรกะของระบบ และไม่ปล่อยให้ LLM เป็นผู้ตัดสินว่าคำสั่งนั้นทำได้หรือไม่

ระบบเก่าที่ไม่มีชั้น API เลยเป็นกรณีที่ยากที่สุด การให้ Agent เข้าฐานข้อมูลของระบบเก่าตรง ๆ คือการข้ามด่านนี้ทั้งด่าน ถ้าองค์กรกำลังชั่งว่าจะปรับระบบเก่าอย่างไร ควรนับเรื่องนี้เข้าไปในการตัดสินใจ ระหว่าง rewrite กับ refactor ด้วย

ด่านที่ห้า ย้อนดูได้ว่า Agent ทำอะไร ในนามใคร

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

สกมช. กำหนดไว้ในข้อ OPS-06 ให้มีระบบเฝ้าระวังและบันทึก log การดำเนินการ (Actions) ทั้งหมดที่ Agentic AI ทำโดยอัตโนมัติ เพื่อการตรวจสอบย้อนหลัง และข้อ OPS-02 ให้เก็บ log ไว้ในระบบที่ปลอดภัยและตรวจสอบได้

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

อีกเรื่องที่ต้องคิดคือ log ของ Agent มักมีข้อมูลละเอียดอ่อนติดมาด้วย เพราะมันเก็บ prompt และข้อมูลที่ Agent อ่าน สิทธิ์เข้าถึง log จึงต้องจำกัดเข้มพอ ๆ กับตัวข้อมูลเอง

ด่านที่หก เห็นความผิดปกติขณะเกิด และรู้ว่าใครมีสิทธิ์สั่งหยุด

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

OWASP แนะนำให้ตั้งเกณฑ์จำนวนการเรียกเครื่องมือ และมี circuit breaker ที่หยุด จำกัดความเร็ว หรือส่งเรื่องให้คนตรวจเมื่อเกินเกณฑ์ ส่วนเอกสารของ สกมช. ยกตัวอย่างการกักกันเหตุการณ์ของ Agentic AI ว่าให้เพิกถอน API Keys และระงับสิทธิ์การเข้าถึงระบบอื่นของ Agent ทันที

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

ด่านที่เจ็ด แบ่งให้ชัดว่างานไหน Agent ทำเองได้ งานไหนต้องมีคนอนุมัติ

Human-in-the-loop ที่ใช้ได้จริงไม่ได้แปลว่าให้คนกดอนุมัติทุกขั้นตอน ถ้าทุกอย่างต้องรอคน Agent ก็เป็นแค่แบบฟอร์มที่ช้าลง และเมื่อต้องอนุมัติทุกรายการ การอนุมัติจะค่อย ๆ กลายเป็นการกดผ่านตามความเคยชิน

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

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

วางทั้ง 7 ด่านไว้ตรงไหนในสถาปัตยกรรม

ด่านทั้งหมดข้างต้นไม่ควรไปอยู่ใน prompt ของ Agent การเขียนใน prompt ว่า "ห้ามลบข้อมูล" เป็นเพียงคำขอ และ prompt injection เขียนทับคำขอนั้นได้ การควบคุมจริงต้องอยู่ในส่วนที่ Agent แก้เองไม่ได้

รูปแบบที่เราแนะนำคือวางชั้นกลางระหว่าง Agent กับระบบจริง อาจเป็น API gateway ที่องค์กรมีอยู่แล้ว หรือบริการที่สร้างขึ้นเฉพาะก็ได้ ทุกคำสั่งของ Agent ต้องผ่านชั้นนี้ ซึ่งทำหน้าที่ยืนยัน identity ของ Agent ตามด่านที่หนึ่ง ตรวจสิทธิ์และขอบเขตข้อมูลตามด่านที่สองและสาม บังคับ rate limit และตรวจ input ตามด่านที่สี่ เขียน audit log ตามด่านที่ห้า ส่งสัญญาณให้ระบบ monitoring และรับคำสั่งหยุดตามด่านที่หก และพักคำสั่งที่ต้องรอคนอนุมัติตามด่านที่เจ็ด ส่วนที่ตรวจสิทธิ์ของชั้นนี้ OWASP เรียกว่า independent pre-execution policy decision point

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

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

ข้อโต้แย้งที่ได้ยินบ่อย: แพลตฟอร์ม AI มี guardrail ในตัวอยู่แล้ว

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

ถ้าวันหนึ่งองค์กรเปลี่ยนแพลตฟอร์ม guardrail ทั้งหมดก็หายไปพร้อมกัน ด่านที่อยู่ฝั่งระบบขององค์กรเองจึงเป็นส่วนที่องค์กรควบคุมได้จริง

เขียน 7 ด่านลง TOR และเงื่อนไขกับ vendor

ถ้า Agent มาจาก vendor หรือสร้างโดยผู้พัฒนาภายนอก ด่านทั้งเจ็ดจะมีผลจริงก็ต่อเมื่ออยู่ในเอกสารที่ผูกพันผู้ส่งมอบ ถ้าไปเพิ่มตอนตรวจรับงาน มักช้าเกินไป เพราะ architecture ถูกวางไปแล้ว

สิ่งที่ควรระบุใน TOR อย่างน้อยมีห้าเรื่อง Agent แต่ละตัวต้องมี identity แยกและอยู่ในบัญชีคลาวด์ขององค์กร ผู้ส่งมอบต้องส่งรายการเครื่องมือและสิทธิ์ที่ Agent ใช้ พร้อมเหตุผลของแต่ละสิทธิ์ ต้องมี audit log ที่บอกได้ว่า Agent ทำอะไรในนามใคร โดยองค์กรเข้าถึง log ได้เอง ทีมภายในต้องสั่งหยุด Agent ได้โดยไม่ต้องรอผู้พัฒนา และตารางที่แยกว่างานไหนอนุมัติอัตโนมัติ งานไหนต้องมีคนอนุมัติ ต้องอยู่ในรายการส่งมอบ เรื่องบัญชีคลาวด์ใช้หลักเดียวกับเงื่อนไข TOR ที่อ้างถึงในด่านที่หนึ่ง

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

ถ้ายังผ่านไม่ครบ จะเริ่มตรงไหน

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

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

---

สรุป

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

ตอนนำเรื่องเข้าขออนุมัติ หลักฐานที่ช่วยให้กรรมการตัดสินใจได้คือตารางสั้น ๆ ที่บอกสถานะของแต่ละด่านว่าผ่านแล้วหรือยัง พร้อมชื่อตำแหน่งที่เป็นเจ้าของแต่ละด่าน และตารางงานที่แยกว่างานไหน Agent ทำเองได้ ถ้าอ้างรหัสข้อใน checklist ของ สกมช. ประกอบ เช่น DSG-07 หรือ OPS-06 กรรมการจะเห็นว่าเกณฑ์ไม่ได้มาจากความเห็นของทีมเพียงฝ่ายเดียว

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส