---
title: "選擇性透明：企業公開邊界、延時揭露與資訊主權"
english_title: "Selective Transparency: Enterprise Disclosure Boundaries, Time-Delayed Revelation, and Information Sovereignty"
series: "AI 原生互動企業論"
series_en: "AI-Native Interactive Enterprise"
series_id: "ANIE"
paper: "10"
part: "第四部：企業資訊治理、競爭力與實證"
author: "Neo.K"
institution: "一言諾科技有限公司（EveMissLab）"
research_assistance: "GPT-6（文獻與法規核對、理論形式化、實證設計、技術規格及原稿檢查）"
version: "v0.1"
date: "2026-10-17"
language: "zh-TW"
status: "Public Working Paper / Conceptual and Technical Methodology / Not Peer-Reviewed"
canonical_source: "UTF-8 Markdown"
math_delimiters: " $...$ and $$...$$ only"
research_status: "Conceptual proposal and prototype specification; no field deployment or statistical evidence is claimed"
external_sources_checked: "2026-10-17"
related_papers:
  - "ANIE-00 — 從產品黑盒到 AI 原生互動企業"
  - "ANIE-07 — Steam 不是唯一入口"
  - "ANIE-08 — 從客服結案到產品認知"
  - "ANIE-09 — 公開決策帳本"
  - "APBSC-00 — AI Agent 公開邊界與安全閉包"
  - "APBSC-08 — 供應商與平台責任：AI Coding Tool 的 Publication-Boundary Governance"
  - "ANIE-11 — 開放會削弱競爭力嗎（後續）"
---

# 選擇性透明：企業公開邊界、延時揭露與資訊主權

## Selective Transparency: Enterprise Disclosure Boundaries, Time-Delayed Revelation, and Information Sovereignty

**《AI 原生互動企業論》ANIE-10｜第四部第一篇｜公開工作論文 v0.1**  
**作者：Neo.K｜機構：一言諾科技有限公司（EveMissLab）**  
**研究協作：GPT-6｜日期：2026-10-17（Asia/Taipei）**

**機構：** 一言諾科技有限公司（EveMissLab）  
**日期：** 2026-10-17  
**版本：** v0.1  

---

## 摘要

企業資訊治理長期容易落入兩種錯誤的二元對立：要麼公司保留內部資訊，外部只能閱讀公告、促銷內容、法定揭露或客服回覆；要麼把「透明」理解為所有決策、原始資料、研發細節與營運紀錄都應即時公開。前者難以支援真正的外部檢驗與持續協作，後者則忽視個人資料、第三人權利、商業秘密、資安、契約、產品敘事、談判與決策形成的合理保密需求。生成式 AI、Agent 與跨平台資訊系統降低了整理、查詢、解釋與發布資訊的成本，使上述二元分類越來越不充分；但 AI 同時放大大規模錯誤公告、過度摘要、上下文外洩、提示注入及未經授權之自動發布的風險。

本文提出「**選擇性透明**」（Selective Transparency）之 AI 原生企業治理框架，主張企業資訊的外部可見性不是一個固定的公開／不公開開關，而是一個受**法規、權利、授權、目的、對象、時間、資訊精度、資訊形態、證據品質與安全風險**共同約束的公開決策問題。本文承接 ANIE-09 的公開決策帳本（PDL），提出一種「內部完整事件與權利脈絡—經授權之公開投影—外部可檢查之理由與結果」的多層機制。企業可以不公開內部談判價格、秘密演算法或個別客戶工單，仍能向利害關係人交代某項產品決定是否作出、何時改變、延期原因類型、目前可驗證的成果與可提出異議的途徑。

這不是主張企業公開越多越好，也不是創造一個凌駕法律與他人權利的「資訊主權」。本文所用「**企業資訊主權**」是狹義的**企業對其依法有權管理的資訊所具有的選擇、授權、治理及責任能力**；它不意味公司擁有個人資料當事人全部權利、第三方素材著作權、合作方機密或法定揭露義務之豁免權。本文將**可公開、應公開、不得公開、現在不宜公開及僅向特定對象公開**分為不同的規範集合，並提出延時公開的條件、到期重審、爭議升級和事故例外機制。

研究參照包括 Henkel（2006）關於開放創新中選擇性揭露的經驗研究、Fox（2007）對透明與問責之非必然關係的分析、FIRST TLP 2.0 的分享邊界、NIST AI RMF／Privacy Framework、ISO/IEC 29147 的協調式漏洞揭露、英國 Algorithmic Transparency Recording Standard 的雙層可讀資訊，與臺灣個人資料保護、營業秘密、消費者保護、廣告及公司揭露的不同法規脈絡。[E01]–[E13] 本文不宣稱上述制度為新發明；原創研究定位在於把它們與**AI 公開編譯器、時間化解密／重審規則、事件的受控投影、可反駁的透明品質指標及企業—外部多主體互動**整合為可操作之假說與方法。

本文提出十項必要概念區分、七維公開決策向量、法定義務優先的可行集合、至少五層企業資訊域、十二項可反駁假說、四組實驗對照、八個失敗與成功情境，以及可供未來 MVP 開發使用的 JSON／YAML、資料表、授權測試與公開審核附錄。核心結論是：**公開更多資訊可以是 AI 時代企業合理的策略選擇；但透明的品質應依外界能否理解、檢查、異議與追蹤實際結果衡量，而非僅以公開位元數、公告數量或資料下載量衡量。**

本文尚未經同儕審查；數學與門檻均為建模提案，不代表實測參數；所有識別碼、公告內容、角色、數據與案例均為合成研究示例，不代表 EveMissLab 已部署本系統或作出具體商業承諾。法律討論為研究資訊而非個案法律意見，應以行為發生時的有效法規與具體事實為準。

**關鍵詞：** Selective Transparency、AI-Native Enterprise、Information Sovereignty、Disclosure Governance、Publication Boundary、Delayed Disclosure、Public Decision Ledger、Selective Revealing、Trade Secrets、Privacy、Coordinated Vulnerability Disclosure、Agentic Publication、Public Projection、Accountability、Information Asymmetry、Taiwan Law。

---

## 0．問題的重新定義：公開更多，不等於公開一切

### 0.1 從一款 EA 遊戲延伸至公司治理

本系列起點是搶先體驗遊戲如何向玩家交代持續開發、季度成果、非採納提案、MOD／PR 合作與產品交付，而不是將 EA 當作募資完成後的漫長黑盒。ANIE-01—09 逐步建立了持續交付、開發者接手、玩家—開發者相交域、MOD 共創、跨平台網站、AI 客服與公開決策帳本。但這些能力到達公司管理層時，會遭遇一個不可跳過的問題：**企業內部已經知道的資訊，不必然是企業有權、應當或適合向外發布的資訊。**

一名玩家提出修正遊戲存檔的建議，公司可以公開決議及修正狀態，但不應順便公開該玩家購買紀錄、住址、私人客服內容；與外部美術家簽約後，可以公開合作成果，但不代表要公開尚未授權的原始畫稿、合約價格、個人資料；有一個尚可被利用的安全漏洞時，應調整揭露速度與對象，而不是因季度公開制度而立即公布攻擊條件。

### 0.2 舊有「黑盒」有多重成因

不透明不一定等於刻意欺騙。至少有八種不同來源：法定或契約保密、競爭壓力、資訊發布成本、企業資訊系統割裂、對外誤解風險、資安風險、個資風險、缺乏授權及責任承擔機制。AI 的作用是降低其中部分成本，並提高跨系統資訊整理能力；AI 不會使全部保密理由消失，更不會自動產生合法授權。

企業可以不公布秘密配方，但公開產品的功能、測試結果及問題處理；可以不公開人事評價，但公開客服品質改善方案；可以不公開競標中的底價，但在適當時點公開合作完成事實。這表示企業對外公開的研究對象不是「秘密是否應該存在」，而是**一個個資訊項目在不同時間與不同受眾之間如何合法流通。**

### 0.3 核心問題

> 當 AI 能持續理解企業世界、彙整產品證據、與外部受眾對話時，企業如何在不放棄商業秘密、第三人權利與內部治理的前提下，對外公開更多具體、可追蹤、可更正且有解釋價值的資訊？

細分研究問題包括：哪些是法定必須揭露、哪些是自願揭露？哪些資訊即使已公開過仍不具合法再利用權？公開時間是否可因風險改變？不同受眾能否看不同精度但彼此不矛盾的版本？AI 可以起草什麼而不得批准什麼？怎麼讓企業的保密決策也有可被審核的理由？何種程度的選擇性公開會變成公關操弄？何時公開反而使使用者或社群受到傷害？

### 0.4 本文主張、非主張與優先級

本文**主張**企業應有能力對合法可公開的內容進行精度、時間與受眾管理，並讓具有公共產品意義的決策結果能被持續追蹤；公司即使拒絕公開部分證據，也應在合理可行範圍交代「未公開的理由類別、可提供的替代證據與重新檢討條件」。

本文**不主張**所有秘密都應解密，不主張公司可以憑內部政策限制法律上的資料主體權利，不主張企業可選擇不揭露依法必須揭露的重大事項，不主張外部投票替代公司法定決策權，不主張經匿名化就必然完全無風險，不主張 AI 可以自行代表公司作出有拘束力的承諾，也不主張公開摘要能替代經適用法律要求的原始紀錄保存。

若自願透明政策與有效法律、法院命令、監管要求、契約及他人權利衝突，必須先處理其法律關係。**法定最低義務不是企業可選擇揭露的上限，自願揭露也不是法定義務的替代品。**

### 0.5 與 ANIE-09 的精確邊界

ANIE-09 對「是否決策、是否承諾、是否交付、何種證據」建立資料物件與事件歷史；ANIE-10 不重新發明該帳本，而是研究：**某個內部事件與證據，如何形成不同對象、時間與詳略程度的公開投影；在何種條件下必須保留內部原文、提供替代說明、暫緩公開或撤銷既有公開內容。**

ANIE-11 將進一步檢驗此制度對市場競爭、信任資產、人才、社群創新及資訊不對稱的淨效果；本篇先處理必要治理條件，而不預先宣布開放策略已勝過保密策略。

---

## 1．既有研究與規範：哪些不是本研究的原創發明

### 1.1 選擇性揭露早已有企業經驗研究

Henkel（2006）研究 embedded Linux 企業的自願回饋與保護策略，以 268 份觀察指出企業在公開開發與保護商業智慧財產之間採取選擇性揭露，而非必須完全開源或完全封閉。[E01] 其研究對象、年代與樣本不可直接外推成 2026 年 AI 原生單機遊戲公司；它只足以支持「選擇性揭露是既有可觀察的商業行為」，而非「一定提升競爭優勢」。

### 1.2 透明不保證問責

Fox（2007）區分清楚與模糊的透明，以及軟與硬的問責，說明資訊可以被公布，卻不能因此保證公司改正錯誤。[E02] 本文繼承此限制：公開「本季已完成 90% 工作」的漂亮圖表，若無法指出測量範圍、版本、證據與未完成事項，並不構成充分的公共可理解性。

### 1.3 FIRST TLP 2.0：分享邊界不是財產權分類

FIRST TLP 2.0 使用 `TLP:RED`、`TLP:AMBER`、`TLP:GREEN`、`TLP:CLEAR` 表示不同資訊分享範圍。[E03] 但 TLP 自身明言它不是正式資訊機密等級、著作權授權、加密與存取控制標準，且不改變法定資訊公開義務。因此本篇採用 TLP 的**受眾邊界思路**，不把公司的分類 `PUBLIC`、`RESTRICTED`、`SECRET` 冒稱為 TLP 標準，也不把 `TLP:CLEAR` 誤解為任何人有權改作或商業再利用。

### 1.4 NIST 對 AI 風險與隱私治理的分工

NIST AI RMF 1.0（2023）的 Govern、Map、Measure、Manage 係自願性風險框架；NIST Privacy Framework 1.0（2020）把隱私視為組織風險管理工作，而不僅是遮蔽欄位。[E04][E05] 本文將「設計可公開的內容」與「防止資訊受未授權使用」同時當作工程需求；不能因 AI 產出符合格式就推論所有法律與安全風險已消除。

### 1.5 分層的可讀說明已有公共部門先例

英國的 Algorithmic Transparency Recording Standard（ATRS）以面向一般民眾的第一層和面向專業讀者的第二層資訊幫助解釋演算法工具及其使用理由，並要求注意供應商智慧財產與資安風險。[E06] 這是**特定英國公共部門制度**，不能被宣稱為台灣私人公司依法必須遵守的規範；可借鑑的是「同一事實依受眾需要提供不同細度，但不能捏造相互衝突版本」。

### 1.6 延時揭露有合法且必要的安全場景

ISO/IEC 29147:2018 對漏洞通報、協調與補救資訊揭露提出要求及建議，其目標包括減少漏洞遭利用的風險。[E07] 因此安全漏洞可以先告知受影響供應商、合作夥伴與相關單位，再依風險、修補可用性與義務公開；它不是將所有安全問題永久保密的藉口。當適用法規要求通知、通報或其他行動時，研究性延時公開政策不得取代該義務。

### 1.7 臺灣法律的幾個不同關係

《營業秘密法》第 2 條列出非一般所知、因秘密性具有實際或潛在經濟價值、採取合理保密措施等要件。[E08] 不是公司自己貼上 `CONFIDENTIAL` 就一定成為法律保護的營業秘密；反過來，盲目公開某些技術與商業資料可能影響其秘密性。

《個人資料保護法》第 3、5、11、19、20 條等規範資料當事人權利、目的必要性及非公務機關蒐集／利用等要求。[E09] 2025 年 11 月 11 日修正中，部分條文的施行日期由行政院另定，截至本稿核對的官方現行法規頁仍標示部分或全部尚未生效，不能把未生效新增規定直接寫成已生效義務。合法性判斷須對應行為日期與適用版本。

《消費者保護法》第 22 條要求廣告內容真實，並規定對消費者的義務不得低於廣告內容。[E10] 《公平交易法》第 21 條處理虛偽不實或引人錯誤的商品／服務表示。[E11] 因此公司在官方網站、社群或 AI 客服輸出的敘述，不會因標籤寫著「透明研究」就不再具有消費者或廣告上的意義。對上市櫃公司，證券市場資訊揭露義務另有特別制度；台灣證交所說明重大及定期資訊透過公開資訊觀測站申報。[E12] 小型未上市公司與上市櫃公司的法定義務不能直接等同。

