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

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

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

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

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

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

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

ชั้นสามส่วน: บันทึกการเรียกเครื่องมือ การปักหมุดระยะเวลาเก็บข้อมูล การล้าง 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 ของฉันไว้ได้ ฉันเขียนสรุปไว้ในบล็อกของทีมด้วยเพื่อให้ทักษะนี้ไม่หายไปกับตัวบุคคล