企業 AI 從治理邊界到規模化落地,我把它分為七個階段,今天我們一起來走一次。首先要了解公司在治理上的落差,接著討論 AI 在幫我們整理資料、寫程式、直接動手這三個層面,我們所畫的線,它有沒有越線。最後是治理、賦能以及擴散三個議題。
重點摘要
- 94% 主管認為 AI 是未來 12 個月影響資安最大的新興技術(WEF),但 84% 企業尚未針對 AI 重新設計職務(Deloitte)——治理與人才是最大缺口。
- 發生 AI 安全事件的企業中,68% 沒有落地的 AI 治理政策;影子 AI 安全事件一年內翻倍,平均成本 539 萬美元(IBM)。
- AI 程式碼語法正確率 99.9%,資安通過率卻只有 56%,44% 帶有 OWASP Top 10 嚴重漏洞(Veracode)。
- AI Agent 最脆弱的是人、系統、Agent 之間的「交接點」,授權應以目的與行為約束(BCG)。
- 治理檢核的每一項,都要回答「誰負責?」與「如何證明?」(WEF/Capgemini ACAP Playbook)。
治理落差:管理跟得上嗎?
讓我們先看公司在 AI 治理上面,大家掌握得如何?可以先問自己三個問題,看看是不是都回答得出來:
- 公司有多少人在用 AI,我們知道嗎?
- AI 已經幫我們做了哪些事?
- 我們的管理跟得上嗎?
世界經濟論壇在今年一月初發表了 《Global Cybersecurity Outlook 2026》,對 92 個國家、800 多位企業主管做調查,其中 94% 認定 AI 是未來 12 個月對企業網路安全影響最大的新興技術,比雲端技術的 61% 高上許多,這並不令人意外。其中 87% 的主管認為 AI 相關漏洞正在狂飆,而且非常恐怖,所以我們今天坐在這裡一起關注,非常合理。
接下來這一篇含金量就很高了。Deloitte 為了了解企業 AI 導入現狀,在今年初對全球 24 個國家與地區的企業主管做了 3,235 份量化問卷,為求謹慎,還加上 15 場與企業高階主管及 AI/資料科學專家的深度質化訪談。他們有一個驚人的發現:企業在 Infrastructure、Strategy 與 Data Management 做足準備的比例相對高,但在「風險、治理」與「人才」上的準備卻遠遠不足。
這形成了治理上的鴻溝:管理跟不上,人才密度也跟不上。這對我們是個挑戰,也是一個非常好的機會——亂世出英雄。為自己加油,也為身旁的夥伴加油!
資料邊界:哪些資料可以給 AI 看?
這是大家每天都在關注的議題,大家多半自認為做得不錯,但可能過於樂觀。請思考一下,自己能不能回答這些問題:
- 公司的哪些資料可以給 AI 看?
- 哪些資料不行?
- 我們對資料的流向,掌握得很好嗎?
IBM 在 《Cost of a Data Breach Report 2026》 中提到,有 21% 被入侵的企業已證實發生 AI 安全問題,平均成本高達 533 萬美元,大約 1.7 億台幣!其中最嚴重的是 MCP 與外部連接風險,還有雲端安全設定錯誤這種低級錯誤;另外,資料下毒、模型逆向攻擊、提示詞注入也很嚴重。
影子 AI:一年內翻倍
同一份報告也指出,讓公司很痛的還有 Shadow AI(影子 AI),安全事件一年內翻倍。什麼是影子 AI?就是員工有意或無意使用公司沒有核准及管理的 AI。它造成的後果是:49% 資料外洩、42% 營運中斷、35% 公司聲譽受損。
為什麼會這麼慘?這份調查直接告訴我們答案:發生 AI 安全事件的企業中,有 33% + 35%,也就是高達 68% 根本沒有落地的 AI 治理政策。
我們可以反思一下:公司目前做到了多少?資安專業同仁跟主管們,有沒有正視這個問題?
程式邊界:AI 寫的程式,有人檢查嗎?
接下來看看現在很流行的 Vibe Coding。你的公司有沒有人在自己寫程式解決生產力問題?
- 公司有沒有人用 AI 自己寫程式?
- AI 寫的程式,有人去檢查嗎?
- 這些程式用了哪些套件或 API,我們知道嗎?
根據 PMLR 在 2026 年初發表的學術論文,研究者挑選 GitHub 上 100 個知名開源專案,看看人類工程師曾經修補過的安全漏洞,AI 會不會再犯。他們出了 186 個陷阱題,結果無論哪一組 AI,都能把功能寫到差強人意、通過功能測試,但在資安測試上卻表現很差——大約八成 Vibe Coding 的程式碼都有安全漏洞。
專門提供程式安全檢測的平台廠商 Veracode 在今年五月公布數據:AI 的語法正確率在過去幾年進步飛快,現在幾乎可以穩定做到 99.9%;但資安通過率卻沒什麼進步,好像 AI 一直學不會一樣,平均只有 56%。也就是說,AI 產出的程式碼中高達 44% 帶有 OWASP Top 10 嚴重漏洞。
進一步看,AI 模型在 CWE-327(過時加密演算法)與 CWE-89(SQL Injection)已經表現得很好,分別有 82 到 86 分;但在 CWE-80(XSS)與 CWE-117(Log Injection)卻慘不忍睹,成功率連 15% 都不到。也就是說,在核心的安全控制上,AI 寫的程式風險非常高。
為什麼 AI 寫出安全程式這麼難?
看看 Sonatype 從 2019 年統計至今的開源惡意套件成長:到去年底已經超過 123 萬個惡意開源套件,而且成長速度越來越快。也就是說,攻擊者愈來愈常利用開源套件與軟體供應鏈當作攻擊入口。最新數據是 2025 年底,每 5 個 npm release 就有約 1 個被判定存在漏洞。
當你或同事請 AI 幫忙寫一個生產力工具,很容易出現這個情境:AI 很快寫出可以動的程式,自動推薦 npm 套件問你要不要用,你 99.999% 會說同意,而且希望它不要一直問。沒幾分鐘程式寫好了,功能測試正常、比想像中更完美,你超級有成就感——可是剛剛 AI 用的套件,你並沒有一個一個去檢查版本、漏洞、來源與維護狀態,所以就中標了。
還記得嗎?裡面有 44% 會帶有 OWASP Top 10 嚴重漏洞。
行動邊界:AI 做錯事,誰負責?
接下來是 AI Agent 要面對的 Action Boundary。我們是否也能回答這些問題?
- 公司已經有 AI Agent 進入系統流程了嗎?
- 它可以自己做決定嗎?
- AI 如果做錯事,誰可以負責?
在 Deloitte 對 3,235 位高階主管的調查中,23% 的公司已經一般性使用 Agentic AI;未來兩年內,74% 的企業認為會達到中度使用。也就是說,許多實際業務場景會開始讓 Agent 進入正式流程。
McKinsey 在今年 3 月 《Securing the Agentic Enterprise》 中提到,企業已經認知到 AI Agent 的安全風險,相關預算會從現有的 4% 提升到 15%。接下來三年的資安預算會集中花在哪裡?看前三名就好:IAM、治理風險與合規、機密資料隱私。
交接點,就是最脆弱的地方
BCG 前陣子發表了一篇含金量很高的報告,推薦大家一定要去看。它說:對人員的控制靠判斷力與後果來約束;對應用程式的控制靠寫死的規則;對 Agent 的控制則要靠專屬身分與權限。這三者各自獨立都沒問題,但運用 AI Agent 時,往往是由員工下指令、Agent 呼叫企業系統、再呼叫另一個 Agent 或 API 完成交易——這個過程涉及三個領域的換手,換手時授權邏輯未必能延續,所以「交接點」就會變成最脆弱的地方。
因此 BCG 提出一種以目的與行為去約束的授權機制:要去理解這個 AI Agent 現在為了什麼目的、正在做什麼行為,這個行為是否符合原本被授權的目的。
- 任意讀取所有客戶資料?
- 把資料傳到外部工具?
- 自動修改付款帳戶?
- 自己核准付款?
治理:誰負責、怎麼規範、查得到嗎?
接下來進到 Governance。大家的公司在這部分做得如何?
- 公司裡誰負責 AI 治理?
- AI 可以做什麼,有清楚的規範嗎?
- AI 做過什麼,我們查得到嗎?
BCG 把解法整理成兩個核心概念:Purpose(目的)——Agent 可以達成什麼?Conduct(行為)——Agent 可以用什麼方式達成?然後要看五個元素:
- 專屬身分Dedicated identityAgent 必須有自己的身分,不能借用員工帳號登入,這樣才知道「到底是哪一個 Agent 做的」。
- 逐次授權Per-request grant每一個任務都重新授權,而不是一次給永久權限。任務內容改變,權限也要重新評估。
- 執行中驗證Runtime verificationAgent 執行任務時要持續檢查,尤其是付款、刪除資料、變更權限等高風險動作,不能只在一開始驗證一次。
- 明確責任歸屬Clear accountability必須有一個明確的人類 Owner,可以核准、介入,必要時停止 Agent。
- 完整可追溯Full reconstructionLog 不只要記「做了什麼」,還要能還原:為什麼做、怎麼做、用了什麼權限、哪些控制機制被觸發。
WEF 的 ACAP 框架:完整生命週期
世界經濟論壇更進一步提出 ACAP(Agent Capability and Authorization Profile)框架,要求記錄 AI Agent 從規範、設計、部署到持續治理的完整生命週期:
- Agent 治理政策Agent guidelines先由企業建立 Agent 治理政策:哪些任務可以交給 AI、哪些不能交、什麼情況要人工核准。
- 系統設計與評估System design and assessment把治理原則轉成具體系統設計。針對某一個工作流程,定義 Agent 需要哪些能力、資料與權限,並進行風險評估。
- 準備並部署Prepare and deploy把前面的設計轉成真正可執行的權限設定、風險分類與部署控制。
- 監控與改善Monitor and improveAgent 不是設定好就結束,上線後要持續觀察它的行為、風險與實際使用狀況,再調整 ACAP。
賦能:從 Pilot 走到 Production
- 有規則了,員工知道該怎麼做嗎?
- 有工具了,流程就能安全落地嗎?
- 從 Pilot 走到 Production,中間還缺什麼?
Sonatype 《2026 State of the Software Supply Chain Report》 的核心概念是 Compliance-as-Code:把企業的資安與合規要求,轉化成開發流程中可以自動檢查、強制執行的規則。資安不能等到軟體開發完成才檢查,而應該從設計階段就納入,並貫穿整個軟體生命週期。它提出四個階段:
- 政策階段Policy要有驗收標準,將資安與合規要求寫入系統設計及驗收條件。
- 開發階段Development要有 SAST、SCA、SBOM,利用自動化工具檢查程式碼漏洞、第三方套件及軟體組成。
- 部署階段Deployment要有 Vulnerability & Component Health Gates,建立漏洞與元件健康檢查關卡,不符合標準就阻止部署。
- 稽核階段Audit要有 Evidence for Procurement & Regulators,保留 SBOM、檢測結果及合規證明,供採購單位與監管機關查驗。
ACAP Playbook:一張治理檢核表
更具體的來了。WEF/Capgemini 《AI Agents in Action: ACAP Playbook》 針對 AI Agent 的系統設計與評估(System Design and Assessment)提出一張治理檢核表。它依據前面提到的框架,將每一階段的治理定義出細項步驟,並要求每一項都落實回答四個問題:
相關細節請參考簡報與文獻,有問題歡迎再跟我討論。
擴散:控制住風險,持續放大 AI
終於,我們來到最後一個階段。各位主管請問自己三個問題:
- 能把厲害部門的成功經驗複製到其他部門嗎?
- AI 專案越來越多以後,會不會失控?
- 有沒有辦法控制住風險,然後持續將 AI 放大?
Deloitte 《State of AI in the Enterprise 2026》 問了三千多位企業主管:你們導入 AI 是只在工具層次的使用?還是已經進入流程?或是更進一步改變企業的產品、服務與商業模式?
請注意這個數字,藉此了解自己公司的位置。貴公司呢?有沒有克服前面提到的種種問題、定義好治理、做好規範,然後擴大到公司的每一個角落?
常見問題
企業 AI 治理可以分成哪幾個階段?
可以分成七個階段:先看清治理落差,再檢視三條安全邊界——資料邊界(AI 可以看哪些資料)、程式邊界(AI 寫的程式是否安全)、行動邊界(AI Agent 可以做什麼),最後是治理、賦能與擴散,讓 AI 在控制住風險的前提下規模化落地。
什麼是影子 AI(Shadow AI)?為什麼危險?
影子 AI 是指員工有意或無意使用公司沒有核准及管理的 AI 工具。IBM《Cost of a Data Breach Report 2026》指出,影子 AI 安全事件一年內翻倍,平均成本高達 539 萬美元,造成 49% 資料外洩、42% 營運中斷、35% 聲譽受損;而發生 AI 安全事件的企業中,有 68% 沒有落地的 AI 治理政策。
AI 寫的程式(Vibe Coding)安全嗎?
功能通常沒問題,資安卻不及格。Veracode 數據顯示,AI 程式碼的語法正確率接近 99.9%,資安通過率卻只有 56%,約 44% 帶有 OWASP Top 10 嚴重漏洞;PMLR 2026 年的研究也發現約八成 Vibe Coding 程式碼有安全漏洞。AI 自動推薦的開源套件更要逐一檢查版本、漏洞、來源與維護狀態。
企業該如何管控 AI Agent 的權限?
BCG 建議以目的(Purpose)與行為(Conduct)約束授權,並落實五個元素:專屬身分(不借用員工帳號)、逐次授權(每個任務重新授權)、執行中驗證(高風險動作持續檢查)、明確責任歸屬(有人類 Owner 可介入或停止)、完整可追溯(Log 能還原為什麼做、怎麼做、用了什麼權限)。
什麼是 WEF 的 ACAP 框架?
ACAP(Agent Capability and Authorization Profile)是世界經濟論壇提出的 AI Agent 治理框架,涵蓋完整生命週期:第 0 步建立 Agent 治理政策、第 1 步系統設計與評估、第 2 步準備並部署、第 3 步上線後持續監控與改善。WEF 與 Capgemini 的 ACAP Playbook 進一步要求每個檢查項目回答:要做什麼、做到什麼程度、誰負責、留下什麼證據。
什麼是 Compliance-as-Code?
Compliance-as-Code 是 Sonatype 提出的概念,把資安與合規要求轉成開發流程中可自動檢查、強制執行的規則,分四個階段:政策階段寫入驗收標準、開發階段導入 SAST/SCA/SBOM、部署階段設立漏洞與元件健康檢查關卡、稽核階段保留 SBOM 與檢測結果作為合規證據。
參考資料
- World Economic Forum,《Global Cybersecurity Outlook 2026》
- Deloitte,《State of AI in the Enterprise 2026》(2026 年 1 月)
- IBM/Ponemon Institute,《Cost of a Data Breach Report 2026》
- PMLR,2026 年 AI 程式碼安全性研究論文(GitHub 100 個開源專案、186 個漏洞測試題)
- Veracode,《GenAI Code Security Report 2026》
- Sonatype,《2026 State of the Software Supply Chain Report》
- McKinsey & Company,《Securing the Agentic Enterprise》(2026 年 3 月)
- Boston Consulting Group(BCG),《The Authorization Gap: Why Yesterday's Controls Won't Work with Today's Agents》(2026 年 9 月 22 日)
- World Economic Forum/Capgemini,《AI Agents in Action: ACAP Playbook》(2026 年 5 月 26 日)
完整出處與連結請見 參考文獻(Google 文件)。
關於講者:楊宏文 Hubert Yang
普萊德科技 AI 顧問|前緯創集團顧問
受邀於 Ai Network × CompTIA 主辦的 2026 CompTIA Skills Day Taiwan「高階決策者的 AI 資安戰略(Securing the AI-First Enterprise)」論壇分享,從企業 AI 導入現場出發,談生成式 AI 的治理框架與安全邊界。
更多關於楊老師