荷蘭資料保護局：Google隱私權政策違反該國資料保護法
荷蘭資料保護局（Data Protection Authority, DPA）歷經長達七個月的調查，於2013年11月28日發布新聞稿，聲明Google違反該國資料保護法，因其未適當告知用戶他們蒐集了什麼資料、對資料做了些什麼事。
DPA主席Jacob Kohnstamm表示：「Google在未經你我同意的情形下，對我們的個人資料編織了一張無形的網，而這是違法的。」調查報告援引了Google執行長Eric Schmidt在2010年一場訪談中所說的話：「你不用鍵入任何字，我們知道你正在什麼地方、去過什麼地方，甚至或多或少知道你在想些什麼。」。
調查顯示Google為了展示個人化的廣告及提供個人化的服務，而將不同服務取得的個人資料加以合併，如搜尋記錄、所在位置及觀看過的影片等。然而，從用戶的觀點來看，這些服務係基於全然不同的目的，而Google亦未事先提供用戶同意或拒絕的選項。依照荷蘭資料保護法的規定，Google合併個人資料前，應經當事人明示同意，而該同意無法藉由概括（隱私）服務條款取得。針對DPA的聲明，Google回應他們已經提供用戶詳細資訊，完全符合荷蘭法律。
DPA表示將通知Google出席聽證會，就調查結果進行討論，並決定是否對Google採取強制措施。但是，從Google的回應看來，他們不太可能在聽證過後改變心意。以先前Google街景車透過Wi-fi無線網路蒐集資料的案例為鑑，Google（市值達3500億美元）若繼續拒絕遵循，將有可能面臨高達1佰萬歐元的罰鍰。
- Dutch Authorities Find Google Violates Its Private Data Protection Act
- Google's privacy policy violates Dutch data protection law, Dutch DPA says
- Google Under Fire From Dutch Data Protection Authority
- Dutch DPA Concludes That Google Is in Breach of Data Protection Act
- Dutch data protection agency says Google is violating privacy laws
- Google privacy changes break Dutch data protection law, says regulator
- Google violated Dutch data protection laws, says watchdog
- Dutch DPA: privacy policy Google in breach of data protection law
美國第9巡迴上訴法院(9th Circuit)於2015年7月6日對外宣布Multi Time Machine v. Amazon案的見解，其推翻地方法院看法，認定被告Amazon公司提供的服務有侵害原告Multi Time Machine公司商標權之虞。 本案原告Multi Time Machine公司是一家製作手錶的廠商，在被告Amazon公司的網站上有提供零售服務。原告認為被告網站提供之服務，可使消費者搜索網站內的物品，但其所得之結果(含圖片)卻容易令人混淆，如搜尋原告的MTM手錶(為Multi Time Machine之商標)，會將商標權人及其他廠商的商品都包含在內，導致消費者誤認為其他廠商手錶也是由MTM製造，進而購買非原告公司生產之手錶。原告因而向地方法院提出訴訟，認為被告Amazon公司侵害其商標權，違反聯邦法典內之Lanham Act的第1114條(1)(a)及第1125條(a)(1)規定。但洛杉磯地方法院認為被告行為並未侵害商標權，原告不服故提起上訴。 第9巡迴上訴法院採用1979年AMF v. Sleekcraft Boats案認定之方式，並於2011年Network Automation v. Advanced System Concepts案後發展出的測試標準，用以判斷有無侵害商標權。其標準包含：1.商標的強度、2.商品近似或相關連程度、3.與商標的相似性、4.實際混淆之證據、5.銷售管道、6.消費者在意程度、7.被告意圖、8.擴展之可能性。上訴法院認為，本案除了3、5、8三項較無關外，其餘5項因素經法院研究結果，原告商品在被告網站上販售時，1、2、7於原告影響較大，而4、6是被告提供服務(即供消費者購買)時須在意的。因此，綜合判斷之結果，被告行為已可能侵害原告之商標權，故推翻地方法院之判決結果，發回地方法院續行審理，本案後續判決進展及結果實值持續觀察。
美國OMB發布M-26-04備忘錄，確立聯邦採購之「無偏見原則」與透明度義務美國白宮管理與預算辦公室（Office of Management and Budget，以下簡稱OMB）在2025年12月11日發布M-26-04備忘錄（以下簡稱本指引），目標是落實第14319號行政命令「防止聯邦政府中的覺醒AI」（Preventing Woke AI in the Federal Government）。本指引闡述「追求真相」（Truth-seeking）、「意識型態中立」（Ideological Neutrality）兩大「無偏見AI原則」（Unbiased AI Principles），並強制要求聯邦機構在採購大型語言模型（LLM）時，必須將此二原則納入合約條款。 為確保符合規定，本指引要求聯邦機構在進行採購時，應避免強制供應商揭露過於敏感的技術資料（如模型權重），而是採取以下兩層級的資訊揭露架構： 1. 基本透明度要求（Minimum Threshold for LLM Transparency） 各機構於招標階段，應要求供應商提供以下資訊： (1) 可接受的使用政策：界定產品適當與不適當用途的文件。 (2) 模型、系統和/或資料的摘要卡（Model, System, and/or Data Cards）：包含訓練摘要、風險緩解措施及基準測試評分。 (3) 終端用戶資源與意見回饋機制：包含用戶教程及針對違反無偏見原則產出的回報管道。 2. 強化透明度門檻（Threshold for Enhanced LLM Transparency） 若機構擬將模型整合至其他軟體或服務中，則需獲取更深入的開發與運作資訊，例如： 1. 預訓練和後訓練（Pre-Training and Post-Training）：如影響產出事實性（factuality）的活動、系統提示詞（System Prompts）、以及內容審查過濾器的具體運作。 2. 模型評估：針對政治議題的偏見測試結果與方法論。 3. 模型中嵌入的企業控制（Enterprise-Level Controls）: 如可客製化的系統指令或來源引用功能。 4. 第三方對模型的修改：非原廠開發者所施加的額外控制層。 本指引對聯邦行政機構具有行政拘束力。機構必須於2026年3月11日前更新採購政策，並將上述要求納入新舊合約中。值得注意的是，本指引引入了「實質性要求」（Materiality Requirement），即若供應商拒絕針對違反無偏見原則的產出採取糾正措施，將構成合約違約之重要事由，機構得據此終止合約。 觀察美國OMB此次發布的內容，係透過將「意識形態中立」轉化為具體的採購合規要件，OMB利用聯邦政府龐大的購買力，在採購合約中確立供應商的「透明度義務」，OMB指引不僅建立了明確的法遵標竿，更可能發揮示範效應，將政府端的無偏見規範逐步推廣至私營部門，轉化為產業的最佳實踐標準。
英國資訊委員辦公室（Information Commissioner’s Office，ICO）認定英國電子零售業者Carphone Warehouse違反《Data Protection Act 1998》資料保護法英國電子零售業者Carphone Warehouse在2015年遭到網路攻擊，造成逾300萬客戶及1000名員工的資料外洩，外洩的資料包括客戶的姓名、地址、電話號碼、出生日期、婚姻狀況及1.8萬名客戶的金融卡資訊。 英國資訊委員辦公室（Information Commissioner’s Office，ICO）認為涉及之個人資料嚴重影響個人隱私，使得個人資料有被誤用的風險。ICO進一步調查後並發現，駭客僅是透過有效的登入憑證，就能藉由WordPress軟體存取系統，此事件亦暴露該組織技術安全措施之不足，因受影響系統中使用的軟件的重要元素已過時，且公司未能執行例行的安全測試。ICO認為，像Carphone Warehouse此類規模龐大的公司，應積極評估其資料安全系統，確保系統穩健而避免類似的攻擊。 據此，ICO判定該公司缺乏妥善的安全措施保障使用者資訊，已嚴重違反《Data Protection Act 1998》資料保護法，判罰40萬英鎊。 從今年5月25日起，隨著GDPR的生效，法律將更加嚴格。對此，ICO亦發布了有用的指導，包括GDPR指南，現在採取的12個步驟和工具包。國家網絡安全中心（NCSC）也為組織為保護自己所採取的步驟提供了有用的指導。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（National Security Agency, NSA）於2022年11月10日發布「軟體記憶體安全須知」（“Software Memory Safety” Cybersecurity Information Sheet），說明目前近70%之漏洞係因記憶體安全問題所致，為協助開發者預防記憶體安全問題與提升安全性，NSA提出具體建議如下： 1.使用可保障記憶體安全之程式語言（Memory safe languages）：建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言，以取代C與C++等無法保障記憶體安全之程式語言。 2.進行安全測試強化應用程式安全：建議使用靜態（Static Application Security Testing, SAST）與動態（Dynamic Application Security Testing, DAST）安全測試等多種工具，增加發現記憶體使用與記憶體流失等問題的機會。 3.強化弱點攻擊防護措施（Anti-exploitation features）：重視編譯（Compilation）與執行（Execution）之環境，以及利用控制流程防護（Control Flow Guard, CFG）、位址空間組態隨機載入（Address space layout randomization, ASLR）與資料執行防護（Data Execution Prevention, DEP）等措施均有助於降低漏洞被利用的機率。 搭配多種積極措施增加安全性：縱使使用可保障記憶體安全之程式語言，亦無法完全避免風險，因此建議再搭配編譯器選項（Compiler option）、工具分析及作業系統配置等措施增加安全性。