EU AI Act Article 50: Provider ต้องทำให้ผู้ใช้รู้ว่ากำลังคุยกับ AI

ลองนึกภาพว่ามีข้อความทักลูกค้าว่า

“ผมตรวจคำสั่งซื้อให้แล้ว และสามารถยืนยันการเปลี่ยนที่อยู่จัดส่งได้ทันที”

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

ตั้งแต่ 2 สิงหาคม 2026 กฎความโปร่งใสตาม Article 50 ของ EU AI Act เริ่มใช้แล้วครับ

แต่ต้องแยกให้ชัดตั้งแต่ต้นว่าอะไรคือตัวบทกฎหมายที่มีผลผูกพัน และอะไรคือแนวทางตีความ

Article 50(1) วางหน้าที่ไว้ที่ provider ของระบบ AI ที่ออกแบบมาให้โต้ตอบโดยตรงกับบุคคล ให้ระบบถูกออกแบบและพัฒนาเพื่อทำให้คนรู้ว่ากำลังโต้ตอบกับ AI เว้นแต่ความเป็น AI จะเห็นได้ชัดอยู่แล้วเมื่อพิจารณาจากสถานการณ์และบริบท

ส่วนการบอกว่าทำงานแทนใคร การแจ้งใน key step และทุก interaction ใหม่ มาจาก Guidelines ปี 2026 ของ European Commission ซึ่งเป็นแนวทางตีความที่ไม่มีผลผูกพันเหมือน Regulation ไม่ใช่ถ้อยคำที่เขียนไว้ตรง ๆ ใน Article 50(1)

1) ข่าวนี้คืออะไรในภาษาคนทำงาน

ตัว Regulation ใช้แกนสำคัญ 3 เรื่อง

1. ผู้มีหน้าที่คือ provider
2. ระบบต้องถูกออกแบบมาให้ interact directly with natural persons
3. คนต้องได้รับข้อมูลว่ากำลังโต้ตอบกับ AI เว้นแต่เรื่องนี้จะ เห็นได้ชัดอยู่แล้ว สำหรับบุคคลที่รู้ข้อมูลพอสมควร ช่างสังเกต และรอบคอบ โดยดู circumstances และ context

ดังนั้น Article 50(1) ไม่ได้เขียนตรง ๆ ว่า Agent ต้องบอกว่าทำงานแทนใคร ต้องแจ้งทุก key step หรือต้องแจ้งใหม่ทุก interaction

แล้ว Commission Guidelines เพิ่มอะไร

Guidelines ปี 2026 เป็นแนวทางตีความและคำแนะนำเชิงปฏิบัติที่ไม่มีผลผูกพันเหมือนตัว Regulation แนวทางนี้อธิบายว่า AI Agent อาจอยู่ในขอบเขตเมื่อโต้ตอบกับคนที่สั่งงาน หรือบุคคลอื่นระหว่างทำงาน เช่น

• จองบริการ
• จัดการอีเมลหรือข้อความ
• เจรจาหรือทำสัญญา
• ดำเนินการซื้อ
• ตอบลูกค้า
• ทำงานใน social media
• ช่วยเขียนโค้ดและคุยกับผู้ใช้โดยตรง

สำหรับ Agent ที่อยู่ในขอบเขต Guidelines แนะนำให้เปิดเผย 2 เรื่องหลัก

1. มันเป็น AI ไม่ใช่มนุษย์
2. มันกำลังทำงานแทนใคร

Guidelines ยังแนะนำการแจ้งในจังหวะสำคัญ เช่น ตอนขออนุญาต รายงานผล และยืนยันการทำงาน รวมถึงทุก interaction ใหม่

จุดสำคัญคือ “ทำงานแทนใคร”, “key step” และ “ทุก interaction ใหม่” เป็นภาษาจากแนวทาง Commission ไม่ใช่ข้อกำหนด verbatim ใน Article 50(1) ครับ

2) ทำไม founder และทีมเล็กควรสนใจ

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

แต่ต่อให้ยังไม่เข้าเขต EU โดยตรง บทเรียนเรื่องความโปร่งใสก็ใช้ได้กับธุรกิจไทยทันที

