2026年6月18日 星期四

考量產品安全面向的使用資訊原則概述（七之五）

IEC/IEEE 82079-1:2019（見前篇）
© All Rights reserved。 版權聲明。CC BY-SA 4。0。
（內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。）

8 使用說明的結構

標題

內容

8.1一般

使用資訊應予以結構化，係提升其可使用性與易理解性，當適用時，並提供方便搜尋、便於導引及明確理解內容的功能。

若一般資訊可能冗長或複雜，應明確劃分為便於閱讀的各個部分，並保持格式一致。

若目標受眾截然不同，例如：安裝人員與維修技術員，應將資訊分章或區隔章節。

對於包含多份文件的印刷資訊，封面或書脊上的資訊應方便區分不同文件。 

註：關於結構與文件的更多資訊可參考 IEC 81346-1 及 IEC 62023。 

若提供補充資訊，則可在使用資訊的顯著位置標示之。

若有補充資訊可用，使用資訊可提供存取地點，例如：連結至包含補充資訊的網站。

系統可以由來自不同供應商的不同元素組成。若系統供應商開發了系統使用的資訊，供應商可能會將所提供的資訊整合為整體資訊的一部分。

當整合多個來源的資訊時，應考慮以下事項：

l   一致性的文件編號；

l   使用資訊的整合方法，例如：整合的拷貝（副本）、納入相關內容、與原始文件交叉參照，或是原始文件中的特定章節；

l   保持術語一致或使用交叉參照.

8.2   資訊類型

應在其功能結構中分配給預先定義的資訊類型，例如：

a)       概念性資訊。此資訊類型包括以下內容：

1. 關於使用資訊本身的資訊；

2. 產品與組件的描述與識別；

3. 控制與顯示的描述；

4. 流程描述 （使用案例或操作概念 ），

5. 安全提醒。

b) 說明的資訊。此資訊類型包括以下內容:

1. 程序的每個步驟（例如：組裝、安裝、維護任務）；以及

2. 警告訊息（係為程序的一部分）。

c) 參考資料。此資訊類型包括以下內容:

1. 書名頁資訊；

2. 法律要求的資訊；

3. 故障排除；

4. 維修時間表；

5. 目錄；

6. 術語詞彙表；

7. 索引。

8.3   結構化

8.3.1一般

結構化是指依據此份文件中的原則與詳細要求，將資訊分配到資訊模型或架構中。供使用資訊應依所有層級資訊結構化：

1. 若有多個資訊產品，則稱為一組資訊產物；

2. 資訊產品；

3. 資訊類型。

為了確保結構一致，應定義並套用規則於資訊中。 

註：在更高層次上，結構化可應用於元素，如句子、圖形、媒介物件及特定物件類型的標記。

各層級應適用適當的規則。

8.3.2使用資訊模型

以下列出三種內容結構方法，其中一種應採用:

1. 利用結構化方法建立資訊模型；

2. 使用現有的資訊模型，例如：開源資訊模型；以及

3. 透過結構化方法調整現有資訊模型。

8.3.3 使用領先準則

結構設計的領先準則選擇應依據支持的產品、資訊產品及目標受眾等因素而定。

領先準則的結構化原則示例參見表2：

原則

對主題細分與排列的考量

任務

依任務執行順序

產品

產品的功能或元素

產品生命周期

階段，例如運送、安裝、操作、保養、修理、處置

目標受眾

根據受眾的資訊需求進行資訊分割

認知程度

首先，從簡單到複雜

參數

為了方便參考，採用字母排序，例如參數列表、索引

8.3.4詳細的步驟說明結構

8.3.4.1一般

逐步說明應包含初步資訊、教學步驟及完成資訊。

8.3.4.2 初步資訊

初步資訊應包括以下事項：

1. 簡要概述程序之目的，並對包含（其他地方未提供）的必要概念之定義或說明；

2. 在開始任務前，識別所需的技術或行政作業項目；

