กฎเกณฑ์ AI ที่กำลังมา: ธุรกิจไทยที่ขายต่างประเทศต้องเตรียมอะไร

อ่านแบบสั้น

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

1. เหตุใดธุรกิจไทยควรสนใจก่อนถูกลูกค้าถาม

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

กฎอาจใช้ตามตลาดและผลกระทบ ไม่ใช่ที่ตั้งผู้พัฒนาเพียงอย่างเดียว ลูกค้าองค์กรในยุโรปจะส่ง Questionnaire และข้อกำหนดสัญญาให้ Supply Chain ก่อนวันบังคับใช้ บริษัทที่ไม่มีรายการระบบและเอกสารอาจเสียดีลแม้ผลิตภัณฑ์มีคุณภาพ

นอกจาก EU AI Act ยังมี PDPA, กฎหมายผู้บริโภค ทรัพย์สินทางปัญญา และกฎอุตสาหกรรมที่เกี่ยวข้อง ต้องวิเคราะห์เป็นราย Use Case ไม่ใช้คำว่า “เป็นแค่ผู้ใช้ API” แล้วคิดว่าไม่มีหน้าที่

ข้อควรระวังบทความนี้ให้กรอบเตรียมธุรกิจ กฎหมายและ Timeline เปลี่ยนได้ ควรให้ที่ปรึกษากฎหมายตรวจผลิตภัณฑ์ ตลาด บทบาท และสัญญาจริงก่อนตัดสินใจ

2. Timeline ที่ควรใส่ในแผนสินค้า

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

รู้ก่อนว่าบริษัทเป็นผู้พัฒนา ผู้ใช้งาน หรือผู้จัดจำหน่าย เพราะหน้าที่ตามกฎต่างกัน

ตามข้อมูลทางการของ EU ชุดกฎใช้แบบทยอย ข้อกำหนดความโปร่งใสและการบังคับใช้ส่วนใหญ่เริ่มในปี 2026 ข้อกำหนดระบบ High-risk บางประเภทใน Annex III มีกำหนดช่วงปลายปี 2027 และ High-risk ที่ฝังในผลิตภัณฑ์กำกับบางประเภทมีกำหนดปี 2028

บริษัทไม่ควรรอถึงกำหนด เพราะการทำ Data Governance, Quality Management, Technical Documentation และ Monitoring ใช้เวลา โดยเฉพาะหากผลิตภัณฑ์มีวงจรขายยาว ลูกค้าอาจกำหนด Readiness ล่วงหน้า

ช่วง	สิ่งที่ธุรกิจควรทำ
วันนี้–2026	Inventory, Literacy, Transparency และ Contract
2027	จัดประเภท High-risk, Evidence, QMS และ Supplier Readiness
2028	Product Compliance, Monitoring และ Audit ตาม Scope

3. รู้ก่อนว่าบริษัทเป็น Provider, Deployer หรือตัวกลาง

หน้าที่แตกต่างตามบทบาท ผู้สร้างระบบภายใต้ชื่อของตนอาจเป็น Provider ผู้ใช้ในกระบวนการเป็น Deployer ผู้นำเข้าและผู้จัดจำหน่ายอาจมีหน้าที่เฉพาะ หากปรับระบบสำคัญหรือเปลี่ยน Intended Purpose บทบาทอาจเปลี่ยน ต้องทำ Contract Map ตลอด Supply Chain

เวิร์กโฟลว์ปฏิบัติตามกฎที่ฝังอยู่ในระบบ เก็บหลักฐานให้เองโดยไม่เพิ่มงาน

ทำ Use-case Inventory ระบุวัตถุประสงค์ ผู้ได้รับผล กระบวนการตัดสินใจ ข้อมูล โมเดล ตลาด และ Human Oversight จากนั้นให้ Legal จัดประเภท หลีกเลี่ยงการจัดความเสี่ยงจากชื่อเทคโนโลยีอย่างเดียว ระบบเดียวใช้ใน Marketing อาจเสี่ยงต่างจากใช้คัดเลือกพนักงาน

4. หลักฐานที่ควรสร้างไม่ว่าถูกจัดระดับใด

วัตถุประสงค์และข้อจำกัดที่อนุมัติ
Data Source, สิทธิ์, คุณภาพ และ Retention
Model/Version, Vendor และการเปลี่ยนแปลง
Evaluation ตามกลุ่มและกรณีเสี่ยง
Human Oversight และสิทธิ์หยุด/แก้
Log, Incident, Complaint และ Corrective Action
คำอธิบายผู้ใช้และการเปิดเผย AI-generated content ตามกรณี

สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค

ใช้ Documentation as Code เชื่อม Evidence กับ Release ไม่เขียนเอกสารย้อนหลังปีละครั้ง ทุกการเปลี่ยนโมเดล Knowledge หรือ Intended Use ต้องประเมินผลกระทบและเก็บ Decision Record

5. สัญญา Vendor ต้องส่งหลักฐาน ไม่ใช่เพียง SLA Uptime

สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค

ถามข้อมูล Training/Data Policy, Security, Model Change, Evaluation, Subprocessor, Location, Incident Notification และ Exit/Deletion กำหนดสิทธิ์รับเอกสารที่จำเป็นต่อหน้าที่ของบริษัท หาก Vendor ไม่ให้ข้อมูล บริษัทอาจพิสูจน์ Compliance ของผลิตภัณฑ์ตนไม่ได้

สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค

ทำ Supplier Tier ตามผลกระทบ โมเดลที่ใช้ร่างภายในกับโมเดลที่อยู่ใน High-risk Product ต้องมี Due Diligence ต่างกัน วาง Model Replacement Plan หาก Vendor เปลี่ยนเงื่อนไขหรือไม่ผ่านข้อกำหนด

