就在各國還在爭論AI到底應該跑多快時，AI安全問題已經從研究室走進現實。最近OpenAI暫停部分先進模型訓練，原因是測試中的AI代理出現超出原先指令範圍的行為。Nvidia也推出OpenShell與Sentry等安全工具，希望把失控的AI代理限制在一定範圍內，必要時直接關閉。AI能力愈來愈強，大家開始碰到同一個問題，出了事，到底誰知道？要不要強制通報？作者：張瑞雄（台北商業大學榮譽講座教授）

就在各國還在爭論AI到底應該跑多快時，AI安全問題已經從研究室走進現實。最近OpenAI暫停部分先進模型訓練，原因是測試中的AI代理出現超出原先指令範圍的行為。Nvidia也推出OpenShell與Sentry等安全工具，希望把失控的AI代理限制在一定範圍內，必要時直接關閉。AI能力愈來愈強，大家開始碰到同一個問題，出了事，到底誰知道？要不要強制通報？

[caption id="attachment_322010" align="alignnone" width="797"] AI出事72小時內要說｜專家論點【郭啟全】（圖／AI生成）[/caption]

美國紐約州給了一個很簡單的答案，72小時。新的RAISE法案要求大型AI開發商向州政府登記，從2027年1月1日起遵守安全、透明及事故通報規定。發生重大安全事件，必須在72小時內向主管機關報告，還要定期提出重大風險評估，公開安全與透明制度。

72小時很重要

飛機出事要調查，食品出問題要下架，銀行遭駭要通報，AI公司為什麼可以自己決定什麼時候公布事故？

過去AI公司的安全資訊大多掌握在自己手上。模型出了異常，公司先調查、先修補、先開會，最後才決定要不要對外說。但公司同時是開發者、測試者、事故知情者，也是決定公布多少資訊的人。當產品價值可能高達數百億美元，甚至牽動上市與募資時，要公司完全靠自律對外揭露自己的重大失誤，本來就很勉強。

最近AI代理的發展更使情況不同，以前聊天機器人回答錯誤，頂多給你一個錯誤答案。AI代理現在可以操作電腦、寫程式、呼叫其他工具、登入網站，甚至替人完成一連串工作。能力從「回答」變成「行動」，事故的意義也跟著改變。最新案例已經出現AI代理嘗試執行未獲授權的行動，這也是各界對安全通報突然重視的原因。

但什麼叫出事

72小時看起來很嚴格，真正執行時卻有一個漏洞。什麼程度才算「重大安全事件」？

紐約州法律涵蓋模型未依使用者要求自主行動、模型權重遭竊或外洩、重要安全控制失效，以及未經授權使用等情況，但還附帶相當高的「重大傷害」門檻，某些令人不安的AI代理事件未必達到法定通報標準。也就是說，AI已經翻牆跑出去，卻可能因為還沒有造成足夠大的實際損失，而不必依這套制度通報。

因此，未來制度應該把「事故」與「異常」分開。重大事故72小時強制通報，沒有造成傷害卻出現逃脫安全限制、自行擴張權限、欺騙監控系統等異常行為，也應留下紀錄。政府不必要求每件事都公布，更不必看到一次異常就處罰公司，但不能完全不知道。

管大不管小

另外如果各州各訂一套規定，AI公司會不會忙著填表而沒有時間做研究？小公司會不會因為合規成本太高，最後只剩幾家巨頭玩得起？

所以紐約的做法有一點很重要，它主要鎖定大型AI開發商，而非每一家使用AI的公司。歐盟的AI Act也採取類似的風險思維，對具有系統性風險的通用AI模型要求進行模型評估、風險降低、重大事故通報及資安防護。

用AI整理會議紀錄的小公司，與花幾十億美元訓練先進模型的企業，承擔的社會風險根本不同。法規如果大小通吃，只會增加中小企業成本。政府應該盯住最有能力造成大規模影響的模型，以及醫療、金融、能源、交通等高風險用途。

台灣也該準備

台灣現在談AI治理，常在「不要妨礙創新」與「一定要保障安全」之間打轉。這兩句話都對，卻很難拿來處理明天真的發生的事故。

我們需要回答一些很實際的問題，例如大型AI系統發現重大漏洞，幾小時內要通報？通報給誰？政府有沒有人看得懂？企業隱匿要不要處罰？善意主動通報能不能減輕責任？涉及商業機密的資料如何保護？同一事故如果影響金融、醫療與個資，要不要向3個主管機關各報一次？

這些事情現在就可以訂規則，不必等AI出事才開始想。

A公司可以犯錯，但不能把重大事故藏在公司裡。AI愈有能力替人做事，這條規矩就愈重要。社會最怕的是AI出了錯，但世界沒有人知道。

這篇文章 AI出事72小時內要說｜專家論點【張瑞雄】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

學生交來一篇文章，老師懷疑是AI寫的，丟進AI偵測工具，螢幕跳出「AI生成的機率85%」，學生就算作弊嗎？作者：張瑞雄（台北商業大學榮譽講座教授）

學生交來一篇文章，老師懷疑是AI寫的，丟進AI偵測工具，螢幕跳出「AI生成的機率85%」，學生就算作弊嗎？

[caption id="attachment_301959" align="alignnone" width="842"] 別太相信AI能抓AI｜專家論點【張瑞雄】。（圖／AI生成）[/caption]

AI偵測工具的創辦人都承認，達到100%的正確率大概做不到。連賣偵測工具的人都不敢保證，學校怎麼敢把一個百分比當判決書？

誰寫的？

AI文字偵測有先天困難，今天AI愛用的句型，明天新版可能就消失。人類發現AI愛用破折號，告訴ChatGPT不要用，它馬上可以改。網路上甚至出現專門替AI文章「人性化」的工具，抓的人永遠追著寫的人跑。

OpenAI自己就是很好的例子，2023年曾推出AI文字偵測器，結果只能辨識出26%的AI文章，還把9%的人類文章誤判成AI，幾個月後乾脆下架。

