資料邊界是什麼？

不是每份資料都能自由流動。你要先決定，它能流到哪裡。

Hook

你寫了一個公司內部的 RAG 助手。 員工可以問流程、 查文件、 找會議紀錄。 一開始大家都很滿意。 問 onboarding， 它答得很快。 問 API 規格， 它也很準。 直到某天下午， 有人問了一句：

最近薪資調整有什麼動向？

系統真的回答了。 而且不是泛泛而談。 它直接引用了一段 HR 還沒公告的薪資表摘要。 回答底下還附了來源片段。 十分鐘後， 截圖出現在員工群組。 你第一個反應可能是： 「是不是模型不該信？」 但這次的核心問題， 不是 trust boundary。 不是模型把外部惡意內容當指令。 而是資料本身流到了不該流到的地方。 HR 文件也許完全可信。 它不是惡意內容。 它甚至可能來自你最信任的內部系統。 問題在於： 這份資料不該被這個使用者、 這個 query、 這個 output 路徑拿到。 這個分界， 就是 資料邊界。 如果 trust boundary 在問：

這段內容能不能被信任？

那 data boundary 問的是：

這份資料能不能流到這裡？

這兩個問題很像， 但不一樣。 你把它們混在一起， 系統就會出現一種很危險的錯覺： 只要資料是真的， 就可以流動。 這是錯的。 很多最尷尬的事故， 不是因為資料是假的。 而是因為資料是真的， 卻被送到了錯的人面前。

Learn

一句話定義

資料邊界不是在判斷真偽。 它在判斷流向。 對工程師來說， 最實用的問句不是：

這段內容準不準？

而是：

這段內容現在能不能被 collect、store、retrieve、output 到這個位置？

只要你少問其中任何一段， 系統就會自己補答案。 而系統自己補出來的答案， 通常是： 「既然拿得到，就先用吧。」

資料邊界 vs 信任邊界

先把兩者切開。 前一門課講的 trust boundary， 是在管輸入的權威性。 這門課講的 data boundary， 是在管資料的可流動範圍。 你可以先看最小對照表：

問題	信任邊界	資料邊界
核心問句	這段內容能不能信？	這份資料能不能流到這裡？
主要風險	prompt injection、假指令、惡意來源	越權檢索、敏感資料擴散、錯層回流
常見場景	user message、網頁內容、briefing	knowledge base、memory、log、API response
出事方式	模型被帶偏去做錯事	系統把不該出去的資料送出去

一個內容可以同時在 trust 上安全， 但在 data 上危險。 剛剛那個薪資表例子就是。 HR 文件可能是最可信的內部資料。 可是一旦它被檢索給錯的人， 它一樣是事故。 反過來也成立。 外部網頁內容可能非常不可信， 但如果你只是拿它當低權限素材、 不進高敏流程， 資料邊界未必立刻出事。 所以兩條邊界不能互相取代。 你需要同時畫。

你要先記住的資料流四階段

資料邊界最實用的骨架， 是把整條 data flow 拆成四段：

1. collect
2. store
3. retrieve
4. output

這四段不是理論分類。 它們對應的就是你系統裡真正的工程節點。 如果你 review 架構圖時畫不出這四段， 表示你根本還不知道資料在哪裡越界。 先看最小定義：

階段	問題	典型失敗
collect	這份資料怎麼進來？	一開始就混入不該收的資料
store	進來後放哪裡？	高敏資料落到低保護儲存層
retrieve	誰可以把它撈出來？	query 撈到超出權限的內容
output	最後吐給誰、吐多少？	回答、報表、log 把敏感資訊帶出去

這四段每一段都可能破。 很多團隊只盯 retrieve。 因為 RAG 事故最顯眼。 但真實世界裡， collect 跟 store 的錯誤常常更早埋雷。

collect：不是能抓到就該收

很多系統的第一個錯誤， 發生在 ingest 的那一刻。 像是：

• 把整個 Slack export 全收進知識庫
• 把 debug dump 連同 access token 一起收
• 把會議逐字稿原封不動餵進 memory pipeline

這些都不是 retrieve 太貪心。 而是 collect 時沒有先問： 這份資料應不應該進系統？ 你要建立的直覺是： 不是每份可得資料都值得被納入。 有些資料在來源系統裡存在， 不代表它應該被 AI 層看見。

store：分類錯一層，後面全部補不回來

資料進來後， 第二關是放哪裡。 這一步最常被低估。 因為很多人覺得： 「先存起來，之後 retrieve 再過濾就好。」 這種想法很危險。 因為只要 store 放錯層， 你後面每一個 consumer 都要補救一次。 補得好不好， 完全看運氣。 典型例子包括：

• 把 confidential 文件跟 internal FAQ 放同一個 vector store
• 把 restricted 原文塞進所有 agent 共用的 memory
• 把含 PII 的原始 payload 放進 everyone 可讀的 object store

你一開始分類沒切開， 後面每次 retrieve 都像在拆炸彈。

retrieve：大多數 RAG 事故死在這裡

retrieve 是最容易出事、 也最常被看見的一段。 因為它直接影響：

• 模型這次看見什麼
• 使用者這次能問到什麼
• agent 這次會不會拿到超出授權的上下文

retrieve 的破洞通常不是「完全沒權限控管」。 更常見的是看起來有控， 但控得太粗。 像這樣：

• 只用關鍵字相似度，不看資料級別
• 只驗登入狀態，不驗部門或 principal
• 只限制 top-k，不限制敏感等級
• 只做 file-level ACL，不做 chunk-level 過濾

系統表面上是有 gate 的。 但實際上， 它還是讓高一級的資料混進來了。

output：不是拿到了就能原樣吐出來

