วิธีเพิ่มการเปิดเผย AI ใน API ของคุณ

อินเทอร์เฟซผู้ใช้แชทของคุณมีป้ายเล็กๆ ที่เขียนว่า “AI-generated” ใต้การตอบกลับทุกครั้ง ดีแล้ว ตอนนี้ทีมพันธมิตรเรียกใช้เอนด์พอยต์ /summarize ของคุณจากงานแบบแบตช์ (batch job) เขียนผลลัพธ์ลงในฐานข้อมูล และแสดงผลในรายงานที่ลูกค้าเห็น ป้ายของคุณไม่ได้ช่วยอะไรเลย

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

ตั้งแต่วันที่ 2 สิงหาคม 2026 เป็นต้นไป มาตรา 50 ของกฎหมาย EU AI Act ทำให้เรื่องนี้เป็นรูปธรรมสำหรับหลายทีม ผู้ให้บริการโมเดลอย่าง Anthropic ทำเครื่องหมายผลลัพธ์ของตนในระดับโมเดล แต่หน้าที่ในการบอกผู้คนว่าพวกเขากำลังติดต่อกับ AI อยู่กับผู้ที่ใช้งานระบบนั้นๆ หาก API ของคุณอยู่ตรงกลางระหว่างสองส่วนนี้ คุณคือเหตุผลที่ผู้เรียกใช้ของคุณสามารถปฏิบัติตามได้หรือไม่

นี่คือวิธีที่จะใส่การเปิดเผยข้อมูลลงในสัญญาแทนที่จะเป็นอินเทอร์เฟซ: สิ่งที่ต้องส่งคืน, จะวางไว้ที่ใด, วิธีจัดทำเอกสาร, และวิธีทดสอบเพื่อให้รอดจากการปรับโครงสร้างใหม่ครั้งต่อไป Apidog ครอบคลุมด้านการออกแบบ, เอกสาร, และการทดสอบไว้ในที่เดียว

สิ่งที่ควรอยู่ในผลตอบกลับ

สามสิ่งนี้ตอบคำถามที่แตกต่างกันสามข้อ

สร้างขึ้นมาหรือไม่? บูลีน หรือดีกว่านั้นคือ enum ai_generated: true เป็นจุดเริ่มต้นที่ดี แต่ generation: "synthetic" | "assisted" | "human" มีประโยชน์มากกว่า เพราะ “Claude ปรับปรุงฉบับร่างของมนุษย์” และ “Claude เขียนทั้งหมด” นั้นแตกต่างกันอย่างแท้จริง และข้อยกเว้นของมาตรา 50 ก็ถือว่าแตกต่างกัน

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

เรารู้อะไรบ้าง? สถานะแหล่งที่มา (Provenance status) หากคุณตรวจสอบแล้ว เก็บสิ่งนี้แยกต่างหากจากแฟล็กการสร้าง เพราะ “เราสร้างสิ่งนี้” คือข้อเท็จจริงที่คุณเป็นเจ้าของ และ “เราได้ยืนยัน C2PA manifest” คือการสังเกตที่คุณทำขึ้น

รูปแบบที่คงทน:

{
  "id": "sum_4f81a2",
  "content": "The incident affected two regions for 41 minutes...",
  "ai": {
    "generation": "synthetic",
    "vendor": "anthropic",
    "model": "claude-opus-5",
    "human_review": false,
    "generated_at": "2026-08-11T09:14:22Z"
  },
  "provenance": {
    "status": "unchecked",
    "standard": null
  }
}

สองรายละเอียดที่ควรให้ความสำคัญ

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

provenance.status มีสถานะมากกว่าสองสถานะ verified, absent, invalid และ unchecked ล้วนมีความหมายแตกต่างกัน และการรวมสิ่งเหล่านี้เข้าเป็นบูลีนจะทำให้ข้อมูลที่เป็นประโยชน์หายไป การหยุดชะงักของบริการยืนยันของคุณไม่ควรดูเหมือนกับผลลัพธ์ที่สะอาด

เฮดเดอร์หรือเนื้อหา?

ทั้งสองอย่าง สำหรับผู้บริโภคที่แตกต่างกัน

