iT邦幫忙

0

EduShield:一個用 AI 協作開發的開源個資去識別化工具

  • 分享至 

  • xImage
  •  

專案資訊

為什麼會做這個專案?

現在使用 ChatGPT、Claude 等生成式 AI 協助處理工作內容已經越來越普遍。

但如果是行政、公文、教育或社福相關工作,資料裡經常會包含:

  • 姓名
  • 電話
  • Email
  • 地址
  • 學號
  • 身分識別資訊
  • 其他敏感內容

問題就變成:

「AI 很好用,但工作資料裡有個資,到底要怎麼用?」

如果每次使用 AI 前,都要人工逐一檢查並刪除個資,不但麻煩,也很容易因為疏忽而漏掉。

因此我開始思考,能不能做一個很簡單的中間層:

原始資料 → 個資去識別化 → AI 處理 → 個資還原

這就是 EduShield 最初的想法。

EduShield 在做什麼?

EduShield 是一個免費、開源的資料去識別化工具。

它的核心工作流程不是單純「把個資打碼」,而是希望建立一個可以實際融入 AI 工作流程的閉環。

1. 遮蔽

使用者將原始資料貼入 EduShield,系統會協助辨識可能的個資並替換成 placeholder。

例如:

王小明{{PERSON_1}}

原本:

王小明於 8 月 20 日提交申請……

處理後:

{{PERSON_1}} 於 8 月 20 日提交申請……

2. 交給 AI 處理

去識別化後的內容就可以交給 AI 進行後續處理,例如:

  • 公文潤飾
  • 報告整理
  • 文字改寫
  • 會議紀錄整理
  • 文件撰寫
  • 格式調整

這時 AI 接觸到的是去識別化後的內容,而不是原始姓名等資訊。

3. 將 AI 結果貼回 EduShield

AI 完成處理後,再將結果貼回 EduShield。

4. 還原

EduShield 會依照原本建立的對應關係,把 placeholder 還原成原始資料。

例如:

{{PERSON_1}}王小明

因此最後不需要人工逐一尋找並替換。

這也是我認為這個專案最重要的地方:

EduShield 不只是去識別化工具,而是嘗試建立「遮蔽 → AI → 還原」的完整工作流。

技術架構

這個專案其中一個核心設計原則是:

能不把資料送到遠端,就不要送。

因此目前的核心工具可以直接以 單一 HTML 檔案執行,不需要另外架設後端伺服器。

整體可以簡化理解成:

使用者
  │
  ▼
EduShield
  │
  ├─ Regex / 規則辨識
  │
  ├─ 本機 AI(Ollama)
  │
  ├─ Placeholder Mapping
  │
  └─ 還原機制

資料處理主要發生在使用者端。

如果需要使用 AI 協助辨識比較複雜的個資,也可以搭配 Ollama 使用本機模型。

因此我希望它可以同時兼顧:

易用性 × 隱私 × 可攜性

為什麼不是全部交給 AI?

這是開發過程中我覺得比較有意思的一個問題。

如果完全依賴 LLM 來判斷個資,確實可以處理比較複雜的自然語言情境,但同時會帶來:

  • 模型判斷不穩定
  • 不同模型結果可能不同
  • 效能問題
  • 本機硬體需求
  • 對於固定格式資料其實沒有必要使用 LLM

所以目前採用的是 規則 + AI 的混合方式

對於姓名、電話、Email、身分識別碼等具有明確格式的資料,可以先透過 Regex 等規則處理。

比較難單純靠格式判斷的內容,再交由本機 AI 協助。

概念上是:

能用規則解決的,就不要浪費 AI。

開發過程中最大的挑戰:我其實不知道自己不知道什麼

這個專案對我來說還有一個特殊的地方。

這是我第一次大量使用 AI 協作開發一個相對完整的軟體專案。

從架構設計、程式碼撰寫,到功能實作,我都大量使用 AI 協助。

這讓我可以在相對短的時間內,把原本只是想法的東西做成一個可以實際操作的版本。

但同時也產生一個很現實的問題:

AI 幫我把功能做出來,不代表我就知道它有沒有問題。

例如:

  • Regex 的邊界條件
  • 特殊格式的漏判
  • 誤判問題
  • Placeholder 對應關係
  • AI 改寫內容後的還原
  • 效能
  • 瀏覽器相容性
  • 本機模型判斷結果
  • 特殊敏感資訊的處理方式

這些都是我目前持續驗證的部分。

所以我沒有把 EduShield 當成「已經完成的產品」。

比較準確的說法是:

我先把一個真的能運作的版本做出來,接下來希望透過開源與實際使用,把我自己沒有發現的問題找出來。

特敏資訊的防護

除了基本的個資辨識之外,目前也針對部分特定敏感資訊設計較嚴格的防護與阻斷機制。

這部分的想法不是單純「提醒使用者」,而是在某些情況下直接提高操作門檻,降低使用者誤把敏感資料交給 AI 的風險。

不過我也不希望把 EduShield 包裝成「使用後就絕對安全」的工具。

去識別化本身就不存在可以輕易保證 100% 完整的情況。

因此目前比較希望把 EduShield 定位成:

在使用 AI 前,多一道資料檢查與去識別化的防護層。

而不是取代組織本身的個資管理政策、資安規範或人工判斷。

目前開發狀態

目前已經完成可以實際使用的初版,包括:

  • 個資辨識與遮蔽
  • Placeholder 對應
  • AI 處理後的內容還原
  • Regex 規則處理
  • 本機 Ollama AI 輔助
  • 特定敏感資訊的防護機制
  • 單一 HTML 執行模式

目前則持續進行:

  • 更多個資類型的辨識
  • Regex 邊界條件測試
  • 誤判/漏判改善
  • 還原機制的特殊情境測試
  • 效能與使用體驗改善
  • 安全性與架構 Review

為什麼現在把它開源?

因為我覺得這個專案最需要的其實不是再多幾個功能,而是:

更多人幫我找問題。

如果你是前端、JavaScript、資安、隱私保護、NLP、LLM 或資料去識別化相關的開發者,很歡迎直接看原始碼。

如果發現:

  • Bug
  • 資安問題
  • Regex 漏洞
  • 不合理的架構
  • 不必要的程式碼
  • 更好的實作方式

都歡迎直接提出 Issue 或 Pull Request。

甚至如果你覺得這個架構適合自己的學校、公司或組織,也可以直接 Fork 回去修改。

最後

我做 EduShield 的出發點其實很簡單:

我不希望「怕個資外洩」最後變成完全不用 AI 的理由。

但同時,也不希望大家因為 AI 很方便,就直接把原始工作資料全部貼上去。

我比較希望中間多一道很簡單的流程:

資料 → EduShield → AI → 還原

如果這個專案最後能讓更多人在使用 AI 前,養成「先過一下去識別化」的習慣,我就覺得它有達到最初的目的。

GitHub:
https://github.com/oas114/EduShield

歡迎 Review,也歡迎直接抓 Bug。

畢竟這是我第一次用這種方式完成一個完整專案,現在最需要的是大家告訴我:

「這裡有問題,你沒想到。」


*提醒邦友,使用第三方服務/API 時,請務必評估資安風險與隱私保護
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言