跳至主要內容

當AI給你營養建議:台灣《營養師法》還沒想過的法規空白

之前分享利用 Claude Code 做飲食營養分析 Bot 的經驗。我自己有個習慣,就是在做新的專案時,會先評估法遵風險。當我在做飲食營養分析 Bot 時,我才知道原來台灣除《醫師法》外還有《營養師法》,而《營養師法》第 12 條列舉營養師的法定業務,包含營養評估、飲食設計、個案諮詢、膳食管理等。

這部《營養師法》在幫大家的健康把關,因為不能隨便一支影片、一段報導,就能提供營養建議。在法規中,需要接受完整的專業教育,並持續進修,每 6 年就要提出繼續教育的證明文件,才能更新執業證照;沒有「營養師」的證照不能自稱「營養師」,法規中列舉了營養師的業務範圍,並規定須親自執行業務,不能由他人代理,如果藉由通訊方式執行業務,還要經過執業登記的主管機關核准;執行業務時還要做紀錄,這些紀錄可能還會成為法律或醫療紀錄文件。

成為「營養師」需要符合嚴格的要求與限制,並不是隨便用AI分析、讓AI提供建議就能取代的。台灣每年會舉辦 2 次營養師的考試,參考自中華民國營養師公會在 2025年的資料,台灣每年營養科系的畢業生約 1500 人,到 2025年,累計已有 11,860 人通過考試取得執照,及格率約 25%,看起來是一個具有挑戰性的考試。

Bot 的個人化建議,算不算「執行業務」?

在我設計的 Bot 裡,不是只有拍照上傳讓 AI 去分析、評估,事實上還有其他情境的飲食需求,再提供使用者建議,例如由 Bot 提醒當天攝取的蛋白質不足,或我在前篇文章中提到的鈉的攝取量過高,Bot可能提醒要減少鈉的攝取或是多補充哪些蛋白質來源,這些分析與建議是否算「執行業務」?在該法第 29 條中也寫明,如果沒有取得營養師的資格而執行相關業務,本人及其雇主各處新臺幣 5 萬元以上,25 萬元以下罰鍰。

法律規範的對象是「人」,目前法律還沒有明確定義 AI 工具的法律地位,也不知道該找誰負責,是開發的工程師?大語言模型的公司?還是開發的公司?一般開發者通常會在提供的資訊裡加上「僅供參考、非醫療建議」的免責聲明來規避,但無從得知這樣的聲明在法律是否具有效力。另外,由於在 Bot 中可以設定慢性病的個別飲食計算,還可能同時踩到《醫師法》(涉及診療)與《營養師法》(涉及個案管理)。同時,即使開發者已在服務中加入「僅供參考、非醫療建議」的免責聲明,主管機關或法院在判斷是否構成營養師業務的執行時,仍然會以服務的實質功能為主要審查對象。例如,若 Bot 提供高度個人化的營養評估、針對個案的飲食設計、或針對慢性病提出具體調整建議,這些行為在實質上已接近營養師法第 12 條所列的業務範圍,單憑免責聲明可能無法完全排除法律風險。目前台灣尚無直接針對此類 AI 工具的司法判決,但實務上「看實質、不看形式」是法院在醫事法領域常採用的審查原則,這也是開發者需要特別留意的地方。

法規精神 vs. AI現實:一個難解的矛盾

現行《營養師法》的立法精神是保護民眾不受道聽途說與庸醫之害,但 AI 時代最大的衝突,可能是「AI 可能比平均水準的諮詢更準確,卻沒有法律地位」。這個矛盾,台灣目前沒有出口。

現行中華民國法律無法解決的根本問題包括:

  1. 不明確的責任主體:誰應該為 AI 建議導致的傷害負責?開發者說是工具,使用者說信了 AI,傷者說誰賠?
  2. 「諮詢」的定義沒有數位化更新:在立法時只想到人對人的「諮詢」。AI 是一對百萬人的個人化互動,現有法律框架根本無法對應。
  3. 跨國AI模型供應商的管轄空白:若 AI 背後是 Anthropic、OpenAI、Google 或其他國家的大語言模型,台灣主管機關(衛福部/食藥署 或數位發展部)可能無法管到供應商,只能管台灣境內的介接服務。

他山之石:美國、歐盟、英國

基於過往工作的經驗,我請AI協助找尋相關資料。

美國:風險分級模式

目前在應用程式商店中有提供食品營養分析功能的應用程式,可能還結合許多類似運動監測、生理資訊監測的功能,這些目前都可能是遊走在灰色地帶,以不違反《營養師法》為前提來提供服務。但我在想,有沒有可能有符合時代發展的進一步作法?