เนื้อหาคือความจริง เป็นสิ่งที่ถูกจัดเก็บ บันทึก เล่นซ้ำ และส่งต่อลงไป หากผู้เรียกใช้เก็บเฉพาะ JSON ที่แยกวิเคราะห์แล้ว การเปิดเผยข้อมูลจำเป็นต้องอยู่ในนั้น

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

HTTP/1.1 200 OK
Content-Type: application/json
X-AI-Generated: synthetic
X-AI-Model: anthropic/claude-opus-5

สองกฎสำหรับเฮดเดอร์: ทำให้มันสอดคล้องกันในทุกเอนด์พอยต์ เพราะเฮดเดอร์ที่ปรากฏในบางเส้นทางนั้นแย่กว่าเฮดเดอร์ที่ไม่ปรากฏเลย และอย่าถือว่าเฮดเดอร์เป็นข้อมูลที่น่าเชื่อถือหากเนื้อหาไม่ตรงกัน เลือกหนึ่งอย่างให้เป็นข้อมูลหลัก บันทึกว่าอันไหน และให้การทดสอบของคุณบังคับใช้

สำหรับการตอบกลับแบบสตรีมมิง ให้ใส่การเปิดเผยข้อมูลในเหตุการณ์แรกหรือในเฮดเดอร์การตอบกลับ ผู้เรียกใช้ที่เริ่มแสดงผลโทเค็นแรกไม่ควรรอจนถึงส่วนท้ายเพื่อทราบว่าพวกเขากำลังแสดงผลอะไร หากคุณยังใหม่กับการออกแบบเฮดเดอร์โดยทั่วไป HTTP headers คืออะไร ครอบคลุมพื้นฐานไว้

ใส่ไว้ในสเปก

ฟิลด์การเปิดเผยข้อมูลที่ไม่ได้อยู่ในคำจำกัดความ OpenAPI ของคุณเป็นเพียงข้อตกลงปฏิบัติ และข้อตกลงปฏิบัตินั้นจะเสื่อมถอยไป กำหนดให้เป็น schema ที่นำกลับมาใช้ใหม่ได้ เพื่อให้เอนด์พอยต์ที่ใช้ AI ทุกแห่งใช้รูปแบบเดียวกัน:

components:
  schemas:
    AiDisclosure:
      type: object
      required: [generation]
      properties:
        generation:
          type: string
          enum: [synthetic, assisted, human]
          description: >
            synthetic = produced by a model with no human authoring.
            assisted = a human authored the content and a model edited,
            translated, or summarised it.
            human = no model involvement.
        vendor:
          type: string
          example: anthropic
        model:
          type: string
          example: claude-opus-5
        human_review:
          type: boolean
          description: >
            True when a person reviewed the output before it was returned
            and an identifiable party holds editorial responsibility.
        generated_at:
          type: string
          format: date-time

จากนั้นอ้างอิงถึงมันทุกที่ และทำให้ ai เป็น property ที่จำเป็นในทุกการตอบกลับที่สามารถมีผลลัพธ์จากโมเดลได้ ความจำเป็นนั้นสำคัญ: ฟิลด์ที่ไม่จำเป็นคือสิ่งที่ผู้เรียกใช้ต้องเขียนโค้ดป้องกัน และส่วนใหญ่จะไม่ทำ

ประโยชน์ต่อเนื่องสองประการ เอกสารที่สร้างขึ้นของคุณจะอธิบายฟิลด์นี้ให้ผู้บริโภคทุกคนเข้าใจโดยไม่ต้องมีใครเขียนหน้า wiki และการตรวจสอบสเปกจะตรวจจับวันที่มันหายไป ซึ่งเป็นโหมดความล้มเหลวที่เกิดขึ้นจริง วิธีตรวจสอบ OpenAPI specs ครอบคลุมด้านการตรวจสอบ และ OpenAPI diff เพื่อบล็อกการเปลี่ยนแปลงที่ทำให้ระบบล่มใน CI จะตรวจจับผู้ที่แอบทำให้มันเป็นทางเลือก

เส้นทางที่คนมักลืม

ฟิลด์การเปิดเผยข้อมูลมักจะหายไปในเส้นทางที่ไม่มีใครคิดถึง สี่สิ่งที่คุณควรตรวจสอบอย่างชัดเจน

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