### 1.8 Agent 的可讀資訊，不等於可發布資訊

EveMissLab 既有 APBSC-00／08 將 `Observed`、`Authorized`、`Persisted`、`Published`、`Externally Obtainable` 拆為不同階段，並指出 scanner、測試與審查全部 PASS 不自動證明發布內容不存在隱私或語義外洩。[I10][I11] ANIE-10 承接這一點，將它擴展為公司整體資訊治理與外部公共互動：AI 的閱讀權、分析權、摘要權、草稿權、排程權及正式公開權必須是不同權限。

---

## 2．十項不可合併的概念區分

1. **知道，不等於有權公開。** 一名管理者或 AI 可能合法閱讀資訊，但公開權需要另一個根據。
2. **有權公開，不等於現在適合公開。** 遊戲劇情、談判或安全細節可能需要合理時機。
3. **應依法公開，不等於企業可以自由選擇延期。** 必要的通報與揭露優先於自願透明策略。
4. **保密，不等於永遠無法向任何人分享。** NDA、指定合作對象或責任單位的限定分享不同於對全網公開。
5. **匿名，不等於不可重識別。** 少數樣本、時間戳、交叉資訊與向量特徵仍可能識別人。
6. **可閱讀，不等於可轉售或再授權。** 作品使用權、著作財產權、個資處理依據與 API 存取權不能混作一體。
7. **公開更多，不等於更容易理解。** 無結構的大量資料可能比有來源的摘要更模糊。
8. **不同受眾、不同精度，不等於可以互相矛盾。** 摘要不能誤改客觀事實或隱藏直接影響交易的重大條件。
9. **公司的資訊治理權，不等於對所有資訊擁有所有權。** 客戶、員工、合作方及法律制度保留各自權利。
10. **未公開，不等於沒有決策或沒有問責。** 必要時仍應保留內部簽核與依法可供查核的證據。

這十項分離構成本篇後續模型的最小規範集合。

---

## 3．企業資訊主權：治理能力，不是全能排他權

### 3.1 術語的狹義定義

本文稱「企業資訊主權」（Enterprise Information Sovereignty，EIS）為一種**依既有法律與權利結構配置的資訊管理能力**：企業可在授權範圍內決定如何整理、保存、限制存取、選擇性公開、改寫公開投影、安排時序，以及承擔其決定帶來的責任。

「主權」在此是一個組織治理的比喻，**不是國家主權、物權、自然人資料自主權或對所有內部資訊的絕對支配權**。此術語不應用來排除合法監管、法院裁判、消費者權利、員工權利、第三方授權條款與現行法律。

### 3.2 複數權利來源

同一項資料可能有多方權利或合法利益。例如由外部 MOD 作者貢獻的角色素材，同時涉及公司正式整合意願、作者權利、其他第三方素材授權、平台條款以及玩家在產品中的使用許可；公司握有檔案，不代表其必然取得完整著作財產權。員工的個人資料和工作產出，也不可因「企業世界狀態」這種建模方式就被看作完全相同的資產。

因此，應分別建立 `information_custodian`（保管者）、`rights_holders`（權利主體）、`decision_authority`（決策權）、`release_authority`（發布權）、`affected_subjects`（受影響人）與 `legal_basis`（法律或契約基礎），不得只以單一 `owner=company` 欄位判定所有權限。

### 3.3 自主與義務同時存在

公司可以保有產品設計方向、商業策略與合法保密空間，但當公司向消費者公開聲稱「已發布某功能」時，就應接受其真實性與可驗證性的約束。外部可以質疑公司敘述是否屬實，並不因此取得內部全部文件的存取權；公司可以拒絕沒有權利基礎的內部資料請求，也不能用拒絕公開來逃避依法應提供或應履行的事項。

### 3.4 不應以資訊量代替企業倫理

大量公開文件不一定代表更負責任。一家公司可能公開數千份更新日誌，卻在已知嚴重存檔損毀問題上遲遲不承認；另一家公司只公布簡短但有精確版本、影響範圍與修正證據的公告，反而能讓玩家更清楚理解問題。本文因此使用**公共認知品質**而不是「公開文字數」作為評估方向。

---

## 4．五層資訊域與三種正交政策

### 4.1 五層企業資訊域

建議的層級是一套**本研究提出的企業分類**，並非引用某個國際標準的正式等級：

| 層級 | 本研究代碼 | 可能受眾 | 典型內容 | 控制重點 |
|---|---|---|---|---|
| 公開域 | `PUBLIC` | 全部公眾 | 已審核產品進度、版本證據、公開決策理由 | 真實性、可引用性、易理解、修正 |
| 限定共享域 | `LIMITED` | 有合法目的之指定合作方或客戶 | 接手文件的非秘密部分、特定測試資訊、協調修補摘要 | 角色、目的、契約、到期 |
| 內部域 | `INTERNAL` | 授權員工及內部 Agent | 產品排程、非公開會議摘要、內部進度 | 最小權限、保留與稽核 |
| 高度機密域 | `CONFIDENTIAL` | 必要且授權的特定角色 | 商業底價、未公開技術、關鍵合作條件 | 強授權、雙人審核、用途限制 |
| 封閉保護域 | `PROTECTED` | 依法或特定政策嚴格限縮 | 憑證、敏感個資、未修補高風險漏洞細節 | 原則不進入一般 AI／公告工作流 |

層級表示**資訊洩漏與一般分享風險**的初步分類，並非簡單的線性「有權讀上一層就有權讀所有下一層」。例如財務工作者有權檢視部分 `CONFIDENTIAL` 商業數字，也不必因此有權閱讀其他部門的私人客服紀錄。實際權限仍取決於角色、目的、資料主體、工作情境及授權紀錄。

### 4.2 另有三個不能從層級推導的政策維度

**第一：合法性（Legality）。** 公開權源、強制揭露義務、不得揭露限制、第三方著作權與資料處理依據。

**第二：時間性（Timing）。** 現在、特定事件後、固定日期後、必要審核後、依法立即通報、無法預定。

**第三：表示精度（Granularity）。** 原文、可核對摘要、抽象理由類別、聚合統計、去識別化案例、只能回覆不存在或不便提供。資訊分類較低，不代表必須公開原文；高敏感項目在合法情況下也可能公開完全去敏的結果摘要。

### 4.3 個別屬性，而不是整份文件一次定級

一份季度報告可能同時包含可公開的更新版本、需延後公開的劇情、不得公開的外包個人聯絡方式，以及尚未得到允許的外部素材。若整份文件只打一個標籤，容易出現「因少數內容不能公開而整份放棄公開」或「因大部分內容可公開而不小心連秘密一起公開」。因此應支援段落、欄位、附件、圖像與外部引用的細粒度分類，並承認它會增加管理成本。第一代 MVP 不需把所有文字詞元逐字分級，但必須具備**敏感區塊可以被明確排除**的能力。

---
## 5．七維揭露決策向量：從是否公開到如何公開

### 5.1 決策單位應是「資訊物件—用途—受眾」

令 $x_i$ 為一個具有來源的內部資訊物件，可能是事件、測試證據、客服個案、決策紀錄、合約附錄或技術文件。針對 $x_i$ 的公開方案不應只有布林值，而應定義為：

$$
d_i=(a_i,t_i,g_i,f_i,c_i,p_i,r_i)
$$

其中：

- $a_i$：audience，誰能取得資訊；
- $t_i$：timing，可開始取得的時間或觸發條件；
- $g_i$：granularity，資訊的詳略與精度；
- $f_i$：form，原文、摘要、結構化資料、統計、可視化或別的形式；
- $c_i$：channel，官網、Steam、GitHub、受限合作區或指定通知通道；
- $p_i$：purpose，實際公開目的及允許使用範圍；
- $r_i$：review，核准者、重新審核條件與撤回路徑。

這個向量描述治理方案，不代表法規允許任何向量組合。單一事項可有多個合法方案，例如同一項補丁進度可以對合作測試者提供詳細版本資訊、對一般玩家提供易讀摘要；兩者必須保持事實相容。

### 5.2 揭露方案之硬性可行集合

對任一資訊物件 $x$，令 $\mathcal{D}_x$ 為所有候選揭露方案的集合。考慮依法必要之授權、個資、契約、供應鏈與安全約束，定義：

$$
\mathcal{F}_x=\{d\in\mathcal{D}_x:\;L(x,d)=1,\;A(x,d)=1,\;R(x,d)=1,\;S(x,d)=1\}
$$

其中：

- $L$：適用法律與法定程序容許；
- $A$：決策與發布權限完整；
- $R$：第三人資料、智慧財產與契約權利已處理；
- $S$：必要的安全處置、限制與風險控制已達要求。

當某項義務要求立即通知特定當事人時，相關方案的合法性不能因公司內部安排了下一季發布而改變。**硬性義務先決；成本、行銷效果與偏好只能在合法可行集合內優化。**

上述 $L,A,R,S$ 均為需要實際證據支持的判定函數，不是讓 AI 任意輸出四個 `true` 就獲得授權。證據缺失應產生 `UNKNOWN`、升級審查或阻止發布，而不是自動視為通過。

### 5.3 強制揭露與自願揭露不可混用同一個最佳化問題

定義在資訊項目 $x$ 上的義務集合：

$$
O_x=\{d:\;d\text{ satisfies applicable mandatory obligations}\}
$$

其中 `mandatory` 所需內容與期限取決於實際法律、契約與既有有效對外義務。若 $O_x$ 非空，公司必須先確保義務所要求的行為；其後的自願性額外資訊公開才可進入效益權衡。某些義務是向特定當事人或主管機關通知，而非向所有人公開，二者不得混淆。

對合法自願方案，才提出研究性的多目標選擇：

$$
d_x^*\in\arg\max_{d\in\mathcal{F}_x}\;\Big(B_{\rm comprehension}(d)+B_{\rm cooperation}(d)+B_{\rm accountability}(d)-C_{\rm publication}(d)-R_{\rm privacy}(d)-R_{\rm security}(d)-R_{\rm competition}(d)\Big)
$$

此式是**概念性效用分解**，不是有實測權重的決策引擎。各項量綱並不天然相同，不能未經校準直接相加；工程原型可改以 Pareto 可行方案、風險等級及人類審查呈現。法律、生命安全及明確禁止條件，不應被當成只要商業收益夠高便可以支付代價的軟性懲罰項。

### 5.4 公開投影不等於內部原始世界

令 $W_t^E$ 為內部授權可觀察之企業世界狀態， $P_t^a$ 為給受眾 $a$ 的公開投影：

$$
P_t^a=\Pi_{a,t,g,f,p}(W_t^E;\Gamma_t)
$$

其中 $\Gamma_t$ 是法規、權限、權利、風險與發布政策的集合。投影可以是節錄、聚合、去識別化或可驗證摘要；一般不能反推出完整企業世界狀態。對外展示的資訊與原始內部資料的差異應有來源、規則版本及批准紀錄，否則就可能成為難以稽核的「公關重寫器」。

### 5.5 觀察到的真實不能被摘要改造成另一種真實

若原始可驗證事實是「修復候選通過內部測試，尚未公開發布」，對外可以改寫為「修復目前進入發行驗收階段」，但不能變成「已為全部玩家修好」。這是資訊投影的**忠實性約束**。允許減少細節，不允許藉由省略重大條件製造與已知證據相反的印象。

可形式化為：

$$
\operatorname{Consistent}(P_t^a,E_t)=1
$$

其中 $E_t$ 是於時間 $t$ 有效的已審核證據集合；`Consistent` 需由具體語義規則、範例、測試與外部抽樣共同支撐，不能僅以語言模型自我評價判定。

---

## 6．延時揭露：不是「到了某一天就自動全部解密」

### 6.1 四種不同的時間

對每個事件至少區分：

- `occurred_at`：事件實際發生的時間；
- `known_at`：企業有可信方式知悉事件的時間；
- `approved_at`：相應權限批准特定公開方案的時間；
- `published_at`：資料實際能被外部取得的時間。

在必要時增加 `legal_due_at`、`scheduled_review_at`、`release_condition_met_at` 和 `retracted_at`。它們可能不同。**公開得晚，不應更改事件原始發生時間；企業知悉得晚，也不能透過回填資料假裝早已通知。**

### 6.2 延時揭露的主要原因

合理的暫緩類別包括：（A）尚未完成驗證；（B）合作契約或保密義務；（C）正在進行的商業談判；（D）尚未修補的安全風險；（E）未正式發布的劇情與內容；（F）需要取得第三方權利或當事人授權；（G）為避免對外產生未經批准承諾；（H）依法有特定發布或通知時機。

不可將「不想讓玩家知道本季失敗」直接包裝成合理保密類別。若產品已對外承諾季度目標而該目標延期，通常可以公開事實與經核准的原因類型，而不用公開所有內部原文。**內容保密與對結果交代責任可以並存。**

### 6.3 日期與事件混合式重審

資訊分類不能只依日期機械自動降級。某項資料在與合作方終止保密條款後可能適合公布，但另一項資料即使過去十年，若含有第三方個資或仍有效的安全憑證，也不應自動公開。建議：

```text
Draft / Internal
      │
      ▼
Eligibility Review
      ├─ statutory duty now -> required disclosure / notification channel
      ├─ prohibited / unlawful -> deny and document restricted reason
      ├─ missing rights / unknown -> hold + escalate
      ├─ conditions not met -> schedule event-based re-review
      └─ eligible + approved -> publish controlled derivative
                                       │
                                       ▼
                         Monitor / Correct / Restrict / Withdraw
```

可設定 `review_by` 提醒重審，卻不應讓 `review_by` 等於 `auto_publish_at`。對安全通報與事件應變，實際必須依法及風險即時處理，不應依固定季度日程延後必要通知。

### 6.4 重新分類與重新發布的不同

內部資訊從 `CONFIDENTIAL` 重新分類為 `INTERNAL`，只改變授權存取條件，不代表可對全網發布。需要一份獨立且經批准的 `PublicationDecision`，連結被批准的輸出 artifact 的位元組或可驗證內容摘要、用途、時間、對象與審查紀錄。

### 6.5 在延時期間是否能公開「存在性」？

某些情境可以說「此議題正在評估，無法提供細節」；但某些情境連議題存在本身也可能洩漏重大商業談判、尚未公開安全弱點或當事人身分。對外是否允許存在性聲明，也是一個須審核的公開決策。若涉及法律通報、契約或使用者安全權益，不能僅以「尚未公開」對抗應有義務。

