未來領航員 / 打造品牌力 /AI 專案換負責人怎麼交接？帳號、工作流、日誌與責任邊界清單

AI 專案換負責人怎麼交接？帳號、工作流、日誌與責任邊界清單

作者：FlyPig AI 團隊發布：2026-09-21 更新：2026-09-21 閱讀：10 分鐘

企業團隊交接 AI 工作流、權限、文件與責任邊界的明亮封面圖

摘要

AI 專案最脆弱的時刻，常常不是工具出錯，而是「原本懂流程的人不在了」。一位主管轉任、一位外包窗口換人、一位實作同仁離職，可能讓 API key、service account、Agent 工作流、知識庫來源、審核規則與事故聯絡人全部變成口耳相傳。

真正穩健的交接，不是把帳號密碼丟給下一個人，而是讓新負責人能回答三件事：哪些 AI 流程仍在正式營運中？哪些權限與資料會造成風險？如果明天出事，誰能暫停、誰能查日誌、誰能對外說明？

核心結論

AI 專案換負責人時，交接清單至少要覆蓋五層：帳號與金鑰、工作流與資料來源、人工批准、日誌與成本、事故與退場。

交接層級	要確認什麼	沒交接的風險
帳號與金鑰	管理員、API key、service account、OAuth app、外掛	離職帳號仍有權限，或新 owner 無法停用流程
工作流與資料來源	Agent 任務、排程、觸發條件、知識庫、CRM、Drive、表單	有流程還在跑，但沒有人知道它讀哪些資料
人工批准	哪些輸出能自動送出，哪些要審核，誰能批准	AI 草稿被誤當正式承諾，或高風險動作無人把關
日誌與成本	使用量、錯誤、審核紀錄、預算告警、重試設定	成本暴增、錯誤重複發生，卻找不到責任線索
事故與退場	暫停按鈕、替代流程、供應商窗口、資料匯出	出事時只能等供應商或原負責人回覆

最務實的判斷句是：AI 專案不是交接「工具」，而是交接一套會持續影響營運的決策流程。

為什麼 AI 專案不能只靠原負責人口頭交接
第一步：列出仍在跑的 AI 流程
第二步：把人員帳號和系統帳號分開
第三步：交接資料來源與知識庫邊界
第四步：確認誰能批准、暫停與恢復
第五步：留下 30 天觀察與回查節奏
參考來源與資料時間
常見問題
延伸閱讀

為什麼 AI 專案不能只靠原負責人口頭交接

傳統系統交接，多半會交帳號、文件、主機、廠商窗口與 SOP。AI 專案多了一層麻煩：它不只是「系統能不能登入」，而是「AI 是否仍在替公司讀資料、產生內容、分類客戶、草擬回覆、觸發工具或更新欄位」。

這些流程常常一開始只是試點：

某個同仁用個人 API key 做了客服摘要。
某個外包把表單 leads 接到 AI 分類流程。
某個主管用共享硬碟建立知識庫。
某個內容窗口讓 AI 自動產出 SEO 草稿。
某個工程或 no-code 流程用 service account 連到 CRM。

試點成功後，大家開始依賴它，但文件、權限、日誌與預算未必跟上。等到原負責人轉任、離職、請假或供應商窗口換人，才發現沒有第二個人能完整說明：

這個 Agent 到底能做哪些動作？
它讀到哪些資料夾、表單、Email、CRM 或知識庫？
哪些輸出會對外送出？
錯誤時會不會自動重試？
預算告警寄給誰？
要暫停時按哪裡？

NIST AI 風險管理框架提醒，AI 風險需要被治理、量測、管理與盤點。把這句話翻成中小企業語言，就是：不要讓 AI 專案只存在某個人的腦袋裡。

第一步：列出仍在跑的 AI 流程

交接不要從工具清單開始，而要從「仍在影響營運的流程」開始。

很多公司會列出自己用了哪些 AI 工具，卻漏掉真正重要的問題：哪些工具已經接進正式流程？哪些只是在個人試用？哪些會讀資料、寫資料或對外產出？

可以先用這張表盤點。

流程	目前 owner	觸發方式	讀取資料	寫入位置	對外影響	風險等級
客服摘要	客服主管	工單建立後自動觸發	客服對話、訂單備註	工單摘要欄位	間接影響客戶回覆	中
表單 leads 分類	行銷營運	表單送出後觸發	表單、試算表、CRM	CRM 標籤	影響業務跟進順序	中
SEO 草稿產生	內容窗口	每週排程	既有文章、官方來源	草稿資料夾	需審稿後才公開	中
報價草稿	業務主管	人工啟動	產品型錄、客戶需求	報價草稿	可能影響金額與承諾	高
Agent 自動更新欄位	資訊窗口	背景排程	CRM、內部文件	CRM 或資料庫	直接改正式資料	高