美國 FDA 在 2020年啟動「數位健康卓越中心」(Digital Health Center of Excellence,DHCoE),目的是協調 FDA 內部所有數位健康相關工作,並非直接負責審批決策,DHCoE的主要工作領域為數位健康政策支援、醫療器材網路安全、AI/ML、真實世界證據(Real World Evidence)、法規科學研究。美國FDA把軟體分成「醫療器材等級」和「非醫療器材」,判斷標準是:軟體的輸出是否直接用於醫療診斷或治療決策。一般健康追蹤 app 通常不被歸類為 Software as a Medical Device(SaMD),但若 AI 針對慢性病患者給出具體飲食處方,就可能跨線。DHCoE 在2025年11月,數位健康諮詢委員會專門討論「生成式 AI 驅動的數位心理健康醫療器材」,顯示美國 FDA 已開始正式處理生成式應用的監管問題,而再更早之前我也提過歐盟與美國相關的監管資訊;在 2026年 1 月美國 FDA 更新 2019 年的「一般健康工具指引」(General Wellness: Policy for Low Risk Devices)與 2022 年的「臨床決策支援軟體指引」(Clinical Decision Support Software,CDS),核心方向是「低風險放行、高風險維持管控」,這些對美國的軟體開發者來說,很多過去灰色地帶的健康工具現在明確不需要美國 FDA 審查,也降低許多法遵風險。

除了美國,歐盟與英國也各自走出不同的路,剛好可以跟美國的「風險分級」對照。

歐盟:雙軌疊加、從嚴

歐盟《醫療器材法規》(Medical Device Regulation,MDR)與《AI Act》的交集,其判斷邏輯類似於美國此FDA,看的是「意圖用途」,如果應用程式(APP)只是健康提醒或追蹤,屬於「一般促進健康應用程式」(Wellness App);但只要涉及診斷、治療建議或臨床判讀,就會被歸類為醫療器材軟體(SaMD)。如果這個SaMD 本身內建 AI 或機器學習,例如針對慢性病患者給出個人化飲食建議,依「AI Act對醫材的高風險分類」還會被額外歸類為「高風險AI系統」,必須同時符合 《MDR》 與 《AI Act》 兩套規範,包括資料治理、透明度、人為監督、風險管理與上市後監控等義務。在之前的全球 AI 監管進度中,也提到歐洲議會已於2026年6月16日公布確認通過的AI 法 Omnibus 修正案,將嵌入受歐盟產品安全法規約束之產品的AI系統則延至2028年8月2日。

英國:補強規範中,採認國際機制

英國藥品與保健產品管理局(MHRA)的現行指引「軟體與人工智慧(Software and artificial intelligence (AI) as a medical device)一樣是判斷軟體是否具「醫療用途」,但目前尚未有專屬的AI醫療器材規範,只確認會在「2026年依英國生命科學產業計畫發布專屬框架」,處理AI生命週期治理、透明度與資安要求——這一點跟台灣現在的空白狀態其實頗為類似。比較特別的是,英國另外設計國際採認機制「Statement of policy intent: international recognition of medical devices」:只要廠商已取得美國FDA、加拿大衛生部或澳洲TGA的核准,就能直接申請英國的簡化審查,預計可縮短6到12個月的上市時間。

英國在2024年啟動全球第一個AI醫療器材法規沙盒「AI Airlock」,並持續擴大測試規模;2025年9月更成立「AI醫療監管國家委員會」(National Commission into the Regulation of AI in Healthcare),研議AI醫療器材監管的未來方向。

結論:在法規灰色地帶裡,我們還能做什麼?

從我自己動手做自己的飲食營養分析 Bot 開始,原本只是想解決自己的健康管理需求,卻意外找到台灣法規對 AI 時代未曾設想的空白。《營養師法》的立法精神立意良善,是要保護民眾不被沒有專業訓練的建議誤導,但它假設的前提,是「諮詢」發生在人與人之間,而不是一個能同時服務上百萬使用者、隨時給出個人化建議的AI。

目前沒有人真正確定「僅供參考、非醫療建議」這句話在法律上是否站得住腳,也沒有人能明確回答,當AI建議出錯時,責任該由誰承擔:寫程式的人、訓練模型的公司,還是提供服務的開發者?

美國、歐盟、英國的做法,剛好提供 3 種不同參考方向:美國 FDA 用風險分級處理:低風險的一般健康工具直接放行,只有真正涉及診斷或治療決策的高風險應用才需要嚴格審查,效率最高,開發者至少知道自己站在哪條線的哪一邊;歐盟則是 《MDR》 加 《AI Act》雙軌從嚴,只要 SaMD 內建 AI,一律視為高風險系統,資料治理、透明度、上市後監控一項都不能少,課責機制最完整,但代價可能是提高業者的法遵成本與風險;英國則一邊補齊自己的AI 醫材框架,一邊用「國際採認」承認美、加、澳已經做過的審查結果,等於用別人的把關,換自己上市審查的時間。

