
012 企業導入 AI Agent 的四道關卡
落在哪些主題(2 個)
失敗成本
級 3 錢、流程與組織
傷的是時間與成本,不是人。
動線位置
第 7 站 組織與技術棧
不在病人動線上,但決定前面六站做不做得成
從一個醫療 AI POC 卡在生產環境的情境出發,兩位工程主管拆解企業要讓 AI agent 上線,架構上非解決不可的四道關卡。
重點摘要
POC 好用不代表能上線 健保應用的示範一旦要進生產環境,資安、法遵、臨床主管會接連追問稽核紀錄、資料流向、人工核准與 evals,這些在 POC 階段通常都還沒處理。
稽核軌跡要禁得起檢驗 SOC2、HITRUST、HIPAA 要的不是開發者慣用的 log,而是能完整重建 agent 每個動作、每次資料存取、每次授權的紀錄。做法是用只能新增、蓋時間戳的事件日誌(event sourcing)當唯一事實來源,寫入簡單、讀取靠重放。
醫療資料要跟事件紀錄分開放 PHI 形狀複雜、常超過 1MB,甚至更大,存取限制嚴格,也有客戶要求資料不能離開自己的 VPC。做法是事件只存對物件儲存的參照,資料本身用 schema 驅動的物件儲存不可變地另外存放,也讓 agent 用 token 在使用當下才領資料的 zero trust 成立,藉此堵住 lethal trifecta。
人與 LLM 該被當成同一種 agent 什麼時候該把決策升級給人無法預先排定,人跟 LLM 處理上下文的方式也不同。解法是讓平台裡任何 LLM 能做的動作人也能做,下游流程不用區分是誰執行的。
evals 可以是架構的副產品 LLM 非決定性、離線資料集不代表正式環境、資料還會隨時間漂移,讓評測天生難做。但靠前面事件重放、物件儲存與人機同權這三個原則,就能直接比較 agent 跟人類的差異,甚至在客戶環境裡對正式資料跑評測而不外洩資料。
與其事後補規範,不如先蓋地基 先做出 POC 準確率、再把稽核、安全、evals 當附加項外掛上去,最後只會做出脆弱、難以推廣的系統;反過來先把生產環境的要求當架構原則,再往上重建 POC 的準確率,才走得通。
值得記的話
often getting things into production is really where the challenge lies
大家以為 AI 是難的部分,其實把東西送上生產環境才是真正的挑戰
03:42
It has to contain a complete record of absolutely every action that the agent took.
這才是企業安全框架眼中真正的稽核軌跡
05:38
LLMs will have no problem if you give them massive, massive, massive text, but humans, that's not the case.
人跟 LLM 處理上下文的方式天差地遠
13:29
LLMs are not deterministic, so it can be quite tricky to pin down the precise change that led to some sort of change in output.
這是 evals 天生難做的原因之一
14:57
時間軸 10 段
名詞與人物 9 個
提到但沒有展開
- 演講中提到「不可信資料能否操縱模型」與「怎麼整合 Epic、Salesforce 等既有系統」兩個問題,講者表示因時間有限沒有在台上展開,留待會後交流。
- 事件溯源搭配 schema 驅動物件儲存的架構,講者提到醫療情境常需要同一份事件紀錄事後產生不同解讀視角,這部分只點出結論,沒有展開細節。
動線上同一站的其他場 · 組織與技術棧
009從人才到流程的 AI-Native 轉型非官方整理,內容著作權屬原講者與主辦方。筆記是摘要與索引,短引用都標時碼並連回原片,想聽細節請看原影片。
YouTube 播放清單 · 共 12 場、135 個時間軸段落、92 個名詞、53 條雙語金句。