ลูกค้าตัดสินใจได้ถูกขึ้น

ลูกค้าอาจยอมให้ AI เช็กสถานะสินค้า แต่ไม่ต้องการให้ AI เปลี่ยนสัญญา ยืนยันราคา หรือส่งข้อมูลส่วนตัวโดยไม่รู้ตัว

ถ้า Agent บอกขอบเขตตั้งแต่ต้น ลูกค้าจะรู้ว่าควรสั่งงานต่อหรือเรียกคน

ลดความรู้สึกว่าธุรกิจกำลังแอบใช้ Bot

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

การแนะนำตัวตรง ๆ สั้น ๆ ดีกว่าซ่อนรายละเอียดไว้ในหน้าเงื่อนไขที่ไม่มีใครเปิดอ่าน

ทำให้ทีมออกแบบอำนาจของ Agent ชัดขึ้นในทางปฏิบัติ

แม้ Article 50(1) ไม่ได้กำหนด Action Boundary หรือ Human Handoff ไว้เป็นข้อบังคับ การเขียนว่า Agent ทำงานแทนใครและทำอะไรได้ก็ช่วยให้เราเห็นช่องโหว่ของ workflow เอง เช่น

• Agent ตอบข้อมูลได้ แต่แก้ข้อมูลลูกค้าไม่ได้
• Agent ร่างข้อเสนอได้ แต่ส่งไม่ได้จนกว่าคนจะยืนยัน
• Agent เช็กคำสั่งซื้อได้ แต่คืนเงินไม่ได้
• Agent นัดหมายได้ แต่ทำสัญญาไม่ได้

นี่คือ operational best practice ที่ช่วยให้ทีมเข้าใจขอบเขตของระบบตัวเอง ไม่ใช่ legal requirement ใน Article 50

3) ใช้กับงานของตัวเองยังไง

เริ่มจากทำ inventory ทุกจุดที่ AI คุยกับคนโดยตรง ไม่ว่าจะเป็นหน้าเว็บ, LINE, Facebook, email, voice agent หรือ inbox ภายในบริษัท แล้วแยกงานเป็น 3 ชั้น

1. Legal core จาก Article 50(1): Provider ออกแบบและพัฒนาให้คนรู้ว่ากำลังโต้ตอบกับ AI หากไม่เข้า obviousness exception
2. Non-binding Commission guidance: บอกว่าทำงานแทนใคร แจ้งใน key step และแจ้งทุก interaction ใหม่
3. Operational best practice: อธิบาย Job Scope, Action Boundary และ Human Handoff

ข้อความแรกตาม legal core และ guidance

อย่างน้อยต้องออกแบบให้ผู้ใช้ได้รับข้อมูลว่ากำลังคุยกับ AI ตาม Article 50(1) ส่วนชื่อองค์กร ขอบเขตงาน และวิธีเรียกคนในตัวอย่างนี้เป็น guidance และ best practice ที่ช่วยลดความกำกวม

สวัสดีครับ ผมเป็น AI Assistant ของ [ชื่อองค์กร]
ช่วยเรื่อง [ขอบเขตงาน] ได้
ถ้าต้องการคุยกับเจ้าหน้าที่ พิมพ์ [คำสั่งหรือวิธีติดต่อ]

ก่อนทำงานที่มีผลจริง เป็น operational best practice

ถ้า Agent กำลังจะจอง เปลี่ยนข้อมูล ส่งข้อความ ซื้อสินค้า หรือทำ action ที่ย้อนกลับยาก การย้ำสิ่งที่กำลังจะทำและขอการยืนยันในจุดที่เหมาะสมเป็นวิธีคุม workflow ที่ดี ไม่ใช่ข้อกำหนด verbatim ใน Article 50(1)

ผมกำลังจะเปลี่ยนที่อยู่จัดส่งของคำสั่งซื้อ [เลขอ้างอิง]
จาก [ข้อมูลเดิม] เป็น [ข้อมูลใหม่]
ยืนยันให้ดำเนินการหรือไม่

ตอนรายงานผลตาม guidance และ best practice

Commission Guidelines พูดถึง reporting ใน key step ส่วนการไม่เขียนเหมือนงานสำเร็จเมื่อ Agent เพียงร่างคำตอบหรือส่งคำขอไปยังระบบหลังบ้านเป็น operational best practice