3. 目標受眾完成任務所需的資源清單，可能包括：工具、其他人員、資料、文件、密碼或額外軟體、或設備；

4. 適用於整個程序的相關警告、警示與備註。

多個步驟共有的初步資訊可以組合起來並一次性呈現，以避免冗贅。

8.3.4.3說明步驟

說明步驟應以阿拉伯數字編號，並依展示順序呈現。

在適用的說明步驟前，應提供相關的警告訊息與警示。 

每個步驟都包含一個動作。教學步驟應標示預期結果或系統回應，並說明可能發生的錯誤訊息及復原程序。 

冗長或複雜的一步步指令應分段。應明確標示替代或重複步驟，讓目標受眾能判斷該執行或跳過哪些替代或重複步驟，以及在哪裡重新加入主程序。 

註：應標示應查閱參考資訊的步驟（例如：特殊代碼或指令）、需要特別注意的步驟，或錯誤常見的部分。 

在英語、法語及其他存在命令句且文化傳承尚可接受的語言中，說明步驟應使用命令句式形式來描述目標受眾的動作.

8.3.4.4完成資訊

使用資訊應標示一組逐步指示的結束。它應說明目標受眾如何判斷程序已成功完成（此係在產品設計與測試中經常有的考量重點），並可能包含相關主題的參考或連結，例如後續任務或故障排除。

8.4   引導與提供的資訊

8.4.1一般

使用資訊應包含方便瀏覽內容的元素，如8.4條暨相關節次所規定。

8.4.2 印刷式使用資訊的引導做法

8.4.2.1頁碼

若使用資訊超過兩頁（印刷版），則頁碼應編號。編號為（n）為（m），其中（n）代表實際頁碼，（m）則可使用總頁數。

8.4.2.2目錄

超過12頁的資訊應附目錄，除非能展現無此必要。目錄中的標題與頁碼應與正文中使用相同。目錄應有足夠層級幫助目標讀者有效率地找到資訊，但標題層級不應超過四層。

8.4.2.3索引

若資訊冗長且複雜，應附上按字母順序排列的關鍵字索引。目錄中應引用索引。

註：更多關於索引的資訊可參考ISO 5963。

8.4.3動態演示8.4.3.1個人化演示

如果可能，應該只向目標受眾展示達成特定目標或執行特定措施所需的特定資訊。此外，應透過區隔方式向目標受眾提供完整的支援產品資訊。 

若資訊中的主題僅限特定目標受眾（例如：付費顧客、使用者群組或使用者剖繪），資訊傳遞系統應限制存取權限。

8.4.3.2前後情境的敏感性

若個人的電子裝置可存取情境資訊（例如：地理資料、語音資料或影像模式），使用資訊可利用前後情境資訊向目標受眾提供更精確的資訊，惟此舉的前提係必須取得當事人的同意。

8.4.3.3搜尋功能

於電子傳送資訊中應提供某種電子搜尋機制。搜尋功能至少應包含文字字串。搜尋功能不僅應基於全文搜尋，還應由搜尋演算法、分類法、同義詞詞典及其他可用技術支援。

8.4.3.4連結到相關主題

如適用時，每個電子資訊主題可連結至其他相關主題，但任何連結不得分散或消弭目標受眾的興趣。涉及相同或相似主題的不同電子媒介（如文字、影片或聽覺元素）應連結或交叉參考，以便適宜時可以一同使用。 

外部連結（URL）通常視為不穩定，不應作為唯一引用方式，儘管如此，仍可能作為額外服務予以提供。

在印刷資訊中使用時，應包含相關資訊的完整網址以便查閱。

（未完，見續篇）



張貼者： 於 沒有留言:
標籤： , , , , , , , ,

人工智慧風險衝擊評鑑邁步走（三之三）

 （續前篇） 

適合醫療保健、醫療器材產業界及風險管理界。此文僅供個人參考與資訊喚回，尚非標準建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO、主管機關及出版指引文件的官方網站、洽詢各家專業公司、諮詢顧問等。
CC BY-SA 4。0。


