สำหรับผู้ผลิตเครื่องจักรและผู้ให้บริการ Industrial IoT ในประเทศไทย การเตรียมความพร้อมด้าน กฎหมายข้อมูล EU สำหรับเครื่องจักรอุตสาหกรรม ไม่ใช่เพียงการเพิ่มปุ่มส่งออก CSV หรือเปิด cloud API ก่อนส่งมอบ Regulation (EU) 2023/2854 หรือ EU Data Act เริ่มมีผลใช้บังคับทั่วไปตั้งแต่วันที่ 12 กันยายน 2025 และตาม Article 50 หน้าที่ด้านการออกแบบตาม Article 3(1) ใช้กับผลิตภัณฑ์เชื่อมต่อและบริการที่เกี่ยวข้องซึ่ง นำออกสู่ตลาด EU หลังวันที่ 12 กันยายน 2026 ข้อกำหนดนี้ไม่ใช่คำสั่งให้แก้ไขเครื่องจักรเก่าทุกเครื่องที่ติดตั้งอยู่แล้วในวันดังกล่าว
บทความนี้จัดทำกรอบปฏิบัติสำหรับผู้ผลิตเครื่องจักร ผู้ขาย IoT ผู้รวมระบบ และโรงงานผู้ซื้อ ตั้งแต่การพิจารณาขอบเขต บทบาท user และ data holder บัญชีข้อมูล การเปิดเผยก่อนทำสัญญา การเข้าถึงโดยตรงหรือผ่าน data holder มาตรการปกป้อง สัญญา ไปจนถึงหลักฐาน FAT/SAT แผน 90 วันที่กล่าวถึงเป็นข้อเสนอการบริหารโครงการของ TOMAS TECH ไม่ใช่ระยะผ่อนผันตามกฎหมาย และ API เป็นเพียงตัวอย่างการติดตั้งใช้งาน กฎหมายไม่ได้บังคับ API โปรโตคอล หรือเทคโนโลยีใดเป็นการเฉพาะ
ใครควรเริ่มทันที และผลลัพธ์ที่พร้อมปล่อยผลิตภัณฑ์คืออะไร
ควรเริ่มงานหากบริษัทขายหรือให้เช่าเครื่องจักรเชื่อมต่อใน EU มีบริการติดตามหรือบำรุงรักษาระยะไกล เก็บข้อมูลเครื่องจักรไว้ในคลาวด์ของ OEM หรือจัดทำ RFP สำหรับโรงงานใน EU การตั้งบริษัทอยู่นอก EU ไม่ได้ทำให้หลุดจากขอบเขตโดยอัตโนมัติ เพราะข้อบังคับครอบคลุมผู้ผลิตที่นำผลิตภัณฑ์เชื่อมต่อออกสู่ตลาด EU และผู้ให้บริการที่เกี่ยวข้องโดยไม่ขึ้นกับสถานที่ตั้ง
ผลลัพธ์ที่ต้องการไม่ใช่ป้าย “compliant” แต่เป็นชุดหลักฐานรายรุ่นที่ตอบได้ว่าใครเป็นผู้ใช้ ใครเป็นผู้ถือข้อมูล ข้อมูลและ metadata ใดพร้อมใช้งาน ผู้ใช้รับหรือสั่งแบ่งปันข้อมูลอย่างไร มาตรการปกป้องใดใช้ และทดสอบเส้นทางข้อมูลครบถ้วนอย่างไร
| คำถามของผู้บริหาร | คำตอบที่ไม่เพียงพอ | คำตอบที่ใช้ตัดสินใจปล่อยผลิตภัณฑ์ |
|---|---|---|
| รุ่นใดอยู่ในขอบเขต | “สินค้ากลุ่ม IoT รองรับ” | รุ่น บริการที่เกี่ยวข้อง วันที่นำออกสู่ตลาด EU และบันทึกการพิจารณา |
| ต้องให้ข้อมูลอะไร | “ให้ machine log” | รายการระดับ field แหล่งกำเนิด ขั้นการประมวลผล metadata ความถี่ และที่เก็บ |
| ให้ข้อมูลอย่างไร | “มี API” | เส้นทางตรง/ผ่านผู้ถือข้อมูล ตัวตน รูปแบบ QoS เหตุขัดข้อง การดึงและลบ |
| ปกป้องอะไร | “ทุกอย่างเป็นความลับ” | การประเมิน trade secret ข้อมูลส่วนบุคคล ความปลอดภัยไซเบอร์และเครื่องจักรรายรายการ |
| พิสูจน์อย่างไร | “dashboard ใช้งานได้” | ภาคผนวกสัญญา FAT/SAT log การอนุมัติข้อยกเว้น และคู่มือผู้ใช้ |
ผังพิจารณาขอบเขต: วันที่ ผลิตภัณฑ์ บริการ และบทบาท
อย่ารวมสองวันที่เข้าด้วยกัน EU Data Act เริ่มใช้ทั่วไปวันที่ 12 กันยายน 2025 ส่วนหน้าที่ออกแบบตาม Article 3(1) ใช้กับผลิตภัณฑ์เชื่อมต่อและบริการที่เกี่ยวข้องซึ่ง นำออกสู่ตลาด EU หลังวันที่ 12 กันยายน 2026 ไม่มีระยะผ่อนผันตามกฎหมาย 90 วัน และไม่ควรกล่าวว่าเครื่องจักรที่ติดตั้งอยู่ทั้งหมดต้องออกแบบใหม่ในวันเดียวกัน
จากนั้นพิจารณารายรุ่นว่าเป็น connected product หรือไม่ เครื่องจักรอุตสาหกรรมและหุ่นยนต์เป็นตัวอย่างที่ European Commission ระบุ ตรวจว่าผลิตภัณฑ์รับ สร้าง หรือสื่อสารข้อมูลเกี่ยวกับการใช้งาน ประสิทธิภาพ หรือสภาพแวดล้อมหรือไม่ และบริการติดตาม บำรุงรักษา หรือเพิ่มประสิทธิภาพระยะไกลเชื่อมกับการทำงานของผลิตภัณฑ์อย่างไร
บทบาทต้องยึดธุรกรรมและอำนาจควบคุมจริง ผู้ใช้อาจเป็นผู้ซื้อ ผู้เช่า หรือผู้ใช้ภายใต้สัญญา leasing ส่วน data holder คือฝ่ายที่มีสถานะทางกฎหมายและทางปฏิบัติในการทำให้ข้อมูลที่เกี่ยวข้องพร้อมใช้งาน OEM ตัวแทนจำหน่าย cloud provider และบริษัทบริการอาจอยู่ในสายเดียวกัน จึงต้องเทียบสัญญากับ permission จริง
| ขั้น | คำถาม | หลักฐาน | หากยังสรุปไม่ได้ |
|---|---|---|---|
| 1. Market placement | รุ่นหรือเครื่องนั้นออกสู่ตลาด EU เมื่อใด | เอกสารนำเข้า ขาย เช่า และส่งมอบ | ยืนยันกับที่ปรึกษากฎหมาย EU |
| 2. Connected product | รับ สร้าง หรือสื่อสารข้อมูลที่เกี่ยวข้องหรือไม่ | Functional spec, architecture, interface list | ให้เจ้าของผลิตภัณฑ์อนุมัติรายรุ่น |
| 3. Related service | บริการดิจิทัลเชื่อมกับหน้าที่ของผลิตภัณฑ์หรือไม่ | Service description, terms, SLA | ประเมินผลิตภัณฑ์และบริการร่วมกัน |
| 4. User | ใครเป็นเจ้าของ ผู้เช่า หรือผู้ใช้แบบ leasing | สัญญาการค้าและสิทธิใช้ทรัพย์สิน | แยกตามรูปแบบธุรกรรม |
| 5. Data holder | ใครทำให้ข้อมูลพร้อมแก่ผู้ใช้ได้จริง | Access matrix, cloud contract, operation map | กำหนดความรับผิดชอบผู้รับจ้างช่วง |
FAQ ของ Commission เป็นแนวทางปฏิบัติ ไม่ใช่ตัวบทกฎหมาย ตาม Article 7 การยกเว้นหน้าที่ Chapter II สำหรับ micro/small enterprise มีเงื่อนไข รวมถึงต้องไม่มี linked/partner enterprise ที่ไม่เข้าข่าย และตัว micro/small enterprise เองต้องไม่ได้รับเหมาช่วงจากผู้อื่นให้ผลิตหรือออกแบบ connected product หรือให้ related service เงื่อนไขนี้หมายถึงบริษัทเป็นผู้รับงานตามสัญญาจากผู้อื่น ไม่ใช่กรณีที่บริษัทว่าจ้าง subcontractor ของตนเอง ต้องให้ผู้เชี่ยวชาญกฎหมาย EU ตรวจข้อเท็จจริงเฉพาะกรณี.
แยกขอบเขตข้อมูลก่อนเลือกเทคโนโลยี
คำว่า “ข้อมูลเครื่องจักร” กว้างเกินกว่าจะเขียน RFP หรือทดสอบได้ คำอธิบายของ Commission ระบุว่าขอบเขต Chapter II เกี่ยวข้องกับ raw data และ pre-processed data ที่ data holder มีพร้อมใช้ รวมถึง metadata ที่เกี่ยวข้อง ส่วน inferred/derived data และ content อยู่นอกขอบเขตการเข้าถึงที่อธิบายดังกล่าว อย่างไรก็ดี ต้องตรวจแต่ละสัญญาณและขั้นการประมวลผลจริง

