美國紐約南區聯邦地方法院(S.D.N.Y.)於2022年7月15日駁回了臨床試驗軟體公司Medidata Solutions Inc. (以下簡稱Medidata公司)控告競爭對手Veeva Systems Inc. (以下簡稱Veeva公司)竊取其營業秘密的請求。
原告Medidata公司於2017年1月指控被告Veeva公司陸續挖角其數名離職員工,部份員工離職時私自拷貝公司檔案,其中包含原告的產品研發、商業策略等營業秘密,而被告根據這些資訊開發了和原告相似的軟體,造成其重大損害,因此向被告請求4.5億美元的損害賠償。
被告Veeva公司抗辯雖然這些員工離職時私自保留原告的檔案,但原告在訴訟中並未明確說明哪些屬於該公司的營業秘密,亦即未特定營業秘密標的;此外,即便這些離職員工自行保留的檔案中有包含原告所稱之營業秘密,但原告提出的證據不足以證明被告有不當取用(misappropriation)其營業秘密,僅根據被告有僱用原告離職員工等事實,即推論被告有不當取用。原告試圖透過此模糊和毫無根據的主張,限制產業的創新、競爭、人才流動。
本案歷經五年的纏訟,法院最終駁回原告請求。法官指出,原告在整個訴訟過程中並未明確定義哪些資訊屬於營業秘密,原告似乎認為任何資訊皆屬於其營業秘密,這樣的主張無異於代表任何公司永遠無法挖角其他公司的員工,因為這些員工到新公司任職後所說的任何話,都會間接地揭露他們在之前工作中所學習到的事情,因此駁回原告之訴。
從本案可以觀察到,企業應定期盤點公司內部資訊,明確界定營業秘密範圍,並落實管理及妥善留存相關證據,發生侵害營業秘密爭議時才能有效舉證。
「本文同步刊登於TIPS網站(https://www.tips.org.tw )」
美國的數位服務推動小組18F(Digital service delivery,18F),因辦公室位於華盛頓特區F街18號而得名。2014年3月由總務署(General Service Administration,GSA)成立,透過業界與政府合作模式,幫助政府機關改善流程及增進效率,其所輔導的專案計畫將實際轉變政府機關提供數位服務及科技產品之運作模式,以達跨部會、機關之整合,並使對公眾的數位服務更便於使用。 18F為幫助美國各機關建造、購買及分享現代數位服務以提升政府的使用者經驗,提供了五項服務:(一)就已存的數位規格(digital component)打造訂製化產品(custom products);(二)以創新方式購買科技,使各政府能夠獲得更快、更好及產生更好結果的IT服務。詳細服務內容有代寫委外服務建議書(Request For Proposal,RFP)、開發市場利用現代技術購買IT服務、購買開放源代碼(open source code)以提升專案計畫;(三)替政府建造一安全、可擴展的工具與平台,其能更加符合需求並能夠持續為改善以達需求;(四)協助成為數位化組織,不只是增加組織內部數位化能力,更要形成數位習慣並最終促使組織文化改變;(五)透過討論會、設計工作室、指南及文件工作平台,提供及分享18F實際運用的相關現代數位化服務技術,使政府機關能自行複製及使用。 近期知名成果案例發生於加州。在加州,每一年的孩童福利服務案件管理系統超過2萬名社工利用為追蹤管理超過50萬件虐待及忽視兒童案件,若使用過時系統產生風險將無法估計,故加州政府、美國衛生與人群服務部(Department of Health and Human Services,DHHS)即利用了前述相關服務,與18F共同重新設計該系統的採購流程。從2015年11月至2016年10月,合作建立新系統不到1年的時間,導入了契約文件之簡化、模組化(modular)契約之合併、敏捷性開發(agile development)、使用者中心之設計及開放源(open source)之實踐。 首先,代寫委外服務建議書,18F於其中展示如何將專案計畫為模組化,亦即別於過往採購的傳統模式,非尋找單一開發商去建置整個已預設需求的系統,透過分離的方式,找尋不同開發商以更符合實際需求,亦能避免時間金錢的浪費,降低遲約或違約之風險。再者,聚集可能符合資格的供應商,邀請眾供應商建造以開放源代碼(open source code)方式的原型(prototype)。透過此一過程的激盪,18F從中協助評估所提出的原型、技術等,以了解供應商如何提出及是否符合使用者中心的設計。同時也能減少政府與供應商雙方的招標時間及行政成本。最後,為使加州政府機關能自行複製及使用相關現代數位化服務技術,18F示範敏捷軟體開發(agile software development)專案計畫。從中加州政府不僅瞭解如何為風險評估,且思考相關技術部門於專案計畫中的角色定位。 面臨現代化數位服務,在美國,聯邦與州政府都面臨極大挑戰。18F介入發展新模式,更能達實際需求,亦為內化之協助,利於政府自行發展其他數位服務。18F與加州政府合作之案例,或許能為國家發展數位服務運作之借鏡。
歐盟個資保護委員會公布GDPR裁罰金額計算指引歐盟個人資料保護委員會 (European Data Protection Board, EDPB)在徵詢公眾意見後,於今(2023)年5月24日通過了「歐盟一般資料保護規則行政裁罰計算指引04/2022」(Guidelines 04/2022 on the calculation of administrative fines under the GDPR)。此一指引,旨在協調各國資料保護主管機關(Data Protection Authorities, DPAs)計算行政罰鍰的方法,以及建立計算《歐盟一般資料保護規則》(General Data Protection Regulation, GDPR )裁罰金額的「起點」(Starting Point)。 時值我國於今(2023)年5月29日甫通過《個人資料保護法》之修法,將違反安全措施義務的行為提高裁罰數額至最高1500萬,金額之提高更需要一個明確且透明的定裁罰基準,因此該指引所揭露的裁罰計算步驟值得我國參考。指引分為五個步驟,說明如下: 1.確定案件中違反GDPR行為的行為數以及各行為最高的裁罰數額。如控管者或處理者以數個行為違反GDPR時,應分別裁罰;而如以一行為因故意或過失違反數GDPR規定者,罰鍰總額不得超過最嚴重違規情事所定之數額(指引第三章)。 2.確定計算裁罰金額的起點。EDPB將違反GDPR行為嚴重程度分為低度、中度與高度三個不同的級別,並界定不同級別的起算金額範圍,個案依照違反GDPR行為嚴重程度決定金額範圍後,尚需考量企業的營業額度以定其確切金額作為裁罰數額起點(指引第四章)。 3.控管者/處理者行為對金額的加重或減輕。評估控管者/處理者過去或現在相關行為的作為加重或減輕的因素而相應調整罰鍰金額(指引第五章)。 4.針對各違反行為,參照GPDR第83條第4項至第6項確定行政裁罰上限。GDPR並沒有對具體的違反行為設定固定的罰款金額,而是對不同違反行為規範了裁罰最高額度上限,EDPB提醒,適用第三步驟或下述第五步驟所增加的額度不能超過GDPR第83條第4至第6項度對不同違反行為所訂的最高額度限制(指引第六章)。 5.有效性、嚇阻性與比例原則的考量。個資保護主管機關應針對具體個案情況量以裁罰,必須分析計算出的最終額度是否有效、是否發揮嚇阻以及是否符合比例原則,而予以相應調整裁罰額度,而如果有客觀證據表明裁罰金額可能危及企業的生存,可以考慮依據成員國法律減輕裁罰金額(指引第七章)。 EDPB重申其將不斷審查這些步驟與方法,其亦提醒上述所有步驟必須牢記,罰鍰並非簡單數學計算,裁罰金額的關鍵因素應取決具體個案實際情況。
德國聯邦內政部提出「資訊科技安全法」(草案),保障關鍵基礎設施及資訊安全德國聯邦內政部繼與德國聯邦經濟暨能源部與交通暨數位基礎設施部共同擬定之「數位議程2014 - 2017」(Digitale Agenda 2014 – 2017)政策裏,於本年8月19日提出資訊科技安全法(草案)(IT-Sicherheitsgesetz)。該草案的提出目的為保障德國公民與企業使用的資訊系統安全,特別是在全國數位化進程中,攸關國家發展的關鍵基礎設施。德國內政部長de Maizière在新聞發表會上,宣稱要讓德國成為全球資訊科技系統及數位基礎設施安全的先驅與各國的模範。除外,亦欲藉此強化德國資訊科技安全企業的競爭力,提升外銷實力。 該草案的主要對象係關鍵基礎設施營運者(Kritische Infrastrukturbetreiber),例如在能源、資訊科技、電信、運輸和交通、醫療、水利、食品、金融與保險等領域的企業。「關鍵基礎設施」的定義並未涵蓋德國聯邦政府部門之間使用的數據通信系統。不過,究竟係在這些基礎設施領域的哪些企業該受到資訊科技法的約束,德國內政部將陸續與各相關部會研討後再以行政法規的方式明確表列出來。 關鍵基礎設施企業必須採取適當的保護措施以保障關鍵基礎設施的正常運行。所採取的保護措施可符合同業或同業公會裡所認可的最新資訊安全標準,且得符合一定的付出成本比例。不過衡量標準,最後還是得由德國聯邦資訊安全局(Bundesamt für Sicherheit in der Informationstechnik, BSI)〉做認定。上述之企業需兩年內完成安全防護措施的設置。為防止電信系統非法入侵,該草案也修增德國電信法(Telekommunikationsgesetz)為施予電信業者更高的資訊安全防護標準。針對網際網路服務提供者(Internet Service Providers, ISP)也特別施加設置防範駭客攻擊的尖端防護措施義務。 關鍵基礎設施業者的資訊安全系統均須透過德國聯邦資訊安全局(Bundesamt für Sicherheit in der Informationstechnik, BSI)每兩年定期審核,若沒通過則會被要求依德國聯邦資訊安全局的標準去處裡該安全漏洞。 若是上述業者的資訊安全系統有受損,並且可導致關鍵基礎設施的故障或損毀,該企業需通報德國聯邦資訊安全局,且該記錄可匿名化。但是,若是因駭客攻擊直接導致關鍵基礎設施的故障或損毀,該企業則需立即通報德國聯邦資訊安全局,不可匿名。
經濟合作與發展組織發布《促進AI可歸責性:在生命週期中治理與管理風險以實現可信賴的AI》經濟合作與發展組織(Organisation for Economic Co-operation and Development, OECD)於2023年2月23日發布《促進AI可歸責性:在生命週期中治理與管理風險以實現可信賴的AI》(Advancing accountability in AI: Governing and managing risks throughout the lifecycle for trustworthy AI)。本報告整合ISO 31000:2018風險管理框架(risk-management framework)、美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST)人工智慧風險管理框架(Artificial Intelligence Risk Management Framework, AI RMF)與OECD負責任商業行為之盡職調查指南(OECD Due Diligence Guidance for Responsible Business Conduct)等文件,將AI風險管理分為「界定、評估、處理、治理」四個階段: 1.界定:範圍、背景、參與者和風險準則(Define: Scope, context, actors and criteria)。AI風險會因不同使用情境及環境而有差異,第一步應先界定AI系統生命週期中每個階段涉及之範圍、參與者與利害關係人,並就各角色適用適當的風險評估準則。 2.評估:識別並量測AI風險(Assess: Identify and measure AI risks)。透過識別與分析個人、整體及社會層面的問題,評估潛在風險與發生程度,並根據各項基本價值原則及評估標準進行風險量測。 3.處理:預防、減輕或停止AI風險(Treat: Prevent, mitigate, or cease AI risks)。風險處理考慮每個潛在風險的影響,並大致分為與流程相關(Process-related)及技術(Technical)之兩大處理策略。前者要求AI參與者建立系統設計開發之相關管理程序,後者則與系統技術規格相關,處理此類風險可能需重新訓練或重新評估AI模型。 4.治理:監控、紀錄、溝通、諮詢與融入(Govern: Monitor, document, communicate, consult and embed)。透過在組織中導入培養風險管理的文化,並持續監控、審查管理流程、溝通與諮詢,以及保存相關紀錄,以進行治理。治理之重要性在於能為AI風險管理流程進行外在監督,並能夠更廣泛地在不同類型的組織中建立相應機制。