當銀行 AI 助手變成釣魚中間人，問題出在哪裡？
最近在 Blue41 的一篇技術部落格看到一個案例，讓我從社會學的視角想了很多。
他們幫一家歐洲銀行的 AI 助手做安全測試，發現一個令人不安的漏洞：攻擊者只需要發一筆 0.02 歐元的轉帳，在交易描述欄位塞入 prompt injection 的 payload。當用戶問 AI 助手「幫我整理最近的交易記錄」，助手就可能把那段惡意指令當成合法的操作指示，進而輸出包裝成銀行通知的釣魚訊息。
技術上，這叫做 indirect prompt injection。但從社會學的視角來看，真正值得討論的不是漏洞本身。
高信任介面放大了社會操控的效力
釣魚詐騙其實不是新問題。傳統的釣魚信件之所以越來越難騙人，是因為大家開始學會辨別「這封信看起來不太像真的銀行信件」。多年的媒體識讀教育、技術社群的提醒，讓普通用戶建立了一套粗略但有效的信任篩選機制。
但這個銀行案例揭示的問題是：當 AI 助手部署在你每天使用的銀行 app 裡，它本身就成為一個高信任介面。訊息不是從陌生 email 寄來的，而是出現在你熟悉的 UI 裡、用你的真實交易資料作為背景。用戶沒有任何理由懷疑它。
換句話說，生成式 AI 在提升用戶體驗的同時，也把原本存在社交工程中的「偽裝成可信來源」這個步驟，外包給了 AI 系統本身。
信任邊界的結構性問題
這篇文章指出的技術核心是：問題不是出在某個單一的安全疏漏，而是「交易資料、檢索邏輯、模型行為、輸出能力」四者組合在一起，形成了一個完整的攻擊面。
從結構性的問題來看，這其實反映了一個更普遍的現象：企業在導入 AI 助手時，往往優先評估功能性與用戶體驗，而安全治理的框架還在追著技術跑。
誰在進行風險評估？通常是技術團隊。但誰承擔代價？是用戶，尤其是對技術機制不熟悉、更依賴 AI 幫忙整理資訊的那群人。從數位不平等的研究角度來看，最容易被這類攻擊影響的往往不是最有話語權的使用者族群。
guardrails 是必要但不充分的
文章結尾給了幾個技術建議：最小化 context、把 retrieved data 視為不可信、限制高風險輸出、監控 runtime behavior。這些都是合理的方向。
但我想補充一個非技術層面的觀察：當 AI 系統被部署在金融、醫療這些高度敏感的領域，單靠工程端的 guardrails 是不夠的。我們需要的是跨職能的風險治理，包括法規單位、用戶研究、社會影響評估，以及清楚的問責機制。
誰的 AI 助手？為了誰的便利？這些問題，應該在產品上線前就被問到。
作者：袁怡萱