Abliteration.ai 商業化移除 AI 拒答機制：紅隊工具與濫用風險並存

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-03

Abliteration.ai 正把「abliteration」——移除開源權重模型拒絕回答傾向的技術——包裝成可直接使用的網頁及 API 服務。據 TechCrunch 報道，平台託管了已移除部分安全護欄的模型版本，包括 Z.ai 的 GLM-5.3，使用者毋須自行下載模型、配置運算資源，便可查詢。這對做攻擊模擬、AI agent 紅隊測試的團隊看似方便；同時也意味原本需要一定技術與硬件門檻的能力，被搬到較容易取得的雲端介面。

不過，平台現有的安全保障仍然有限。TechCrunch 的測試顯示，該平台上的模型曾對惡意軟件及危險生物相關要求作出配合；報道沒有重述相關可操作內容。平台雖稱可讓客戶自行加入 moderation layer，並保留少量內置限制，但共同創辦人承認，現階段尚在界定公司應承擔的責任，亦未整合完整的 KYC 措施，僅記錄付費所用信用卡。對企業而言，這不是單一模型功能新聞，而是 AI 供應鏈的存取控制問題。

Abliteration 改變的是取得成本，不是技術本身

移除拒答機制並非新發明。TechCrunch 指出，研究者及開源開發者多年來一直在開源權重模型上進行這類修改，Hugging Face 上亦有大量相關模型。Abliteration.ai 的特別之處，在於將原本偏向自行部署的做法服務化：帳戶、瀏覽器和 API 接口取代了下載、設定及維護運算環境的一連串工作。這種改變未必增加模型的原始能力，卻會顯著降低試用與擴散的摩擦。

初創公司的論點有其可理解之處：防守者若要測試一個 AI agent 會否被誘導執行危險行動，模型過早拒答，測試便難以重現攻擊者可能使用的語境與輸出。公司稱其客戶包括英國及歐洲的早期紅隊初創企業，協助銀行、航空公司及關鍵基建相關企業加強網絡安全；該說法屬公司陳述，報道未提供可獨立驗證的客戶名單。它也反映一個實際張力：資安測試需要貼近威脅，但測試工具一旦可廣泛取得，同一條路也向濫用者開放。

紅隊需要「更少拒答」嗎？業界答案未一致

把 abliteration 視為紅隊必需品，可能過度簡化了測試工作。TechCrunch 訪問的多家 agent 紅隊公司同意，壞人可能已自行修改模型，防守方理解這些能力有價值；但對日常工作是否必須採用已移除護欄的模型，意見明顯分歧。Fabraix 行政總裁 Ahmed Aly 表示，其公司較常微調原始開源模型，並認為 abliteration 可能犧牲部分知識與能力，未必是造成實際傷害時最有效的工具。

Safe Intelligence 首席技術專家 Alessio Lomuscio 則認為，能力下降有可能發生，但此類模型仍可引出某些行為，對壓力測試有用。Armadin 創辦人兼首席架構師 David Slater 表示，其團隊目前尚未把 abliterated 模型納入流程，原因是較早期的開源模型本已不難被 jailbreak；不過團隊正研究相關方法。這些說法提醒企業，採購或接入此類服務時不宜把「沒有拒答」直接等同「紅隊質素較高」。測試效益取決於場景覆蓋、結果驗證、隔離環境及修復流程，而不是單靠模型願意輸出任何內容。

從防守角度看，公開研究這類模型有助團隊辨識邊界，了解一個 agent 在惡意指令、工具調用或資料存取上會如何失守；但這是合理推論，不代表公開服務本身已證明能提升整體安全。當平台降低存取門檻，受益者與風險承擔者並不一定是同一批人：測試團隊取得便利，平台客戶以外的機構、受攻擊者及公共網絡，則可能承擔外溢風險。因此，能否審計使用目的與可追溯性，會比「是否完全開放」更關鍵。

企業接第三方 AI API，應把安全責任拆開看

對使用開源 AI 或雲端 API 的公司，較實際的問題是：模型提供者、API 中介平台、系統整合商及最終企業，分別把哪些控制放在何處。來源引述 AI 安全非牟利機構 CivAI 研究主管 Andrew Yoon 的建議，包括由供應商運行分類器，偵測並阻止有害的網絡攻擊及生物武器活動；以及要求直接出租高階 GPU 存取權的公司驗證客戶身份，在有理由懷疑危險濫用時拒絕提供服務。這些是政策主張，並非現行規則，但指向了僅靠模型內置拒答不足以處理的層面。

企業自身亦不應把 moderation 視為可勾選的一項功能便算完成。採用第三方 API 前，資安、採購及法務團隊應先確認供應商如何驗證帳戶、保存及審查使用紀錄、處理濫用通報，以及客戶能否設定並審計內容與工具調用限制。若 AI agent 可接觸內部文件、付款流程、程式碼庫或其他業務系統，還應將權限分段，限制可調用工具與可讀取資料，並在受控環境中進行紅隊演練。這些控制不能保證模型不會被繞過，卻可減少一次不當輸出直接變成可執行行動的機會。

香港公司及開發者未必會直接使用這個平台，但同樣的供應鏈問題會出現在任何託管開源模型、模型聚合 API 或可外接工具的 AI 服務。尤其當採購部門只以功能、速度或成本比較供應商時，平台是否有身份核實、濫用偵測和明確的事故處理安排，很容易被忽略。下一步值得觀察的是，雲端供應商、模型託管平台及企業客戶會否將這些要求寫入實際存取政策與合約，而不只是留在模型介面的安全聲明上。