← 返回觀點
/智慧方案FDE團隊

奇美醫院還沒讓 AI Agent 上線:先補哪三道邊界?

奇美醫院已把 AI 用進臨床與行政,卻因安全執行環境未完備,暫緩 AI Agent 上線。企業可照連線、權限與稽核三道邊界,完成上線審查。

AIEgentWrX人機協作導入
奇美醫院還沒讓 AI Agent 上線:先補哪三道邊界?

業務想用 AI Agent 查歷史報價,採購想用它整理供應商資料,客服則希望它讀取客戶紀錄。做概念驗證時,團隊在意的是回答好不好;準備正式上線後,主管要處理的問題就不一樣了:AI Agent 可以連上哪些系統、能看到哪些人的資料、可不可以修改內容,出了問題又該從哪裡查起?

如果等到功能做完才補上治理規範,IT 與資安只能在既有設計上追加限制,業務也容易把測試階段的方便當成正式需求。因此,我們建議在上線前先訂清楚連線、權限與稽核規範,而且第一波開放的範圍寧可小一點:內部資料先開放讀取、不開放寫入,外部網域經逐一審查後再開放,每次操作也都要留下可供查驗的紀錄。

先限制 AI Agent 可以存取哪些資料,再決定可以執行哪些操作

奇美醫院的做法提供了很好的參考。院方從 2005 年開始累積資料分析能力,後來陸續投入疾病風險預測、生成式 AI(generative AI)文書協作,再逐步走向 AI Agent。不過,AI Agent 目前還沒有正式上線,因為資料治理與安全執行環境仍需要補強。院方用「龍蝦池」比喻安全沙盒(Sandbox),也就是讓程式在受到限制的環境中執行,避免直接影響正式系統,或接觸原本不該存取的資料。

企業可以先列出兩張清單。第一張列出資料來源,包括訂單資料庫、報價檔案、供應商資料與客服紀錄;第二張則列出 AI Agent 可能執行的操作,包括查詢、下載、寄送、建立草稿與寫入系統。允許 AI Agent 讀取資料,不等於可以整批匯出;允許它建立報價草稿,也不等於可以直接寄給客戶。把資料來源和操作權限分開列出來,主管才能清楚看出風險究竟在哪裡。

第一波上線可以先把讀取與寫入分開。AI Agent 先負責查詢內部資料、整理差異及產生草稿,再交由同仁確認;至於修改主檔、核定價格、送出採購單或更新客戶狀態,暫時仍由原有系統與簽核流程處理。對外連線也不要一次全部開放,而是逐一列出必要的網域、用途與負責人,沒有列入清單的連線一律拒絕。

進行上線審查時,可以先要求專案團隊提出資料來源、允許操作與外部網域三份清單,再用實際帳號測試系統是否真的能擋下越權存取與禁止寫入的操作。如果連這三份清單都還寫不清楚,就先不要擴大功能範圍。

權限不能只寫在提示詞裡,還要按照職務與組織分工設定

如果「只能看自己部門的資料」這項規定只寫在提示詞裡,它仍然只是給模型看的文字指示,無法取代身分驗證與系統權限。企業要先回答三類問題:哪些人可以使用哪個 AI Agent、每個 AI Agent 可以讀取哪些單位的資料,以及哪些人可以調整連線與後台設定。如果這三類權限都集中在同一個管理者帳號,出了問題之後,就很難分辨究竟是業務需求、操作失誤,還是有人不當變更了設定。

以報價流程為例,業務可以查詢自己負責客戶的歷史訂單並建立草稿,業務主管可以查看單位內的案件,IT 負責設定連線,資安則負責檢查異常紀錄。採購比價也可以採用相同原則:承辦人只能看到指定供應商與品項,不能因為不同單位共用同一個 AI Agent,就連其他單位的合約條件也一併開放。這些規則都要實際設定在帳號、角色與資料範圍中,不能期待使用者每次對話時都主動提醒 AI Agent。

