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

มาตรา 50 ของ EU AI Act: เปลี่ยนข้อกำหนดความโปร่งใสให้เป็น API contract และ CI checks

มาตรา 50 ของพระราชบัญญัติ AI ของสหภาพยุโรปมีผลบังคับใช้เมื่อวันที่ 2 สิงหาคม 2026 เป็นบทว่าด้วยความโปร่งใส และเป็นบทที่น่าจะกระทบทีมวิศวกรรมทั่วไปมากที่สุด เพราะไม่ได้พิจารณาเพียงว่าระบบของคุณมีความเสี่ยงสูงหรือไม่ แต่พิจารณาว่าผู้ใช้สามารถรู้ได้หรือไม่ว่ากำลังโต้ตอบกับเครื่องจักร

ลองใช้ Apidog วันนี้

การรายงานข่าวส่วนใหญ่มักเน้นผู้ให้บริการโมเดล เช่น การลงนามในประมวลจริยธรรมตามมาตรา 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

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

ด้วยเหตุนี้ ตลาดจึงมักใช้สองแนวทางร่วมกัน:

1. การทำลายน้ำเชิงสถิติสำหรับข้อความ
2. ไฟล์ 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-mail]",
  "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 ที่อาจส่งเอาต์พุตโมเดลกลับมา

ตัวอย่าง test case ที่ควรมี:

Given: request ถูกประมวลผลโดยโมเดล
When: เรียก POST /chat
Then:
  - response มี ai_disclosure
  - ai_disclosure.generated_by_ai เป็น true
  - ai_disclosure.disclosure_required เป็น true
  - model_id ตรงกับโมเดลที่อนุญาต

สำหรับ endpoint ที่คืนข้อมูลจาก cache ให้กำหนด contract เดียวกัน:

Given: response ถูกคืนจาก cache
Then:
  - ai_disclosure ต้องยังคงอยู่
  - disclosure ต้องไม่หายเพราะ cache layer

4. ตรวจสอบ disclosure ใน CI

ฟิลด์ disclosure ที่หายไประหว่าง refactor คือช่องว่างด้านการปฏิบัติตามข้อกำหนดที่เกิดจากการ merge โค้ด

ตรวจสอบอย่างน้อย:

• schema validation: ฟิลด์ที่ required ต้องไม่หาย
• response assertions: ค่าของ disclosure ต้องตรงกับ policy
• model assertions: model ID ต้องเป็นรุ่นที่ได้รับอนุมัติ
• regression coverage: ครอบคลุม success, error, retry และ cached response

ตัวอย่าง assertion เชิงแนวคิด:

assert(response.status === 200);
assert(response.body.ai_disclosure.generated_by_ai === true);
assert(response.body.ai_disclosure.disclosure_required === true);
assert(approvedModels.includes(response.body.ai_disclosure.model_id));

ใน Apidog คุณสามารถทำสิ่งเหล่านี้เป็น test scenario ได้:

1. ยืนยัน model ID ที่แก้ไขแล้ว
2. ยืนยัน header และ body field สำหรับ disclosure
3. ตรวจ response กับ OpenAPI schema
4. เรียก scenario ผ่าน apidog-cli ใน pipeline
5. ให้ build ล้มเหลวเมื่อ contract หรือ policy ถูกละเมิด

ดูแนวทางเพิ่มเติมได้ที่:

• วิธีตรวจสอบความถูกต้องของ OpenAPI specs
• การยืนยัน API
• การทดสอบ API ใน GitHub Actions
• ดาวน์โหลด Apidog

สำหรับทีมที่มีข้อกำกับดูแลเข้มงวด ให้ดู รายการตรวจสอบการกำกับดูแล API ที่สำคัญ และ เครื่องมือการกำกับดูแล API ที่ดีที่สุดสำหรับทีมขนาดใหญ่

คำถามที่พบบ่อย

มาตรา 50 มีผลบังคับใช้กับฉันหรือไม่ หากฉันไม่ได้อยู่ในสหภาพยุโรป?

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

ผู้ให้บริการโมเดลของฉันทำเครื่องหมายเอาต์พุตแล้ว ฉันถือว่าปฏิบัติตามข้อกำหนดหรือไม่?

ไม่ใช่ การที่ผู้ให้บริการปฏิบัติตามมาตรา 50(2) เป็นการทำตามหน้าที่ของผู้ให้บริการ หน้าที่ของคุณตามมาตรา 50(1), 50(4) และ 50(5) ในฐานะผู้ใช้งานแยกต่างหาก Anthropic ระบุในแนวทางของตนเองว่า คุณต้องประเมินอย่างอิสระว่ามาตรา 50 กำหนดอะไรสำหรับผลิตภัณฑ์และบริการของคุณ

ฉันต้องติดป้ายกำกับข้อความที่สร้างโดย AI ทุกชิ้นที่เผยแพร่หรือไม่?

ไม่ใช่ มาตรา 50(4) ครอบคลุมข้อความที่เผยแพร่เพื่อแจ้งข้อมูลสาธารณะในประเด็นที่เป็นสาธารณประโยชน์ และยังมีข้อยกเว้นหากเนื้อหาผ่านการตรวจสอบโดยมนุษย์หรือการควบคุมบรรณาธิการโดยผู้รับผิดชอบด้านบรรณาธิการ

ข้อความปฏิเสธความรับผิดชอบของแชทบอทในข้อกำหนดและเงื่อนไขการให้บริการเพียงพอหรือไม่?

ไม่ใช่ มาตรา 50(5) กำหนดให้ให้ข้อมูลอย่างช้าที่สุดเมื่อเกิดการโต้ตอบครั้งแรก ในรูปแบบที่ชัดเจน แยกแยะได้ และเข้าถึงได้

อะไรคือ Deepfake ภายใต้มาตรา 50(4)?

รูปภาพ เสียง หรือวิดีโอที่สร้างหรือปรับเปลี่ยนให้คล้ายกับคนจริง วัตถุ สถานที่ หรือเหตุการณ์จริง และอาจปรากฏว่าเป็นของแท้โดยหลอกลวง งานศิลปะ งานเสียดสี และงานบันเทิงได้รับการผ่อนปรนในข้อผูกพันด้านการเปิดเผย

ค่าปรับคืออะไร?

สูงสุด 15 ล้านยูโร หรือ 3% ของยอดขายรวมทั่วโลกประจำปีสำหรับปีงบประมาณก่อนหน้า แล้วแต่จำนวนใดสูงกว่า ตามมาตรา 99 สำหรับ SME ที่มีคุณสมบัติเหมาะสม จะใช้จำนวนที่ต่ำกว่า

เราควรลงนามในประมวลจริยธรรมหรือไม่?

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

ประเด็นสำคัญ

มาตรา 50 สั้น และส่วนที่เกี่ยวข้องกับทีม API ส่วนใหญ่สั้นยิ่งกว่า คุณอาจไม่ใช่ฝ่ายที่ต้องฝังลายน้ำในโมเดล แต่มีแนวโน้มว่าคุณคือฝ่ายที่ต้อง:

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

การแปลงเป็นงานวิศวกรรมมีสี่ข้อ:

1. รู้บทบาทของคุณ
2. รู้ว่าโมเดลใดทำเครื่องหมายเอาต์พุต
3. ใส่ disclosure ลงใน API contract
4. ทดสอบมันใน CI

ข้อสุดท้ายคือความต่างระหว่าง “นโยบายที่เขียนไว้” กับ “การรับประกันที่ระบบบังคับใช้ได้”