四、風險緩解策略Risk Mitigation Strategies


一旦風險被識別並優先排序，應採取適當的緩解策略：

Strategy

When to Use

Examples

避免Avoid

風險是不可接受的，且無法被充分控制

不要為此情境部署 AI；採用替代方法

減緩Reduce  

風險可以透過控制措施降低

加入人工審查、改進模型、實施防護措施

轉移Transfer

風險可以與其他利害相關者分擔

投保第三者保險、合約分配、外包

接受Accept

對照後風險在容忍範圍內

文件化接受條件，建立監督措施

 

共通風險管制Common Risk Controls
  • 人類介入（Human-in-the-loop (HITL)）：須要求在採取後續措施前執行人工審查
  • 信心門檻：低信心度的預測事項須依既定層級向上呈報
  • 保護柵欄（英：AI Guardrails，德：KI-Leitplanken）：對某些輸出項目（劑量範圍、禁制行為）設出強硬型限制：
  • 基於AI共同責任模型 (AI Shared Responsibility Model)的觀念，各自承擔甲方負責事項與第三方 AI供應商盡職調查 (Vendor Due Diligence)：
  1. 基礎模型層（供應商當責）： 基礎架構安全、預訓練資料版權（IP）、底層模型安全柵欄；要求供應商提供模型卡 (Model Card)、系統卡 (System Card)、SOC 2 報告或 ISO 42001驗證證明；
  2. 應用與部署層（組織當責）：提示詞輸入流程安全、檢索增強生成 (RAG) 的私有資料庫隱私維護、下游臨床決策的人工審查機制（HITL）。並在合約中明確風險分擔、資料使用限制（禁止保密資訊/資料用於訓練）以及組織的稽核權 (Right to Audit)
  • 偏差測試：定期在受到保護的特定群體間進行評估
  • 持續監督：追蹤績效、漂移與異常狀態
  • 事件應變：當事情出錯時的因應計畫
  • 稽核追蹤：控制執行的證據

五、人工智慧風險評鑑的工具和模板

5.1 建議採用工具如下：

  • NIST AI RMF Playbook 為 AI RMF 1.0 的每個功能和子類別提供結構化評鑑問卷。該手冊包括建議的措施、透明度說明以及引用的相關標準。該手冊建構相當全面的免費資源 人工智慧風險評鑑 並在 airc.nist.gov 上提供各界參考下載。
  • AI Verify 是由新加坡 IMDA（資訊通訊媒體發展局）開發的開源 AI 治理測試框架。它提供涵蓋透明度、公平性、穩健性和當責制等治理原則的技術測試和流程檢查。AI Verify 產生可與利害相關者和監管機構分享的評估報告。
  • IBM AI Fairness 360 和 Microsoft Fairlearn 提供了評估和減輕公平風險的技術工具。AI Fairness 360 包括 70 多個公平指標和 10 種偏差緩解演算法。Fairlearn 提供公平性評估視覺化和緩解方法。上述兩種工具都是開源的程式，並整合到機器學習（ML）頻道中以供採行自動化公平性評鑑。
  • Credo AI、Holistic AI 和 Fairly AI 提供商業 人工智慧風險評鑑 和治理平台。此等工具可自動化風險評鑑的工作流程、追蹤緩解進度、產出合規文件並提供風險視覺化儀表板。它們對於管理跨多個人工智慧系統風險的組織特別有論合使用。

  • 人工智慧事件 資料庫（AIID）和 AIAAIC 儲存庫對現實世界的人工智慧故障和事件進行分類。這些資料庫對於風險識別非常有價值：審查涉及類似人工智慧系統的事件有助於僅透過理論分析來識別可能遺漏的風險。它們是人工智慧安全社群的集體記憶。
  • 英國的科學、創新與技術部，官方網站提供75種人工智慧評估技術保證手法，分成九大類案例研究：
  1. 大數據分析、
  2. 數據驅動的分析方法、
  3. 自然語言處理和生成、
  4. 影像辨識和視訊處理、
  5. 機器學習、
  6. 深度學習、
  7. 虛擬代理或人工對話界面、
  8. 機器人流程自動化和決策管理、
  9. 機器人和自動駕駛汽車/系統、；
  • 歐洲委員會（Council of Europe， CoE）下設的「人工智慧委員會（Committee on Artificial Intelligence，CAI）」倡議的「HUDERIA：從人權、民主和法治角度評估人工智慧系統風險和衝擊評鑑的方法學」，具備四個核心要素：
