這幾年，很多企業開始使用 AI 協助寫程式。有人拿來加速開發、有人拿來修 Bug、有人甚至直接讓 AI 建立整個網站系統。
但很少人真正思考一件事：
「AI 會寫功能，不代表 AI 會幫你守住資安。」
AI 可以快速產生登入系統、會員功能、API 串接、資料庫操作，但如果開發者沒有資安意識，AI 很可能會把密碼明碼儲存、直接相信前端資料、忘記權限驗證、產生 SQL Injection 漏洞，甚至洩漏 API Key。
更可怕的是：AI 產生的程式，看起來通常「非常正常」。因為它能跑、功能也成功，開發者就容易誤以為「沒問題」。但真正的問題，往往是在「攻擊者開始測試時」才會出現。
很多人以為 AI 的問題是寫錯語法、邏輯錯誤或功能異常。其實不是。
真正危險的是：
「AI 會產生看似專業、實際上不安全的程式碼。」
這種風險比 Bug 更難發現。因為 Bug 很快就會壞掉，但資安漏洞，可能半年後才被攻擊。
原因其實很簡單。AI 的本質是「預測最像人類會寫的內容」，而不是「驗證這段程式是否符合安全標準」。它學習的是大量公開程式碼，而公開世界裡，本來就有很多不安全的程式。
也就是說，AI 很可能把「網路上常見但危險的寫法」，當成正常答案。常見例子如下：
query = "SELECT * FROM users WHERE id = " + user_input這種寫法在網路上很多，AI 很容易學到。但這會造成 SQL Injection，攻擊者甚至可能直接刪除整個資料庫。
const apiKey = "123456789";AI 非常常這樣做，因為這樣最容易「快速成功」。但一旦程式碼被上傳到 GitHub，金鑰外洩、雲端帳號被盜刷、第三方服務被濫用都可能發生。
if(user.role === "admin"){
allowAccess();
}問題是前端資料可以被修改。真正的權限驗證，應該在後端進行。
真正重要的，不是「禁止 AI」，而是建立 AI 的安全使用規範。這才是關鍵。
不要讓 AI 擁有過多權限
AI 不應該直接擁有 Production 權限、真實客戶資料、金流系統權限或管理者 API。最安全的做法是使用測試環境、使用假資料、限制權限範圍，並採用最小權限原則。
建立 AI Code Review 機制
AI 產生的程式碼必須經過人類審查，而且不只看功能。真正要檢查的是：輸入驗證、權限控管、敏感資訊暴露、Injection 風險、XSS 漏洞、CSRF 防護。很多企業開始建立 AI Code Review Checklist 與安全開發 SOP。
導入自動化資安掃描
現在已有許多工具可協助檢查 AI 程式碼，包括 SAST（靜態程式碼掃描）、Dependency Scan（套件漏洞掃描）、Secret Scan（金鑰掃描）、Container Security Scan、OWASP 檢測。目前很多 CI/CD 流程已把資安掃描變成自動化標準流程——只要 AI 送出程式，系統就先掃描，不安全就禁止部署。
要求 AI 遵守安全 Prompt 規範
AI 的輸出品質很大程度取決於你怎麼問。如果只說「幫我做登入系統」，AI 很可能只做「能登入」。但如果明確要求：密碼使用 bcrypt、防止 SQL Injection、加入 CSRF 防護、Session 安全設定、Rate Limiting、輸入驗證——AI 產出的品質會完全不同。
不要把 AI 當成資安專家
AI 可以協助撰寫、檢查、分析，但它不能取代資安架構師、滲透測試、安全審計與威脅建模。真正的攻擊很多是「情境型」的，例如權限繞過、商業邏輯漏洞、API 濫用、身份驗證流程缺陷，這些往往需要經驗、攻擊思維與系統理解。
過去，「會寫程式的人」很稀缺。現在，「會要求 AI 寫程式的人」越來越多。
未來真正稀缺的，將不是「會不會開發」，而是：
「知不知道什麼叫安全地開發。」
因為 AI 可以大量生成程式，但它也可能大量生成漏洞。
AI 不會自動讓系統變安全。它只會放大開發者原本的能力與習慣。
所以未來真正重要的，不只是 AI 能不能寫程式，而是：
人類能不能駕馭 AI 的風險。
這才是 AI 開發時代，最核心的技術能力。
