บทนำ
AI รุ่นแรกที่องค์กรใช้กันจำนวนมากมีบทบาทคล้ายผู้ช่วย สรุปเอกสาร ร่างข้อความ วิเคราะห์ข้อมูล หรือเสนอทางเลือก
แต่เมื่อเข้าสู่ยุค Agentic AI ระบบอาจไม่ได้หยุดหลังจากเสนอคำตอบ เพราะสามารถวางแผน เรียกใช้เครื่องมือ เชื่อมต่อระบบ และดำเนินการบางอย่างต่อได้เอง
คู่มือฉบับปรับปรุงของ ก.ล.ต. นิยาม Agentic AI ไว้ในฐานะ AI ขั้นสูงที่สามารถรับรู้ ใช้เหตุผล วางแผน และดำเนินการอย่างเป็นอิสระ โดยใช้เครื่องมือและความรู้ตามบริบทต่าง ๆ และยังแยกบทบาทของผู้เกี่ยวข้องออกเป็น Developer, Customizer และ User อย่างชัดเจน
ตรงนี้ทำให้โจทย์ด้าน governance เปลี่ยนทันที
“เมื่อ AI เปลี่ยนจาก ‘ตอบแทนคน’ ไปเป็น ‘ลงมือแทนคน’ Governance ต้องเปลี่ยนจากการควบคุมคำตอบ ไปสู่การควบคุมอำนาจของระบบ”
สิ่งที่เปลี่ยนในกรอบ AI Governance ฉบับนี้
จากหลักการ สู่ Think → Record → Act
โครงสร้างหลักของคู่มือประกอบด้วย Governance, Principles, Risk Management, AIMS Controls และ Enablers แต่สิ่งที่ช่วยให้กรอบนี้ลงสู่การปฏิบัติได้ชัดขึ้นคือกลไก Think → Record → Act
Think คือ การพิจารณา use case และประเมินความเสี่ยง
Record คือ การบันทึกเหตุผลและข้อมูลไว้ใน AI Inventory
Act คือ การเลือกมาตรการควบคุมให้เหมาะกับบทบาทและระดับความเสี่ยง
แนวทางนี้ทำให้ AI Governance ไม่ควรจบอยู่ที่การมี AI Policy หนึ่งฉบับ แต่ต้องสามารถเชื่อมการตัดสินใจไปถึงหลักฐานและมาตรการควบคุมได้
Agentic AI ทำให้ “ระดับอำนาจ” กลายเป็นความเสี่ยง
คู่มือไม่ได้เพียงให้นิยาม Agentic AI แต่ในตัวอย่างระบบ Automated Trading Support ยังลงรายละเอียดถึงเรื่อง action space, autonomy, reversibility, read/write/execute access และผลกระทบที่อาจขยายวงออกไป
ตัวอย่างมาตรการสำหรับระบบลักษณะนี้รวมถึงการกำหนดผู้มีอำนาจ approve, override, suspend และ rollback ตลอดจนการกำหนด kill-switch authority และจำกัดสิทธิของ agent ตามหลัก least privilege
กล่าวง่าย ๆ คือ ยิ่ง AI สามารถ “ทำ” ได้มาก ความเสี่ยงก็ไม่ควรวัดจากความฉลาดของโมเดลเพียงอย่างเดียว แต่ต้องดูด้วยว่า มันแตะอะไรได้ และเมื่อผิดพลาดมนุษย์ย้อนกลับได้หรือไม่
Developer – Customizer – User ทำให้คำถามเรื่องความรับผิดละเอียดขึ้น
คู่มือแบ่งบทบาทสำคัญอย่างน้อย 3 กลุ่ม
- Developer รับผิดชอบส่วนสำคัญของการออกแบบ พัฒนา ทดสอบ หรือควบคุมโมเดลและระบบ
- Customizer ไม่ได้สร้างโมเดลหลักเอง แต่สามารถนำระบบที่มีอยู่มาปรับค่า เชื่อม workflow หรือกำหนดพฤติกรรมและระดับความเป็นอิสระของ AI ได้
- User คือผู้ที่นำ AI ไปใช้จริงในกระบวนการขององค์กร
ประเด็นนี้มีนัยต่อการทำสัญญาและการแบ่งความรับผิดอย่างมาก เพราะองค์กรที่ซื้อ foundation model จากผู้ให้บริการภายนอก อาจไม่ได้เป็น Developer แต่หากนำมาเชื่อมฐานข้อมูล เชื่อม API สร้าง agent และกำหนดว่า agent ทำอะไรแทนพนักงานได้ องค์กรอาจกำลังมีบทบาทในฐานะ Customizer อย่างมีนัยสำคัญ
ดังนั้นคำถามในสัญญา AI จึงไม่ควรหยุดที่ “ใครเป็นเจ้าของเทคโนโลยี” แต่ควรถามต่อว่า ใครควบคุมโมเดล ใครกำหนด workflow ใครกำหนด autonomy ใครอนุมัติการใช้งาน และใครนำผลลัพธ์ไปสร้างผลทางธุรกิจจริง
การมี Autonomy สูง ใน AI หมายถึง ระบบปัญญาประดิษฐ์ที่มีความสามารถในการตัดสินใจ วางแผน และลงมือทำงานต่างๆ ได้ด้วยตัวเองอย่างอิสระ โดยแทบไม่ต้องพึ่งพาการสั่งการหรือการควบคุมจากมนุษย์ ระบบจะได้รับเพียงเป้าหมายปลายทาง จากนั้นมันจะคิดหาวิธีการ แก้ไขปัญหาเฉพาะหน้า และปรับตัวตามสถานการณ์ที่เปลี่ยนแปลงไปได้เองอย่างสมบูรณ์
AI Inventory ไม่ใช่ทะเบียน Software
กรอบใหม่นำเสนอ AI Inventory ในฐานะ decision-anchored register หรือทะเบียนที่ผูกกับการตัดสินใจ ไม่ใช่เพียงรายการว่าองค์กรซื้อ software อะไรมาบ้าง
ข้อมูลระดับภาพรวมควรช่วยตอบได้ว่า use case คืออะไร ใครเป็น Business Owner กระทบลูกค้าหรือผู้ลงทุนหรือไม่ AI มีอิทธิพลต่อการตัดสินใจระดับใด ความเสี่ยงอยู่ระดับไหน และระบบอยู่ในสถานะทดลอง ใช้งานจริง หรือเลิกใช้แล้ว
“AI Inventory ที่ดีไม่ได้ตอบแค่ว่า ‘เรามี AI อะไร’ แต่ต้องตอบต่อได้ว่า ‘AI ตัวนี้มีอำนาจอะไร ใครรับผิด และถ้าต้องหยุดวันนี้เราจะหยุดตรงไหน’”
PDPA ถูกนำเข้าไปอยู่ใน data flow ของ AI
อีกส่วนที่มีนัยสำคัญคือคู่มือเชื่อม Data Governance และ PDPA เข้ากับ AI use case โดยตรง
ตัวอย่างประเด็นที่คู่มือให้พิจารณารวมถึงการวิเคราะห์ฐานกฎหมายตาม PDPA สำหรับแต่ละ use case, การพิจารณาว่า prompt, input, output และ log อาจเป็นข้อมูลส่วนบุคคลหรือไม่ การกำหนด retention policy การรองรับสิทธิของเจ้าของข้อมูล และข้อจำกัดทางเทคนิคในการลบข้อมูลออกจากโมเดลที่ผ่านการฝึกแล้ว หรือ machine unlearning
ผลคือ PDPA Team กับ AI Team ไม่ควรถูกออกแบบให้เป็นสองเส้นงานที่ไม่พบกัน
โครงสร้างที่สมเหตุสมผลกว่าคือ
AI Use Case → Data Flow → Privacy/PDPA Assessment → Controls → Evidence
“Minimum Evidence Set” ทำให้คำว่า Governance เริ่มประเมินได้
ในส่วนคำถามที่พบบ่อย คู่มือพูดถึงแนวคิด minimum evidence set โดยให้องค์กรมีเอกสารหรือหลักฐานขั้นต่ำที่สัมพันธ์กับระดับความเสี่ยง วัตถุประสงค์ และผลกระทบของ AI ไม่ใช่กำหนดให้ทุก use case ต้องมีเอกสารจำนวนเท่ากัน
หลักคิดนี้สำคัญ เพราะช่วยแก้ปัญหาสองด้านพร้อมกัน
ด้านหนึ่ง องค์กรไม่ควรทำ governance หนักเกินจำเป็นกับ AI ที่มีความเสี่ยงต่ำ อีกด้านหนึ่ง ระบบที่มีผลต่อสิทธิ ลูกค้า การเงิน การตัดสินใจสำคัญ หรือมี autonomy สูง ย่อมต้องมีการประเมิน การอนุมัติ การติดตาม และหลักฐานที่ละเอียดกว่า
การมี Autonomy สูง หมายถึง ระบบปัญญาประดิษฐ์ ที่มีความสามารถในการตัดสินใจ วางแผน และลงมือทำงานต่างๆ ได้ด้วยตัวเองอย่างอิสระ โดยแทบไม่ต้องพึ่งพาการสั่งการหรือการควบคุมจากมนุษย์ ระบบจะได้รับเพียงเป้าหมายปลายทาง จากนั้นมันจะคิดหาวิธีการ แก้ไขปัญหาเฉพาะหน้า และปรับตัวตามสถานการณ์ที่เปลี่ยนแปลงไปได้เองอย่างสมบูรณ์นี่คือการนำเอา การบริหารความเสี่ยงเป็นหลัก ร่วมกับ หลักความได้สัดส่วน มาใช้กับงานจริง แทนการทำเอกสารชุดเดียวบังคับใช้กับ AI ทุกตัว
AI-washing เปลี่ยนคำโฆษณาให้กลายเป็น Governance Risk
กรอบนี้ยังให้ความสำคัญกับ AI-washing ซึ่งหมายถึง การกล่าวถึงการใช้ AI ในลักษณะเกินจริง คลุมเครือ ไม่ครบถ้วน หรืออาจทำให้ผู้รับสารเข้าใจผิดเกี่ยวกับความสามารถ ระดับการใช้งานจริง ประสิทธิภาพ หรือผลลัพธ์ของระบบ
ในทางกลับกัน การเปิดเผยที่เหมาะสมควรบอกบทบาท ขอบเขต ข้อจำกัด และความเสี่ยงตามข้อเท็จจริง พร้อมมีหลักฐานรองรับ
สำหรับฝ่าย Legal และ Marketing นี่อาจหมายถึงการเริ่มปฏิบัติต่อคำว่า
AI-powered / AI-driven / Autonomous
ในลักษณะคล้ายการตรวจ Green Claims หรือ ESG Claims มากขึ้น กล่าวคือ ก่อนเผยแพร่ต้องถามว่า “พิสูจน์ได้หรือไม่”
Vendor Risk ไม่ได้จบที่ SLA
ก.ล.ต. ยังยกระดับความเสี่ยงจากบุคคลที่สามและการกระจุกตัวของผู้ให้บริการ โดยเสนอให้ due diligence ครอบคลุมเรื่อง model/data lineage, cybersecurity, subcontracting, incident notification, audit rights, portability และ exit plan
คู่มือยังชี้ให้ประเมินด้วยว่าองค์กรพึ่ง cloud หรือ foundation model รายเดียวในหลายกระบวนการสำคัญหรือไม่ และสำหรับ use case สำคัญควรมีแผนสำรอง การย้ายระบบ หรือวิธีลดการพึ่งพาผู้ให้บริการเพียงรายเดียว
ผลกระทบต่อธุรกิจในประเทศไทย
จุดที่ต้องอ่านอย่างระมัดระวังคือ กรอบฉบับนี้ถูกจัดทำขึ้นสำหรับบริบทของภาคตลาดทุน จึงไม่ควรตีความว่าทุกบริษัทในประเทศไทยถูก ก.ล.ต. กำหนดให้ต้องปฏิบัติตามกรอบนี้โดยอัตโนมัติ
แต่สิ่งที่ธุรกิจทั่วไปไม่ควรมองข้ามคือ โครงสร้างความเสี่ยงที่กรอบนี้กำลังทำให้เห็น
หากบริษัทใช้ AI เพียงช่วยพนักงานร่างอีเมล ความเสี่ยงอาจอยู่ระดับหนึ่ง แต่เมื่อบริษัทนำ AI ตัวเดิมไปเชื่อม CRM ให้ดึงข้อมูลลูกค้า เชื่อมระบบอนุมัติส่วนลด เชื่อมระบบจัดซื้อ หรือให้ agent เรียก API เพื่อดำเนินงานหลายขั้นตอน ความเสี่ยงได้เปลี่ยนประเภทแล้ว แม้ชื่อผลิตภัณฑ์ AI จะยังเป็นชื่อเดิม
นี่ทำให้ฝ่าย IT ไม่สามารถรับผิดชอบ AI Governance ฝ่ายเดียวได้ เพราะการตัดสินใจหนึ่งเรื่องอาจเชื่อมพร้อมกันทั้ง PDPA, cybersecurity, contract, IP, consumer protection, employment, marketing claims และ operational risk
สำหรับ Legal คำถามสำคัญจะเปลี่ยนจาก “สัญญากับ AI Vendor มี DPA หรือไม่” ไปสู่เรื่องสิทธิในการ audit การเปลี่ยนโมเดล การใช้ subcontractor การแจ้ง incident ความสามารถในการย้ายข้อมูล และ exit strategy
สำหรับ DPO การประเมิน AI จะต้องตาม data flow ไปถึง prompt, output, log, RAG, API และระบบที่ agent เชื่อมต่อ เพราะข้อมูลส่วนบุคคลอาจไม่ได้อยู่เฉพาะในฐานข้อมูลต้นทางอีกต่อไป
สำหรับ Marketing คำว่า AI ไม่ใช่เพียงศัพท์ขายสินค้าอีกแล้ว หากองค์กรกล่าวว่าเทคโนโลยี “ฉลาดกว่า แม่นยำกว่า อัตโนมัติเต็มรูปแบบ” แต่ไม่มีหลักฐานพิสูจน์ คำเหล่านี้สามารถสร้างทั้งความเสี่ยงด้านความน่าเชื่อถือ การเปิดเผยข้อมูล และข้อพิพาทกับลูกค้าได้
สำหรับ Procurement และฝ่ายบริหาร Vendor Risk จุดสำคัญไม่ใช่แค่ผู้ให้บริการมี ISO หรือ uptime เท่าใด แต่ต้องรู้ด้วยว่า หาก provider เปลี่ยนโมเดล ปิด API เปลี่ยนราคา หยุดให้บริการ หรือเกิด outage พร้อมกันหลายระบบ ธุรกิจจะทำงานต่อได้หรือไม่
และสำหรับคณะกรรมการหรือผู้บริหารระดับสูง คำถามสุดท้ายจะย้อนกลับมาที่ Accountability
หาก AI ทำสิ่งที่ไม่ควรทำ ผู้บริหารควรสามารถตอบได้ว่า ใครเสนอ use case นี้ ใครประเมินความเสี่ยง ใครอนุมัติ AI ได้รับสิทธิ์อะไร ใครเฝ้าติดตาม
ใครมีสิทธิ์หยุด และองค์กรมีหลักฐานอะไรยืนยันคำตอบเหล่านั้น
นี่คือเหตุผลที่ Tech Law Now มองว่าแก่นของกรอบฉบับนี้ไม่ใช่ “ต้องมีเอกสาร AI เพิ่มอีกกี่ฉบับ” แต่คือการสร้าง สายความรับผิดตั้งแต่การตัดสินใจ → ระบบ → ข้อมูล → การกระทำ → หลักฐาน และเมื่อ AI เริ่มมี มากขึ้น สายความรับผิดนี้ยิ่งต้องชัดกว่าเดิม
สิ่งที่ควรทำต่อ
- เริ่มจาก AI Inventory ก่อนซื้อเครื่องมือ Governance เพิ่ม สำรวจว่าองค์กรมี AI use case อะไร ใครเป็นเจ้าของ ใช้ข้อมูลอะไร เชื่อมระบบใด ใช้ provider ใด และ AI มีอิทธิพลต่อการตัดสินใจหรือการลงมือทำระดับไหน
- แยกบทบาท Developer / Customizer / User ในแต่ละ use case โดยเฉพาะระบบที่องค์กรไม่ได้สร้างโมเดลเอง แต่มีการทำ RAG, prompt orchestration, workflow automation, API integration หรือสร้าง AI Agent เพราะระดับความรับผิดอาจไม่เหมือนการเป็นผู้ใช้ SaaS ธรรมดา
- เพิ่ม Agent Permission Review สำหรับระบบที่ลงมือทำได้ ระบุให้ชัดว่า agent อ่าน เขียน ส่ง แก้ไข อนุมัติ หรือเรียกใช้เครื่องมืออะไรได้บ้าง พร้อมกำหนด human approval, override, kill switch และ rollback ใน use case ที่ความเสี่ยงสูง
- เชื่อม PDPA เข้า AI Assessment ตรวจ prompt, input, output, log, RAG และข้อมูลที่ส่งให้ provider พร้อมทบทวน lawful basis, retention, data subject rights, cross-border transfer และข้อจำกัดของการลบข้อมูล
- เพิ่ม AI Claims และ Vendor Concentration เข้า Legal/Procurement Review ก่อนใช้คำว่า AI-powered หรือ autonomous ต้องมีหลักฐานรองรับ และก่อนฝากกระบวนการสำคัญไว้กับ provider รายเดียวควรมี portability, fallback และ exit plan
มุมมองผู้เชี่ยวชาญ
“ผมมองว่าจุดเปลี่ยนของเอกสารนี้ไม่ได้อยู่ที่ ก.ล.ต. ใส่คำว่า Agentic AI เข้ามาอย่างเดียวครับ จุดสำคัญกว่า คือ คำถามกำลังเปลี่ยนจาก ‘AI ฉลาดแค่ไหน’ เป็น ‘AI มีสิทธิ์ทำอะไรแทนองค์กร และ ใครเป็นคนให้สิทธิ์นั้น’ ถ้าองค์กรตอบไม่ได้ว่าใครอนุมัติ ใครหยุด และมีหลักฐานอะไร ต่อให้มี AI Policy สวยแค่ไหน Governance ก็ยังไม่เกิด”
อีกประเด็นที่ควรหยิบไปใช้ทันทีคือการเชื่อม AI Governance กับ Data Governance และ PDPA
“อย่าแยก AI Team กับ PDPA Team ออกจากกันครับ เพราะพอ AI เชื่อมระบบ Prompt, Output, Log และข้อมูลที่ Agent เรียกใช้จะกลายเป็น Data Flow ใหม่ทันที ความเสี่ยงทางกฎหมายจึงไม่ได้เริ่มตอน AI ทำผิด แต่มันเริ่มตั้งแต่วันที่เราให้สิทธิ์ AI มากเกินไปโดยยังไม่รู้ว่าใครรับผิดชอบ”
— Phuwara Krobtaku —
LL.M., M.S. (IT), Thai Barrister & Attorney-at-Law
แหล่งอ้างอิง
แหล่งข้อมูลหลัก: สำนักงานคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์ (สำนักงาน ก.ล.ต.) — กรอบการกำกับดูแลการใช้งานปัญญาประดิษฐ์ในภาคตลาดทุน: Artificial Intelligence Governance Framework and Handbook, ฉบับปรับปรุงครั้งที่ 1, สิงหาคม 2569
https://www.sec.or.th/TH/Documents/CyberResilience/Artificial-Intelligence-Governance.pdf
- ประเด็น AI Inventory และการออกแบบเป็นทะเบียนเชิงการตัดสินใจอ้างอิงจากภาคผนวก AI Inventory
- ประเด็น PDPA, prompt/input/output/log, retention, สิทธิของเจ้าของข้อมูล และ machine unlearning อ้างอิงส่วนคำถามที่พบบ่อยของคู่มือ
- ประเด็น AI-washing และ minimum evidence set อ้างอิงส่วน FAQs ของคู่มือ
- ประเด็น Third-party และ Concentration Risk อ้างอิง AIMS Controls 2.4.11
- ประเด็น Agentic AI controls, permission boundaries, suspend และ rollback อ้างอิงตัวอย่างการประยุกต์ใช้สำหรับ Automated Trading Support
