禁不掉，幫不了，出事再說又來不及。

那企業到底該怎麼辦？
我個人看法是這樣....但純粹是從我的角度來看 或許很多人有其他的想法

從 ISO 27001 的角度來看，這種看起來很新的東西，標準裡本來就有一套做法。
這些也是跟其他東西是一樣的流程：
盤點、分類、風險評估、納管，然後寫成規範，不同的面向對應不同的管理方式。

管理目標

先確認想要管的是甚麼，例如:純靜態HTML、私下放企業外部的系統

盤點

ISO 第一件事肯定是資產盤點。你不知道有什麼，後面的東西沒辦法定義，訂出來的也套不上。

但不太一樣的是 以前盤資產是盤伺服器、盤系統、盤廠商，長什麼樣大家都知道。
「員工自己用 AI 做的東西」是全新的一類，可能連長什麼樣都還沒定義。

已知的有什麼：
從管制設備撈紀錄，查誰連了 github.io、Google Sites、Firebase 這類地方；
正式發文請各單位盤點自己做出來的系統或靜態頁面工具。

分類

或許可以從幾個面向看：功能是什麼、碰什麼資料、給誰用、放在哪、做什麼。

同樣是 AI 產的 HTML，一個是 PDF 小工具、一個是企業內部的重要資料計算、一個是處理機敏資料的，不該用同一套要求。

風險評估：分三級

然後從威脅和弱點來看；
或許也可以考慮威脅建模來分析

衝擊看它碰什麼資料、多少人用；可能性看它放在哪、有沒有人管。大概可以簡單的分成三級：

低風險：純前端、不碰個資、小範圍用、放在企業內
中風險：處理內部資料、跨單位用、有表單或上傳
高風險：碰個資或機敏資料、全企業用、需要串內部的系統、包含重要資訊

納管：不同等級不同要求

低風險：登記就好。自動掃描過了就上架，審查員看一眼放行，當天完成。
中風險：登記加審查。人工看、單位主管簽核、資料分級填清楚、定期複查。
高風險：走正式系統申請的流程。

不管哪一類，共同點是：企業都應該納入管理。

寫成政策規範

前面做完後開始訂定企業的整個政策跟規範。

政策幾句話就夠，講整個企業的立場：可不可以用 AI、哪些單位或區域可以用、能用哪些 AI 服務、使用前要不要申請、員工用 AI 做出來的工具或系統要照什麼流程管。

規範

先把範圍明訂清楚

1. 人的範圍2. 事的範圍 3. 地的範圍 4. 時的範圍

• 什麼算工具、什麼算系統
• 什麼可以、什麼不行
• 去哪登記、填什麼、誰審、審多久、審完會怎樣
• 誰負責：做的人是 owner、單位主管簽了就是知情必須連帶負責、資訊單位負責基礎建設和審查。
• 不同的風險對應不同的申請人要求，例如：簡單工具、HTML所有人都能申請，但一個完整的系統就會需要申請人( 開發者)需要具有資訊系統的認知跟資安教育訓練，要介接院內資料就需要證照如:IPAS資安工程師、ISC2 CC、
  google cybersecurity certificate、並且通過企業內部基礎考核。
• 原則禁止，申請審查通過後開放
• 新增、修改、刪除都要走審核流程，沒有「小改不用審」這種例外
• 申請人和單位要負責工具的轉手或下架：人離職、調單位、或工具不用了，單位主管要在期限內指定新 owner 或申請下架，逾期資訊單位直接下架

治理面讓全企業有同一套流程，但長久來看以及從技術面來說
不可能只靠人工跟表單來做管理，所以我覺得應該可以有一個平台把流程系統化自動化。