B2B／To C 數位肖像平台｜第一階段產品流程會議記錄

會議結論

• 第一階段鎖定廣告公司／企業端，不開放個人 To C 註冊與 KYC；To C 資料先以雲端表單與人工建檔處理。
• B2B 使用者應保有自己的 Email／Google 登入與帳號資料；企業歸屬以公司名稱、統編與聯絡資訊完成，不做共用帳密。
• 先不展示 Token、訂閱、預付與線上金流，採紙本合約與人工付款流程；日後再保留交易記錄與價格計算的擴充空間。
• 專案是獨立物件：可先建立空白專案、再加選 Talent；候選加入不通知，只有「提交審核」後才讓平台把關並啟動媒合。
• 平台的可信任價值在於合法授權、合約與可追溯性，不是承諾阻止所有外部二次生成；C2PA／隱性浮水印／KYC 需做研究與邊界定義。
• UI 以參考產品的流程為輸入，但要刪除冗長、混亂與安全有漏洞的部分，wireframe 階段再一起打磨操作與資訊層級。

0. 完整議題覆蓋與討論脈絡（擴充版）

本次實際涵蓋的議題

• B2B／To C 的角色、帳號、企業歸屬與第一階段範圍。
• Email／Google 登入、企業基本資料、統編、企業文件與早期人工建檔。
• KYC 的可靠性、人工覆核、第三方服務、未成年與詐騙風險。
• To C 的多 profile、經紀／公司管理多人、不同人生階段肖像、授權偏好與 AI training 同意。
• 平台是否承擔換臉／生成責任，以及 C2PA、隱性浮水印、授權鏈與可追溯性的真實邊界。
• Dashboard、首頁、搜尋、篩選、收藏、專案、候選名單、邀請／審核、合約、付款與交易紀錄。
• Token、方案、平台抽成、媒體用途計價與紙本合約的過渡方式。
• Talent 履歷／作品公開、競品衝突、評價與資料可見性。
• 參考產品的安全／資訊架構問題、wireframe 的優化原則，以及 To B／To C 的後續交付節奏。

0.1 00:01–00:19｜從參考產品拆功能，先把第一階段收窄

會議一開始不是直接畫頁面，而是把參考產品拆成註冊、KYC／企業驗證、Dashboard、Talent 搜尋與專案幾個模組，確認哪些其實是不同角色共用的能力。討論很快碰到一個根本問題：同一個人可能同時是創作者、KOL、公司負責人或買方；若一個帳號要同時承載 To C 與 To B，資料模型、權限和介面都會變複雜。

• 有人主張長期可以讓同一登入帳號切換角色，或至少讓資料模型保留兩種 membership；這能處理「本人不授權肖像，但以公司身分採購」等情境。
• 也有人以參考產品為例，指出其角色切換、刪資料後狀態與登入路徑都很不直覺，不能因為要保留未來彈性而把第一版做成同樣複雜。
• 最終收斂為：第一階段不是公開雙邊平台，而是供少數熟識廣告公司驗證流程的封閉式 B2B pilot。To C 的完整註冊、KYC、Dashboard、主動接案及角色切換都不進第一階段。
• 但「現在不做」不等於「資料上不存在」：帳號、企業關聯、未來 To C／To B 角色與 profile 的擴充空間應保留，避免第二階段必須推倒重來。

這段討論也定義了產品策略上的前提：若日後從受邀企業擴張為公開市場，金流、稅務、資安、客服與工程營運都會是另一個量級，屆時可能需要以新的公司與產品架構重做，而不是把 pilot 一路硬擴。

來源：00:01–00:19。

0.2 00:19–00:25｜KYC 被視為風險控制，不是漂亮的 onboarding 步驟

KYC 討論的起點是「平台若錯認身分，可能讓他人用某人的臉進行詐騙，反而使平台成為犯罪工具」。因此團隊沒有把 KYC 當成一般拍照上傳功能，而是追問它究竟驗證了什麼、由誰承擔錯誤與是否真的能阻止冒用。

