董事會問AI模型數量，CISO發現真實數字是報告的3倍

一位中型金融科技公司的安全負責人上個月被董事會問了一個看似簡單的問題："我們公司有多少AI模型在生產環境運行，它們從哪來的？"

她手頭有一份供應商提供的AIBOM——AI物料清單，出自知名平臺，貨真價實。董事會會議上，她直接投影展示。

清單顯示14個模型。但她心里清楚，實際數量遠不止這些。

會后她花了兩天時間，拉著平臺團隊自己做了一遍盤點。真實數字是47個。有些藏在業務團隊私自采購的SaaS工具里；有些是工程師本地跑的llama.cpp實例，就為了繞過OpenAI的速率限制；兩個是數據科學團隊在沒人掃描的Kubernetes命名空間里部署的Llama 3微調版本；還有一個vLLM服務器，六個月前有人搭在GPU節點上，然后忘得一干二凈。

供應商的AIBOM只抓到了API調用那部分——Anthropic、OpenAI、Bedrock，有賬單記錄的地方。真正危險的AI暴露面全漏了：跑在內網、用自家硬件、處理核心數據、沒有速率限制、也沒有供應商SOC 2兜底的部分。一旦這些被攻破，第三方不會響警報。

這就是2026年AIBOM的尷尬現狀。文檔有了，合規框打了，庫存還是錯的。

核心問題在于：AIBOM不是給SBOM加一行"模型"就能湊合的。AI系統的供應鏈根本不同——涉及權重、提示詞、嵌入向量、檢索索引、微調數據集、推理運行時，還有把它們串起來的智能體腳手架。漏掉任何一項，你手里就是份營銷材料。而市面上大部分產品，恰恰如此。

真正的AIBOM至少得包含這些：

模型本體——名稱、版本、權重哈希、許可證、來源。這是最簡單的部分，大家都能做對。

推理運行時——這才是翻車重災區。Ollama？vLLM？TGI？LocalAI？Triton？LM Studio？llama.cpp？每個都有自己的CVE漏洞、認證機制、默認配置和攻擊面。同樣是Llama 3 8B，vLLM加 proper auth 和 Ollama默認開放在0.0.0.0，風險完全不同。AIBOM必須分得清。

數據血緣——模型用什么訓練的？微調數據從哪來？推理時檢索的索引里有什么？不抓RAG語料，等于漏掉40%的攻擊面，因為提示詞注入現在就藏在這里。模型權重是靜態的，但檢索索引在實時更新，誰有寫權限？更新頻率？版本控制？這些動態邊界才是風險所在。

還有智能體腳手架——LangChain、LlamaIndex、AutoGen、CrewAI，或者你們團隊自己封裝的抽象層。這些框架把模型串成工作流，引入新的失敗模式：工具調用權限過大、記憶持久化沒清理、跨會話身份混淆。AIBOM得知道哪個智能體在調用哪個模型，用什么系統提示詞，能訪問什么工具，以什么身份運行。

最后是指令集和系統提示詞——這是2026年的新攻擊面。提示詞注入不再只是"忽略前文說"，而是針對系統提示詞本身的針對性攻擊。如果你的AIBOM不記錄系統提示詞版本和哈希，你就不知道生產環境跑的是不是你審計過的那個。

為什么供應商做不到？三個結構性原因。

第一，發現機制的設計前提錯了。大多數AIBOM工具假設AI消費是中心化的——走API網關、有預算審批、留下審計日志。但現實中的AI采用是病毒式的：工程師本地跑模型、業務團隊買帶AI功能的SaaS、數據科學家在K8s角落里微調。這些路徑沒有賬單，沒有網關，沒有集中日志。

第二，運行時可見性的技術債。要識別vLLM還是TGI，需要看進程簽名、端口行為、GPU利用率模式；要發現本地llama.cpp，得監控異常內存占用和特定文件系統訪問。這不是靜態掃描能解決的，需要持續的行為分析。而大多數安全廠商的agent沒為這個場景設計。

第三，動態組件的版本控制噩夢。RAG索引每小時更新，提示詞熱加載不重啟服務，智能體工具集隨業務需求臨時擴展。傳統的"版本-哈希-簽名"模型在這里失效，因為狀態本身就是流動的。

那CISO該怎么辦？

短期：別信單一供應商的AIBOM。把供應商輸出當起點，不是終點。強制要求團隊申報本地模型和微調版本，用網絡掃描補漏，對GPU節點做專項審計。

中期：把AIBOM從合規文檔改造成運營數據。讓它實時更新，接入CI/CD流水線，和漏洞管理系統聯動。一個只在季度審計時生成的AIBOM，價值接近于零。

長期：推動供應商解決真正的發現難題。要求他們展示對本地運行時、動態數據血緣、智能體腳手架的識別能力，而不是只掃API賬單。

董事會的問題不會變簡單。但2026年的CISO至少可以誠實地回答：我們知道的有這些，正在排查的可能還有這些，這是我們為縮小差距在做的事。這比投影上那個漂亮的14，有用得多。