Skip to content
  1. หน้าแรก
  2. บทความของเรา
  3. EU AI Act ถูกเลื่อน แต่หน้าที่บางข้อไม่ถูกเลื่อน: ทำบัญชี AI ในระบบของคุณก่อนลูกค้ายุโรปถาม
116
Enterprise

EU AI Act ถูกเลื่อน แต่หน้าที่บางข้อไม่ถูกเลื่อน: ทำบัญชี AI ในระบบของคุณก่อนลูกค้ายุโรปถาม

EU AI Act ถูกเลื่อน แต่หน้าที่บางข้อไม่ถูกเลื่อน: ทำบัญชี AI ในระบบของคุณก่อนลูกค้ายุโรปถาม

EU เลื่อนกฎ high-risk ของ AI Act แต่หน้าที่ด้านความโปร่งใสยังเริ่ม 2 ส.ค. 2026 ตามเดิม บทความนี้แยกว่าอะไรเลื่อนและอะไรไม่เลื่อน แล้วอธิบายการทำบัญชีฟังก์ชัน AI ในระบบที่ทีมไอทีทำได้เอง

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

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

ข่าวนี้ยืนยันได้แค่ไหน และเราอ่านถึงไหน

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

บทความของ Legal 500 ลงวันที่ 3 สิงหาคม 2026 รายงานว่า Digital Omnibus on AI คือ Regulation (EU) 2026/1744 ประกาศใน Official Journal ของ EU เมื่อวันที่ 24 กรกฎาคม 2026 และมีผลใช้บังคับตั้งแต่วันที่ 27 กรกฎาคม 2026 (ดูบทความของ Legal 500) ส่วนบันทึกของ Gibson Dunn ที่เราเปิดอ่านเขียนก่อนการรับรองขั้นสุดท้าย ระบุว่าข้อตกลงทางการเมืองเกิดขึ้นเมื่อวันที่ 6 พฤษภาคม 2026 และยังรอการประกาศใน Official Journal จึงใช้ยืนยันเนื้อหาของข้อตกลงได้ แต่ใช้ยืนยันสถานะการประกาศใช้ไม่ได้ (ดูบันทึกของ Gibson Dunn)

สิ่งที่เรายังทำไม่ได้คือเปิดตัวกฎหมายบน EUR-Lex อ่านเอง หน้าที่เราเปิดไม่คืนเนื้อหากลับมา ตัวเลขวันที่ทั้งหมดในบทความนี้จึงมาจากแหล่งรองที่ตรงกันสองแห่ง ไม่ใช่จากตัวบท และมีรายงานว่าเคยมีการแก้ถ้อยคำภายหลังการประกาศ ถ้าคุณจะนำวันที่ไปใส่ในเอกสารกำกับดูแลหรือสัญญา ให้เปิดข้อความที่ประกาศจริงเทียบอีกครั้งก่อน

สิ่งที่ถูกเลื่อน และสิ่งที่ไม่ถูกเลื่อน

ตามที่แหล่งรองรายงาน สิ่งที่ถูกเลื่อนคือหน้าที่ของระบบ AI ที่จัดเป็น high-risk สองกลุ่ม

  • ระบบ high-risk แบบ stand-alone ตาม Annex III เช่น ระบบที่ใช้คัดเลือกพนักงาน ประเมินสินเชื่อ หรือใช้ในการศึกษา เลื่อนจาก 2 สิงหาคม 2026 เป็น 2 ธันวาคม 2027

  • ระบบ AI ที่ฝังอยู่ในผลิตภัณฑ์ที่มีกฎหมายความปลอดภัยของ EU กำกับอยู่แล้ว ตาม Annex I เช่น อุปกรณ์การแพทย์ เครื่องจักร เลื่อนเป็น 2 สิงหาคม 2028 (Gibson Dunn ระบุว่าวันเดิมคือ 2 สิงหาคม 2027)

สิ่งที่แหล่งเดียวกันรายงานว่าไม่ถูกเลื่อนมีอย่างน้อยสามเรื่อง

  • หน้าที่ด้านความโปร่งใสตามมาตรา 50 เช่น การแจ้งผู้ใช้ว่ากำลังโต้ตอบกับระบบ AI และการระบุว่าเนื้อหาเป็นผลงานที่ AI สร้าง ยังเริ่มใช้ตั้งแต่ 2 สิงหาคม 2026 ตามเดิม ซึ่งผ่านมาแล้วเมื่อวันที่บทความนี้เผยแพร่

  • หน้าที่ของผู้พัฒนาโมเดล AI อเนกประสงค์ (GPAI) ซึ่งใช้มาตั้งแต่ 2 สิงหาคม 2025 ไม่มีการเปลี่ยนวัน

  • ข้อห้ามใหม่สองข้อ เกี่ยวกับระบบที่สร้างหรือดัดแปลงภาพใกล้ชิดที่สมจริง และสื่อล่วงละเมิดทางเพศเด็ก มีผลตั้งแต่ 2 ธันวาคม 2026 ตาม Legal 500

มีรายละเอียดหนึ่งที่สองแหล่งเล่าไม่ตรงกัน คือช่วงผ่อนผันของการทำเครื่องหมายที่เครื่องอ่านได้ (machine-readable marking) สำหรับระบบ generative AI ที่วางตลาดก่อน 2 สิงหาคม 2026 Legal 500 เล่าว่าเป็นช่วงผ่อนผันสี่เดือน ส่วน Gibson Dunn เขียนก่อนการรับรองและระบุวันที่ 2 ธันวาคม 2026 ในฐานะข้อเสนอ เราจึงไม่ฟันธงเรื่องนี้ และแนะนำให้ตรวจกับตัวบท

ทำไมการเลื่อนจึงไม่เท่ากับ "ยังไม่ต้องทำอะไร"

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

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

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

