ทำไม AI Agent ของคุณต้องมีชั้นกำกับดูแลข้อมูล

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

การตรวจสอบที่ฉันเคยสอบตก

ลูกค้าบริหารบริษัทโฮมเซอร์วิส มีพนักงานหกสิบคน รับคำขอจองสัปดาห์ละประมาณสี่ร้อยรายการ Agent คัดแยกจดหมายด้วยเครื่องมือสี่ตัวคือ read_inbox check_calendar create_booking และ send_sms ฉันบันทึกพรอมต์และผลดิบจากเครื่องมือลงตาราง Postgres ตารางเดียวชื่อ agent_logs เก็บเป็นข้อความดิบ แถวครึ่งหนึ่งไม่มี session id เบอร์โทรและอีเมลวางเป็นข้อความเปลือย โพรเจกต์คริปโตตั้งคำถามเรื่องระเบียนแบบเดียวกัน และฉันเดินผ่านร่องรอยตรวจสอบนั้นในบทความ ออกแบบสำหรับ Web3: จุดที่ความไว้ใจพบกับกฎระเบียบ ทีมงานเก็บทุกอย่างไว้ตลอดเผื่อใช้เทรนโมเดล

ก่อนดีลพาร์ตเนอร์ ผู้ตรวจสอบภายนอกมาถึงและถามสามข้อ ข้อแรกให้ลิสต์ทุกระเบียนลูกค้าที่ Agent เปิดในวันที่ 12 มีนาคม ข้อสองให้แสดงว่าใครอนุมัติ SMS สี่สิบฉบับที่ Agent ส่งในสัปดาห์นั้น ข้อสามให้ระบุวันลบบทสนทนาที่มีเบอร์โทร

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

ผู้ตรวจสอบขอระเบียน ความตั้งใจโน้มน้าวพวกเขาไม่ได้ ทุกวันนี้ Agent ทุกตัวที่ฉันส่งมอบมีชั้นกำกับดูแลเล็กๆ ตั้งแต่ วันแรก ก่อนแตะข้อมูลลูกค้า ชั้นนี้มีสามส่วน ฉันคงชั้นให้สั้นพอที่คนจะอ่านได้ว่าโมเดลแตะอะไรมาก่อนจะไว้วางใจ เส้นเรื่องการกำกับดูแลนี้ฉันลากไว้ในบทความ Glass-box AI: แสดงความมั่นใจของโมเดลเพื่อให้คนไว้วางใจ

ชั้นสามส่วน: บันทึกการเรียกเครื่องมือ การปักหมุดระยะเวลาเก็บข้อมูล การล้าง PII

บันทึกการเรียกเครื่องมือ

ทุกการเรียกเครื่องมือลงตาราง Postgres ชื่อ agent_audit คอลัมน์มี id uuid created_at timestamptz tenant_id text session_id text actor text tool_name text args_hash text args_redacted jsonb result_code text policy_decision text delete_after date ฉันเก็บแฮช SHA-256 ของอาร์กิวเมนต์เต็มบวกสำเนาที่ล้างข้อมูลส่วนบุคคลเป็นป้ายชื่อแล้ว ข้อความดิบของลูกค้าไม่เข้าตารางนี้ ดัชนีสองตัวรับโหลดคำค้นคือดัชนีบน tenant_id กับ created_at และดัชนีบน session_id

Actor มีสามค่าคือ user agent approver ทุกข้อความขาออกต้องมีแถวที่ actor เป็น approver หรือ policy_decision เป็น auto_approved พร้อมเลขกฎ เครื่องมือส่งจะปฏิเสธทำงานเมื่อไม่มีแถวนี้ เมื่อผู้ตรวจสอบถามว่า Agent แตะระเบียนใด คำค้นเดียวตอบได้คือกรอง agent_audit ด้วย session_id แล้วเรียงตาม created_at

การปักหมุดระยะเวลาเก็บข้อมูล

ทุกแถวมี delete_after ค่าเริ่มต้นเท่ากับ created_at บวกสามสิบวัน งาน pg_cron รันทุกคืนตอน 03:00 และลบแถวที่หมดอายุ คอนฟิกลูกค้าลดหน้าต่างเหลือเจ็ดวันสำหรับบทสนทนาอ่อนไหวได้ หรือขยายการจองเป็นเก้าสิบวันได้พร้อมบันทึกยินยอมจากเจ้าของข้อมูล ค่าเริ่มต้นคงสามสิบวัน การลบถูกนับเป็นตัวเลขรายลูกค้าว่าลบกี่แถว แถวเก่าสุดที่เหลือคืออะไร เมื่อผู้ตรวจสอบถามว่าบทสนทนาหายเมื่อไร ฉันแสดงบรรทัดคอนฟิกกับตัวเลขเดือนก่อน

