EU Data Act: สินค้าเชื่อมต่อต้องเปิดข้อมูลให้ผู้ใช้อย่างไร ก่อน 12 กันยายน 2026

12 กันยายน 2026 คือเส้นตายด้านการออกแบบ ไม่ใช่วันเริ่มกฎหมายทั้งหมด

Regulation (EU) 2023/2854 หรือ Data Act ประกาศในวารสารทางการของ EU เมื่อ 22 ธันวาคม 2023 มีผลใช้โดยรวมตั้งแต่ 12 กันยายน 2025 และสร้างกติกาครอบคลุมการเข้าถึงข้อมูลสินค้าเชื่อมต่อ การแบ่งปันข้อมูลระหว่างธุรกิจ เงื่อนไขสัญญาที่ไม่เป็นธรรม การเปลี่ยนผู้ให้บริการ Cloud และการใช้ข้อมูลในกรณีจำเป็นของภาครัฐ ดังนั้นบริษัทที่มีสัญญา การใช้ Cloud หรือการแบ่งปันข้อมูลใน EU อาจมีหน้าที่บางส่วนอยู่แล้ว ไม่ควรตีความว่ากฎหมายทั้งฉบับยังไม่เริ่ม

หมุดหมายใหม่คือ Article 50 ซึ่งระบุว่าหน้าที่ตาม Article 3(1) ใช้กับสินค้าเชื่อมต่อและบริการเกี่ยวเนื่องที่วางตลาดหลัง 12 กันยายน 2026 หน้าที่นี้บังคับแนวคิด Data Access by Design: สินค้าและบริการต้องถูกออกแบบให้ข้อมูลผลิตภัณฑ์ ข้อมูลบริการ และ Metadata ที่จำเป็นเข้าถึงได้โดยง่าย ปลอดภัย ฟรี ครบถ้วน มีโครงสร้าง ใช้รูปแบบที่พบได้ทั่วไป และเครื่องอ่านได้ โดยให้ผู้ใช้เข้าถึงโดยตรงเมื่อเกี่ยวข้องและทำได้ทางเทคนิค การแก้เพียง Terms of Use โดยไม่แตะ Product Architecture จึงไม่เพียงพอ

ใครและสินค้าใดควรตรวจ Scope ก่อน

สินค้าเชื่อมต่อไม่ได้จำกัดเฉพาะ Smart Home แต่ครอบคลุมสินค้าที่รับ สร้าง หรือรวบรวมข้อมูลจากการใช้งานหรือสภาพแวดล้อม และสามารถสื่อสารข้อมูลผ่านการเชื่อมต่อทางกายภาพหรืออิเล็กทรอนิกส์ ตัวอย่างเชิงธุรกิจ ได้แก่ เครื่องจักรโรงงาน อุปกรณ์เกษตร รถและระบบชาร์จ อุปกรณ์สวมใส่ เครื่องใช้ไฟฟ้า ระบบพลังงาน และอุปกรณ์สุขภาพบางประเภท ส่วน Related Service คือบริการดิจิทัลที่เชื่อมกับสินค้าและมีผลต่อการทำงาน เช่น แอปตั้งค่า ระบบติดตาม หรือบริการวิเคราะห์ที่จำเป็นต่อฟังก์ชันของสินค้า

ทำ Scope Matrix แยก Manufacturer, Brand Owner, OEM, Importer, Distributor, Seller, Related Service Provider, Data Holder และ User เพราะหนึ่งบริษัทอาจมีหลายบทบาท ข้อยกเว้นของ Chapter II สำหรับ Microenterprise หรือ Small Enterprise ไม่ใช่ข้อยกเว้นอัตโนมัติ หากมี Partner หรือ Linked Enterprise ที่ใหญ่กว่า หรือรับจ้างออกแบบ ผลิต หรือให้บริการแทนบริษัทอื่น เงื่อนไขอาจไม่ใช้ นอกจากนี้กิจการที่เพิ่งเป็น Medium-sized Enterprise มีช่วงเปลี่ยนผ่านเฉพาะ จึงต้องตรวจโครงสร้างกลุ่มบริษัทและสัญญา OEM ก่อนตัดสินใจ

ทำ Product Data Map ให้รู้ว่าต้องเปิดอะไร และใครเป็นเจ้าของระบบ