1. 基於情境的風險分析（COBRA）：以結構化過程，用於界定人工智慧系統的範圍、識別背景風險因素、繪製潛在影響以及根據傷害的嚴重程度和機率對系統進行分類。檢查三個風險領域：
    • 應用環境（例如：目的、法律環境）
    • 設計/開發環境（例如：資料品質、模型可解釋性）
    • 部署環境（例如：保障措施、訓練、濫用風險）
2. 利害相關者參與流程（Stakeholder Engagement Process，SEP）建議根據系統風險狀況客製化參與流程。這包括利害相關者映射、位置反映（開發人員的身分和權力如何塑造結果）以及包容性參與方法的實用設計。

3. 風險和衝擊評鑑（Risk and Impact Assessment，RIA）對先前確定的衝擊進行兩步驟深入研究，重點關注在規模、範圍、可逆性、和概率，特別著重於邊界情境或弱勢群體。鼓勵反思累積和長期效應。

4. 緩解計劃（Mitigation Plan，MP）引入緩解層次結構（避免、減少、恢復、補償），優先考慮預防而不是補救。涵蓋獲得補救措施的機會，並概述瞭解如何記錄和分配緩解責任。

5.2 風險評鑑範本應包括的項目，如下示：

  • 人工智慧系統描述範本（目的、架構、資料、利害相關者、法規背景資訊）
  • 風險登記範本（風險序號( risk ID)、描述、類別、可能性、嚴重程度、等級或分數、事件負責者、緩解技術、狀態）
  • 風險矩陣範本（具有顏色編碼風險等級和做成回應類別的 5X5 矩陣）
  • 衝擊評鑑範本（分析對個人、團體、組織和社會的衝擊）
  • 緩解計畫範本（控制描述、實施時間表、事件負責者、尤收準則、剩餘風險）。
組織可以將範本依照 NIST AI RMF Playbook 的結構，或是 歐盟人工智慧法案 符合性評定要求方式建立之。

六、常見問題

6.1 什麼是人工智慧風險評鑑？

人工智慧風險評鑑是識別、分析和評估與人工智慧系統相關的潛在風險的系統過程。它檢查技術、營運、道德和合規風險，為治理決策提供資訊並確定緩解工作的優先順序。

6.2 人工智慧風險評鑑和人工智慧衝擊評鑑有什麼不同？

人工智慧【風險評鑑】的重點是識別和評估潛在的故障模式、漏洞和危害、可能出現的問題及其可能性。人工智慧【衝擊評鑑】是評估人工智慧系統對個人、群體和社會的實際衝擊：包括正面和負面衝擊、分配效應以及對基本權利的影響。風險評鑑具有前瞻性（預測潛在危害）；在實務的工作流程衝擊評鑑評估實際或預期的影響。兩者通常是必需的並且相互輔佐以獲得綜合效益。

6.3何時需要進行人工智慧風險評鑑？

歐盟人工智慧法案要求對高風險系統進行風險評鑑，並廣泛用於與 NIST AI RMF 和 ISO 42001， ISO 42005 等框架保持一致。州制度正在不斷發展；歐盟的人工智慧法是一個決策技術的透明度和揭露架構。許多組織也要求進行供應商盡職調查和內部治理的風險評鑑。

6.4 何種情況或條件導致人工智慧系統帶有高風險？