การตอบกลับที่มีข้อผิดพลาดและบางส่วน การหมดเวลาที่ส่งคืนสรุปบางส่วนยังคงเป็นการส่งคืนผลลัพธ์ของโมเดล หากซองจดหมายข้อผิดพลาดของคุณมีรูปร่างที่แตกต่างกัน ก็ต้องมีฟิลด์นี้ด้วย

เพย์โหลดแบตช์และเว็บฮุก การส่งแบบอะซิงโครนัสมักใช้ schema ที่บางลงซึ่งสร้างโดยโค้ดที่แตกต่างกัน นี่คือที่ที่ฟิลด์หายไปบ่อยที่สุด

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

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

ทดสอบให้เหมือนเป็นหลักประกัน

ฟิลด์การเปิดเผยข้อมูลคือคำสัญญาต่อผู้เรียกใช้ของคุณ คำสัญญาที่ไม่ได้ทดสอบก็คือเอกสารประกอบ

ห้าข้อพิสูจน์ครอบคลุมส่วนใหญ่ และเป็นการทดสอบ API ทั่วไป

1. ฟิลด์มีอยู่บนทุกเส้นทางที่ขับเคลื่อนด้วย AI

const body = pm.response.json();
pm.test("response carries AI disclosure", function () {
    pm.expect(body).to.have.property("ai");
    pm.expect(body.ai.generation).to.be.oneOf(["synthetic", "assisted", "human"]);
});

2. เฮดเดอร์ตรงกับเนื้อหา

pm.test("header and body agree", function () {
    pm.expect(pm.response.headers.get("X-AI-Generated")).to.eql(body.ai.generation);
});

3. โมเดลที่รายงานตรงกับที่คุณเรียกใช้จริง นี่คือสิ่งที่ตรวจจับการใช้งานโมเดลสำรองแบบเงียบๆ การที่ผลลัพธ์มีการทำลายน้ำต้นทางหรือไม่ขึ้นอยู่กับรหัสโมเดล ซึ่งเป็นเหตุผลที่ การทำลายน้ำ API ของ Claude ทำให้การปักหมุดโมเดลกลายเป็นรายละเอียดการปฏิบัติตามข้อกำหนดมากกว่าจะเป็นเรื่องประสิทธิภาพ

4. เส้นทางที่แคชไว้ยังคงเปิดเผยข้อมูล เรียกใช้สองครั้ง ยืนยันว่าการตอบกลับครั้งที่สองซึ่งมาจากแคช มีการเปิดเผยข้อมูลเหมือนกับครั้งแรก

5. เส้นทางข้อผิดพลาดยังคงเปิดเผยข้อมูล บังคับให้เกิดการหมดเวลาหรือความล้มเหลวปลายทาง และยืนยันว่าซองจดหมายยังคงมีฟิลด์ดังกล่าว

จัดกลุ่มสิ่งเหล่านี้เข้าเป็นสถานการณ์การทดสอบ เพิ่มการตรวจสอบ schema เทียบกับคำจำกัดความ OpenAPI ของคุณ และรันจาก apidog-cli ใน CI:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$DISCLOSURE_SCENARIO_ID" -e "$APIDOG_ENV_ID" -r cli,html

มันจะหยุดทำงานโดยส่งคืนค่าที่ไม่ใช่ศูนย์เมื่อการยืนยันล้มเหลว ดังนั้นการรวมโค้ดที่ทำให้ฟิลด์หายไปจะทำให้ build ล้มเหลวแทนที่จะถูกนำไปใช้งาน การตั้งค่า pipeline ทั้งหมดอยู่ใน การทำให้การทดสอบ API เป็นไปโดยอัตโนมัติใน GitHub Actions และรูปแบบการยืนยันทั่วไปอยู่ใน การยืนยัน API ดาวน์โหลด Apidog เพื่อสร้างสถานการณ์เทียบกับเอนด์พอยต์ของคุณเอง

จัดทำเอกสารในที่ที่ผู้เรียกใช้มองหา

สองกลุ่มเป้าหมาย สองที่

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

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