• 參考產品看似使用第三方驗證，但團隊無法從前台確定它是純自動比對、人工覆核，還是先放行、後續才審。
• 討論拿銀行與虛擬資產服務作比較：它們通常要求證件、影像與數日稽核，說明可靠驗證未必能即時完成。
• 可行方向包括使用可信賴的第三方 KYC 服務，或採「自動收件＋人工比對」的混合流程；需研究台灣適用性、準確度與成本。
• 第一階段只服務企業，且 To C 不上正式前台，因此不實作個人 KYC；但這不是把問題取消，而是把它列為日後面向 Talent 時的信任基礎研究。
• 未滿 18 歲在本輪被明確視為高摩擦、暫不納入的情境。

來源：00:19–00:25、00:45–00:51、03:21–03:25。

0.3 00:25–00:45｜先盤點 Dashboard，再把「看起來完整」與「真的可用」分開

團隊以參考產品的 Dashboard 為清單，逐一看帳號資料、通知、刪帳號、邀請、Token、方案、帳單、搜尋與 Digital Cast。這段不是要照抄，而是在判斷哪些資訊或入口若現在展示，會讓早期企業誤以為功能已可用。

• Dashboard 應保留帳號、通知、收藏、專案與日後交易紀錄等基本資訊；Token、月額度、儲值、訂閱與假付款頁不該在第一階段出現。
• 團隊特別反對讓使用者在 prototype 中填真實付款或公司資料、卻沒有後端流程；這既造成資安風險，也會製造不必要的客服問題。
• 參考產品被發現有幾個負面教材：角色切換會登出、未完成 KYC 似乎仍能透過網址看到內容、資料刪除後狀態可能不一致、導覽與按鈕層級混亂。這些應列入本產品的避雷清單。
• 聲音、複雜 Digital Cast 生成能力與其他附加模組不屬於現在要驗證的核心；若資料／元件未來有用可留擴充點，但不必顯示入口。
• 對「功能先做、暫時關閉」的態度是：可以保留資料與技術介面，但是否顯示要以早期使用者的理解成本為準；看得到卻不能用的功能，只會引發重複詢問。

來源：00:25–00:45、02:40–02:53。

0.4 00:45–01:07｜To C 的授權不是一個勾選框，而是平台可信任性的來源

雖然 To C 不會先上線，團隊仍花了大量時間拆解其資料與授權語意，因為這些欄位決定日後 B2B 能否正確篩選，也決定平台能否主張自己是在合法使用肖像。

• Talent 應能清楚選擇肖像可被用在哪些產業、媒體與專案類型，也能表示偏好主角／配角、企業級專案等合作條件；這些是媒合訊號，不應默認成不可改的限制。
• AI training 同意必須以可理解的語言獨立呈現。會中明確反對把「資料可能用於訓練」埋在長條款中，因為一般使用者不會讀完也未必理解後果。
• 討論也區分兩件事：平台可承諾「不把未同意的資料拿去訓練」，但不能替所有外部工具或買方保證其私下不會另行訓練。
• 平台不應在第一階段自行承擔換臉、生成結果品質或廣告素材製作責任。較合理的定位是：買方自行使用其工具完成產出，平台提供的是可授權的肖像、條件、合約與使用紀錄；否則生成結果失真、侵權或爭議的責任會被平台吸收。

來源：00:45–00:59、01:00–01:07。

0.5 01:00–01:15｜C2PA／浮水印的價值是可追溯，不是「保證防盜」

會中對 C2PA、隱性浮水印與認證標示有明顯期待，但也有重要的務實收斂：平台不可能靠大型爬蟲監控全網，更無法阻止買方把素材下載後私下二次生成。