建議 IT、資安與業務負責人共同製作角色矩陣(role matrix),逐項寫清楚各角色可以使用哪些功能、查看哪些資料、調整哪些設定,以及需要由誰核准。測試時,團隊除了確認正常流程可以順利完成,也要模擬使用者所屬單位不符合授權條件、帳號已停用,或嘗試存取未授權資料等情況,進行反向測試;確認系統確實會拒絕這些操作後,再按照實際工作需要逐步放寬權限。

留下紀錄還不夠,還要查得出誰做了什麼

AI Agent 出錯時,只留下最後產出的文件並不足以追查問題。企業還要查得到是哪位使用者發起任務、AI Agent 讀取過哪些資料、呼叫過哪些工具、何時遭到系統拒絕,以及哪些人修改過權限。如果稽核紀錄可以任意刪改,或有人下載紀錄卻沒有留下痕跡,資安與內稽仍然無法還原事情經過。

奇美醫院正在研究一種分工方式:先由 AI Agent 理解並規畫任務,再由機器人流程自動化(Robotic Process Automation,RPA)執行固定操作。企業也可以用這種方式劃分責任,讓 AI Agent 負責整理資訊並提出下一步建議,RPA 則只執行事先定義好、結果可以預期的操作。遇到付款、核定價格、修改客戶主檔或對外寄送等工作時,流程就先停下來,等待負責人確認。企業不需要一開始就讓 AI Agent 在理解任務後直接修改正式系統。

EgentWrX 可以透過同一套管理機制落實上述限制:AI Agent 可透過公司內網讀取資料庫,內部資料庫的連線可設定為只能讀取、不能修改,對外網域則逐一審查放行;前台與後台權限分開管理,管理者可以按照單位與自訂角色限制功能及資料範圍;稽核日誌(audit log)可以查詢、匯出,並使用雜湊鏈(hash chain)驗證紀錄是否遭到修改,就連管理者下載稽核紀錄,也會留下紀錄。這些機制讓企業可以實際限制操作並查核紀錄,但企業仍要自行決定哪些流程可以開放,以及由誰負責核准。

正式上線前,應先訂出資安或內稽每週、每月要抽查哪些紀錄,至少要涵蓋 AI Agent 的執行情況、權限異動與稽核資料下載,同時也要寫清楚停用條件、通報對象與追查步驟。等到團隊可以從紀錄中回答「誰在什麼時間、使用哪項權限、做了什麼」,再評估是否開放下一個資料來源或寫入操作。

常見問題

資料庫一定要先設成唯讀嗎?
建議第一波上線先採用唯讀設定,讓 AI Agent 查詢、比對及整理資料;修改主檔、核定價格或送出單據等操作,仍由原有系統處理。等團隊完成測試與風險審查後,再逐項評估是否開放寫入權限,不要一次把整個資料庫的權限全部交出去。
用提示詞限制 AI Agent,可以取代系統權限嗎?
不可以。提示詞只能告訴 AI Agent 工作規則,不能取代帳號、角色與資料範圍等系統權限。企業應分開管理可見資料、可用功能與後台設定權,並使用未授權帳號實際測試系統是否會拒絕存取,以免提示詞寫了一套,實際權限卻是另一套。
哪些操作應該保留人工確認?
遇到付款、核定價格、修改正式資料、對外寄送或跨部門揭露資料等操作時,建議先讓流程停下來,交由負責人確認。企業可以按照金額、資料敏感程度與影響範圍設定需要人工核可的環節,並清楚指定哪些人可以放行、哪些人負責處理例外情況。
稽核日誌至少要記錄哪些內容?
稽核日誌至少要記錄任務發起人、執行時間、使用過的資料與工具、權限異動、失敗或遭到拒絕的操作,以及稽核資料的下載行為。資安或內稽還要定期抽查,確認紀錄無法任意修改,並確保發現越權行為時,可以立即停用相關權限並展開追查。
30 分鐘,一起盤點哪些工作適合先交給 AI

想讓每位同仁都有自己的 AI 分身?

顧問會盡快與您聯繫。

ISO/IEC 27001:2022 資訊安全管理驗證