การบันทึก แนวทางการตรวจสอบ และการพิสูจน์ได้

กำไร:

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

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

เหตุใดการบันทึกจึงแตกต่างใน AI

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

ข้อควรระวัง: การบันทึกไม่ใช่ "บันทึกทุกอย่าง" การบันทึกมากเกินไปทำให้เกิดความเสี่ยงด้านความเป็นส่วนตัว และการบันทึกน้อยเกินไปจะทำให้ขาดหลักฐาน เป้าหมายคือการรักษา PII ให้เพียงพอเพื่อสร้างกิจกรรมขึ้นมาใหม่โดยการปิดบังไว้

สิ่งที่ควรเข้าสู่ระบบ? โครงสร้างเส้นทางการตรวจสอบ

เส้นทางการตรวจสอบ AI ที่มั่นคงประกอบด้วยอย่างน้อย:

• ใคร: ID ผู้ใช้และบทบาท (หรือ ID บริการ)
• เมื่อ: การประทับเวลา (ผนวกเท่านั้นหากเป็นไปได้)
• อะไร: การกระทำที่ต้องการและเครื่องมือที่เรียกออกมา
• รุ่นใด: ชื่อรุ่นและเวอร์ชัน (เช่น claude-opus-4-8) พารามิเตอร์ที่สำคัญ เช่น อุณหภูมิ
• สรุปอินพุต/เอาต์พุต: เวอร์ชันที่ปกปิดหรือสรุป/แฮชของคำขอและการตอบกลับ
• การตัดสินใจ: มีการประมวลผลโดยอัตโนมัติ ส่งถึงมือมนุษย์ ได้รับการอนุมัติหรือปฏิเสธหรือไม่
• ผลลัพธ์: การดำเนินการสำเร็จหรือมีข้อผิดพลาด ทรัพยากรใดได้รับผลกระทบ

ทีละขั้นตอน: สร้างเส้นทางการตรวจสอบ

1. ตั้งเป้าหมาย. ใครจะอ่านบันทึกเหล่านี้และเพราะเหตุใด (การตอบสนองต่อเหตุการณ์ การตรวจสอบการปฏิบัติตามกฎระเบียบ การแก้ไขจุดบกพร่อง) วัตถุประสงค์จะกำหนดสิ่งที่คุณเก็บไว้
2. บังคับใช้นโยบาย PII ปิดบังพรอมต์/การตอบกลับก่อนเข้าสู่ระบบ (หน่วยที่ 2)
3. ให้ความไม่เปลี่ยนรูป ปล่อยให้บันทึกที่สำคัญต่อท้ายเท่านั้น ไม่มีใครควรจะสามารถลบอดีตอย่างเงียบ ๆ ได้
4. กำหนดระยะเวลาการเก็บรักษา กำหนดระยะเวลาตามความสมดุลของข้อกำหนดทางกฎหมายและการรักษาความลับ ลบโดยอัตโนมัติเมื่อหมดเวลา
5. จำกัดการเข้าถึง การเข้าถึงบันทึกควรได้รับการป้องกันด้วย RBAC การอ่านบันทึกควรถูกบันทึกด้วย
6. เพิ่มรหัสสหสัมพันธ์ (รหัสติดตาม) เชื่อมต่อทุกขั้นตอนของคำขอ (อินพุต การเรียกเครื่องมือ การยืนยัน เอาต์พุต) ด้วยข้อมูลประจำตัวเดียว

เทมเพลตที่คัดลอกได้สี่แบบ

สคีมาบันทึกการตรวจสอบ (JSON):

{ "trace_id": "...", "time": "YYYY-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary": "<masked>", "response_summary": "<masked>", "tools": ["tool_a", "tool_b"], "decision": "auto|human_approval", "approval": "approved|rejected|none", "result": "success|error", "affected_resource": "..."}

พรอมต์การควบคุม Log PII:

ดูตัวอย่างบันทึกด้านล่าง ช่องที่ต้องกรอกสำหรับเส้นทางการตรวจสอบ (ใคร เมื่อใด แบบจำลอง การตัดสินใจ ผลลัพธ์) เสร็จสมบูรณ์หรือไม่ PII ดิบยังรั่วไหลออกมาด้วยหรือไม่ สำหรับแต่ละแถว ให้รายงานว่า: "ไม่เพียงพอ / ไม่มีพื้นที่: ... /PII รั่วไหล: ..." <logs>{{ ตัวอย่าง }}</logs>

พรอมต์เหตุการณ์สร้างใหม่:

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

กฎการตัดสินใจนโยบายการเก็บรักษา:

สำหรับบันทึกแต่ละประเภท ให้พิจารณาว่า:- มีภาระผูกพันในการเก็บรักษาตามกฎหมายหรือไม่ (ระยะเวลาขั้นต่ำ ถ้ามี)- มี PII หรือไม่ (หากรวมไว้ ให้ลดระยะเวลา จำกัดการเข้าถึง)- หลักฐานของเหตุการณ์ด้านความปลอดภัย? (ไม่สามารถเปลี่ยนแปลงร้านค้าได้) ผลลัพธ์: "เก็บ N วัน + ต่อท้ายเฉพาะ mi + ระดับการเข้าถึง"

พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง

วิธีการที่ไม่ดี

แนวทางที่แข็งแกร่ง

ไม่เข้าสู่ระบบเลย ("ไม่จำเป็น")