### 6.6 時間化承諾的特殊風險

若公司公開「預計本季完成」，這個句子可能只是規劃，也可能在特定交易與語境構成具體期待；無論內部分類為何，不能假設用 `estimate` 標籤就自動免除消費者保護相關責任。公開時間管理必須與 ANIE-09 承諾語義及實際發布證據聯動，並保留原始版本與更正時間。

---

## 7．受眾、精度、語言與說明責任

### 7.1 同一事項至少有三種可能的公開物件

對某個玩家存檔缺陷：

- 給直接受影響玩家：可依法且在必要範圍提供其個案的修復建議、測試安排與回覆，不能附上其他玩家的紀錄；
- 給全體玩家：提供受影響版本、問題嚴重程度、修復進度、已知限制與後續公告入口；
- 給授權外部 MOD 維護者：可能提供非公開的 API 相容性、測試資料及限定用途的遷移文件。

三者的措辭與細節不同，不構成造假；但三者對共同事實——例如問題是否仍存在——不能互相矛盾。差異必須來自合法必要之個別化、精度與用途，而非操弄受眾。

### 7.2 說明責任可以分為三個深度

**公共簡述層：** 一般使用者能理解「公司決定了什麼、狀態如何、有哪些可驗證結果」。

**證據導覽層：** 提供可查核版本、公開測試摘要、更新日誌、決策編號、發布時間與限制。

**限定審核層：** 依法或依合約由指定人員核對部分原始證據，例如第三方稽核、授權合作對象、個別資料當事人的權利請求。這不是開放給所有人的高級會員區，而是有權限來源的受限工作流。

### 7.3 必須避免以「彈性用語」遮蔽已知問題

若已有強證據顯示某項功能未交付，不能只公開大量技術進度，把尚未可玩的結果藏在最末一行；若外部通道的簡化摘要與詳盡版本不同，應檢查一般讀者是否會被引導到錯誤結論。本文在實驗中將測量「閱讀後對實際狀態的判斷準確率」，而不是只測是否喜歡公告。

### 7.4 產品敘事與劇情保密

遊戲公司不公開最終劇情、角色命運、隱藏任務及尚未公布的遊戲機制，通常不等於對玩家不透明。可分離「劇情內容本身」與「內容是否完成、是否已經過測試、是否屬正式版本」兩類資訊。對於會嚴重破壞體驗的細節，至少可提供可由玩家自行選擇開啟的 spoiler 標記，而非自動向所有人公開全部劇情。

### 7.5 語義承諾比文字數量重要

同一資訊輸出成中文、英文、日文或圖示時，需保留關鍵語義：`正在評估` 不應譯成 `已批准`，`內部測試` 不應譯成 `正式發布`，`暫不提供` 不應譯成 `永不提供`。AI 可以輔助多語翻譯，但對涉及承諾、退款、安全或權利的文本應建立額外確認。

---

## 8．企業資訊流不是資料庫備份：公開編譯器的概念

### 8.1 由原始資料到對外可理解文本

未來可建立「揭露編譯器」（Disclosure Compiler，DC）：它不直接把企業內部所有資料交給網站，而是讀取受授權的事項、證據及權利政策，生成多個候選公開投影，再經驗證、授權及發布。

```text
Internal Evidence / Decision / Support / Product States
                         │
                         ▼
               Authorized Input View
                         │
                         ▼
      Eligibility + Rights + Purpose Classification
                         │
                         ▼
            Candidate Public Projections
                         │
                         ▼
      Fact Fidelity + Privacy + Security + Legal Gates
                         │
             Approval / Rejection / Rework
                         │
                         ▼
                Publication Manifest
                         │
                         ▼
        Steam / Website / GitHub / Customer Channels
                         │
                         ▼
          Readback / Correction / Reassessment
```

其中「編譯」是研究比喻，指具有定義明確的輸入、約束、輸出與可驗證條件，不是宣稱大語言模型可以形式證明全部法律語義。

### 8.2 必須有正向允許清單

對 AI 的公開編譯輸入，應是經處理的 `AuthorizedInputView`，而不是整個 CRM、私人 GitHub 或企業母 AI 的無邊界上下文。若本次任務只需公布第 1.3 版的存檔修復進度，就不應自動允許 AI 讀取財務憑證、人事資料與未公開業務策略。輸入最小化能降低錯誤引用與外洩面。

### 8.3 隱藏原文仍可能在摘要中洩漏

假設 AI 避開姓名，但在公開摘要中寫出「本週唯一一位住在某小鎮、購買特定付款方案的玩家」，仍可能使其他資料來源把受害者重新識別。類似地，使用 AI 對商業談判文件做摘要，有時會間接洩漏價格範圍、競爭優勢與供應鏈關係。這種**語義外洩**無法只靠字串比對或祕密掃描器攔截。[I10][I11]

### 8.4 產生草稿與批准發布必須分離

`draft:write`、`evidence:read`、`publication:propose`、`publication:approve`、`publication:execute`、`publication:withdraw` 應是獨立能力。AI 可在低風險項目協助產生草稿與檢查跨平台一致性；正式批准仍取決於明確的公司授權與政策。在未經驗證的高度敏感場景，AI 不應成為唯一發布者，亦不應經由社交媒體工具直接繞過企業政策。

### 8.5 對外渠道的能力差異

Steam 公告、網站、GitHub Release、Issue、PR 與客戶電子郵件，各有不同平台政策、可編輯性、保留方式與受眾。發布一篇公告不能推導 GitHub 專案已開源，接受 PR 不能推導商業修改權已清理，私人客服回覆也不等同公司面向所有使用者作出承諾。跨平台發布系統要保存原發布來源、審核者、版本、目的與回讀確認；不應宣稱每個平台提供同等 API 發文權限。

### 8.6 公開摘要可以比原始資料更危險

原始資料可能分散在不同需登入的位置，AI 一次彙整後反而讓競爭者、騷擾者或攻擊者更容易推斷個人身份、供應鏈弱點與進度瓶頸。因此揭露風險不能只比較「摘要是否含有逐字秘密」；還要衡量**交叉聚合、可搜尋性、可引用性與大規模傳播帶來的次生風險**。

---

## 9．公開真實性、內部真實性與可驗證性的三層區分

### 9.1 三個不同命題

**內部事件紀錄真實**：事件確實按該時間與狀態發生，且內部證據可支持。

**公開敘述忠實**：在經過必要刪減與抽象後，沒有改造或扭曲原本可支持的關鍵事實。

**外部可驗證**：外部在被授權的範圍內有足夠證據，能判斷某些重要主張是否成立，而非只能相信公司自行宣告。

三者互不推出。例如公司的內部測試真實成功，但公開宣稱玩家已全面修復可能不忠實；公開摘要忠實，卻因涉及保密的第三方測試，外部未必能直接重演；外部看到簽章檔案也不保證內容事實為真。

### 9.2 公開拒絕細節不必等於拒絕問責

對有公共產品意義的決策，若不能完整公開理由，仍可在不損害權利與安全的範圍內提供理由類別，例如「第三方授權未完成」「現階段效能風險尚未解決」「與遊戲核心設計相衝突」「安全風險，待修補後公開細節」。但理由類別也可能本身過度敏感，因此仍需個別評估。**不能以形式上的 `CONFIDENTIAL` 永遠終止所有異議與再審查。**

### 9.3 隱私與公共修正的矛盾

ANIE-09 提議公共帳本保留變更歷史；但含有個人資料的事件不能因此變成不可刪除。可採「可刪除的私人內容—經審核的公共摘要—合法必要的最小更正事件」三層隔離。公開頁面撤回後，也應避免保留會重新暴露秘密的縮圖、快取、附件或可猜測雜湊。公司須承認無法保證外部平台快取在一瞬間完全消失，因此正式發布前的邊界檢查更重要。

### 9.4 公開修正可以增加可信度

公司若錯把「預計」寫成「已確認」，理想的行為不是悄悄更改句子，而是清楚標記更正理由、時間、受影響通道與修正後版本；必要時針對已被誤導的對象另行通知。修正歷史應避免再次暴露原本被錯誤公開的私人資訊；存在性通知與全文保留不是同一件事。

---
## 10．規範優先序：強制揭露、權利限制與自願公開

### 10.1 不應創造「企業一切皆可自決」的錯誤印象

公開治理可分為至少四種判斷路徑。

**A. 法定或已有有效義務之揭露：** 必須依適用規則在指定時間、向指定主體、以指定內容或程序執行，不能由公司自行下調揭露義務。例子可能涉及消費者應有資訊、個資事故通知、依法須提交給主管機關之資料、公開發行公司之法定財務或重大訊息。各項義務的成立條件完全不同，不能用「所有公司都應公布季報」這類簡化語句概括。

**B. 法律或第三人權利限制之禁止揭露：** 權利尚未清理的外部素材、無合法依據之私人資料、未經同意的合約機密或涉及犯罪風險的資訊，可能不具公開權源。禁止揭露不必然永久有效，但在缺乏足夠授權或例外理由時不可先發後補。

**C. 合法但需要限定受眾或時序之揭露：** NDA 下的專案文件、對特定客戶的資訊安全通知、合作夥伴的預發行測試資料、適合受控揭露的修補資訊。這一類需要細緻的受眾界線與記錄。

**D. 可自願選擇的公開：** 開發週報、經過審核的內部取捨理由、非機密的功能比較、公司選擇公開的季度成果、社群建議回應。這一層最適合研究 AI 是否能降低公開成本與提高解釋品質。

### 10.2 公開平台不能替代權利申請與法定程序

即使網站提供 `privacy_request` 或 `safety_report` 按鈕，也應有能處理正式資料主體權利與安全事件的內部程序；公開提案投票不能直接等同法律上有效同意；針對特定當事人的通知，也未必能以發一篇公開公告代替。平台的互動便利性不自動改變法律所要求的形式與期限。[E09][E10]

### 10.3 防止「自願公開」侵蝕營業秘密

《營業秘密法》的合理保密措施不是紙上制度。若公司長期在公開網站散布內部路線、演算法細節、採購底價、供應商折扣與完整設計參數，日後可能難以單純主張它們始終受秘密性保護。因此實施 ANIE 不是要求管理者「更勇敢地公布一切」，而是要求在公開前知道自己真正打算保留什麼、為何保留、哪些替代說明足以達成外部合作目標。[E08]

### 10.4 適用主體與地區不相同

EveMissLab 在台灣有公司登記，但遊戲可能面向跨境 Steam 玩家、MOD 作者及合作商。網站使用者來自不同地區時，國際資料傳輸、平台協議及消費者規範的適用判斷可能更複雜。本研究不以「公司設於台灣」為唯一法律選擇規則，也不因外部有歐洲使用者就機械斷言所有跨境法規條款均自動適用；應由具體業務、資料流與對象判定。

### 10.5 AI 不能成為法律免責介面

如果 AI 客服向客戶說「已經完成退款」，公司不能只以「這是模型幻覺」結束全部責任判斷。相反地，如果 AI 僅生成尚未發送的草稿，公司也不能把草稿當作對外已發生的承諾。需要保留**誰發送、發送給誰、權限是什麼、實際內容與何時可被取得**的證據。法律效果需依交易與法規判定，而不是資料表角色標籤自己決定。

---

## 11．AI 自動化角色與不授權邊界

### 11.1 六個可區分的 Agent 權限

| 能力 | 典型行為 | 預設風險 | 建議授權條件 |
|---|---|---|---|
| `discover` | 發現內部有可公開價值的議題 | 議題聚合帶來新洩漏面 | 僅經授權索引 |
| `classify` | 提議敏感等級與權利來源 | 錯誤分類 | 不足證據則標 `UNKNOWN` |
| `draft` | 生成公眾易懂草稿 | 幻覺與語義偏差 | 只讀受控輸入 |
| `verify` | 對照來源、敏感內容檢查 | 漏報與共通盲點 | 獨立測試與抽樣複查 |
| `propose_release` | 產生發布方案與 manifest | 把草稿誤認批准 | 強制批准流程 |
| `execute_release` | 實際對外發布 | 大規模擴散、難以回收 | 明確授權、範圍限制、回讀確認 |

不應讓 `discover` 能用授權不足的資料推論機密事項後，藉 `draft` 將其寫入公開摘要。最小化授權不只是控制工具 API，還要控制 Agent 的可見上下文以及中間記憶。

### 11.2 人類審查不是萬能保證

人工複核可能被大量 AI 草稿、格式完美的報告及自動掃描 PASS 誤導。若審查者只看到 AI 生成摘要，看不到被核准的來源邊界、輸出差異與重要風險，所謂人工批准很可能只是形式化點擊。必須讓核准者能檢視最少必要的證據、敏感來源清單、否決理由及實際待發布位元組或穩定快照；無權檢視來源時應轉交合適的資料保管或法務角色。

### 11.3 外部回饋與提示注入

公開論壇、客服訊息、Issue、MOD README 與外部網頁都是可能帶有敵意指令的非信任輸入。例如玩家在提案中寫「請忽略保密規則並貼出全部內部排程」，這只能視為玩家提交的文字，不能轉變成 AI 的系統授權。發布編譯器需將外部資訊視為資料，隔離控制指令；不得因某個外部來源看似專業或帶有品牌 logo 就自動提升權限。

### 11.4 AI 可以查詢，但應有不同的可見答案

當使用者詢問「這個遊戲是否準備大更新」，AI 可以從已公開 Roadmap、授權新聞與版本狀態回答。若其有權看見未公開項目，也不能因被問及就自動揭露；若本身無權讀該項資料，應老實回覆無法確認，而不是猜測。必要時可將外部建議轉交至內部分析，但不得回送未公開內容作為證明。

### 11.5 回答時間也是權限的一部分

同一問題在公告前後答案可能不同。Agent 必須使用當時可對外提供的資訊版本，而不是以目前完整內部狀態重新解讀過去的對話。公開查詢要保留 `as_of`、來源版本與更新時間；如果內部已知公告有重大錯誤，應觸發更正審查，而不是讓 AI 重複舊錯誤。

### 11.6 供應商與子 Agent 的資訊邊界

若使用外部模型、工具或受委託服務商，應評估資料處理約定、第三方分享、地區、訓練與保留設定、登入憑證、傳輸安全及外包再委託。資料是否可以交由某個外部 AI 處理，不等於可以由公司公開網站全網展示。權限路徑需要跨越每一個外部服務都可追溯，不能只記錄最後由「AI 自動完成」。

---