| ประเภทข้อมูล | ตัวอย่างในเครื่องจักร | แนวทางปฏิบัติ | ช่องข้อมูลใน inventory |
|---|---|---|---|
| RAW | อุณหภูมิ การสั่น กระแส cycle และ alarm | ประเมินเป็น access candidate ราย field | sensor, unit, timestamp, sampling, missing rule |
| PRE-PROCESSED | ค่า calibrate แล้ว การสั่นผ่าน filter state code มาตรฐาน | พิจารณาเมื่อพร้อมใช้ | transformation, calibration, quality, source link |
| DERIVED | อายุใช้งานคงเหลือ prediction หรือ proprietary score | ตรวจแยก ไม่สรุปว่าต้องรวมอัตโนมัติ | model, IP, input และเงื่อนไขเสนอขาย |
| ข้อมูลส่วนบุคคล | operator ID ประวัติการใช้ วิดีโอ ตำแหน่ง | ต้องมีฐานและมาตรการตาม GDPR แยกต่างหาก | data subject, purpose, retention, access |
| Trade secret | recipe, tuning, tolerance, customer condition | ใช้มาตรการตามสัดส่วน ไม่ปฏิเสธแบบเหมารวม | เหตุผลความลับ ขอบเขต NDA และ technical control |
Data inventory ต้องลงถึงระดับ field: แหล่งกำเนิด เจ้าของ ที่เก็บ ขั้นการประมวลผล ความหมาย หน่วย หลักเวลา คุณภาพ/ความไม่แน่นอน retention ช่องทางดึง ความสัมพันธ์กับ user การแบ่งปันบุคคลที่สาม และ flag ด้าน personal data หรือ trade secret ควรใช้ identifier เดียวกันในงานขาย ออกแบบ สัญญา และ FAT/SAT
อย่าสับสนกับ Digital Product Passport ซึ่งเน้นตัวตนผลิตภัณฑ์และข้อมูลวงจรชีวิต สำหรับแนวคิด DPP ที่เป็นงานข้างเคียง อ่านคู่มือ DPP สำหรับผู้ส่งออกเหล็กจากไทยได้ แต่บทความนี้เน้นข้อมูลที่เกิดระหว่างการใช้ connected product และ related service
ทำให้การเปิดเผยก่อนทำสัญญาตาม Article 3(2) เป็น deliverable ของฝ่ายขาย
ก่อนทำสัญญา ผู้ซื้อควรทราบชนิด รูปแบบ และปริมาณโดยประมาณของข้อมูล ข้อมูลสร้างต่อเนื่องหรือ real time หรือไม่ เก็บในเครื่องหรือระยะไกลและนานเท่าใด รวมถึงวิธีเข้าถึง ดึง หรือลบ เงื่อนไข วิธีทางเทคนิค และคุณภาพบริการต้องชัดเจน
| หัวข้อเปิดเผย | สิ่งที่ต้องเขียนในข้อเสนอ | เจ้าของหลังรับงาน | หลักฐานตรวจรับ |
|---|---|---|---|
| ชนิด รูปแบบ ปริมาณ | data dictionary, format, จำนวนโดยประมาณ และประเภท event/time series | Product/data engineering | sample ตรงกับ dictionary |
| การสร้าง | continuous, periodic, event, batch | Controls/IoT | ทดสอบภายใต้โหลดแทนจริง |
| ที่เก็บและ retention | on-device, edge, cloud และ policy | IT/service operations | config, deletion, restore |
| ช่องทางเข้าถึง | local, portal, bulk, API หรือคำขอ | Product owner | valid, denied, expired request |
| การดึงและลบ | ตรวจตัวตน สิทธิ workflow และ audit | Support/security | การกระทำผู้ใช้และ audit trail |
| เงื่อนไขและ QoS | รูปแบบ update ข้อจำกัด planned outage และ support | Service management | ทดสอบเทียบข้อกำหนดที่ตกลง |
อย่าสร้างตัวเลข uptime, latency หรือ retention แล้วเรียกว่า “มาตรฐาน EU” ให้กำหนดจากข้อเท็จจริงของผลิตภัณฑ์และข้อตกลงทางการค้า แล้วทำให้ทดสอบได้ นอกจากนี้ การใช้ non-personal product data ของ data holder ควรมีข้อตกลงกับ user ที่แยกวัตถุประสงค์ เช่น remote maintenance, benchmarking, product improvement และ AI training อย่างชัดเจน
สถาปัตยกรรมการเข้าถึง: direct กับ mediated access
Article 3(1) กำหนดผลลัพธ์: product/related-service data และ metadata ต้องเข้าถึงได้ง่าย ปลอดภัย ไม่คิดค่าใช้จ่ายจากผู้ใช้ ครบถ้วน มีโครงสร้าง อยู่ในรูปแบบ machine-readable ที่ใช้กันทั่วไป และเมื่อเกี่ยวข้องและเป็นไปได้ทางเทคนิคควรเข้าถึงโดยตรง API เป็นเพียงตัวอย่างการติดตั้ง ไม่ใช่เทคโนโลยีที่กฎหมายบังคับ การส่งไฟล์ที่ปลอดภัย bulk download message stream local interface หรือ cloud endpoint ล้วนเป็นทางเลือกตามบริบท