• 被認為值得研究的方向是：每筆合法授權可否帶有可識別的 provenance、序號、認證標示或隱性資訊，使平台知道曾授權給哪個企業、何種用途，並在發現爭議時提供舉證線索。
• 被否決的過度承諾是：宣稱平台可以自動發現所有未授權生成、完全防止外流，或把一般可見浮水印當成完整保護。
• 對外價值主張應改成「合法來源、可追溯授權鏈、可協助處理爭議」。若公開看到未在授權紀錄中的使用，Talent 與平台會有更清楚的權利依據，而不是聲稱技術能抓到一切。
• 技術上仍未知：C2PA metadata 能否在後續生成流程被保留、隱性浮水印／代碼實際能提供什麼證據力、以及成本與供應商怎麼選。因此本輪只把它列為研究與對外說明的候選，不當作已完成能力。

來源：01:00–01:05、03:21–03:25。

0.6 01:08–01:15｜多 profile 其實是兩種不同產品，不能混為一談

參考產品允許一個帳號有多個 profile，團隊發現這個表面簡單的設計背後至少有兩種完全不同的需求：

• 同一個人不同人生階段／外貌／可授權肖像：每個 profile 仍屬同一人，但資料、價格與可用範圍可能不同。
• 經紀公司或管理單位管理多位不同 Talent：每一人都應各自完成身分與授權確認，且可能有不同抽成、價格與聯絡流程。

結論不是立刻選一種，而是先把兩個情境分開記錄。若是後者，註冊、權限、驗證與付款模型都不能只是「family 底下多一個 profile」；第一階段不需要解這題，但不能讓簡化的 schema 把未來選擇封死。

來源：01:08–01:15。

0.7 01:15–01:40｜B2B onboarding 的核心是個人帳號＋企業歸屬，不是共用帳密

這一段花了很長時間討論早期廣告公司如何進場。關鍵矛盾是：大型企業要拿公司登記文件可能很慢，但若只給一組共用帳密，又無法區分各 team 的收藏、專案、聯絡與責任。

• 最終偏向每位 B2B 使用者仍有自己的 Email／Google 登入與密碼；企業資料是該帳號的歸屬／驗證資訊，不是共用帳號容器。
• 同一企業可以有多個人帳號。不同 team 的候選、收藏與專案預設彼此隔離，即使都屬於同一家公司。
• 第一階段可由平台先拜訪、蒐集資料、手動建檔或提供測試帳號，降低企業取得文件的摩擦；但正式設計不應被「臨時 demo 帳號」綁死。
• 最小企業資料初步收斂為企業名稱、統一編號、聯絡人與必要聯絡方式；公司登記文件／稅務資料的強制性、驗證方式與紙本合約如何配合仍待確認。
• 介面上可讓使用者知道未來有個人選項，但第一階段只開企業路徑，避免誤導。

這段也留下了一個未解的 operating question：早期是讓企業使用者自行註冊後輸入企業 code／資料，還是由平台預先建立並發帳密。會中傾向「產品長期採個人登入，pilot 可人工協助」，不是把預建帳號當唯一流程。

來源：01:15–01:40。

0.8 01:40–02:00｜Token、方案與抽成：先把真實商業流程講清楚

團隊花時間拆解參考產品的 Token 與多方案，發現其差異主要是預付額度，而非第一階段真正需要的產品價值。

• Token 被理解為計價／儲值、行銷包裝、日後資料分析或 community 的可能工具，不是 pilot 必要條件。
• 第一階段若展示 Token、月額度或「方案」，企業會立刻追問何時能買、怎麼扣、是否可退；因此決定先隱藏。
• 不顯示 Token 不代表不思考定價。Talent 的基礎肖像費、媒體型態、使用地區／期間、平台服務費與經紀分成仍需建模。
• 會中出現「Talent 七成、平台三成」等示例，只是用來說明可能的拆帳邏輯，不是已拍板的分潤比例。
• 團隊認為平台收費需要能對應真實服務：合法性、授權紀錄、合約、C2PA／追溯能力與爭議協調，而不只是把買方與 Talent 接起來。

來源：01:40–01:50。

0.9 02:00–02:18｜專案先於 Talent，候選不是邀請，提交審核才是閘門

