1. 為什么 Agent 數(shù)據(jù)治理突然成了繞不開的坎過去一年我參與過三個(gè) Agent 項(xiàng)目從內(nèi)部工具型到面向 C 端的產(chǎn)品級(jí)都有。真正讓我意識(shí)到數(shù)據(jù)治理不是“錦上添花”的是去年一個(gè)做跨境客服 Agent 的案子產(chǎn)品跑通了Demo 效果很好但準(zhǔn)備上線歐洲市場(chǎng)時(shí)法務(wù)團(tuán)隊(duì)直接叫?！?yàn)?Agent 的記憶模塊把用戶對(duì)話原文存到了境外服務(wù)器而對(duì)話里包含大量個(gè)人數(shù)據(jù)。那一刻我才明白Agent 的數(shù)據(jù)治理和傳統(tǒng)應(yīng)用完全不是一個(gè)量級(jí)的問題。傳統(tǒng)應(yīng)用的數(shù)據(jù)流是相對(duì)確定的用戶提交表單數(shù)據(jù)進(jìn)數(shù)據(jù)庫查詢、展示、刪除路徑清晰。但 Agent 不一樣。一個(gè)典型的 Agent 會(huì)涉及短期記憶、長期記憶、工具調(diào)用產(chǎn)生的中間數(shù)據(jù)、向量庫里的嵌入、外部 API 返回的結(jié)果數(shù)據(jù)在多個(gè)組件之間來回流動(dòng)而且很多流動(dòng)是模型自主決策觸發(fā)的不是工程師寫死的。這就導(dǎo)致兩個(gè)后果第一你很難畫出一張完整的數(shù)據(jù)流圖第二你很難回答“這條用戶數(shù)據(jù)到底存在哪、存了多久、被誰訪問過”這種監(jiān)管最關(guān)心的問題。EU AI Act歐盟人工智能法案和 GDPR通用數(shù)據(jù)保護(hù)條例疊加在一起對(duì) Agent 提出的要求可以粗暴地歸納成幾條數(shù)據(jù)最小化、目的限制、存儲(chǔ)期限限制、跨境傳輸合規(guī)、自動(dòng)化決策的可解釋性、以及高風(fēng)險(xiǎn)場(chǎng)景下的記錄留存。這幾條單獨(dú)看都不新鮮但落到 Agent 架構(gòu)上每一條都會(huì)逼著你重新設(shè)計(jì)記憶層、工具層和編排層。這篇內(nèi)容我想聊的就是這件事從一個(gè)實(shí)際做 Agent 開發(fā)的工程師視角把 EU AI Act、GDPR 和數(shù)據(jù)本地化這三座大山拆開講清楚它們分別卡在 Agent 的哪個(gè)環(huán)節(jié)以及我在項(xiàng)目里實(shí)際用過的應(yīng)對(duì)方案。適合正在做或準(zhǔn)備做 Agent 產(chǎn)品、尤其是要面向歐洲市場(chǎng)或者處理個(gè)人數(shù)據(jù)的同學(xué)參考。不管你是剛接觸 Agent 開發(fā)還是已經(jīng)在做數(shù)據(jù)治理相關(guān)工作希望這些踩坑經(jīng)驗(yàn)?zāi)軒湍闵僮唿c(diǎn)彎路。2. 先把三個(gè)監(jiān)管概念和 Agent 的對(duì)應(yīng)關(guān)系理清楚2.1 EU AI Act 管的是“風(fēng)險(xiǎn)等級(jí)”不是“技術(shù)本身”很多人一聽到 EU AI Act 就緊張以為所有 AI 系統(tǒng)都要被嚴(yán)管。其實(shí)它的核心邏輯是按風(fēng)險(xiǎn)分級(jí)不可接受風(fēng)險(xiǎn)、高風(fēng)險(xiǎn)、有限風(fēng)險(xiǎn)、最小風(fēng)險(xiǎn)。絕大多數(shù) Agent 產(chǎn)品落在“有限風(fēng)險(xiǎn)”或“最小風(fēng)險(xiǎn)”區(qū)間真正被重點(diǎn)監(jiān)管的是高風(fēng)險(xiǎn)場(chǎng)景比如用于招聘篩選、信用評(píng)估、教育評(píng)分、關(guān)鍵基礎(chǔ)設(shè)施管理的 AI 系統(tǒng)。對(duì) Agent 開發(fā)者來說關(guān)鍵動(dòng)作是先給自己的產(chǎn)品做風(fēng)險(xiǎn)定級(jí)。我一般會(huì)問三個(gè)問題這個(gè) Agent 的輸出會(huì)不會(huì)實(shí)質(zhì)性影響一個(gè)人的法律地位、就業(yè)機(jī)會(huì)或基本權(quán)利它是不是在替人做決定而不是給人提供參考它的決策過程是不是難以追溯如果三個(gè)問題里有兩個(gè)是“是”那基本就要按高風(fēng)險(xiǎn)來準(zhǔn)備合規(guī)材料了。高風(fēng)險(xiǎn)意味著什么意味著你需要建立風(fēng)險(xiǎn)管理系統(tǒng)、技術(shù)文檔、日志記錄、人工監(jiān)督機(jī)制、準(zhǔn)確性 Robustness 和網(wǎng)絡(luò)安全要求。這些詞聽起來很虛但落到 Agent 上就是很具體的東西你的記憶模塊要有審計(jì)日志你的工具調(diào)用要有權(quán)限邊界你的輸出要有可解釋的推理鏈路你的模型更新要有版本記錄。2.2 GDPR 管的是“個(gè)人數(shù)據(jù)”Agent 的記憶層是重災(zāi)區(qū)GDPR 的核心是個(gè)人數(shù)據(jù)的處理規(guī)則。Agent 最容易出問題的地方就是記憶系統(tǒng)。短期記憶通常存在會(huì)話上下文里會(huì)話結(jié)束就釋放問題不大。但長期記憶和向量庫就不一樣了——它們會(huì)把用戶說過的話、上傳的文檔、甚至 Agent 自己生成的摘要持久化存儲(chǔ)而且往往沒有明確的過期機(jī)制。我見過一個(gè)很典型的錯(cuò)誤設(shè)計(jì)Agent 把用戶每一輪對(duì)話都做 embedding 存進(jìn)向量庫用于后續(xù)的語義檢索。這個(gè)設(shè)計(jì)在功能上很合理但在 GDPR 視角下等于把個(gè)人數(shù)據(jù)無限期存儲(chǔ)而且用戶根本不知道自己的話被轉(zhuǎn)成了向量。更麻煩的是向量本身雖然不可讀但通過反向檢索可以還原出大量原文信息這在監(jiān)管看來仍然屬于個(gè)人數(shù)據(jù)處理。GDPR 還強(qiáng)調(diào)數(shù)據(jù)主體權(quán)利訪問權(quán)、更正權(quán)、刪除權(quán)、可攜帶權(quán)。落到 Agent 上就是用戶要能查到你存了他什么、能要求你改、能要求你刪、能要求你把數(shù)據(jù)導(dǎo)出。如果你的記憶層是一堆散落在不同向量庫和緩存里的 embedding實(shí)現(xiàn)這些權(quán)利的成本會(huì)非常高。2.3 數(shù)據(jù)本地化管的是“數(shù)據(jù)放哪”跨境傳輸是硬約束數(shù)據(jù)本地化要求特定類型的數(shù)據(jù)必須存儲(chǔ)在特定司法管轄區(qū)內(nèi)。對(duì) Agent 來說最直接的沖擊是推理服務(wù)和存儲(chǔ)服務(wù)的地理位置。如果你的 Agent 調(diào)用的是境外的大模型 API用戶數(shù)據(jù)在推理過程中就出境了如果你的向量庫部署在境外云區(qū)域長期記憶也出境了。GDPR 對(duì)跨境傳輸有專門章節(jié)核心是要求接收方所在國家提供“足夠的數(shù)據(jù)保護(hù)水平”或者采用標(biāo)準(zhǔn)合同條款、約束性公司規(guī)則等機(jī)制。實(shí)操中很多團(tuán)隊(duì)會(huì)選擇在歐洲區(qū)域部署一套獨(dú)立的存儲(chǔ)和推理鏈路把歐洲用戶的數(shù)據(jù)完全留在歐洲。這就是所謂的數(shù)據(jù)本地化落地。注意數(shù)據(jù)本地化不是簡單地把服務(wù)器搬到某個(gè)區(qū)域就完事。你還要考慮備份、日志、監(jiān)控?cái)?shù)據(jù)、模型微調(diào)數(shù)據(jù)是否也留在同一區(qū)域。我見過團(tuán)隊(duì)主庫放在歐洲但日志系統(tǒng)默認(rèn)發(fā)到美國結(jié)果審計(jì)時(shí)被揪出來。3. Agent 數(shù)據(jù)治理的架構(gòu)設(shè)計(jì)從數(shù)據(jù)流圖開始3.1 先畫一張“數(shù)據(jù)生命周期圖”別急著寫代碼我在每個(gè) Agent 項(xiàng)目啟動(dòng)時(shí)都會(huì)強(qiáng)制做一件事畫數(shù)據(jù)生命周期圖。不是架構(gòu)圖是數(shù)據(jù)圖。橫軸是數(shù)據(jù)從產(chǎn)生到銷毀的各個(gè)階段縱軸是數(shù)據(jù)經(jīng)過的每個(gè)組件。這張圖要回答幾個(gè)問題數(shù)據(jù)在哪產(chǎn)生、經(jīng)過哪些組件、在哪落盤、存多久、誰能訪問、怎么刪除。具體到 Agent我會(huì)把組件拆成這幾層接入層用戶輸入、編排層Agent 決策邏輯、記憶層短期/長期/向量、工具層外部 API 調(diào)用、模型層推理服務(wù)、日志與監(jiān)控層。然后逐層標(biāo)注數(shù)據(jù)類型原始輸入、模型輸出、工具返回、embedding、摘要、元數(shù)據(jù)。這張圖的價(jià)值在于它讓你在寫代碼之前就發(fā)現(xiàn)合規(guī)風(fēng)險(xiǎn)點(diǎn)。比如你會(huì)發(fā)現(xiàn)編排層的調(diào)試日志里可能記錄了完整的用戶輸入而日志系統(tǒng)往往沒有脫敏工具層調(diào)用第三方 API 時(shí)用戶數(shù)據(jù)可能被發(fā)送到不受控的外部服務(wù)模型層的推理請(qǐng)求可能被云廠商用于服務(wù)改進(jìn)。3.2 記憶分層設(shè)計(jì)短期、長期、永久各管什么Agent 記憶體系通常分三層但很多團(tuán)隊(duì)沒有明確每層的合規(guī)邊界。我的做法是給每層定義清楚存儲(chǔ)內(nèi)容、存儲(chǔ)位置、保留期限、訪問權(quán)限。短期記憶就是當(dāng)前會(huì)話的上下文存在內(nèi)存或會(huì)話緩存里會(huì)話結(jié)束即釋放。這一層基本不涉及持久化合規(guī)壓力最小但要注意會(huì)話超時(shí)機(jī)制別讓上下文無限增長。長期記憶是跨會(huì)話的用戶偏好、歷史摘要、關(guān)鍵事實(shí)。這一層是 GDPR 的重點(diǎn)。我的建議是只存結(jié)構(gòu)化摘要不存原始對(duì)話。比如用戶說“我住在柏林喜歡德語回復(fù)”長期記憶里存的是{city: Berlin, language: de}而不是整段對(duì)話原文。這樣既滿足功能需求又大幅降低個(gè)人數(shù)據(jù)暴露面。永久記憶通常指需要長期保留的審計(jì)日志、合規(guī)記錄、模型版本信息。這一層反而可以保留較久但必須與個(gè)人數(shù)據(jù)解耦只記錄操作事件和系統(tǒng)狀態(tài)不記錄具體內(nèi)容。向量庫的處理最微妙。我的經(jīng)驗(yàn)是向量庫里的 embedding 要綁定元數(shù)據(jù)包括來源、創(chuàng)建時(shí)間、過期時(shí)間、用戶標(biāo)識(shí)。檢索時(shí)先按元數(shù)據(jù)過濾再按語義相似度排序。刪除時(shí)通過元數(shù)據(jù)定位并清除對(duì)應(yīng)向量。這樣既保證功能又讓刪除權(quán)可落地。3.3 數(shù)據(jù)本地化的部署策略區(qū)域隔離怎么做數(shù)據(jù)本地化在架構(gòu)上通常有三種做法單區(qū)域部署、多區(qū)域獨(dú)立部署、混合部署。單區(qū)域部署最簡單但滿足不了多地合規(guī)要求。多區(qū)域獨(dú)立部署是每個(gè)區(qū)域一套完整鏈路數(shù)據(jù)不跨區(qū)成本最高但合規(guī)最穩(wěn)?；旌喜渴鹗前延?jì)算和存儲(chǔ)分離計(jì)算可以跨區(qū)但存儲(chǔ)必須本地。我參與的項(xiàng)目里面向歐洲市場(chǎng)的 Agent 采用的是多區(qū)域獨(dú)立部署歐洲用戶的數(shù)據(jù)從接入到存儲(chǔ)到推理全部在歐盟區(qū)域完成美國用戶走美國區(qū)域兩邊通過統(tǒng)一的控制面管理配置和版本但數(shù)據(jù)面完全隔離。這樣做的好處是合規(guī)邊界清晰壞處是運(yùn)維復(fù)雜度上升模型更新要同步到多個(gè)區(qū)域成本也更高。如果預(yù)算有限可以考慮存儲(chǔ)本地化 推理本地化 控制面集中的折中方案?？刂泼嬷还芾砼渲?、版本號(hào)、非個(gè)人數(shù)據(jù)不碰用戶數(shù)據(jù)。這樣既能滿足數(shù)據(jù)本地化要求又能降低運(yùn)維成本。提示區(qū)域隔離不只是服務(wù)器位置還包括備份、日志、監(jiān)控、CDN、DNS。我踩過的坑是主庫在歐洲但錯(cuò)誤監(jiān)控服務(wù)默認(rèn)把堆棧信息發(fā)到美國堆棧里恰好包含用戶輸入片段。后來把所有可觀測(cè)性組件也做了區(qū)域化部署。4. 核心環(huán)節(jié)實(shí)操從記憶寫入到刪除的完整鏈路4.1 記憶寫入時(shí)的數(shù)據(jù)最小化與脫敏記憶寫入是 Agent 數(shù)據(jù)治理的第一道關(guān)口。我的原則是能摘要就不存原文能結(jié)構(gòu)化就不存自由文本能匿名就不存標(biāo)識(shí)。具體操作上我會(huì)在記憶寫入前加一個(gè)預(yù)處理管道第一步做 PII 檢測(cè)識(shí)別郵箱、電話、地址、身份證號(hào)等第二步做脫敏或哈希第三步做摘要提取把長對(duì)話壓縮成關(guān)鍵事實(shí)第四步做元數(shù)據(jù)標(biāo)注打上來源、時(shí)間、過期策略。PII 檢測(cè)可以用正則加輕量模型組合。正則覆蓋格式固定的類型模型覆蓋上下文相關(guān)的類型。脫敏策略要看場(chǎng)景如果后續(xù)需要精確匹配用哈希如果只需要語義用泛化比如把具體地址泛化成城市。摘要提取我一般用一個(gè)小模型或者規(guī)則引擎把對(duì)話里的關(guān)鍵實(shí)體和意圖抽出來。比如用戶說“幫我訂下周三從柏林到慕尼黑的火車”摘要存的是{intent: book_train, from: Berlin, to: Munich, date: next_wednesday}。原始句子不存。元數(shù)據(jù)標(biāo)注很關(guān)鍵。每條記憶都要有created_at、expires_at、source、user_id_hash、region。這些字段是后續(xù)刪除、審計(jì)、區(qū)域過濾的基礎(chǔ)。4.2 向量庫的合規(guī)配置元數(shù)據(jù)過濾與過期清理向量庫是 Agent 長期記憶的核心組件也是合規(guī)最容易出問題的地方。我用的方案是元數(shù)據(jù)過濾 定時(shí)清理 軟刪除三件套。元數(shù)據(jù)過濾是在檢索時(shí)先按region、user_id_hash、expires_at過濾再做語義相似度計(jì)算。這樣保證歐洲用戶的查詢不會(huì)命中其他區(qū)域的數(shù)據(jù)也保證過期數(shù)據(jù)不會(huì)被檢索到。定時(shí)清理是后臺(tái)任務(wù)定期掃描expires_at小于當(dāng)前時(shí)間的向量并刪除。清理頻率取決于數(shù)據(jù)量和合規(guī)要求我一般設(shè)成每天一次高風(fēng)險(xiǎn)場(chǎng)景可以設(shè)成每小時(shí)。軟刪除是給用戶刪除權(quán)用的。用戶要求刪除時(shí)先把向量標(biāo)記為deleted檢索時(shí)過濾掉然后在下一個(gè)清理周期物理刪除。這樣既保證用戶立即感知到刪除效果又避免頻繁物理刪除影響性能。注意向量庫的刪除不是簡單刪一條記錄。很多向量庫的索引結(jié)構(gòu)導(dǎo)致刪除后空間不會(huì)立即釋放需要重建索引或做 compaction。我在項(xiàng)目里會(huì)定期做索引重建順便清理已刪除向量。4.3 工具調(diào)用時(shí)的數(shù)據(jù)出境控制Agent 調(diào)用外部工具時(shí)用戶數(shù)據(jù)可能被發(fā)送到第三方服務(wù)。這是數(shù)據(jù)出境的高風(fēng)險(xiǎn)環(huán)節(jié)。我的做法是工具白名單 數(shù)據(jù)出境檢查 區(qū)域路由。工具白名單是只允許調(diào)用經(jīng)過合規(guī)審查的工具。每個(gè)工具要標(biāo)注它會(huì)把數(shù)據(jù)發(fā)送到哪個(gè)區(qū)域、是否涉及個(gè)人數(shù)據(jù)、是否有數(shù)據(jù)處理協(xié)議。數(shù)據(jù)出境檢查是在工具調(diào)用前檢查請(qǐng)求里是否包含個(gè)人數(shù)據(jù)以及目標(biāo)區(qū)域是否允許接收。如果不允許要么拒絕調(diào)用要么做脫敏后再調(diào)用。區(qū)域路由是根據(jù)用戶所在區(qū)域選擇對(duì)應(yīng)的工具實(shí)例。比如歐洲用戶的工具調(diào)用走歐洲區(qū)域的部署美國用戶走美國區(qū)域。這要求工具有多區(qū)域部署能力或者至少支持區(qū)域化配置。4.4 用戶權(quán)利響應(yīng)訪問、刪除、導(dǎo)出的工程實(shí)現(xiàn)GDPR 要求用戶能訪問、刪除、導(dǎo)出自己的數(shù)據(jù)。落到 Agent 上需要一套用戶權(quán)利響應(yīng)系統(tǒng)。訪問權(quán)響應(yīng)是匯總用戶在所有組件里的數(shù)據(jù)短期記憶、長期記憶、向量庫、日志、工具調(diào)用記錄。我一般會(huì)建一個(gè)數(shù)據(jù)地圖記錄每類數(shù)據(jù)存在哪個(gè)組件、用什么標(biāo)識(shí)關(guān)聯(lián)。用戶發(fā)起訪問請(qǐng)求時(shí)按數(shù)據(jù)地圖逐組件查詢并匯總。刪除權(quán)響應(yīng)是反向操作按數(shù)據(jù)地圖逐組件刪除。這里要注意級(jí)聯(lián)刪除比如刪了長期記憶對(duì)應(yīng)的向量也要?jiǎng)h刪了用戶標(biāo)識(shí)對(duì)應(yīng)的哈希映射也要處理。導(dǎo)出權(quán)響應(yīng)是把數(shù)據(jù)打包成可讀格式。我一般用 JSON包含結(jié)構(gòu)化記憶、摘要、元數(shù)據(jù)不包含 embedding 原始向量因?yàn)椴豢勺x且體積大。這套系統(tǒng)的工程難點(diǎn)在于數(shù)據(jù)地圖的維護(hù)。Agent 組件多、數(shù)據(jù)流復(fù)雜數(shù)據(jù)地圖很容易過時(shí)。我的經(jīng)驗(yàn)是把數(shù)據(jù)地圖做成配置化每個(gè)組件注冊(cè)自己的數(shù)據(jù)類型和存儲(chǔ)位置新增組件時(shí)強(qiáng)制更新地圖。5. 常見問題與排查技巧實(shí)錄5.1 合規(guī)審查時(shí)最容易被問倒的幾個(gè)問題我在配合法務(wù)做合規(guī)審查時(shí)被問過幾個(gè)很尖銳的問題這里整理出來供大家提前準(zhǔn)備。第一個(gè)問題是“用戶數(shù)據(jù)到底存在哪”。這個(gè)問題看似簡單但如果你沒有數(shù)據(jù)地圖很難當(dāng)場(chǎng)回答。我的建議是提前準(zhǔn)備一份數(shù)據(jù)存儲(chǔ)清單列出每個(gè)組件、每類數(shù)據(jù)、存儲(chǔ)位置、保留期限。第二個(gè)問題是“用戶要求刪除時(shí)你怎么保證刪干凈”。這涉及級(jí)聯(lián)刪除和備份清理。我的做法是刪除請(qǐng)求觸發(fā)后主存儲(chǔ)立即刪備份在下個(gè)周期清理同時(shí)記錄刪除審計(jì)日志。第三個(gè)問題是“模型推理時(shí)數(shù)據(jù)會(huì)不會(huì)被用于訓(xùn)練”。這取決于你用的模型服務(wù)。如果是自部署要確認(rèn)推理日志不被用于訓(xùn)練如果是第三方 API要看服務(wù)條款。我一般會(huì)在合同里明確禁止訓(xùn)練用途并在架構(gòu)上做推理日志脫敏。第四個(gè)問題是“跨境傳輸?shù)姆梢罁?jù)是什么”。這需要法務(wù)介入但工程師要能說清楚數(shù)據(jù)流向和區(qū)域部署情況。5.2 記憶泄漏與跨用戶污染的排查Agent 記憶系統(tǒng)最容易出的 bug 是跨用戶污染A 用戶的記憶被 B 用戶檢索到。這在向量庫里尤其常見因?yàn)檎Z義檢索默認(rèn)不區(qū)分用戶。排查這類問題的第一步是檢查檢索過濾條件。我見過團(tuán)隊(duì)忘了加user_id過濾導(dǎo)致全局檢索。第二步是檢查緩存鍵設(shè)計(jì)緩存鍵必須包含用戶標(biāo)識(shí)。第三步是檢查工具調(diào)用的上下文傳遞別把上一個(gè)用戶的上下文帶到下一個(gè)請(qǐng)求。修復(fù)方案是強(qiáng)制過濾 測(cè)試用例。在檢索層強(qiáng)制要求user_id和region過濾缺失就報(bào)錯(cuò)。同時(shí)寫測(cè)試用例模擬多用戶并發(fā)驗(yàn)證記憶隔離。5.3 數(shù)據(jù)本地化部署后的性能與成本權(quán)衡多區(qū)域獨(dú)立部署會(huì)帶來性能和成本問題。性能上跨區(qū)域同步配置和版本會(huì)有延遲成本上每個(gè)區(qū)域都要一套存儲(chǔ)和推理資源。我的優(yōu)化經(jīng)驗(yàn)是控制面集中、數(shù)據(jù)面隔離、緩存分層?？刂泼嬷煌脚渲煤桶姹咎?hào)數(shù)據(jù)量小延遲可接受。數(shù)據(jù)面完全隔離保證合規(guī)。緩存分層是在每個(gè)區(qū)域加本地緩存減少跨區(qū)域請(qǐng)求。成本優(yōu)化上可以用按需伸縮 冷熱分離。熱數(shù)據(jù)放高性能存儲(chǔ)冷數(shù)據(jù)放對(duì)象存儲(chǔ)。推理服務(wù)按流量伸縮低峰期縮容。5.4 常見問題速查表問題現(xiàn)象可能原因排查方向解決建議用戶要求刪除后仍能檢索到向量庫未物理刪除或索引未重建檢查刪除標(biāo)記和索引狀態(tài)觸發(fā)索引重建確認(rèn)物理刪除跨用戶記憶污染檢索缺少用戶過濾檢查檢索查詢條件強(qiáng)制用戶標(biāo)識(shí)過濾加測(cè)試用例合規(guī)審查無法回答數(shù)據(jù)位置缺少數(shù)據(jù)地圖梳理組件和數(shù)據(jù)流建立配置化數(shù)據(jù)地圖跨境傳輸被質(zhì)疑工具調(diào)用或日志出境檢查工具區(qū)域和日志配置區(qū)域化部署脫敏出境數(shù)據(jù)記憶無限增長缺少過期策略檢查記憶寫入邏輯加過期時(shí)間和定時(shí)清理6. 我在實(shí)際項(xiàng)目里沉淀的幾條經(jīng)驗(yàn)做 Agent 數(shù)據(jù)治理這一年多最大的體會(huì)是合規(guī)不是事后補(bǔ)的是設(shè)計(jì)出來的。等產(chǎn)品跑通了再想合規(guī)改造成本會(huì)高到讓你想重寫。我的做法是在項(xiàng)目啟動(dòng)階段就把數(shù)據(jù)生命周期圖、記憶分層、區(qū)域策略定下來后面寫代碼就是按圖施工。第二個(gè)體會(huì)是數(shù)據(jù)最小化真的能省很多事。少存原文、少存標(biāo)識(shí)、少存長期不僅合規(guī)壓力小存儲(chǔ)成本和檢索成本也低。我見過團(tuán)隊(duì)為了“以后可能有用”把所有對(duì)話都存下來結(jié)果合規(guī)審查時(shí)刪都刪不干凈。第三個(gè)體會(huì)是自動(dòng)化比人工可靠。過期清理、PII 檢測(cè)、區(qū)域過濾這些事靠人記著一定會(huì)漏。做成管道和定時(shí)任務(wù)讓系統(tǒng)自己跑才是可持續(xù)的。最后分享一個(gè)小技巧我會(huì)在 Agent 的每個(gè)記憶寫入和檢索操作上加結(jié)構(gòu)化日志記錄操作類型、數(shù)據(jù)類型、區(qū)域、用戶哈希、時(shí)間戳。這些日志不存內(nèi)容只存元數(shù)據(jù)既能用于審計(jì)又不會(huì)引入新的合規(guī)風(fēng)險(xiǎn)。排查問題時(shí)順著日志就能還原數(shù)據(jù)流向比翻代碼快得多。這個(gè)領(lǐng)域還在快速變化EU AI Act 的具體執(zhí)行細(xì)則、各成員國的落地方式都還在演進(jìn)。我的建議是保持關(guān)注但別等細(xì)則出全了再動(dòng)手。先把數(shù)據(jù)地圖、記憶分層、區(qū)域隔離這些基礎(chǔ)打好后面不管規(guī)則怎么變調(diào)整成本都可控。