No-Code/Low-Code 平台對資料治理有什麼影響？
某企業導入 No-Code/Low-Code 平台，讓各部門能自行建立資料分析與流程應用。隨著使用範圍擴大，管理層開始關注資料權限、存取紀錄與合規要求。依資料治理觀點，下列何者最合理描述此類平台對企業治理機制的典型影響？
某企業導入 No-Code/Low-Code 平台，讓各部門能自行建立資料分析與流程應用。隨著使用範圍擴大，管理層開始關注資料權限、存取紀錄和合規要求。
問你：從資料治理的觀點，這類平台對企業治理機制最典型的影響是什麼？
一句話總結
No-Code/Low-Code 平台通常內建角色權限與存取控管機制，這些功能有助於讓原本只存在於文件上的治理制度真正落地執行，而非取代或削弱治理需求。
先感受問題：人人都能建分析應用，IT 主管怎麼睡得著？
假設你在「全聯健康」醫療連鎖集團的資訊部任職。過去只有 IT 部門才能建系統，現在公司買了 Power Platform，行銷部、財務部、HR 部門都開始自己拖拉元件建立資料分析應用。
IT 主管開始緊張：
- 行銷部門建的應用，有沒有把客戶的個資連到不該看的地方？
- 財務部門的應用，哪些人可以看薪資資料？有沒有存取紀錄？
- 萬一有人把機密資料匯出去，有辦法追查是誰做的嗎？
- 這些應用符合《個資法》和內部合規要求嗎？
這就是「影子 IT（Shadow IT）」的治理挑戰：好處是各部門效率提升，風險是資料流向變複雜、控管難度增加。No-Code/Low-Code 平台對這個問題的典型影響是什麼？
沒有平台內建控管，治理會怎麼跑掉？
在使用 No-Code/Low-Code 平台之前，「全聯健康」的資料治理靠什麼維持？
- 靠人工申請流程：要用哪個資料庫，提單申請，IT 審核，手動開權限。流程慢，但有紀錄
- 靠程式碼審查：開發的應用必須 IT 審查後才上線，確保沒有不當的資料存取
- 靠 IT 集中管理：所有資料應用都由 IT 部門維護，IT 知道所有存取路徑
- 靠員工自律：告知不能存取哪些資料，靠員工自己遵守，實際效果有限
- 靠事後稽核：定期審查存取紀錄，但發現問題時通常已經過了很久
這套方法的問題：流程慢、依賴 IT 成為瓶頸、實際執行力參差不齊。No-Code 平台擴大了存取資料的人數，如果平台沒有內建控管，治理壓力會成倍增加。
平台內建控管讓治理制度真正落地
「全聯健康」採用的 Power Platform 有幾個關鍵的治理功能：
角色權限管理（RBAC）：管理員可以設定「行銷部門只能看到客戶互動資料、不能看薪資資料」。這個設定一次完成，每個行銷人員建的應用都自動受這個規則約束，不需要每次手動審查。
資料存取稽核紀錄：平台自動記錄誰在何時存取了哪些資料、執行了什麼操作，這個紀錄是合規稽核的直接依據。
資料遺失防護（DLP）政策：管理員可設定哪些資料連接器可以使用、敏感資料不能匯出到外部服務，形成系統層級的防護。
結果：IT 主管不再需要每個應用都手動審查，平台的機制本身就確保了治理政策的執行。部門自主性提升了，合規要求也透過平台機制得到保障。
這就是選項 A 講的：平台內建角色權限與資料存取控管機制，有助治理制度落實，這才是 No-Code/Low-Code 對資料治理的典型正面影響。
技術版：No-Code/Low-Code 平台的治理能力
No-Code/Low-Code 平台的治理功能是近年快速成熟的領域，主要企業平台（Microsoft Power Platform、ServiceNow、Salesforce Flow）都提供完整的治理工具組。
主要治理功能模組：
- 身份存取管理（IAM）整合：與企業的 Active Directory 或 SSO 整合，確保人員異動時權限自動更新
- 資料遺失防護（DLP）：設定哪些資料連接器可以互通，防止敏感資料流出受控環境
- 稽核紀錄（Audit Logs）：自動記錄所有操作，滿足合規要求（如 GDPR、《個資法》）
- 環境隔離：生產環境、測試環境、部門沙盒分離，降低誤操作風險
影子 IT 的治理挑戰：No-Code 讓更多人能建應用，若無妥善管理，反而會造成資料孤島（Data Silos）、未受控的外部連接、合規漏洞。平台的治理功能是解方，但需要管理員主動設定和維護，不是「自動就很安全」。
為什麼出題者要考這題：AI 應用規劃師評估 No-Code/Low-Code 工具時，治理能力是關鍵考量之一。這題在測試考生是否理解平台帶來的是「治理能力的工具化」，而不是「取代治理需求」或「破壞治理」。
為什麼其他選項是錯的
B平台強化部門自主性，通常使既有治理流程難以延續
因為各部門都能自己建應用，原本集中由 IT 管的治理流程就被架空了。
這個說法把「部門自主性」和「治理難以延續」畫上等號，但兩者不是必然關係。現代 No-Code/Low-Code 平台的設計恰恰相反：透過內建控管，讓部門自主的同時，治理政策仍然有效執行。「難以延續」是早期野蠻生長的影子 IT 問題，不是平台的典型影響。
對 No-Code 有負面印象、覺得「部門自己建 = IT 失控」的人。這種擔憂有其根據，但不是平台治理功能完善後的典型結果。
C平台主要支援應用快速開發，資料治理仍需完全仰賴外部系統
No-Code/Low-Code 只負責建應用，資料治理的工作還是要靠其他獨立系統來做。
「完全仰賴外部系統」的說法過於絕對，而且不符合現實。主流 No-Code/Low-Code 平台都內建了程度不等的治理功能，不需要「完全」仰賴外部工具。當然可以整合外部 SIEM 或 DLP 系統，但那是加強而非「仰賴」。
對平台功能不熟悉、以為 No-Code 只是「拖拉元件建介面」的人。現代 No-Code 平台的治理功能相當完整，不是只有介面設計工具。
D平台透過自動化設定機制，可顯著降低治理與合規管理需求
因為平台有自動化機制，所以企業對治理和合規的需求就降低了。
這個選項犯了「工具讓問題消失」的邏輯錯誤。平台的自動化功能是讓治理「更容易執行」，但不能「降低」治理需求。合規要求是外在的（法規、業務要求），不會因為用了好工具就變少。越多人用平台，潛在的治理需求只會越大。
混淆「工具讓執行更容易」和「需求本身降低」的人。好的治理工具讓合規更容易達成，但不等於可以少做合規。
同個考點下次怎麼變形
什麼是「影子 IT（Shadow IT）」？為什麼它讓 IT 部門頭痛？
影子聽起來像是違規行為？
影子 IT 是指員工或部門未經 IT 部門批准，自行採購或使用軟體與服務的現象。No-Code 工具使影子 IT 更普遍，因為門檻低。問題在於這些應用的安全性、合規性、資料存取路徑不在 IT 視野內，形成治理盲區。
RBAC（Role-Based Access Control）在資料治理上扮演什麼角色？
就是設定誰能看什麼、誰不能看什麼？
RBAC（角色型存取控制）是根據員工的職位角色而非個人身份來決定資料存取權限的機制。財務部門可看薪資資料，行銷部門不行，這個規則綁在「角色」上，不需要每個人個別設定。RBAC 讓大規模的資料治理變得可管理。
企業導入 No-Code/Low-Code 前，在治理層面應先做哪些準備？
先買工具再說，邊用邊學？
應先完成：資料分類分級（哪些資料是敏感的）、存取政策定義（哪些角色能存取哪些資料）、合規要求盤點（適用哪些法規）。這些政策確定後，再設定到平台的控管機制上，才能確保平台上線後治理有效。工具先於政策是常見的導入失敗原因。
資料治理（Data Governance）和資料管理（Data Management）有什麼差別？
兩個都是「管理資料」，有差嗎？
資料治理是制定政策和規則：誰能存取什麼、資料要保存多久、誰負責資料品質。資料管理是執行這些政策的技術和流程：ETL、資料庫管理、備份。治理是「要做什麼」，管理是「怎麼做」。No-Code 平台的內建控管屬於資料管理，但它的設定依據是資料治理政策。
企業 AI 應用的合規要求主要來自哪些層面？
只有個資法吧？
合規要求來自多個層面：法規層（個資法、GDPR、特定產業法規如金融法）、行業標準層（ISO 27001 資安認證）、企業內部政策（資料分類、存取政策）、AI 倫理框架（公平性、透明性要求）。AI 應用規劃師需要在規劃階段就識別所有適用的合規要求。
想再往下看，這 5 個
- 無程式碼（No Code）完全不需撰寫程式即可建置應用的平台，使用者普及後資料存取範圍擴大，治理挑戰隨之浮現
- 低程式碼（Low Code）以少量程式碼完成應用開發的工具，平台是否內建角色權限與存取控管是治理能否落實的關鍵
- 資料隱私（Data Privacy）保護個人或敏感資料不被未授權存取的原則，是 No-Code 平台擴大使用後最受關注的合規議題
- 資料血緣追蹤（Data Lineage）記錄資料從來源到使用全程的流向，讓企業在合規審查時能追溯誰在哪個應用存取了哪些資料
- AI治理（AI Governance）針對 AI 與資料應用制定政策與監督機制的框架，No-Code 普及正在考驗既有治理制度的適應能力