這是會議最具體的流程收斂。原參考流程把「建立專案」、「選 Talent」、「付款」混在一起，造成大家無法判斷一個空專案是否合理、Talent 何時會被通知、平台又何時應介入。

• 專案是獨立物件。 企業可以先從 Dashboard 建空白專案，填需求、品牌／客戶資訊、用途、預算、聯絡與補充說明，再去找人；這符合「先有需求，再找合適人」的工作方式。
• 從 Talent 頁發起建立專案也應可行，但只預帶該 Talent 作為候選。從 Dashboard 建立的空專案則不應出現 Talent 區塊，直到使用者主動加入。
• 「加入專案」代表企業內部 shortlist，不是向 Talent 發送邀請。候選可在送件前自由增刪，Talent 不應在這階段收到通知。
• 團隊一度討論要在建立空專案後立刻稽核，最後收斂為：候選與需求大致確認後，由企業按 提交審核；平台先看產業、品牌、用途、肖像權條件與其他風險，通過後才開始媒合／通知。
• 正式執行仍要經平台審核、雙方同意、紙本合約與付款。這些完成後，專案才可切換為執行中。

此設計把「草稿／候選池／提交審核／媒合／合約付款／執行」拆開，也讓平台能在 Talent 被打擾之前拒絕不適合的案件，例如高風險產業或不符合平台原則的用途。

來源：02:00–02:18。

0.10 02:18–02:40｜把複雜流程轉成直覺操作：入口不同，但都回到同一個專案

在確認狀態機後，討論進入更細的互動設計，重點是避免使用者建立完專案卻不知道下一步，也避免為了加入候選而被強制跳頁。

• 建立後應回到該專案內容／管理頁，而不是停在空白表單或直接把人送去另一頁；內容頁要清楚呈現候選與下一步。
• 若專案尚無候選，可提供「前往尋找 Talent」或同等明確引導；但不宜在儲存後硬把人跳走，避免失去脈絡。
• 在 Talent 詳情點「加入專案」時，應以彈窗／popover 列出既有專案，並提供建立新專案的分支；不要把使用者丟回專案列表。
• 若從 Talent 頁建立新專案，下一頁要明確顯示已帶入的該名 Talent；若從 Dashboard 建立，則沒有預帶候選。兩個入口最後都指向同一種專案內容模型。
• 收藏功能保留作為較早期的候選池；黑名單被提起，但沒有被列為現階段優先功能。

來源：02:18–02:40。

0.11 02:21–03:00｜履歷、搜尋、首頁與資訊架構：先做可理解的 B2B 工作台

其餘討論主要在定義 B2B 工作台的資訊架構，以及哪些功能必須等資料與商業規則成熟。

• Talent 未來可有已參與專案、作品與被選用紀錄，方便買方避開競品或了解履歷；但 Talent 是否可選擇隱藏、作品如何公開、是否造成同業衝突，都還沒有決定。
• 搜尋頁需要關鍵字、平台預先定義的 Tags、篩選與排序。排序可先考慮身高、年齡等客觀欄位；評價／rating 要等累積足夠資料與規則後才有意義。
• 首頁第一階段應是一頁式 B2B 說明：平台的合法合規價值、使用流程、註冊／登入入口。Global、framework、API、Token／pricing 等參考產品的分支先不放。
• Dashboard 可用側邊導覽收納帳號設定、通知、收藏、專案等；找 Talent 與建立／編輯專案可保留為較明確的核心頁，避免首頁和 Dashboard 同時堆滿入口。
• 團隊明確要求 UI 不照抄參考產品。參考其商業流程，但要移除過長文字、相似按鈕、模糊導覽與不必要跳轉；wireframe 是開始逐頁改善這些問題的時點。

來源：02:21–03:00。

0.12 03:00–03:26｜交付節奏、To C 表單與研究工作

會議最後才把前面所有討論轉成下一步；這部分不只是排程，也反映第一階段如何用人工流程承接尚未產品化的 To C。