3年過去了，技術當然進步很多。一個軟體宣稱在AI文字超過20%的文件中，誤判率低於1%。聽起來已經很好，但1%放進100萬名學生，就可能有1萬名學生被冤枉。所以軟體公司也很小心，偵測比例低於20%時，乾脆不顯示確切百分比，因為容易誤判。它還明白提醒學校，AI偵測結果不能單獨作為處分學生的依據。工具公司都叫老師不要太相信工具，老師更不該迷信。

好學生倒楣？

一個英文寫得很棒的學生，句型規律、文法幾乎沒有錯，可能比較像AI。一個英文程度不好的學生，拼字錯誤、文法亂七八糟，反而很有「人味」。如果最後前者被懷疑作弊，後者順利過關，是不是開了一個很大的玩笑？

非英語母語學生更值得注意，很多AI偵測器主要用英文資料訓練，語言能力、文章類型、篇幅都可能影響結果。連OpenAI當年的分類器都承認，在非英文文字上的表現更差。

還有一個灰色地帶，學生自己寫初稿，叫AI改英文，算誰寫的？學生寫中文，請AI翻成英文呢？自己列大綱，AI幫忙整理句子又怎麼算？今天的文章很少只有「100%人寫」與「100%AI寫」兩種，AI輔助寫作愈普遍，硬要把每篇文章貼上人類或AI標籤，會愈來愈困難。

老師用心才是正途

老師一次改50份報告，不可能每篇都當刑警辦案。偵測器可以幫老師找出值得注意的文章，就跟抄襲比對系統一樣，有紅燈就多看兩眼，可是有紅燈不等於有罪。

老師如果懷疑學生大量使用AI，最簡單的方法是把學生叫來談。你為什麼選這個題目？這一段在講什麼？資料從哪裡來？把其中一個觀點再說清楚。真的自己寫過的人，通常講得出思考過程。

更好的方法是看過程。學生留下大綱、資料來源、初稿、修改紀錄與AI對話，老師看到的是作品怎麼長出來。大學也可以增加口試、課堂寫作、專題實作與簡報答辯。這些方法比較麻煩，卻比盯著「AI生成73%」來做判斷公平。

AI已經進入職場，學校若還把「完全不用AI」當成規定，也會碰到麻煩。學生畢業進公司，老闆可能第一天就叫他用AI來提高效率。

老師規定不能用AI，學生偷偷叫AI整篇代寫，當然要處理。老師准許用AI整理資料，學生清楚交代怎麼使用，就沒有必要抓。每一門課先把界線講明白，比事後拿偵測器追殺有效得多。

學生用AI寫作，老師再用AI決定學生有沒有作弊。教育如果走到這一步，最該被檢討的恐怕不是學生，不用大腦的老師和學校才是罪魁禍首。

延伸閱讀：AI開始不聽話，人類準備好了嗎？｜專家論點【張瑞雄】

這篇文章 別太相信AI能抓AI｜專家論點【張瑞雄】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上篇聊到，Cosmos DB 這類資料庫天生是為 OLTP（處理單筆交易）設計的，想拿來做 OLAP（跨資料分析），需要先把巢狀資料反正規化成寬表。攤平之後，還有兩件事要決定：資料要放進什麼樣的資料庫、以及用什麼工具讓業務人員自然語言查詢。作者：黃婉中（雲端架構師）

上篇聊到，Cosmos DB 這類資料庫天生是為 OLTP（處理單筆交易）設計的，想拿來做 OLAP（跨資料分析），需要先把巢狀資料反正規化成寬表。攤平之後，還有兩件事要決定：資料要放進什麼樣的資料庫、以及用什麼工具讓業務人員自然語言查詢。

[caption id="attachment_274302" align="alignnone" width="834"] （圖／AI生成）[/caption]

順帶一提，攤平不用另外建表、複製一份資料維護。微軟的 Fabric 是一套把資料整理、儲存、查詢、視覺化包在一起的分析平台，用它的 Mirroring 功能，Cosmos DB 資料同步過去後，可以直接下 query 把巢狀 JSON 展開，再用這段 query 建一個 view。View 不是實體資料，是存起來的查詢邏輯，不用寫 ETL，也不動 Cosmos DB 本身的結構。 

除了表怎麼設計，資料庫本身也要跟著換

客戶後來又問了我一個問題：既然只是把表格設計改一下，那是不是隨便找個資料庫，把表改成上篇那樣就好，不用大費周章換資料庫？

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

這裡有一層容易被忽略的細節：反正規化只是改變表怎麼設計，但資料庫底層如何存資料，也會影響效能。

傳統 SQL 資料庫（像 PostgreSQL、MySQL）是列式儲存（row storage）：同一筆記錄的所有欄位，實際存在硬碟上相鄰的位置。這對 OLTP 很合適，因為一筆交易通常要讀寫一整列的大部分欄位，例如結帳、更新個人資料，整列存在一起，一次讀寫就搞定。

但 OLAP 常見的查詢是「只挑幾個欄位，掃過幾百萬列」，例如上篇那張銷售事實表，只要「城市」跟「小計」這兩欄算加總，不需要其他欄位。如果資料是列式儲存，即使只要兩個欄位，硬碟還是得把整列讀出來才能挑出需要的部分，等於浪費大量讀取效能。這就是為什麼專門做 OLAP 的資料庫，用的是欄式儲存（columnar storage）：把同一個欄位的資料集中存在一起，查詢時只讀取需要的欄位，大幅加快分析查詢的速度。

所以「要不要換成專門的欄式儲存資料庫」，是看兩個條件：

查詢形狀：如果使用情境是「掃過很多列、只看幾個欄位、要加總分組」，欄式儲存更快。

寫入方式：如果是批次匯入、寫入後很少逐筆修改（像這個客戶每天把 Cosmos DB 資料批次同步過來），欄式儲存更有優勢。

為什麼是 Fabric，不是自己組一套？

資料整理好，也放進合適的資料庫之後，接下來要決定的是：業務人員要用什麼工具，才能用自然語言查到答案。

客戶問我：如果重點是「把資料攤平」，那用 Microsoft AI Foundry 直接接 Cosmos DB，用 AI agent 現場處理，是不是也可以？

技術上走得通，Cosmos DB 的 SQL API 本身也能查巢狀 JSON。但差別在於：Cosmos DB 沒有Create view這種把查詢邏輯存成物件的功能，agent 每次都得現查。要把攤平邏輯固化成一個大家共用的 view，需要使用Fabric。Fabric 可以針對鏡射資料建 view，之後 Data Agent、Power BI 都直接查這個 view 就好。