เริ่มจากวาดเส้นทาง Sensor หรือ Event ไปยัง Device, Gateway, Mobile App, Cloud, Analytics, Support และ Partner API แยก Product Data ที่เกิดจากการใช้สินค้า Related Service Data ที่เกิดจากบริการ และ Metadata ที่จำเป็นต่อการตีความ เช่น Timestamp, Unit, Device Identifier, Error Code Definition และ Sampling Frequency จากนั้นระบุว่าอะไรเข้าถึงได้โดยตรง อะไรเป็น Readily Available Data ที่ Data Holder ได้มาหรือสามารถได้มาด้วยการดำเนินการอย่างง่าย และอะไรเป็นข้อมูลอนุมานหรือทรัพย์สินทางปัญญาที่ต้องวิเคราะห์ขอบเขตเพิ่มเติม

จัดทำ Data Dictionary ระบุชื่อ Field, คำอธิบาย หน่วย รูปแบบ ความถี่ แหล่งกำเนิด ระดับ Model หรือ Device, Personal Data Flag, Trade Secret Flag, Retention, Security Classification, Evidence Owner และ API Version หลักสำคัญคือข้อมูลที่ส่งให้ผู้ใช้ต้องมีคุณภาพเดียวกับที่ Data Holder มีอยู่ ไม่ควรลดความละเอียด เปลี่ยนหน่วยโดยไม่บอก หรือให้ไฟล์ที่ไม่มี Metadata จนใช้งานจริงไม่ได้ การมี Source of Truth เดียวช่วยลดความขัดแย้งระหว่าง Firmware, App, Cloud, คู่มือ และสัญญา

ออกแบบ Access Journey ให้เรียบง่าย ปลอดภัย และไม่ใช้ Dark Pattern

หากผู้ใช้เข้าถึงข้อมูลจากสินค้าไม่ได้โดยตรง Article 4 กำหนดให้ Data Holder ทำ Readily Available Data และ Metadata ให้เข้าถึงได้โดยไม่ชักช้า ผ่านคำขออิเล็กทรอนิกส์ที่เรียบง่ายเมื่อทำได้ทางเทคนิค รูปแบบต้องครบ มีโครงสร้าง เครื่องอ่านได้ และรองรับต่อเนื่องหรือ Real-time เมื่อเกี่ยวข้องและทำได้ ผู้ใช้ยังขอให้ส่งข้อมูลแก่บุคคลที่สาม เช่น ผู้ให้บริการซ่อม บำรุงรักษา หรือวิเคราะห์ประสิทธิภาพได้ตาม Article 5

ออกแบบ Journey ตั้งแต่ยืนยันว่าเป็นผู้ใช้ เลือก Device และช่วงเวลา ดาวน์โหลดหรืออนุญาตบุคคลที่สาม ตรวจสถานะ ยกเลิกการแบ่งปัน และร้องเรียน หลีกเลี่ยงการขอข้อมูลระบุตัวตนเกินจำเป็น การวางตัวเลือกแบบชี้นำ ขั้นตอนยกเลิกที่ยากกว่าขอใช้ หรือการเก็บ Log เกินความจำเป็น ควรใช้ Role-based Access, Strong Authentication, Encryption, Audit Trail, Rate Limit และ Revocation พร้อมทดสอบทั้งเจ้าของสินค้า ผู้เช่า ผู้ใช้ธุรกิจ ศูนย์ซ่อม และกรณีเปลี่ยนเจ้าของอุปกรณ์

ข้อมูลก่อนซื้อและสัญญาต้องตรงกับสิ่งที่ระบบทำได้จริง

ก่อนทำสัญญาซื้อ เช่า หรือเช่าซื้อ ผู้ขายต้องแจ้งประเภท รูปแบบ และปริมาณโดยประมาณของข้อมูล สินค้าสร้างข้อมูลต่อเนื่องหรือ Real-time หรือไม่ เก็บบนอุปกรณ์หรือ Server ที่ใด เก็บนานเท่าใด และผู้ใช้เข้าถึง ดึง หรือเมื่อเกี่ยวข้อง ลบข้อมูลได้อย่างไร สำหรับ Related Service ต้องแจ้งธรรมชาติ ปริมาณ ความถี่ วัตถุประสงค์การใช้ข้อมูล ผู้ประมวลผล ช่องทางติดต่อ วิธีขอส่งข้อมูลให้บุคคลที่สาม สิทธิ์ร้องเรียน Trade Secret Holder ระยะสัญญา และวิธียุติสัญญา

