近來歐盟健康食品上市審查標準之實務觀察

  歐盟自2007年起開始實施「歐盟(EC)1924/2006號食品營養及健康訴求規則」(簡稱營養與健康訴求規則)以來,對於以營養與健康為訴求的產品,要求廠商上市販賣之產品,必須經過科學實證,產品標示必須簡易明瞭,強調科學實證必須證明食用該產品對人體有益,並證明食用產品與其功能效果間能建立因果關係,更強調文字敘述應貼近事實、清楚明瞭、確實可靠,避免使用模糊不清或造成不同解讀的文字,以便於消費者識別選購產品,滿足個人攝取這類食品的需求。

 

  自規則實施以來,業者紛紛向歐盟食品安全管理局(European Food Safety Authority,簡稱EFSA)遞交申請案件,期待通過審查,獲准上市。然而,以營養與健康訴求規則中的第十四項減少疾病風險與促進兒童健康訴求,引起較多爭議。到2008年9月底,九件申請案當中已有八件遭到EFSA駁回,無不引起產業界的恐慌。僅Unilever(聯合利華公司,以下簡稱Unilever)的植物固醇產品(plant sterol)一案通過。反觀其餘個案,廠商遭EFSA駁回申請案的理由不一。例如,法國廠商Bio-Serae以仙人掌纖維衍生物申請具有降低血脂質的健康訴求,EFSA表示提交的證據資料不足以建立食用產品與效果功能間的因果關係。再者,另一件訴求ALA(α亞麻油酸)和LA(亞麻油酸)之攝取可以促進兒童生長的申請案中,EFSA接受廠商檢附的證據資料,但表示孩童經由正常飲食即可攝取足夠的ALA與LA,攝取量高於均衡飲食標準沒有益處。

 

  雖然EFSA之意見不具有法律效力,且負面意見不表示否定產品之成分或功能,僅表示其依據資料不完整,不足以證明兩者具有因果關係,但卻具有相當之影響力。目前某些業者面對法令細節尚未明朗,同時負面意見多於正面意見的情形下,憂心負面意見恐將影響公司與產品形象,先行退出審查過程並暫緩產品上市。到2008年底,EFSA又駁回五件關於益生菌(probiotics)增進兒童健康的申請案,表示提供的證據資料不足以證明其功能為由。累計至去年底二十七申請案中(含上述五件益生菌申請案),僅有五件申請案獲得EFSA之正面意見,負面意見依舊多於正面意見。

 

  然而在2009年1月,EFSA核准西班牙廠商Danone促進兒童骨骼生長的健康訴求,表示證據資料足以建立因果關係,證明維他命D有助於鈣質攝取。顯示出業者提供充足科學證據資料與完整的產品說明,以證明其食用產品與功能效果間的因果關係,將利於審查作業進行,也將助於獲得EFSA之核准上市。

本文為「經濟部產業技術司科技專案成果」

相關連結
※ 近來歐盟健康食品上市審查標準之實務觀察, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=2979&no=57&tp=1 (最後瀏覽日:2026/09/02)
引註此篇文章
你可能還會想看
澳大利亞政府擬修正《支付系統管理法》將數位支付,如Apple Pay、Google Pay納入法律規範中

澳大利亞國庫部(Department of the Treasury)於2023年10月11日發布《支付系統管理法》(Payment Systems(Regulation)Act 1998)修正草案,擬擴張法案適用主體,將Apple Pay、Google Pay等數位支付或提供此項支付服務事業納入規範,其目的在於提升企業的開放性及責任,並關注大型科技企業在其中扮演的角色。 本次修正案中,將修改現行支付系統的定義及適用主體,擴大至提供支付服務平臺企業,將被視為金融機構受到拘束,並授權澳大利亞準備銀行(the Reserve Bank of Australia,下稱RBA)監管數位支付平臺。修正草案內容整理如下: 1.重新定義「支付系統」。現行法定義為「透過任何形式或方式促進貨幣流通的系統」,草案則納入非貨幣(non-monetary,如數位貨幣)及提供便利支付服務的支付平臺系統。 2.擴大「參與者」定義。現行法規中參與者僅包含管理、運作支付系統的企業,草案則擴張至與支付價值鏈(payments value chain)具直接或非直接相關連之所有企業。 3.現行規範中,僅RBA在可能涉及使用者財務安全及公共利益(下述)考量時,有指定支付系統的職權,並有權監管該支付系統,包含決定新參與者的加入、訂定制度內參與者應遵守的標準及指引、對相關爭議問題進行仲裁等。修法後國庫部部長(Minister)將擁有相同權力。規範所稱之「公共利益」,指有助提升財務安全、高效率並具有競爭性,且不會導致金融體系風險增加。 4.提高法案中刑事處罰的罰金金額。現行法規授權RBA訂定支付制度之相關標準及指引,若制度內參與者未依標準或指引行事,RBA會提出要求企業為特定行為或不行為之指示,仍未依循可能會科處澳幣5,500元的罰金(約臺幣11萬3千元),修法後將提高至2倍,惟罰金之處罰權最終仍須法院審判決定。 我國針對電子支付產業有電子支付機構管理條例、金融消費者保護法規範,並要求第三方支付服務業者落實洗錢防制法規定,避免淪為洗錢或地下匯兌工具,未來可持續觀察澳大利亞及其他國家對於支付平臺議題之討論及發展趨勢,作為我國評估相應治理措施及手段參考基礎。