Direct access ให้ user ที่ได้รับอนุญาตดึงข้อมูลจากเครื่องหรือ edge ใกล้เครื่องโดยไม่ต้องยื่นคำขอเป็นรายครั้ง เหมาะกับ local analytics แต่ต้องจัดการ identity การแบ่งเครือข่าย โหลดของเครื่อง version และการเพิกถอนเมื่อเลิกใช้ ส่วน mediated access ผ่าน portal หรือบริการของ data holder จัดการสิทธิรวมศูนย์ง่ายกว่า แต่เพิ่มการพึ่งพา availability ขั้นตอนคำขอ และผู้ขาย
| ปัจจัย | Direct access | ผ่าน data holder | ข้อกำหนดใน RFP |
|---|---|---|---|
| ช่องทาง | interface บนเครื่องหรือ edge | cloud, portal, request service | ช่องทางหลักต่อ dataset |
| ประโยชน์ | local integration ลดการพึ่งพา | identity และ sharing แบบรวมศูนย์ | จับคู่กับวัตถุประสงค์ user |
| ความเสี่ยง | OT load, rogue access, version drift | outage, friction, lock-in | fallback และ incident process |
| ตัวตน | device, user, application | tenant, user, recipient | issue, rotate, revoke, audit |
| Metadata | version ไปกับ schema | catalogue/response | unit, time, quality, version |
| การทดสอบ | load, disconnect, permission, update | request, sharing, outage, expiry | expected FAT/SAT result |
Metadata ทำให้ตัวเลขใช้งานได้ ค่า “38.4” ไม่มีความหมายหากไม่รู้หน่วย ความหมาย timestamp สถานะ calibration และกฎ missing data ควรอธิบายเนื้อหา dataset วิธีเก็บ ข้อจำกัดการใช้ license คุณภาพ/ความไม่แน่นอน format vocabulary และช่องทางเทคนิค
สำหรับงานที่เกี่ยวข้อง อ่านแนวทาง IIoT interoperability และ TIS 30162 และแนวทางหลักฐานความปลอดภัย IoT ตาม ETSI EN 303 645ได้ ทั้งสองช่วยจัดระบบหลักฐาน แต่ไม่ใช่ใบรับรองทดแทน EU Data Act
สัญญาข้อมูล IIoT และ responsibility matrix ใน RFP
เทคโนโลยีอย่างเดียวไม่ตอบว่าใครต้องดำเนินการต่อคำขอของใคร Commission เผยแพร่ non-binding model contractual terms สำหรับความสัมพันธ์ data holder–user, user–data recipient และ data holder–data recipient เอกสารเหล่านี้ปรับใช้ได้โดยสมัครใจ ไม่ใช่ certificate และไม่แทน legal review
| Deliverable/กิจกรรม | Machine OEM | IoT/cloud | EU sales/service | Factory user | Data recipient |
|---|---|---|---|---|---|
| พิจารณารุ่นและ market placement | R | C | A | I | I |
| Data inventory/metadata | A/R | R | C | C | I |
| Access/identity design | R | A/R | C | C | I |
| เปิดเผยก่อนสัญญา | C | C | A/R | I | I |
| ตรวจ user/แต่งตั้ง recipient | I | R | A | R | C |
| Trade-secret safeguards | A/R | R | C | C | C |
| FAT/SAT evidence | A | R | C | R | I |
| Incident, deletion, exit | R | A/R | R | R | R |
A คือผู้รับผิดชอบสุดท้าย R คือผู้ลงมือ C คือผู้ร่วมปรึกษา I คือผู้รับทราบ ตัวอย่างนี้ให้ OEM รับผิดชอบขั้นสุดท้ายต่อหลักฐาน FAT/SAT ที่รวมกัน ส่วนผู้ใช้โรงงานเป็นผู้ดำเนินการและบันทึก site acceptance test ให้ปรับตามคู่สัญญาจริง ต้องกำหนดการยกเลิก subscription การขายเครื่องต่อ การคืน lease การเปลี่ยน user และ cloud provider รวมถึง credential revocation, data return, retention, deletion และ audit evidence
การแบ่งปันแก่บุคคลที่สามต้องเป็นเส้นทางควบคุมสำหรับ recipient ที่ user เลือก: ตรวจตัวตนผู้ใช้ ระบุผู้รับ จำกัดข้อมูลและระยะเวลา บันทึกวัตถุประสงค์ เพิกถอนได้ และมี audit trail ไม่ใช่ endpoint ที่เปิดให้ทุกคน
Guardrail สำหรับ trade secret, cybersecurity, safety และ GDPR
การเพิ่ม access ไม่ได้หมายถึงการถอด protection สำหรับข้อมูลที่มี trade secret ให้ใช้ classification ราย field purpose limit จำกัดผู้เข้าถึง NDA secure environment และ logging การติดป้าย confidential เพียงอย่างเดียวไม่ใช่เหตุปฏิเสธแบบเหมารวม เส้นทางที่อ้าง serious economic damage มีเงื่อนไขเข้มและต้องมีหลักฐาน
ข้อจำกัดด้าน security ก็ไม่ใช่ข้อยกเว้นทั่วไป ต้องพิจารณาข้อกำหนด security ในกฎหมาย EU หรือกฎหมายประเทศสมาชิก ผลกระทบร้ายแรงต่อสุขภาพ ความปลอดภัย หรือ security และขั้นตอนแจ้งที่เกี่ยวข้อง คำว่า “เป็นระบบ OT” ไม่ใช่บันทึกการตัดสินใจที่เพียงพอ
| ความเสี่ยง | สิ่งที่ควรหลีกเลี่ยง | Guardrail | ผู้อนุมัติ |
|---|---|---|---|
| Trade secret | จัดทุก field เป็นความลับ | เหตุผลราย field, minimum scope, NDA, controlled environment | Legal/business owner |
| Machine safety | ปิด access ทั้งหมด | read-only separation, load limit, independent safety | Machinery safety owner |
| Cybersecurity | shared permanent credential | unique identity, least privilege, revocation, audit, update | Product security owner |
| Personal data | ส่งออกเหมือน product data ทั่วไป | legal basis, purpose limit, minimisation, rights process | DPO/privacy owner |
| Availability | stream ไม่จำกัด | capacity, priority, rate control, fallback | Product/service owner |
หากมี operator ID วิดีโอ หรือตำแหน่ง การเปิด access ตาม Data Act ไม่ได้สร้างฐานทางกฎหมาย GDPR ให้อัตโนมัติ ต้องประเมิน necessity, minimisation, retention, transparency, international transfer และ data-subject rights แยกต่างหาก
FAT/SAT: ทดสอบโดยทำให้เส้นทางข้อมูลผิดปกติ
FAT ต้องทดสอบ permission ผิด network ขาด clock drift schema เปลี่ยน missing data third-party sharing และ contract exit ไม่ใช่แค่ดาวน์โหลดสำเร็จหนึ่งครั้ง SAT ทำซ้ำกรณีสำคัญบนเครือข่าย ตัวตน และนโยบายจริงของโรงงาน
| Test | เงื่อนไข | ผลที่คาดหวัง | หลักฐาน | Failure gate |
|---|---|---|---|---|
| DA-01 | Authorized user ขอข้อมูล | ได้ scope, format, metadata ตามตกลง | output, dictionary, audit log | แก้และ retest |
| DA-02 | ผู้ไม่มีสิทธิขอ | ปฏิเสธ ระบุเหตุผล และบันทึก | identity/notification log | Security STOP |
| DA-03 | User เลือก third party | แชร์เฉพาะขอบเขตและเวลา | authority, token, receipt | Conditional release |
| DA-04 | Network ขาดและกลับมา | loss, buffer, duplicate ตาม spec | fault/replay log | Recovery REWORK |
| DA-05 | Schema/firmware เปลี่ยน | version, compatibility, notice ทำงาน | old/new comparison | Change STOP |
| DA-06 | Clock drift, gap, outlier | แสดง quality และ uncertainty | source/transformation evidence | Quality REWORK |
| DA-07 | จบสัญญาหรือขายต่อ | revoke, return, retain, delete ครบ | revocation/deletion evidence | Shipment STOP |
| DA-08 | Access load สูง | ไม่กระทบ control และ safety | PLC, network, load log | Safety review |
ตรวจความหมายด้วย ได้แก่ unit, timezone, clock synchronisation, quality flag, calibration, model และ firmware version ข้อมูลที่ดึงได้แต่ตีความไม่ได้อาจนำไปสู่การบำรุงรักษาผิดพลาด แยกผลเป็น pass, conditional pass, retest และ stop โดยปัญหา cross-tenant, safety หรือ personal data ต้องหยุด release
แผนเตรียม 90 วันพร้อม release gate
แผนนี้เป็นรูปแบบโครงการของ TOMAS TECH ไม่ใช่ระยะผ่อนผันตามกฎหมาย เป้าหมายคือพารุ่นแรกที่อยู่ในขอบเขตผ่าน release gate ไม่ใช่ประกาศว่าพอร์ตทั้งหมดพร้อม

