SAS CIO揭內部GenAI實戰經驗：員工自建4,200支AI代理，AI Coding也改變工程師角色

SAS CIO Jay Upchurch日前接受專訪時透露，SAS內部有5,000多個微軟生成式AI助理Copilot授權，自家員工更用來建立超過4,200支AI代理。這些代理不只是個人生產力工具，部分甚至已成為企業級應用，協助工程師跨系統操作、搜尋知識和執行維運流程。

在軟體開發方面，SAS也大規模導入AI輔助開發。從需求蒐集、使用情境整理、軟體開發待辦事項（Backlog）管理，再到程式生成和驗證，都有AI參與。Jay Upchurch直言，有了AI輔助，工程師的角色正在改變，不再從零開始寫程式，更像是從一個「已經能運作的版本」接手迭代，工程師的基礎知識與專業素養也更顯重要。

先從推廣GenAI助手開始，意外催生大量AI實驗

SAS如何推動員工用生成式AI？其實很簡單。他們先採購微軟生成式AI助理Copilot的授權，約5,000多個，然後導入知識工作者的日常工作中，讓員工自行探索、嘗試AI如何協助自己工作。

結果，企業內部很快地出現各種零散但有趣的AI實驗，有些人用AI整理會議和文件，有些人用來搜尋知識、撰寫提案，也有人開始嘗試AI輔助開發和維運自動化。

但SAS後來發現，若缺乏制度化推動，這些AI創新很容易停留在個人實驗。因此，SAS後來展開一項名為Project Horizon的AI推動計畫，在各部門設置AI推動者，來分享AI使用經驗、推廣成功案例和交流新想法。

這項計畫不只是高層主導的AI專案，更像是一種企業內部的AI擴散機制。Jay Upchurch形容，SAS本來就擁有強烈的好奇心文化（Curiosity engine），而AI的導入，就像替這個文化「再添一把火」，放大AI探索熱潮。

5,000個Copilot授權，催生出4,200支AI代理

最驚人的是，SAS內部AI代理的成長速度。

Jay Upchurch透露，目前SAS有5,000多個Copilot授權，自家員工用這些授權，建立了超過4,200支AI代理。這些代理大多鎖定特定知識領域和工作流程，供個人或團隊使用，例如IT維運知識查詢、雲端支援流程、提案文件生成或企業知識搜尋等。

而且，每支代理都由建立者自行管理生命周期。這也意味著，企業IT角色也在大幅變化，從過去的建立系統、提供工具，到現在各部門員工自己建立AI工具，IT逐漸轉向平臺治理、安全管理和AI標準管理。

SAS甚至開始從這4,200支員工自建的代理中，挑選部分案例、正式發布為企業級代理，目前約有12支供內部使用。其中包括協助撰寫提案邀請書（RFP）的代理，以及可整合ServiceNow、Datadog等工具的維運支援代理。

以RFP代理為例，它可以快速整理過往提案、搜尋技術規格和生成投標內容。這類應用之所以重要，是因為大型企業的RFP流程通常涉及大量重複性知識工作，包括技術文件、法規要求、安全條件與歷史提案內容等，往往高度依賴人工整理。

另一類則是協助雲端維運的AI代理。這些代理可整合ServiceNow、Datadog等工具，協助工程師搜尋知識、查詢工單和執行維運流程。Jay Upchurch表示，工程師透過AI代理就能完成跨系統操作和資訊查詢，不必再頻繁切換不同系統和工具。

這些實例，也反映SAS目前推動的Agentic AI方向，不只是單純的任務型聊天機器人，而更接近跨系統協作的AI工作介面，讓AI成為企業日常流程中的新作業層。

Jay Upchurch點出，SAS也將內部AI應用拆成3個層次。第一是提高個人生產力，例如文件整理、知識搜尋和會議摘要；第二層是企業流程轉型，也就是用來優化工作效率；第三層是產品與服務本身的AI化，也就是將MCP、Agentic AI和智慧決策等能力，直接嵌入產品與服務架構中。尤其，SAS今年在自家年會上揭露多項結合MCP的AI服務，部分就是來自內部應用的成功經驗。

AI Coding改變工程師角色，從寫程式轉向驗證與迭代

除了AI代理，Jay Upchurch也分享SAS內部AI輔助開發的落地經驗。他指出，他帶領的IT團隊，早已開始用AI協助處理開發流程，從需求蒐集、使用情境整理、軟體開發待辦事項（Backlog）管理，再到程式生成和驗證等都包含在內。但他認為，真正的改變，不只是寫程式速度變快，而是工程師的工作模式。

過去，工程師往往得從基礎框架開始，一邊撰寫程式碼、一邊測試與除錯；現在則由AI，先根據需求生成大部分的程式碼，再由工程師下指令調整、驗證結果。Jay Upchurch表示，AI現在已能先完成80%至90%的程式碼，工程師則負責後續迭代和修正。

但他也強調，AI輔助開發這件事，並不代表工程師能力變得不重要。相反地，工程師現在更需具備強大的基礎知識、良好開發習慣、深厚的架構理解和下提示的能力，才能真正駕馭AI及其生成的結果。

「如果沒有強大的基礎知識，你的指令不會成功，最後的輸出也不會成功，」他說。

SAS也從下指令，走向規格驅動開發模式

問及是否採用近期熱門的規格驅動開發（Spec-driven Development）方法，Jay Upchurch表示，SAS已開始往這個方向走，先定義規格與需求，再由AI生成程式碼。

他的原因很直接：若缺乏清楚規格，不同指令可能導致AI產生不同版本程式碼，進一步增加維護和治理難度。這也反映了，像SAS這樣的跨國軟體開發大廠，其AI Coding模式也從早期的指令導向，走向更成熟的規格導向。

Jay Upchurch也提醒，企業若只是把AI硬塞進既有流程，本質上其實只是「很昂貴的自動化」。真正重要的，不是讓既有繁瑣流程變快，而是重新思考：哪些流程其實已不需要。

AI正在改變漏洞管理節奏

除了AI輔助開發本身，Jay Upchurch也特別提到AI對資安的衝擊。他指出，近期包括Anthropic等業者開始展示AI驅動的漏洞發掘能力，甚至能在存在數十年的老舊系統中找出潛藏漏洞。

這意味著，企業漏洞管理流程將被迫進一步AI化。因為，過去漏洞修補往往需要發現漏洞、等待patch、安排更新、測試和再次驗證，但現在，攻擊者可能在AI找到漏洞後幾分鐘內，就發動攻擊。Jay Upchurch坦言，「漏洞管理再也不一樣了。」也因此，SAS開始用AI進行漏洞掃描、安全檢測和弱點管理，要跟上AI發現漏洞的速度。