• 先產出／確認優化後的 B2B flow chart，再進 B2B wireframe；wireframe 過程中再讓設計與產品一起優化 UI，而不是現在就對畫面微調做過度承諾。
• To C 先不做前台，改以中文雲端表單／欄位清單蒐集資料。做法傾向先將參考產品的 profile、授權、篩選項目拆成可刪改清單，交由相關方確認，再定稿成表單。
• Talent 的紙本肖像／授權同意與「註冊時蒐集的資料」被明確區分：前者屬正式簽約，後者是建立可搜尋資料的 intake；不能混成一張模糊表單。
• 會中提及：先於下一工作週確認 B2B flow；暫抓 7/31 16:00 進行 C2PA、KYC 與隱性浮水印的內部研究討論；以 8/7 作為 wireframe／UI 檢視節點。另有一處口語提到的日期與前述節奏不完全一致，因此實際行事曆仍應再確認。
• C2PA／浮水印／KYC 的研究會不只由技術端說明，而要先整理「想保護什麼、能承諾什麼、要問供應商什麼」，讓產品、商務與設計可共同判斷。

來源：03:00–03:26。

本次討論中刻意沒有假裝已決定的事項

• To C 多 profile 要優先支援不同人生階段肖像，還是經紀／公司管理多人。
• 企業 onboarding 的最終驗證方式：統編、公司文件、人工拜訪紀錄、企業 code 與紙本合約如何組合。
• 每種媒體用途、地區、期間的價格計算公式與平台／Talent／經紀分潤。
• Talent 履歷、合作品牌、評價與作品的公開範圍，以及競品排他與退出權。
• C2PA／隱性浮水印的技術選型、可驗證範圍與是否在第一階段對外呈現。
• 專案審核的具體 SLA、拒絕規則與何種資料必須在提交時具備。

1. 第一階段的產品邊界

只做 B2B，To C 暫時不做完整前台

第一階段的目標是讓少數廣告公司能試用平台、驗證「找人—談合作—合法使用肖像」的流程，而不是立即建立公開市場。因此：

• 先開放企業端；個人／創作者端的完整註冊、KYC、審核、個人 Dashboard 與主動接案均延後。
• To C 所需資料改由雲端表單蒐集，再由平台人工建檔；未來要做前台時，再把已確認的欄位、授權與篩選條件轉為產品流程。
• 企業端可保留「個人」選項的資訊提示，但第一階段不開放該入口，避免使用者對未完成流程產生期待。
• 對少數熟識企業的 demo 可使用預先建好的資料與帳號；正式使用仍以個人 Email／Google 登入為主，避免日後帳號轉正與權限拆分的麻煩。

來源：00:12–00:16、01:17–01:18、01:34–01:37、03:10–03:13。

B2B 註冊與企業驗證

第一階段的 B2B 註冊要足夠簡單，核心不是完成嚴格企業 KYC，而是辨識「此使用者屬於哪個企業」。建議最小欄位：

• 個人登入：Email／Google 第三方登入與個人密碼設定。
• 企業歸屬：企業名稱、公司統編、聯絡人姓名與必要聯絡方式。
• 長期欄位先保留：企業文件、稅籍／帳務資訊、企業驗證與方案資料，但不必在第一階段強制上傳。
• Demo 與早期導入：若大型企業取得公司登記文件困難，先由平台人工協助建檔、以紙本合約或既有拜訪資料驗證。

會中也指出參考產品有「KYC 未完成仍可瀏覽內容、角色切換會登出、資料刪除後狀態不一致」等問題；本產品不應複製這些安全與體驗缺口。

來源：00:45–00:53、01:17–01:18、01:26–01:37。

2. B2B 核心使用流程

建議的專案狀態機

建立草稿專案
  → 填寫需求與使用條件
  → 瀏覽／收藏／加入候選 Talent（僅企業端可見）
  → 提交平台審核
  → 審核通過並發出邀請／進入媒合
  → 雙方確認、紙本合約與付款完成
  → 專案執行中

