GDPR 與文件：關於上傳 PDF，法律是怎麼說的

你把一張發票拖進一個免費的線上工具想把它縮小。上面有客戶的姓名、一個地址，也許還有一組統一編號。五秒鐘後你得到一個更小的檔案，然後就繼續忙別的。剛剛有發生什麼跟法律有關的事嗎？

在 GDPR 之下，很可能有。而大多數人從來沒想過這件事，因為那份文件看起來人畜無害，而那個工具看起來免費。

這不是法律意見。我不是你的律師，每種情況都有自己的細節。但這套規則的輪廓值得理解，因為它會改變你該如何處理那些含有他人資料的文件。

GDPR 所稱的「處理」

人們以為 GDPR 講的是資料庫和行銷名單。實際的定義要寬廣得多。處理幾乎是你對個人資料所做的任何事：蒐集、儲存、讀取、變更、分享、刪除。這項法規甚至明文把「查閱」和「使用」列為處理的形式。

所以當你的 PDF 含有個人資料（一個姓名加一組電話號碼就已經足夠），而你又對那個檔案做了某件事，你就是在處理個人資料。壓縮它算。合併它算。轉檔它算。

光是這一點還不算問題。企業整天都在處理個人資料。GDPR 要問的是你「怎麼」做，以及沿途「還有誰」碰過那份資料。

為什麼上傳會牽扯進一個「處理者」

這正是雲端那部分要緊的地方。當你把那張發票上傳到一個外部服務時，檔案就脫離了你的掌控，落到別人的伺服器上。那家公司現在代表你處理那份個人資料。GDPR 給他們一個名字：處理者（processor）。而你，那個決定這麼做的人，則是控制者（controller）。

一旦牽扯進處理者，控制者就會背上實實在在的義務。最重要的是第 28 條：你需要和那個處理者簽一份書面合約，通常稱為資料處理協議（Data Processing Agreement）。它必須載明他們可以對資料做什麼、如何保護它、何時刪除它，以及他們能不能再把它交給別人。

停下來想想你上個月用的那個免費 PDF 工具。你有跟他們簽 DPA 嗎？你有讀過他們的伺服器位在哪裡嗎？你有查過他們的次處理者是誰嗎？幾乎肯定沒有。你把一個含有他人個人資料的檔案，上傳給了一家你毫無合約關係的公司。這就是那道缺口。

跨境傳輸的陷阱

當伺服器位在歐盟之外時，事情會變得更棘手。把個人資料送到另一個國家的供應商，是一次傳輸，而 GDPR 對這類傳輸有所限制。你需要一個有效的法律依據，例如標準契約條款，或針對那個國家的適足性認定。

大多數免費工具不會告訴你它們在哪裡執行。檔案可能在另一個大陸的資料中心被處理、被推進佇列、被暫存在儲存空間裡，而你毫無辦法得知。對一張私人度假照片來說，沒問題。但對一份滿是客戶資料的合約來說，你已經悄悄做了一次自己無法佐證的跨境傳輸。

最小化，那個人人都忘記的原則

GDPR 有一個叫做資料最小化的原則。你應該只處理你真正需要的個人資料，並以侵擾最小的方式進行。還有一個相關的原則：在設計一套流程時就要考慮隱私，而不是事後才考慮。

把這套用在像壓縮 PDF 這樣簡單的工作上。你需要為了把一份客戶合約縮小，就把它送到第三方伺服器嗎？不需要。壓縮可以在你自己的機器上完成。把它送出去，就多了一個處理者、一份你沒有的合約，也許還多了一次你無法正當化的傳輸——而這一切只是為了改變一下檔案大小。這正好是最小化的反面。

為什麼本機端處理能避開大部分問題

這正是讓整個問題變小的部分。如果檔案從未離開你的裝置，就沒有第三方在處理它。沒有處理者，就沒有第 28 條的合約要追。沒有任何東西跨越邊界，所以也沒有需要正當化的傳輸。你仍然是控制者，仍然欠當事人應有的謹慎，但一大塊文書工作就是不適用了，因為沒有別人碰過那份資料。

這就是那些完全在你瀏覽器中運作的工具背後的構想。程式碼在本機端、在你電腦的記憶體裡完成工作，你的 PDF 原地不動。這就是我們打造 reader.me 的方式。當你 壓縮 PDF 時，檔案是在你的瀏覽器裡處理的，從不會抵達我們的任何伺服器。打開你瀏覽器的 DevTools，盯著 Network 分頁，你就能確認沒有任何含有你文件的東西被送出去。

給企業與自由工作者的實用步驟

幾個能讓你站在對的一邊的習慣：

• 把任何含有姓名、證件號碼或聯絡方式的文件都當成個人資料。 發票、合約、履歷和醫療表單全都算。
• 在把任何東西上傳到雲端工具之前，先問處理者是誰。 沒有 DPA、對伺服器位置沒有明確答案？那就別讓客戶資料經過它。
• 對於壓縮、合併或分割這類例行工作，預設使用本機端工具。 如果它能在你的瀏覽器裡執行，就沒有處理者需要審查。
• 保留一份簡短紀錄，記下哪些服務碰過個人資料。GDPR 本來就期待控制者知道這件事。
• 當你確實需要一項雲端服務時，挑一個提供真正 DPA 的，並且會告訴你資料存放在哪裡。

這些規則聽起來很沉重，但日常的解法很輕。大多數 PDF 工作根本不需要伺服器。把檔案留在你的機器上，那麼大部分的法律重擔，從一開始就不會落到你身上。