EU AI Act Enforcement 2026: รับมือ Complaint, Whistleblower และ RFI อย่างไร

2 สิงหาคม 2026 เปลี่ยนอะไร และอะไรยังไม่เริ่มพร้อมกัน

European Commission อัปเดต Enforcement Framework เมื่อ 24 สิงหาคม 2026 ว่าอำนาจบังคับใช้ของ AI Office และหน่วยงานระดับประเทศเริ่มทำงานตั้งแต่ 2 สิงหาคม 2026 สำหรับบทบัญญัติที่มีผลแล้ว เช่น Prohibited AI Practices, หน้าที่ของผู้ให้บริการ General-Purpose AI หรือ GPAI และความโปร่งใสของระบบ AI บางประเภท การตีความว่า ‘AI Act ใช้ครบทั้งหมดแล้ว’ จึงกว้างเกินจริง เพราะข้อกำหนด High-risk AI ใน Annex III ถูกเลื่อนไปใช้ 2 ธันวาคม 2027 และ High-risk AI ที่ฝังในผลิตภัณฑ์ตามกฎหมายเฉพาะเริ่ม 2 สิงหาคม 2028 หลังการแก้ไขปี 2026

ผู้บริหารจึงควรสร้าง Applicability Timeline ต่อ Use Case ระบุระบบ เจ้าของ บทบาท ความเสี่ยง ประเทศที่ใช้ หน้าที่ที่มีผลแล้วและหลักฐานปัจจุบัน เพื่อป้องกันทั้งการลงทุนเกินจำเป็นและการพลาดหน้าที่ที่เริ่มแล้ว เช่น AI Literacy หรือ Transparency

ธุรกิจไทยอยู่ใน Scope เมื่อใด และใครเป็นผู้กำกับ

Article 2 ครอบคลุม Provider ที่นำระบบหรือโมเดล AI เข้าสู่ตลาด EU, Deployer ที่ตั้งอยู่ใน EU ตลอดจน Provider หรือ Deployer ในประเทศที่สามเมื่อผลลัพธ์จากระบบถูกใช้ใน EU และยังครอบคลุม Importer, Distributor, ผู้ผลิตสินค้าที่วาง AI พร้อมผลิตภัณฑ์ภายใต้ชื่อหรือเครื่องหมายการค้าของตน และ Authorised Representative บางกรณี ดังนั้นการไม่มีบริษัทลูกในยุโรปไม่ได้ตัด Scope อัตโนมัติ ต้องตรวจเส้นทางของ Output, ผู้ใช้ และสินค้าเป็นรายกรณี

Enforcement ไม่ได้รวมศูนย์อยู่ที่ AI Office ทั้งหมด คณะกรรมาธิการระบุว่า AI Office ดูแลผู้ให้บริการ GPAI, ระบบ AI ที่พัฒนาโดยผู้ให้บริการหรือบริษัทในกลุ่มเดียวกับ GPAI Provider และระบบที่ฝังใน Very Large Online Platform หรือ Search Engine ตาม DSA ส่วนระบบอื่นอยู่กับ National Competent Authorities และ EDPS ดูแล AI ของสถาบัน EU องค์กรจึงควรทำ Authority Map แยกตามประเทศและ Use Case พร้อมผู้ประสาน Legal, Privacy, Product, Security และ HR

Complaint, Whistleblower และ Downstream Complaint ต่างกันอย่างไร

AI Act Complaint Tool เปิดให้บุคคลธรรมดาและนิติบุคคลร้องเรียนการฝ่าฝืนที่อยู่ในอำนาจเฉพาะของ AI Office ผู้ร้องต้องระบุประเทศ เหตุการณ์ รายละเอียด และข้อมูลติดต่อ ช่องทางนี้ไม่ใช่ Anonymous Reporting แต่ AI Office ระบุว่าจะจัดการอย่างเป็นความลับ และเมื่อเรื่องอยู่นอกอำนาจอาจแจ้งผู้ร้องหรือส่งต่อหน่วยงาน Market Surveillance หรือหน่วยงานสิทธิขั้นพื้นฐานโดยได้รับความยินยอมตามความเหมาะสม

Whistleblower Tool เป็นช่องทางปลอดภัยสำหรับบุคคลที่มีความเกี่ยวข้องทางวิชาชีพกับผู้ให้บริการ GPAI หรือระบบ AI ที่อยู่ในเขตอำนาจของ AI Office และรองรับการไม่เปิดเผยชื่อพร้อมเอกสารประกอบ ส่วน Downstream Provider ที่สร้างระบบบนโมเดล GPAI ของผู้อื่นและเห็นว่าผู้ให้บริการโมเดลไม่ปฏิบัติตาม Articles 53–55 มีช่องทาง Complaint เฉพาะตาม Article 89(2) ซึ่งไม่ใช่ช่องทางนิรนาม ความแตกต่างนี้ทำให้องค์กรต้องมี Intake Matrix เพื่อจำแนกผู้แจ้ง ประเด็น กฎหมาย ระบบ ประเทศ และหน่วยงานปลายทางก่อนดำเนินการ

