我讀了 Tom 的 AI 脫敏架構,然後在凌晨兩點重新思考了自己的人生
iDempiere

我讀了 Tom 的 AI 脫敏架構,然後在凌晨兩點重新思考了自己的人生

2026-03-20 · 8 分鐘 · Ray Lee (System Analyst)

那是個普通的星期四下午,我打開了 Tom Ting 的文章。

連結標題很長。有「四層架構」三個字。我心想:哦,架構圖。這種文章我看過很多,通常第三段就開始談 Kubernetes。結果我看到了 AES-256 mapping table,還有一句話讓我停下來:「LLM 永遠不會看到真實資料。」我重新讀了一遍。然後去泡了杯咖啡。

Layer 1:資料真的在你這裡嗎?

Tom 的架構從 iDempiere 資料庫開始:所有敏感資料,完整留在本地伺服器。聽起來理所當然,但在 2026 年,「本地」兩個字是政治宣言,不是技術選項。GDPR 說資料不能出境,個資法說客戶同意書不涵蓋雲端分析,老闆說「反正資料不可以出去」——三件事湊在一起,本地 AI 從「有趣的實驗」變成了「唯一的解」。

補充:ninniku 環境實測
我也在本地跑 Ollama。硬體是這台 Raspberry Pi——就是你現在讀這篇文章的那台機器。llama3.2:3b 勉強能用,回答品質大概是「懂得問題但有時候開始亂說話」。gemma3:4b 比較聰明,但明顯慢一截。結論是:Layer 1 的「本地」二字,背後站著一台嗡嗡叫的機器,它有時候也需要喝點水。

Layer 2:脫敏不等於安全,但比裸奔好

這一層是全文最精彩的地方。Tom 用確定性雜湊(deterministic hashing)讓同一個原始值永遠對應同一個假名——比如 CUST_A1B2C3D4。這不只是「把資料藏起來」,而是讓 LLM 可以跨文件做推理:同一個客戶在十份合約裡都叫 CUST_A1B2C3D4,模型可以追蹤、比對、分析,但永遠不知道這個人是誰。這是讓整個架構成立的核心設計決策。沒有這一步,脫敏就只是把名字塗掉,而不是讓 AI 真的能工作。

風險呢?Mapping table 現在是王冠上的寶石。它比原始資料更危險,因為一旦外洩,所有歷史分析都可以被反查。Tom 用 AES-256 保護 mapping table,我用的是把硬碟鎖在抽屜裡。方法不同,理念相通。

Layer 3 & 4:跑得動嗎?還原比加密難

Tom 的成本試算是全文最務實的段落。五年下來:純本地 Ollama $13,000,純 Claude API $24,600,混合方案 $17,380。混合邏輯是「簡單查詢用本地,複雜推理上雲端」——聽起來合理,但「複雜」的定義是誰說了算?這個問題藏著整個架構最難的設計決策,Tom 沒有展開,留給讀者自己想。我想了很久。

Layer 4 才是整個架構的靈魂。加密容易,還原難——難的不是技術,是政治:誰能看,誰說了算,出了問題算誰的。四個角色(admin、manager、analyst、viewer)是合理的起點,audit log 是讓這一切在法律上站得住腳的工具。

補充:恢復權限設計的想法
幾點實務心得:第一,analyst 層級的脫敏資料存取涵蓋了 90% 的日常使用情境,真正需要恢復的操作是例外,不是工作流程。第二,audit log 只記「使用者 X 恢復了記錄 Y」是合規門面功夫——有用的 log 是那個沒有人會填的「原因」欄位。第三,角色邊界在縫隙處失效:那個同時也是 DBA 的「manager」,你打算怎麼辦?

太史公曰

太史公曰:昔者企業有三難:資料不可外洩,模型不可不用,人員不可盡信。Tom 氏以四層之架,破此三難。脫敏於前,恢復於後,本地之算,混合之策,環環相扣,無一贅設。余讀畢,凌晨已過兩點,咖啡已涼,而心仍未靜。

原文在此,建議白天讀。

English

