再好的點子，沒有合規、拿得到、付得起的資料就是空談。
動手前先盤點四面向：可取得性、隱私、成本、時程——一項紅燈就卡住。
再好的點子，沒有合規、拿得到、付得起的資料就是空談。資料限制評估就是動手前先盤點四件事：可取得性、隱私法規、成本、時程。很多專案死在「做到一半才發現資料不能用」。
GDPR/個資法，個資要去識別化。
買資料、標註、儲存都要錢。
資料蒐集與清理要多久。
口訣：拿得到嗎、能合法用嗎、付得起嗎、來得及嗎——四個都「是」，這個資料需求才成立。
選一種資料需求，看它在可取得性、隱私、成本、時程四個面向的紅綠燈，以及整體可行性判斷。注意：只要有一項是紅燈，整個需求就卡住。
| 類型 | 要問什麼 | 風險 |
|---|---|---|
| 可得性 | 需要的欄位/資料量拿不拿得到 | 中途才發現資料不足 |
| 品質 | 資料完整、正確、及時嗎 | 垃圾進、垃圾出 |
| 隱私/法規 | 涉及個資嗎(GDPR/個資法/出境) | 觸法、罰款 |
| 成本/時程 | 標註成本多少、多久拿得到 | 超預算、專案延誤 |
釐清資料的需求與限制是 iPAS 規劃考點(初級科目一、中級科目二)。重點:動工前先確認需要哪些欄位、量夠不夠、品質如何、標註成本與法規限制,這些決定專案可行性。易混點:資料不足或標註太貴常是專案失敗主因,別等建模才發現;法規(個資法、GDPR)會限制可用的資料與用途。情境:可行性評估、判斷該不該啟動專案。
想練情境題與詳解 → AI 學習與考證地圖
資料庫層級對資料的規則(如非空、唯一、外鍵、值域)，確保只有合法資料能寫入，從源頭維護品質與完整性。
主鍵(唯一識別)、外鍵(維護表間關聯)、NOT NULL、UNIQUE、CHECK(值需符合條件)、預設值。
主鍵唯一識別一筆紀錄、不可重複或空；外鍵指向另一表的主鍵，維護參照完整性、避免孤兒紀錄。
在寫入時就擋掉錯誤(重複、缺值、無效值、斷裂關聯)，從源頭防止髒資料，比事後清理更省力可靠。
會；過嚴可能拒絕合理資料或拖慢寫入，需在完整性與彈性、效能間取捨，依場景設計適當規則。