RFI และอำนาจสอบสวน: อย่ารอให้มีหนังสือแล้วค่อยหาเอกสาร

AI Office มีอำนาจส่ง Request for Information เพื่อขอเอกสารและข้อมูล ตรวจประเมินโมเดล ขอการเข้าถึงผ่าน API หรือวิธีทางเทคนิคที่เหมาะสม และในบางกรณีขอ Source Code รวมถึงขอมาตรการแก้ไขหรือจำกัดการเปิดให้ใช้โมเดล สำหรับระบบที่อยู่ในอำนาจ AI Office ยังอาจสัมภาษณ์ผู้มีข้อมูลโดยความยินยอมและตรวจสถานที่ของ Provider ได้ ขอบเขตจริงขึ้นกับฐานกฎหมายและผู้ถูกกำกับ จึงต้องอ่านหนังสือทุกฉบับร่วมกับที่ปรึกษากฎหมาย ไม่ควรตอบแบบ Template เดียวกัน

คณะกรรมาธิการอธิบายว่า RFI แบบทั่วไปอาจมีผลหากตอบไม่ถูกหรือทำให้เข้าใจผิด ส่วนคำขอที่ออกเป็นมติทางการอาจครอบคลุมกรณีไม่ตอบหรือตอบไม่ครบด้วย ขั้นตอนภายในจึงควรล็อก Preservation Notice ห้ามลบ Log หรือแก้ Record เดิม ระบุ Single Point of Contact และทำ Response Register บันทึกคำถาม แหล่งข้อมูล ผู้ตรวจ วันที่ เวอร์ชัน และข้อจำกัดของคำตอบ ทุกการแปลหรือสรุปข้อมูลเทคนิคควรผ่านการยืนยันจากเจ้าของระบบก่อนส่ง

สร้าง AI Enforcement Evidence Pack ที่ตอบได้จากข้อมูลจริง

Evidence Pack ขั้นต่ำควรมี AI System and Use Case Inventory, Role and Scope Assessment, Model Card หรือข้อมูล Vendor, Contract และ Change Notice, Data Source and Lawful-use Record, Risk Assessment, Testing, Human Oversight, Transparency Notice, Output Review, Incident and Complaint Log, CAPA และหลักฐานการอบรมตามบทบาท เอกสารแต่ละรายการต้องมี Owner, วันที่มีผล, Version, Retention และ Access Control ไม่ควรเก็บ Prompt หรือข้อมูลลูกค้าทุกอย่างโดยไม่มีวัตถุประสงค์ เพราะการเก็บเกินจำเป็นสร้างความเสี่ยงด้าน Privacy และความลับเพิ่มขึ้น

สิ่งที่หน่วยงานต้องการไม่ใช่แฟ้มจำนวนมาก แต่คือ Traceability ที่อธิบายได้ว่าใครตัดสินใจจากหลักฐานใด ณ เวลาใด เชื่อม AI Use Case ID กับ Vendor Version, Data Version, Test Result, Output, Human Reviewer, Publication/Decision และ Corrective Action หากโมเดลหรือ Policy เปลี่ยน ต้องรักษาประวัติว่าเวอร์ชันใดใช้กับเหตุการณ์นั้น การทำ Retrieval Drill รายไตรมาสจะเปิดเผยช่องว่างได้เร็วกว่าการรอ Audit จริง

ออกแบบ Response Workflow ภายใน 72 ชั่วโมงแรก

องค์กรสามารถกำหนดเป้าหมายภายใน 72 ชั่วโมงเพื่อควบคุมเหตุ แม้ไม่ใช่เส้นตายทั่วไปของ AI Act สำหรับทุก Complaint ชั่วโมง 0–4 ให้บันทึกเรื่อง แยกระดับความรุนแรง รักษาหลักฐาน และตั้งทีม Legal–AI–Security–Privacy ชั่วโมง 4–24 ให้ตรวจ Scope, Authority, ระบบ เวอร์ชัน ผู้ได้รับผลกระทบ และมาตรการหยุดความเสียหายโดยไม่ทำลายหลักฐาน ชั่วโมง 24–72 ให้ยืนยันข้อเท็จจริง เปิด CAPA กำหนดการสื่อสาร และจัดทำรายการข้อมูลที่ต้องขอเพิ่ม