關鍵原則：

• 專案先於 Talent。 企業應可先建立空白需求，再依需求找人；從 Talent 頁建立專案則可預帶該 Talent 作為候選。
• 加入不等於邀請。 加進專案的 Talent 只是企業內部 shortlist，尚不通知對方。
• 提交審核才是閘門。 平台可在通知 Talent 前檢查產業、用途、內容與合規風險，避免不適合的平台案件繼續流轉。
• 執行不是建立後立刻發生。 需經平台審核、雙方確認、合約與付款後才切換為「執行中」。

來源：01:51–01:53、02:09–02:15。

「找人」頁與專案的互動

• Talent 搜尋頁保留關鍵字、Tags、篩選與排序；可能的排序包括身高、年齡與資料成熟後的評價。
• 收藏功能保留，方便在建立專案前形成候選池；黑名單不是當前優先事項。
• 「加入專案」應開啟彈窗，列出可加入的既有專案，並提供建立新專案的分支；避免把使用者帶離目前的搜尋脈絡。
• 若從某位 Talent 直接建立新專案，可在專案表單顯示已預帶的單一候選；若從 Dashboard 建立空專案，則不顯示 Talent 區塊，直到後續加入候選。
• 專案建立完成後應進入專案內容／管理頁，明確呈現下一步「找 Talent」或「提交審核」，不要讓使用者在列表中迷路。

來源：02:16–02:17、02:28–02:40。

專案表單要留下什麼

第一階段的專案表單應留下真正會影響媒合與授權的資訊：

• 專案需求與背景。
• 公司／品牌資料；若是代理商，企業資料可預帶入，再補品牌或客戶資訊。
• 使用範圍、媒體型態、地區／期間等肖像權條件。
• 預算與價格條件。
• 可聯繫、可作決策的窗口。
• 補充說明。

線上 legal approval、上傳正式合約與付款元件可先移除，改由紙本合約處理；但欄位結構應預留，避免未來重做資料模型。

來源：01:53–02:01、02:04–02:06。

3. 定價、Token 與帳單

第一階段：不做 Token 與線上金流

• 不顯示 Token 餘額、月額度、儲值、訂閱方案或假付款頁，避免製造使用者必須追問的未開放功能。
• 合作價格、平台抽成、付款週期與款項分配先靠紙本合約與人工流程處理。
• Dashboard 的「帳單」若保留，內容應是付款方式／流程說明，以及未來可回看的交易記錄，而不是 Token 定價頁。

長期：價格計算與平台價值仍要建模

• Talent 的肖像使用費可能隨媒體型態（例如數位、戶外、電視）與使用範圍累加，因此專案內需逐步形成價格計算模型。
• Token 可以是後續的儲值、分析、社群與行銷包裝工具，但不該在尚未有實際金流前提早暴露。
• 平台的服務價值不只是名單媒合，還包含授權、合約、追溯與爭議處理；抽成／加價模式要在定價資料到位後決定。

來源：01:37–01:45、02:40–02:47。

4. To C、授權與可信任邊界

To C 的資料與 profile 模型

雖然 To C 不在第一階段上線，會中已確認幾個必須保留的設計問題：

• 多 profile 可能代表同一人不同人生階段／不同肖像，也可能代表經紀公司管理多位 Talent；兩種情境的帳號與驗證流程不同，不能混成一種。
• 創作者應能填寫偏好角色（主角／配角等）、不想合作的產業、可使用的肖像範圍與價格條件；這些是 B2B 篩選與降低溝通成本的關鍵資料。
• 後續可考慮顯示已參與專案與作品履歷，但須先釐清本人是否能隱藏、競品排他與公開作品的授權規則。

來源：00:37–00:41、01:11–01:14、02:22–02:24。

KYC、C2PA 與浮水印：平台做什麼、不做什麼