高風險分類取決於屬於何種領域（如：醫療保健、就業、信貸）、決策類型（做出決定的後果、AI提供建議以供人類做出決定）、受到AI系統輸出結果而影響的群體、結果的可逆性。根據新近陸續公布的各國相關法規，大多數醫療保健人工智慧系統皆歸類為【高風險】。

6.5人工智慧風險評鑑應多久更新一次？

高風險人工智慧系統應每季（或半年）進行補充評鑑一次，並每年進行全面更新評鑑；低風險系統則每年進行一次評鑑。

當發生重大變化（如：新模型、資料變更、部署環境變更、擴展應用範圍）、法規發生變化、事件發生後，所有人工智慧系統都應及時受到重新評鑑。

對關鍵風險指標的持續監督應補充定期的正式重新評鑑。

註：高風險人工智慧系統必須強制要求第三方紅隊測試，例如：內部自動化紅隊 (Automated Red Teaming)、內部人類紅隊 (Internal Human Red Teaming)、以及第三方獨立紅隊 (Independent Third-party Red Teaming)。目的在測試及檢驗人工智慧系統的三大維度：
  • 對抗性技術測試：針對資料中毒、模型逆向工程。
  • 社會認知與倫理紅隊：專門模擬惡意用戶透過提示詞工程（Prompt Engineering）誘導 AI 輸出違反公平性、歧視性或醫療誤診言論的「越獄（Jailbreaking）」測試。
  • 紅隊結果的量化回饋：紅隊發現的漏洞必須直接映射至 1.5 節的「風險矩陣」中，重新計算剩餘風險。

6.6 誰應該參與人工智慧風險評鑑？

有效的評鑑需要跨職能部門的參與及投入，侷限於單一學科評鑑將遺漏或忽略重要風險事項：

風險類別

參與人員

技術風險

AI/ML 工程師、安全和保全工程人員

特定前後環節

受影響的使用者代表和執行贊助商

法規要求

法律、合規、查證、確證

公平和社會影響

倫理學家和受影響的社區代表

評鑑過程

風險管理者提供方法和框架專業知識


6.7哪些人工智慧風險較易遭到忽略？

經常被忽視的風險包括下列事項（非完整列出）：
  • 透過下游系統互動造成的間接損害
  • 交叉群體的公平風險（而不僅僅是個人受保護的特徵）
  • 僅在生產環境中出現的新興風險
  • 來自第三方模型、資料集和相互依賴關係的供應鏈風險
  • 累積部署效應帶來的社會各級層面的風險
  • 隨著現實世界資料分佈情形不同於從訓練資料轉移來的資料，組織常常低估模型漂移（英：Model Drift (Data/Concept Drift)，德：Modell-Drift (Daten-/Konzeptdrift)，分成【數據漂移】與【概念漂移】），效能逐漸下降的風險。



6.8哪些架構標準或規範適用於哪些法規？

  • NIST AI RMF 非常適合美國聯邦要求
  • NIST 已發布了符合歐盟人工智慧AI法和ISO 42001的橫向連結管道
  • ISO 23894 【AI風險管理評鑑，另以專文介紹】與 ISO 42001 【AI管理系統】直接配合，並與 ISO 31000 風險管理標準整合一致，適用於企業風險管理系統化作業及管理之需
  • ISO 42005：2025【資訊技術—人工智慧—人工智慧系統衝擊評鑑（Information technology — Artificial intelligence — AI system impact assessment）】
  • MITRE ATLAS 專門解決對抗性/安全風險
  • 國際經濟合作組織（OECD）人工智慧建議架構提供國際協調基礎指引。
為了遵守相關法規要求，大多數組織採用 NIST AI RMF 或 ISO 23894 作為其主要評鑑方法，並將額外的各國或區域性法規要求作為補充管制項目。

7. 參考資料


（全文竟）



張貼者： 於 沒有留言:
標籤： , , , , , ,
訂閱： 文章 (Atom)