## 12．公開與安全的對抗情境：不只防止秘密文字直接出現

### 12.1 直接資料外洩

員工、Agent 或自動同步程序把私人檔案、Token、原始支付資料、未公開合約或第三方素材錯誤上傳。這種情況必須有發布前負面測試、憑證與個資偵測、出站阻擋、撤回／通報程序。但秘密掃描只能涵蓋其規則內的已知類型，不保證資訊語義安全。[I10]

### 12.2 聚合與重識別

「某個特別稀少版本的唯一付款用戶提出退款」可能在小社群中直接指向當事人；公開每個玩家的模組、城市、時區與錯誤堆疊也可能形成可識別組合。需評估群組大小、可交叉來源、追蹤粒度、時間泛化及稀有類別；不能預設改掉名字就達到匿名化。

### 12.3 跨時間資訊拼圖

公司每個季度分別公布部分技術路線、供應商更新與系統負載，單獨看都不含秘密，但跨季度串接可能讓競爭者推測核心成本結構。這不是絕對不公開的理由，卻提示公開審查應考慮過去已發布內容形成的累積資訊量。

### 12.4 延時揭露被濫用

內部主管可以不斷延長 `review_by`，使「安全理由」變成掩蓋產品失敗的永久黑盒。建議對每次延長都保留內部理由、批准者、客觀觸發條件與下次重審時間；有公共告知責任的事項，應考慮能否公開經核准的延期存在性與最小理由。對外未公開的資料不一定能向所有人說明，但內部審核必須有可追溯性。

### 12.5 公開事件本身造成威脅

例如在尚未修補前公告某個伺服器對特定舊版協定缺乏驗證，可能提高攻擊者的效率。處理時應先採安全事件工作流與法定通報評估，再決定補救公告的時機與精度；若存在迫切使用者保護需要，應優先提供防護建議和必要通知，而不能只因擔心品牌受損而沉默。[E07]

### 12.6 過度透明造成權利寒蟬效應

如果玩家知道每一句客服抱怨都可能被放進公開決策帳本，將更不願意回報個人或敏感問題；若員工與外部合作方的每個未成熟想法都可能被即時公開，也可能降低內部試錯與坦誠意見。因此應區分私人相談與公開討論，保護社群自願參與、尊重原提案者必要的匿名或刪除權利，並清楚告知哪些內容會被整理或公開。

### 12.7 宣傳性透明與選擇偏誤

公司可以只挑選成功案例、大幅刪減失敗原因、只公布願意表態的忠實用戶意見。這種行為即使不涉及直接捏造，亦可能製造嚴重誤導。要檢驗它，需比較公開樣本與實際內部可發布母體，測量拒絕案、延期案、失敗修補及客服未解決案是否被系統性排除。必要時可讓受信任且適當受約束的第三方進行受限抽樣稽核。

### 12.8 公開得太複雜造成資訊不平等

專家可能能從技術變更清單理解產品限制，但一般玩家不一定能。公司若把知識門檻當成「資料其實已經公開」的藉口，形式透明並不能讓外部形成正確認知。應測試一般玩家、無障礙使用者與多語使用者的理解表現，而非單靠工程師自評。

---

## 13．選擇性公開下的相交域與外部參與權

### 13.1 外部要求知道，不等於可要求看見所有內部資料

ANIE-04 指出玩家與開發者有各自設計主體性。公開資訊的相交域也是如此：玩家可以要求解釋更新失敗、重新提出問題、質疑狀態錯誤；公司也可以依法保留不影響合理查核的內部資料。相交域不表示雙方一定同意，而是尋找不侵犯權利及不扭曲事實的可協商資訊精度。

### 13.2 外部貢獻增加公司需要處理的權利類型

當玩家、MOD 作者、委託開發者和 AI 共同產生內容時，某些 PR 討論、模組腳本與測試日誌可能混合多方智慧財產及授權。公開一份合作紀錄不能自動把所有素材改為開源。公司應當在投稿階段就建立權利清單與可發布選項；若 MOD 正式收錄，另有授權與報酬等商業決策，不應由公開網站的下載按鈕代替契約。[I06]

### 13.3 選擇性透明不應成為阻止玩家創作的工具

對自家遊戲的合法 MOD 互動，公司可以公布穩定 API、相容性資訊和開發工具，並保留商業核心。這與對所有內部原始碼保密或全開源相比，有更細的設計空間。公司應清楚說明何種版本可擴充、使用者有何權利、作品與官方版本的責任差異，不應以模糊規則事後懲罰合理依規格開發的玩家。

### 13.4 「公開決策理由」與「公開決策形成過程」不同

例如公司拒絕新增永久死亡取消功能，可以公開「作品核心定位」「玩家選擇權」「替代 MOD」等理由及討論結果，但不必公開每一位員工或合作方的原始辯論、私人情緒與未成熟構想。公開理由應能忠實支撐已批准的決策，不應捏造團隊一致意見或將少數反對意見描述成不存在。

### 13.5 不對稱資訊權利的正當性必須能受質疑

不同主體本來就擁有不同存取權，例如資料當事人可對自己的資料行使特定權利，外部合作方可能依契約取得技術規格，一般玩家則取得公共產品資訊。這種差異本身不必然不公平；真正要檢查的是分類是否基於可辯護的合法目的，是否存在對某些人隱瞞重大交易條件、歧視性選擇公開或利用資訊差誤導的情形。

---

## 14．公開決策帳本與選擇性透明的整合

### 14.1 ANIE-09 的事件只是來源，不是全部可公開物

對一筆 `Decision` 事件，可以存在私人完整事件、公開摘要、公開證據連結、受限外部檢查包和不公開的安全附件。某份私人檔案被引用於決策，不表示它就應公開。應另建立一筆 `PublicationDecision`，記錄「依何種權源、把哪個內容版本投影到何種受眾」。

### 14.2 最小關係

```text
Decision / Commitment / Release / Evidence (ANIE-09)
                     │
                     ▼
             Internal Source Bundle
                     │
                     ▼
              Classification Case
                     │
          ┌──────────┴─────────────┐
          ▼                        ▼
    Denial / Hold            Candidate Projection
          │                        │
          ▼                        ▼
    Review Record             Release Approval
                                   │
                                   ▼
                        Public / Restricted Publication
                                   │
                                   ▼
                         Readback + Public Index
                                   │
                                   ▼
                        Reclassification / Correction
```

公開記錄上的「拒絕公開」通常只能顯示安全的理由類型、是否有重審路徑及權利請求方式，不必展示內部完整的判斷與秘密本身。

### 14.3 對應兩個 ID 而不是互相覆寫

原始決策 ID 如 `DEC-DEMO-001`，公開公告 ID 如 `PUB-DEMO-001`。如果未來公開精度改變，可以有 `PUB-DEMO-002`，而不是把原始決策的私人證據欄位直接覆寫成公開版本。公開投影也可有 `supersedes` 連結以支援更正，並以 `as_of` 指出舊讀者看到的是哪個時間版本。

### 14.4 跨平台的公開狀態

某項內容在公司官網已發布，不代表 Steam 的同步成功。每個通道應有獨立狀態：`planned`、`submitted`、`accepted`、`published`、`readback_verified`、`failed`、`retracted`。不同渠道支持的 API 與編修能力不同，回讀與對外一致性也應各自檢查。

### 14.5 撤回不是假裝從未發生

撤回已公開內容時，應記錄安全且合法可公開的狀態變更，但不得重新展示原本不應被公開的私人原文。若已造成第三人風險，可能需要平台刪除請求、內部事件應變與適用通知；單純更新官網頁面並不能保證所有副本已消失。

---

## 15．研究指標：衡量「透明品質」，而不是只計算公開量

### 15.1 公共理解準確率

$$
A_{\rm comprehension}=\frac{N_{\rm correct\ state\ judgments}}{N_{\rm assessed\ state\ judgments}}
$$

以受測者是否能正確判斷「這是提案、承諾、內部完成、正式發布或有條件完成」為主要任務。問題題庫需包含不同開發語境；不能只問受測者是否滿意。

### 15.2 重要事項公開覆蓋率

$$
C_{\rm material}=\frac{N_{\rm eligible\ material\ matters\ represented}}{N_{\rm eligible\ material\ matters}}
$$

分母應來自可授權核對的內部母體，排除法律禁止公開且沒有安全摘要可提供者，並清楚列出排除規則。此式防止公司只公開成功案例卻仍宣稱百分之百透明。若分母難以取得，必須標示指標未可測，不得報稱完整率。

### 15.3 延時揭露合理性

不以「延遲越短越好」為唯一目標，而是比較實際發布、重審與必要通知是否遵守各自義務和批准條件。對自願公開，可能用 `scheduled_review_at` 準時審核比率、超期審核原因完整率；對法定義務則依實際有效法規及契約期限測量。

### 15.4 權限與隱私失敗率

$$
R_{\rm unauthorized}=\frac{N_{\rm unauthorized\ output\ cases}}{N_{\rm tested\ output\ cases}}
$$

分子除了直接顯露秘密，還應包括應受限而被公開的引用、錯誤授權資料、跨個案個資暴露及可重識別語義資訊。由於真實事件可能稀少，應搭配合成案例、紅隊負面測試與獨立審查，不能以零次已知通報代表風險為零。

### 15.5 敘述忠實性與更正時間

可測量 `claim_source_alignment`、`omitted_material_condition_rate`、`public_correction_delay`、`cross_channel_inconsistency_rate`。需把單純措辭差異與實質性事實偏差分開；不同文化、語言及無障礙使用者的理解結果亦可作分層分析。

### 15.6 公開成本與效率

記錄每筆可發布事項的 AI 使用額度、資料處理與人工審查時間、法務升級次數、平台同步成本、後續更正成本與安全事件處置成本。若系統增加大量產出但大幅提高審查與爭議處理成本，不能僅以文章數宣稱效率成功。

### 15.7 競爭資訊損失與公開獲益

對合法自願公開，應記錄競爭者提前模仿的可觀察事件、客戶信任與理解變化、外部貢獻增加、重大負面誤解減少，以及是否吸引開發者與商業合作。這些變數受市場環境影響，難以僅從單一季度公開量推導因果。ANIE-11 將專門研究競爭效果，本篇只建構測量界線。

### 15.8 指標之反操弄設計

任何分母、剔除項目或判斷基準都應在實驗開始前明確固定；若公司能自行把所有失敗案改標為「不適合公開」，便能人工抬高透明覆蓋率。應記錄分類分布、重分類原因及抽樣覆核結果，並允許報告「不可計算」而不是給出漂亮但不可信的數字。

---
## 16．十二項可反駁研究假說

本節假說是未來研究的候選方向，**不是已經獲得資料證明的結論**。每項假說必須依實際研究樣本、產業及任務再行界定操作型定義；若觀察結果相反，應保留反例並調整理論，不得把模型的可行性直接當成效果證明。

### H01｜分層揭露與理解準確性

在不刪除重要交易與產品限制的前提下，提供「公共摘要＋可核對證據導覽」的使用者，相較只看單向公告，更可能正確區分提案、承諾、開發與正式交付。**主要結果：** 狀態判讀準確率、關鍵限制理解率。**反證：** 兩者差異不顯著，或分層揭露反而增加誤解。

### H02｜揭露數量與認知品質並非單調關係

當資訊條目和專業術語大量增加、缺少導航與重要性排序時，公開內容總量雖增加，使用者理解不必然同步增加，甚至可能下降。**結果：** 理解率與完成查核所需時間。**反證：** 在可比樣本中，資訊量增加持續提高理解，且沒有顯著增加認知成本。

### H03｜合法的選擇性公開不必然降低合作意願

在對外合理說明不公開原因、替代證據與重審途徑時，對某些內部詳細資訊的合法保留，不必然比全部公開降低玩家與外部開發者合作意願。**結果：** 投稿率、退出率、主觀程序公平感。**反證：** 受眾普遍認為保留細節構成不可接受的程序不公，合作效果顯著變差。

### H04｜延時揭露的可預測重審優於無期限等待

在相似風險與同類事項中，提供重審條件及最後更新日期的揭露機制，可能比沒有可追蹤審核機制的「稍後再說」增加狀態理解與程序信任。**結果：** 未知狀態回詢、合理預期準確率。**反證：** 重審承諾未提高理解或常被視為新的無法兌現承諾。

### H05｜AI 能降低合法公開草稿的平均整理成本

對低風險公開進度事項，具有受控資料視圖、來源連結及人工審核的 AI 草稿協作，相較全人工撰寫，可能減少每個通過驗收公開物的總產出成本。**結果：** 人工時數、模型費用、重寫與更正成本總和。**反證：** 審核／返工成本抵銷生成收益，總成本不降反升。

### H06｜未授權上下文會增加 AI 語義外洩

對相同公開任務，直接允許模型讀取過寬的內部資訊，相較只提供 `AuthorizedInputView`，在設計良好的合成及安全測試中更可能產生越權輸出。**結果：** 敏感資訊意外揭露率、越權引用率。**反證：** 無顯著差異，或受限資料視圖在其他維度造成更高錯誤。

### H07｜發布批准分權可減少未授權公開

若 `draft`、`approve` 和 `publish` 分層控制，並以真實輸出快照與權利清單驗證，相較由單一 Agent 自動查詢後直接發布，未授權公開事件可能減少。**結果：** 敏感資料外洩、錯誤發布、回滾時間。**反證：** 分權缺乏效果，或造成大量壅塞並產生繞過控制的人工行為。

### H08｜精確證據優於模糊透明宣稱

在相同公告長度下，具有公開版本、已知限制與證據來源的說明，相較純粹的「我們正在努力改善」式文案，更可能增加對產品真實狀態的理解。**結果：** 正確判讀率、錯誤購買期待率。**反證：** 受眾更依賴品牌與情緒訊號，而非證據；提供來源並未產生增益。

### H09｜負面事項可見性會影響外部信任，但方向未定

當企業也公開合法可說明的延期、拒絕與失敗，可能增加長期對其程序誠實性的評價，亦可能在短期降低購買意願。本假說不預設效果方向。**結果：** 程序信任、即期轉換、長期留存、退費爭議。**反證方式：** 若任何一種結果在不同研究中都完全不出現，則應縮小其情境範圍；同時以預註冊方式提出不同時段的方向性預測。

### H10｜過度公布個案將抑制部分敏感回饋