這裡不需要一次做成大型系統。先把「有沒有對外影響」「有沒有寫入正式資料」「有沒有讀敏感資料」三件事標出來，新負責人才知道哪裡不能隨便動。

試點、正式、停用要分清楚

AI 流程交接最常見的混亂，是試點和正式流程混在一起。

狀態	判斷標準	交接要求
個人試用	只在個人帳號中測試，沒有接正式資料	可封存或刪除，避免繼續佔用權限
小範圍試點	讀取部分資料，有人工審核，影響有限	交接 owner、資料範圍、審核規則與停損條件
正式營運	已進入客服、業務、內容、報表或資料更新流程	必須有文件、日誌、備援 owner、暫停流程與成本告警
待退場	不再使用，但帳號、key、資料或排程仍存在	交接退場計畫，確認撤權、匯出與刪除

如果交接時發現某個流程「大家以為停了，但其實還在跑」，這不是小事。那代表公司已經有無主流程，應優先暫停或指定 owner。

第二步：把人員帳號和系統帳號分開

AI 專案交接最怕兩種情況：第一種是所有流程都綁在原負責人的個人帳號；第二種是所有人共用同一把 key，沒有人知道它被放在哪些地方。

OpenAI Developers 的 service accounts API Reference 將 project service account 與 API key 視為可管理的專案資源。Google Cloud IAM 也長期提醒 service account key 需要妥善管理與輪替。這些不是大企業才需要的事。只要 AI 流程已經進入營運，中小企業也需要把「人的權限」和「系統跑流程的權限」分開。

交接時至少確認四件事

類型	要問的問題	建議動作
人員帳號	原 owner 還是不是唯一管理員？	加入新 owner，移除不再需要的成員
API key	key 是誰建立的？放在哪些平台？權限多大？	標記用途，必要時輪替，禁止放在個人文件
service account	是否只用於單一專案？是否有過大權限？	限縮 scope，記錄責任 owner 與用途
OAuth / 外掛	哪些外掛仍能讀 Drive、Email、CRM 或試算表？	撤掉不用的授權，保留必要授權證據

交接不是要求每家公司都立刻導入完整 IAM 制度，而是先做到一個底線：新負責人要能知道「哪些權限存在、誰能改、怎麼停」。

不要用截圖交接 secret

API key、OAuth token、service account key、Webhook token、資料庫密碼都不應該用聊天截圖、文件截圖、Email 明文或簡報交接。

比較穩健的方式是：

由新 owner 在正式平台建立或接收自己的權限。
舊 key 若曾由離職或外包人員持有，優先輪替。
key 放在部署平台 secret manager、作業系統金鑰圈或公司核准的密碼管理工具。
文件只記錄「用途、owner、存放位置、輪替日期、權限範圍」，不記錄明文 secret。

這一步看似麻煩，但它會在下一次事故、成本異常或供應商換約時救你一命。

第三步：交接資料來源與知識庫邊界

AI 專案換人時，最容易被忽略的是資料來源。

模型、工具、流程都可以重建，但如果新 owner 不知道知識庫引用哪一版文件、哪些資料夾不該被索引、哪些客服紀錄已去識別，後續就很容易出現錯答、過期承諾或敏感資料外流。

資料來源交接表

資料來源	用途	更新 owner	可否被 AI 讀取	可否對外引用	注意事項
官方產品型錄	客服與業務問答	產品窗口	可讀	可引用，但需看版本日期	價格與規格需正式確認
內部 SOP	內部助理回答	營運主管	可讀	不可對外逐字引用	含內部流程與權限資訊
客服紀錄摘要	改善 FAQ	客服主管	去識別後可讀	只能改寫成正式答案	不可保留個資與情緒片段
CRM leads	業務分類	業務主管	限欄位可讀	不可對外引用	不做自動評分歧視
共享硬碟歷史文件	企業搜尋	資訊窗口	分級後可讀	需經內容 owner 審核	過期文件先排除

這張表的目的不是增加文書工作，而是讓新 owner 不會把「AI 可以讀到」誤認成「AI 可以直接使用」。

知識庫要交接版本，不只交接資料夾

如果公司使用 RAG、企業搜尋、Dify、內部助理或 Agent 工作流，交接時應記錄：

哪些資料夾或文件已被索引。
最近一次更新時間。
哪些資料已排除。
哪些答案必須回到正式來源確認。
哪些主題 AI 應拒答或轉人工。
知識庫重建或回滾的方式。

尤其是價格、合約、退款、醫療、金融、法規、教育安全、個資、供應商條款等高風險內容，不要讓 AI 依舊版知識庫直接回答。

第四步：確認誰能批准、暫停與恢復

AI 專案交接時，最重要的不是誰會操作工具，而是誰能做三種決策：批准、暫停、恢復。

