ตรวจรับระบบที่ทีมพัฒนาใช้ AI เขียนโค้ด: เขียนอะไรลง TOR และขอหลักฐานอะไรตอนส่งมอบ

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

ตรวจรับจากระบบและหลักฐาน ไม่ต้องไล่หาผู้เขียน

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

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

ตัวเลขที่เราเปิดอ่านจากต้นฉบับ และตัวเลขที่ยืนยันไม่ได้

ก่อนอ้างตัวเลขใด เราเปิดหน้าต้นฉบับของผู้เผยแพร่แต่ละรายอ่านเอง ผลที่ได้มีดังนี้

• Software Improvement Group (SIG) ระบุในข่าวประกาศรายงาน State of Software 2026 ลงวันที่ 9 มิถุนายน 2026 ว่าจากการทดสอบของ SIG โค้ดที่ AI สร้างมีการละเมิดด้านความเสี่ยงความปลอดภัยประมาณสองเท่าของโค้ดที่คนเขียน ข่าวประกาศเดียวกันระบุว่า benchmark ของ SIG ครอบคลุมมากกว่า 30,000 ระบบ และบอกว่าโค้ดที่ AI สร้างคิดเป็น 1.9% ของโค้ด production ในองค์กร เราอ่านเฉพาะข่าวประกาศ ไม่ได้เปิดรายงานฉบับเต็ม จึงยืนยันไม่ได้ว่าตัวเลขสองเท่ามาจากตัวอย่างขนาดเท่าใด

• Veracode ระบุในข่าวประกาศ GenAI Code Security Report ลงวันที่ 30 กรกฎาคม 2025 ว่าทดสอบโมเดลภาษามากกว่า 100 ตัวกับโจทย์เขียนโค้ด 80 ข้อ และโค้ดที่ได้มีช่องโหว่ใน 45% ของกรณี ประชากรของตัวเลขนี้คือโจทย์ทดสอบที่ Veracode คัดมา ไม่ใช่ระบบที่ใช้งานอยู่จริง

• Veracode เผยแพร่ผลรอบถัดมาในบล็อก 2026 GenAI Code Security Report ลงวันที่ 28 กรกฎาคม 2026 ว่าราว 44% ของงานสร้างโค้ดในการทดสอบทำให้เกิดช่องโหว่ที่เสี่ยง และคะแนนผ่านด้านความปลอดภัยเฉลี่ยของโมเดลอยู่ที่ 56% เทียบกับ 55% ในรายงานฉบับแรก หน้านี้ไม่ระบุจำนวนโมเดลที่ทดสอบและไม่อธิบายวิธีให้คะแนน เราจึงใช้ตัวเลขนี้เป็นสัญญาณแนวโน้มเท่านั้น

• CloudBees เผยแพร่ผลสำรวจ State of Code Abundance เมื่อ 19 พฤษภาคม 2026 ในข่าวประกาศ Enterprise technology leaders report production failures from AI-generated code ผู้ตอบ 213 คนที่เป็นผู้นำด้านเทคโนโลยีขององค์กร (ความคลาดเคลื่อนบวกลบ 8% ที่ความเชื่อมั่น 95%) 81% รายงานว่าเคยเจอ production failure ที่เกี่ยวกับโค้ดที่ AI สร้าง และ 12% มีหน่วยงานกำกับดูแลเรื่องนี้โดยเฉพาะ ตัวเลขทั้งสองมาจากคำตอบของผู้ตอบเอง

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

ตัวเลขสองตัวของ SIG ต้องอ่านคู่กัน

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

เงื่อนไขที่ควรอยู่ใน TOR และสัญญา

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

การเปิดเผยการใช้เครื่องมือ AI

ให้ผู้พัฒนาแจ้งเป็นลายลักษณ์อักษรว่าใช้เครื่องมือ AI ตัวใด สำหรับงานประเภทไหน (เขียนโค้ด เขียน test หรือเขียนเอกสาร) และแจ้งใหม่เมื่อเปลี่ยนเครื่องมือระหว่างโครงการ ระดับที่ตรวจสอบได้คือรายโครงการ ไม่ใช่รายบรรทัด ควรกำหนดด้วยว่าห้ามส่ง source code ของคุณ ข้อมูลส่วนบุคคล หรือ secret เข้าเครื่องมือที่ไม่ได้ตกลงกันไว้ ข้อนี้เกี่ยวกับ การรั่วของ secret ใน repo และ pipeline โดยตรง

ข้อกำหนดเรื่อง review

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

ใครรับผิดชอบการแก้ช่องโหว่หลังส่งมอบ

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

หลักฐานที่ควรขอตอนส่งมอบ

รายการนี้ครอบคลุมประเด็นหลักที่เรามองว่าตรวจรับได้จริง เราไม่ได้อ้างว่าครบทุกกรณี และควรปรับตามระบบของคุณ