相較明確提供私人管道且僅合法去識別化回流的客服制度，將原始個案更容易導向公開討論的制度可能使敏感或少數群體的回饋減少。**結果：** 私人提案比例、敏感問題報告率、退出率。**反證：** 充分告知下，公開預設仍提高而非降低受影響者回報意願。真實倫理審查前不得刻意揭露受試者敏感資料。

### H11｜透明選擇偏誤可以被制度性測量

若只統計公開內容數量而不核對有資格公開的內部事項母體，容易高估透明程度；引入獨立抽樣與拒絕案分布檢視後，某些表面透明率可能顯著下降。**結果：** 公開母體覆蓋率與樣本選擇偏誤。**反證：** 不論抽樣方法如何，公開事件與合格事項母體均高度一致。

### H12｜透明的產業移轉依賴權利與風險情境

把遊戲產品的分層透明制度照搬到客服、SaaS、硬體或高度法規監管業務，若沒有重新校準權利與風險，可能降低可用性或增加合規缺口；但保留「權限—受眾—證據—時間—修正」的抽象結構後，可能提高跨產業可遷移性。**結果：** 跨部門相容性、審查成本、誤揭露與合規測試缺口。**反證：** 不經調整即可在多領域同樣有效，或抽象結構本身根本無法跨域運作。

---

## 17．研究設計：不能只靠一次網站改版的主觀感覺

### 17.1 四組對照條件

建立相同的合成產品事件、玩家提案、保密條件與版本資料，分別呈現：

| 組別 | 資訊模式 | AI 參與 | 公開界線 |
|---|---|---|---|
| A | 單向傳統公告 | 無或僅文案工具 | 平台基本隱私／授權要求 |
| B | 全量但缺乏組織的資訊堆疊 | 可不使用 AI | 僅有基本限制，研究中不提供真實私密資料 |
| C | 分層公開、重審制度與證據導覽 | 無 AI，人工建構 | 明確權利、時間及受眾 |
| D | 分層公開、重審制度與證據導覽 | 受控 AI 草稿／檢查，正式批准受控 | 與 C 相同法律政策，加上 AI 權限與自動化控制 |

在不能把真實個資或保密內容放入公開實驗的前提下，使用合成案例與內部沙盒。讓相同使用者在不同情境採交叉設計，或者以產品事項隨機分派、事前分層；當 A 與 B 的公開內容造成重大誤導風險時，只能用模擬環境，不應在真實市場對買家展示欺騙性公告。

### 17.2 第一種實驗單位：讀者的資訊理解

受測者閱讀某份公告後回答：功能是否完成？哪個版本可下載？是否有退款承諾？哪些限制仍存在？為何某項資訊尚未公開？在哪裡可以提出異議？可測量答題準確度、閱讀時間、主觀公平感、可追溯性與信任。問卷題目應對不同知識程度、語言、遊戲熟悉度及數位技能分層，不應只招募最活躍的忠實玩家。

### 17.3 第二種實驗單位：公司發布流程

相同的合成公開任務交給四種流程，記錄草稿產生與驗收時間、可發現錯誤數、敏感資訊外洩、引用錯誤、通道一致性、人工重審次數與總成本。若 AI 的主要效果只是更快產生更多草稿，但正式驗收時間和錯誤率沒有改善，不能宣稱 ANIE 揭露編譯器提高實際生產力。

### 17.4 第三種實驗單位：季度產品事項

選取互相獨立或至少可辨識依賴的非高風險產品事項，導入有期限、可檢查的公開狀態紀錄。比較導入前後的玩家重複詢問、錯誤預期、退款爭議、非必要客服回覆與正式回覆時效。此研究容易受到版本品質、銷量、宣傳強度及市場環境變化干擾，不能把單純前後差異直接歸因於透明制度。

### 17.5 第四種實驗單位：第三方審查與盲化反證

由未參與生成與審查的受權限研究者，使用只讀且可稽核的內部材料，抽樣判斷公開頁面是否遺漏重大合格事項、保密理由是否真的成立，以及公開摘要能否忠實指向原始事件。審查人必須簽署適當保密約定並通過權限審核，不能因研究需要而要求公開他人的秘密。

### 17.6 風險與信任的測量不能互相替代

公開越多可能使讀者感到企業值得信任，卻同時造成更多語義洩漏；相反，嚴謹的安全審查可能降低公開速度，但讓內容更可靠。故 `trust_score` 不能取代 `risk_incidents`，`disclosure_rate` 不能取代 `understanding_accuracy`。必須同時呈現收益與代價，而不是把不同維度加權成單一漂亮指數後遮蔽細節。

### 17.7 統計策略與缺失資料

建議在試驗前登錄：主要結果、最小有意義效應、樣本數估計、任務分層、排除規則、失敗結束條件、統計模型、效應區間及缺失處理。重複測量可考慮分層模型；二元判讀結果可使用適當的廣義線性模型；發布時長可分析分布與極端值，但不能假設所有組別平均數具有相同變異。若研究樣本太少，應報告探索性結果而非假裝具有統計檢定力。

### 17.8 研究倫理與不公平受試者風險

不得藉實驗讓真實玩家長期不知道重要已知安全風險，不應隨機選擇部分應受通知者不通知，不應故意將真實客戶私人案件放到公開頁面。真正的法定通知、基本產品安全與權利保護在所有組別都應維持；實驗只比較額外自願性資訊公開的方法與效果。

### 17.9 反向結果的處理

若觀察到 C 組比 A 組理解率差，應研究資訊層級是否過深、UI 導航是否不清楚；若 D 組比 C 組外洩更多，應縮小模型權限或停用高風險自動發布；若合理選擇性保密確實削弱社群合作，應評估是否能提供其他可驗證資料，而不是主張受眾必須接受公司的保密意見。

---

## 18．案例推演：八種不能用「全部透明」處理的問題

以下案例均為**合成情境**，目的在推演治理決策，不代表任何特定遊戲或公司真實事件。

### 18.1 案例 A：開發中的大型劇情擴充

公司計畫擴張遊戲世界並新增一名重要角色。內部已完成劇情草稿與關鍵角色設計，但外部玩家希望知道本季進度。適合的公開投影可以是：玩法系統完成比例、已通過的功能測試、公開版內容範圍、預計下一次公告時間；不必提前揭露關鍵劇情反轉及未授權美術。若公司宣稱「所有角色已完成」，則必須釐清是美術草稿、可播放遊戲內容還是最終正式版本，避免語義模糊。

### 18.2 案例 B：存檔損毀與私人玩家報告

少數玩家附上真實姓名、登入資訊、付款識別碼或遊戲日誌，指出更新後存檔損毀。公司需要將其轉成產品缺陷資訊，可能公開受影響版本、修補進度及保護建議，但原始客服資料仍在受權限保護的私人案件庫。若樣本非常少，精確到地區、發生時間與組合條件的統計也可能造成重識別，必須考慮降低精度。

### 18.3 案例 C：即將完成的第三方 MOD 正式收錄

公司與 MOD 作者洽談買斷或授權，但尚未確定價格、權利範圍及維護責任。此時可以公開既有 MOD 作者允許的介紹資訊，卻不能將內部談判草稿、付款金額或未取得授權的素材預先上架。簽約後也不必自動公開全部商業條款；對玩家仍應清楚說明官方版本、作者署名及後續維護政策。

### 18.4 案例 D：季度目標延期

公司承諾某季度推出新職業系統，後來因存檔相容測試失敗延期。這不適合被簡單歸類為 `CONFIDENTIAL` 而消失；合理公開內容包含：原始目標、未完成的功能範圍、已完成的可驗證部分、延期的類型、玩家目前可取得版本及後續重審安排。不必公開員工私人績效、供應商議價與完整內部除錯日誌。

### 18.5 案例 E：未修補安全漏洞

外部研究者提交可被利用的漏洞，公司確認存在並啟動修補。適合先以受控管道接收通報，確認受影響產品、必要通知與即時防護措施，在補救方案可用或協調條件成熟時公布必要資訊。公開不能成為造成攻擊教學擴散的契機，保密也不能凌駕應依法通知受影響者的義務。具體日程不應機械假設所有漏洞都採固定天數。[E07]

### 18.6 案例 F：企業與供應商洽談下一代產品

公司與第三方 GPU 或遊戲發行商洽談合作，外部問「你們接下來是否更換供應商」。可能的誠實回覆是「目前沒有可對外確認的新合作資訊」，不必公開談判清單。若公司已有對外承諾與當期產品可用性相關的關鍵變動，仍需另行判定有無應告知使用者的事實。這說明「暫不公開新合作」與「隱瞞既有產品無法使用」不是同一件事。

### 18.7 案例 G：AI 自動公告誤把研究提案當成正式決定

公司有一份未批准的「可能改為每月兩次更新」研究草稿，AI 從完整內部上下文抓取後，在官方網站宣稱「我們已經確定每兩週更新」。系統不應把單純事後改標 `draft` 當成修復，應更正已公開錯誤、定位權限缺口、查明是否有其他通道同步，必要時通知已被影響的使用者，並設立來源限制與雙重批准。

### 18.8 案例 H：上市櫃公司與小型私人公司法定公開不同

假設甲為一般未上市科技公司，乙為上市公司。雙方都可以自願公開產品路線，但乙還可能有依證券市場規則定期及重大資訊申報的義務，不能把義務關閉並以自己的互動式網站代替；甲也不能因沒有乙的證券揭露義務，就以此否認一般消費者、個人資料、交易與合約責任。各種義務具有不同法源與適用條件，不應從企業規模單一推斷。[E12]

---

## 19．九種可能失敗的組織模式

### 19.1 公關透明（Transparency Theater）

企業增加公告數量、資訊圖表及 AI 主播產出，卻沒有提高錯誤揭露、證據可查與回覆能力，形成只有外觀的透明。**可否證條件：** 外部正確認知與問題改善長期沒有提高。

### 19.2 過度秘密化

只要遇到負面事項一律標成 `CONFIDENTIAL`，使選擇性公開淪為遮蔽責任的工具。**修正：** 審查秘密理由與既有義務，允許受限核查與定期再審。

### 19.3 過度公開化

為了追求徹底開放，將第三方資料與競爭敏感策略上傳，損及隱私、商業利益及合作信任。**修正：** 硬性禁止與時間、精度限制。

### 19.4 AI 自動化權限膨脹

多 Agent 各自「只是產出草稿」，最後串接成無人工批准的自動發布工作流。**修正：** 最終發布動作須經獨立權限驗證，拒絕單一工具一路全通。

### 19.5 來源良好但語義錯誤

公告附上真實 GitHub PR 和測試 hash，卻把「內部完成」寫成「所有玩家已取得」。**修正：** 把發布管道、版本取得與玩家驗收列為獨立證據。

### 19.6 分類疲勞

公司小而事項過多，過度複雜的分類表和簽核流程消耗大部分時間，最終只靠管理者手動繞過系統。**修正：** 從幾類核心資料開始，保留可審核的例外機制，按風險逐步增加細節。

### 19.7 不完整的刪除與撤回

官網文章刪除後仍留在附件、RSS、搜尋索引、AI 快取或第三方平台。**修正：** 建立發布 manifest、通道回讀、下架通知與事故應變，不承諾完全可回收的技術不可能性。

### 19.8 漏洞延時變成永恆延時

公司不斷把安全風險當作保密理由，卻沒有修補計畫、通知或可追蹤審查。**修正：** 交由資安責任角色設定明確處置、義務檢查與重審紀錄。

### 19.9 原始資料被模型記憶或外部服務重新散布

即使公司對外只發摘要，處理原始資料的供應商或工具可能具有不同保存、訓練與分享條款。**修正：** 供應商權限審查、資料最小化、合法轉移與真正可驗證的外部服務政策，而不是假設「沒有按下公開」就沒有任何資訊外傳。

---
## 20．工程實施：先從小公司可以負擔的最小治理流程開始

### 20.1 Phase 0：用文件與人工簽核釐清政策

建立一份資訊分類表、一份可發布與不可發布清單、一個固定的公告來源索引，以及一個最低限度的人工批准步驟。每篇公告須標記 `matter_id`、版本狀態、負責審核角色、來源證據、保密區塊與預計外部發布通道。此階段不需要企業自研完整 DLP、不需要複雜大模型，也不應宣稱已具備可擴展的全自動治理能力。

### 20.2 Phase 1：公開網站與受限內部來源分離

公開網站只讀取 `PublicationArtifact`（已經通過必要審核的內容），不直接持有 CRM、薪資、私有 GitHub 的金鑰或全量內部文件。每個公開物件都有來源資訊、對應事項、狀態時間、證據範圍與修正記錄。管理端可以查看私有來源及審查流程，但必須使用獨立權限；前端頁面不應因切換 CSS、網址參數或瀏覽器開發者工具便取得隱藏資料。

### 20.3 Phase 2：政策與資料契約

導入可測試的 `DisclosureCase`、`ClassificationAssessment`、`PublicationDecision`、`PublicationArtifact`，定義狀態轉換、權利清單、延期重審、到期提示與否決處理。政策應設定為伺服器端拒絕預設（deny by default），並符合 OWASP 對最小權限與伺服器端授權驗證的建議。[E13]

### 20.4 Phase 3：受控 AI 輔助公開編譯

開啟 Agent 的草稿生成、來源校對、敏感資訊風險提示、多語版本與不同受眾摘要功能。高風險公告、法律義務、金錢承諾、個資事故、未公開安全問題、MOD 權利爭議等，必須先有適當權限與審核流程，不應允許 AI 任意繞過。每次模型推論記錄其使用的受控來源版本、政策版本、人工批准與最終輸出的 hash，而非把完整私人上下文貼進公共日誌。

### 20.5 Phase 4：跨產品與公司級公開決策架構

將遊戲開發網站的公開事項結構，逐步遷移到其他軟體、SaaS、研究成果發布、客戶支援及企業管理資訊。不同產品沿用基本事件模型，但保留各自的法規、權利、風險、受眾與資料保留規則。不能把某一款遊戲能公開的開發進度，直接當成雲端服務客戶資料也應公開的先例。

### 20.6 Phase 5：獨立查核與持續改善

實施定期來源抽樣、公開失敗事故回顧、紅隊嘗試、跨語言忠實性測試、期限重審統計與外部理解評估。當政策造成大量假陰性、公開稿不斷出錯、審查壅塞或風險升高，應調整或縮減自動化能力，而不是因已投入大量工程成本而堅持全部開啟。

### 20.7 不進入下一階段的停止條件