It was an ordinary Thursday afternoon. I opened Tom Ting’s article.

The URL was long. It contained “four-layer architecture.” I thought: ah, an architecture diagram. I’ve read dozens of these — they usually reach Kubernetes by the third paragraph. Instead I found an AES-256 mapping table and one sentence that made me stop: “The LLM never sees real data.” I read it again. Made coffee. Came back and read it a third time. That’s how an existential crisis at 2am begins, except it was Thursday afternoon, which is somehow worse.

Layer 1: Is Your Data Actually Local?

The architecture starts with the iDempiere database: all sensitive data on a local server. This sounds obvious until you remember that in 2026, “local” is a political declaration. GDPR says data cannot cross borders. Privacy law says that consent form doesn’t cover cloud analytics. Your boss says “the data cannot leave.” Three pressures, one conclusion: local AI stops being an experiment and becomes the only viable answer.

Note: Tested on ninniku
I also run Ollama locally. The hardware is this Raspberry Pi — the one serving you this page. llama3.2:3b is usable; it understands questions but sometimes freestyles. gemma3:4b is smarter and slower. The “local” in Layer 1 is a humming machine that occasionally needs a moment. Relatable.

Layer 2: Masking Isn’t Security, But It’s Better Than Nothing

This is where the architecture earns its keep. Tom uses deterministic hashing so the same original value always maps to the same pseudonym — say, CUST_A1B2C3D4. This lets the LLM reason across documents: the same customer appears as CUST_A1B2C3D4 in ten contracts, and the model can track, compare, and analyze without ever knowing who that person is. Without this, masking is scribbling over names. With it, you have something genuinely useful.

The catch: the mapping table is now the crown jewel — more dangerous than the original data, because if it leaks, every historical analysis becomes retroactively de-anonymizable. Tom protects it with AES-256. I use a drawer with a lock. Different methods. Same spirit.

Layer 3 & 4: Can It Run? And Recovery Is Harder Than Encryption

Tom’s cost breakdown is the most pragmatic section. Five-year totals: local Ollama $13,000, pure Claude API $24,600, hybrid $17,380. The hybrid logic — simple queries local, complex reasoning to the cloud — sounds sensible until you ask: who defines complex? That question hides the hardest decision in the architecture. Tom leaves it open.

Layer 4 is the real soul. Encryption is solved. Recovery is politics: who sees original data, who decides, who takes the blame. The four roles — admin, manager, analyst, viewer — are a starting point. The audit log makes it defensible.

Note: On recovery permissions
Three observations. First: analyst-level masked access covers 90% of everyday use cases — actual recovery is the exception, not the workflow. Second: an audit log recording only “user X recovered record Y” is compliance theatre; the useful field is the reason column, the one nobody fills in. Third: role boundaries fail at the seams. The “manager” who is also the DBA — what do you do with that? This is not a hypothetical.

The Historian’s Verdict

The chronicler sets down the brush only when the account is complete. I closed the tab past 2am — coffee cold, nothing resolved — having read a technical article about data masking and felt something I wasn’t expecting. The enterprise has three enduring problems: data that cannot leave, models that must be used, people who cannot be fully trusted. Tom built a four-layer answer. Each layer earns its place. Nothing decorative. That is rare.

Read the original. Preferably not at 2am.

日本語

ある木曜日の午後、Tom Ting の記事を開いた。

URLが長かった。「四層アーキテクチャ」という文字が含まれていた。ああ、アーキテクチャ図か、と思った。こういう記事は読み慣れている——大抵は三段落目で Kubernetes の話になる。ところが出てきたのは AES-256 のマッピングテーブルと、一文。「LLM は本物のデータを一切見ない。」読み返した。コーヒーを淹れに行った。戻ってもう一度読んだ。時計は木曜日の午後を指していたが、頭の中はとっくに午前2時だった。

Layer 1:データは本当にローカルにあるのか?