ระบุขีดจำกัดให้ชัดเจน หากคุณส่งผ่านผลลัพธ์ของ Claude ข้อความนั้นจะมีลายน้ำฝังอยู่ซึ่งคุณไม่สามารถตรวจสอบได้เอง และ Anthropic ยังไม่ได้เปิดเผยวิธีการตรวจจับ การบอกเช่นนั้นดีกว่าการบอกเป็นนัยว่าคุณมีความสามารถในการตรวจสอบที่คุณไม่มี เหตุผลอยู่ใน วิธีตรวจจับลายน้ำของ Claude

เอกสารแบบโต้ตอบช่วยได้มากกว่าปกติในที่นี้ เพราะผู้เรียกใช้สามารถเห็นฟิลด์การเปิดเผยข้อมูลในการตอบกลับแบบสดๆ แทนที่จะเชื่อตาราง การโฮสต์เอกสาร API แบบโต้ตอบพร้อมคอนโซลทดลองใช้ ครอบคลุมการตั้งค่าดังกล่าว

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

เฮดเดอร์ X-AI-Generated เป็นมาตรฐานหรือไม่? ไม่ใช่ ไม่มีเฮดเดอร์มาตรฐานที่ได้รับการรับรองสำหรับการเปิดเผยข้อมูล AI เลือกชื่อ, จัดทำเอกสาร, ทำให้สอดคล้องกัน, และถือว่ามันเป็นส่วนหนึ่งของสัญญาของคุณ

การเปิดเผยข้อมูลควรอยู่ในเฮดเดอร์หรือเนื้อหา? ทั้งคู่ เนื้อหาคือสิ่งที่ถูกจัดเก็บและส่งต่อ เฮดเดอร์ให้บริการพร็อกซี, เกตเวย์, บันทึก และการตอบกลับที่ไม่ใช่ JSON จัดทำเอกสารว่าอันไหนเป็นข้อมูลหลักหากทั้งสองไม่ตรงกัน

ฉันจำเป็นต้องทำสิ่งนี้ตามกฎหมายหรือไม่? ขึ้นอยู่กับบทบาทและเนื้อหาของคุณ ภาระผูกพันตามมาตรา 50 ตกอยู่กับผู้ให้บริการและผู้ใช้งานแตกต่างกัน และ 50(4) ครอบคลุมถึง deepfakes และข้อความที่เป็นประโยชน์ต่อสาธารณะโดยมีข้อยกเว้นสำหรับการควบคุมบรรณาธิการโดยมนุษย์ มาตรา 50 ของ EU AI Act สำหรับนักพัฒนา API อธิบายรายละเอียด การตัดสินใจทางกฎหมายเป็นของที่ปรึกษาของคุณ ส่วนระบบงานเป็นของคุณ

ผู้ให้บริการของฉันทำลายน้ำผลลัพธ์อยู่แล้ว แค่นั้นไม่พอหรือ? ไม่ใช่ ลายน้ำเป็นสัญญาณที่เครื่องจักรสามารถอ่านได้ซึ่งผู้เรียกใช้ของคุณไม่สามารถอ่านสำหรับข้อความได้ในปัจจุบัน และมันไม่ตอบสนองหน้าที่การเปิดเผยข้อมูลของคุณในฐานะผู้ใช้งาน มันเป็นส่วนเสริม ไม่ใช่สิ่งทดแทน

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

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

ฉันควรจัดเวอร์ชันฟิลด์นี้หรือไม่? มันเป็นส่วนหนึ่งของ schema การตอบกลับของคุณ ดังนั้นให้จัดเวอร์ชันเช่นเดียวกับส่วนอื่นๆ การเพิ่มค่า enum คือการเปลี่ยนแปลงที่ผู้เรียกใช้ของคุณจำเป็นต้องทราบ และความแตกต่างของสเปกใน CI จะบอกพวกเขา

ข้อคิดที่สำคัญ

การเปิดเผยข้อมูล AI ล้มเหลวในฐานะฟีเจอร์ UI และทำงานได้ดีในฐานะสัญญา ใส่ฟิลด์ที่จำเป็นในผลตอบกลับ, สะท้อนมันในเฮดเดอร์, กำหนดมันครั้งเดียวใน OpenAPI spec ของคุณ, และยืนยันมันในเส้นทางแคช, ข้อผิดพลาด, แบตช์ และเส้นทางสำรองที่มันมักจะหายไป

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