ไปป์ไลน์ล้าง PII

สองรอบทำงานก่อนข้อมูลลงดิสก์ รอบแรกใช้ regex หาอีเมล เบอร์โทร เลขบัตร IBAN และรูปแบบบัตรประชาชนของประเทศที่ฉันรับงาน รอบสองส่งข้อความผ่านโมเดลภาษาขนาดเล็กที่แท็กชื่อ ที่อยู่ถนน และวันเกิดในข้อความอิสระ รวมคำที่สะกดผิดซึ่ง regex พลาด ข้อความที่ล้างแล้วลงบันทึกและความจำของ Agent ต้นฉบับลงห้องนิรภัยเข้ารหัสที่มี TTL เจ็ดวัน เปิดอ่านได้ผ่านบทบาท break-glass เท่านั้น และทุกการอ่านเขียนแถวบันทึกของตัวเอง

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

ต้นทุนการสร้างเทียบกับต้นทุนการรั่วไหล

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

เทียบกับบิลที่ฉันเห็นบริษัทเซอร์วิสสี่สิบคนจ่ายหลังเหตุข้อมูลเกือบรั่วไหลครั้งหนึ่งคือประมาณ $35,000 ครอบคลุมรีวิวกฎหมาย แจ้งลูกค้า และงานแก้สามสัปดาห์ พนักงานกลับไปกรอกมือเงียบๆ หลังความไว้ใจในเครื่องมือตก ชั้นนี้ต้นทุนสร้างประมาณ $2,500 เหตุครั้งนั้นแพงกว่าสิบสี่เท่า ยังไม่นับความไว้ใจที่หายไป

เช็กลิสต์ที่คัดลอกไปใช้ได้เลย

รันลิสต์นี้กับ Agent ปัจจุบันของคุณในสัปดาห์นี้ ติ๊กทีละข้อหรือเปิดตั๋วงานสำหรับข้อที่ขาด

1. สร้าง agent_audit ด้วยสิบเอ็ดคอลัมน์ข้างบนบวกดัชนีทั้งสองตัว
2. ให้ทุกเซสชันมี session_id คงที่ตั้งแต่ข้อความแรก
3. บันทึกทุกการเรียกเครื่องมือ ห้ามมีการเรียกเงียบ
4. เก็บ args_hash บวกอาร์กิวเมนต์ที่ล้างแล้ว ข้อความดิบของลูกค้าห้ามเข้าบันทึก
5. ปัก delete_after ทุกแถว ยึดค่าเริ่มต้นสามสิบวัน
6. ตั้งงานลบทุกคืน แจ้งเตือนเมื่อมันข้ามรอบ
7. เพิ่มรอบล้าง regex พร้อมชุดทดสอบสองร้อยตัวอย่าง
8. เพิ่มรอบล้างโมเดลสำหรับชื่อและที่อยู่
9. เก็บต้นฉบับในห้องนิรภัย TTL เจ็ดวันหลังการเข้าถึงแบบ break-glass
10. ปล่อยข้อความขาออกได้เมื่อมีแถวอนุมัติเท่านั้น
11. ซ้อมทุกเดือน หยิบเซสชันสุ่มหนึ่งอันมาตอบสามคำถามตรวจสอบให้จบในสิบนาที
12. เก็บโน้ตการเก็บข้อมูลหนึ่งหน้า เก็บอะไร อยู่ที่ไหน อยู่นานเท่าไร ใครอนุมัติการเปลี่ยน

ฉันซ้อมแบบนี้ทุกวันจันทร์แรกของเดือน ใช้เวลายี่สิบนาที มันคงช่วยการเปิดใช้เดือนกุมภาพันธ์ 2024 ของฉันไว้ได้ ฉันเขียนสรุปไว้ในบล็อกของทีมด้วยเพื่อให้ทักษะนี้ไม่หายไปกับตัวบุคคล

สิ่งที่วัดได้

เลเยอร์ compliance เห็นได้ใน log ที่มันเขียน สิ่งที่เปลี่ยน:

ตัวชี้วัด	ก่อน	หลัง	ที่มา
tool call ที่มี log	0%	100%	log sampler