對台灣來說,個人角度認為比較務實的方向,是「美國式的風險分級」加上「英國式的國際採認」,而不是照搬歐盟的雙軌從嚴。台灣的個人開發者、小型新創本來就資源有限,如果比照歐盟,要求 AI 飲食建議工具比照醫療器材做完整的風險管理與上市後監控,等於直接把像我這樣的個人專案排除在合法範圍之外;但完全不管、放任現況模糊,又會回到前面說的責任真空。與其從零打造一套台灣專屬的AI醫材框架,不如先參考美國「一般健康工具」與「臨床決策支援軟體」的分級標準,把「提醒/追蹤」跟「個人化處方級建議」劃出清楚界線,同時比照英國的精神,承認 FDA、EMA等已經做過的風險判斷,減少台灣主管機關從零審查的負擔。這樣至少能讓像我一樣的個人開發者,知道自己的 Bot 站在哪一邊,而不是所有人一起賭一把。

對我自己來說,這個Bot目前只服務我一個人,還沒有到需要煩惱法律責任的規模。但如果哪天想把它分享給更多人使用,這篇文章整理的這些問題,就是我在推出這個服務前必須先想清楚的事,而我更希望,台灣的法規能在公開服務之前,能先明確的標示範圍,減少我的法遵風險與成本。

 

Image by Jan Mateboer from Pixabay

留言

此網誌的熱門文章

用Claude Code做一個AI飲食營養分析Bot:從拍照辨識到條碼查詢的實作筆記

沒想到在十多年後,因為想做飲食營養控管,所以自己利用 AI 開始做一個簡單的食品營養分析工具,能分析我每餐的飲食是否充足或過量,並提供有依據的飲食建議。 最初的雛形是基於以往曾參與「 Food Open Data 」倡議的經驗,我希望用最簡單的方式,拍照-->AI辨識與分析-->提供建議,然後統計一段期間的營養攝取狀況。 最初的想法 當我把我的雛形想法告訴 AI 後,Claude Code 很快的就幫我設計好雛形、教我如何申請Telegram Bot,這些步驟都寫得很清楚,整個雛形做好不用半天,我還愣住了,怎麼可能這麼簡單?難怪那些應用程式公司只把飲食營養分析當作一個「附加功能」,主要目的是蒐集其他的生理監測資料,但這些公司蒐集資料的用途,我自己在處理過美國資料經紀公司所販售的資料隱私資訊後,這是值得關心的議題,但不在此篇文章裡討論。 不過,我只專注在飲食分析項目,我覺得這個功能如果可以做好,再想想其他的。最初的想法很宏大,因為家人與自己患有慢性疾病,所以特別針對某些族群設計,但事實上,如果沒有實際的使用情境,可能也無法做出符合需求的產品。 於是我把這個Bot的使用者只鎖定在我自己的飲食分析上,那就簡單多了。 工具與環境限制 我在今年已經改用 Claude Cowork 與 Claude Code 協作,雖然 Claude Code 有一般介面版,但我大多數時間都開著終端機視窗使用 Claude Code,這樣比較能專心工作。 基於使用工具的習慣,我使用 Claude Code 開始建置,當時的模型雖然已經有Opus 4.8,但Sonnet 4.6已綽綽有餘,而後來出現的Fable 5 則用在其他專案裡。 因為只做給自己用,所以選擇最簡單的 Chatbot 形式;也因為我希望可以自由的使用而不是提供過多的個人資料給其他平台,選用 Telegram Bot,而不是台灣人常用的 LINE Bot ,而且 LINE上太多廣告,根本不想開它。 在衡量經濟現實及自我管理資料的想法後,目前這個 Bot 與資料庫只放在我的電腦裡,沒有上雲端,當電腦休眠、網路斷線時,Bot就會停止工作。 雖然只是給我自己使用,但我還是要求資料庫是加密儲存的,匯出資料時也必須加密。 台灣的飲食文化很多元 我不是開發者、也不是營養師,我自己也沒使用過其他的應用程式,所以無從理解在開發飲食營...

停不下來的更新

