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

來源：https://www.ithome.com.tw/news/176029

不少企業還在思考是否全面導入生成式AI助手時，老牌數據分析大廠SAS已開始面對下一個問題：當員工都能自行建立AI代理（AI Agent）後，企業該如何治理、擴散，甚至將這些AI能力進一步產品化？

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發現漏洞的速度。

'

新加坡政府公布AI代理沙盒測試結果，評估公共服務應用效益與治理風險

來源：https://www.ithome.com.tw/news/176027

為了解AI代理能否實際用於公共服務，以及導入前需要處理哪些風險，新加坡網路安全局（Cyber Security Agency of Singapore，CSA）、新加坡政府科技局（Government Technology Agency of Singapore，GovTech Singapore）與新加坡資訊通信媒體發展局（Infocomm Media Development Authority，IMDA）於5月20日共同發布AI Agents Sandbox白皮書，揭露與Google合作的沙盒測試成果。

這項AI代理沙盒計畫自2025年8月啟動，測試期約4個月。Google在沙盒環境中開放GovTech Singapore測試團隊試用可操作電腦與瀏覽器的AI代理，觀察這類代理能否在公共服務情境中依照指示瀏覽網站、操作介面並完成多步驟任務。

在這次沙盒測試中，新加坡政府與Google根據風險與效益程度，將AI代理應用分成4類：低風險高效益（Advance）、低風險低效益（Adopt）、高風險高效益（Adapt），以及高風險低效益（Avoid）。依此框架，沙盒最後選定3個公共部門場景：政府數位服務品質檢測，屬於可優先推進的Advance類型；聊天機器人上線前AI安全測試，屬於可中期導入的Adopt類型；協助民眾或社工申辦社福服務流程，屬於需要搭配防護措施再測試的Adapt類型，藉此觀察AI代理在不同應用情境中的表現。

在政府數位服務品質檢測方面，結果顯示，AI代理能夠協助檢查政府網站回應時間、搜尋功能與頁面完整性，也能辨識測試環境中刻意放入的失效頁面、填充文字（filler text），以及測試環境網址與正式網站網域不一致等問題。

在聊天機器人安全測試場景中，AI代理可依照指示，在不同聊天機器人介面傳送測試用提示詞，減少人工重複執行測試的負擔。不過，白皮書也指出，當聊天機器人回應內容較長時，AI代理在記錄結果時仍可能出現不準確或幻覺問題。

至於社福服務申辦場景，白皮書將其歸類為高風險、高效益的Adapt類型。測試顯示，AI代理能協助使用者完成申請流程，包括找出缺漏或不一致資訊，並將社工訪談紀錄等非結構化內容整理成表單欄位所需資料。白皮書指出，這類能力未來可延伸至其他複雜表單處理、多來源資訊彙整或行政申請流程，但由於涉及個資與敏感資料，部署時仍須納入人工審查與權限控管機制。

白皮書也提醒，AI代理能夠讀取網頁與外部內容，因此必須留意間接提示注入等AI模型安全風險。這類攻擊手法可能透過變造的網頁內容或惡意指令，誘使代理前往未核准網站、揭露敏感資料或執行非預期動作。

因此，新加坡政府與Google建議，組織導入AI代理應用時，應採取分層防禦與風險分級監督。高風險任務應設置事前審查機制；低風險且可回復的任務，則可透過日誌與事後稽核控管，避免每個步驟都要求人工確認，反而削弱AI代理原本可帶來的自動化效益。

'

Claude託管代理現可連企業內網並在自有環境執行工具

來源：https://www.ithome.com.tw/news/176026

Anthropic更新Claude平臺，替Claude Managed Agents加入兩項企業導入代理應用所需的基礎能力，包括可連接私有網路MCP伺服器的MCP通道（MCP Tunnels）研究預覽版，以及可在客戶自有環境執行工具與程式碼的自架沙箱（Self-hosted Sandboxes）。該日更新未涉及新模型，重點放在代理的內部系統連線、工具執行位置與資料流向控管。

MCP（Model Context Protocol）主要用途是讓AI系統透過標準方式連接外部工具與資料來源。Anthropic藉由開放MCP通道，讓Claude可連到企業私有網路中的MCP伺服器，該機制採用僅對外連線方式，企業不必開放外部連入內網的防火牆連接埠，也不需要把內部服務放到公開網際網路。MCP通道目前屬於研究預覽版。

另一項更新是自架沙箱。沙箱是讓代理執行工具與程式碼的隔離環境，可降低代理任務影響其他系統的風險。Claude Managed Agents預設在Anthropic管理的雲端容器中執行工具與程式碼，而自架沙箱則保留Anthropic端的代理任務調度，但把工具與程式碼執行移到客戶控制的基礎設施中。

Anthropic說明，如此可讓代理使用的程式碼、檔案系統與網路出口留在客戶環境內，適合資料不能離開組織邊界、需要連接非公開內部服務，或必須符合合規與稽核要求的企業。這也讓企業在導入Claude託管代理時，可依自身安全政策決定代理實際執行工作的環境。

MCP通道與自架沙箱是兩項獨立功能。前者處理Claude如何連到企業私有網路中的工具，後者處理代理工具與程式碼要在哪裡執行。企業可以單獨使用其中一項，也可以同時搭配，讓AI代理連線與執行環境都更貼近既有內部控管方式。Anthropic也註明，自架沙箱目前尚未支援AWS上的Claude平臺。

另外，Claude Managed Agents現在可在進行中的工作階段，更新代理關聯的MCP伺服器與工具設定。當代理工具集與MCP工具輸出超過10萬個詞元（Token）時，系統會自動把完整內容寫入沙箱檔案，只提供模型一段截短預覽與檔案路徑，再由模型視需要讀取完整內容。該功能主要用於較長時間、多工具互動的代理任務。

'