การบันทึกชุดขั้นต่ำเพื่อสร้างเหตุการณ์ใหม่

กำลังบันทึกพร้อมท์/ตอบกลับแบบดิบตามที่เป็นอยู่

สรุปมาสก์ + การบันทึก ID ติดตาม

จัดเก็บบันทึกได้ไม่จำกัด

ระยะเวลาการเก็บรักษาที่มีความสมดุลระหว่างกฎหมาย + ความเป็นส่วนตัว

ใครๆ ก็สามารถลบบันทึกได้

บันทึกที่สำคัญเป็นส่วนต่อท้ายเท่านั้น มีการควบคุมการเข้าถึง

มินิเคสสามอัน

กรณีที่ 1 — Trace ID ลดการตรวจสอบในหนึ่งวันลงเหลือ 15 นาที “ใบสมัครของฉันถูกปฏิเสธอย่างไม่ยุติธรรม” ลูกค้ารายหนึ่งกล่าวกับผู้ช่วยประเมินเครดิตล่วงหน้าของธนาคาร ด้วย ID ความสัมพันธ์ ทีมจึงสร้างอินพุตของแอปพลิเคชัน การยืนยันพนักงาน และการตัดสินใจขึ้นมาใหม่ภายใน 15 นาที แสดงให้เห็นว่าข้อผิดพลาดเกิดจากเกณฑ์ที่ไม่ถูกต้องในการตรวจสอบกฎและทำการแก้ไขแล้ว

กรณีที่ 2 — พบการบันทึกที่มากเกินไปในการตรวจสอบ บริษัทอีคอมเมิร์ซแห่งหนึ่งกำลังเขียนพร้อมท์/ตอบกลับทั้งหมดลงในบันทึกข้อมูลดิบเพื่อการแก้ไขจุดบกพร่อง ในระหว่างการตรวจสอบประจำปี พบว่าบันทึกเหล่านี้มีที่อยู่และหมายเลขโทรศัพท์ของลูกค้า และถูกเก็บไว้เป็นเวลา 2 ปี การค้นพบนี้ปิดลงโดยการเปลี่ยนไปใช้นโยบายการปกปิด + การเก็บรักษา 90 วัน ฟังก์ชั่นเส้นทางการตรวจสอบยังคงอยู่

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

เคล็ดลับ: กำหนดรหัสความสัมพันธ์ (รหัสการติดตาม) ให้กับแต่ละคำขอและดำเนินการผ่านทุกขั้นตอน เมื่อเกิดปัญหา ความสามารถในการรวบรวม "ทุกอย่างเกี่ยวกับคำขอนั้น" ด้วยการสืบค้นเพียงคำเดียวคือตัวเร่งที่ใหญ่ที่สุดในการตอบสนองต่อเหตุการณ์

ข้อผิดพลาดทั่วไป

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

โดยสรุป

• การบันทึกของ AI จะเพิ่มมิติสามมิติให้กับ "ใครทำอะไร" ได้แก่ รุ่น/เวอร์ชันใด ข้อความแจ้งเตือนใด และการตอบสนองใด
• เป้าหมายคือการรักษา PII ให้น้อยที่สุดเพียงพอที่จะสร้างกิจกรรมขึ้นใหม่โดยการปกปิด ไม่มากไม่น้อยไปกว่านี้
• เส้นทางการตรวจสอบควรรวมฟิลด์ใคร/เมื่อ/อะไร/แบบจำลอง/การตัดสินใจ/ผลลัพธ์
• บันทึกที่สำคัญควรต่อท้ายเท่านั้น ควรจำกัดการเข้าถึง และควรบันทึกการเข้าถึงบันทึกด้วย
• Correlation ID (Trace ID) เชื่อมต่อทุกขั้นตอนของคำขอและเร่งการสืบสวนเหตุการณ์ให้เร็วขึ้น

งานสมัคร

เลือกคำขอจากโฟลว์ AI ของคุณเอง และเขียนแนวทางการตรวจสอบที่เหมาะสมที่สุดด้วยสคีมา JSON ด้านบน จากนั้นทำการทดสอบสองครั้ง: (1) คุณสามารถเล่าเรื่องตั้งแต่ต้นจนจบด้วยการบันทึกนี้ได้หรือไม่? (2) มี PII ดิบอยู่ในบันทึกหรือไม่ หากไม่มีช่องให้เพิ่ม หากมี PII ให้ปิดบัง สุดท้าย ให้กำหนดระยะเวลาเก็บรักษาและระดับการเข้าถึง

รายการตรวจสอบ

• [ ] เส้นทางการตรวจสอบประกอบด้วยช่องใคร/เมื่อ/อะไร/รูปแบบ/การตัดสินใจ/ผลลัพธ์
• [ ] พรอมต์/การตอบกลับถูกมาสก์ก่อนบันทึก (ไม่มี PII)
• [ ] ID สหสัมพันธ์ (Trace ID) ถูกกำหนดให้กับแต่ละคำขอ
• [ ] บันทึกที่สำคัญจะต่อท้ายเท่านั้นและควบคุมการเข้าถึง
• [ ] ระยะเวลาการจัดเก็บถูกกำหนดโดยยอดทางกฎหมาย + การรักษาความลับ และจะถูกลบเมื่อสิ้นสุดระยะเวลา
• [ ] ด้วยบันทึก ฉันสามารถสร้างกิจกรรมขึ้นมาใหม่ได้ภายในเวลาไม่ถึง 30 นาที