30 天導入 AI 分析的合理目標，不是讓全員都開始問 AI，而是用一個真實、風險可控且會被追問的分析，驗證資料範圍、Plan 審閱、SQL evidence、Report 與權限流程。月底應得到可否擴大的證據與失敗清單，而不是一場看起來順利的 demo。
第 1–3 天：選對場景與 owner
好試點同時具備四項：
- 資料已存在，且範圍能鎖定；
- 問題曾有口徑爭議或需要重跑；
- 答案有實際用途，但錯誤不會立刻造成不可逆損失；
- 有一位業務 owner 與一位分析 reviewer 願意參與。
適合例子是季度 onboarding 復盤、退款原因分布或既有活動成效回顧。不適合的第一案是薪資、授信、法遵判定、醫療決策，或跨數十系統但沒人說得清口徑的專案。
產物是一頁試點章程：決策問題、資料來源、禁止範圍、owner、成功標準與退出條件。
第 4–7 天：建立最小品質底線
先定義團隊對「正式分析」的最低契約：
- Execute 前 Plan 必須有人審；
- Plan 至少寫分母、grain、時間窗、join key 與 checkpoint；
- 關鍵數字能回到 SQL evidence；
- Report 必須含具體數字與 limitations；
- Quick 結果需標示為探索，不直接對外。
再準備兩組測試：一組資料品質檢查（NULL、duplicate key、日期新鮮度），一組指標驗收（與既有可信結果比對、抽查個案）。NIST AI RMF 將風險管理定位為設計、開發、使用與評估的持續工作；試點的品質底線應能實際被觀察與記錄，而不是只是一句「需人工監督」。NIST AI RMF
第 8–14 天：跑第一個真實案例
讓使用者從自然語言需求開始，但不要直接要最後答案：
目標：找出 onboarding 最大流失點，供下季改善排序。
對象：7 月首次啟用試用的 account。
要求：先探索 schema 並起草 Plan；在我核准前不要跑正式分析。
審 Plan 時，刻意邀請非 SQL 的業務 owner 留至少一條口徑批註。執行後核對：SQL 是否對應 Plan、checkpoint 是否真的跑過、Report 是否把觀察與推論分開、限制是否具體。
這週不要只記成功畫面。記錄每次人工介入、口徑修正、查詢錯誤、工具失敗與重跑原因。
第 15–18 天：專門審失敗，而不是急著擴大
把問題分成四類：
| 失敗類型 | 例子 | 優先修正 |
|---|---|---|
| Context | 不知道退款定義 | 補 Reference／專案知識，不只是改 prompt |
| Data | key 重複、日期缺漏 | 資料品質 checkpoint、縮小結論 |
| Workflow | 未審 Plan 就引用結果 | 權限、狀態與交付規則 |
| Interpretation | 把相關寫成因果 | Report 模板與人工 reviewer |
若錯誤來自缺乏業務定義，就把定義連同來源與適用範圍沉澱；若定義仍有爭議，不要直接存成 Agent 的長期真理。修復的是資訊與工作環境，不是無限加長一條 prompt。
第 19–23 天：定義權限、觀測與復原
先回答「誰能做什麼」：
- 誰能看哪些 workspace／資料來源；
- 誰能建立 artifacts 或執行正式查詢；
- 誰能核准 Plan、管理連線或匯出結果；
- 活動紀錄保留什麼、多久、誰查看；
- credential 如何 expiry、rotate、revoke；
- Agent 中斷或 writer conflict 如何處理。
若使用外部 Agent，第一次先走最小 scope 與低權限；不要因 demo 順利就長期留下 Admin。MCP 官方安全指南建議最小預設權限、明確授予額外能力，並限制本機 server 的檔案、網路與系統資源。MCP Security Best Practices
第 24–27 天：用第二個案例測可重複性
第二案不要複製第一案資料，但應使用相同品質規則。選另一位使用者、相鄰問題，觀察：
- 他能否理解何時用 Quick、何時用 Project；
- Plan 模板是否真的降低漏項；
- 沒有原作者在場時，SQL 與 evidence 能否被接手；
- 同一問題重跑時，口徑與限制是否一致。
如果流程只在原試點 champion 陪同時成立，代表還不能擴大。
第 28–30 天：用四組指標做決策
不要只量「省了幾分鐘」。建議保留：
- 品質：Execute 前口徑修正數、checkpoint 發現數、Report 退回原因。
- 可重現性：重跑時間、接手者找到 evidence 的時間、缺失 artifact 數。
- 交付可用性：Report 中可直接採用比例、limitations 完整度、owner 是否願意簽收。
- 治理：權限例外、失敗撤銷、writer conflict、敏感內容進 log 的事件。
月底決策可以是擴大、保留小範圍、補強後再試，或停止。停止也可能是成功的試點結果：它證明目前資料與責任機制尚未適合放大。
Lantide Data 如何支援這條路線
Lantide Data 是 local-first 的桌面 SQL 分析 IDE 與 Agent runtime。Quick／Project 雙軌避免小問題過度流程化；正式分析以 Plan、批註、使用者 Approve & Execute、SQL evidence 與 Report 推進；Agent Memory 的知識先進 Queued Knowledge 再由人核准；外部 Agent 則可透過本機 MCP Server 受 workspace scope 與 Observe／Execute／Admin 限制。可搭配 產品試點與推廣路線。
它適合本機表格資料、adhoc SQL 分析與需要審閱交付的小型團隊。它不是 ETL scheduler、多人 BI server、企業 IAM 或自動決策系統；資料是否送往外部模型與 connector 的條件，也仍須依實際設定與供應商逐一檢查。
30 天完成定義
月底應至少留下：兩份真實 Executed Report、對應 Plan 與 SQL evidence、一份失敗分類、最小權限表、撤銷演練紀錄、擴大／暫停決策。缺少這些，就算 demo 很流暢，也只能證明工具會動，尚未證明工作流能被治理。
結語
30 天的重點是把一次 AI 成功回答，轉成團隊可重複、可審閱、可停止的流程。從一個有價值但可控的問題開始；先找到失敗，再決定是否擴大，通常比追求第一週的「全自動」更接近真正採用。