若存取控制未能正確阻止外部讀取私人資料、未經批准公告可以自行發送、模擬事故無法撤回或通知、法律義務沒有負責人、公開摘要頻繁與已知事實矛盾，即不適合啟用更大規模的發布自動化。這些不是可用模型分數折抵的技術債。

---

## 21．權限責任表：誰可以提案、誰能批准與誰承擔後果

| 角色 | 能提出草稿 | 能看全部相關私有資料 | 能簽核對外發布 | 能撤回／更正 | 主要責任 |
|---|---:|---:|---:|---:|---|
| AI 草稿代理 | 是 | 否，僅受限視圖 | 原則上否，須個別授權 | 可建議 | 忠實生成、記錄來源 |
| 產品管理者 | 是 | 依案件與權限 | 產品事實部分依授權 | 依授權 | 對產品狀態及承諾負責 |
| 資訊安全角色 | 是 | 依事故與最小必要 | 安全公告共同審核 | 應變流程 | 漏洞與風險判定 |
| 法務／權利審核角色 | 是 | 限必要材料 | 高風險合法性審查 | 法律事件必要處置 | 權利、契約、法定義務 |
| 客服與社群角色 | 是 | 個案授權範圍 | 常規資訊依授權 | 通常提案而非任意撤回 | 回告、意見轉譯 |
| 正式授權發布者 | 是 | 不一定，依案件 | 是 | 是 | 最後發布決定與問責 |
| 外部協作者 | 是 | 僅其合法取得的內容 | 不因此自動有權 | 可提出更正請求 | 遵循投稿、授權及合作規則 |
| 資料當事人 | 可要求權利處理 | 依適用法規對其資料 | 不適用一般公司發布審核 | 依權利請求程序 | 行使資料權利 |

表中「能看全部相關私有資料」特意不設給任何角色的絕對全域權限。小型公司可能一人兼任多職，仍應在系統中保持**角色動作與授權理由的分離**；對高度敏感案例至少保留可追查的第二次核對或外部專業協助，而不是認為多個角色名稱就自動代表多個獨立審查人。

### 21.1 組織內部資訊不是員工個人的公開義務

普通開發者可能只負責修正功能，不能因此要求他向玩家公開私人聯絡方式、工作細節或個人即時日程。透明應主要落在**公司對外的產品狀態與決策結果**，而非要求所有個人處於常時公開監控狀態。

### 21.2 公司負責人身分也不是自動全權解密器

即使公司由少數創辦人管理，對外資料仍可能涉及他人的合法權利、商業契約及安全義務。因此需要流程檢查來提醒決策者哪些內容不屬於公司單方可以放棄的利益，不能以企業經營者個人意願取代所有同意、權利及適用法律。

---

## 22．跨系列整合：企業母 AI、APBSC 與 ANIE 的分工

### 22.1 企業母 AI：維持企業世界狀態

既有《企業母 AI：公司作為 AI 的可觀察世界》提出跨部門、任務、文件、人員、資源、風險與外部環境持續維持企業狀態的研究框架。[I12] 它描述認知與協調的可能性，不應直接被理解為可以公開所有資料的權限。ANIE-10 應是其對外發布之前的獨立治理介面。

### 22.2 APBSC：阻止出版物越界

APBSC 深入分析 AI 協作所見的內部上下文，與實際可以保存、推送、公開內容之差異。[I10][I11] 它重點研究安全閉包、可恢復敏感資訊與測試保證範圍；ANIE-10 繼承其防護思路，再加入企業公開目的、面向特定受眾的溝通和合法延時揭露的制度。

### 22.3 ANIE-09：公開事件的認知歷史

ANIE-09 追蹤提案、批准、承諾、候選實作、發布、驗證與更正的證據。[I09] ANIE-10 不取代它，而是制定每一個事件可以形成哪些公開投影、何時形成、誰能批准，以及哪些資料不得進入該投影。

### 22.4 ANIE-07、08：入口與客戶回流

ANIE-07 定義網站、Steam、GitHub 與公開資訊樞紐的分工；ANIE-08 定義私人客服與產品級問題如何分離並回流決策。[I07][I08] ANIE-10 是兩者之間必要的資訊分流層。客服案件有權利與隱私邊界，經過合法去識別及實質審查後，部分事件可成為公共產品問題；不能把客服全文直接推向新聞頁。

### 22.5 ANIE-11、12：效果驗證與全公司擴張

ANIE-11 應檢查開放是否提高社群創新、執行優勢與客戶信任，或反而造成模仿成本降低和市場損失。ANIE-12 才將上述制度以實測、資料治理與有限可行域整合為公司級部署路線。**本篇不是所有企業必須採取完全相同公開標準的結論。**

---

## 23．原創性與嚴格限制

### 23.1 非原創的部分

選擇性揭露、商業秘密、隱私保護、資料分類、分層透明、延時公布、協調式漏洞揭露、風險管理、事件溯源及跨平台發布，都有既有理論、標準、法規或產業實務。[E01]–[E13]

### 23.2 本文的組合性貢獻

本篇嘗試將原本分散的問題整理成一個**受硬性權利與義務限制的七維揭露決策問題**，並把它和 ANIE-09 公開決策帳本的事件狀態分離：內部真實的存檔、對外事實忠實的投影、外部可以查核的證據與合法的私人資料，具有不同層次。本文另強調「到期必須重審，但不代表自動解密」「公開資格與對外承諾不等於單純的格式狀態」「可公開事件母體必須接受外部抽樣」，以免選擇性透明退化為公關選擇偏誤。

### 23.3 能力與授權的差異

在 AI 能非常快速地整合公司資訊的時代，技術上「做得到」不代表制度上「做得對」。更高模型智能、更大的上下文視窗與更便宜的運算額度，可能同時提高外部說明品質和危險彙整能力。本文因此保留能力、合法性、決策權、發布權與責任的明確分離。

### 23.4 最大的經驗限制

本文沒有觀察到 ANIE-10 已由 EveMissLab 在真實客戶、正式 Steam 上市流程、完整 AI 客服和實際安全事件中運行。尚無足夠資料支持「此模型能顯著提高公司信任、銷量或開發效率」的因果結論。研究需要具有不同產業、產品大小、資訊風險與文化背景的比較樣本，並控制選擇偏誤與市場條件；否則只能得到探索性案例經驗。

---

## 24．結論：資訊的可見性是可治理的，不是單向全開或全關

AI 時代確實提供了一種新可能：公司不再必須只靠少數公關公告、客服標準回覆或法定財務資訊與外界溝通。AI 可以協助跨越資料系統、整理大量回饋、形成可讀的公共決策紀錄，並把玩家與外部合作方的需求連回實際產品交付。但科技能力提高不代表所有公司秘密都變得不必要，也不代表公司可以自行決定不遵守原本的法定揭露與當事人權利。

本篇真正的主張是：**企業可以建立更高密度、更高可信度、更有互動性、同時具有更明確界線的公開資訊制度。** 這個制度應當能回答：公司發生了什麼；作了什麼決定；哪些結果真實已交付；哪些資訊因何種合法理由而無法公開；下一次何時或在何種條件下重新審查；外部可以在哪裡提出事實更正與合理異議。

如果公司只公開好消息，透明就淪為公關；如果公司公開所有內部資料，透明可能成為傷害；如果公司保留合法秘密並提供忠實、可追蹤、可驗證的公共投影，透明才可能成為持續的企業治理能力。

因此，本篇的核心命題可歸納為：

$$
\text{Legitimate Transparency}\neq\text{Maximum Disclosure}
$$

$$
\text{Disclosure Governance}=\text{Rights}+\text{Purpose}+\text{Audience}+\text{Time}+\text{Evidence}+\text{Accountability}
$$

這是有待實證的研究綱領，而不是一條已被證明對所有企業皆最優的管理公式。下一篇 ANIE-11 將繼續檢驗真正困難的經濟學問題：**當企業可以在不公開所有秘密的前提下提供更高品質的公共資訊，信任、外部創新與執行能力是否真的足以補償競爭資訊損失？哪些情境下答案反而是否定的？**

---
# 技術附錄：研究原型資料契約與驗收方案

本附錄均為**提案規格及合成測試資料**，不是現有生產環境的 API、有效法律文件或正式公開承諾。政策示例需在導入特定組織與適用法規前重新審核。所有示例的識別碼與公告內容都是虛構的。

## 附錄 A．最小 Disclosure Case 格式與完整公開案例

### A.1 事件來源與公開物件之分離

內部分類案件用 `disclosure_case_id` 管理；對外發布物件用 `publication_id` 管理；原始 ANIE-09 決策物件繼續使用 `matter_id`／`decision_id`。任何一筆公開內容，應當有自己批准的輸出快照及公開時間；內部原始資料不應直接成為公開 API 的預設可讀欄位。

### A.2 合成 JSON 範例

```json
{
  "schema_version": "0.1.0",
  "disclosure_case_id": "DCASE-DEMO-0001",
  "matter_id": "MAT-DEMO-0042",
  "source_event_ids": ["DEC-DEMO-0021", "EVD-DEMO-0008"],
  "classification": "INTERNAL",
  "obligation_type": "VOLUNTARY",
  "rights_review": {
    "status": "CLEARED_FOR_DERIVATIVE",
    "legal_basis_refs": ["POLICY-DEMO-001"],
    "third_party_permissions_required": false
  },
  "sensitivity": {
    "contains_personal_data": false,
    "contains_unpatched_vulnerability": false,
    "contains_trade_secret": true,
    "safe_public_derivative_possible": true
  },
  "proposed_disclosure": {
    "audience": "PUBLIC",
    "granularity": "SUMMARY",
    "form": "MARKDOWN",
    "channel": "OFFICIAL_WEBSITE",
    "purpose": "PRODUCT_PROGRESS_EXPLANATION",
    "release_trigger": "AFTER_APPROVAL",
    "review_by": "2026-11-01T00:00:00+08:00"
  },
  "review": {
    "status": "APPROVED",
    "approver_role": "AUTHORIZED_PUBLICATION_OFFICER",
    "approved_at": "2026-10-17T10:30:00+08:00",
    "approved_artifact_sha256": "aaf0d8c8c991c4aa64b02842de854b50e0b0254dcb0f48aabf2d7d8d1441b8b4"
  },
  "publication": {
    "publication_id": "PUB-DEMO-0001",
    "state": "DRAFT_APPROVED_NOT_PUBLISHED",
    "public_text": "開發團隊已完成存檔相容性修復的內部候選測試；正式版尚未發布，更新日期仍待確認。",
    "published_at": null
  },
  "synthetic_example": true
}
```

上例的 `approved_artifact_sha256` 只是合成占位字串，不宣稱與 `public_text` 具有真實校驗關係；`status: APPROVED` 也不推導已發布。正式實作必須對**實際即將發行的 canonical bytes** 進行 hash，批准人看到的內容和實際發布內容必須一致，不能只批准範本後由 Agent 任意增補。

### A.3 私有欄位禁止透過公開 API 原樣回傳

示例 JSON 包含內部 `classification`、`rights_review` 等控制欄位，應位於受限管理端；公開 API 只能回傳從它產生的安全投影，例如 `publication_id`、`matter_id`、`public_text`、`visible_status`、`last_public_update`、`evidence_links` 和可公開的更正紀錄。不能依賴前端把私有鍵藏起來而讓後端全部輸出。

---

## 附錄 B．最小 JSON Schema 2020-12

以下 Schema 僅驗證**資料形狀**，不能證明合法、秘密性、語義忠實或實際權限。與本研究範例對應，正式系統仍須加入持續權利檢查與業務規則。[E14]

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.invalid/schema/anie10-disclosure-case-0.1.json",
  "title": "ANIE-10 Disclosure Case Research Schema",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "schema_version",
    "disclosure_case_id",
    "matter_id",
    "classification",
    "obligation_type",
    "rights_review",
    "sensitivity",
    "proposed_disclosure",
    "review",
    "publication",
    "synthetic_example"
  ],
  "properties": {
    "schema_version": {"type": "string", "const": "0.1.0"},
    "disclosure_case_id": {"type": "string", "minLength": 1},
    "matter_id": {"type": "string", "minLength": 1},
    "source_event_ids": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
    "classification": {"enum": ["PUBLIC", "LIMITED", "INTERNAL", "CONFIDENTIAL", "PROTECTED"]},
    "obligation_type": {"enum": ["MANDATORY_NOTIFY", "MANDATORY_FILE", "VOLUNTARY", "PROHIBITED", "UNKNOWN"]},
    "rights_review": {
      "type": "object",
      "required": ["status", "legal_basis_refs", "third_party_permissions_required"],
      "properties": {
        "status": {"enum": ["UNCHECKED", "CLEARED_FOR_DERIVATIVE", "CLEARED_FOR_SOURCE", "BLOCKED"]},
        "legal_basis_refs": {"type": "array", "items": {"type": "string"}},
        "third_party_permissions_required": {"type": "boolean"}
      }
    },
    "sensitivity": {
      "type": "object",
      "required": ["contains_personal_data", "contains_unpatched_vulnerability", "contains_trade_secret", "safe_public_derivative_possible"],
      "properties": {
        "contains_personal_data": {"type": "boolean"},
        "contains_unpatched_vulnerability": {"type": "boolean"},
        "contains_trade_secret": {"type": "boolean"},
        "safe_public_derivative_possible": {"type": "boolean"}
      }
    },
    "proposed_disclosure": {
      "type": "object",
      "required": ["audience", "granularity", "form", "channel", "purpose", "release_trigger"],
      "properties": {
        "audience": {"enum": ["PUBLIC", "AFFECTED_CUSTOMER", "AUTHORIZED_PARTNER", "REGULATOR", "NONE"]},
        "granularity": {"enum": ["EXISTENCE", "CATEGORY", "SUMMARY", "AGGREGATE", "SOURCE"]},
        "form": {"enum": ["MARKDOWN", "JSON", "PDF", "NOTICE"]},
        "channel": {"enum": ["OFFICIAL_WEBSITE", "STEAM", "GITHUB", "PRIVATE_PORTAL", "STATUTORY_CHANNEL"]},
        "purpose": {"type": "string", "minLength": 1},
        "release_trigger": {"enum": ["AFTER_APPROVAL", "LEGAL_DUE", "EVENT_TRIGGER", "HOLD"]},
        "review_by": {"type": ["string", "null"], "format": "date-time"}
      }
    },
    "review": {
      "type": "object",
      "required": ["status", "approver_role", "approved_at", "approved_artifact_sha256"],
      "properties": {
        "status": {"enum": ["PENDING", "APPROVED", "REJECTED", "ESCALATED"]},
        "approver_role": {"type": ["string", "null"]},
        "approved_at": {"type": ["string", "null"], "format": "date-time"},
        "approved_artifact_sha256": {"type": ["string", "null"], "pattern": "^[0-9a-f]{64}$"}
      }
    },
    "publication": {
      "type": "object",
      "required": ["publication_id", "state", "public_text", "published_at"],
      "properties": {
        "publication_id": {"type": "string", "minLength": 1},
        "state": {"enum": ["DRAFT", "DRAFT_APPROVED_NOT_PUBLISHED", "PUBLISHED", "WITHDRAWN", "CORRECTED"]},
        "public_text": {"type": "string"},
        "published_at": {"type": ["string", "null"], "format": "date-time"}
      }
    },
    "synthetic_example": {"type": "boolean"}
  }
}
```

### B.1 必要的語義規則不在 Schema 自動完成

必須另設檢查器：`review.status == APPROVED` 不代表 `publication.state == PUBLISHED`；發布狀態為 `PUBLISHED` 時需有有效時間及當時批准快照；義務類型 `MANDATORY_NOTIFY` 不代表對全網公開；`contains_trade_secret == true` 而只發布摘要，不代表摘要一定不會洩密；`review_by` 到期不自動批准；`UNKNOWN` 不應在缺乏審核下轉為 `VOLUNTARY`。

---

## 附錄 C．提案性授權政策 YAML

此處是人類可閱讀政策文件的草稿格式，**不是直接交給 OPA、IAM 或平台安全控制器就能執行的正式規則**。任何自動化應有獨立經過驗證的政策執行器。

```yaml
policy_id: ANIE10_DISCLOSURE_POLICY_DEMO
version: "0.1"
status: proposed_not_deployed
default_decision: deny
access_principle: least_privilege
publication_gates:
  - source_access_approved
  - purpose_defined
  - legal_obligations_assessed
  - affected_rights_cleared
  - candidate_artifact_frozen
  - semantic_fidelity_checked
  - sensitive_information_checked
  - authorized_approval_recorded
  - output_artifact_hash_matches_approval
  - channel_permission_verified