ผมส่งคำขอเปลี่ยนที่อยู่แล้ว
สถานะปัจจุบัน: รอระบบยืนยัน
ถ้าไม่สำเร็จภายใน [เวลา] จะส่งต่อให้เจ้าหน้าที่

Operator Kit: AI Agent Disclosure Card 6 ช่อง

ใช้ checklist นี้ตรวจ Agent หนึ่งตัวได้ภายใน 15 นาที โดยดูป้ายกำกับให้ชัด

• Legal core: ข้อบังคับจาก Article 50(1)
• Commission guidance: แนวทางตีความปี 2026 ที่ไม่มีผลผูกพันเหมือน Regulation
• Operational best practice: วิธีออกแบบ workflow ของทีม ไม่ใช่ข้อกำหนดใน Article 50

1. AI Identity

Legal core: Provider ต้องออกแบบและพัฒนาให้บุคคลรู้ว่ากำลังโต้ตอบกับ AI หากความเป็น AI ไม่ได้เห็นชัดอยู่แล้วตาม circumstances และ context

ข้อความแนะนำตัว:

2. Acting For

Commission guidance: Agent บอกหรือไม่ว่าทำงานแทนบุคคล บริษัท แบรนด์ หรือทีมใด เรื่องนี้ไม่ใช่ถ้อยคำ verbatim ใน Article 50(1)

Agent ทำงานในนามของ:

3. Job Scope

Operational best practice: ผู้ใช้รู้หรือไม่ว่า Agent ช่วยเรื่องอะไรได้ และเรื่องอะไรทำไม่ได้ นี่ไม่ใช่ legal requirement ใน Article 50

ทำได้:
ทำไม่ได้:

4. Action Boundary

Operational best practice: แยกให้ชัดว่า Agent แค่ตอบ, ร่าง, ขออนุญาต หรือทำ action จริง Action Boundary ไม่ใช่ legal requirement ใน Article 50

Read:
Draft:
Request approval:
Execute:

5. Key-step Message

Commission guidance: กำหนดข้อความสำหรับจังหวะสำคัญอย่างการขออนุญาต รายงานผล ยืนยันการทำงาน และเริ่ม interaction ใหม่ ทั้ง key-step disclosure และ every-new-interaction เป็นแนวทางตีความ ไม่ใช่ถ้อยคำ verbatim ใน Regulation

ก่อนลงมือ:
หลังลงมือ:
เมื่อเริ่ม interaction ใหม่:

6. Human Handoff

Operational best practice: บอกวิธีเรียกคน ระยะเวลาที่คาดหวัง และข้อมูลที่ Agent จะส่งต่อ Human Handoff ไม่ใช่ legal requirement ใน Article 50

คำสั่งเรียกคน:
เวลาตอบกลับโดยประมาณ:
ข้อมูลที่จะส่งต่อ:

เมื่อตรวจครบแล้ว ให้ทดลอง 5 สถานการณ์

• ลูกค้าถามว่า “คุณเป็นคนหรือ Bot”
• ลูกค้าขอให้ทำงานนอกขอบเขต
• ลูกค้าเปลี่ยนใจก่อน action สำเร็จ
• ระบบหลังบ้านตอบช้าหรือ error
• ลูกค้าขอคุยกับเจ้าหน้าที่ทันที

ถ้าผู้ใช้ยังตอบไม่ได้ว่า “ใครทำอะไรในนามของใคร” แปลว่าข้อความหรือ workflow ยังไม่ชัดพอ

5) Article 50(2) AI-content marking แยกจาก interactive disclosure

Article 50(2) เป็นข้อบังคับอีกชุดหนึ่งที่วางหน้าที่ไว้ที่ provider ของระบบ AI ซึ่งรวมถึง general-purpose AI systems ที่สร้าง synthetic audio, image, video หรือ text

Provider ต้องทำให้ output ถูกทำเครื่องหมายใน machine-readable format และตรวจจับได้ว่าเป็น AI-generated หรือ manipulated ตามเงื่อนไขของข้อกฎหมาย นี่คือเรื่อง content marking ไม่ใช่หน้าที่แจ้งตัวระหว่างสนทนาตาม Article 50(1)