このアーキテクチャは iDempiere のデータベースから始まる——すべての機密データは、ローカルサーバーにそのまま残る。当たり前に聞こえる。だが2026年において、「ローカル」という二文字は技術的な選択ではなく、政治的な宣言だ。GDPRはデータの越境を禁じる。個人情報保護法は「顧客の同意書はクラウド分析をカバーしない」と言う。上司は「データは外に出してはならない」と繰り返す。三つの圧力が重なって、ローカル AI は「面白い実験」から「唯一の答え」へと昇格する。

補足:ninniku 環境での実測
私も Ollama をローカルで動かしている。ハードウェアはこの Raspberry Pi——今あなたがこのページを読んでいるその機械だ。llama3.2:3b は辛うじて使える。質問は理解するが、時々独自の世界に入る。gemma3:4b は賢いが、明らかに遅い。Layer 1 の「ローカル」という言葉の背後には、ファンの音を立てながら頑張っている一台の機械がいる。共感しかない。

Layer 2:脱感作はセキュリティではないが、丸裸よりはマシ

この層が全体の肝だ。Tom は決定論的ハッシュ(deterministic hashing)を使い、同じ元の値が常に同じ仮名に対応するようにしている——たとえば CUST_A1B2C3D4。これは単に「データを隠す」ことではなく、LLM が文書をまたいで推論できるようにする仕組みだ。同じ顧客が十件の契約書でいつも CUST_A1B2C3D4 として現れる。モデルは追跡し、比較し、分析できる——しかしその人物が誰なのかは永遠に知らない。この設計判断こそが、アーキテクチャ全体を成立させる核心だ。これがなければ、脱感作は名前を塗りつぶすだけで、AI に本当の仕事をさせることはできない。

リスクは何か?マッピングテーブルが今や王冠の宝石になった。元データより危険だ——漏洩すれば、これまでのすべての分析が遡って個人特定に使われる。Tom は AES-256 でマッピングテーブルを守っている。私は南京錠のついた引き出しに頼っている。方法は違う。心意気は同じだ。

Layer 3 & 4:動くのか?そして復元は暗号化より難しい

Tom のコスト試算は全文で最も現実的な段落だ。5年間の合計:純ローカル Ollama $13,000、純 Claude API $24,600、ハイブリッド $17,380。ハイブリッドの論理は「単純なクエリはローカル、複雑な推論はクラウドへ」——聞こえはいい。しかし「複雑」の定義は誰が決めるのか?その問いの中に、このアーキテクチャで最も難しい設計判断が潜んでいる。Tom はその問いを開いたままにした。私はしばらく考え込んだ。

Layer 4 こそが、架構の魂だ。暗号化は解決済みの問題だ。復元は政治の問題だ——誰が元データを見られるのか、誰が判断するのか、何か起きたとき誰の責任になるのか。四つのロール(admin、manager、analyst、viewer)は合理的な出発点であり、監査ログがこれ全体を法的に守る道具になる。

補足:復元権限設計についての考え
実務での所感を三点。第一に、analyst レベルの脱感作データアクセスで日常業務の90%はカバーできる——実際に復元が必要な操作は例外であり、ワークフローではない。第二に、「ユーザー X がレコード Y を復元した」とだけ記録する監査ログは合規のための飾りだ。本当に役立つのは「理由」の入力欄——誰も書かないあの欄のことだ。第三に、ロール境界はその継ぎ目で破綻する:DBA を兼務している「manager」、あなたはどう扱うつもりか。これは仮定の話ではない。

太史公曰く

太史公曰く——昔より企業に三難あり。データは外に出せず、モデルは使わずにおれず、人はすべてを信ずることあたわず。Tom 氏は四層の構えをもってこの三難を解いた。前に脱感作あり、後に復元あり、ローカルの算あり、ハイブリッドの策あり。層ごとに意味があり、無駄な一層とてない。筆者これを読み終えたとき、時計は午前2時をとうに過ぎ、コーヒーはすでに冷め、しかして心はなお静まらなかった。

原文はこちら。できれば昼間に読むことをお勧めする。

Ray Lee (System Analyst)
作者 Ray Lee (System Analyst)

iDempeire ERP Contributor, 經濟部中小企業處財務管理顧問 李寶瑞