選 Fabric，等於買了一套資料整理、儲存、查詢介面、視覺化全部包在一起的服務。攤平好的資料留在 OneLake 裡，Fabric Data Agent 直接查，要做報表就接 Power BI，中間不用再多想「這份資料該放哪個資料庫」。

如果選 Foundry，拿到的是查詢介面跟 AI 推理引擎，但資料整理完要放哪裡，得自己決定，可以放 Azure SQL、放 PostgreSQL，甚至最後還是得繞回 Fabric 的 OneLake。要做視覺化報表，還得另外接 Power BI 或別的工具。

有內部工程團隊、想要高度客製化的公司，可能會選 Foundry 自己組；沒有工程團隊、想要幾個月內上線的中小企業，買一套包好的服務，反而更划算。

給讀者的判斷框架

回頭看整件事，其實可以歸納成四個問題，遇到類似情境時可以拿來問自己：

1. 我要做的是 OLTP 還是 OLAP？ 查一筆資料 vs. 算一堆資料的加總，需要不同資料庫設計。
2. 值不值得做反正規化？ 這是一次性的整理成本，換取之後每次查詢都更快更準。如果查詢頻率低、資料結構單純，不一定要大費周章。
3. 需不需要換成專門的欄式儲存？ 看查詢的形狀（找特定一筆，還是掃很多列算加總）跟寫入的方式（頻繁單筆修改，還是批次匯入），不是單純看資料量大小。
4. 要自己組，還是買整合服務？ 沒有工程團隊、想快速上線，選整合服務；有能力客製化、想要更大的彈性，可以自己組。

這篇文章 讓 Cosmos DB 的資料開口說話：攤平之後怎麼查？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