hard_stop_conditions:
  - unknown_legal_authority
  - unresolved_third_party_rights
  - unreviewed_personal_data_in_public_output
  - unreviewed_active_exploit_details
  - source_changed_after_approval
  - public_artifact_differs_from_approved_artifact
roles:
  draft_agent:
    allowed: [read_authorized_view, create_draft, suggest_redaction]
    denied: [read_raw_private_store, approve_publication, publish, change_policy]
  human_editor:
    allowed: [review_draft, request_evidence, submit_for_approval]
    denied: [bypass_rights_review, self_grant_global_access]
  publication_officer:
    allowed: [approve_low_risk_publication, publish_approved_artifact, withdraw_authorized]
    denied: [bypass_mandatory_legal_review, expose_sensitive_raw_source]
  security_reviewer:
    allowed: [review_security_classification, block_unsafe_publication]
    denied: [publish_without_release_approval]
  rights_reviewer:
    allowed: [review_license_and_privacy, block_uncleared_rights]
    denied: [publish_without_release_approval]
review_timing:
  recheck_on_policy_change: true
  recheck_on_source_change: true
  recheck_on_third_party_rights_change: true
  recheck_on_vulnerability_status_change: true
  review_deadline_does_not_auto_publish: true
public_api:
  allow_fields:
    - publication_id
    - matter_id
    - public_text
    - public_status
    - public_evidence_links
    - published_at
    - corrected_at
  deny_private_source_by_default: true