6. ความโปร่งใสต้องอยู่ใน UX และกระบวนการ

บอกผู้ใช้เมื่อโต้ตอบกับ AI ตามบริบท อธิบายขอบเขตและช่องทางติดต่อคน สำหรับการตัดสินใจที่มีผลกระทบ แสดงข้อมูลที่ใช้ สิทธิ์คัดค้านหรือขอทบทวนตามที่เกี่ยวข้อง ไม่ซ่อน Disclaimer ใน Terms ยาว

เนื้อหาสังเคราะห์ควรมี Provenance และ Approval ตามความเสี่ยง สร้าง Label/Metadata ที่คงอยู่ผ่านช่องทาง downstream ฝึกพนักงานไม่ให้ Over-rely และมี Script อธิบายลูกค้าอย่างตรงไปตรงมา

Compliance เป็นคุณสมบัติการขายลูกค้าองค์กรซื้อความมั่นใจ หากบริษัทตอบได้ว่า Agent ใดใช้ข้อมูลอะไร ใครรับผิด และเกิด Incident แล้วทำอย่างไร จะลดเวลา Security/Legal Review และสร้างความต่างจากคู่แข่งที่มีเพียง Demo

7. สร้าง Compliance Program ที่ไม่เป็นคอขวด

สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค

ใช้ Risk-tier Workflow: Low-risk Self-assessment, Medium Review โดย Data/Security และ High-risk Cross-functional Assessment สร้าง Template, Approved Pattern และ Sandbox ให้ทีมทำเร็วภายใน Guardrail Legal ควรเข้าตั้งแต่ Design ไม่ใช่ก่อน Go-live วันสุดท้าย

สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค

ตั้ง AI Governance Committee ขนาดพอเหมาะ เน้น Policy และข้อยกเว้น ไม่อนุมัติทุก Prompt มี AI Register, Owner, Review Date และ Dashboard Incident/Evidence ตรวจการปฏิบัติจริงด้วย Sampling

8. สิ่งที่ทำได้วันนี้โดยไม่รอกฎหมายชัดทุกบรรทัด

ทำทะเบียน AI ทุกระบบและตลาดที่เกี่ยวข้อง
ระบุ Owner, Intended Use และ Risk เบื้องต้น
สร้าง Data/Model Lineage และ Version Record
กำหนด Human Oversight, Incident และ Complaint
เพิ่ม AI Clause ใน Procurement/Vendor Contract
ให้ Legal ตรวจ Use Case สำคัญและ Roadmap ตลาด

สรุป: ธุรกิจไทยที่ขายต่างประเทศควรเตรียมหลักฐานและ Governance ก่อนถูกลูกค้าหรือกฎบังคับ Inventory, Classification, Lineage, Evaluation และ Human Oversight เป็นฐานที่มีประโยชน์ไม่ว่ากฎหมายปรับอย่างไร เป้าหมายคือสร้างระบบที่อธิบาย ควบคุม และแก้ไขได้ ไม่ใช่ทำเอกสารเพียงเพื่อผ่าน Checklist

แหล่งอ้างอิงทางการEuropean Commission — EU AI Act implementation timeline
European Commission — Navigating the AI Act

DNA MAKER · SOLUTION BLUEPRINT

สร้างหลักฐานการทำงานที่ตอบลูกค้าและผู้ตรวจได้ ตั้งแต่วันแรก

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

สิ่งที่ระบบควรเก็บไว้ให้อัตโนมัติ

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

SOFTWARE ENGINEERING GLOSSARY

คลังคำศัพท์การพัฒนาซอฟต์แวร์

คำศัพท์กลุ่มนี้ช่วยให้คุยกับทีมพัฒนาเรื่องหลักฐานและการตรวจสอบย้อนหลัง

คำศัพท์	คืออะไร	ตัวอย่างที่เข้าใจง่าย	คำถามที่ผู้บริหารควรถามทีมพัฒนา
Traceability	ความสามารถย้อนรอยว่าผลลัพธ์หนึ่งมาจากข้อมูลและกติกาชุดใด	ย้อนดูได้ว่าการปฏิเสธคำขอนี้ใช้เกณฑ์เวอร์ชันใด	เราย้อนรอยได้ถึงระดับใด และเก็บไว้นานเท่าไร?
Versioning	การเก็บเวอร์ชันของโมเดล กติกา หรือเอกสาร เพื่อรู้ว่าใช้อะไรอยู่ ณ เวลาหนึ่ง	บันทึกว่าเดือนที่แล้วระบบใช้กติกาเวอร์ชัน 3	ถ้าต้องอธิบายผลของเมื่อสามเดือนก่อน เรามีข้อมูลพอไหม?
Consent	การขอและบันทึกความยินยอมของผู้ใช้ก่อนเก็บหรือใช้ข้อมูล	บันทึกว่าลูกค้ายินยอมให้เก็บบทสนทนาเมื่อใด	เราพิสูจน์การยินยอมย้อนหลังได้อย่างไร?
PII	ข้อมูลที่ระบุตัวบุคคลได้ ต้องดูแลเป็นพิเศษ	ชื่อ เบอร์โทร และเลขที่เอกสารของลูกค้า	ข้อมูลส่วนบุคคลถูกส่งออกนอกระบบใดบ้าง?
Model Card	เอกสารสรุปว่าโมเดลถูกใช้ทำอะไร มีข้อจำกัดใด และประเมินอย่างไร	สรุปขอบเขตการใช้งานและกรณีที่ไม่ควรใช้	เรามีเอกสารแบบนี้สำหรับระบบที่ใช้อยู่หรือยัง?