• รายการ dependency ชื่อ เวอร์ชัน และ license ของไลบรารีทุกตัวที่ระบบใช้ พร้อมไฟล์ lockfile จาก repository AI มักแนะนำไลบรารีที่ทีมไม่ได้เลือกเอง รายการนี้จึงเป็นที่เดียวที่เห็นว่าระบบพึ่งพาอะไรอยู่ วิธีใช้รายการนี้ตรวจว่ากระทบกับข่าวช่องโหว่ใหม่หรือไม่ อธิบายไว้ใน บทความเรื่อง npm supply chain และ SBOM

• ผลทดสอบ รายงานการรัน unit test และ integration test พร้อมระบุว่า test ครอบคลุมอะไรและไม่ครอบคลุมอะไร จุดที่ควรระวังคือ test ที่ AI เขียนให้ผ่านโค้ดที่ AI เขียน อาจผ่านทั้งที่พฤติกรรมผิดความต้องการ จึงควรให้ฝ่ายธุรกิจของคุณเขียนกรณีทดสอบตาม TOR เองอย่างน้อยกลุ่มหนึ่ง แล้วรันบนสภาพแวดล้อมของคุณ

• ผลสแกนความปลอดภัยฉบับดิบ ขอไฟล์ผลลัพธ์จริงจากเครื่องมือสแกนโค้ด (SAST) และสแกน dependency ไม่ใช่สไลด์สรุป ไฟล์ต้องระบุ commit ที่สแกน วันที่ และค่าที่ตั้งไว้ รวมถึงรายการข้อพบที่ยังเปิดอยู่ พร้อมผู้รับผิดชอบและกำหนดแก้

• บันทึก review รายการ pull request ที่เข้า branch หลัก ผู้ทบทวนแต่ละรายการ และรายการที่ merge โดยไม่มีผู้ทบทวน ข้อมูลนี้ดึงจากระบบ repository ได้โดยไม่ต้องให้ทีมเขียนใหม่

• ผลตรวจหา secret ผลสแกนทั้งประวัติ git ไม่ใช่เฉพาะไฟล์ปัจจุบัน และหลักฐานว่า secret ที่เคยหลุดถูกหมุนเปลี่ยนแล้ว

• การ build จาก repository ของคุณ ให้ทีมภายในหรือบุคคลที่สามสร้างระบบจาก source ที่ส่งมอบในบัญชีขององค์กรเอง ถ้าทำไม่ได้โดยไม่พึ่งผู้พัฒนา แปลว่าการส่งมอบยังไม่เสร็จ ประเด็นนี้ตรงกับเรื่องความต่อเนื่องของผู้พัฒนาใน ก่อนจ้างพัฒนาระบบ ประเมินความเสี่ยงที่ vendor จะหายไป

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

การทดสอบเจาะระบบและการส่งมอบ

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

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

ลำดับที่เราแนะนำคือ ผู้พัฒนาส่งหลักฐานตามรายการข้างต้น ทีมของคุณสุ่มรันซ้ำบางรายการ ผู้ทดสอบอิสระทำ penetration test ผู้พัฒนาแก้และ retest แล้วจึงลงนามรับ ถ้าระบบที่ส่งมอบมีส่วนที่เรียกใช้ MCP server หรือเครื่องมือ AI ภายในตัวผลิตภัณฑ์เอง นั่นเป็นโจทย์แยกอีกชุดที่ต้องดูสถาปัตยกรรมความปลอดภัยของส่วนนั้น ดู บทความเรื่องสถาปัตยกรรมความปลอดภัยของ MCP server

กรณีที่ไม่ต้องทำครบชุดนี้

ข้อเสียที่ต้องบอกก่อนคือ การขอหลักฐานครบชุดทำให้ช่วงปิดโครงการยาวขึ้น และทีมพัฒนาต้องเตรียมเอกสารเพิ่ม ถ้าระบบของคุณเป็นเครื่องมือภายในที่มีผู้ใช้ไม่กี่สิบคน ไม่มีข้อมูลส่วนบุคคล ไม่เปิดสู่อินเทอร์เน็ต และเลิกใช้ได้โดยไม่กระทบงานหลัก การจ้าง penetration test และเก็บบันทึก review ย้อนหลังอาจเกินความจำเป็น ในกรณีนั้นเราแนะนำให้ขอสามอย่างพอ คือ รายการ dependency ผลสแกนฉบับดิบ และการ build ซ้ำได้จาก repository ของคุณ ความเข้มของการตรวจรับควรตามความเสียหายที่เกิดขึ้นได้ ไม่ได้ตามจำนวนช่องในแบบฟอร์ม

สิ่งที่ควรเก็บไว้

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

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