สร้าง Pre-contract Data Notice หนึ่งชุดแล้วเชื่อมไปยังหน้าสินค้า Marketplace, ใบเสนอราคา, Distributor Pack, คู่มือ, App Onboarding และ Contract Schedule ห้ามคัดลอกข้อความกฎหมายกว้าง ๆ หากระบบจริงยังส่งออกได้เพียง CSV รายเดือน ให้บอกข้อเท็จจริงนั้นพร้อม Quality of Service ไม่ควรอ้าง Real-time API เพื่อการตลาด การทดสอบแบบ Contract-to-Code Traceability จะช่วยยืนยันว่าทุกข้อความมี Owner, Endpoint, Format, Retention และ Evidence รองรับ

คุม GDPR, Trade Secret และ Cybersecurity โดยไม่ปิดสิทธิ์ผู้ใช้

Data Act ไม่ได้แทน GDPR หากข้อมูลเป็น Personal Data การให้ผู้ใช้หรือบุคคลที่สามเข้าถึงยังต้องมีฐานกฎหมายตาม GDPR และเงื่อนไขเพิ่มเติมสำหรับข้อมูลอ่อนไหว เมื่อผู้ร้องขอไม่ใช่ Data Subject ยิ่งต้องตรวจสิทธิ์และฐานประมวลผลให้ชัด แยก Personal, Non-personal และ Mixed Data ตั้งแต่ Data Map ใช้ Data Minimisation, Purpose Limitation และสิทธิ์การเข้าถึงตามบทบาท ไม่ควรใช้ Consent เป็นคำตอบเดียวโดยไม่วิเคราะห์ฐานกฎหมายที่เหมาะสม

Trade Secret ต้องได้รับการคุ้มครองผ่านการระบุข้อมูลและมาตรการที่ได้สัดส่วน เช่น Confidentiality Agreement, Access Protocol, Technical Standard และการควบคุมบุคคลที่สาม ไม่สามารถปฏิเสธทุกคำขอเพียงติดป้ายว่าเป็นความลับ การระงับหรือปฏิเสธทำได้ภายใต้เงื่อนไขเฉพาะ ต้องมีเหตุผลเป็นลายลักษณ์อักษรและแจ้งหน่วยงานที่เกี่ยวข้อง ส่วนข้อจำกัดด้าน Security ต้องเชื่อมกับความเสี่ยงร้ายแรงต่อสุขภาพ ความปลอดภัย หรือความมั่นคง ไม่ใช่ใช้เป็นเหตุผลทั่วไปเพื่อปิด API

แผนเตรียม 4 สัปดาห์ก่อน 12 กันยายน 2026

สัปดาห์ที่ 1 เลือก Product Family ที่จะวางตลาด EU หลัง 12 กันยายน 2026 แต่งตั้ง Product, Legal, Privacy, Security, Engineering, Customer Service และ EU Partner ทำ Scope Matrix กับ Data Flow และรวบรวมสัญญา สัปดาห์ที่ 2 ทำ Data Inventory และ Data Dictionary ระบุ Readily Available Data, Metadata, Personal Data, Trade Secret และ Owner พร้อม Gap Assessment เทียบ Article 3–7

สัปดาห์ที่ 3 สร้าง Minimum Viable Access Journey ตั้งแต่ยืนยันผู้ใช้ ดาวน์โหลด ส่งต่อ และยกเลิก ทดสอบ Format, API, Authentication, Response Time, Logging และ Incident Handling พร้อมปรับ Pre-contract Data Notice และสัญญา สัปดาห์ที่ 4 ทำ End-to-End Test กับ EU Importer หรือ Distributor และผู้ให้บริการภายนอก ปิด Critical Gap ตั้งระบบรับคำร้องและหลักฐาน แล้วทำ Roadmap สำหรับทุก SKU เป้าหมายไม่ใช่มีปุ่ม Download แต่คือข้อมูลที่ถูกต้อง ปลอดภัย เคลื่อนย้ายได้ และคำสัญญากับลูกค้าตรงกับระบบจริง

• มี Scope Matrix แยกสินค้า บริการ บริษัทในกลุ่ม และบทบาทตามกฎหมาย
• มี Data Map และ Data Dictionary ที่ผูก Field กับ Metadata, Owner และ Classification
• มี Access Journey สำหรับผู้ใช้และบุคคลที่สาม พร้อม Revocation และ Complaint Route
• มี Pre-contract Data Notice, Contract Schedule และ Support Script ที่ตรงกับระบบจริง
• มีผล End-to-End Test, Security Review, GDPR Review และ Trade Secret Controls ก่อนวางตลาด