朋友都問我「客訴資料放 LINE 安全嗎」，我的答案不是「我很小心」

先回答那個所有人都會問的問題

我們公司沒有 IT 部門。這些系統不是部門交付的專案，是我一個財務，利用下班時間跟訂閱額度內的 AI，一套一套蓋出來的。它們全都要碰公司資料：客訴內容、客人聯絡方式、員工身分。

每次跟人聊到這件事，對方第一句話幾乎都是同一個：

「把客訴、員工資料放進 LINE 機器人，安全嗎？」

很多人聽到 LINE 就倒退，直覺認為這是個充滿貼圖跟遊戲分享的地方，怎麼可以放企業資料。

我的答案可能跟你想的不一樣。我不是說「我很小心」，我是說：我根本沒把身份權限交給 bot 自己管。

一般人的直覺是：把資料放進系統，就要自己建一套帳號系統、自己設角色、自己維護密碼。連資安工程師寫的部落格都是這樣教的。

但我不是工程師，我連帳號系統都不想維護。我只做了一件事——不自己建帳號系統，直接借 LINE 的群組結構當權限系統。

LINE 本身就是身份系統。誰在哪個群組、誰不在哪個群組，LINE 早就替我管好了，而且隨時在更新。我要做的不是重造一個身份系統，是去讀它。

三套系統，同一套哲學。差別只在於，各自的防護要做到多嚴。

客訴是最敏感的資料，所以這套我做最嚴，分三層：

第一層，鎖群組。 客訴助理已經與 BI 嫁接，只有店長可以進 BI。

第二層，分店阻隔。 門店同仁有回覆、查詢的需求，但他們只能看到自己店的事。門店群組裡的客訴助理，只回覆該門店的客訴——時間、內容。讓大部分同仁知道情況、做檢討。

第三層，個資分級。 營運管理群組才會收到完整資料：全門店、客人、聯絡方式、時間、內容。讓門店營運主管（店長、副店長）方便處理、追蹤。

注意看，是同一支 bot、不同群組，給不同詳度的資料。這不是「要不要鎖」的問題，用我常講的一句話說：

「不是『要不要鎖』，是『每個人看到他該看的層級』。」

這些設計，全是在上線前就想好的，不是出事之後才補。個資這種東西，出事再補，就來不及了。

聽到這裡你可能會問：既然沒有 IT 部門，這些權限交給 HR 維護不就好了？

我算過一筆帳。餐飲業人員流動極快，今天這個店長離職，明天那個門店換了三個新人。如果權限綁在一份名冊上，每個禮拜都要催人更新——而這是給 HR 加工作。

「我不可能指望 HR 來卡權限，那只會讓 HR 翻臉而已。」

這句不是氣話，是實話。真正上線的系統，不能建立在一份永遠過期的名冊上。權限必須跟身份源自動連動，而 LINE 的群組就是那個一直活在當下的身份源。

BI 戰情室是另一套做法，嚴格程度介於中間。

它是一個串 LINE bot 的網站。要進去，必須登 LINE；登完系統會檢查，你是不是在高管群組裡，不是就擋掉。

目的很單純：高管也不愛用系統，這個鎖讓我敢把資料攤開給他們看。鎖住高管群組之後，還多一個好處——可以推送戰情卡片，一種每日總結的概念。早上醒來看一眼 LINE，今天的戰況就結束了。

Learning Hub 最輕，因為它是內部培訓，不碰客人個資。但員工身分一樣要驗。

登入時，先綁定（員編＋身分證後 4 碼）確認身分。之後權限不用特別設定，系統直接拿 LINE userid 去驗證：這個人還在不在公司全員群組。

有，就是在職；沒有，就是離職。離職自動失效。

「有 = 在職，沒有 = 離職。」

這套我一開始就想到，理由跟客訴系統一樣：人員流動快速，更新名冊會很痛苦。與其維護名冊，不如讓 LINE 群組自己當名冊。人走了，群組踢掉了，權限自然就沒了，不用任何人記得去做。

你一定會想，我是不是也曾想過自己建一套權限系統？想過。

但建了要維護，維護要花時間。我所有的判斷標準只有一條：會增加工作的一律避免。權限系統如果每個月都要有人去清名冊、修帳號，那它就變成另一份永遠做不完的工作。

「程式替我們工作，而不是我們替 AI 工作。」

這個原則不只適用在權限上，也適用在我所有系統的每個環節。能交給 LINE 自己管的，就不自己造；能自動跟隨的，就不人工維護。省下來的力氣，才拿得去做真正重要的判斷。

回頭看，三套系統三種嚴格程度，背後是同一件事。

客訴助理，把最敏感的個資鎖在主管群組，同仁只看自己店的概況。BI 戰情室，用高管群組把資料關在決策層裡。Learning Hub，用群組在職名單，讓離職的人自動失去一切。

不是堆疊愈多技術愈安全，而是讓對的人，在對的地方，看到對的資料。身份由 LINE 管，分層由群組定，我的 bot 只負責一件事——照群組給答案。

這就是我對「安全嗎」三個字的回答。把風險想清楚了，系統才敢上線。