車聯網資料要怎麼合規做 AI?座艙與售後資料的個資與資安框架

車聯網 AI 合規,是指在導入 AI 之前,先確認每一筆座艙與售後資料的蒐集、告知、去識別、傳輸與存取,都能對應到《個人資料保護法》的特定目的、以及車輛網路安全法規(如 UN R155、ISO/SAE 21434)的控管要求,讓「這筆資料能不能餵給模型」成為一個可判斷、可稽核的決定,而不是一句「應該可以吧」。

先講一個真實的場景。去年我們接一家車廠的售後智慧客服案子,客戶很興奮,說車機裡有三年份的行車與語音資料,「全部丟進去做個 Copilot」。我請工程師拉了一份資料清單出來,結果第一頁就卡住:座艙麥克風收到的不只是車主指令,還有後座乘客的對話、甚至導航講出來的住家地址。這些資料當初的蒐集告知,只寫了「為提供語音助理服務」。你要拿它訓練一個會被客服人員查詢的模型,特定目的對不上,這在個資法上就是外之利用。

Demo 很美不算數。能上線、而且不會在稽核時爆掉,才算數。

車聯網 AI 合規到底在管什麼

很多團隊把合規想成「資安做好加密就沒事」,這是誤解。車聯網 AI 合規其實同時被兩套邏輯夾住:一套是個資,管的是「這筆關於人的資料,你有沒有權利這樣用」;另一套是車輛網路安全,管的是「資料在傳輸與系統之間,會不會被竄改或外洩」。前者的主管邏輯來自個資法與 GDPR,後者則對應 UN R155/R156 與 ISO/SAE 21434。

兩者的交集,正是 AI 最想吃、也最危險的那塊資料——座艙裡的語音影像、駕駛行為、生物特徵;售後端的維修紀錄、車主聯絡方式、精確定位軌跡。這些資料的商業價值最高,敏感度也最高。合規不是要你別碰,而是要你分清楚哪些能直接用、哪些要處理過才用、哪些根本不該進模型。

先把資料分層:座艙與售後不是同一件事

我們的做法是,進場第一週不寫任何一行 AI 的程式碼,先做資料盤點。座艙資料的特性是「即時、密集、含旁人」——駕駛沒辦法幫後座乘客同意,所以語音與影像通常要在邊緣端就做去識別,原始檔不上雲。售後資料的特性則是「跨系統、可連結」——維修單、保固、CRM 一旦串起來,單獨看不敏感的欄位組合起來就能還原到特定車主,這叫重新識別風險,是最容易被忽略的雷。

分層之後,判斷才有依據。

一個可以照著跑的判準框架

我們內部用一張表決定「這筆資料能不能進 AI、要怎麼進」。它不完美,但能讓法務、資安、工程三方在同一張紙上對話,而不是各說各話。

這張表的重點不在欄位本身,而在最右邊那兩欄:大多數「不能用」的資料,經過去識別、假名化或聚合之後,其實是「處理過就能用」。合規的價值不是把門關上,是幫你找到那扇開著的門。

我們踩過的雷,先講給你聽

第一個雷是「同意範圍」。車主當初按下的那個同意,往往只涵蓋原本的功能,不涵蓋拿去訓練模型。補救方式不是回頭重新要一次同意（實務上回收率低到沒意義),而是設計去識別流程,讓資料脫離「個人資料」的定義,就不再受原同意範圍限制。

第二個雷是「假名化不等於匿名化」。假名化的 VIN 只要對照表還在,法律上仍是個資。我們會把對照表放進獨立、受存取控管的系統,和模型環境物理隔離。

第三個雷最隱形:向量資料庫。RAG 系統把售後文件切塊嵌入後,很多人以為原文被「打散」就安全了,其實嵌入向量可以被反推出敏感內容。所以敏感欄位要在進入向量庫之前就處理掉,而不是事後補。

合規做得好,AI 才跑得久。這也是為什麼我們接車用案子時,會派前線部署工程師和客戶的法務、資安坐在同一個房間裡,把上面這張判準表逐列填完再動工——因為讓一套系統真正上線、而且經得起稽核,從來不是模型的問題,是有沒有人願意在現場把這些髒活扛完的問題。