บัญชี AI feature คืออะไร และควรมีอะไรอยู่ในนั้น

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

สำหรับแต่ละฟังก์ชัน เราแนะนำให้บันทึกอย่างน้อยเรื่องเหล่านี้

  • ชื่อฟังก์ชันและระบบที่มันอยู่ เช่น แชตบอตตอบลูกค้าในเว็บไซต์ ฟังก์ชันสรุปเอกสาร ฟังก์ชันให้คะแนนใบสมัคร

  • งานที่ AI ทำ และผลลัพธ์ไปไหนต่อ ผลลัพธ์แสดงให้คนอ่านเฉย ๆ หรือถูกนำไปตัดสินใจต่อโดยอัตโนมัติ

  • โมเดลหรือบริการที่อยู่ข้างหลัง เป็นโมเดลที่ทีมฝึกเอง บริการ API ของผู้ให้บริการภายนอก หรือฟังก์ชันที่มากับซอฟต์แวร์สำเร็จรูป

  • ผู้ใช้ปลายทางเห็นหรือไม่ว่าเป็น AI มีข้อความแจ้ง มีป้ายกำกับบนเนื้อหาที่สร้าง หรือไม่มีเลย

  • ข้อมูลอะไรเข้าไปในฟังก์ชัน โดยเฉพาะข้อมูลส่วนบุคคล และข้อมูลนั้นออกไปนอกระบบหรือนอกประเทศหรือไม่

  • เจ้าของฟังก์ชัน เป็นรายชื่อคน ไม่ใช่ชื่อแผนก

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

AI ที่ซ่อนอยู่ในสิ่งที่ซื้อมา

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

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

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

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

ความโปร่งใสในหน้าจอ: จุดที่ทีมระบบแก้ได้เองโดยไม่ต้องรอกฎหมาย

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

  • แชตบอตหรือผู้ช่วยเสียงบอกตัวเองไหมว่าเป็นระบบอัตโนมัติ หรือแต่งตัวให้เหมือนพนักงาน

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

  • ถ้ามีมนุษย์ตรวจผลลัพธ์ก่อนส่ง ระบบบันทึกไหมว่าใครตรวจ เมื่อไร

ข้อสุดท้ายโยงกับเรื่อง log ที่เราเขียนไว้ในบทความเรื่องการเก็บ log และ audit trail ถ้าฟังก์ชัน AI ไม่ทิ้งร่องรอยว่าอะไรเข้า อะไรออก และใครอนุมัติ ก็ตอบคำถามย้อนหลังไม่ได้ แม้ในวันที่ไม่มีกฎหมายข้อใดบังคับ

กรณี AI Agent ที่เข้าไปทำงานในระบบจริง

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

ข้อโต้แย้งที่ได้ยินบ่อยคือ กฎเลื่อนไปปี 2027 แล้ว ไว้ค่อยทำตอนใกล้ถึงวัน คำถามนี้มีเหตุผล และสำหรับองค์กรที่ระบบ AI เข้าข่าย high-risk ตาม Annex III จริง ๆ ช่วงเวลาที่ได้เพิ่มมาก็ช่วยลดแรงกดดันได้มาก เราไม่ได้เห็นว่าใครควรทิ้งงานอื่นมาทำเรื่องนี้

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

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

จะเริ่มตรงไหน

  1. ถามแต่ละแผนกว่าใช้เครื่องมืออะไรที่มีฟังก์ชัน AI อยู่ รวมถึงที่มากับซอฟต์แวร์เดิมโดยที่ไม่ได้เลือก อย่าถามแค่ทีมไอที

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

  3. เปิดหน้าจอจริงของแต่ละฟังก์ชันที่ผู้ใช้เห็น แล้วจดว่ามีข้อความบอกว่าเป็น AI หรือไม่ ถ่ายภาพหน้าจอเก็บไว้พร้อมวันที่

  4. ตรวจว่าฟังก์ชันไหนส่งข้อมูลออกนอกระบบ และข้อมูลนั้นมีข้อมูลส่วนบุคคลหรือไม่ เรื่องที่ตั้งของข้อมูลเราเขียนแยกไว้ในบทความเรื่อง region ของ Cloud และ PDPA

  5. ส่งตารางให้ที่ปรึกษากฎหมาย พร้อมคำถามว่าฟังก์ชันไหนอยู่ในขอบเขต และกำหนดวันทบทวนตารางซ้ำเมื่อมีการอัปเดตซอฟต์แวร์หรือมีเครื่องมือใหม่


สรุป

การเลื่อนกฎ high-risk ของ EU ไม่ได้ทำให้หน้าที่ด้านความโปร่งใสถูกเลื่อนตาม และไม่ได้ทำให้คำถามของลูกค้าหายไป ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ทำตารางหนึ่งหน้าที่บอกว่าระบบขององค์กรมีฟังก์ชัน AI อะไร ใครเป็นเจ้าของ และผู้ใช้ปลายทางเห็นหรือไม่ว่าเป็น AI ตารางนั้นใช้ได้ทั้งตอบแบบสอบถามของลูกค้า ส่งให้ที่ปรึกษากฎหมาย และส่งต่อให้ทีมที่มารับช่วงระบบ

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

FAQ: คำถามที่พบบ่อยเกี่ยวกับบทความนี้

รวมคำถามและคำตอบที่ช่วยให้คุณเข้าใจเนื้อหาในบทความนี้ได้ดียิ่งขึ้น

ค้นหา:

EU AI Actบัญชีฟังก์ชัน AIAI governanceความโปร่งใสของ AIแบบสอบถามผู้ขาย
แชร์:

บทความอื่น ๆ

เตรียมพบกับบทความเร็วๆ นี้