一直更新Blog的版型,我必須承認是一件很無聊的事,不過這次除了版型的更動外,連分類和文章內文也做了變動。 先說分類吧!在Blogger叫做Label,不過,Blogger在分類上有一些bugs,只能使用英文,以前這裡的分類大多都是中文分類,結果在link上就是一堆亂七八糟的亂碼,所以我把它改成英文,同時細分一些項目,把出版的文章和一些教學的文章分開來,雖然已經很久沒寫新的,不過既然放上來就做個分類。然而就在新舊label移轉之後,發現中文的label還會存在,而且還會出現莫名奇妙的幽靈數字,Blogger知道這是個bug,不過似乎一直沒有修復的跡象。所以在分類上就出現了如右圖一般的情況,在英文標籤裡會有文章,但是在中文標籤裡是沒有文章出現的,但奇怪的是,有些中文標籤已經不見了,然而在Beauty-Beta這個部落格裡,我也做了分類上的變動,由於以前用英文開頭的Label,所以在label的變動上倒是不用擔心會有這樣的情況。 再來是文章的內容,把以前的文章重新分類,標題前面的一些全形符號或是分類刪掉,除了一些比較特殊的,我會留著,例如壹陸壹,因為在label裡為了統一,我留著原本的E61,但人家的店名是壹陸壹,所以留下文章標題前面的中文分類,另外像是Entertainment項目裡,可能有音樂,可能有電影,就會在前面留下中文分類。 前簡單的CSS和HTML改成現在的XML,這無疑是讓我們再多學些東西,能有時間鑽研當然是好事,可是轉換後,我一直沒有時間去改,當然多半也是因為懶,到現在也是拿別人做好的版型去改配色而已,所以像裡面的設定、安裝的widget和analytics的javascript都要一個一個重新裝,上個星期幾乎每天都弄到天亮才睡,只為了整理這個blog。也因為之前在blog裡放了technorati的分類,所以還要修改以前的文章,把它們加入technorati,還有裡面的語法要更改,所以這個星期甚至下個星期都會一直收到這裡的更新訊息,對於不斷收到訊息干擾的朋友們,在這裡說聲抱歉。 在版面上因為blogger系統在feed接受上的更新,所以還有四個東西沒加進去,分別是最近的文章(Recent Post)、Comments(目前是用別人寫的widget)還有GVO的feed訂閱顯示、Beauty-Beta的訂閱顯示也都還沒放上去。 在Feed訂閱上,以前bl...

法制追不上AI:缺乏台灣AI基本法子法,公務員使用生成式AI的五大風險

昨晚看新聞,現任台北市長拋出一個政策宣示:未來公務員將配給自動化的AI工具,讓台北市政更「前進」。台北市資訊局也已快速推出 CiviClaw,目標是 2027 年讓每位公務員都能無門檻使用 AI。 這樣的政策方向讓我感到憂心。長期觀測各國個資保護規範的我清楚知道:台灣的個人資料保護主管機關至今仍是「籌備處」,尚未正式運作;《個人資料保護法》的修法呼聲雖久,AI相關條款卻付之闕如;《人工智慧基本法》已於今年1月施行,但高風險AI認定標準的子法至今仍是空白。 有網路、有 IoT 不等於智慧城市,有 AI 當然也不等於智慧城市,應該重視制度能否承接工具帶來的責任。 歐盟已明確禁止業者使用 AI 推測員工或學生的心理狀態;美國聯邦政府要求採購 LLM 時廠商必須提交模型卡與資料卡;韓國 AI 基本法的子法早已配套生效。這些都是台灣政府在推動配給公務員 AI 之前,必須正視的制度差距。 以下我與大家分享長期觀測的內容,由AI協助整理資料: 歐盟:從禁令到揭露義務的多層規制體系 歐盟的AI治理框架是由多部法律疊加起來的立體架構,最底層是2018年施行的 GDPR,處理的是個人資料如何被蒐集、儲存、使用的基礎規則,再來疊是2024年生效的《人工智慧法》(EU AI Act,下稱 AI 法),建立不同風險等級分類管理AI系統,從禁止使用到高強度監管、再到一般透明度義務,形成不同層次。最新的一層則是仍在立法程序中、但主要架構已確立的 Digital Omnibus ,試圖修補 AI 法與 GDPR 之間的規範衝突。 AI 法第50條是最直接影響生成式AI服務的條款,自2026年8月2日起全面適用。根據這條規定,凡是讓使用者與AI系統互動的業者,必須主動告知對方「正在與 AI 互動」,而不能讓人誤以為面對的是真人。AI生成的文字、影像、音訊等內容,還必須以機器可讀的格式加上標記,使平台與監管機關得以溯源辨識。與此同時,AI法第14條要求高風險AI系統必須設計成「可由自然人有效監控」的形式,確保機器的決策不會在缺乏人工審核的情況下直接作用於當事人。 AI法所稱的「高風險 AI 」,涵蓋的場景比一般想像的廣。依該法附件三列舉,生物辨識系統、關鍵基礎設施管理、教育與職業篩選、就業與人員管理、信貸與社會福利申請審核、執法、移民邊境管制,以及司法審判輔助,都在高風險範疇之內。這些場景的業者必須進...