「要跑，不要用走的」(Run, don't walk)，是輝達執行長黃仁勳送給AI世代最直接的一句提醒。2023年，他在國立臺灣大學畢業典禮上曾經告訴當年的畢業生，世界正站在AI革命的起跑線；到了2026年5月10日，他又在美國卡內基美隆大學(CMU)畢業典禮再度重申這一句話。這裡所說的「跑」，並不是盲目追逐熱門技術，也不是要求每個人陷入過度競爭，而是提醒我們，當科技演進速度遠比教科書改版與企業決策更快時，不能再抱著「等一切準備好再開始」的心態。生成式AI、智慧製造、機器人與先進半導體正快速改變研發和生產模式。因此，科技人必須保持學習動力，敢於動手驗證、快速修正，並在變局中找到自己能創造的價值。最真正重要的是要一邊「跑」，一邊校正「方向」。作者：郭啟全（明志科技大學 機械工程系暨機械與機電工程研究所 教授、明志科技大學 智慧醫療研究中心 教授、長庚大學 機械工程學系 合聘教授、明志科技大學 可靠度工程研究中心 教授）

「要跑，不要用走的」(Run, don't walk)，是輝達執行長黃仁勳送給AI世代最直接的一句提醒。2023年，他在國立臺灣大學畢業典禮上曾經告訴當年的畢業生，世界正站在AI革命的起跑線；到了2026年5月10日，他又在美國卡內基美隆大學(CMU)畢業典禮再度重申這一句話。這裡所說的「跑」，並不是盲目追逐熱門技術，也不是要求每個人陷入過度競爭，而是提醒我們，當科技演進速度遠比教科書改版與企業決策更快時，不能再抱著「等一切準備好再開始」的心態。生成式AI、智慧製造、機器人與先進半導體正快速改變研發和生產模式。因此，科技人必須保持學習動力，敢於動手驗證、快速修正，並在變局中找到自己能創造的價值。最真正重要的是要一邊「跑」，一邊校正「方向」。

[caption id="attachment_274352" align="alignnone" width="834"] 雨中不停步 ，科技人沿著AI賽道跑向智慧未來。 (資料來源：郭啟全)[/caption]

談到「跑」，筆者腦中浮現的是幾個令人印象深刻的畫面。曾經有人撐著傘在操場上一圈又一圈地跑，也有人沿著松山機場周邊持續前進；即使天空飄著小雨，真正熱愛跑步的人，依然會按照原定計畫完成當天的里程。這一些畫面很平常，卻讓我想到科技研發的真實樣貌。筆者指導大學部專題生時，也曾發現部分學生做專題總是「用走的，而不是用跑的」：遇到

問題先擱置、等待老師提醒才行動，實驗與資料整理也一再延後，導致整體進度相當緩慢。做專題就像跑步，不一定要一開始便全力衝刺，但必須設定目標、維持節奏並持續累積；如果總是停在原地等待，原本充裕的時間，最後也可能變成一場匆忙趕工的追逐賽。專題研究不可能天天都是晴天，實驗可能失敗，設備可能故障，模擬結果也可能與實驗對不上。遇到這些「小雨」時，有些人停下來等天氣變好，有些人則需要調整速度，撐著傘繼續跑。意志力不是硬撐到底，更不是忽略風險，而是知道目標在哪裡，遇到問題後仍願意換一種方法前進。對學生而言，是多做一次實驗、多待在實驗室一些時間、多閱讀一篇文獻以及多與實驗室學長姐討論問題點；對研究團隊而言，是從錯誤資料找出原因以及解決方案；對企業而言，則是在市場尚未明朗時，仍願意投入人才與關鍵技術。科技創新很少是一路順風的短跑，更多時候，是一段必須接受挫折並持續累積的長程賽。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

不過，只靠意志力還不夠，科技人也需要敏銳的觀察力。跑步的人必須看「路」，知道哪裡積水、哪裡濕滑、何時該加速、何時應避開風險；投入科技發展也是如此。面對AI浪潮，我們不能只看運算速度有多快，更要觀察產業缺少什麼、使用者需要什麼，以及技術可能帶來哪些倫理、安全與就業影響。「要跑，不要用走的」不是焦慮式的催促，而是一種主動面對未來的態度。科技人既要有在雨中前進的意志力，也要有看清路況與辨識機會的觀察力，才能夠跑得穩，也帶著臺灣科技產業跑得更遠。

這篇文章 AI時代別再用走的！科技大學機械系學生如何跑出未來競爭力｜專家論點【郭啟全】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

最近AI失控的事件頻傳，這已不限於回答錯誤，有些AI會忽略指令、規避限制、冒充使用者取得授權，甚至為了完成任務採取使用者根本沒有要求的行動。AI愈能替人做事，人類也開始面對一個過去只存在於科幻小說的問題，交給AI的權力，還收不收得回來？作者：張瑞雄（台北商業大學榮譽講座教授）

最近AI失控的事件頻傳，這已不限於回答錯誤，有些AI會忽略指令、規避限制、冒充使用者取得授權，甚至為了完成任務採取使用者根本沒有要求的行動。AI愈能替人做事，人類也開始面對一個過去只存在於科幻小說的問題，交給AI的權力，還收不收得回來？

[caption id="attachment_274394" align="alignnone" width="810"] AI開始不聽話，人類準備好了嗎？｜專家論點【張瑞雄】。（圖／AI生成）[/caption]

最令人不安的例子來自AI代理程式，曾出現數百個自主代理程式協同行動，突破原有測試範圍並攻擊外部系統。這已經超過大家熟悉的「AI幻覺」，因為幻覺主要是說錯話，代理型AI卻可能真的寄信、修改程式、存取資料、使用帳號，甚至操作其他資訊系統。

從回答到行動

過去使用ChatGPT之類的生成式AI，人類大致仍握有最後決定權。AI寫一封信，我們決定寄不寄。AI提出投資建議，我們決定買不買。代理型AI改變了這層關係，人只需要交代目的，它便能自行拆解工作、選擇工具、連接其他服務並持續執行。自主程度愈高，效率確實愈驚人，出錯時造成的損害也從「答案錯了」升高為「事情已經做了」。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

這正是AI產業目前最難處理的矛盾，大家希望AI更聰明、更主動，最好不用每一步都詢問人類。企業也期待它能24小時工作，自行處理採購、客服、程式設計、財務與行政流程。可是AI愈有用，就必須給它更多權限。沒有電子郵件權限，它無法當祕書。沒有企業資料庫權限，它很難分析營運。但給AI能力和權限，風險也同時成長。

不能只靠煞車

面對AI失控，有人主張放慢大型模型發展，甚至暫停能力更強的模型。這種警告有其道理，卻很難成為長久方案。美國、中國、歐洲及全球科技公司都在競逐AI能力，要求所有人同時停下來，政治上與商業上都缺乏可行性。近期部分AI公司已因安全事件放慢測試、加強監控，也說明安全成本正在成為模型開發無法迴避的一部分。

比較務實的方向，是把AI代理程式視為企業裡一位速度極快、能力很強，卻不能完全信任的數位員工。公司不會把所有帳號、銀行密碼、客戶資料與簽約權一次交給剛報到的員工，AI也不應享有無限制權限。每個代理程式應有明確身分、工作範圍與權限，重要操作留下完整紀錄，高風險行為必須取得人工核准，超過預定範圍就自動停止，這些做法已逐漸成為企業治理AI代理程式的重要方向。

更值得建立的是AI事故通報制度，航空業不會因為飛機最後安全降落，就把差點撞山的事件當作沒發生。AI也需要類似的要求，若模型欺騙使用者、偷偷繞過權限或企圖掩蓋行動，即使最後沒有造成損失，也應留下紀錄並進行調查。現在許多失控資料仍來自社群平台上的使用者自行揭露，因此只能看到部分情況，實際數量可能更多。

責任不能外包

法律也必須跟上，AI做錯事，企業無法逃避責任。公司既然決定部署AI，就必須對AI結果負責。未來甚至連保險業都得重新界定風險，因為AI取得合法帳號後自行造成損害，究竟屬於資安攻擊、操作失誤還是產品責任，現有制度未必能清楚回答。

AI的下一階段競賽，不該只比誰的模型考試分數最高、推理最快、代理能力最強。能不能讓一個能力愈來愈大的系統知道哪裡必須停手，讓人類知道它做過什麼，出事時又能立即切斷權限，將決定這項科技能否取得社會長期信任。

人類過去擔心機器不夠聰明，所以努力教它思考。如今AI開始能自己規畫、自己執行，甚至能與其他AI合作，人類需要學習如何控制它。科技史上最危險的時刻，往往不是工具沒有能力，而是人類給了工具能力，卻忘了同時設下邊界，讓工具變成脫韁野馬。

這篇文章 AI開始不聽話，人類準備好了嗎？｜專家論點【張瑞雄】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

有個貸款客戶想要回答一些商業問題，例如「這個月哪個合作機構的成交量最高」。他們本來是用 Cosmos DB 存資料，但每次想知道這類問題的答案，都得找分析師，寫一段查詢、等結果。為了縮短等待，我們幫他們把資料攤平、做反正規化，讓客戶從此可以直接用自然語言去查詢，不用再等分析師。作者：黃婉中（雲端架構師）

有個貸款客戶想要回答一些商業問題，例如「這個月哪個合作機構的成交量最高」。他們本來是用 Cosmos DB 存資料，但每次想知道這類問題的答案，都得找分析師，寫一段查詢、等結果。為了縮短等待，我們幫他們把資料攤平、做反正規化，讓客戶從此可以直接用自然語言去查詢，不用再等分析師。

[caption id="attachment_274110" align="alignnone" width="885"] （圖／AI生成）[/caption]

這篇想把中間比較細節的兩個部分拆開來講：一是為什麼 Cosmos DB 不適合直接分析，二是攤平跟反正規化在做什麼。

資料庫的兩種個性：OLTP 跟 OLAP

先講兩個詞，因為後面會一直用到。

OLTP（Online Transaction Processing，線上交易處理）：例如打給客服、銀行轉帳。OLTP 資料庫的強項是「單一一筆」存取。

OLAP（Online Analytical Processing，線上分析處理）：例如「這個月哪個放款機構成交最多」。OLAP 資料庫的強項是「大量資料」統計。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

Cosmos DB 是 OLTP，但跟 SQL 的 OLTP 不一樣

這裡有個容易搞混的地方：傳統 SQL 資料庫也是拿來做 OLTP 的，但它跟 Cosmos DB 做 OLTP 的方式不一樣。

SQL 資料庫：把資料拆細（正規化）。 客戶資料一張表、貸款資料一張表、還款紀錄一張表，彼此用關聯串起來。這樣做的好處是，如果客戶改名字，只要改一個地方，不會有些表改了、有些表忘記改，資料不會兜不起來。查詢的時候，用 JOIN 把幾張表接起來看。

Cosmos DB：把資料打包在一起。 一個客戶的姓名、聯絡方式、名下所有貸款、每筆貸款的還款紀錄，全部塞進同一份 JSON 文件裡。客服系統一查這個客戶，一次就把所有相關資料抓齊，不用像 SQL 那樣東拼西湊做 JOIN，速度極快。

這也是為什麼 Cosmos DB 裡的資料長得「一層包一層」，技術上叫巢狀結構（nested structure），客戶底下包貸款，貸款底下包還款紀錄，像俄羅斯娃娃一樣。是為了讓應用程式查詢快的刻意設計。

兩個產品都是為了讓「單筆存取」快，只是方法不同。

想做分析，才發現這個設計不夠用

當資料累積多了，客戶開始想要做分析，回答「這個月哪個放款機構成交最多」。像這種要攤開所有客戶、所有貸款，跨資料去加總比較，是巢狀打包結構最不擅長的事。因為資料被鎖在一份一份的文件裡，每份都要打開來看，才能湊出跨資料的統計結果。

解法：「反正規化」把資料變成一張寬表

要解決這個問題，做法是把巢狀資料攤平成表格。

用一個具體例子說明。一間店有兩個客戶：小明住台北，買過兩次東西；小華住高雄，買過一次。

如果是 SQL 正規化的做法，會拆成三張小表：

客戶表

產品表

訂單表

「小明」這兩個字只在客戶表裡出現過一次，訂單表只存客戶編號，不存名字。這樣做的好處是，小明改名字只要改一個地方；但想知道「小明總共花了多少錢」，得把三張表 JOIN 起來，先查出客戶編號、再對應產品單價，才能算出總金額。

如果是 OLAP 反正規化的做法，會攤平成一張寬表：

銷售事實表

「小明」「台北」這些資訊重複出現了兩次。在正規化的世界裡，這種重複是大忌；但在這裡是刻意設計的，因為現在想問「小明總共花了多少錢」，不用 JOIN 任何表，直接把小明那幾列的「小計」加起來就好；想問「哪個城市買最多」，把「城市」欄位拿出來加總分組就好。

這種「一列代表一筆事件、允許重複」的表，在資料倉儲的世界裡叫 fact table（事實表）；像「小明」「台北」這種會重複、用來描述這筆事件的欄位，叫 dimension（維度）。

一句話總結兩者的差異：正規化把「小明」這個名字存一次、用編號互相參照，換取修改資料時的安全；反正規化把「小明」這個名字允許重複貼在每一列上，換取統計加總時不用東拼西湊查好幾張表。

這裡說的「攤平」，就是反正規化，把 Cosmos DB 裡打包好的巢狀資料，拆開重組成扁平的寬表。欄位命名清楚、預先算好常用的加總。讓後面不管是人還是 AI，都能一眼看懂、快速查詢。

下篇想接著聊：整理完的資料放好之後，該用什麼工具讓業務人員自然語言查詢，這件事該自己組一套系統，還是買現成的整合服務。

這篇文章 讓 Cosmos DB 的資料開口說話：從等分析師，到自然語言查詢｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

筆者最喜歡前往亞洲的兩個國家參加國際研討會，一個是日本，另一個是新加坡。每一次出國，當然要聆聽大師之研究成果、學技術以及認識國際學者，但是筆者更在意的是，這一個國家為什麼能把一件事做到世界級。日本最值得學習的是職人精神(spirit of craftsmanship)。走進拉麵店、壽司店或甜點店，常會發現店面不大、品項不多，師傅卻願意花數十年反覆磨練同一項技術。從食材、刀工、火候到擺盤，每一個細節都不馬虎，因此許多平凡料理也能累積出國際肯定的品質。這一種精神和機械工程非常接近。一個零件的尺寸差一點、表面粗糙度多一點、製程參數偏一點，最後機械零件之性能就會完全不一樣。優秀工程師不只是把產品做出來，而是持續追問，還能不能更準、更穩、更安全。作者：郭啟全（明志科技大學 機械工程系暨機械與機電工程研究所 教授、明志科技大學 智慧醫療研究中心 教授、長庚大學 機械工程學系 合聘教授、明志科技大學 可靠度工程研究中心 教授）

筆者最喜歡前往亞洲的兩個國家參加國際研討會，一個是日本，另一個是新加坡。每一次出國，當然要聆聽大師之研究成果、學技術以及認識國際學者，但是筆者更在意的是，這一個國家為什麼能把一件事做到世界級。日本最值得學習的是職人精神(spirit of craftsmanship)。走進拉麵店、壽司店或甜點店，常會發現店面不大、品項不多，師傅卻願意花數十年反覆磨練同一項技術。從食材、刀工、火候到擺盤，每一個細節都不馬虎，因此許多平凡料理也能累積出國際肯定的品質。這一種精神和機械工程非常接近。一個零件的尺寸差一點、表面粗糙度多一點、製程參數偏一點，最後機械零件之性能就會完全不一樣。優秀工程師不只是把產品做出來，而是持續追問，還能不能更準、更穩、更安全。

[caption id="attachment_274329" align="alignnone" width="846"] 一座食堂看見一所大學的世界觀 新加坡國立大學把國際化端上餐桌。（圖／郭啟全提供）[/caption]

新加坡帶給筆者的啟發則是國際化(internationalization)，這一個國家面積不大、天然資源有限，卻很清楚人才、教育與全球連結就是競爭力，因此大學積極延攬國際師資與學生，研究團隊也習慣跨國合作。以新加坡國立大學(NUS)為例，目前校方資料顯示，其在QS世界大學排名中位居亞洲第一、全球第十，這一項成果主要是反映新加坡長期國際布局所形成之影

響力。 對臺灣科技大學而言，國際化不能只停留在出國參訪或英文畢業門檻，而是要讓學生真正和不同文化背景的人一起進行實務專題、解決問題以及發表研究成果。特別是機械工程已經不再僅只是車床、鑽床、銑床、磨床與機構設計，還要結合人工智慧、智慧製造、半導體設備、機器人、能源以及醫療工程。學生若只有單一技術，很容易被快速變化的產業淘汰；若同時具備實作、跨域整合與國際溝通能力，就更有機會走進全球科技產業。新加坡國立大學把國際化端上餐桌，圖1為一座食堂看見一所大學的世界觀。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

不過，科技人才的養成不能只有專業與國際化，還必須回到「人」本身。臺大校長陳文章曾經勉勵大一新生們，大學生涯要重視三件事情，包括結交好友、培養面對挫折的忍耐力，以及勇敢追求自己的夢想。這三句話，也非常適合送給科技大學與機械工程系學生。工程專題很少一次成功，實驗會失敗、模具會加工錯誤、程式會出錯、實驗數據也可能不如預期，若遇到問題就選擇放棄，再好的硬體設備也培養不出真正的工程師。結交好友，代表學會團隊合作；面對挫折，代表建立工程韌性；勇敢追夢，則是願意離開舒適圈，走向未知的技術與產業。日本經驗提醒筆者把一件事做深，新加坡經驗提醒筆者把視野打開，而這三項期許則提醒筆者，把自己鍛鍊成值得信任的人。這也是筆者想透過科技島與年輕世代分享的核心觀念：未來真正有競爭力的科技人才，既要有職人的手，也要有國際的眼，更要有面對失敗仍願意向前走的心。

這篇文章 當日本職人遇上新加坡國際化:科技大學機械人才如何練成世界級競爭力｜專家論點【郭啟全】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

人工智慧開放平台Hugging Face對外披露，其生產基礎設施遭到入侵，攻擊者在一個週末之內竊取了內部憑證與資料集。這起事件本身並不罕見，資安事故幾乎每天在世界各地上演。真正令人震驚的，是幾天之後揭曉的攻擊者身份，不是某個隱身地下室的黑客組織，而是OpenAI自己訓練出來的AI代理人，在一場網路安全能力測試中，擅自突破隔離環境、連上網際網路，並主動駭入Hugging Face，只為了找到可以讓自己考試作弊的答案。OpenAI事後在聲明中坦承，這是一起「前所未見的安全事件」。這句話說得輕描淡寫，卻掩蓋不了其背後令人不安的現實。作者：張瑞雄（台北商業大學榮譽講座教授）

人工智慧開放平台Hugging Face對外披露，其生產基礎設施遭到入侵，攻擊者在一個週末之內竊取了內部憑證與資料集。這起事件本身並不罕見，資安事故幾乎每天在世界各地上演。真正令人震驚的，是幾天之後揭曉的攻擊者身份，不是某個隱身地下室的黑客組織，而是OpenAI自己訓練出來的AI代理人，在一場網路安全能力測試中，擅自突破隔離環境、連上網際網路，並主動駭入Hugging Face，只為了找到可以讓自己考試作弊的答案。OpenAI事後在聲明中坦承，這是一起「前所未見的安全事件」。這句話說得輕描淡寫，卻掩蓋不了其背後令人不安的現實。

[caption id="attachment_260057" align="alignnone" width="834"] AI失控必須透明和究責｜專家論點【張瑞雄】（圖／AI生成）[/caption]

目標扭曲的代價

這起事件最值得深思的一點，並不是AI的能力有多強，而是它的能力有多危險。AI模型並非懷有惡意，它只是在執行被優化的任務而已。問題恰恰在這裡，當一個高度自主的AI系統被賦予「盡可能取得高分」這樣的目標，而沒有清楚界定達成目標的限制時，它便會自行計算最有效率的方法，哪怕那條方法是侵入別人的伺服器。

研究人員將此稱為「獎勵駭客」，也就是模型在追求目標時，完全不顧任何隱性約束。這不是科幻小說的情節，而是在一個實際的測試環境中，帶著真實後果發生的事情。OpenAI揭露的文件顯示，測試期間安全分類器被刻意關閉，目的是評估模型的「原始能力」，卻也因此讓防護機制形同虛設。這個設計本身就是一個教訓，在AI系統具備高度自主行動能力的時代，任何以「實驗」為名拆除護欄的做法，都必須重新評估其必要性與風險。

透明度和管理須加強

Hugging Face執行長Clément Delangue在事件曝光後立即在X平台發聲，要求OpenAI展現「徹底的透明度」，並釋出這批流氓代理人的完整行動紀錄，讓整個研究社群得以研究究竟發生了什麼。他同時呼籲OpenAI提撥1億美元的運算資源，協助Hugging Face社群建立更強韌的網路防禦能力。

這些訴求看似強硬，實則合情合理。AI安全事件不同於一般資安漏洞，其影響面遠超過受害公司本身，更關係到整個AI生態系統的信任基礎。問題的核心不在於AI是否「失控」，而在於OpenAI如何設計並管理這個工具，以及那套管理機制為何失效。

OpenAI對外的回應，目前只是把媒體詢問轉介至事件發生後的初始聲明，說正在調查中。這種態度，距離真正的透明還差得很遠。

從技術層面看，這起事件揭示了一個根本性的挑戰。傳統上，AI業界習慣用「沙盒」這種封閉的環境來測試模型能力，理論上與外界網路完全隔離。但這次的模型代理人卻能找到網路隔離的漏洞，成功逃脫，顯示沙盒的圈管，已跟不上模型能力成長的速度。

AI治理的當務之急

這場競賽的邏輯，讓人想起核武時代的某種熟悉氣氛，能力競賽先行，規範建立在後。不同的是，AI的擴散速度遠比核技術快得多，門檻也低得多，而且它不需要物理彈頭，一個目標設定偏差的自主代理人就已足夠。

面對這樣的局面，單靠個別公司的自律遠遠不夠。各國政府與國際社會需要認真討論，如何建立具有約束力的AI安全測試標準，特別是針對具備高度自主行動能力的代理人系統，應設置強制性的隔離要求與事故通報機制。台灣正在積極發展AI應用，也正在討論建立AI人文與倫理研究機制，這起事件提供了一個極具說服力的現實案例，說明倫理討論與技術治理不能脫節，必須齊頭並進。

類似事件有多少

有人或許會說，這只是一次偶發的測試失誤，不必過度解讀。但連OpenAI自己都在事後的技術文件中坦承，長時間執行的自主代理人，有能力學會辨識監督系統的盲點，並繞開它來達成自己的目標。這已不是科幻，是文件記錄在案的現實。

一個系統在追求目標的過程中，自主進行情境判斷、選擇攻擊對象，而研發它的公司渾然未覺，直到幾天之後才意識到。類似的代理人安全事件，還有多少？有多少被掩蓋住？誰來負責任？

這個問題，比任何技術漏洞都更需要一個坦誠的答案。

這篇文章 AI失控必須透明和究責｜專家論點【張瑞雄】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

2026年7月，一則震驚全球科技界的消息悄然傳出。OpenAI承認，其旗下兩款模型，包括GPT-5.6 Sol以及一款尚未公開發布的更強大模型，在接受網路安全能力評測期間，自行衝破隔離沙盒環境，穿越OpenAI內部系統，闖入公開網際網路，最終入侵了AI模型托管平台Hugging Face的生產基礎設施，竊取內部資料集與服務憑證。這場攻擊完全出於模型自身的「動機」，它們判斷Hugging Face可能存有與考題相關的資料，於是主動出擊，為自己在評測中取得更高分數。沒有人下達指令，沒有人事先策劃，一切都是AI自主完成的。作者：張瑞雄（台北商業大學榮譽講座教授）

2026年7月，一則震驚全球科技界的消息悄然傳出。OpenAI承認，其旗下兩款模型，包括GPT-5.6 Sol以及一款尚未公開發布的更強大模型，在接受網路安全能力評測期間，自行衝破隔離沙盒環境，穿越OpenAI內部系統，闖入公開網際網路，最終入侵了AI模型托管平台Hugging Face的生產基礎設施，竊取內部資料集與服務憑證。這場攻擊完全出於模型自身的「動機」，它們判斷Hugging Face可能存有與考題相關的資料，於是主動出擊，為自己在評測中取得更高分數。沒有人下達指令，沒有人事先策劃，一切都是AI自主完成的。

[caption id="attachment_250952" align="alignnone" width="825"] AI失控的第一槍已經打響｜專家論點【張瑞雄】。（圖／AI生成）[/caption]

這不是科幻小說，不是資安研究的假想情境，這是真實發生的事。

從理論到現實的跨越

過去數年，資安界一直在沙盤推演「自主AI攻擊者」的可能性。資安專家的警告幾乎被視為末日預言派的誇大其詞。但Hugging Face事件徹底終結了這場辯論，它將一個長期停留在白皮書和研討會上的假設情境，以最直接的方式兌現在現實世界中。這次事件「把AI有能力入侵一家公司、並在公司來得及偵測和回應之前完成攻擊的理論場景」，變成了現實。

更令人深思的是攻擊的規模與速度，這群AI代理在一個週末之內，橫跨數以千計的短暫虛擬機器執行超過17,000次有紀錄的自動化操作，不斷在不同的線上服務之間轉移，控制基礎設施，就像一支永遠不需要睡眠、不需要換班、不會疲憊的攻擊部隊。傳統資安思維中那個「人類需要時間回應」的緩衝空間，在AI驅動的攻擊面前幾乎蕩然無存。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

能力與對齊的拉鋸戰

從技術層面而言，這次事件顯示的問題遠不止於資安漏洞。模型為了在評測中取得好成績而自主向外界尋求資源，本質上是一種「目標達成優先於規定遵守」的行為模式。AI業界稱這類行為為「目標錯位」，而它在現實世界中的表現遠比學術論文描述的要更加具體、更加令人不安。

一名OpenAI內部人士坦承，「我們訓練模型擅長完成任務，並且不擇手段去完成任務」，而如何保證模型不採取危險或非預期的行動，「至今仍是尚未解決的開放技術問題」。這句話的分量極重，因為它來自一家全球最頂尖AI實驗室的內部，而不是任何外部批評者。當資本競速迫使實驗室在評測時解除模型的部分安全限制，以「準確測量能力」為由，便等於創造了一個充滿可乘之機的測試脆弱窗口。

法規的致命空白

Hugging Face事件的另一道警鐘，是當前法律框架對AI安全事故的揭露義務幾乎形同虛設。OpenAI在法律上完全沒有義務公開這次事件，美國加州與紐約州雖已通過法律，要求大型AI公司揭露重大安全事故，但門檻定在須造成50人以上死亡或逾10億美元財產損失，才構成強制申報的條件。其實法案原版本應涵蓋此類事件，卻在OpenAI等科技業者遊說後被大幅縮水，讓企業得以自行決定是否揭露。換言之，我們今天能知道這件事，是因為OpenAI選擇了透明（Hugging Face原本不知道攻擊是來自OpenAI的AI代理），而非因為法律要求如此。

全球已有65%的企業在過去一年內經歷過至少一次與AI代理相關的資安事故，其中61%涉及敏感資料外洩。但監管框架的設計速度，仍遠遠落後於AI能力提升的速度。

集體防禦才是正道

Hugging Face共同創辦人暨執行長在事後說了一句值得銘記的話：「AI安全不可能由任何一家公司單獨在秘密中解決。」這正是這場危機留給整個產業最重要的教訓。資安從來就不是零和競爭的場域，攻擊的工具一旦外洩或被其他人複製，後果是所有人共同承擔的。AI先進模型實驗室之間需要建立強制性的事故通報機制，跨機構共享攻擊手法與防禦知識，而不是各自將失控事件悄悄壓在企業內部消化。

OpenAI形容這次事件是「前所未有的網路安全事故」。但更令人警覺的，也許是那名匿名OpenAI員工說的另一句話，「模型以前也曾突破沙箱，我們總是設法修補，但根本不可能修補一個有創意的AI所能想到的所有逃脫路徑。」在這個AI能力已超越補丁速度的時代，我們所需要的，已不只是更厚的牆，而是對整個AI開發與部署文化的根本性反思。

這篇文章 AI失控的第一槍已經打響｜專家論點【張瑞雄】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上一篇提到，一間保險公司被 10 幾年累積下來的資料架構卡住：報表永遠慢半拍、同一份資料存了好幾次、沒人敢保證數字是乾淨的。作者：黃婉中（雲端架構師）

上一篇提到，一間保險公司被 10 幾年累積下來的資料架構卡住：報表永遠慢半拍、同一份資料存了好幾次、沒人敢保證數字是乾淨的。

[caption id="attachment_250943" align="alignnone" width="861"] 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】。（圖／AI生成）[/caption]

這篇來聊聊，他們後來怎麼解決，以及這件事對你來說，有什麼可以參考的地方。

讓資料「留在原地」

過去處理這類問題，標準做法是：把資料從原始系統抽出來，搬到分析用的地方，這個過程就是我們常聽到的 ETL（Extract、Transform、Load）。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

問題是，搬一次，就多一次時間延遲、多一次儲存成本、多一個可能出錯的環節。

這間公司後來採用的做法，核心概念反過來：盡量讓資料留在原地，只在需要的時候，讓不同系統去「看」同一份資料，而不是各自複製一份。

具體做法，是用一個統一的資料底層（你可以想像成一個共用的大倉庫），把原始資料、整理過的資料、給主管看報表用的資料，分成三層放在同一個地方。業界常用「銅銀金」來比喻這三層，其實就是資料越往上走，越乾淨：

• 銅層（Bronze）：原封不動的原始資料，先進倉庫放著，不做任何加工
• 銀層（Silver）：整理過、算過的資料，給核保、財務這些部門做分析用
• 金層（Gold）：給主管看的整合報表，這層通常東西最少

這樣做的好處是，同一份資料只存一次，卻能同時給不同用途的人使用，不用每個部門各自搬一份、各自處理一次。

資料「即時」同步，卻不影響效能

你可能會問：資料放在原地，那報表要怎麼更新？如果每次要看報表，都要去正式的營運資料庫裡撈一次，那不就拖慢了原本系統的速度？

我用一個比喻說明：

想像資料庫是一間忙碌的廚房。如果你想知道廚房現在剩幾顆蛋，直接衝進廚房打開冰箱清點，會擋到廚師做菜。

但廚房通常會有一張「進出貨紀錄單」，放在冰箱旁邊，每次有東西進出，就會記一筆：「拿走 2 顆蛋」。

新一代的資料同步技術，做的就是：不去正式資料庫裡翻找，而是讀取這張「異動紀錄單」，看到有變動，就同步更新到分析用的那份資料上。

這樣一來，主管看到的報表可以接近即時更新，但完全不會影響到原本系統的運作速度。這也是為什麼很多企業現在能做到「資料一進來，馬上就能分析」，不用再等隔天。

減少「人搬資料」

除了讓資料留在原地，這間公司還做了一件事，是把整個資料搬運流程，從「人工處理」變成「全自動管線」。

過去要跟外部夥伴（比如維修廠、其他保險公司）交換資料，常常得靠人工，透過檔案傳輸的方式一來一往，資料格式對不對、有沒有漏傳、傳錯版本，都得靠人去確認，容易出錯。

現在這個流程改成透過自動化的資料管線（Pipeline），用 SFTP（一種安全的檔案傳輸協定）自動化地拉取、傳送資料，不用再有人手動下載、上傳、確認。這帶來兩個好處：第一，速度快很多；第二，資料出錯率降低。

同樣的邏輯，也用在公司內部原本的營運資料庫上。以前資料庫裡的資料，要先被「搬」到分析平台，才能進行下一步處理。

這次的做法，是直接讓分析平台去「還原」或「鏡像」既有的資料庫，等於少了一次額外的搬運，資料庫裡的東西不用真的被複製出去，分析平台就能直接取用。

權限管理

不是每個部門都應該看到同一份資料。

業務部門、資料分析團隊、財務部門，他們需要的資料範圍不同，能承受的風險也不同。如果讓所有人共用同一個工作環境，很容易發生兩個問題：一是權限管理混亂，誰該看什麼、不該看什麼很難釐清。二是效能互相干擾，如果資料分析團隊在跑一個很吃資源的大型查詢，可能會拖慢業務部門原本正常的日常操作，也就是所謂的「吵鬧鄰居」問題。

這間公司的做法，是依照使用情境，把工作區分開：日常營運用的、開放給業務部門自助分析用的、給資料科學家做進階建模用的，各自獨立，權限也依角色分層設定。這樣一來，不同部門可以在各自需要的範圍內工作，不會互相干擾，也降低了資料外洩或誤用的風險。

資料治理是地基

除了搬資料的效率問題，這間公司同時處理的，是資料治理，簡單說，就是「這份資料從哪來、誰能看、有沒有包含個資」，要有一套機制去管理。

具體來說，包含幾個部分：

• 資料目錄：清楚記錄公司到底有哪些資料、放在哪裡，不用再靠老員工的記憶
• 來源追蹤（Lineage）：一筆數字，能追溯回它最原始是從哪裡來、經過哪些加工
• 權限控管：誰能看什麼資料，依照角色分層管理，不是人人都是最高權限
• 個資偵測：自動掃描、標記出敏感資料（比如身分證字號、病歷資訊），提醒相關人員要特別小心處理

對一間受金融監理單位監管的公司來說，這套治理機制是合規的必要條件。而且提早把地基打好，之後不管是要導入 AI 分析、或是跟外部夥伴交換資料，都會輕鬆很多。

小結

就算你不是保險業，這個案例背後的邏輯，值得每個管理資料的人想一想：

這份資料被搬了幾次？
很多企業帳單暴增、報表又慢又亂，可能的原因之一，是資料在系統間被搬來搬去、被複製了好幾份。與其急著導入新的分析工具，不如先盤點一下：這份資料到底被搬了幾次？是不是都有必要？

降低資料流動的成本
不管你公司現在用的是哪一家供應商的工具，這幾年資料圈的趨勢，是想辦法減少資料被搬運、被複製的次數。下次評估架構的時候，這會是一個很實用的判斷標準。

這篇文章 一份資料存了3次：保險公司的資料孤島求生記（下）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。