近 70% 的組織，已經在自家系統裡發現由 AI 工具造成的漏洞，其中五分之一，甚至因此發生了重大資安事件。面對這個現實，業界正在提出一個新名詞：AI 軟體安全，簡稱 AISec，用來因應 AI 從輔助角色，正式走進軟體開發核心之後所帶來的全新風險。
AI 不只寫程式，還自己上線改系統
過去二十年，應用程式安全建立在一個幾乎沒人質疑過的假設上：被保護的軟體，是由人開發、由人維運的。但 AI 已經深度進入軟體生命週期，傳統 AppSec 的假設仍停留在「人寫、人測、人負責」。
當 AI 也開始參與編碼、測試、部署與維運時，資安風險就從程式漏洞擴大到模型、代理、權限與責任邊界。
這個轉變的起點，是 AI 在軟體生命週期裡角色的質變。AI 過去只是幫助開發者加快寫程式速度的工具，如今卻參與從系統設計、實作、測試，到維運與調校的每一個階段，人力介入的比例愈來愈低。
與此同時，企業正朝著「自主企業」（Autonomous Enterprise）的方向前進，讓 AI 代理人在商業流程與 IT 維運中，自行完成感知、推理、決策、行動與學習的完整循環。這不是軟體開發的小幅演進，而是本質上的一場革命，過去被視為理所當然的防護對象、治理範圍與信任基礎，都必須被重新檢視。
舊工具沒失靈，是保護錯了對象
既有工具並沒有失去價值，問題不在工具本身，而在於它們原本鎖定的保護對象，已經跟現實脫節。
AI 生成程式碼的速度，已經超過團隊實際能審查的速度，漏洞被引入的速度也比過去任何時候都快；更關鍵的是，AI 如今能直接修改系統、調整設定、把更新推送到正式環境，往往缺乏直接的人工監督，讓企業愈來愈難回答這段程式碼從哪裡來、誰該負責、是否可以被信任。
開發者被究責，但問題其實不在他們
開頭那組數字，只是問題的一角。追查原因時，45% 的資安主管、開發者與應用程式安全工程師，把矛頭指向開發者；但同一份調查也顯示，2025 年有 46% 的開發者坦言不信任所用 AI 工具的準確性，較 2024 年的 31% 明顯上升。
使用 AI 工具的開發團隊比例，也已攀升至 94%，主要驅動力是生產力與效率需求，其中超過半數開發者，使用的是未經 IT 部門授權的「影子 AI」，讓錯誤與責任更難追蹤。
真正該究責的不是開發者個人，而是他們長期身處的系統。安全編碼的最佳實務，從未被真正教導、也未被強制執行。
在監理政策成熟之前，企業必須建立自我治理機制，包括設定基礎安全規則並搭配實戰訓練、追蹤所有正在使用的 AI 工具與部署方式、成立跨層級團隊持續調整政策並促成同儕監督，才能讓生產力壓力，不至於演變成企業無法承受的風險。
AISec 該承擔的角色
AISec 正因如此有其存在的必要，它必須涵蓋模型與提示詞本身的安全防護，確保自主代理人的行為符合預期，並為 AI 在正式環境中做出的決策設下護欄，同時具備追蹤能力，掌握整個生命週期中人類與機器共同形塑出來的完整軌跡。
這門學科出現的時間點，確實比漏洞蔓延的速度晚了一步，但那些現在就開始超前部署 AISec 實務、而非等到事故發生後才回頭補救的企業，仍能在「自主企業」從特例變成常態的世界裡，站在更有利的位置。
【推薦閱讀】
◆ 什麼是「上下文炸彈」？防守方第一次把 AI 提示注入反過來當武器
◆ 【AI Agent 身分治理】企業擁抱 AI Agent 卻幾乎不做把關，三個方向現在就能補救
◆ 資安長看不到的「暗物質」：放手讓 AI 自動修補前，先過 5 道門檻
＊本文開放合作夥伴轉載，參考資料：Forbes、SecurityBrief，首圖來源：Unsplash
（責任編輯：鄒家彥）
