<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>PDPA on YJ-OnLine</title>
    <link>https://www.yjho.me/tags/pdpa/</link>
    <description>Recent content in PDPA on YJ-OnLine</description>
    <generator>Hugo -- 0.146.0</generator>
    <language>zh-TW</language>
    <lastBuildDate>Fri, 01 May 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.yjho.me/tags/pdpa/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>當 AI 開始面</title>
      <link>https://www.yjho.me/dp_column/2026-05-01_%E5%B0%B1%E6%A5%AD%E9%9A%B1%E7%A7%81%E8%88%87ai%E8%87%AA%E5%8B%95%E5%8C%96%E6%B1%BA%E7%AD%96%E5%90%88%E8%A6%8F/</link>
      <pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate>
      <guid>https://www.yjho.me/dp_column/2026-05-01_%E5%B0%B1%E6%A5%AD%E9%9A%B1%E7%A7%81%E8%88%87ai%E8%87%AA%E5%8B%95%E5%8C%96%E6%B1%BA%E7%AD%96%E5%90%88%E8%A6%8F/</guid>
      <description>&lt;p&gt;場景一：你在人力銀行投了履歷，系統幾秒後回覆：「感謝您應徵，此職缺已找到合適人選。」你不知道的是，這份履歷可能從來沒有被任何人類看過。招募系統已經根據學歷、工作經驗、語意特徵，甚至履歷中的空白期與用字模式，替你打了分數，然後把你的檔案歸類到「不優先考慮」。&lt;/p&gt;
&lt;p&gt;場景二：你任職的公司上線了一套新的「智慧考勤系統」，用臉部辨識取代傳統打卡鐘。人力資源部門說這是「提升效率」。但沒有人清楚說明，影像資料會不會被上傳到雲端、供應商位於哪個國家、臉部特徵模板會保存多久，或者離職後是否會刪除。&lt;/p&gt;
&lt;p&gt;場景三：公司引進 AI 績效評估系統，每週根據鍵盤輸入節奏、會議參與率、電子郵件回覆速度與任務系統紀錄，自動計算「組織貢獻指數」。你的年終獎金、晉升機會，甚至是否被列入改善名單，都可能受一個你從未看過、也難以挑戰的模型影響。&lt;/p&gt;</description>
    </item>
    <item>
      <title>台灣跨國企業的跨境傳輸合規全景</title>
      <link>https://www.yjho.me/dp_column/2026-04-29_%E8%B7%A8%E5%A2%83%E5%82%B3%E8%BC%B8%E5%90%88%E8%A6%8F%E5%85%A8%E6%99%AF/</link>
      <pubDate>Wed, 29 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://www.yjho.me/dp_column/2026-04-29_%E8%B7%A8%E5%A2%83%E5%82%B3%E8%BC%B8%E5%90%88%E8%A6%8F%E5%85%A8%E6%99%AF/</guid>
      <description>&lt;p&gt;某個下午，台北總部收到中國子公司的資安通報：內部人力資源（Human Resources, HR）系統疑似遭入侵，受影響資料包含台灣派駐人員、中國當地員工，以及少量歐洲子公司借調員工資料。&lt;/p&gt;
&lt;p&gt;這時候，問題不只是「要不要通知當事人」。法務、資安與人資很快會被一串更麻煩的問題追著跑：中國子公司把員工資料同步回台灣，是不是符合中國《個人信息保護法》（Personal Information Protection Law, PIPL）的資料出境規則？歐洲借調員工資料曾經傳到台灣總部，當時有沒有歐盟《一般資料保護規則》（General Data Protection Regulation, GDPR）的傳輸工具？台灣母公司把資料放在新加坡雲端區域，是否觸發新加坡《個人資料保護法》（Personal Data Protection Act, PDPA）或其他供應商所在地的要求？如果外洩發生在跨國系統，通報時鐘要從哪一個法域開始算？&lt;/p&gt;</description>
    </item>
    <item>
      <title>個資事件調查，不是出事後才開始</title>
      <link>https://www.yjho.me/dp_column/2026-04-23_%E5%80%8B%E8%B3%87%E4%BA%8B%E4%BB%B6%E8%AA%BF%E6%9F%A5%E4%B8%8D%E6%98%AF%E5%87%BA%E4%BA%8B%E5%BE%8C%E6%89%8D%E9%96%8B%E5%A7%8B/</link>
      <pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://www.yjho.me/dp_column/2026-04-23_%E5%80%8B%E8%B3%87%E4%BA%8B%E4%BB%B6%E8%AA%BF%E6%9F%A5%E4%B8%8D%E6%98%AF%E5%87%BA%E4%BA%8B%E5%BE%8C%E6%89%8D%E9%96%8B%E5%A7%8B/</guid>
      <description>&lt;p&gt;很多企業把「個資事件調查」想成危機發生後的補救程序：先止血、再寫報告、最後交代。&lt;br&gt;