ช่วงเปลี่ยนผ่านถึง 2 ธันวาคม 2026 ใช้เฉพาะภาระ Article 50(2) สำหรับระบบที่เข้าเงื่อนไขและวางตลาดก่อน 2 สิงหาคม 2026

ช่วงเปลี่ยนผ่านนี้ ไม่ได้เลื่อน การใช้ Article 50(1) สำหรับระบบที่โต้ตอบโดยตรงกับบุคคล

อีกด้านหนึ่ง Commission Guidelines อธิบายว่า backend machine-to-machine call ที่ output ไม่ได้ตั้งใจให้ไปถึงบุคคล ไม่อยู่ใน direct-interaction scope แบบเดียวกัน

ดังนั้นอย่าใช้ checklist เดียวตัดสินทุกระบบ ต้องแยกอย่างน้อย 3 เรื่อง

1. AI คุยกับคนโดยตรงหรือไม่
2. AI สร้าง content ที่คนจะเห็นหรือไม่
3. ธุรกิจอยู่ในบทบาทและตลาดใด

ขอบเขตดินแดนและบทบาทของแต่ละองค์กรอาจเปลี่ยนคำตอบได้ หาก provider หรือ deployer อยู่ใน EU, นำระบบเข้าตลาด EU, หรือ output ของระบบที่อยู่นอก EU ถูกใช้ใน EU ควรตรวจ territorial scope ตาม Article 2 และข้อเท็จจริงของ workflow

บทความนี้เป็น operational explainer ไม่ใช่คำปรึกษากฎหมาย หากระบบให้บริการใน EU หรือทำ action สำคัญแทนลูกค้า ควรให้ผู้เชี่ยวชาญตรวจบทบาท provider/deployer, territorial scope, ข้อยกเว้น และข้อความจริงอีกครั้ง

6) Data-Espresso จะเอาไปใช้ยังไง

มุมที่ Data-Espresso สนใจคือการทำให้ AI Agent เป็นเพื่อนร่วมงานที่ลูกค้าเข้าใจ ไม่ใช่ระบบที่ซ่อนตัวอยู่หลังชื่อบัญชี

ถ้ากำลังทำ sales agent, support agent, booking agent หรือ back-office agent ลองใช้ AI Agent Disclosure Card กับ workflow เดียวก่อนครับ

Data-Espresso และ OPB Stack ช่วยแปลงข่าว AI ให้เป็น workflow, ขอบเขตงาน, ข้อความแนะนำตัว, action ที่ต้องยืนยัน และจุดส่งต่อให้คนที่ใช้งานได้จริง

เริ่มจากข้อความแรกและ action สำคัญ ไม่ต้องรอให้ระบบใหญ่สมบูรณ์ทั้งก้อน

สรุป

EU AI Act Article 50 ต้องอ่านเป็นชั้น ๆ ครับ

ข้อบังคับ Article 50(1): Provider ของระบบที่ออกแบบมาให้โต้ตอบโดยตรงกับบุคคลต้องทำให้คนรู้ว่ากำลังโต้ตอบกับ AI เว้นแต่ความเป็น AI จะเห็นได้ชัดอยู่แล้วตามสถานการณ์และบริบท

Commission guidance ที่ไม่มีผลผูกพันเหมือน Regulation: บอกว่าทำงานแทนใคร แจ้งใน key step และทุก interaction ใหม่

Operational best practice: Job Scope, Action Boundary และ Human Handoff ช่วยให้ลูกค้าเข้าใจระบบและช่วยให้ทีมคุม workflow แต่ไม่ใช่ legal requirements ใน Article 50

ส่วน Article 50(2) เป็นอีกเรื่อง คือ machine-readable marking ของ AI-generated หรือ manipulated content อย่านำมาปนกับ interactive disclosure

สำหรับธุรกิจ สิ่งที่ควรทำวันนี้คือเปิดดู Agent หนึ่งตัว แยก legal core, guidance และ best practice ให้ชัด แล้วให้ผู้เชี่ยวชาญตรวจ scope หากมีความเกี่ยวข้องกับ EU