• KYC 是身分驗證問題，較適合使用專業第三方服務或人工審核；第一階段因只做企業端，暫不實作。
• 平台不可能靠大型爬蟲阻止所有私下二次生成或未授權使用；可信任承諾應改為「可證明合法來源、可記錄授權鏈、違規時可追溯」。
• C2PA／內容憑證與隱性浮水印值得研究：它們可協助辨識由平台合法取得的素材與授權線索，但不能被描述成全面防盜或完全阻止再生成的機制。
• 所有 AI training、肖像用途與可接受的產業選項必須清楚、可理解、可選擇；不可把重要授權藏在長條款裡。

來源：00:19–00:25、00:52–01:02、03:21–03:25。

5. 首頁、Dashboard 與 UI 原則

第一階段的資訊架構要少而清楚：

• 首頁：B2B 導向的一頁式說明，清楚說明平台目的、合法合規價值與完整使用流程；只放註冊與登入入口。
• Dashboard：帳號／通知、專案管理、收藏與必要的付款記錄；避免 Token、全球／框架／API 等未開放區塊。
• 核心獨立頁：找 Talent、建立／編輯專案；其餘盡量收在 Dashboard 的側邊導覽中。
• UI 不照抄參考產品。參考其商業流程，但要重做過長文字、相似按鈕、模糊入口與不合理跳轉；wireframe 是把這些決策落地的時點。

來源：02:54–03:02。

6. 待辦與後續決策

• 完成 B2B 優化版 flow chart：將「企業優先、建立專案、加入候選、提交審核、合約／付款後執行」畫成可與團隊確認的版本。
• 整理 To C 欄位清單／flow：將參考平台欄位拆成可刪改的項目，交由相關方確認哪些 profile、授權與篩選資料必須保留；確認後再做中文雲端表單。
• 釐清企業註冊最小資料：企業名稱、統編、聯絡人與必要驗證方式；同時定義早期人工建檔與正式自助註冊的切換條件。
• 取得定價與合約流程資料：確認肖像權媒體用途、價格組合、平台抽成、付款時間點與紙本合約步驟。
• 研究 C2PA、KYC 與隱性浮水印：先定義平台可承諾的追溯能力、不能承諾的防護邊界，以及第一階段是否要放進對外說明。
• 先完成 B2B wireframe，再討論 UI；To C 前台暫以表單／人工流程承接。

會中提及的節奏：下一工作週確認 flow、之後進入 B2B wireframe；另暫定 7/31 16:00 進行 C2PA／KYC／浮水印的內部研究討論，並以 8/7 作為 wireframe／UI 檢視節點（年份未明）。

7. 仍待回答的問題

• 企業驗證在早期究竟由什麼資料構成？統編、公司文件、紙本合約、人工拜訪紀錄的組合與責任邊界為何？
• 平台審核需要在「提交審核」前檢查哪些內容？產業、用途、品牌、預算、肖像權條件與不合規案件如何處理？
• 專案價格怎麼由 Talent 基礎報價、媒體型態、使用期間、地區與平台費用組成？哪些資訊對買方與 Talent 透明？
• C2PA／浮水印能提供的證明力到哪裡？若素材在平台外被再生成，平台如何蒐證、提醒與處理，而不過度承諾？
• To C 多 profile 要優先支援「同一人不同時期」還是「經紀公司管理多人」？兩者是否應用不同帳號模型？
• 作品履歷、已合作品牌與評價是否公開？如何避免競品衝突、過度曝光與不當評價？

轉錄與品質註記

• 音檔時長：3 小時 26 分 14 秒。
• 轉錄採 Meeting Notes v2 direct lane；214/214 個語音窗皆通過文字與對齊品質閘門，未解析語音比例為 0%。
• Diarization 偵測到 6 位說話者，但所有聲紋比對皆未達保守門檻，因此本記錄不以人名歸屬發言或待辦。
• 依本次要求，未執行 Context ingestion、知識庫寫入或 speaker learning；本頁是根據可稽核逐字稿整理的會議紀錄，非逐字稿全文。