ห้ามตอบโต้ผู้แจ้ง ลบหรือแก้ Log ย้อนหลัง ติดต่อผู้ร้องโดยไม่มีผู้รับผิดชอบ หรือส่งชุดข้อมูลดิบออกไปโดยไม่ตรวจสิทธิและความลับ การสื่อสารควรแยกข้อเท็จจริงที่ยืนยันแล้ว สิ่งที่กำลังตรวจ สมมติฐาน และมาตรการชั่วคราวอย่างชัดเจน หากเรื่องแตะข้อมูลส่วนบุคคล ความมั่นคงปลอดภัย การเลือกปฏิบัติ แรงงาน หรือผู้บริโภค อาจมีกฎหมายและเส้นตายอื่นทำงานคู่กัน ต้องเปิด Cross-Regulatory Incident Track ไม่ใช่จำกัดการวิเคราะห์อยู่ที่ AI Act

เพดานค่าปรับสูง แต่การบริหารความเสี่ยงต้องมองมากกว่าตัวเลข

Enforcement Framework ของคณะกรรมาธิการระบุเพดานสำหรับ Prohibited AI Practices สูงสุด 35 ล้านยูโรหรือ 7% ของยอดขายทั่วโลกต่อปี แล้วแต่มูลค่าใดสูงกว่า การฝ่าฝืนหน้าที่อื่นบางกลุ่มอาจสูงสุด 15 ล้านยูโรหรือ 3% และการไม่ให้ข้อมูลหรือให้ข้อมูลผิด ไม่ครบ หรือทำให้เข้าใจผิดอาจสูงสุด 7.5 ล้านยูโรหรือ 1% สำหรับ Provider ของ GPAI Article 101 กำหนดเพดานสูงสุด 15 ล้านยูโรหรือ 3% ในกรณีที่ระบุ อย่างไรก็ดี เพดานไม่ใช่ค่าปรับอัตโนมัติ การกำหนดจำนวนจริงต้องพิจารณาลักษณะ ความร้ายแรง ระยะเวลา เจตนา ความประมาท และหลักความได้สัดส่วน

ความเสียหายเชิงธุรกิจมักเกิดก่อนคำสั่งสุดท้าย เช่น การหยุดระบบ เสียลูกค้า การสอบสวนหลายประเทศ Vendor Dispute และความเชื่อมั่นของพนักงาน การลงทุนที่ให้ ROI สูงจึงไม่ใช่ซื้อ Dashboard เพิ่ม แต่คือทำให้ระบบมี Owner, Control และ Evidence ลดเวลาค้นข้อมูล ลดการตอบขัดแย้ง และหยุดผลกระทบได้เร็ว Board Dashboard ควรดูทั้ง Use Case ที่ยังไม่ประเมิน, Evidence Completeness, Open Incident, CAPA เกินกำหนด และเวลา Retrieval

แผน 30 วัน: จากเอกสารกระจัดกระจายสู่ Enforcement Readiness

วัน 1–7 ทำ AI Inventory และ EU Nexus Scan ระบุระบบ Vendor รุ่น ประเทศ ผู้ใช้ ผลลัพธ์ และบทบาททางกฎหมาย พร้อมหยุด Use Case ที่ห้ามหรือไม่มี Owner ชัดเจน วัน 8–14 ทำ Authority and Intake Matrix แยก Complaint, Whistleblower, Customer Complaint, Privacy Incident และ Security Incident กำหนดช่องทางรับเรื่อง การรักษาความลับ การส่งต่อ และผู้มีอำนาจตัดสินใจ

วัน 15–21 สร้าง Evidence Pack Template และ Response Register เชื่อมหลักฐานจริงหนึ่ง Use Case ที่มีความเสี่ยงสูงต่อธุรกิจ วัน 22–30 ทำ Mock Complaint และ Mock RFI จับเวลา Retrieval ตรวจความสอดคล้องระหว่าง Legal, Technical และ Public Communication แล้วปิด CAPA ตัวชี้วัดเริ่มต้นควรเป็น AI Use Case ที่มี Owner 100%, Scope Assessment ครบ 100%, Critical Evidence Completeness มากกว่า 95%, Retrieval ภายในหนึ่งวันทำการ และ CAPA รุนแรงเกินกำหนดเป็นศูนย์

• ตั้ง AI Enforcement Owner และผู้แทนสำรองที่ติดต่อได้จริง
• ทดสอบการค้นคืน Model/Vendor Version และ Decision Log จากเหตุการณ์จำลอง
• แยก Privileged Legal Review ออกจาก Operational Record ตามกฎหมายที่เกี่ยวข้อง
• ทบทวนสัญญา Vendor เรื่อง Audit, Incident, Change Notice, Evidence และ Cooperation
• รายงาน Board ด้วยความเสี่ยง ผลกระทบ และ CAPA ไม่ใช้เพียงจำนวนเครื่องมือ AI