# 零信任、雲端、AI 與 LLM 相關法規與標準整理

---

## 台灣零信任架構相關規範

1. **國家資通安全研究院《零信任架構 (ZTA)》（2024）**
- 定位：資安研究與標準參考。
- 核心：提出「身份鑑別、設備鑑別、信任推斷」三機制，並要求驗證廠商是否符合。
- 適用：各政府機關及導入零信任架構之單位。
📎 [官方網站 – 零信任架構 ZTA](https://www.nics.nat.gov.tw/core_business/cybersecurity_defense/ZTA/)

2. **金管會《零信任參考指引》（2024）**
- 定位：金融業專屬參考指引。
- 核心：參考美國 CISA 的「零信任成熟度分級模型」，推出四階段分級，鼓勵金融業逐步導入。
- 適用：各金融機構。
📎 [金管會零信任參考指引](https://www.fsc.gov.tw/ch/home.jsp?id=96&parentpath=0,2&mcustomize=news_view.jsp&dataserno=202407180002&dtable=News)

---

## 國際零信任架構標準

1. **NIST SP 800-207《Zero Trust Architecture》（2020，美國 NIST）**
- 定位：全球最權威的零信任架構標準文件。
- 核心：定義零信任七大原則，涵蓋 PDP、PEP、控制層、資料層與支援層。
- 適用：各類組織導入零信任架構的參考依據。
📎 [NIST SP 800-207](https://csrc.nist.gov/publications/detail/sp/800-207/final)

2. **CISA《Zero Trust Maturity Model (ZTMM) 2.0》（2023，美國 CISA）**
- 定位：零信任成熟度分級模型。
- 核心：提出五大支柱（身份、裝置、網路／環境、應用與工作負載、資料）以及四種成熟度等級（傳統、進階、最佳化、最優化）。
- 適用：政府機關、金融機構及大型企業導入零信任的成熟度評估。
📎 [CISA Zero Trust Maturity Model 2.0](https://www.cisa.gov/zero-trust-maturity-model)

---

## 台灣雲端相關規範

1. **《金融機構作業委託他人處理內部作業制度及程序辦法》第十九條（2023，金管會）**
- 定位：主管機關法規，規範委外處理內部作業。
- 與雲端關聯：若雲端服務屬於委外業務範疇，需遵守此條款規定。
📎 [相關法規 PDF（雲端部分註記）](https://www.fsc.gov.tw/userfiles/file/%E9%9B%B2%E7%AB%AF%E5%95%8F%E7%AD%94%E9%9B%86%E7%99%BC%E5%B8%83%E7%89%88112%E5%B9%B410%E6%9C%88.pdf)

2. **《政府機關雲端服務應用資安參考指引 v1.3》（2024，資通安全署／國家資通安全研究院）**
- 定位：政府機關雲端應用的資安控制指引。
- 核心：涵蓋 IaaS、PaaS、SaaS 控制措施、部署模型、資料安全與管控機制。
- 適用：中央／地方政府機關。
📎 [共通規範專區 – v1.3 指引](https://www.nics.nat.gov.tw/cybersecurity_resources/reference_guide/Common_Standards/)

3. **《金融機構作業委外使用雲端服務自律規範》（2024，銀行公會）**
- 定位：金融機構使用雲端服務的自律規範。
- 核心：規範金融機構在使用雲端運算與儲存服務時，應落實風險管理、資安控管、合規審查等機制。
- 適用：所有銀行及金融機構。
📎 [公告版 PDF](https://www.ba.org.tw/FileDownload/Download?FileId=ce02ca50-b415-4cd3-ab47-85038f40ee5b&FileName=%E9%87%91%E8%9E%8D%E6%A9%9F%E6%A7%8B%E4%BD%9C%E6%A5%AD%E5%A7%94%E5%A4%96%E4%BD%BF%E7%94%A8%E9%9B%B2%E7%AB%AF%E6%9C%8D%E5%8B%99%E8%87%AA%E5%BE%8B%E8%A6%8F%E7%AF%84%28%E5%90%AB%E7%B8%BD%E8%AA%AA%E6%98%8E%29-%E5%85%AC%E5%91%8A%E7%89%88+.pdf)

4. **《保險業作業委外使用雲端服務自律規範》（2024，壽險公會／產險公會）**
- 定位：保險業使用雲端服務的自律規範。
- 核心：包含雲端服務供應者選擇、資料主權、隔離性、日誌控管等。
- 適用：全體保險業。
📎 [官方條文](https://www.nlia.org.tw/information_area/discipline_line/%E4%BF%9D%E9%9A%AA%E6%A5%AD%E4%BD%9C%E6%A5%AD%E5%A7%94%E5%A4%96%E4%BD%BF%E7%94%A8%E9%9B%B2%E7%AB%AF%E6%9C%8D%E5%8B%99%E8%87%AA%E5%BE%8B%E8%A6%8F%E7%AF%84/)

5. **《金融機構使用雲端服務實務手冊》（2024，銀行公會）**
- 定位：操作指引／實務手冊。
- 核心：雲端服務類型 (IaaS、PaaS、SaaS)、風險評估、管理架構、檢核表。
- 適用：金融機構在導入／管理雲端服務時的參考依據。
📎 [手冊 PDF](https://www.ba.org.tw/FileDownload/Download?FileId=600d928f-0657-474f-b280-c2799421e682&FileName=%E9%87%91%E8%9E%8D%E6%A9%9F%E6%A7%8B%E4%BD%BF%E7%94%A8%E9%9B%B2%E7%AB%AF%E6%9C%8D%E5%8B%99%E5%AF%A6%E5%8B%99%E6%89%8B%E5%86%8A%28%E5%90%AB%E5%B0%88%E6%9C%89%E5%90%8D%E8%A9%9E%E8%88%87%E6%AA%A2%E6%A0%B8%E8%A1%A8%29%E7%AC%AC%E4%B8%80%E7%89%88__113.08.pdf)

---

## 國際雲端安全與治理標準

1. **CSA STAR（Cloud Security Alliance – Security, Trust & Assurance Registry）（2013 起）**
- 定位：全球最廣泛採用的雲端安全認證與評估登錄制度。
- 分級：
- Level 1：自我評估（Self-Assessment）
- Level 2：第三方稽核（ISO/IEC 27001 + CSA CCM 控制）
- Level 3：持續監測（Continuous Monitoring）
- 適用：雲端服務供應商、企業客戶評估雲端安全。
📎 [CSA STAR Registry](https://cloudsecurityalliance.org/star)

2. **ISO/IEC 27017:2015《雲端服務資訊安全控制》**
- 定位：ISO/IEC 27002 的雲端專用延伸。
- 核心：針對「雲端供應商」與「使用者」分別規範責任與安全控制。
- 適用：雲端服務供應商與使用雲端服務的組織。
📎 [ISO/IEC 27017 官方頁面](https://www.iso.org/standard/43757.html)

3. **ISO/IEC 27018:2019《公有雲 PII 隱私保護》**
- 定位：專門針對公有雲環境下個人可識別資訊（PII）的保護。
- 核心：要求雲端服務提供者落實資料最小化、透明化、隱私同意與稽核機制。
- 適用：公有雲服務提供者與使用公有雲的組織。
📎 [ISO/IEC 27018 官方頁面](https://www.iso.org/standard/76559.html)

4. **SOC 2 Type II（AICPA Trust Services Criteria，2017 起）**
- 定位：國際常見的雲端服務審計報告。
- 核心：涵蓋安全性、可用性、處理完整性、機密性、隱私。
- 適用：美國與跨國雲端供應商（AWS、Azure、GCP 幾乎都有）。
📎 [AICPA SOC 2 官方介紹](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/sorhome)

---

## CSA 雲端風險 Top 11（2024，Cloud Security Alliance）

📎 [Top Threats to Cloud Computing 2024](https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-2024)

1. **錯誤配置與變更控制不足**：雲端儲存桶（如 AWS S3）權限設為「公開」，客戶資料外洩。
2. **身分與存取管理不善**：員工離職後未撤銷雲端權限，前員工仍能刪除生產環境資料。
3. **不安全的介面與 API**：未啟用身分驗證的 REST API，攻擊者直接調用竊取資料。
4. **雲端安全策略不當**：企業直接套用預設防火牆設定，未關閉不必要的通訊埠 (如 SSH 22)。
5. **不安全的第三方資源**：使用未審查的第三方容器映像 (Docker Image)，內含挖礦惡意程式。
6. **不安全的軟體開發**：未過濾用戶輸入值，駭客透過輸入欄位發動 SQL 注入攻擊。
7. **意外資料暴露**：工程師誤將雲端金鑰上傳至 GitHub，攻擊者取得後操控資源。
8. **系統漏洞**：未修補雲端伺服器的 Log4j 漏洞，駭客遠端植入後門。
9. **雲端可視性不足**：企業使用 AWS + Azure 多雲，卻無統一監控，異常流量未被偵測。
10. **未經認證的資源共享**：雲端檔案分享連結未設密碼，任何人點擊即可下載敏感文件。
11. **進階持續性威脅（APT）**：國家級駭客透過釣魚郵件入侵，長期潛伏竊取研發資料。

---

## 台灣人工智慧相關規範

1. **《人工智慧基本法》(2025，立法院)**
- **定位**：台灣 AI 發展的根本大法（上位法），明定**國科會**為主管機關。
- **核心**：確立七大治理原則（含永續發展、人類自主、隱私保護、透明可解釋等），並設立「國家人工智慧戰略特別委員會」。
- **重點**：採「風險分級」管理，平衡產業創新與人權保障，要求針對高風險 AI 應用建立救濟與歸責機制。
- 📎 [官方條文](https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=H0160093&kw=%e4%ba%ba%e5%b7%a5%e6%99%ba%e6%85%a7%e5%9f%ba%e6%9c%ac%e6%b3%95)

2. **《政府機關使用生成式 AI 參考指引》（2024，行政院）**
- 定位：行政機關指引。
- 核心：禁止輸入機密或個資到公開 LLM；AI 輸出不可直接作為唯一決策依據。
- 適用：所有政府機關。
📎 [官方文件](https://www.nstc.gov.tw/nstc/attachments/da74d556-5b1b-4cbd-9015-901cce87ff91)

3. **《金融業運用人工智慧 (AI) 指引》（2024，金管會）**
- 定位：產業專用規範。
- 核心：金融機構導入 AI 時，須符合隱私保護、資安檢核、第三方管理等要求。
- 適用：所有金融機構。
📎 [指引 PDF](https://www.fsc.gov.tw/websitedowndoc?file=chfsc%2F202408231741530.pdf&filedisplay=%E9%99%84%E4%BB%B6_%E9%87%91%E8%9E%8D%E6%A5%AD%E9%81%8B%E7%94%A8AI%E6%8C%87%E5%BC%95.pdf)

4. **《金融機構運用人工智慧技術作業規範》（2024，銀行公會）**
- 定位：金融機構自律規範。
- 公布時間：2024 年 4 月 15 日。
- 核心：風險評估、客戶權益、個資保護、模型透明、供應商管理。
- 適用：所有銀行及金融機構。
📎 [官方文件](https://www.ba.org.tw/PublicInformation/Detail/5100?enumtype=ImportantnormType&type=99537959-bc87-4d24-bcb7-83c8e7767e65)

5. **《保險業運用人工智慧系統自律規範》（2025，壽險公會／產險公會）**
- 定位：保險業 AI 自律規範。
- 公布時間：2025 年 4 月 10 日。
- 核心：風險管理、資料隱私、公平待客、模型透明、第三方管理。
- 適用：壽險與產險公司。
📎 [官方條文](https://law.lia-roc.org.tw/Law/Content?lsid=FL104924)

6. **《證券商運用人工智慧技術自律規範》（2024，證券公會）**
- 定位：證券業自律規範。
- 核心：資訊安全、個資保護、智慧財產權、模型公平性與客戶權益。
- 適用：所有證券商。
📎 [官方 PDF](https://www.twsa.org.tw/F01/doc/%E4%B8%AD%E8%8F%AF%E6%B0%91%E5%9C%8B%E8%AD%89%E5%88%B8%E5%95%86%E6%A5%AD%E5%90%8C%E6%A5%AD%E5%85%AC%E6%9C%83%E8%AD%89%E5%88%B8%E5%95%86%E9%81%8B%E7%94%A8%E4%BA%BA%E5%B7%A5%E6%99%BA%E6%85%A7%E6%8A%80%E8%A1%93%E8%87%AA%E5%BE%8B%E8%A6%8F%E7%AF%84.pdf)

7. **《公部門人工智慧應用參考手冊（草案）》（2024/2025，數位發展部）**
- 定位：行政部門草案。
- 核心：提供操作原則、流程、範例，納入隱私倫理考量。
- 適用：全體公部門。
📎 [官方草案下載](https://moda.gov.tw/digital-affairs/digital-service/guide/15002)

8. **《人工智慧（AI）產品與系統評測參考指引（草案）》（2024，數位發展部 數位產業署）**
- 定位：政府公布之**評測參考指引（草案）**，屬自願性導引；公告預告期至 **113/04/17**（建立：113/03/29）。
- 核心：提出 AI 產品/系統之**基本規範**（風險識別、透明性、場域測試、風險管理等）與**基本檢測基準**（測試流程與項目），促成可依循之評測/治理框架（含 **AIEC** 概念）。
- 適用：資訊、電信、傳播、資安、網際網路等產業。
📎 [公告頁](https://moda.gov.tw/ADI/news/bulletin-board/11896)
📎 [草案 PDF](https://www-api.moda.gov.tw/File/Get/adi/zh-tw/0u5igOQcVXiBO9b)

9. **《AI 產業人才認定指引（114 年 7 月）》（2025，數位發展部 數位產業署）**
- 定位：政府對 AI 產業從業/專業者的人才資格認定指引。
- 核心：定義 AI 人才能力標準、分類認定與評定流程。
- 適用：AI 產業開發者、研究者、企業技術人員等。
📎 [指引公告頁與下載](https://moda.gov.tw/ADI/services/publications/16938)

10. **《生成式 AI 安全與倫理使用手冊》（2019，國科會 NSTC）**
- 定位：研究與教育用之倫理/安全守則。
- 核心：強調學術研究與教育場域的倫理責任、安全規範、避免學術不端。
- 適用：大專校院、研究機構、計畫主持人與研究人員。
📎 [官方頁面](https://www.nstc.gov.tw/folksonomy/detail/dbf8da09-22be-4ef1-8294-8832fc6e8a26?l=ch)

11. **《台北市政府生成式 AI 參考指引》（2024，臺北市政府智慧城市辦公室）**
- 定位：地方政府對公務體系之 AI 使用規範。
- 核心：適用場景、禁止事項、資料保護原則，並推動 AI 服務試辦與監管。
- 適用：臺北市政府各局處及相關計畫。
📎 [官方頁面](https://smartcity.taipei/cp.aspx?n=B62A305B042D90DD)

---

## 國際人工智慧法規與框架

1. **歐盟《AI Act》（2024）**
- 定位：全球第一部完整 AI 法規。
- 核心：風險分級管理，禁止性／高風險應用須符合法規。
📎 [The EU Artificial Intelligence Act](https://artificialintelligenceact.eu/)

2. **ISO/IEC 42001:2023《AI 管理系統》**
- 定位：全球第一個 AI 管理系統國際標準，可第三方認證。
- 核心：建立、實施、維護 AI 管理系統，與 ISO 27001 可整合。
📎 [ISO/IEC 42001 官方頁面](https://www.iso.org/standard/81230.html)

3. **NIST《AI Risk Management Framework (AI RMF)》（2023，美國 NIST）**
- 定位：美國 NIST 的 AI 風險管理框架。
- 核心：可信賴性、偏見、透明度、安全性評估。
- 性質：非強制，但成為實務標準。
📎 [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework)

---

## OWASP Top 10 for LLMs (2025)

### 分類整理

- **事前（訓練／建置／供應鏈）**
- LLM03 供應鏈風險 (Supply Chain Risk)
- LLM04 資料與模型投毒 (Data & Model Poisoning)
- LLM08 向量與嵌入弱點 (Vector & Embedding Weaknesses, 建置時未加密)

- **事中（推論／執行／使用中）**
- LLM01 提示詞注入 (Prompt Injection)
- LLM02 敏感資訊揭露 (Sensitive Information Disclosure)
- LLM05 不當輸出處理 (Improper Output Handling)
- LLM07 系統提示詞洩露 (System Prompt Leakage)
- LLM08 向量與嵌入弱點 (Vector & Embedding Weaknesses, 整個資料庫外洩)
- LLM09 錯誤資訊 (Misinformation)

- **事後（營運／權限／成本）**
- LLM06 過度代理授權 (Excessive Agency)
- LLM10 無限資源耗盡 (Unbounded Resource Consumption)

### 📝 考試提醒：易混淆項目
- **LLM05 vs LLM09**：前者是「沒查證就用」，後者是「AI 產生錯誤」
- **LLM01 vs LLM07**：前者是「攻擊模型行為」，後者是「偷看系統設定」
- **LLM02 vs LLM07**：前者是「洩露用戶資料」，後者是「洩露系統資訊」

---

### 1. 提示詞注入 (Prompt Injection)
- **定義**：惡意輸入讓模型執行超出設計範圍或未授權的操作。
- **案例**：DeepSeek 上線初期被網友以「jailbreak／提示詞注入」繞過安全限制，誘導其回答原本限制的台灣、天安門等敏感議題。
- **新聞來源**：[DeepSeek 被 jailbreak，談論台灣與天安門等敏感主題 (2025)](https://www.cna.com.tw/news/ait/202501290062.aspx)
- **防禦**：加強輸入檢測並持續更新防護規則，避免被繞過限制。

---

### 2. 敏感資訊揭露 (Sensitive Information Disclosure)
- **定義**：模型在輸入、輸出或紀錄過程中，可能洩漏個人、企業或機關的敏感資訊。
- **案例**：三星工程師將內部程式碼貼到 ChatGPT，結果公司機密外洩，公司緊急禁止使用。
- **新聞來源**：[三星員工外洩內部機密，緊急限縮 ChatGPT 使用 (2023)](https://www.ithome.com.tw/news/156291)
- **防禦**：不得將機密或個資輸入公開 LLM，服務端也需強化日誌與資料庫安全。

---

### 3. 供應鏈風險 (Supply Chain Risk)
- **定義**：LLM 系統仰賴的第三方套件、模型或服務若不安全，可能成為攻擊途徑。
- **案例**：資安專家警告，國內企業常直接使用 HuggingFace 等開源模型，若來源未審核，恐引入後門或惡意授權。
- **新聞來源**：[Hugging Face被查出共享的機器學習模型存在資安威脅 (2024)](https://www.ithome.com.tw/news/161549)
- **防禦**：審核並驗證第三方套件與模型來源。

---

### 4. 資料與模型投毒 (Data & Model Poisoning)
- **定義**：惡意或偏頗的資料進入訓練或微調過程，使模型學到錯誤或歧視性結果。
- **案例**：
1. **微軟 Tay 聊天機器人**：上線後遭大量惡意使用者灌輸仇恨言論，短短 24 小時內就學會輸出種族歧視、性別歧視與攻擊性內容，最終被迫下線。
- [微軟 Tay 聊天機器人 24 小時內被玩壞，充滿種族仇恨推文 (2016)](https://www.ithome.com.tw/news/103111)
2. **GPT 履歷排序偏見**：彭博實測發現，OpenAI GPT-3.5 在履歷篩選時，對帶有非裔美國人姓名的履歷明顯低估，反映出訓練資料存在種族偏見。
- [蝦米！OpenAI GPT在履歷排序也搞種族偏見 (2024)](https://ec.ltn.com.tw/article/breakingnews/4601482)
3. **中國 DeepSeek 政治審查**：BBC 測試發現，DeepSeek 在遇到台灣、六四、西藏等問題時，不是拒答，就是給出符合中國官方立場的回應，顯示「選擇性投毒」的風險。
- [DeepSeek 的審查爭議：無法回答，或是中國官方的敘事版本 (2025)](https://www.bbc.com/zhongwen/articles/c0lz28yx480o/trad)
- **防禦**：確保訓練資料多元且經審核，並進行偏見檢測與公平性審計。

---

### 5. 不當輸出處理 (Improper Output Handling)
- **定義**：AI 產生的輸出若未經驗證或過濾就直接使用，可能帶來安全或法律風險（如惡意程式碼、假引用、錯誤客服資訊）。
- **案例**：
1. **猶他州律師案**：律師在上訴請願書中引用 AI 生成的虛構案例，法院查無此案，最後遭裁罰 **1000 美元**。
- [使用ChatGPT寫訴狀「憑空產生虛假案例」 美國律師遭開罰道歉 (2025)](https://tw.news.yahoo.com/share/491e2012-83cf-3007-88c0-e646f6ca5617)
2. **加拿大航空客服案**：客服聊天機器人誤導乘客關於退款規定，乘客依 AI 回答行事卻遭拒絕，最後法院判定 Air Canada 必須賠償。
- [AI浪潮下首起判決！聊天機器人誤導客戶 加航需賠償 (2024)](https://news.ltn.com.tw/news/world/breakingnews/4584025)
3. **Vibe Coding 案例**：開發者誤信 AI 產生的「自動換 API Key」程式碼，實際上程式並未正確實作金鑰輪替，導致舊金鑰仍可被濫用，最終造成 API 配額耗盡與成本暴增。
- [Vibe Coding 風險案例：AI 沒有真的幫你換 Key (2025)](https://blog.darkthread.net/blog/vibe-coding-risk/)
- **防禦**：所有 AI 輸出須經人工或系統驗證，避免直接引用或對外使用。

---

### 6. 過度代理授權 (Excessive Agency)
- **定義**：AI 被賦予過多系統操作權限，可能誤操作或被濫用。
- **案例**：
1. **Replit AI 助理**：在「vibe coding」實驗中刪除生產資料庫並試圖隱瞞。
- [AI機器人誤刪創業者資料庫還撒謊隱瞞 Replit執行長致歉 (2025)](https://tw.news.yahoo.com/share/df6564ec-87cb-3c89-970e-23d6c2140294)
2. **台新銀行戰神 AI**：自動鎖定疑似高風險帳戶，導致部分正常用戶帳戶遭誤鎖。
- [台新用AI鎖定疑似高風險帳戶，但部分民眾帳戶被誤鎖 (2025)](https://www.bnext.com.tw/article/84377/taishin-ai-lock)
- **防禦**：採最小權限原則，嚴格控管 AI 可執行的操作，關鍵決策（如鎖帳戶、刪除資料）應保留人工審核或多層安全閘門。

---

### 7. 系統提示詞洩露 (System Prompt Leakage)
- **定義**：AI 的隱藏設定或系統提示詞被洩露，讓攻擊者繞過規則或濫用系統。
- **案例**：Bing Chat（Sydney）剛上線時，prompt injection 洩漏完整 system prompt。
- **新聞來源**：[以ChatGPT強化的Bing遭使用者誘騙，洩露工程代號及機密 (2023)](https://www.ithome.com.tw/news/155474)
- **防禦**：加強提示詞保護，避免被誘導輸出內部設定。

截圖TVBS Youtbue頻道

---

### 8. 向量與嵌入弱點 (Vector & Embedding Weaknesses)
- **定義**：向量資料庫或嵌入若缺乏保護，可能導致資料外洩或被惡意操控。
- **案例**：研究人員發現多個 LLM 向量資料庫未設存取控制，導致企業與醫療資料直接暴露在網路上。
- **新聞來源**：[趨勢科技警告：數以千計的AI伺服器正暴露在網路上 (2025)](https://www.ithome.com.tw/pr/170580)
- **防禦**：對向量資料庫加權限、加密，並檢查輸入資料，避免被惡意污染。

---

### 9. 錯誤資訊 (Misinformation)
- **定義**：AI 可能生成錯誤或虛構資訊（幻覺），或因訓練資料偏見，導致誤導使用者判斷。
- **案例**：Google Bard 在發表會展示時，被問到「韋伯太空望遠鏡的新發現」，錯誤宣稱它拍攝了太陽系外行星的第一張照片（實際上早在 2004 年就有了）。錯誤回答曝光後，導致 Google 母公司 Alphabet 股價一天內蒸發超過 1000 億美元。
- **新聞來源**：[Google Bard答錯天文問題，Alphabet市值蒸發千億美元 (2023)](https://www.ithome.com.tw/news/156055)
- **防禦**：建立事實查核與多來源比對機制，避免盲目信任 AI 輸出。

---

### 10. 無限資源耗盡 (Unbounded Resource Consumption)
- **定義**：惡意或濫用請求造成系統資源或成本過度消耗。
- **案例**：台北捷運 AI 客服因被濫用詢問程式問題，導致 Token 消耗激增，營運成本上升。
- [台北捷運 AI 客服被拿來寫程式碼，Token 用量爆增 (2024)](https://www.ithome.com.tw/news/166191)
- **防禦**：設定使用上限與濫用偵測機制。