因應2020年社會實現自動駕駛,日本訂定自動駕駛制度整備大綱

  日本IT綜合戰略本部及官民資料活用推進本部於4月17日公佈「自動駕駛制度整備大綱」。大綱設定2020年至2025年間,日本社會實現自動駕駛下,所需檢討修正之關連法制度。   本大綱中,係以2020年實現自動駕駛至等級4為前提(限定場所、速度、時間等一定條件下為前提,系統獨自自動駕駛之情形),以在高速公路及部分地區之道路實現為條件設定。社會實現自動駕駛有以下課題需克服: 道路交通環境的整備:以自駕系統為行駛,一般道路因為環境複雜,常有無法預期狀況發生,導致自駕車的電腦系統無法對應。 確保整體的安全性:依據技術程度,設定一般車也能適用之行駛環境、設定車輛、自動駕駛之行駛環境條件以及人之互相配合,以達成與一般車相同之安全程度為方針下,由關係省廳間為合作,擬定客觀之指標。此一指標,並非全國一致,應就地方之特性,設定符合安全基準及自動駕駛行駛環境條件,建構整體確保安全之體制。 防止過度信賴自駕系統:訂定安全基準,使日本事件最先端自動車技術擴及於世界,訂定包含自駕系統安全性、網路安全等自動駕駛安全性要件指針。 事故發生時之法律責任:自動駕駛其相關人為駕駛人、系統製造商、道路管理者等多方面,其法律責任相對複雜化。現在係以被害人救濟觀點,至等級4為止之自動駕駛,適用自動車損害賠償責任險(強制責任險)方式,但是民法、刑法及行政法等法律全體之對應,仍為今後之課題,必須為早期快速處理。為了強化民事責任求償權行使、明確刑事責任之因果關係、並實現車輛安全性確保、避免所有人過度負擔等,車輛行駛紀錄器之裝置義務化、事故原因究明機制等,關係機關應合作為制度檢討。   本大綱最後並提出,在自動駕駛技術快速發展下,就其發展實際狀況應為持續半年1次召開會議檢討檢討。

美國國家標準暨技術研究院發布「全球AI安全機構合作策略願景目標」,期能推動全球AI安全合作

美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST)於2024年5月21日提出「全球AI安全機構合作策略願景目標」(The United States Artificial Intelligence Safety Institute: Vision, Mission, and Strategic Goals,下稱本策略願景),美國商務部(Department of Commerce)亦於2024年參與AI首爾峰會(AI Seoul Summit)期間對外揭示本策略願景,期能與其他國家攜手打造安全、可靠且可信賴之AI生態系。 由於AI可信賴與否往往取決於安全性,NIST指出當前AI安全所面臨的挑戰包含:一、欠缺對先進AI之標準化衡量指標;二、風險測試、評估、驗證及確效(Test, Evaluation, Validation, and Verification, TEVV)方法不健全;三、欠缺對AI建模後模型架構與模型表現間因果關係的了解;四、產業、公民社會、國內外參與者等在實踐AI安全一事上合作程度極為有限。 為因應上述挑戰並促進AI創新,NIST在本策略願景中擬定以下三大戰略目標:(1)推動AI安全科學發展:為建立安全準則與工具進行技術合作研究,並預先部署TEVV方法,以利評估先進AI模型之潛在風險與應對措施;(2)推展AI安全實務作法:制定並發布不同領域AI風險管理之相關準則與指標,以達到負責任設計、開發、部署與應用AI模型與系統之目的;(3)支持AI安全合作:促進各界採用前述安全準則、工具或指標,並推動全球合作,以發展國際通用的AI安全風險應對機制。

美國國家安全局發布「軟體記憶體安全須知」

  美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。

TOP