共用資料層不等於共用一個資料庫
傳統報表追求穩定、可重現與固定口徑；AI 問答則需要理解自然語言、處理模糊條件，並在不同問題之間動態組合資料。兩者可以使用相同的底層事實，卻不應直接共用沒有治理的資料表。若只是把 BI 工具和大型語言模型接到同一個資料庫，欄位歧義、重複資料與權限落差仍然存在，只是以更快的速度暴露給使用者。
值得共用的是一套受管理的資料契約：哪些實體是客戶、訂單、產品與據點；每個指標如何計算；時間、幣別與狀態如何解讀；哪些角色可以查看哪些範圍。報表依此產生固定視圖，AI 則透過同一套語意定義建立查詢計畫。實體儲存可以是資料倉儲、湖倉或多個服務，但對使用者而言，定義必須一致。
先定義資料粒度，再定義指標
共用資料層最常見的問題不是模型能力，而是資料粒度不清。例如訂單表是一筆訂單、訂單明細還是一筆出貨？客戶數是帳號、統一編號、門市還是聯絡人？如果沒有先固定資料粒度與主鍵，同一個問題在報表和 AI 中可能得到不同答案，而且兩邊看起來都合理。
工程團隊應把核心資料集當成可版本化的產品，至少明確記錄以下內容：
- 資料粒度：每一列代表什麼事件或實體，以及允許的重複條件。
- 關聯規則：主鍵、外鍵、主資料對照與跨系統身分合併方式。
- 時間語意：建立時間、入帳時間、出貨時間與更新時間各自適用的分析情境。
- 指標契約：公式、篩選條件、稅額與幣別處理、取消或退貨狀態，以及資料負責人。
指標最好集中在語意層或受控的模型視圖，而不是分散在報表 SQL、試算表公式與提示詞中。當定義需要修改時，應建立新版本並說明影響範圍，避免歷史報表在沒有通知的情況下改變。
資料管線與查詢介面要分層
實務上可將來源資料、標準化資料與可供分析的資料模型分開。ERP、CRM、LINE、IoT 或外部服務的原始資料先保留來源欄位與載入時間，再進行型別校正、去重、主資料對照及商業規則處理，最後才建立提供報表與 AI 使用的資料集。這種分層讓工程師可以追查答案從哪個來源、經過哪些轉換，而不必直接在最終表格中猜測。
報表通常適合讀取預先彙總、效能穩定的資料模型；AI 問答則可能需要依問題下鑽，但仍應透過受控的查詢服務或核准視圖。兩者不必執行完全相同的 SQL，只要使用相同的指標契約與資料版本。對高頻指標可以建立彙總表或快取，對低頻探索性問題則限制掃描範圍、逾時與成本。
- 為每個資料集標示更新頻率、最近成功時間與可接受的延遲。
- 保留來源批次或事件識別碼，讓報表數字與 AI 答案可以回溯。
- 將資料品質檢查放進管線，包括唯一性、完整性、關聯完整性與合理範圍。
- 對失敗或延遲的資料明確顯示狀態，不讓 AI 用流暢文字掩蓋資料缺口。
讓 AI 取得語意，不要取得無限制資料庫權限
大型語言模型不應持有可以任意查詢正式資料庫的高權限帳號。較安全的方式是讓模型先從資料目錄取得核准的資料集、欄位說明、關聯與指標定義，再由查詢服務驗證產生的結構化請求。服務端負責套用資料列與欄位權限、查詢成本限制及允許的運算，模型只負責理解問題與組織答案。
- 先辨識使用者身分、部門、租戶與可查詢的資料範圍。
- 將問題對應到核准指標、維度、時間區間與篩選條件。
- 在執行前驗證資料集、欄位、關聯、掃描量與敏感資料政策。
- 回傳結果時附上指標定義、資料時間與使用的篩選條件。
- 若資料不足、口徑不明或查詢失敗，明確要求澄清或拒絕推測。
權限必須在資料與查詢層強制執行，不能只寫在提示詞中。對含有個資、薪資或商業機密的欄位，還需要遮罩、用途限制與稽核紀錄。使用者輸入與檢索到的文件都應視為不受信任內容，避免文字指令繞過既有權限。
用可對帳的方式逐步上線
不建議一開始就讓 AI 回答所有企業問題。先選擇定義成熟、已有可信報表且業務價值明確的主題，例如訂單狀態、庫存可用量或服務案件趨勢。工程團隊可以用既有報表作為對帳基準，建立一組包含同義詞、模糊日期、跨維度比較與無權限情境的驗收問題。
上線後需要同時觀察資料管線、查詢計畫與回答呈現。記錄使用者問題、解析後的指標與條件、執行的資料版本、查詢結果及最終答案，才能判斷錯誤來自語意理解、資料品質還是文字生成。修正也應回到語意層、資料契約或查詢規則，而不是持續在提示詞中加入例外。
成熟的共用資料層是一項持續維護的內部產品。它有明確負責人、版本、品質門檻與變更流程，也允許報表和 AI 採用不同的呈現方式。當兩者都能引用相同定義、資料時間與權限結果，AI 問答才會從方便的展示功能，變成可被日常決策信任的介面。