OWASP 對 LLM excessive agency 的提醒，核心問題之一就是系統被賦予過多功能、過多權限或過多自主性。換成營運語言，就是 AI 不能因為原 owner 離開，就變成沒有人能管的自動執行者。

三種決策權要寫清楚

決策	什麼時候需要	誰應該參與
批准	AI 草稿要對外寄出、發布、更新正式欄位或觸發高風險動作	流程 owner、業務或客服主管、必要時管理者
暫停	錯答、延遲、成本暴增、資料異常、權限疑慮、供應商事故	事件 owner、資訊窗口、營運主管
恢復	異常排除後重新開啟自動化	原流程 owner、新 owner、測試或審核窗口

「能登入平台」不代表「能決定恢復」。恢復自動化前，至少要完成小批次測試，確認輸出格式、資料來源、成本與審核規則仍正常。

每個高風險流程都要有暫停方法

交接文件中可以保留一段簡單但關鍵的內容：

流程	暫停方式	人工替代	恢復條件
客服 AI 初回覆	關閉自動回覆，改人工審核	使用客服模板與人工分派	連續測試通過，錯答率回到可接受範圍
表單 leads 分類	暫停自動標籤	人工用試算表標記	欄位同步正確，無個資誤用
SEO 草稿排程	停用排程	手動建立草稿	來源、日期、圖片、schema 驗證通過
報價草稿	取消自動生成正式報價	業務主管人工產生	價格與條款來源確認
Agent 寫入 CRM	關閉寫入權限	人工更新欄位	回歸測試與日誌查核通過

這不是悲觀，而是讓公司知道 AI 失控時還有方向盤。

第五步：留下 30 天觀察與回查節奏

AI 專案換 owner 後，不要以為交接會議結束就安全。真正的風險通常會在接下來幾週浮出來：某個排程突然失敗、某把 key 到期、某個告警仍寄給舊人、某個知識庫沒人更新、某個外包帳號還在。

建議交接後保留 30 天觀察期。

時間	檢查重點	產出
第 1 天	owner、帳號、key、暫停方法、核心流程	交接確認表
第 7 天	是否有失敗排程、錯誤率、成本異常、無主告警	第一週回查紀錄
第 14 天	知識庫更新、人工批准、輸出品質、客服或業務回饋	修正清單
第 30 天	權限是否收斂、舊 owner 是否撤權、是否需要退場或重設流程	正式接手紀錄

交接完成的最低標準

不要用「文件已交」當作完成。比較好的完成標準是：

新 owner 能獨立說明所有正式 AI 流程。
新 owner 能找到每個流程的資料來源、日誌與預算告警。
不再需要舊 owner 的個人帳號才能維運。
不必要的外包、試點、個人 key 與 OAuth 權限已移除或排程輪替。
高風險流程有暫停、人工替代與恢復條件。
交接後 30 天內至少做過一次回查。

如果做不到，代表不是「交接還沒漂亮」，而是 AI 專案仍有營運風險。

參考來源與資料時間

資料時間：2026-09-21。以下來源用來建立 AI 專案 owner 交接、權限、service account、Agent 權限與風險治理的保守框架；實際設定仍應以各平台後台、正式合約與企業內部政策為準。

本文不是法律、資安、採購或合規意見。若交接牽涉個資、合約、付款、金融、醫療、教育安全、上市櫃揭露、重大客戶承諾或跨境資料，請由企業正式權責人與專業顧問確認。

常見問題

AI 專案只是一個小工具，也需要交接嗎？

如果只是個人試用，可以簡化。但只要它讀取公司資料、寫入正式系統、影響客服或業務回覆、產生對外內容、使用 API 成本或有排程自動執行，就應該有最小交接紀錄。

原負責人離職後，要不要立刻換掉所有 API key？

不一定所有 key 都要立刻換，但至少要盤點 key 的建立者、用途、存放位置、權限範圍與使用中的流程。若 key 曾被個人持有、外包持有、放在不安全位置或權限過大，應優先輪替。

交接文件可以放在共享雲端硬碟嗎？

可以放交接文件，但不要把 secret 明文放進文件。文件應記錄用途、owner、權限範圍、存放位置與輪替日期；真正的 key、token、密碼應放在公司核准的 secret 管理工具、部署平台 secret 或安全的密碼管理機制中。

新 owner 不懂技術怎麼辦？

新 owner 不一定要會寫程式，但必須能知道流程 owner、資料來源、人工審核、暫停方式、成本告警與事故聯絡人。技術細節可以由資訊窗口補位，但營運責任不能完全丟給工具或外包。

外包或顧問做的 AI 流程也要交接嗎？

更要交接。外包交付不應只交結果，還要交工具帳號、權限範圍、資料來源、排程、日誌、維護方式、暫停方法與退出方案。否則公司會買到一個能運作但不能治理的黑盒流程。