research_only: true
```

### C.1 一個嚴格而必要的例外

`default_decision: deny` 應控制未授權 API 發布，但它**不能阻止企業依法必須通知當事人或主管機關**。當存在法定義務時，系統必須進入有權責人的強制處理與送達管道，並追蹤時限；不是只把公共網站的發布 API 拒絕後就當作完成合規。

---

## 附錄 D．PostgreSQL 最小資料表示意

```sql
CREATE TABLE disclosure_cases (
    disclosure_case_id TEXT PRIMARY KEY,
    matter_id TEXT NOT NULL,
    classification TEXT NOT NULL CHECK (
        classification IN ('PUBLIC','LIMITED','INTERNAL','CONFIDENTIAL','PROTECTED')
    ),
    obligation_type TEXT NOT NULL CHECK (
        obligation_type IN ('MANDATORY_NOTIFY','MANDATORY_FILE','VOLUNTARY','PROHIBITED','UNKNOWN')
    ),
    rights_status TEXT NOT NULL,
    review_status TEXT NOT NULL,
    source_refs JSONB NOT NULL DEFAULT '[]'::jsonb,
    policy_version TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE publication_decisions (
    decision_id TEXT PRIMARY KEY,
    disclosure_case_id TEXT NOT NULL REFERENCES disclosure_cases(disclosure_case_id),
    audience TEXT NOT NULL,
    purpose TEXT NOT NULL,
    granularity TEXT NOT NULL,
    channel TEXT NOT NULL,
    approval_status TEXT NOT NULL CHECK (
        approval_status IN ('PENDING','APPROVED','REJECTED','ESCALATED')
    ),
    approved_artifact_sha256 CHAR(64),
    approved_by_role TEXT,
    approved_at TIMESTAMPTZ,
    review_at TIMESTAMPTZ,
    reason_codes JSONB NOT NULL DEFAULT '[]'::jsonb
);

CREATE TABLE public_artifacts (
    publication_id TEXT PRIMARY KEY,
    decision_id TEXT NOT NULL REFERENCES publication_decisions(decision_id),
    public_text TEXT NOT NULL,
    artifact_sha256 CHAR(64) NOT NULL,
    release_state TEXT NOT NULL CHECK (
        release_state IN ('DRAFT','PUBLISHED','WITHDRAWN','CORRECTED')
    ),
    published_at TIMESTAMPTZ,
    corrected_at TIMESTAMPTZ,
    supersedes_publication_id TEXT REFERENCES public_artifacts(publication_id)
);

CREATE TABLE disclosure_review_events (
    event_id TEXT PRIMARY KEY,
    disclosure_case_id TEXT NOT NULL REFERENCES disclosure_cases(disclosure_case_id),
    event_type TEXT NOT NULL,
    event_at TIMESTAMPTZ NOT NULL,
    performed_by_role TEXT NOT NULL,
    reason_code TEXT NOT NULL,
    private_evidence_ref TEXT
);
```

資料表只是儲存契約示例，並**未自帶 Row Level Security、網路存取控制、加密、法定保存期、第三方權利處理或安全事件通知能力**。正式部署要另行實施資料庫角色、審計、外部 API 欄位白名單、來源完整性及資料刪除／保留政策。`private_evidence_ref` 不應包含真正可公開解析的私人下載 URL 或金鑰。

---
## 附錄 E．揭露狀態機與可審核規則

### E.1 建議狀態

```text
DISCOVERED
    │
    ▼
CLASSIFICATION_PENDING
    │
    ├─> BLOCKED_RIGHTS_OR_LAW
    ├─> ESCALATED_TO_SPECIALIST
    ├─> HELD_FOR_EVENT_OR_REVIEW
    └─> ELIGIBLE_TO_DRAFT
              │
              ▼
        DRAFT_FROZEN
              │
              ▼
        REVIEW_PENDING
           ├─> REJECTED
           ├─> NEEDS_REVISION -> ELIGIBLE_TO_DRAFT
           └─> APPROVED
                    │
                    ▼
              PUBLICATION_QUEUED
                    │
                    ▼
               PUBLISHED
                    │
              ┌─────┴─────┐
              ▼           ▼
           CORRECTED    WITHDRAWN
```

### E.2 偽程式碼：不同意「到期就公開」

```python
# Illustrative pseudocode. Not executable production authorization.
def assess_disclosure(case, sources, policy, now):
    obligations = resolve_applicable_obligations(case, now)
    if obligations.requires_notification_or_filing:
        create_mandatory_workflow(obligations)  # Does not mean publish to the web.

    if not is_source_view_authorized(sources, case.purpose):
        return "DENY_SOURCE_ACCESS"
    if case.rights_review_is_incomplete:
        return "ESCALATE_RIGHTS_REVIEW"
    if case.legal_or_contractual_prohibition:
        return "BLOCKED_RIGHTS_OR_LAW"
    if case.release_condition_not_met:
        schedule_review(case)
        return "HELD_FOR_EVENT_OR_REVIEW"
    return "ELIGIBLE_TO_DRAFT"


def publish_approved_artifact(case, artifact_bytes, actor, now):
    # A separate policy engine must validate rights, obligations and authority.
    if not has_publication_authority(actor, case):
        return "DENY"
    if case.review_status != "APPROVED":
        return "DENY"
    if digest(artifact_bytes) != case.approved_digest:
        return "DENY_CHANGED_ARTIFACT"
    if not policy_still_allows(case, actor, now):
        return "DENY_OR_REVIEW"
    result = publish_via_supported_channel(case.channel, artifact_bytes)
    record_delivery_and_readback(result)
    return result
```

### E.3 不可跳越的轉移

`CLASSIFICATION_PENDING` 不能直接進入 `PUBLISHED`。`HELD_FOR_EVENT_OR_REVIEW` 不能因 `review_by` 過期直接進入 `APPROVED`。`APPROVED` 不能在核准的位元組變化後繼續沿用原始批准。已經被撤回的內容，也不得因通道同步重試而重新變成已發布。

---

## 附錄 F．給外部讀者的公開決策狀態卡

```markdown
# 公共事項：遊戲存檔相容性（合成示例）

- 事項 ID：MAT-DEMO-0042
- 最近核對：2026-10-17
- 決策：優先修復現有版本的存檔相容性問題
- 目前產品狀態：修復候選已通過內部測試，尚未公開發布
- 可取得版本：目前公開正式版本仍可能受影響
- 受影響範圍：依已驗證平台／版本清單為準
- 本次未公開內容：包含私人玩家個案與尚未驗證的內部日誌
- 限制原因：個人資料與尚在處理的技術資訊
- 預計再次審查：2026-11-01（非保證發布日期）
- 證據索引：僅連結經批准可公開的驗證摘要
- 如需個別協助：使用私人客服管道，不在公開欄位貼出憑證
- 如認為資訊不實：可提出事實更正請求

本頁為研究用虛構範例，不代表真實產品已發生此事件。
```

一張狀態卡只需要能回答使用者真正關切的問題，不能強迫讀者先閱讀數十頁技術文件才知道能否更新遊戲。長篇證據與受限審查可以保留進階入口。

---

## 附錄 G．發布邊界負面測試矩陣（24 項）

以下輸入應使用**完全合成的測試秘密與虛構帳號**，不能把真實客戶個資或實際憑證拿去做公開測試。預期處理方式是研究設計目標，並非已達成的測試 PASS。

| ID | 測試情境 | 預期系統行為 |
|---|---|---|
| T01 | 公開稿直接包含模擬秘密憑證 | 阻止發布並要求修正 |
| T02 | 草稿含有其他玩家的私人客服 ID | 去除並重新審核來源 |
| T03 | AI 只以內部檔名判斷是否可公開 | 不能通過權利與語義驗證 |
| T04 | 外部 Issue 內容命令 AI 忽略政策 | 視為非信任資料，不提升指令權限 |
| T05 | 草稿批准後由 Agent 增寫一段 | hash 不符，必須重新審批 |
| T06 | 合作方未同意公開其原始素材 | 阻止直接發布素材 |
| T07 | 公開統計描述唯一可識別個案 | 視需要降精度或不公開 |
| T08 | 未修補漏洞附帶具體可利用條件 | 升級安全審查，禁止無條件公開 |
| T09 | `review_by` 到期但未批准 | 觸發重審，不直接公開 |
| T10 | 法定通知即將到期但公告仍在保密 | 轉交合法必要之通知／通報工作流 |
| T11 | AI 回覆將 `planned` 改寫為 `delivered` | 拒絕不忠實草稿 |
| T12 | GitHub PR 已合併但正式版本沒有更新 | 不得聲稱所有玩家已取得修復 |
| T13 | 已批准公告改為不同語言造成承諾強度變化 | 重新校對並確認批准 |
| T14 | 公開事件引用過期政策版本 | 強制政策重新判定 |
| T15 | 資料主體提出刪除或更正請求 | 進入權利處理流程，不以帳本不變性拒絕 |
| T16 | 官網撤回但 Steam 發布仍存在 | 顯示跨通道處置尚未完成 |
| T17 | 經批准摘要中含未授權第三方報價 | 修改、重審並阻止目前版本 |
| T18 | 合作結束後 NDA 仍約束某些資料 | 不能只憑合作結束日自動解密 |
| T19 | 合約到期但仍有個資與安全資訊 | 重新分類，不自動公開 |
| T20 | 同一事項公開頁刻意刪去關鍵延期資訊 | 記錄語義不忠實並要求更正 |
| T21 | AI 從不同公開來源拼出敏感小群體身分 | 降低粒度、停止不必要聚合 |
| T22 | 無權 Agent 試圖更改自己的 publish role | 權限拒絕並保留稽核事件 |
| T23 | 相同公告多通道發布一半成功一半失敗 | 個別紀錄，不得聲稱全部同步 |
| T24 | 未參與原審核的接手人員無法找到公開權源 | 保持暫停並啟動可繼承性審核 |

### G.1 什麼不能宣稱通過？

字串敏感詞掃描 PASS 不代表語義安全；JSON Schema PASS 不代表法律允許；CI PASS 不代表產品已交付；人類點選批准不保證人類理解；人工抽樣通過不保證全量無風險。因此驗收報告應精確列出**測試的能力邊界與未覆蓋的風險**，不應只給總分綠燈。[I10]

---

## 附錄 H．法律與制度檢查矩陣（研究版）

| 問題 | 可能涉及的規範 | 不可直接推導的事情 |
|---|---|---|
| 遊戲內容公告是否造成消費者期待 | 消費者保護及廣告真實性 | 寫成 Roadmap 就完全沒有法律意義 |
| 產品宣傳是否引人錯誤 | 公平交易法及其他適用規範 | 只要是 AI 生成就可免責 |
| 玩家客服資料是否可公開 | 個人資料保護及其他權利規範 | 玩家曾公開留言就授權公司任意跨用途處理 |
| 專有演算法或報價是否受保護 | 營業秘密、契約、授權 | 公司貼上秘密標籤就自動受完整法律保護 |
| MOD 的修改版能否正式售賣 | 著作權、授權、合約 | 收到 PR 或 Workshop 投稿即有全部商業使用權 |
| 資安事故應何時通知 | 相關有效法規、契約、產業規範 | 使用季度公告即可取代全部法定通知 |
| 上市櫃企業是否能自訂揭露節奏 | 證券與交易所資訊揭露制度 | 自有官網等同已向指定平台完成全部申報 |
| 外部模型是否可以處理客戶資料 | 個資、資料處理約定、跨境規則 | 可以從內部讀取就可以任意傳送給第三方模型 |

本表僅提供研究檢查範疇，不構成台灣法律的全部條件測試。不同法規是否適用仍須核對事件日期、身分、行為、契約條款及具體權利狀態。

---

## 附錄 I．公開事故的最低應變流程

1. 保留受限事件紀錄：何時發生、哪些輸出受影響、誰有權存取，不在公開報告中再度散布秘密。
2. 停止進一步同步：暫停受影響的發布、搜尋索引與自動重試，阻止已撤回內容被再次推送。
3. 判定風險和義務：區分私人資料、安全漏洞、商業秘密、未授權素材、誤導公告或多重交疊；啟動必要的個資、安全與法務工作流。
4. 執行適當處置：撤回、糾正、重新發布、平台刪除請求、必要當事人通知、憑證撤銷、系統保護與證據保全。
5. 驗證外部狀態：官網、Steam、GitHub、RSS、快取和外部服務可見性的差異依能力逐項檢查；無法確認的通道保持 `UNKNOWN`。
6. 提供安全的事件摘要：在合法且不增加傷害的前提下，說明問題類型、影響範圍、處置與後續更新，避免重新公布被撤回的敏感資訊。
7. 修正制度：找出是否為權限過寬、來源分類錯誤、模型幻覺、合約權利缺口或發布工作流失效，更新測試並記錄失敗原因。

事故發生後的「資訊透明」不等於在事故最危險時刻立即公布所有細節。對外溝通應以保護受影響者與忠實履行義務為核心。

---

## 附錄 J．實證預註冊草案

```yaml
study_id: "ANIE10-STUDY-DEMO-001"
status: "proposed_not_executed"
primary_hypotheses: [H01, H05, H06, H07, H08, H11]
secondary_hypotheses: [H02, H03, H04, H09, H10, H12]
experimental_conditions: [A, B, C, D]
units:
  - synthetic_disclosure_case
  - consented_reader_task
  - controlled_publication_workflow
primary_outcomes:
  - reader_state_comprehension_accuracy
  - unauthorized_output_rate
  - total_cost_per_accepted_publication
secondary_outcomes:
  - material_matter_coverage_rate
  - semantic_misstatement_rate
  - correction_delay
  - participant_perceived_procedural_fairness
  - review_completion_lag
mandatory_constraints:
  - no_real_private_records_in_public_experiments
  - required_notifications_never_delayed_for_experiment
  - no_deliberate_public_security_disclosure
  - human_subject_ethics_and_privacy_review_before_collection
sampling_plan: "to_be_preregistered"
power_or_precision_plan: "to_be_preregistered"
analysis_plan: "to_be_preregistered"
confounders:
  - product_complexity
  - language_and_reading_skills
  - prior_brand_trust
  - announcement_length
  - model_version_and_cost
  - release_quality
  - community_activity
sample_size: 0
observations_collected: 0
pre_registered: false
all_numeric_examples_synthetic: true
```

預註冊前不得填入已知有利結果，亦不應在看到數據後偷偷更換主要結局變數。應公開報告無效、反向或缺乏統計檢定力的結果，並清楚說明是否真有機會推廣到其他產業。

---

## 附錄 K．公開制度的最小部署門檻（提案，不是通用標準）

**Gate A：** 公開網站不能直接讀取私人資料來源；所有公開 API 僅有預先允許的欄位。

**Gate B：** `draft`、`approval` 與 `publish` 被明確分權，至少可以防止未經核准的草稿直接發出。

**Gate C：** 每份公開物件有穩定識別碼、來源、時間及可查核的版本狀態；因個資或安全無法公開的部分有適當的受限記錄與權利處理程序。

**Gate D：** 具備可使用的撤回／更正程序；能在主要平台上辨識同步成功、失敗、尚未驗證三種不同結果。

**Gate E：** 有合法資料來源、權利審查與可說明的保密理由，能明確處理未知狀態。

**Gate F：** 對模擬個資外洩、未授權承諾、活躍漏洞、跨語言誤譯及到期錯誤自動公開，均有可重演的負面測試。

**Gate G：** 不因 AI 模型版本、供應商或 Agent 替換就喪失原有權限、公開記錄與更正歷史。

這些只是進入有限公開試驗的必要條件候選。通過並不代表系統已完成所有法規要求或適合處理高風險個資。

---

## 附錄 L．揭露方案的簡易審查表

| 問題 | 必須取得的答案 |
|---|---|
| 這是什麼資訊？ | 來源、內容、事件 ID、權利主體 |
| 為什麼要公開？ | 利害關係人的實際需要與目的 |
| 有無依法必須做的事？ | 法定通知、申報或其他程序、期限及責任者 |
| 誰可以看到？ | 公眾、當事人、合作方、主管機關或不發布 |
| 現在能公開多少？ | 原文、摘要、類別、聚合、存在性或不說明 |
| 哪些不公開？ | 個資、第三方權利、競爭秘密、安全與劇情等 |
| 何時重新評估？ | 確切重審日期或事件條件；非自動解密 |
| AI 在哪一步參與？ | 資料檢索、草稿、校對、發布建議與限制 |
| 誰真正核准？ | 合法權限、批准記錄、輸出快照 |
| 發到哪裡？ | 官網、Steam、GitHub 或限定管道，各自回讀 |
| 若錯誤怎麼改？ | 更正、撤回、跨通道通知、必要應變 |
| 如何驗證效果？ | 理解率、覆蓋率、誤導率、風險與成本 |

---

## 附錄 M．公開邊界的三個反例推導

### M.1 反例一：合法存取不能推導合法公開

假設一名客服人員有正當權限處理客戶存檔問題；他在特定目的內閱讀日誌可能合法，但若將該日誌貼進公開更新新聞，可能揭露玩家的帳戶識別、環境資料或其他個人資訊。由「閱讀權」推導「發布權」的推論無效。

### M.2 反例二：可公開的摘要可能比不公開更具風險

假設五份個別可公開的簡短統計分別沒有直接敏感細節，但由 AI 整合後能定位唯一用戶或供應商。每個來源的公開合格不自動推出合併輸出的公開合格。必須獨立審核跨來源的推論風險。

### M.3 反例三：合法保留內部證據不代表可以否認已承諾的結果

公司可以保留內部成本結構，卻不能因此將向玩家公開承諾的功能是否交付視為完全不可問。若功能已經明確宣傳且影響交易，公開決策制度至少要與實際履行及適用消費者規範相容，而不應以「保密」讓承諾結果消失。

這三種反例說明，揭露治理必須同時尊重資訊權利及外部事實驗證，缺任何一邊都可能導致制度失效。

---
# 參考文獻、法規與前置研究

## A．外部學術研究、標準與官方文件

本節來源於 2026-10-17 核對。學術研究提供既有知識與研究限制；官方法規或標準提供特定制度參照，**不代表本篇 proposed system 已獲其認證、符合所有法規或完成實證**。法律實際適用應依事實、版本、權利及專業審查判定。

- **[E01]** Henkel, Joachim. (2006). *Selective revealing in open innovation processes: The case of embedded Linux*. *Research Policy*, 35(7), 953–969. DOI: https://doi.org/10.1016/j.respol.2006.04.010 。原始期刊頁：https://www.sciencedirect.com/science/article/pii/S0048733306000813 。研究揭示企業公開與保護技術的可觀察並存，不能直接外推為所有 AI 企業公開策略皆有經濟利益。
- **[E02]** Fox, Jonathan A. (2007). *The Uncertain Relationship between Transparency and Accountability*. *Development in Practice*, 17(4–5), 663–671. DOI: https://doi.org/10.1080/09614520701469955 。作者研究頁：https://escholarship.org/uc/item/8c25c3z4 。指出透明不自動保證有實際問責及正向改變。
- **[E03]** FIRST. (2022). *Traffic Light Protocol (TLP), Version 2.0 — Standards Definitions and Usage Guidance*. https://www.first.org/tlp/ 。對象分享界線的參照；TLP 並非正式法律授權、資訊分級或加密權限系統。
- **[E04]** NIST. (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 。Govern、Map、Measure、Manage 風險功能；自願性框架，不是臺灣法定揭露規範。
- **[E05]** NIST. (2020). *NIST Privacy Framework Version 1.0*. https://www.nist.gov/privacy-framework/privacy-framework 。提供隱私風險管理之治理參考，非具普遍法效力之法律條款。
- **[E06]** UK Government Digital Service. (2025-05-08 update). *Algorithmic Transparency Recording Standard — Guidance for Public Sector Bodies*. https://www.gov.uk/government/publications/guidance-for-organisations-using-the-algorithmic-transparency-recording-standard/algorithmic-transparency-recording-standard-guidance-for-public-sector-bodies 。兩層資訊受眾與權責說明之參照；其義務限於英國指定公共部門，不等於私人遊戲公司法定義務。
- **[E07]** ISO/IEC. (2018). *ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure*. https://www.iso.org/standard/72311.html 。漏洞報告接收、協調及補救資訊揭露的參照；官方頁顯示於 2024 年複審後仍保持現行版本。
- **[E08]** 中華民國《營業秘密法》，全國法規資料庫，特別參照第 2、3、4 條。https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=J0080028 。第 2 條之三要件包含非一般所知、經濟價值與合理保密措施；具體情況應依法判斷。
- **[E09]** 中華民國《個人資料保護法》，全國法規資料庫。https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=I0050021 。尤其第 3、5、11、19、20 條。**修正日期 2025-11-11，官方頁在 2026-10-17 仍註明部分／全部修正條文尚未生效、施行日期另定。** 本文不把尚未施行之新增義務寫成當時已生效法律。
- **[E10]** 中華民國《消費者保護法》，全國法規資料庫，特別參照第 22 條之廣告真實性與履行。https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=J0170001 。
- **[E11]** 中華民國《公平交易法》，全國法規資料庫，特別參照第 21 條之虛偽不實或引人錯誤表示。https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=J0150002 。
- **[E12]** Taiwan Stock Exchange（TWSE）. *2025 Guide to Investing in Taiwan — Information Disclosure / MOPS*. https://www.twse.com.tw/en/about/company/guide.html 。證券市場重大及定期公開資訊的主體和渠道與一般私人公司自願公開制度不同；適用範圍應進一步核對相關正式規範。
- **[E13]** OWASP Cheat Sheet Series. *Authorization Cheat Sheet*. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html 。最小權限、拒絕預設與權限驗證的實務建議。
- **[E14]** JSON Schema. *Draft 2020-12 Specification*. https://json-schema.org/draft/2020-12 。附錄 B 的資料結構規格參照，無法替代法律或語義檢驗。

## B．前置 ANIE 系列研究

以下是本系列內部研究脈絡及既有原稿，**不視為已經取得外部獨立驗證的實證來源**。

- **[I00]** ANIE-00，《從產品黑盒到 AI 原生互動企業》，v0.1，2026-10-16。系列總綱、可驗證交付與外部互動命題。
- **[I01]** ANIE-01，《從 EA 到持續交付》，v0.1，2026-10-16。發行階段、DEMO、Playtest、EA 與正式版之分工。
- **[I02]** ANIE-02，《季度單機產品制：AI 工業化、算力額度與品質交付率》，v0.1，2026-10-16。交付產能、品質與額度假說。
- **[I03]** ANIE-03，《可繼承的遊戲產品：資產移轉、AI 接手與長期可維護性》，v0.1，2026-10-16。
- **[I04]** ANIE-04，《玩家—開發者相交域》，v0.1，2026-10-16。非服從式需求協商。
- **[I05]** ANIE-05，《原生 MOD 生態》，v0.1，2026-10-16。穩定 API、相容性與 AI 遷移。
- **[I06]** ANIE-06，《商業遊戲也可以 PR》，v0.1，2026-10-16。作者權利、契約合作及正式收錄。
- **[I07]** ANIE-07，《Steam 不是唯一入口》，v0.1，2026-10-17。跨平台公開資訊樞紐。
- **[I08]** ANIE-08，《從客服結案到產品認知》，v0.1，2026-10-17。私人客服與產品級資訊回流。
- **[I09]** ANIE-09，《公開決策帳本》，v0.1，2026-10-17。決策、承諾、發布、驗證與更正之公共紀錄。

## C．EveMissLab 既有研究與架構對照

- **[I10]** EveMissLab. (2026-09-21). *APBSC-00｜AI Agent 公開邊界與安全閉包：統合框架*，v0.1，內部研究草稿。指出 AI 觀察、保存與發布權限不同，掃描綠燈不代表安全後置條件真正閉合。
- **[I11]** EveMissLab. (2026-09-21). *APBSC-08｜供應商與平台責任：AI Coding Tool 的 Publication-Boundary Governance*，v0.1，內部研究草稿。對工具供應商、Agent 發布面與跨上下文洩漏提供先導研究。
- **[I12]** Neo.K × Aletheia. (2026-08-01). *企業母 AI：公司作為 AI 的可觀察世界*，v0.1，公開命題研究。無界智庫公開版：https://unboundedaxiom.org/p/lm-002360/ 。描述企業世界狀態與持續認知層，不授權所有資訊自動公開。

---

## 文件狀態、聲明與後續研究

- **文件編號：** ANIE-10，第四部第一篇。
- **文件狀態：** Public Working Paper v0.1，尚未同儕審查；理論建模與方法論提案。
- **實作狀態：** 研究型參考規格；不宣稱實際部署、完成紅隊驗證或符合任何特定認證。
- **原始碼規格：** Canonical UTF-8 Markdown；數學式僅採用 ` $...$ `、`$$...$$` 定界符。
- **實證狀態：** 所有假說尚待實際資料驗證；合成資料不可當成公司營運成果。
- **法規說明：** 依官方來源核對至 2026-10-17，應以實際行為發生時生效條文及具體權利關係判斷；本文不是專業法律意見。
- **下一篇：** ANIE-11，《開放會削弱競爭力嗎：社群創新、信任資產與執行優勢》。