| ช่วงเวลา | งาน | เงื่อนไขเสร็จ | Gate |
|---|---|---|---|
| วัน 1–15 | ยืนยันรุ่น market placement บทบาท related service | Applicability/owner ได้รับอนุมัติ | ไม่ชัดให้ STOP และถาม EU counsel |
| วัน 16–30 | ทำ inventory, boundary, metadata, risk flag | field สำคัญมี owner และเหตุผล | ช่องว่างให้ REWORK |
| วัน 31–45 | ออกแบบ direct/mediated, identity, log, sharing | architecture, threat, permission ผ่าน | กระทบ safety ให้ STOP |
| วัน 46–60 | จัดทำ disclosure, contract, RFP, support | technical scope ตรงกับ contract | ต่างกันให้ REWORK |
| วัน 61–75 | pilot, FAT, fault injection, correction | ไม่มี critical defect และ evidence พร้อม | conditional/retest |
| วัน 76–90 | SAT, training, release review | owner sign-off, due date, version lock | RELEASE หรือ STOP |
เริ่มด้วย vertical chain เดียวตั้งแต่ SENSOR, MACHINE, EDGE, METADATA ถึง USER และ recipient ที่เลือก พร้อม audit จากนั้นค่อยขยาย pattern ไปยังสัญญาณอื่น คณะอนุมัติต้องตรวจว่า INVENTORY มีเหตุผล CONTRACT ตรงกับระบบ ACCESS ใช้ได้ TEST ครอบคลุม fault/change/exit และ RELEASE ไม่มีประเด็นร้ายแรงที่ยังไม่มีเจ้าของ
Checklist สำหรับผู้ซื้อ
- ระบุผลิตภัณฑ์ บริการ วันที่คาดว่าจะออกสู่ตลาด user และ data holder
- รายการ field, metadata, format, volume, frequency, storage, retention และ processing stage
- เหตุผลการแยก raw, pre-processed, derived, personal และ trade-secret data
- ทางเลือก direct/mediated ต่อ dataset และ fallback
- Authentication, authorisation, recipient nomination, revocation และ audit
- Pre-contract disclosure, data-use agreement, sharing term และ support flow
- มาตรการ trade secret, privacy, security, safety พร้อมชื่อผู้อนุมัติ
- FAT/SAT case, test data, pass criteria, due date และ handover evidence
- กฎแจ้งเปลี่ยน schema, firmware, cloud, compatibility และ retest
- ความต่อเนื่องของความรับผิดชอบเมื่อเปลี่ยน subcontractor หรือ cloud provider
ให้ประเมินค่าใช้จ่ายการเดินระบบด้วย ได้แก่ การรักษา dictionary ตรวจ user เปิด sharing ตอบคำขอ เก็บ audit log คุม schema version และทำ contract exit แยกหน้าที่ access ของ user ออกจากบริการวิเคราะห์หรือบำรุงรักษาที่เพิ่มมูลค่า
คำถามที่พบบ่อย
การเตรียม EU Data Act สำหรับเครื่องจักรต้องทำอะไรบ้าง
ต้องพิจารณารุ่นและบทบาท จัดทำ inventory และ metadata สร้างช่องทาง access/share ที่ใช้งานได้ เปิดเผยก่อนทำสัญญา กำหนดข้อตกลงใช้และแบ่งปันข้อมูล วาง safeguards และสร้างหลักฐาน FAT/SAT เป็นระบบผลิตภัณฑ์และสัญญา ไม่ใช่ feature เดียว
ต้องแก้เครื่องจักรติดตั้งเดิมทั้งหมดในวันที่ 12 กันยายน 2026 หรือไม่
ไม่ควรกล่าวเช่นนั้น หน้าที่ออกแบบ Article 3(1) ใช้กับ connected products และ related services ที่ นำออกสู่ตลาด EU หลังวันที่ 12 กันยายน 2026 กรณี stock, upgrade หรือ remanufactured equipment ต้องพิจารณาข้อเท็จจริงและปรึกษากฎหมาย EU
กฎหมายบังคับให้ทำ API หรือไม่
ไม่บังคับ API เป็นเพียงตัวเลือกทางปฏิบัติ ข้อกำหนดเน้นผลลัพธ์และไม่ได้กำหนด protocol เฉพาะ อาจใช้ local access, bulk export, messaging, portal หรือ API ตาม data, purpose และ technical feasibility
มีระยะผ่อนผัน 90 วันหรือไม่
ไม่มี แผน 90 วันในบทความนี้เป็นข้อเสนอของ TOMAS TECH เพื่อควบคุมโครงการจนถึง release decision ไม่ใช่ statutory grace period
Trade secret หรือ cybersecurity ใช้ปฏิเสธได้หรือไม่
ใช้คำติดป้ายแบบเหมารวมไม่ได้ ต้องประเมินข้อมูล เงื่อนไขกฎหมาย ความเสียหายที่เป็นไปได้ safeguard ที่ได้สัดส่วน และขั้นตอนที่กำหนด เส้นทางปฏิเสธมีเงื่อนไขเข้ม ควรใช้ EU legal counsel และหารือ competent authority เมื่อเหมาะสม
สรุป: ใส่ “data handover” ในเกตปล่อยเครื่องจักร
การเตรียม EU Data Act ต้องอยู่ใน product release gate เดียวกับ applicability, role, data boundary, metadata, access, identity, third-party sharing, safeguards, contract และ FAT/SAT เริ่มจากรุ่นเดียวที่กำลังส่ง EU และ data chain ที่ครบหนึ่งเส้น เชื่อมทุก field กับ contract term และ test case
TOMAS TECH ช่วยผู้ผลิตเครื่องจักรและโรงงานในไทยจัด workshop รายรุ่น data inventory access architecture ภาคผนวก RFP และ FAT/SAT design ได้ การตัดสินกฎหมายขั้นสุดท้ายต้องเป็นของผู้เชี่ยวชาญ EU แต่ทีมวิศวกรรมสามารถทำ requirement ให้ทดสอบได้ตั้งแต่ช่วงแนวคิดและเสนอราคา หากต้องการประเมินในระยะแรก ติดต่อ TOMAS TECH ได้
หมายเหตุทางกฎหมาย: บทความนี้เป็นข้อมูลทั่วไปด้านเทคนิคและการจัดซื้อ ไม่ใช่คำปรึกษากฎหมาย โปรดยืนยัน applicability, role allocation, GDPR, trade secret, security, safety และสัญญากับที่ปรึกษากฎหมาย EU ที่มีคุณสมบัติ และ competent authority เมื่อจำเป็น
แหล่งอ้างอิงปฐมภูมิ
- Regulation (EU) 2023/2854 — ตัวบททางการ โดยเฉพาะ Articles 1, 3, 4 และ 50
- European Commission — Data Act explained เรื่อง connected products, data scope, roles, sharing และ trade secrets
- European Commission — Data Act FAQ v1.4, 22 January 2026 เป็น implementation guidance ไม่ใช่ตัวบทกฎหมาย
- European Commission — Non-binding Model Contractual Terms ตัวอย่างโดยสมัครใจสำหรับสามความสัมพันธ์หลัก
- European Commission — ประกาศเริ่มใช้ Data Act เรื่องการเริ่มใช้วันที่ 12 กันยายน 2025
- Interoperable Europe — Rolling Plan for ICT Standardisation 2026 บริบทเชิงปฏิบัติของ dataset description และ access method