EU AI Act มาตรา 50 สำหรับนักพัฒนา API: สิ่งที่ต้องทำเครื่องหมายและเมื่อไหร่

มาตรา 50 ของ EU AI Act: เปลี่ยนข้อกำหนดความโปร่งใสให้เป็น API contract และ CI checks มาตรา 50 ของพระราชบัญญัติ AI ของสหภาพยุโรปมีผลบังคับใช้เมื่อวันที่ 2 สิงหาคม 2026 เป็นบทว่าด้วยความโปร่งใส และเป็นบทที่น่าจะกระทบทีมวิศวกรรมทั่วไปมากที่สุด เพราะไม่ได้พิจารณาเพียงว่าระบบของคุณมีความเสี่ยงสูงหรือไม่ แต่พิจารณาว่าผู้ใช้สามารถรู้ได้หรือไม่ว่ากำลังโต้ตอบกับเครื่องจักร การรายงานข่าวส่วนใหญ่มักเน้นผู้ให้บริการโมเดล เช่น การลงนามในประมวลจริยธรรมตามมาตรา 50(2) หรือการใช้ลายน้ำใน Claude แต่หากคุณเรียกใช้โมเดลผ่าน API แล้วนำผลลัพธ์ไปแสดงในผลิตภัณฑ์ของคุณ คุณมีหน้าที่ของตัวเอง การที่ผู้ให้บริการโมเดลปฏิบัติตามข้อกำหนดไม่ได้ทำให้หน้าที่ของคุณหมดไป บทความนี้อธิบายมาตรา 50 จากมุมมองของทีมที่จัดส่ง API: แต่ละวรรคกำหนดอะไร คุณรับผิดชอบส่วนใด ข้อยกเว้นทำงานอย่างไร และจะทำให้ข้อกำหนดเหล่านี้ตรวจสอบได้ใน CI ด้วย Apidog แทนการติดตามด้วยสเปรดชีตได้อย่างไร ห้ามาตราและผู้ที่ต้องรับผิดชอบ | มาตรา | ผู้รับผิดชอบ | ข้อกำหนด | |---|---|---| | 50(1) | ผู้ให้บริการ | ระบบที่โต้ตอบโดยตรงกับผู้คนต้องทำให้ชัดเจนว่าเป็น AI เว้นแต่จะชัดเจนอยู่แล้วสำหรับบุคคลที่มีความรู้ดีพอสมควร | | 50(2) | ผู้ให้บริการ | ระบบ AI สร้างสรรค์ต้องทำเครื่องหมายเสียง รูปภาพ วิดีโอ และข้อความสังเคราะห์ในรูปแบบที่เครื่องอ่านได้ เพื่อให้ตรวจจับได้ว่าเนื้อหาถูกสร้างหรือเปลี่ยนแปลงโดย AI | | 50(3) | ผู้ใช้งาน | ระบบจดจำอารมณ์และระบบจำแนกประเภทข้อมูลชีวภาพต้องแจ้งผู้ที่ถูกเปิดเผยข้อมูล | | 50(4) | ผู้ใช้งาน | ต้องเปิดเผย Deepfake และข้อความที่สร้างโดย AI ซึ่งเผยแพร่เพื่อแจ้งข้อมูลสาธารณะในประเด็นที่เป็นสาธารณประโยชน์ | | 50(5) | ทั้งสอง | การเปิดเผยต้องเกิดขึ้นไม่เกินการโต้ตอบหรือการสัมผัสครั้งแรก และต้องชัดเจน แยกแยะได้ และเข้าถึงได้ | ประเด็นสำคัญคือการแยกบทบาทระหว่าง ผู้ให้บริการ และ ผู้ใช้งาน ไม่ได้วัดจากขนาดบริษัท แต่ขึ้นกับบทบาทที่คุณมีต่อระบบนั้น - หากคุณสร้างและนำระบบ AI สร้างสรรค์ออกสู่ตลาด EU คุณคือผู้ให้บริการ - หากคุณใช้ระบบของผู้อื่นภายใต้อำนาจของคุณเอง คุณคือผู้ใช้งาน - หากคุณนำ Claude มาอยู่ในผลิตภัณฑ์ของคุณ เปลี่ยนชื่อแบรนด์ และควบคุมประสบการณ์ผู้ใช้ คุณอาจเป็นทั้งสองฝ่ายในคนละส่วนของสแต็ก เริ่มต้นด้วยการทำ inventory ของทุก flow ที่มี AI: ระบบ: Support Chat โมเดล: third-party LLM บทบาท: ผู้ใช้งาน ผู้ใช้ปลายทาง: ลูกค้าที่คุยผ่านเว็บแชท ข้อกำหนดที่เกี่ยวข้อง: 50(1), 50(5) หลักฐานที่ต้องมี: ข้อความเปิดเผยใน UI + ฟิลด์ disclosure ใน API response 50(2): การทำเครื่องหมายที่เครื่องอ่านได้ มาตรา 50(2) คือส่วนที่ผู้ให้บริการโมเดลให้ความสำคัญ ผู้ให้บริการระบบ AI ที่สร้างเสียง รูปภาพ วิดีโอ หรือข้อความสังเคราะห์ ต้องทำให้เอาต์พุตมีเครื่องหมายที่เครื่องอ่านได้ และตรวจจับได้ว่าเนื้อหานั้นถูกสร้างหรือเปลี่ยนแปลงโดย AI กฎหมายไม่ได้กำหนดเทคนิคตายตัว แต่ระบุว่าโซลูชันต้องมีประสิทธิภาพ ทำงานร่วมกันได้ แข็งแกร่ง และเชื่อถือได้เท่าที่ทำได้ทางเทคนิค โดยคำนึงถึงประเภทเนื้อหา ต้นทุน และเทคโนโลยีที่ใช้กันทั่วไป ด้วยเหตุนี้ ตลาดจึงมักใช้สองแนวทางร่วมกัน: - การทำลายน้ำเชิงสถิติสำหรับข้อความ - ไฟล์ Manifest แบบลงนามตามมาตรฐาน C2PA สำหรับไฟล์สื่อ ไม่มีวิธีใดสมบูรณ์แบบ และข้อกำหนดก็ยอมรับข้อจำกัดนี้ ข้อยกเว้นที่ทีมเครื่องมือต้องแยกให้ออก ฟังก์ชันช่วยเหลือสำหรับการแก้ไขมาตรฐาน ระบบที่ทำหน้าที่ช่วยแก้ไขทั่วไปอาจอยู่นอกขอบเขต เช่น ตัวตรวจสอบการสะกด ตัวจัดรูปแบบ หรือ autocomplete ที่เติมคำระหว่างผู้ใช้กำลังพิมพ์ ไม่มีการเปลี่ยนแปลงข้อมูลที่ป้อนเข้าอย่างมีนัยสำคัญ หากระบบไม่เปลี่ยนข้อมูลที่ได้รับอย่างมีนัยสำคัญ มาตรา 50(2) อาจไม่มีผลบังคับใช้ เส้นแบ่งระหว่าง “ช่วยแก้ไข” กับ “สร้างหรือเปลี่ยนเนื้อหาอย่างมีนัยสำคัญ” ไม่ได้กำหนดไว้แบบตายตัว: - การเรียงลำดับคีย์ใน JSON ใหม่ ไม่ใช่การสร้างเนื้อหาสังเคราะห์ - การแก้คำสะกด ไม่ใช่การเขียนเนื้อหาใหม่ - การเขียนย่อหน้าใหม่ให้เป็นอีกโทนเสียงหนึ่ง มีแนวโน้มเกินกว่าการแก้ไขมาตรฐาน จุดนี้ควรเป็นการตัดสินใจที่ทีมกฎหมายกำหนด แล้วให้ทีมวิศวกรรมแปลงผลลัพธ์เป็น policy ที่ตรวจสอบได้ สิ่งที่ต้องบันทึกในระบบ หากคุณใช้โมเดลที่ทำเครื่องหมายเอาต์พุตแล้ว คุณอาจได้รับความครอบคลุมในส่วน 50(2) สำหรับเอาต์พุตนั้น แต่ควรบันทึกข้อมูลนี้เป็น configuration ที่ทดสอบได้ ไม่ใช่ความรู้ที่อยู่ในเอกสารภายนอก ตัวอย่าง configuration: models: model-a: provider: external-provider machine_readable_marking: true marking_effective_from: "2026-08-02" legacy-model: provider: external-provider machine_readable_marking: pending fallback_allowed: false เป้าหมายคือป้องกันกรณีที่ routing หรือ fallback เปลี่ยนโมเดลโดยเงียบ ๆ แล้วส่งผลให้เอาต์พุตสลับจาก “มีเครื่องหมาย” เป็น “ไม่มีเครื่องหมาย” 50(4): วรรคที่คุณอาจต้องรับผิดชอบ ผู้ใช้งานมีหน้าที่หลักสองประเภทตามมาตรา 50(4) 1. Deepfake หากคุณใช้งานระบบที่สร้างหรือปรับเปลี่ยนรูปภาพ เสียง หรือวิดีโอที่เป็น Deepfake คุณต้องเปิดเผยว่าเนื้อหานั้นถูกสร้างหรือปรับเปลี่ยนโดย AI สำหรับงานศิลปะ งานเสียดสี งานบันเทิง และงานลักษณะใกล้เคียงกัน ภาระการเปิดเผยเบาลง: คุณต้องเปิดเผยการมีอยู่ของเนื้อหาที่สร้างขึ้น แต่ต้องไม่ขัดขวางการแสดงผลหรือการเพลิดเพลินกับผลงาน 2. ข้อความ AI ในประเด็นที่เป็นสาธารณประโยชน์ หากคุณใช้ระบบสร้างหรือปรับเปลี่ยนข้อความที่เผยแพร่เพื่อแจ้งข้อมูลสาธารณะในประเด็นที่เป็นสาธารณประโยชน์ คุณต้องเปิดเผยว่าข้อความดังกล่าวสร้างหรือเปลี่ยนแปลงโดย AI อย่างไรก็ตาม มีข้อยกเว้นสำคัญ: ข้อกำหนดนี้ไม่มีผลเมื่อเนื้อหาผ่านการตรวจสอบโดยมนุษย์หรือการควบคุมบรรณาธิการ และมีบุคคลธรรมดาหรือนิติบุคคลที่รับผิดชอบด้านบรรณาธิการต่อการเผยแพร่ “มีคนดูผ่าน ๆ” ไม่เท่ากับการควบคุมบรรณาธิการที่รับผิดชอบได้ หากคุณดูแลห้องข่าว บล็อกนโยบาย หรือเว็บไซต์ข้อมูลสุขภาพ คุณควรเก็บหลักฐานของกระบวนการ เช่น - ผู้ตรวจสอบเนื้อหา - เวลาที่อนุมัติ - เวอร์ชันก่อนและหลังการแก้ไข - ผู้รับผิดชอบด้านบรรณาธิการ - สถานะการเผยแพร่ ตัวอย่างข้อมูล audit ที่เก็บต่อบทความ: { "content_id": "public-health-2026-001", "ai_generated": true, "human_reviewed": true, "editorial_owner": "Editorial Team", "reviewed_by": "e*****@example.com", "reviewed_at": "2026-08-10T09:15:00Z", "publication_status": "approved" } มาตรา 50(4) ไม่ได้ครอบคลุมข้อความที่เผยแพร่ทุกชนิด ตัวอย่างเช่น product copy, macro สำหรับฝ่ายสนับสนุน, code comments และบทสรุปภายใน ไม่ใช่ข้อความที่เผยแพร่เพื่อแจ้งข้อมูลสาธารณะในประเด็นที่เป็นสาธารณประโยชน์ 50(1) และ 50(5): กฎสำหรับหน้าต่างแชท มาตรา 50(1) กำหนดให้ระบบที่ตั้งใจโต้ตอบโดยตรงกับบุคคลธรรมดาต้องแจ้งให้ทราบว่ากำลังโต้ตอบกับ AI เว้นแต่จะชัดเจนอยู่แล้วสำหรับบุคคลที่มีข้อมูลดีพอสมควร ช่างสังเกต และรอบคอบ ในทางปฏิบัติ อย่าพึ่งพาคำว่า “ชัดเจน” มากเกินไป - วิดเจ็ตที่ระบุชัดว่า “AI Assistant” มีความเสี่ยงต่ำกว่า - ช่องทางสนับสนุนที่ AI ตอบด้วยชื่อและบุคลิกมนุษย์โดยไม่มีการระบุ มีความเสี่ยงสูงกว่า มาตรา 50(5) เพิ่มข้อกำหนดด้านเวลาและการเข้าถึง: - ต้องเปิดเผยไม่เกินเวลาที่มีการโต้ตอบครั้งแรก - ต้องชัดเจน - ต้องแยกแยะได้ - ต้องเข้าถึงได้ การซ่อนข้อความปฏิเสธความรับผิดชอบไว้ในข้อกำหนดการใช้งานไม่ใช่การเปิดเผยในการโต้ตอบครั้งแรก ทำให้ disclosure เป็นส่วนหนึ่งของ API response หาก API ของคุณส่งเอาต์พุตโมเดลให้ UI ของทีมอื่นหรือให้ลูกค้าภายนอก อย่าปล่อยให้การเปิดเผยเป็นเพียงการตัดสินใจของ UI ให้ส่ง metadata ไปกับ response และระบุไว้ใน OpenAPI contract ตัวอย่าง OpenAPI schema: components: schemas: ChatResponse: type: object required: - message - ai_disclosure properties: message: type: string description: ข้อความตอบกลับสำหรับผู้ใช้ ai_disclosure: type: object required: - generated_by_ai - disclosure_required properties: generated_by_ai: type: boolean example: true disclosure_required: type: boolean example: true model_id: type: string example: "model-a" ตัวอย่าง response: { "message": "ฉันเป็นผู้ช่วย AI และสามารถช่วยค้นหาข้อมูลเกี่ยวกับคำสั่งซื้อของคุณได้", "ai_disclosure": { "generated_by_ai": true, "disclosure_required": true, "model_id": "model-a" } } การมีฟิลด์นี้ไม่ได้แทนที่ข้อความใน UI แต่ช่วยให้ผู้เรียก API รู้ว่าต้องแสดง disclosure และช่วยให้ระบบ downstream ตรวจสอบ policy ได้ อ่านเพิ่มเติม: การเพิ่มการเปิดเผย AI ให้กับ API ของคุณเอง วันที่สำคัญและสิ่งที่ยังเปลี่ยนแปลงได้ 2 สิงหาคม 2026 มาตรา 50 มีผลบังคับใช้ นี่คือวันเดดไลน์หลัก 10 มิถุนายน 2026 มีการเผยแพร่ประมวลจริยธรรมว่าด้วยความโปร่งใสของเนื้อหาที่สร้างโดย AI คณะกรรมาธิการและคณะกรรมการ AI ยืนยันว่าเป็นเครื่องมือสมัครใจที่เพียงพอสำหรับการแสดงให้เห็นถึงการปฏิบัติตามข้อกำหนด องค์กรประมาณ 190 แห่งลงนามภายในสิ้นเดือนกรกฎาคม รวมถึง Anthropic การลงนามเป็นไปโดยสมัครใจ การไม่ลงนามหมายความว่าหน่วยงานเฝ้าระวังตลาดจะประเมินแนวทางของคุณเป็นรายกรณี 2 ธันวาคม 2026 มีรายงานอย่างกว้างขวางว่าเป็นวันขยายเวลาสำหรับระบบ AI สร้างสรรค์ที่มีอยู่ในตลาดก่อนวันที่ 2 สิงหาคม 2026 เพื่อปฏิบัติตามข้อกำหนดการทำเครื่องหมายที่เครื่องอ่านได้ตามมาตรา 50(2) ผ่านแพ็กเกจ AI Omnibus ที่ตกลงกันชั่วคราวในเดือนพฤษภาคม 2026 ให้ถือว่าวันนี้เป็นเป้าหมายที่อาจเปลี่ยนแปลงได้ และยืนยันข้อความสุดท้ายกับที่ปรึกษากฎหมาย แทนการวางแผนจากพาดหัวข่าว การเปลี่ยนแปลงของ Anthropic อยู่ในช่วงเวลานี้เช่นกัน โมเดล Claude ที่เปิดตัวในหรือหลังวันที่ 2 สิงหาคม 2026 จะมีการทำเครื่องหมายตั้งแต่เปิดตัว ส่วนโมเดลเก่ากำลังได้รับการปรับปรุง หากผลิตภัณฑ์ของคุณอ้างอิง model ID เก่า คุณกำลังพึ่งพาการปรับปรุงนั้นให้เสร็จสมบูรณ์ ค่าใช้จ่ายของการไม่ปฏิบัติตามข้อกำหนด การละเมิดมาตรา 50 อยู่ในระดับโทษที่สองของ มาตรา 99: สูงสุด 15 ล้านยูโร หรือ 3% ของยอดขายรวมทั่วโลกประจำปีสำหรับปีงบประมาณก่อนหน้า แล้วแต่จำนวนใดสูงกว่า สำหรับ SME ที่มีคุณสมบัติเหมาะสม จะใช้จำนวนที่ต่ำกว่า เพื่อเปรียบเทียบ: - การปฏิบัติที่ต้องห้าม: สูงสุด 35 ล้านยูโร หรือ 7% - การให้ข้อมูลที่ทำให้เข้าใจผิดแก่หน่วยงาน: สูงสุด 7.5 ล้านยูโร หรือ 1% - การละเมิดข้อกำหนดความโปร่งใส: สูงสุด 15 ล้านยูโร หรือ 3% การบังคับใช้ดำเนินการผ่านหน่วยงานเฝ้าระวังตลาดระดับชาติ เปลี่ยนข้อกำหนดให้เป็นงานวิศวกรรม การตีความกฎหมายไม่ใช่งานของทีมวิศวกรรม แต่ทีมวิศวกรรมต้องทำให้ผลการตัดสินใจนั้นถูกบังคับใช้และตรวจสอบซ้ำได้ 1. ระบุบทบาทของแต่ละระบบ ทำตารางที่ระบุว่าแต่ละระบบหรือแต่ละเส้นทาง API ทำหน้าที่เป็นผู้ให้บริการหรือผู้ใช้งาน | ระบบ | บทบาท | โมเดล | ข้อกำหนดที่เกี่ยวข้อง | |---|---|---|---| | Customer chat | ผู้ใช้งาน | โมเดลบุคคลที่สาม | 50(1), 50(5) | | Public content generator | ผู้ใช้งาน | โมเดลบุคคลที่สาม | 50(4), 50(5) | | โมเดลที่คุณนำออกสู่ตลาดเอง | ผู้ให้บริการ | โมเดลขององค์กร | 50(2) | ทำตารางนี้ให้เป็นส่วนหนึ่งของ architecture review หรือ release checklist ไม่ใช่เอกสารที่ไม่เคยอัปเดต 2. ระบุสถานะการทำเครื่องหมายใน model configuration บันทึกว่า model ID ใดทำเครื่องหมายเอาต์พุตและเริ่มใช้เมื่อใด ตรวจสอบให้ครอบคลุม: - โมเดลหลัก - โมเดล fallback - โมเดลที่ใช้กับ cached response - โมเดลที่ใช้ใน region หรือ environment ต่างกัน - model ID ที่ถูก pin ไว้ในระบบเก่า 3. ทำให้ disclosure เป็น API contract กำหนดฟิลด์ disclosure เป็น required field สำหรับทุก endpoint ที่อ