昨天寫了去識別的一個小坑。今天寫的是更重的一件事：學生資料。這一篇沒有故事反轉，只有我劃的一條線，和它如何在系統裡被自動強制。

我的工作會碰到的資料

我是國小老師。日常會經手的資料裡，有些種類我認為無論如何都不該離開被我控制的範圍：能指向特定學生的資料。名字、班級與座號的組合、家長聯絡事項、輔導的背景描述。這份清單不難列，難的是它不能靠記住，要靠系統替我擋。

我的基本決策：等級要靠「去識別與否」分流

我自己的判準只有一條：這份材料去識別了沒有？

已經去識別、用代號的材料，可以進到工作流程裡，包含可以交給 AI 處理。未去識別的原始材料──原始的記錄、能對上人的描述──只能放在我自己的加密儲存裡，不進任何同步、任何搜尋、任何 AI 的上下文。這和中間的等級無關，是二分：去了的能動，沒去的不能動。

這個規則的用處在於它可執行。我的 agent 們在寫入任何筆記之前，都會先判斷這份材料屬於哪一側；需要判斷而無法確定的，昨天說過，一律走拒絕的方向。

讓 AI 接手前的固定步驟：本機先假名化

我現在固定的流程是：**任何學生相關的材料，先在本機跑一個假名化的腳本，再交給外面的模型。**這個腳本做的事情不聰明：把名字換成固定代號、把班級資訊壓掉。它的價值在於固定：每一次的處理都一樣，交出去的材料長得一樣，我要還原時有同一張對照表。

九月的時候，我把其中一條主管線接起來：八位現役學生的 profile 材料，一律先過本機的假名化，處理完的材料才進到後面那一段交給雲端模型的處理。這條線的每一步，現在有紀錄：什麼時候、處理了哪些材料（以代號計）、假名化腳本的版本號。沒有這三個紀錄的處理，視為沒有發生。

自動閘門在這條線上的角色

這個系列的讀者已經熟悉我的送出閘門。它在這條線上做的是最低限度的機械檢查：身分證字號、超常位數的數字 ID、特定型態的姓名欄。這些是「一定不該出現」的字串，一旦出現，提交就失敗。

必須誠實說：這個閘門在學生資料的紅線上，守的是底線不是主線。語意層的可識別性，「那位住巷口、媽媽在超商上班的學生」，任何 regex 都看不到。所以主線的把關者還是我自己：發布前逐字讀。閘門的角色是抓我手滑，不是替我判斷。

不踩線的代價

寫了這麼多紅線，看起來頗累。這裡仍想老實面對一個問題：這條線的代價有時是慢。有幾份材料，我希望快速拿到 AI 的幫助，卻因為還沒做假名化而整份先放下。

但我想清楚的版本是：這種「慢」是設計而不是成本。**多一道本機流程，換的是「沒有哪一次方便的例外會變成不可回收的錯誤」。**敏感資料外流的屬性就是不可回收；用固定的流程把它從例外變成規則，我睡得著。

還沒解決的

對照表本身目前由我手工維護。次數變多之後，維護也開始吃時間，我還沒有決定要不要把它服務化──服務化本身又會引入新的存取問題，這個兩難我還在觀察。

明天

紅線的最後一天，寫我把整個學校的校務系統接進 AI 之後發生什麼，還有我把學校的名字一個一個拿掉的過程。