但在實務上，真正決定事件損害大小的，往往不是你出事後有沒有寫出漂亮報告，而是你出事前有沒有把調查機制設計進日常治理。&lt;/p&gt;
&lt;p&gt;事故辨識與分級、證據保全、根因分析、通報決策、改善落地。這些能力如果只在事故當天才臨時啟動，通常都太晚。&lt;/p&gt;
&lt;!-- more --&gt;
&lt;h2 id=&#34;一多數組織卡在形式合規&#34;&gt;一、多數組織卡在「形式合規」&lt;/h2&gt;
&lt;p&gt;在台灣脈絡下，個資治理正從形式合規走向實質治理。差別在於：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;形式合規：文件齊全、稽核紀錄完整，但事件來時角色混亂&lt;/li&gt;
&lt;li&gt;實質治理：DPO、專責人員、查核人員分工明確，事故處理能即時運轉&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;也就是說，制度有沒有「被用」比制度有沒有「存在」更重要。&lt;/p&gt;
&lt;h2 id=&#34;二真正的壓力測試在前-4-小時&#34;&gt;二、真正的壓力測試在前 4 小時&lt;/h2&gt;
&lt;p&gt;以常見情境為例：離職人員疑似帶走客戶資料，並在競業環境使用。這時候最常出現的不是技術問題，而是治理問題：&lt;/p&gt;</description>
    </item>
    <item>
      <title>當處理者成為漏洞：跨國供應鏈個資治理的現在與未來</title>
      <link>https://www.yjho.me/dp_column/2026-04-21_%E8%99%95%E7%90%86%E8%80%85%E6%B2%BB%E7%90%86%E8%B7%A8%E5%9C%8B%E4%BE%9B%E6%87%89%E9%8F%88%E5%80%8B%E8%B3%87%E9%A2%A8%E9%9A%AA/</link>
      <pubDate>Tue, 21 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://www.yjho.me/dp_column/2026-04-21_%E8%99%95%E7%90%86%E8%80%85%E6%B2%BB%E7%90%86%E8%B7%A8%E5%9C%8B%E4%BE%9B%E6%87%89%E9%8F%88%E5%80%8B%E8%B3%87%E9%A2%A8%E9%9A%AA/</guid>
      <description>&lt;h2 id=&#34;一個常被忽略的洩漏環節&#34;&gt;一個常被忽略的洩漏環節&lt;/h2&gt;
&lt;p&gt;2025 年，某家台灣半導體供應商的雲端資料處理者遭到勒索軟體攻擊，數萬筆客戶訂單與員工身份資料外洩。事後調查發現：這家處理者同時替十幾家台灣企業處理資料，但沒有一家控制者曾在合約中約定「處理者事故發生後的通報時效」——導致多數母公司是在新聞報導後才得知，而非依賴處理者的正式通知。&lt;/p&gt;
&lt;p&gt;這不是個案。在個人資料管理系統（Personal Information Management System, PIMS）中，處理者（Processor）治理是最容易被空洞化的環節：合約裡寫得完整，實際上卻從未執行。當事故發生，監理機關裁罰的對象是控制者（Controller），而非處理者。處理者的過失，最終由控制者承擔。&lt;/p&gt;
&lt;p&gt;本文以 2026 年初的研究發現為基礎，深度解析：處理者治理的七個強制條款、各國制度差異、為何多數企業的處理者稽核形同虛設，以及台灣跨國企業該如何建立可執行的處理者治理系統。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