最後一段是 output。 這也是很多工程團隊最容易「太相信模型」的地方。 因為他們以為： 只要 retrieve 已經做過， 模型就可以自由組句。 但 output 還有自己的邊界。 同一份資料， 可能可以出現在：

• 給 admin 的完整後台頁面
• 給一般員工的摘要回答
• 給 log 的 redacted 版本
• 給 email 的單段結論

也就是說， 可被 retrieve， 不等於可被原文輸出。 你還要決定：

• 誰能看完整內容
• 誰只能看摘要
• 誰連摘要都不該看
• 哪些欄位要遮罩

如果你忽略 output boundary， 系統就會把上游所有努力一次吐光。

四級分類：public / internal / confidential / restricted

要把資料邊界做成工程慣例， 你需要一個夠小、 但能落地的分類法。 這門課先用四級就好：

等級	代表意思	典型例子
public	對外公開也沒關係	官網文件、已公告規格
internal	公司內部可流通，但不該外流	SOP、內部 wiki、一般會議摘要
confidential	只限特定人或特定流程	客戶名單、未公開 roadmap、內部財務資料
restricted	高風險，預設不應自由檢索與輸出	薪資表、身分證號、醫療或法務文件、主密鑰材料

這四級的重點不在於命名多精美。 而在於每一級都要對應不同的行為規則。 至少要回答三件事：

1. 它可以存到哪裡？
2. 誰可以檢索？
3. 最後可以怎麼輸出？

你可以先用最小版規則理解：

等級	Store	Retrieve	Output
public	一般 store 可	大多數 flow 可	可原文或摘要
internal	內部 store	僅內部 principal	以工作目的輸出
confidential	分層 store	需 principal + 用途驗證	預設摘要或局部顯示
restricted	高保護 store	極少數 flow	預設拒絕或人工 gate

你不一定永遠用這四級。 但你至少要有一套明確規則， 而不是每次靠感覺。

三個最常見破洞

這門課先讓你對準三個最常見的 failure mode。 後面幾課都會圍著它們轉。

破洞一：RAG 撈到上一級資料

這是最經典的邊界事故。 一個 internal 問題， 撈到了 confidential 片段。 一個 confidential case， 撈到了 restricted 附件。 模型本身不需要作惡。 它只是很誠實地使用了你提供的上下文。 真正的錯在 retrieval policy。

破洞二：memory consolidation 把高敏資料落到低層

這一種比較陰。 你本來覺得 restricted 資料沒有直接對外。 但 consolidation pipeline 在做長期記憶時， 把它提煉成一般摘要， 又落到了較低敏的層。 幾週後， 另一個 agent 從低敏層撈到這段摘要。 這就是典型的資料降階外流。 它不是一次性爆炸。 它是慢慢滲出去。

破洞三：log / debug 把 PII 印出

很多資料邊界事故根本不發生在主功能。 而是發生在你覺得「只是為了方便除錯」的地方。 像是：

• print(payload)
• request body 全量記錄
• 失敗重試時把原文片段寫入 error log

主程式也許有做 retrieve gate。 但 log 沒做 redaction， 一樣會把敏感資訊送到另一個大水池裡。

先建立心智模型，不急著找神奇技術

這一課故意不講太多具體技術。 不講哪個向量資料庫比較安全。 不講哪個 access control framework 最潮。 也不講哪個 redaction library 最方便。 原因很簡單。 如果你腦中沒有 flow map， 你最後只會得到一堆散落的 patch：

• 這裡補一個 allowlist
• 那裡加一個 regex
• 另一邊再塞一個 guardrail

然後每次出事， 你都不知道到底是哪一段越界。 真正要先長出來的， 是這個反射：

任何資料問題，都先問它發生在 collect、store、retrieve、還是 output。

只要你能先把事故落到其中一段， 修法就開始有方向。

一張你可以帶去 review 會議的檢查表

下次你在看 AI agent 或 RAG 設計時， 先別急著問模型選哪個。 先用這張表問：

問題	你要逼團隊講清楚的事
資料怎麼進來？	collect 是否有排除不該收的來源
進來後放哪裡？	store 是否按敏感等級分層
誰能撈？	retrieve 是否同時看 principal、用途、資料級別
怎麼吐？	output 是否有遮罩、摘要、拒絕策略
出事時在哪段？	能不能把事故歸到四階段之一

如果一個設計回答不了這五題， 那就不是「之後再補」。 而是還沒準備好上線。

這一課你先帶走兩句話

第一句：

資料可信，不代表資料可以自由流動。

第二句：

資料邊界不是只看 retrieval；collect、store、output 每一段都要有 gate。

這兩句話先記住。 後面幾課， 我們才會開始把它壓成具體做法：

• 怎麼替每筆資料掛 provenance
• 怎麼驗寫入者是不是合法 principal
• 怎麼用 namespace 把不同 agent 隔開
• 怎麼做一條不會吃自己摘要的 consolidation pipeline

AI 協作：學了這個，跟 AI 怎麼配合？

這個技能在 AI 協作中的定位，是讓你先把資料流畫清楚，再要求 AI 幫你找邊界缺口，而不是一開始就瞎補技術。 你的人類優勢：

• 只有你知道哪份資料在你的組織裡算 internal、confidential、還是 restricted。
• 只有你能判斷某個 output 看似方便，實際上會不會造成跨部門或跨角色外流。

可以這樣跟 AI 說：

我有一個 RAG / memory flow。請先不要提解法，先把整條資料流拆成 collect、store、retrieve、output 四段，列出每段碰到的資料類型、principal、和可能的越界點。最後幫我找出最容易被忽略的一段，並說明為什麼。

Do