發展階段支出可列為資產
第三十七號會計公報 「無形資產的會計處理」 新近出爐，就無形資產清楚給予定義，並解釋如何進行會計處理與鑑價。其中最特別的是，第三十七號公報首次區分「研究」和「發展」階段的不同，發展階段有可能資本化。資本化最大的影響是，支出可以列為資產，不會影響損益，研究型企業的資產負債、損益表也將更為精準。
舉例來說，生化、製藥業者因研究期很長，所有研發期間的投入，過去都須列為費用，導致獲利被明顯稀釋；未來根據三十七號公報，企業專案計畫接近商品化的發展階段，就可以資本化，此時的損益表上費用項目，就不會那麼高， 因此，「發展」階段可列為資產，有助鼓勵科技業者增加研究發展經費的投入。
至於企業併購所產生的購買價格和被併公司淨值之間的溢價，過去通常以商譽處理，不過在 37 號公報上路後，會計師建議不應再把溢價直接當作商譽來處理，此乃因第 37 號公報所稱的無形資產，並不包含商譽，且必須具有「個別可辨認性」。因此，併購溢價應該區分為商譽和無形資產兩者，其後續評價對企業也較為有利。
此外會計業者也表示，促產條例中對研發投抵的認列，有可能受到三十七號公報的影響，需要做調整，這部分有待財政部進ㄧ步規範清楚。
日本國家網路安全中心（内閣サイバーセキュリティセンター，或稱National Information Security Center, NISC）於2020年3月2日發布「網路安全相關法令問答集」（サイバーセキュリティ関係法令Q&Aハンドブック），以回應日本內閣在2017年7月27日通過的「網路安全戰略」（サイバーセキュリティ戦略）中所提及應整理相關法制，以利企業實施網路安全措施與對策之決定。因此，內閣網路安全戰略本部（サイバーセキュリティ戦略本部）普及啟發‧人才培育專門調查會（普及啓発・人材育成専門調査会）於同年10月10日成立工作小組，針對網路安全相關法令進行推動與調查工作。 本問答集內容涉及13項法律議題，包括議題如下： 說明網路安全基本法（サイバーセキュリティ基本法）網路安全之定義與概要； 以公司法為核心，從經營體制觀點說明董事義務，例如建立內部控制機制，以確保系統審核與資料揭露之適當性； 以個人資料保護法為核心，例如說明個人資料的安全管理措施； 以公平交易法（不正競争防止法）為核心，說明在營業秘密的保護範圍內，利用提供特定資料與技術手段，來實施迴避行為係屬無效； 以勞動法規為核心，說明企業採取網路安全措施之組織與人為對策； 以資通訊網路、電信業者等為中心，說明IoT相關法律問題； 以契約關係為中心，說明電子簽章、資料交易、系統開發、雲端應用服務等議題； 網路安全相關證照制度，例如資訊處理安全確保支援人員； 說明其他網路安全議題，例如逆向工程、加密、訊息共享等； 說明發生網路安全相關事故之因應措施，例如數位鑑識； 說明當網路安全糾紛有涉民事訴訟時應注意之程序； 說明涉及網路安全之刑法規範； 描述日本企業在實施網路安全措施時，應注意之相關國際規範，例如歐盟一般資料保護規則（General Data Protection Regulation, GDPR）與資料在地化（Data Localization）等議題。 此外，隨著網路與現實空間的融合，各產業發展全球化，相關法規也日益增加，惟網路安全相關法規，在原無網路安全概念與相關法制的日本法上，卻鮮少有較為系統化的概括性彙編與解釋文件。因而盤點並釐清網路安全相關法令則成為首要任務，故研究小組著手進行調查研究，並將調查結果—「網路安全法律調查結果」（サイバーセキュリティ関係法令・ガイドライン調査結果）與「第四次關鍵基礎設施資訊安全措施行動計畫摘要表」（重要インフラの情報セキュリティ対策に係る第４次行動計画）作為本問答集之附錄文件以資參酌。最後，NISC期待透過本問答集，可作為企業實施具體網路安全對策之實務參考。
OECD發布《抓取資料以訓練AI所衍生的智慧財產問題》報告經濟合作與發展組織（Organisation for Economic Co-operation and Development, OECD）於2025年2月9日發布《抓取資料以訓練AI所衍生的智慧財產問題》報告（Intellectual property issues in artificial intelligence trained on scraped data），探討AI訓練過程中「資料抓取」對智慧財產之影響，並提出政策建議，協助決策者保障智財權的同時推動AI創新。 資料抓取是獲取AI大型語言模型訓練資料之主要方法，OECD將其定義為「透過自動化方式，從第三方網站、資料庫或社群媒體平臺提取資訊」。而未經同意或未支付相應報酬的抓取行為，可能侵害作品之創作者與權利人包括著作權、資料庫權（database rights）等智慧財產及相關權利。對此，報告分析各國政策法律的因應措施，提出四項關鍵政策建議： 一、 訂定自願性「資料抓取行為準則」 訂定適用於AI生態系的準則，明確AI資料彙整者（aggregators）與使用者的角色，統一術語以確保共識。此外，準則可建立監督機制（如登記制度），提供透明度與文件管理建議，並納入標準契約條款。 二、 提供標準化技術工具 標準化技術工具可保護智財權及協助權利人管理，包括存取控制、自動化契約監控及直接支付授權金機制，同時簡化企業合規流程。 三、 使用標準化契約條款 由利害關係人協作訂定，可解決資料抓取的法律與營運問題，並可依非營利研究或商業應用等情境調整。 四、 提升法律意識與教育 應提升對資料抓取及其法律影響的認知，協助權利人理解保護機制，教育AI系統使用者負責任地運用資料，並確保生態系內各方明確瞭解自身角色與責任。
英國資訊委員辦公室首次對違反資料保護案件開罰英國資訊委員辦公室（Information Commissioner’s Office，ICO）於今（2010）年11月24日首次對違反資料保護案件開罰。 賀福郡理事會（Hertfordshire County Council）員工在今年6月兩度將載有高度敏感性資料的文件傳真予錯誤的收件人。ICO經調查後認定，由於賀福郡理事會未能防止兩次資料外洩事件發生，導致嚴重損害，而在首次外洩事件發生後，亦未採取足夠的預防措施避免類似情況發生，因此裁定十萬英鎊之罰鍰。 另一家發生資料外洩事件的人力資源服務公司A4e，則是因其員工將含有兩萬四千筆個人資料的筆記型電腦帶回家後遭竊，且包括個人姓名、出生年月日、郵遞區號、薪資、犯罪紀錄等相關資料並未加密。ICO認為，A4e並未採取適當措施避免資料外洩，且A4e允許其員工將未加密的筆記型電腦帶回家時，已知內含個人資料種類及數量，因此裁定六萬英鎊之罰鍰。 ICO表示，希望本次處罰能對於處理個人資料的機構有所警惕。 ICO今年4月被賦予裁罰權，至於裁罰的標準，則有裁罰指引（fine guidance）可參考。根據裁罰指引，若資料控制者（data controller）故意違反資料保護法（Data Protection Act），或可得而知可能違法之情形，卻未採取適當措施預防之，而可能造成相當損害時，ICO得處以相當罰鍰。
歐盟執委會公布「數位金融包裹」法案為鼓勵金融產業之創新，同時使其遵循應有之責任，並讓歐盟金融消費者與商業機構享有更多之利益，歐盟執委會於2020年10月24日提出數位金融包裹法案（Digital Finance Package），並提出以下2項數位金融立法提案： 一、加密資產立法提案（Proposal for Markets in Crypto-assets） 為促進金融創新並同時保有金融穩定性與保護投資人，歐盟執委會提出加密資產管制框架立法提案，並將加密資產分為已受監管與未受監管兩類，前者將持續依據既有規範進行管理。而針對尚未管制之加密資產，該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制，要求取得核准後始可提供服務。具體而言之，立法提案包含以下項目： （一）針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。 （二）針對向公開市場提供加密資產進行管制，例如，依據提案第4條，供應商應為法人，第5條則要求供應商應製作加密資產白皮書，並將其提供給主管機關後始可於公開市場提供相關服務。 （三）針對代幣資產發行人以及其加密資產之審核程序，依據提案第15條，代幣發行者必須為歐盟境內之法律實體。另外，該法要求加密資產發行人應誠實、公平且專業，並完成加密資產白皮書之出版與制定市場溝通規則。 （四）針對加密資產之收購，該法第4章亦設有相關規範，於第37條及38條規定收購之評估機制。 （五）針對加密資產服務供應商之授權與營運條件，該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。 （六）針對市場秩序維護之部分，該法於第6章規範相關預防市場濫用之禁止事項與要求，並於第7章賦予歐盟成員國各主管機關相關權力，例如第94條之監督與懲處權限。 二、歐盟數位營運韌性管制框架立法提案（Proposal for Digital Operational Resilience） 數位化總伴隨資安風險，歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案，以確保相關企業可應對所有與通訊技術有關之干擾與威脅，另外，銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊，另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含： （一）ICT風險管理要求：該立法提案參照相關國際標準，於第5至第14條制訂相關ICT風險管理要求，惟未要求應遵循具體國際標準。 （二）ICT相關事件報告：該提案於第15至20條規範相關報告義務，將整合歐盟金融機構之ICT相關事件報告與監測程序。 （三）數位運作韌性測試：該提案於第21至第24條要求ICT風險管理框架應定期進行測試，惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。 （四）第三方單位風險：該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測，例如，第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範，另外，ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。