從兩端開始Start from both ends
of the problem

一端是問題：我到底要解決的是什麼？先把它拆開，拆到能對上一個數字為止。另一端是結果：那個數字要變成多少？然後從結果往回推。中間這五個問題，就是用來把兩端接起來的。One end is the problem: what am I actually solving? Take it apart until a piece lines up with a number. The other end is the result: what does that number have to become? Then work backwards. The five questions in between are the bridge.

A · 問題端The problem end我到底要解決什麼？What am I actually solving?

用一句話寫出問題：誰、什麼現象、多久一次、差多少A one-line problem statement: who, what, how often, how much
拆成子問題，先拆流程、再拆原因Break it into sub-problems: by process first, then by cause
拆到有一層對得上一個數字，就停Stop at the layer that lines up with a number

⇢五個問題Five questions從結果往回問，AI 到第四題才出場Asked backwards from the result; AI enters at question four⇠

B · 結果端The result end要得到什麼結果？What result do we need?

一個數字，不是一個方向One number, not a direction
baseline 在哪、target 多少、什麼時候要達到Where the baseline is, what the target is, by when
誰會在上面簽名Who signs their name on it

客戶第一次講的，通常是症狀或是解法，不是問題。「門診拖太晚」是症狀，「我們需要 AI」是解法。我會先把它拆開，拆到有一層能對上一個數字。What a client says first is usually a symptom or a solution, not the problem. "Clinics run late" is a symptom; "we need AI" is a solution. I take it apart until one layer lines up with a number.

1 · 問題陳述State it一句話：誰、什麼現象、多久一次、差多少。「胸腔科每節門診比排程多跑 25 分鐘」，而不是「門診效率不好」。One line: who, what, how often, by how much. "Chest medicine runs 25 minutes over per session", not "clinic efficiency is poor".

2 · 拆開Break it down先照流程拆（候診、看診、檢查、領藥），每一段再拆原因。子問題之間不重疊、合起來不漏。By process first (waiting, consult, tests, pharmacy), then by cause inside each. Sub-problems do not overlap and leave nothing out.

3 · 假設Hypothesise先猜最可能的那一支，只驗證那一支，不用每一支都查。驗證的方法要便宜：到現場坐一天、做訪談、抽資料來看。Pick the most likely branch and test it; do not audit every branch. Testing should be cheap: sit in for a day, interview, pull a sample.

4 · 收斂Converge拆到有一層能對上一個數字，就停在那一層。那個數字就是候選 KPI，接到結果端去。Stop at the layer that lines up with a number. That number is the KPI candidate, and it connects to the result end.

拆的時候，我守三條顧問的規矩Three consulting rules I keep while cutting

MECE子問題之間不重疊、合起來不漏。檢查法：每一支加起來等不等於整體？兩支之間有沒有重複算到同一件事？每一支能不能分開量？Sub-problems do not overlap and leave nothing out. The check: do the branches add up to the whole? Does anything sit in two branches? Can each branch be measured on its own?

兩棵樹Two trees先畫問「為什麼」的診斷樹，找到真正的原因；再畫問「怎麼辦」的解法樹。順序反過來，就會拿著解法找問題。First a diagnostic tree that asks "why", to find the real cause; then a solution tree that asks "how". Reverse the order and you end up holding a solution looking for a problem.

假設驅動Hypothesis-driven每一支先寫下一個猜測，還有「如果猜對了，應該會看到什麼」，然後只查最可能的那一支。查完發現不對，再換下一支。Each branch gets a guess and a "if true, we would see…". Test only the most likely branch; if it fails, move to the next.

拆法有四種，看問題長什麼樣子來挑Four ways to cut, chosen by the shape of the problem

照流程By process候診 → 看診 → 檢查 → 領藥。適合「到底卡在哪一段」這種問題。Waiting → consult → tests → pharmacy. For "where is the wait" problems.

照公式By formula停機時數＝故障次數 × 每次停機時間。每一項都量得到，KPI 自然就出來了。Downtime = failures × time per failure. Every term is measurable, so the KPI falls out.

照客群或地區By segment分行 × 業務線 × 客戶類型。適合「哪裡最嚴重」的問題。Branch × business line × customer type. For "where is it worst" problems.

照能不能寫成規則By yes / no用規則就做得到的／需要人判斷的。這一刀決定要不要用 AI。Rule-based / needs judgement. This cut decides whether AI is needed at all.

把解法當問題Solution as problem「我們需要 AI」不是問題陳述。"We need AI" is not a problem statement.

流程跟原因混在一起Process mixed with cause拆出來的子問題互相重疊，查了也不知道該改哪裡。Overlapping sub-problems; you investigate and still do not know what to change.

拆太細Too fine拆到沒有任何一層對得上數字，KPI 就定不出來。No layer lines up with a number, so no KPI can be set.

兩棵我實際畫過的樹Two trees I have actually drawn

每一步都有它存在的理由，但「必要」不代表「只能這樣做」。先問這一步產出的是什麼，再問最直接的路是哪一條。Every step exists for a reason. But "necessary" doesn't mean "only this way." Ask what it produces, then ask for the most direct route.

1 · 它會產出什麼？1 · What does it produce?日期、數量、門檻這類 → 用規則就好。分類、預測 → 靠資料跟標註。判斷、生成 → 這時候才需要模型。A date, a count, a threshold → a rule. Classify or predict → data and labels. Judge or generate → then a model.

2 · 最直接的路是什麼？2 · The most direct route?先算一下不用新技術的做法要花多少錢。沒有這個基準，什麼 AI 方案看起來都划算。First cost out the no-new-tech option. Without that baseline, every AI option looks worth it.

3 · 多付的錢買到了什麼？3 · What does the extra cost buy?要往上爬一階，就要講得出數字會多改善多少、要多扛多少風險。講不出來，就先別往上爬。Going up a rung has to buy a number I can state, and a risk I can state. If I can't, I stay down.

這不是標準答案，只是問問題的順序。越下面越便宜，先從下面問起。It's not a standard, it's an order of questions. Cheaper at the bottom, so start there.

先從數字開始，找到產生這個數字的流程，再找出最值得改的那一步，挑最便宜、又改得動它的方法。然後講定下週一開始，誰要換個做法。Start with the number. Find the process behind it. Find the one step worth changing. Pick the cheapest thing that changes it. Then decide who does something different on Monday.

第一次見面我就會問這些。答案決定整合怎麼接、交付物怎麼切。每一題後面都寫了我為什麼問，還有聽到哪些答案我會特別留意。I ask these in the first meeting. The answers decide how we integrate and how we cut the delivery. Each one comes with why I ask, and which answer is a red flag.

AI 成果怎麼管：靠一個迴路How an AI outcome is controlled: one loop

五個節點，每一個都對應一章。治理跟資安是第三個節點，不是丟在附錄。自動播放會停在這個視角最在意的那個節點。Five nodes, one chapter each. Governance and security are the third node, not an appendix. Autoplay stops on the node this lens cares about most.

Outcome Dashboard

一頁只盯一個數字，其他東西都是在解釋它為什麼動、為什麼不動。這裡拿捷運手扶梯的預測性維護當示範。One number per page. Everything else explains why it moves. Illustrative data: metro escalator maintenance.

打開可以實際操作的 AIOM 成果儀表板（虛構示範資料）↗Open the working AIOM outcome cockpit (synthetic demo data) ↗

這一章只是靜態示意；完整互動版放在This chapter is a static sketch; the working version is the AIOM Outcome Cockpit ↗

AIOM Outcome Cockpit可以實際操作的子專案：先看主管視角，再往下看每週簡報、結果 vs baseline、振動偏差、KPI 象限、生命週期。數字都是虛構的示範資料。A working sub-project: an executive view first, then the weekly brief, outcome vs baseline, vibration deviation, KPI quadrant and lifecycle. All numbers are synthetic demo data.

開啟 ↗Open ↗

KPI vs 承諾KPI vs commitment

採用（leading）Adoption (leading)

舊表單還有 35% 的人在用：舊流程不退場的話，數字就會彈回去。35% still on the old sheet. If it doesn't retire, the number bounces back.

Baseline: Jan–Jun avg, SOW §4.2Source: CMMS + sensor gateway, client system of recordReviewed weekly with client示範資料Illustrative data

#	承諾（SOW）Promised (SOW)	實際做到的（我親自驗證）Built (verified by me)	狀態Status	行動Action
M1	12 個月的感測器資料跟維修紀錄都進到 pipeline 裡12 months of sensor + maintenance history in the pipeline	9 個月；2024 Q1 的檔案格式不一樣，還沒解析9 months; 2024 Q1 files in a different format, unparsed	Drift	我寫了解析腳本把資料補齊，下週再重跑 baselineWrote the parser myself; baseline re-run next week
M2	模型 v1 在 holdout 上 precision ≥ 0.70Model v1 precision ≥ 0.70 on holdout	0.74，holdout 的定義已經核對過0.74, holdout definition checked	On promise	—
M3	警示會自動建立 CMMS 工單Alerts auto-create CMMS work orders	現在是每天匯出 CSV，再人工建單Daily CSV export, manual ticketing	Drift	IT 那邊的 API 權限卡了 6 週；先用 n8n 寫進去，等 API 開通之後再切換過去Client IT API access stuck 6 weeks; n8n writes for now, switch when API opens
M4	先試行 20 台，技師完成訓練20 units piloted, technicians trained	20 台已上線，18 位技師都訓練完了20 live, 18 technicians trained	On promise	—
M5	舊的 Excel 巡檢表要退場Old Excel inspection sheet retired	進行中，還有 35% 的人在用In progress, 35% still using it	In progress	跟站務主管約時間談，把退場日期定下來Meeting station managers to set a retirement date

「做出來的」那一欄，都是實際跑過、打開來看過才填上去的，不是從狀態報告抄來的。I write the Built column after I've run it, read it and opened it myself. Not from a status report.

上報紀錄（每一筆都附解法）Escalation log (always with a fix)

W	問題Issue	建議解法Recommended fix	狀態Status
19	CMMS API 權限延誤，連帶影響 M3，也會拖到 Q2 的數字CMMS API delay will hit the Q2 number	先用 n8n 暫時代替寫入，兩週就能上線n8n as interim writer, live in two weeks	Open
21	兩站的技師不信警示，還是手動覆核Two stations don't trust alerts, re-check manually	先拿前 10 次警示的命中紀錄給他們看Show them the hit record of the first 10 alerts	Open
15	Baseline 期間有碰到一次電力中斷Baseline window included a power outage	照 SOW 的 exclusions 先剔掉，再重算一次Excluded per SOW, baseline recalculated	Closed

證據鏈跟下一個機會Evidence trail & next opportunity

機會Opportunity	為什麼是現在Why now	預估價值Est.
電梯模組，同一個站點Elevator module, same stations	同一套感測跟工單流程可以重複用Same sensor + work-order flow reusable	SGD 180K
第二條路線，20 台Second line, 20 units	試行跟沒試行的對照組已經建好Pilot vs control comparison established	SGD 220K

每個月的 KPI 是客戶的 Facilities 出的，不是我們自己算的Monthly KPI issued by the client's Facilities team, not computed by us
省下的停機損失，用客戶財務那邊提供的每小時成本換算Avoided downtime valued at the client's own hourly cost

哪個 KPI 先做？看三個分數：影響力、業務衝擊（越低越好）、導入成本（越低越好）。你可以改分數、拉權重，排名會即時更新。Which KPI first? Three scores: impact, disruption (lower is better), cost (lower is better). Change a score, drag a weight, the ranking updates.

Net Gain = Impact × 20 · Investment Cost = (w_D·Disruption + w_C·Cost) ÷ (w_D+w_C) × 20 · Priority = w_I·Net Gain − (1−w_I)·Investment Cost · ROI% = Priority ÷ Investment Cost × 100

影響力權重Impact weight w_I 0.50

業務衝擊權重Disruption weight w_D 0.50

成本權重Cost weight w_C 0.50

#	候選 KPICandidate KPI	影響力Impact	衝擊Disrupt	成本Cost	Net Gain	Inv. Cost	Priority	ROI%

左上角是 Net Gain 高、Investment Cost 低的項目，先做這些。氣泡越大代表 ROI 越高，藍色的是前兩名。Top-left is high Net Gain, low Investment Cost: do first. Bigger bubble, higher ROI; blue marks the top two.

KPI CardKPI Card

交付物是我交給你的東西，成果是你的數字真的動了。SOW 裡這兩個都要寫進去。A deliverable is what I hand you. An outcome is your number moving. The SOW needs both.

一條線上有三個點：起點、承諾、現在。One line, three marks: where we started, what we promised, where we are.

Baseline 120 h用上半年的平均，寫進 SOW 簽核。沒有 baseline，你就沒辦法說它「有動」。First-half average, signed in the SOW. No baseline, no "it moved."

Target 84 h · Q4−30%。而且要連續一季都達標才算數。−30%. It has to hold for a full quarter.

Guardrails誤報要 ≤ 15%，計畫性維修最多只能 +10%。不能靠多排維修，把停機「消滅」掉。False alerts under 15%, planned maintenance up no more than 10%. You can't fix downtime by scheduling more downtime.

如果 leading 指標連不到 KPI，KPI 又連不到錢，那它就是虛榮指標。If I can't draw a line from the indicator to the KPI, and from the KPI to money, it's a vanity metric.

客戶不肯承諾數字怎麼辦？Client won't commit a number? 那我先承諾量測方法。花四週把 baseline 建起來，再一起定數字。Then I commit to the measurement. Four weeks for a baseline, then we set the number together.

每月非計畫停機時數Unplanned downtime · h / monthMRT escalators · 範例example

Business question: 停機造成多少服務中斷，還有多少緊急出勤成本How much service disruption and emergency call-out cost does downtime create
Metric & formula: Σ 非計畫停機分鐘 ÷ 60，每月計算，計畫性維修不算進去Σ unplanned downtime minutes ÷ 60, monthly, excluding planned maintenance
System of record: CMMS 工單的時間戳記；由客戶的 Facilities 部門持有CMMS work-order timestamps; owned by the client's Facilities team
Grain & window: 每台／每月；每月出報表，每季判定Per unit / per month; monthly report, quarterly judgement
Baseline: 1–6 月平均 120h，已在 SOW §4.2 簽核Jan–Jun average 120h, signed in SOW §4.2
Target & deadline: 84h · Q4 季底Q4 month-end
Exclusions: 電力中斷、人為破壞、供應商召回Power outage, vandalism, vendor recall
Guardrails: 誤報率 ≤ 15%；計畫性維修的時數增加不能超過 10%False-alert rate ≤ 15%; planned maintenance hours up no more than 10%
Leading indicators: 24h 內處理完的警示比例、由模型觸發的工單比例Alerts handled within 24h; share of work orders from the model
Owner (client): Head of Station Facilities
Attribution rule: 試行的 20 台 vs 沒試行的 20 台，做對照20 piloted units vs 20 untouched units

資安框架：成熟度模型、Zero Trust、NIST CSF 2.0Cybersecurity frameworks:
maturity, Zero Trust, NIST CSF 2.0

有些成果像爬梯子，要爬上這一階才看得到下一階在哪。所以 KPI 得一階一階定。Some outcomes are a climb. Each rung shows you the next one, so the KPI moves with the ladder.

示範用的是 Zero Trust 的 Identity 支柱，照 CISA ZTMM 分四級。Example: the Identity pillar of Zero Trust, on CISA's four levels.

梯子是怎麼讓 KPI 動起來的How the ladder keeps the KPI honest

每一階都有一張 KPI 卡片，量的是這一階的條件做到多少。One KPI card per rung. It measures how much of that rung is done.
只承諾下一階。爬到了之後，再來估下一階。合約就用 change order 一階一階往上加。Commit to the next rung only. Re-estimate when you get there. Extend by change order.
護欄是用來防止偷吃步的：不能改定義，也不能把風險評低。Guardrails stop cheating. No redefining levels, no rating risk down.
用在哪：監理成熟度、Zero Trust、AI 治理、AI 採用都可以。Works for: regulatory maturity, Zero Trust, AI governance, AI adoption.

成熟度怎麼變成合約：一年四個 gateFrom maturity to contract: four gates a year

	Q1	Q2	Q3	Q4
做什麼Work	界定範圍：哪些系統在裡面、核心／間接／周邊怎麼分；第一次評估，拿到 baseline；挑兩個最弱的構面Fix the scope: which systems are in, and which are core / indirect / peripheral; first assessment, baseline; pick the two weakest dimensions	把這兩個構面推到下一級Move those two dimensions up one level	第二次評估；其他構面跟上Second assessment; the other dimensions catch up	第三方或內稽複評，把分數寫進年報Independent or internal-audit re-score; the number goes into the annual report
KPI	評估完成率 100%，每格都有證據Assessment 100% complete, evidence in every cell	兩個構面各 +1 級Two dimensions each +1 level	整體分數 ≥ baseline + 0.5Overall score ≥ baseline + 0.5	複評跟自評的分數差 ≤ 0.3Re-score within 0.3 of self-assessment
合約裡寫的In the contract	固定費，交付物是評估報告Fixed fee; deliverable is the assessment report	達級付款 70 / 3070 / 30 payment on level reached	change order：下一級才加進來Change order: the next level is added only now	最後 20% 看複評結果Final 20% rides on the re-score
沒過 gate 的話If the gate fails	整體等級會被最弱的那一格拖住，所以哪個構面或系統沒過，就單獨輔導那一塊：補證據、補流程、補設定，補到那一格過為止，不要去硬拉整體分數。輔導之前，先回頭看範圍：是核心系統沒過，還是周邊系統拖累？核心沒過，就停在這一級；周邊沒過，可以切出去，下一季再補。另外也要檢查等級是不是寫得太寬，要改就走 change control。這兩條路都走不通，就停損，不往下一季加錢。The overall level is held down by the weakest cell, so the failing dimension or system gets its own remediation: close the evidence, process or configuration gap until that cell passes, instead of forcing the overall score up. Before remediating, go back to scope: did a core system fail, or is a peripheral one dragging? A core failure holds the level; a peripheral one can be carved out and fixed next quarter. Check at the same time whether the level is written too loosely, which goes through change control; if neither works, stop, and no money is added for the next quarter.

成熟度模型就五個零件：先界定範圍，再來是構面、等級、每一格的證據、算分的規則。少一個，它就只是一張好看的表。A maturity model has five parts: scope first, then dimensions, levels, evidence for every cell, and a scoring rule. Miss one and it is just a nice-looking table.

0 · 界定範圍Scope先畫系統邊界，再把邊界裡的系統分三層：核心、間接、周邊。分法照 ISMS（ISO 27001）的系統等級定義來；有 AI 的話，再疊一層 AIMS（ISO 42001）的 AI 系統分級。範圍沒先講清楚，後面每一格都會吵。Draw the system boundary first, then tier what sits inside it: core, indirect, peripheral. The tiering follows the ISMS (ISO 27001) system classification; where AI is involved, layer the AIMS (ISO 42001) AI-system classification on top. Get the scope wrong and every later cell turns into an argument.

核心Core直接產生或處理那個數字的系統Systems that produce or process the number itself間接Indirect餵資料進去、或接結果出來的系統Systems that feed data in or take results out周邊Peripheral碰得到，但不影響結果；可以切到下一季Connected, but does not move the result; can wait a quarterAIMS有 AI 的系統再疊一層分級：照 AI 治理那一章的第一層來打分，分數高的歸到核心層，而且要獨立驗證AI systems get one more tier on top: the layer-1 score from the AI governance chapter; High → core tier, independent validation

1 · 構面Dimensions三到五個，彼此不重疊。太多，沒人填得完；太少，看不出差異。Three to five, non-overlapping. Too many and nobody fills it in; too few and nothing shows.

2 · 等級Levels四到五級，每一級都寫成能回答「是」或「否」的陳述句。Four or five, each written as declarative statements a reviewer can answer yes or no to.

3 · 證據Evidence每一句陳述都要指定「拿什麼來證明」：文件、設定、紀錄、抽測。沒有證據的等級不算。Every statement names its proof: a document, a setting, a log, a sample. A level without evidence does not count.

4 · 算分Scoring規則寫死，誰來評都一樣；而且不准跳級。Fixed rules so anyone scores the same way, and no skipping levels.

Dimension level = 這個構面從下往上，每一級陳述都答「是」、中間沒斷掉的最高那一級highest level where every statement in that dimension is "yes"　·　Overall score = Σ(w_d × level_d) ÷ Σ w_d　·　Gate = 下一季只承諾「下一級」，拿第一次自評當 baselinecommit only to the next level per quarter, first self-assessment as baseline

我畫過的一張爬山圖：ESG 成熟度模型One I drew: an ESG maturity model

在 Deloitte 時我起草了這個四構面的模型。下面是它的骨架，格子裡是示意用的描述；點任一格，可以看那一級要拿出哪些證據。At Deloitte I drafted this four-dimension model. The skeleton is below with illustrative cell text; click a cell to see what evidence that level needs.

四個構面對得上 NAEM 成熟度路徑的四個主題（business focus / culture / data / technology）；構面底下放哪些指標，是先做重大性評估（materiality）再挑的，不是全放。ESG 的「範圍」就是報告邊界：營運控制還是財務控制，先講清楚。The four dimensions line up with the four themes of the NAEM maturity pathway (business focus / culture / data / technology); the metrics under each dimension come out of a materiality assessment, not a full list. For ESG, "scope" is the reporting boundary: operational or financial control, settled up front.

做成熟度模型最常踩的四個坑Four traps in maturity work

自評灌水Self-assessment inflation每個單位都說自己是 L3。Every unit says it is at L3.解法：證據清單＋抽測，分數由第三方或內稽出。Fix: evidence list plus sampling; the score comes from audit, not the unit.

跳級Skipping levels直接承諾 L5，連 L2 的文件都還沒有。Committing to L5 with no L2 documents.解法：合約只寫下一級，爬到了再用 change order 加。Fix: the contract names the next level only; add the rest by change order.

改定義Moving the goalposts達不到就把陳述改寬一點。When it is hard to reach, the statement gets loosened.解法：定義要做版本控管，改動要走 change control。Fix: version the definitions; changes go through change control.

成熟 ≠ 成果Maturity is not an outcome已經到 L4，但事故沒變少、停機也沒變短。At L4, yet incidents and downtime have not moved.解法：每一階旁邊放一個結果數字，兩個一起看。Fix: put an outcome number next to every level and read them together.

我實際用過的五套成熟度模型Five maturity models I have worked with

模型Model	結構Structure	誰在用Who uses it	我拿它來做什麼What I used it for
CISA Zero Trust Maturity Model v2	5 支柱 × 4 階段，外加 3 條橫向能力5 pillars × 4 stages, plus 3 cross-cutting capabilities	美國聯邦機關；金管會 2024 零信任指引的分級參考US federal agencies; the staging reference for Taiwan FSC's 2024 Zero Trust guidelines	銀行 Zero Trust 藍圖的現況評估、三年路線圖Current-state assessment and three-year roadmap for a bank's Zero Trust blueprint
DoD Zero Trust Strategy	7 個支柱、45 項能力、152 項活動，分 Target / Advanced7 pillars, 45 capabilities, 152 activities, Target vs Advanced	美國國防部與其供應鏈US DoD and its supply chain	對照用：跟客戶解釋金管會指引的分級是從哪裡來的，哪些活動對銀行其實太重As a cross-reference: explaining to clients where the FSC staging comes from, and which activities are too heavy for a bank
FFIEC CAT	固有風險五個等級 × 五個領域成熟度Five inherent-risk levels × five domains of maturity	美國的銀行監理機關；台灣的銀行拿來當自評參考US bank supervisors; Taiwanese banks use it for self-assessment	海外分行合規巡檢的評分骨架，還有「爬山圖」那一頁Scoring skeleton for overseas-branch compliance reviews, and the mountain chart in the next tab
ISO/IEC 42001 readiness	條文 4–10，加上附錄 A 的 38 項控制，分「符合／部分符合／不符合」三檔Clauses 4–10 plus 38 Annex A controls, scored Met / Partial / Gap	要拿 AI 管理系統驗證的企業Organisations heading for AI management-system certification	AI 治理差距分析，產出的就是 AI 治理那一章的三根柱子AI governance gap analysis; the output became the three pillars in the AI governance chapter
AI 採用階梯（自己畫的）AI adoption ladder (my own)	L1 試用 → L5 嵌進流程，每一級一張 KPI 卡片L1 pilot → L5 embedded in the workflow, one KPI card per level	要從 PoC 走到上線的企業客戶Enterprise clients going from PoC to production	GenAI 助理、Agentic 自動化的季度 gate，見「三個 AI 示範」Quarterly gates for GenAI assistants and agentic automation; see the three AI demos

美國分行：先量固有風險，再決定每個領域要爬到哪一級。CAT 在 2025 年退場，換成 NIST CSF，這套做法一樣適用。US branches: measure inherent risk first, then set the level each domain has to reach. CAT retired in 2025; the same logic works on NIST CSF.

固有風險概況：這家分行為什麼要爬到這一階Inherent risk profile: why this branch has to climb this high

技術與連線類型Technologies & connection types

服務通路Delivery channels

線上／行動產品與技術服務Online/mobile products & tech services

組織特性Organizational characteristics

外部威脅External threats

這家分行整體風險評為 Moderate。風險越高，成熟度就要爬得越高。This branch: Moderate. Higher risk, higher climb.

領域 3：一年內要過的四個 gateDomain 3, four gates in a year

Q1	Q2	Q3	Q4
Evolving 這一階的每一條陳述都答「是」（100%），而且證據查得到100% of Evolving statements "Yes", evidence on file	Intermediate 做到 40%，每個缺口都有 owner 跟到期日40% of Intermediate; every gap has an owner and a date	完成 80%，內稽抽測也通過了80%; internal-audit sampling passed	100%，有獨立驗證，會向董事會跟主管機關報告100%; independently verified; reported to board and regulator

第二個例子：Zero Trust 五大支柱Second example: Zero Trust, five pillars

CISA 的 Zero Trust 成熟度模型分五大支柱、四個階段，另外還有三項橫跨所有支柱的共通能力。金管會 2024 年的零信任參考指引，分級方式就是以這套跟美國國防部的版本為基礎。CISA's Zero Trust Maturity Model: five pillars, four stages, plus three capabilities that cut across all pillars. Taiwan's FSC 2024 Zero Trust guidelines took their staging from this and the US DoD version.

先講架構，再講成熟度：NIST SP 800-207Architecture first, then maturity: NIST SP 800-207

五大支柱講的是「哪些東西要成熟」，800-207 講的是「這些東西放在架構的哪裡」。每個支柱的訊號會送進 Policy Engine，PEP 才有依據決定要不要放行；只要有一個支柱還停在 Traditional，Policy Engine 就少一種訊號可以參考。The five pillars are what you mature; 800-207 is where they sit. Each pillar feeds signals into the Policy Engine, which is what gives the PEP grounds to allow or deny; a pillar still at Traditional is one signal the engine cannot see.

五大支柱、四個階段Five pillars, four stages

NOW／TARGET 是以一家中型銀行為例的示意，不是任何真實客戶的評分。NOW / TARGET show an illustrative mid-size bank, not any real client's score.

參考圖Reference figures

這裡放兩張參考圖。金管會的 Zero Trust 指引，分級就是參考 CISA 跟美國國防部這兩套。Two reference figures. The FSC Zero Trust guidelines drew on CISA's and the US DoD's levels.

Implementing the CISA Zero Trust Maturity Model: seven steps from assess and benchmark to partner with expert — Implementing the CISA Zero Trust Maturity Model · reference figure (Napkin)

Zero Trust maturity journey from Traditional to Initial, Advanced and Optimal drawn as a mountain climb — Zero Trust Maturity Journey · reference figure

同一把梯子也可以拿來用在 AI 上，每一階都有自己的 KPI 跟 gate。The same ladder, applied to AI. Each rung has its own KPI and gate.

用到這些框架的案子Engagements that used these frameworks

2023–24
台灣金融業第一個 Zero TrustTaiwan's first banking Zero Trust
Deloitte · US$4M
2022–24
海外合規巡檢（美泰星港）Overseas compliance reviews (US, TH, SG, HK)
Deloitte · 一套評分，四個國家Deloitte · one rubric, four countries
2023–24
證券商 ISO 27001:2022 改版Securities firms · ISO 27001:2022
Deloitte · 五家Deloitte · five firms
2021–22
銀行 ISMS／PIMSBank ISMS / PIMS
Deloitte · 30+

AI 治理：以 ISO/IEC 42001 為骨架，每一條都拿得出證據AI governance,
built on ISO/IEC 42001

治理不是多開一個委員會。我用 ISO/IEC 42001 的架構，把五個原則（透明、問責、公平、安全與隱私、持續改進）落到 Annex A 的控制項：每一項都有人負責、有紀錄可查、有證據可以交給稽核。Governance isn't one more committee. I use the ISO/IEC 42001 structure to turn five principles (transparency, accountability, fairness, security and privacy, continuous improvement) into Annex A controls, each with an owner, a record and evidence an auditor can check.

ISO/IEC 42001 是 AI 管理系統（AIMS）的國際標準。我把它想成一棟房子：屋頂是管理系統本身，五根柱子是治理原則，地基是 Annex A 的 38 項控制。點任一根柱子，看它的意思、我怎麼落地、交得出什麼證據。ISO/IEC 42001 is the international standard for an AI management system (AIMS). I think of it as a building: the roof is the management system, the five pillars are the principles, the foundation is the 38 controls in Annex A. Pick a pillar to see what it means, how I put it in place and what evidence it produces.

ISO/IEC 42001 LAISO/IEC 23894ISO/IEC 27001 LAISO/IEC 27701BS 10012ISO/IEC 27799CISA (exam passed, experience requirement in progress)EU AI Act

五個原則取自 ISO/IEC 42001 Annex C 列的 AI 目標（問責、公平、隱私、安全、透明與可解釋等），加上第 10 章的持續改進。The five principles draw on the AI objectives listed in ISO/IEC 42001 Annex C (accountability, fairness, privacy, security, transparency and explainability, among others) and on continual improvement in clause 10.

Annex A 有 9 個控制域、38 項控制。不是每一項都要做：依組織的風險挑選，在適用性聲明（SoA）裡寫清楚哪些採用、哪些不採用、為什麼。下面是 9 個控制域，還有每一域我會交出去的東西。Annex A has 38 controls in nine areas. Not every control applies: you choose by risk and justify each choice in the Statement of Applicability (SoA). Here are the nine areas and what I hand over for each.

Annex A	控制域Control area	項數Controls	要求什麼What it asks	我交出的東西What I hand over
A.2	AI 相關政策Policies related to AI	3	有一份 AI 政策，跟資安、隱私、品質政策對得上，並定期檢討。An AI policy that fits with security, privacy and quality policies, reviewed on a schedule.	AI 政策草案、跟現有政策的對照表AI policy draft, cross-walk to existing policies
A.3	內部組織Internal organization	2	角色跟責任講清楚，員工有管道回報疑慮。Clear roles and responsibilities, and a way for staff to report concerns.	RACI、疑慮回報流程RACI, concern-reporting procedure
A.4	AI 系統的資源Resources for AI systems	5	資料、工具、運算資源跟人力都要盤點、記錄。Data, tooling, compute and people, documented.	資源清冊：模型、API、運算資源、人員能力Resource register: models, APIs, compute, skills
A.5	AI 系統影響評估Assessing impacts of AI systems重點Focus	4	評估系統對個人、群體跟社會的影響，並留下文件。Assess and document impacts on individuals, groups and society.	影響評估範本、評估紀錄Impact assessment template and records
A.6	AI 系統生命週期AI system life cycle	9	需求、設計、驗證與確效、部署、上線後的運作與監控、技術文件、事件日誌。Requirements, design, verification and validation, deployment, operation and monitoring, technical documentation, event logs.	八步交付流程裡的關卡跟文件Stage gates and documents in my eight-step delivery
A.7	AI 系統的資料Data for AI systems重點Focus	5	資料怎麼取得、品質怎麼確保、來源追不追得到、怎麼前處理。How data is acquired, its quality, its provenance and how it is prepared.	資料清冊、品質規則、資料血緣Data inventory, quality rules, lineage
A.8	給利害關係人的資訊Information for interested parties	4	給使用者的說明文件、對外報告、事件通報。User documentation, external reporting, incident communication.	System card、事件通報流程System card, incident communication procedure
A.9	AI 系統的使用Use of AI systems	3	負責任使用的流程跟目標，系統只用在當初設定的用途。Processes and objectives for responsible use; the system stays within its intended use.	使用守則、預期用途聲明Acceptable-use rules, intended-use statement
A.10	第三方與客戶關係Third-party and customer relationships重點Focus	3	跟供應商、客戶之間的責任怎麼分。How responsibilities are split with suppliers and customers.	供應商評估、合約條款清單Supplier assessment, contract clause checklist
	合計Total	38	9 個控制域Nine control areas

我會先做深的三個地方Three areas I go deepest on

Clause 6.1 · A.5AI 風險與影響評估AI risk and impact assessment開工前評一次；換資料、換模型、換使用者群或提高自動化程度時再評一次。風險評估看組織會出什麼事，影響評估看個人、群體跟社會會受什麼影響，兩個分開做。評分方式在「風險評分」那一頁。Assess before we build, and again whenever the data, model, user group or level of automation changes. Risk assessment asks what can go wrong for the organisation; impact assessment asks what it means for individuals, groups and society. They are done separately. The scoring is on the Risk scoring tab.交付：風險清冊、影響評估紀錄、再評估觸發條件Hand-over: risk register, impact assessment record, re-assessment triggers

A.7資料治理Data governance訓練跟檢索用的資料，要說得出從哪裡來、有沒有授權、品質夠不夠、有沒有偏。資料血緣追得到，每一次轉換都有紀錄。個資跟醫療資料先分級，再決定能不能用、能不能出境。For training and retrieval data, we can say where it came from, whether we have the right to use it, whether the quality is good enough and whether it is skewed. Lineage is traceable and every transformation is recorded. Personal and health data are classified first, then we decide whether they can be used and whether they can leave the country.交付：資料清冊、品質規則跟檢查結果、資料血緣圖Hand-over: data inventory, quality rules and results, lineage map

A.10 · A.4.4供應鏈與第三方Supply chain and third parties企業導入 AI，常常用的是別人的模型、API 跟雲。誰負責什麼要先寫進合約：客戶資料能不能拿去訓練、模型改版會不會先通知、出事多久要通報、我們能不能稽核。Enterprise AI usually runs on someone else's model, API or cloud. Write who owns what into the contract: whether customer data can be used for training, whether model changes are notified in advance, how fast incidents are reported, and whether we can audit.交付：供應商清單跟評估、合約條款清單、責任分配表Hand-over: supplier register and assessment, contract clause checklist, responsibility matrix

控制域名稱跟項數依 ISO/IEC 42001:2023 Annex A；中文是我的翻譯，說明跟交付物是我的整理。Control areas and counts follow ISO/IEC 42001:2023 Annex A. The descriptions and hand-overs are my own summary.

風險評分我分兩層。第一層先把 use case 分級，決定要看多深；第二層才逐條幫風險打分，決定要做什麼控制、誰來簽。開工前評一次，之後只要換資料、換模型、換使用者群或提高自動化程度，就要重評。I score risk in two layers. Layer one tiers the use case and decides how deep the review goes; layer two scores each risk and decides which controls apply and who signs. Score before we start, and again whenever the data, the model, the user group or the level of automation changes.

Layer 1use case 分級：決定要看多深Tier the use case: how deep五個因素各給 1–3 分，加總後分成低／中／高。對應的是金管會 AI 指引的六個考量、MAS 的 impact × complexity × reliance，以及 EU AI Act 的高風險清單。Five factors, 1–3 each, summed into low / medium / high. Lines up with Taiwan FSC's six considerations, MAS's impact × complexity × reliance, and the EU AI Act high-risk list.

Layer 2風險登錄表：決定要做什麼Risk register: what to do每一條風險先用 Likelihood × Impact 打分，再扣掉控制有效性，得到殘餘風險；殘餘風險決定要過哪一道 gate。對應的是 ISO/IEC 23894 跟 42001 的風險處理。Each risk gets Likelihood × Impact, less control effectiveness, giving residual risk; residual sets the gate. Lines up with ISO/IEC 23894 and 42001 risk treatment.

第一層：自己點點看Layer 1: try it

第二層：量表先講清楚，分數才會有人信Layer 2: define the scales, or nobody trusts the score

Likelihood 1–5

1 · 幾乎不會，一年不到一次Rare, less than once a year
2 · 一年幾次A few times a year
3 · 每個月Monthly
4 · 每週Weekly
5 · 每天都在發生Daily

Impact 1–5

財務、客戶與個人、監理、聲譽四個面向各自評，取最嚴重的那一個Score four facets and take the worst: financial, customer or people, regulatory, reputation

1 · 可忽略，內部處理掉Negligible, handled internally
3 · 客戶受影響、要補救；主管機關會問Customers affected, remediation needed; the regulator asks
5 · 法定通報、人身安全、重大裁罰Mandatory reporting, personal safety, major sanction

控制有效性，看證據不看自評Control effectiveness, by evidence not self-assessment

0 · 沒有控制No control
0.3 · 有設計，寫在文件裡Designed, in a document
0.5 · 有執行、有紀錄Operating, with records
0.7 · 測試過（抽測或演練）Tested (sampling or drill)
0.9 · 獨立驗證過Independently validated

Inherent Risk = Likelihood (1–5) × Impact (1–5) · Residual Risk = Inherent × (1 − Control effectiveness) · Gate: Residual ≥ 10 → 一定要有 HITL + 管理層簽核HITL required + management sign-off；5–9.9 → 關鍵決策 HITL + 抽測HITL on key decisions + sampling；< 5 → 監控monitor

要評的七類風險The seven risk categories I score

模型Model準確度、漂移、幻覺Accuracy, drift, hallucinationISO/IEC 23894 資料Data品質、個資、外洩、資料出境Quality, personal data, leakage, cross-borderISO/IEC 27701 · 27799 安全Securityprompt injection、資料外傳、agent 越權Prompt injection, exfiltration, agent overreachOWASP LLM Top 10 · Zero Trust 營運Operational可用性、第三方依賴、kill switchAvailability, third-party dependence, kill switchMAS AIRM · 27001 合規ComplianceEU AI Act、金管會 AI 指引、PDPA / 個資法EU AI Act, FSC AI guidelines, PDPA42001 Annex A 公平與可解釋Fairness & explainability偏誤、說不清楚為什麼Bias, unexplainable decisions42001 · IMDA 人People自動化偏誤：審查步驟大家都直接按過Automation bias: the review step everyone clicks throughIMDA · MAS

EU AI Act 的分級是另一條線，分數再低也抵不掉：只要落在高風險清單裡（信用評估、關鍵基礎設施的安全元件、醫療器材），就直接適用高風險系統的義務。ISO/IEC 23894 管的是方法，EU AI Act 管的是門檻。這裡用的是示範資料。The EU AI Act tier is a separate line, not something a score can buy down: anything on the high-risk list (creditworthiness, safety components of critical infrastructure, medical devices) takes the high-risk obligations outright. ISO/IEC 23894 supplies the method; the EU AI Act supplies the threshold. Sample data.

治理不會等到最後一章才做。八步裡每一步都有一份治理產出，第八步的 evidence pack 就是把這些全部裝訂起來。Governance isn't the last chapter. Every one of the eight steps produces one governance artefact; the evidence pack in step eight is just those, bound together.

ISO/IEC 42001 是自願採用、可以拿去驗證的國際標準；EU AI Act 是法規。兩者的關係是：用 42001 建好的管理系統，能交出 AI Act 要的大部分證據，但光有 42001 驗證，不等於符合 AI Act。下面是高風險 AI 系統的主要義務，跟 42001 裡對應的地方。ISO/IEC 42001 is a voluntary, certifiable international standard; the EU AI Act is law. The link: a management system built on 42001 produces much of the evidence the Act asks for, but a 42001 certificate alone does not mean you comply with the Act. Below are the main obligations for high-risk AI systems and where they sit in 42001.

EU AI Act	高風險系統的要求High-risk requirement	對應的 ISO/IEC 42001Where it sits in ISO/IEC 42001
Art. 9	風險管理系統Risk management system	6.1 風險評估與處置 · A.5 影響評估6.1 risk assessment and treatment · A.5 impact assessment
Art. 10	資料與資料治理Data and data governance	A.7 · A.4.3
Art. 11	技術文件Technical documentation	A.6.2.7 · A.6.2.3
Art. 12	紀錄保存（日誌）Record-keeping (logs)	A.6.2.8 事件日誌A.6.2.8 event logs
Art. 13	透明，以及提供給部署者的資訊Transparency and information for deployers	A.8.2 · A.9.4 預期用途A.8.2 · A.9.4 intended use
Art. 14	人為監督Human oversight	A.9.2 負責任使用 · A.6.1.3 設計流程 · A.3.2 角色A.9.2 responsible use · A.6.1.3 design process · A.3.2 roles
Art. 15	準確度、穩健性與資安Accuracy, robustness and cybersecurity	A.6.2.4 驗證與確效 · 搭配 ISO/IEC 27001A.6.2.4 verification and validation · with ISO/IEC 27001
Art. 17	品質管理系統Quality management system	第 4–10 章，也就是 AIMS 本身Clauses 4–10: the AIMS itself
Art. 25	價值鏈上的責任分配Responsibilities along the value chain	A.10 第三方與客戶關係A.10 third-party and customer relationships
Art. 72–73	上市後監控、嚴重事件通報Post-market monitoring, serious-incident reporting	A.6.2.6 · A.8.4 · 第 10 章A.6.2.6 · A.8.4 · clause 10

這張對照是我自己整理的，不是官方對照表。截至 2026 年 11 月：EU AI Act 第一個調和標準 EN 18286（AI 品質管理系統）在 2026 年 10 月公告，設計上是疊在 42001 上面，它帶來的符合推定主要涵蓋第 17 條的品質管理系統；42001 驗證本身沒有這個效果。2026 年的 Digital Omnibus 修正把高風險系統的義務延到 2027 年 12 月（附件 III）跟 2028 年 8 月（附件 I 的產品）。金管會的 AI 指引跟 MAS 的 AI 風險管理指引，我用同一套控制去對。The mapping is mine, not an official cross-walk. As of November 2026: the first harmonised standard under the Act, EN 18286 (quality management for AI), was cited in October 2026. It is designed to sit on top of 42001, and the presumption of conformity it offers mainly covers the Article 17 quality management system; a 42001 certificate carries no presumption on its own. The 2026 Digital Omnibus amendments moved high-risk obligations to December 2027 (Annex III) and August 2028 (Annex I products). I map Taiwan's FSC AI guidelines and the MAS AI risk-management guidelines to the same controls.

從 proposal 到 SOW，再到驗收Proposal → SOW → delivery

在 Deloitte 是先談 proposal，簽約後寫 SOW，人天由我估算。在 iKala 則是先跑 PoC，收費是簽約金加訂閱。兩邊有一點是一樣的：proposal 裡的每一塊，到頭來都要能驗收。Deloitte: negotiate the proposal, sign, then write the SOW. I priced in person-days. iKala: PoC first, signing fee plus subscription. Either way, every block of the proposal has to become something you can verify.

我對照了兩個外部基準：一個是 McKinsey 轉型辦公室的 L0–L5 gate，另一個是 SaaS 客戶成功那套 value realization。我的八步跟它們都對得上，差別只在我把「簽字」單獨寫成一步。Two outside benchmarks: McKinsey's L0–L5 transformation gates, and SaaS value-realization practice. My eight steps line up with both. The difference is that I make the signature its own step.

−70%一開始估的價值，到 L5 真正實現時平均會掉七成，所以 pipeline 要準備到目標的 3 倍Initial value estimates fall ~70% by L5, so the pipeline needs 3× the targetMcKinsey, 18 APAC transformations

~30%只有三成的轉型有達到原定目標Only about 30% of transformations hit their intended targetsMcKinsey

4每個 initiative 大概四個里程碑最剛好：有早期預警，又不會管得太細About four milestones per initiative: early warning without micromanagingMcKinsey

2–4每個客戶定 2–4 個 SMART KPI，每一個都要附上 baseline、資料來源、target 跟 deadline2–4 SMART KPIs per account, each with baseline, data source, target, deadlineValue realization practice

我已經在做的Already in my method

KPI 要先把 baseline、資料來源、target、deadline、owner 寫清楚（KPI card）KPI with baseline, data source, target, deadline, owner (the KPI card)
量測在 onboarding 的時候就接好，不要事後才去找資料（instrumentation 本身就是交付物）Instrument during onboarding, don't hunt for data afterwards (instrumentation is a deliverable)
每週看執行面（tactical）、每月看 KPI、每季做 business review（這就是 dashboard 的節奏）Weekly tactical, monthly KPI pulse, quarterly review (the dashboard cadence)
把採用率當領先指標，看 activation、使用頻率跟使用深度Adoption as a leading indicator: activation, frequency, depth
要報給管預算的人，不是只報給使用者Report to the budget owner, not only the users

從這些基準學到、準備補進來的做法What I'm taking from the benchmarks

一開始的估算要打折：每個候選 KPI 的預估價值先乘以 0.3，再來排優先順序Discount early estimates: multiply each candidate's estimated value by 0.3 before ranking
每週每個 initiative 都要有一個具體動作，不用等到里程碑One concrete action per initiative every week, not just at milestones
精簡指標：對結果貢獻不到 0.01% 的指標就合併掉Prune metrics: anything under 0.01% of impact gets folded in
一個 owner 最多扛三個 initiative，不然會變成 20% 的人做 80% 的事Cap owners at three initiatives, so 20% of people don't carry 80% of the load
QBR 之前先把資料對清楚，不要在主管面前吵數字Reconcile the data before the QBR, never in front of the executive

來源：Sources: McKinsey, Keeping transformations on target · Umbrex, Value Realization & Success Management

先把目標設好，再看現況，收尾一定要有人簽字。上面是 Evlos 的五個階段，藍框是我多加的三步。Target first, then the current state. And someone signs at the end. Evlos phases on top; the blue ones are the three steps I add.

最常斷在 5 跟 6 之間：上線慶祝完，舊表單其實還開在第二個螢幕上。所以舊流程的退場日期要寫進 SOW，也要放上 dashboard。It usually breaks between 5 and 6. We celebrate go-live and the old sheet is still open on the second screen. So the retirement date goes in the SOW and on the dashboard.

Proposal 裡的東西In the proposal	SOW 裡要變成什麼Becomes, in the SOW	我過去的做法My past practice
價值主張、預期效益Value proposition	KPI card 上要有：數字、baseline、target、deadline、owner、量測方法KPI card: number, baseline, target, deadline, owner, method	董事會層級 roadmap 上的每個 initiative，都有指定的 owner 跟 KPIEvery initiative on a board roadmap had a named owner and KPI
交付物清單Deliverables list	每一項都配 acceptance criteria：怎樣才算交件、誰來簽收、幾天內要回覆Each with acceptance criteria: what counts, who signs, response days	政府案的話，期初 / 期中 / 期末報告各自都有審查會跟修正期Government: inception / interim / final reports, each with review and revision window
時程Timeline	Milestone 搭配 gate，過不了就不往下走Milestones with gates	Zero Trust：assessment 過了，才會進到 implementationZero Trust: implementation only after the assessment gate
範圍Scope	In / out of scope / client obligationsIn / out of scope / client obligations	資料、權限、人、決策時限，這些都寫成客戶的義務Data, access, people and decision deadlines as client obligations
報價Pricing	付款跟 acceptance 綁在一起；outcome-based 的部分要寫爭議處理條款Payment tied to acceptance; dispute clause for any outcome-based part	按人天計價（Deloitte）；bundle 的成本跟毛利模型（iKala）Person-day pricing (Deloitte); bundle cost and margin model (iKala)
假設Assumptions	Assumptions & dependenciesAssumptions & dependencies	資料拿得到、API 開得通、使用者可以來參加訓練Data accessible, API available, users available for training
—	Change control	政府案就走公文變更；企業案就走 change orderOfficial correspondence for government; change orders for enterprise

振動感測器 → 捷運手扶梯：先把問題問對，再談模型Vibration sensors → metro escalators: get the question right before the model

做感測器的客戶以為 AI 可以直接預測機械手臂故障。振動資料很多，但標好的故障幾乎沒有。我把案子改成有維修紀錄的捷運手扶梯，做出一個有 baseline 的預測性維護模型；機械手臂留到第二階段。A sensor maker believed AI could predict robotic-arm failures out of the box. Plenty of vibration data, almost no labelled failures. I re-scoped it to metro escalators, where maintenance logs exist, and delivered a predictive-maintenance model with a real baseline. The robotic arm became phase two.

US$100K合約金額contract value

6個月的感測資料months of sensor data

2個階段：手扶梯先，機械手臂第二phases: escalators first, robotic arm second

資料從左邊的感測器走到右邊的保養工單；維修結果再回頭變成標籤。Data runs from the sensors on the left to the work order on the right; repair outcomes flow back as labels.

怎麼開始的How it started

客戶收了振動資料，也收了第一筆款，團隊就準備從 FFT 開始從頭做。We had the vibration data and a first payment, and the team was about to build FFT features from scratch.

我問了兩件事。第一，現成的物理 AI 平台都有了，為什麼還要自己從頭刻？第二個問題更大：振動資料很多，標好的故障幾乎沒有，模型就沒東西可以學。所以我回頭提了另一個有標籤資料的案子：捷運手扶梯。I asked two things. One: physics-AI platforms already exist, why hand-build this? Two, the bigger one: lots of vibration data, almost no labelled failures, so nothing to learn from. I went back with a case that had labels: metro escalators.

成交 US$100K，六個月的感測資料，做出來的是一個有 baseline 的預測性維護模型。這次學到的是：先把問題問對，往往比換一個更好的模型有用。Closed at US$100K on six months of sensor data, delivered a predictive-maintenance model with a real baseline. The lesson: a better question usually beats a better model.

成果怎麼量How the result gets measured

Baseline 是現在的做法：定期保養加事後維修。模型要贏的是這個，不是贏另一個模型。The baseline is today's practice: scheduled maintenance plus repair after failure. That is what the model has to beat, not another model.
三個驗收指標：預警提前量（故障前幾天亮燈）、誤報率（每台每月幾次）、覆蓋率（維修紀錄裡的故障類型，模型抓得到幾種）。Three acceptance metrics: warning lead time (days before failure), false-alarm rate (per unit per month), coverage (how many failure types in the logs the model catches).
商業上看兩個數字：非計畫停機時數、緊急維修次數。這兩個降了，保養合約才談得下去。Two business numbers: unplanned downtime hours and emergency call-outs. When those fall, the maintenance contract follows.
資料條件寫進合約：維修工單要跟感測資料對得上時間，不然沒有標籤。Data readiness goes into the contract: work orders must line up in time with sensor data, or there are no labels.

客戶名稱跟實際數字不公開，當面聊。Client and actual numbers withheld; happy to discuss in person.

健檢中心的營養師助理：自己查得到，就不用轉介A nutritionist's assistant at a health-check group: find it yourself, no referral needed

台灣前三大的健檢集團。營養師在諮詢時要查檢項說明、衛教文件、飲食建議跟內部 SOP；以前查不到就得問內部專家、再轉介。我們把這些文件整理成一個有權限、有來源的知識庫，接上 LINE 跟網頁，2025 年 1 月到 9 月做完。One of Taiwan's three largest health-check groups. During consultations nutritionists look up test explanations, patient-education material, diet guidance and internal SOPs; when they couldn't find it they asked an internal expert or referred the case on. We turned those documents into a permissioned knowledge base with sources, connected to LINE and the web, January to September 2025.

30位營養師在用nutritionists using it

800+每月查詢次數queries a month

9個月，2025 年 1 到 9 月months, Jan–Sep 2025

每個答案都帶來源段落；營養師的回饋回寫到知識庫。Every answer carries its source passage; nutritionist feedback is written back to the knowledge base.

流程改了什麼What changed in the workflow

以前Before

查不到Can't find it
問內部專家Ask an internal expert
等回覆Wait
轉介給專科Refer the case on

現在Now

問一句Ask once
看來源段落Read the source passage
自己判斷Decide
回覆受檢者Answer the client

內部專家只看被標記「答不出來」的問題。Internal experts only see questions flagged as unanswered.

我堅持的三件事Three things I held the line on

每個答案都附來源段落。營養師看得到出處才敢用，這也是稽核軌跡的起點。Every answer cites its source passage. Nutritionists only trust what they can check; it is also the start of the audit trail.
權限跟著角色走，受檢者的個資不進知識庫。知識庫裡只有文件，沒有人。Permissions follow roles; no client personal data enters the knowledge base. Documents only, never people.
先量採用，再量效益。每月查詢量、回答有沒有被採用，這兩個先看；省了多少諮詢時間，第二年再量。Measure adoption before benefit. Monthly queries and whether answers get used come first; consultation time saved is a second-year number.

成效數字還沒量完，目前只有採用率；客戶名稱不公開。Benefit numbers are still being measured; adoption is what exists today. Client withheld.

同一個健檢集團的第二個案子：LINE 當單一入口，內部效率跟對外營收一起做Second engagement with the same group: LINE as the single front door, one lane for efficiency and one for revenue

第一個案子做完，集團把 2026 年的 AI 跟雲端預算一起拿出來談。我寫的提案是雙主軸：A 線是內部流程（HR、財會），B 線是對外成長引擎（導流分流、To-B 看板、AI+CRM 報價）。每個模組都有驗收條款、分數跟 ROI。2025 年 10 月提案，已成交。After the first engagement the group put its 2026 AI and cloud budget on the table. My proposal had two lanes: A for internal process (HR, finance), B for the growth engine (patient routing, a B2B partner dashboard, AI+CRM pricing). Every module carries acceptance terms, a score and an ROI. Proposed October 2025, signed.

−25%平均等待時間（驗收目標）average waiting time (acceptance target)

−30%核銷天數（驗收目標）reimbursement cycle days (target)

≤60sTo-B 報表出報（驗收目標）B2B report generation (target)

上面是 A 線，下面是 B 線，兩條都從 LINE 進來，底下共用同一個平台。Lane A on top, lane B below, both entering through LINE and sharing one platform underneath.

每個模組都打分Every module scored

模組Module	Net Gain	Investment CostInvestment Cost	ROI
A · HR／財會流程A · HR / finance process	4.25	2.75	154.5%
B1 · 健檢導流／分流B1 · Routing / queue	4.42	3.03	145.9%
B2 · To-B 成效看板B2 · B2B partner dashboard	4.15	2.50	166.0%
B3 · AI+CRM 報價策略B3 · AI+CRM pricing	4.00	2.10	190.5%

分數 1–5。Net Gain 是四個效益細項的平均，Investment Cost 是四個成本細項的平均，ROI% ＝ Net Gain ÷ Investment Cost。Scores 1–5. Net Gain averages four benefit items, Investment Cost four cost items; ROI% = Net Gain ÷ Investment Cost.

三個階段，兩年內Three phases inside two years

1	A：Onboarding＋預算檢核；B：智慧預約／分流（等待 −25%）A: onboarding + budget checks; B: smart booking / routing (waiting −25%)
2	B：跨場域導流（轉換 +10%）、To-B 看板（出報 ≤60 秒）；A：核銷阻擋擴充B: cross-site routing (conversion +10%), partner dashboard (≤60s); A: wider reimbursement blocking
3	B：AI+CRM 報價策略器（覆蓋 ≥80%、報價迴轉 −30%）；總體驗收、SOP 跟教材B: AI+CRM pricing engine (coverage ≥80%, quote turnaround −30%); overall acceptance, SOPs, training

四類風險先寫好對策Four risk classes, countermeasures first

資料合規：DPIA、最小化收集、同意留痕、對外交換先匿名化Data compliance: DPIA, minimal collection, consent records, anonymised exchange
整合：舊系統沒有 API 就先批次＋Webhook，穩了再 API 化Integration: batch + webhook first where legacy systems lack APIs, then API
採用：LINE 原生提醒、模板化任務卡、現場帶教Adoption: native LINE reminders, templated task cards, on-site coaching
營運：雙環境、可回退、SLA 跟重大事件通報Operations: dual environments, rollback, SLA and incident reporting

金額跟補助細節不公開。Budget and subsidy details withheld.

壽險理賠的醫療文件：OCR 只是第一步，審核靠規則跟人Medical documents in life-insurance claims: OCR is step one; the review is rules plus people

一家人壽保險公司（MLI）的理賠案件，三種文件：診斷證明書、醫療費用收據、病歷摘要。每家醫院的版面都不一樣，還有手寫跟印章。系統先辨識、再抽欄位、再對保單條款跑規則，最後由理賠人員覆核。地端部署，辨識準確度約 93%，已成交。Claims at a life insurer (MLI), three document types: diagnosis certificates, medical receipts, discharge summaries. Every hospital has its own layout, plus handwriting and stamps. The system recognises, extracts fields, runs rules against the policy, and a claims officer reviews. Deployed on site, recognition accuracy about 93%, signed.

93%辨識準確度recognition accuracy

3類文件：診斷證明、收據、病摘document types: certificate, receipt, summary

15天法定給付期限（保險法 §34），時效就是商業理由-day statutory settlement window (Insurance Act §34), the business case

虛線框裡的都在地端。黃色跟紅色的案件一定會到人手上。Everything inside the dashed box stays on site. Yellow and red cases always reach a person.

醫療文件跟一般文件哪裡不一樣Why medical documents are not ordinary documents

版面不統一。每家醫院的診斷證明跟收據格式都不同，模板式 OCR 撐不住，所以用多模態模型加版面分析。No standard layout. Each hospital's certificate and receipt look different; template OCR breaks, so a multimodal model with layout analysis.
手寫跟印章。醫師簽章常蓋在字上，要先分離再辨識；辨識不到的欄位標記給人看，不猜。Handwriting and stamps. Doctors' seals land on the text; separate first, then read. Unreadable fields are flagged for a person, never guessed.
醫療名詞。診斷要對到 ICD-10，收據項目要對到給付項目，同一件事有好幾種寫法，靠對照表加相似案例檢索。Medical vocabulary. Diagnoses map to ICD-10, receipt items to benefit items, and one thing has many spellings; lookup tables plus similar-case retrieval.
特種個資。病歷、醫療、健康檢查是個資法第 6 條的特種資料，所以模型跟資料都留在地端，誰看過哪一份都有紀錄。Special-category data. Medical records fall under Article 6 of Taiwan's PDPA, so model and data stay on site and every access is logged.

規則引擎看什麼What the rules engine checks

等待期、除外責任Waiting period, exclusions
住院天數 × 日額上限Hospital days × daily-benefit cap
收據加總是否等於申請金額Receipt total equals the claimed amount
同一事故重複申請、跨院重複Duplicate claims for one event, across hospitals
診斷碼跟申請的給付項目對不對得上Diagnosis code matches the benefit claimed

綠色直接進簽核、黃色附理由給理賠人員、紅色退回補件。Green goes straight to approval, yellow goes to the officer with reasons, red goes back for documents.

準確度怎麼維持How accuracy is kept

三個檢核點分開量：文字辨識、檢索、分類Three checkpoints measured separately: recognition, retrieval, classification
Golden set 每期自動跑，掉到門檻以下就通知 ITA golden set runs every period; below threshold, IT is notified
人工修正回存，常見寫法跟錯字越收越多Corrections are stored back; common phrasings and typos accumulate

圖是照原提案的架構重畫的；客戶內部數字不公開。Diagram redrawn from the original proposal; internal numbers withheld.

研究所：基因轉殖，加上醫學影像的機器學習Grad school: gene editing, plus machine learning for medical imaging

2017 到 2019 年在台大醫工，跟創業同時進行。主修組織工程跟基因轉殖（用 CRISPR/Cas9 做基因 knock-in、knock-out），轉殖之後用醫學影像的機器學習，在雙光子顯微鏡下追蹤活體細胞；另一條線是 X 光影像的癌細胞分析。都用 MATLAB 做傳統機器學習。這是我第一次把「資料品質決定模型」這件事放進腦袋裡。2017 to 2019 at NTU Biomedical Engineering, in parallel with the startup. Tissue engineering and gene editing (CRISPR/Cas9 knock-in and knock-out); after editing, machine learning on medical images to track living cells in vivo under a two-photon microscope. A second line was cancer-cell analysis on X-ray images. Both classical machine learning in MATLAB. It was the first time "data quality decides the model" got into my head.

X 光X-ray癌細胞影像分析cancer-cell image analysis

雙光子Two-photon活體細胞影像追蹤in-vivo live-cell tracking

MATLAB影像處理＋傳統機器學習image processing + classical ML

上面是 X 光那條，下面是活細胞那條。X-ray on top, live cells below.

做了什麼What was done

X 光：影像正規化、圈出感興趣區域、抽紋理跟形態特徵、訓練分類器，再看哪些特徵真的有用。X-ray: normalise, mark regions of interest, extract texture and shape features, train a classifier, then check which features actually matter.
活細胞：顯微縮時影像先分割出每一顆細胞，再逐幀連結成軌跡，看形態跟移動怎麼變。Live cells: segment each cell in time-lapse microscopy, link frame to frame into tracks, watch shape and movement change.

留下來的東西What stayed with me

標記比模型貴。標一張 X 光要醫師的時間，所以後來每個 AI 案子我都先問「標籤哪裡來」。手扶梯那個案子就是這樣問出來的。Labels cost more than models. Labelling one X-ray takes a doctor's time, so every AI engagement since starts with "where do the labels come from". The escalator case came out of that question.
前處理佔八成時間。模型只佔兩成，到現在還是這樣。Pre-processing is 80% of the time. The model is the other 20%, still true today.
當年的準確率跟資料量沒有留下來，這裡就不寫。The accuracy and dataset numbers from back then were not kept, so none are shown here.

HPV 疫苗的市場進入：公費打 2 價，自費市場怎麼定位 4 價跟 9 價HPV vaccine market access: with the public programme on the bivalent, where do the 4- and 9-valent fit

2019 到 2020 年，以 NTU Consulting Club 的身份幫一家跨國藥廠做 4 價跟 9 價疫苗的市場研究跟市場進入分析。當時公費剛開始幫國中女生打 2 價，自費的 9 價一劑五千多還缺貨。問題不是要不要賣，是賣給誰、在哪裡賣、怎麼講。In 2019–2020, through the NTU Consulting Club, I worked on market research and market-access analysis for a global pharma company's 4- and 9-valent vaccines. The public programme had just started giving junior-high girls the bivalent; the self-paid 9-valent cost over NT$5,000 a dose and was out of stock. The question was not whether to sell, but to whom, where, and with what message.

NT$5,5009 價一劑，2018 年 10 月調價後per 9-valent dose after the Oct 2018 price rise

3劑完整療程（15 歲以上）doses for a full course (15+)

≈9萬公費國中女生，每年junior-high girls in the public programme, per year

從族群拆到價別，再到通路跟訊息。公費那條不是我們的市場。From segment to valency, then channel and message. The public line is not our market.

當時的市場背景（公開資料）Market context at the time (public sources)

公費：2018 年 12 月起，國中女生免費接種 2 價。Public: from December 2018, junior-high girls get the bivalent free.
自費 9 價：一劑從 NT$4,800 調到 5,500，三劑約 NT$16,500；缺貨近一年，診所排候補。Self-paid 9-valent: NT$4,800 → 5,500 a dose, about NT$16,500 for three; out of stock for nearly a year, clinics kept waiting lists.
自費 4 價：一劑約 NT$3,000–3,500。Self-paid 4-valent: about NT$3,000–3,500 a dose.
需求：除了本地，還有香港跟中國來的跨境接種。Demand: local, plus cross-border patients from Hong Kong and China.

我們怎麼拆How we broke it down

族群：公費 cohort 之外的女性、男性（當時幾乎沒人講）、跨境。Segments: women outside the public cohort, men (barely discussed then), cross-border.
通路：醫學中心、婦產科跟小兒科診所、健檢中心、企業團體。Channels: medical centres, OB-GYN and paediatric clinics, health-check centres, corporate groups.
價格：4 價當入門、9 價當完整保護，差價要能用「多擋幾型」講清楚。Price: 4-valent as entry, 9-valent as full protection; the gap has to be explained in "how many more types".
訊息：給醫師的是臨床證據，給家長的是「打完就不用再想」。Message: clinical evidence for doctors, "done and settled" for parents.

藥廠名稱不公開。本頁數字來自公開報導（報導者 2018、公視 2018、今周刊 2025）。Pharma company withheld. Figures from public reporting (The Reporter 2018, PTS 2018, Business Today 2025).

手術機器人跟 RAS 代理：市場有多大，授權怎麼算Surgical robots and RAS distribution: how big is the market, and how to price the licence

2019 到 2020 年，在一家跨國醫療器材代理商的團隊裡，幫兩類產品做評估：脊椎手術機器人跟腹腔鏡手術系統。要回答兩個問題：台灣的可及市場有多大，代理的授權模式該怎麼設計。In 2019–2020, inside a global medtech distributor's team, I helped evaluate two product lines: a spine-surgery robot and a laparoscopic system. Two questions: how big is Taiwan's addressable market, and how should the distribution licence be structured.

2類器械：脊椎機器人、腹腔鏡device classes: spine robot, laparoscopy

2種估法：由上而下、由下而上sizing methods: top-down, bottom-up

3種授權模式：買斷、租賃、按台次licence models: purchase, lease, per procedure

兩條估法在「可及市場」會合，對得上才敢往下談授權。Two sizing routes meet at the addressable market; only when they agree do we move to licensing.

Market sizing 怎麼做How the sizing was done

由上而下：健保申報的脊椎跟腹腔鏡手術量 × 適合機器輔助的比例 × 合理滲透率。Top-down: NHI-reported spine and laparoscopic volumes × share suited to robot assistance × a reasonable penetration rate.
由下而上：醫學中心跟區域醫院數 × 每家可能採購的台數 × 每台一年的手術量。Bottom-up: number of medical centres and regional hospitals × units each might buy × procedures per unit per year.
兩個數字對得起來，才敢拿去談。Only when the two agree does the number go into the room.

授權模式Licence models

買斷：設備＋保固，醫院一次付清Purchase: equipment + warranty, paid up front
租賃：月費含維護，現金流壓力小Lease: monthly fee with maintenance, lighter on cash flow
按台次：耗材＋每台手術費，量大才划算Per procedure: consumables + a fee per case, pays off at volume

醫院的現金流、健保給付、醫師的學習曲線，決定哪一種走得通。Hospital cash flow, NHI reimbursement and the surgeon learning curve decide which one works.

數字屬於客戶，當面聊。Numbers belong to the client; in person.

衛生福利部（2021）：長照雲端適法性研究，跟衛福部自己的資安轉型MOHW (2021): cloud legality for long-term care, and the ministry's own security transformation

進 Deloitte 的第一年，兩個案子。一個是研究案：長照機構導入智慧醫療、IoT、AI 的時候，受照顧者的機敏資料能不能委託雲端，法規跟資安要怎麼接。另一個是衛福部的 ISMS，我帶 5 個人、加自己 6 個人的團隊，在 ISO 27001 上疊 ISO 27799 的醫療控制。同一年還跟其他團隊一起調查一起疫苗資訊外洩事件。First year at Deloitte, two engagements. A research study: when long-term-care facilities adopt smart health, IoT and AI, can residents' sensitive data be entrusted to the cloud, and how do regulation and security connect. And the ministry's own ISMS, where I led a team of five plus myself, layering ISO 27799's health controls on ISO 27001. The same year I joined another team to investigate a vaccine-data leak.

6人的 ISMS 團隊，含我-person ISMS team, me included

1本研究成果出版published research report

2套標準：ISO 27001＋27799standards: ISO 27001 + 27799

長照雲端適法性研究The long-term-care cloud study

問題：長照機構想用雲端跟 AI，但受照顧者的健康資料是特種個資，機構又多半沒有資訊人員。Problem: facilities want cloud and AI, but residents' health data is special-category data and most facilities have no IT staff.
做法：盤點長照服務法、個資法、資安法跟衛福部的委外規範，對照 IoT、AI、雲端三種情境，畫出哪些可以委託、哪些要留在機構、委託要簽什麼。Method: map the Long-term Care Services Act, PDPA, Cyber Security Management Act and MOHW outsourcing rules against IoT, AI and cloud scenarios; mark what can be outsourced, what stays in-house, and what the contract must say.
產出：研究報告出版，衛福部委託辦理。Output: a published research report commissioned by MOHW.
我的角色：參與撰寫台灣第一部數位長照服務法（2021），負責醫療的部分。這是衛福部委託的委外研究《長照服務雲端系統探討評估及資訊安全框架分析》，全文約 80 萬字。My part: co-authored Taiwan's first Digital Long-Term Care Services Act (2021), responsible for the healthcare sections. It came out of MOHW-commissioned research, a study on long-term-care cloud systems and their information-security framework of about 800,000 characters.

智慧健康照護科技計畫：長照機構運用雲端資訊服務適法性研究 ↗Smart Health Care Technology Programme: legality of cloud services in long-term-care facilities ↗

ISO 27799 疊在 27001 上ISO 27799 layered on 27001

27001 是通用的資訊安全管理；27799 是醫療版的補充：病歷存取、去識別化、醫療器材接網路、緊急時的例外存取。27001 is generic information security; 27799 adds the health layer: record access, de-identification, networked medical devices, emergency break-glass access.
不是另外導入一套，是在 27001 的控制上加醫療專屬的要求，證據也共用。Not a second system: health-specific requirements on top of the 27001 controls, sharing the evidence.
政府案的八個步驟在下面；留下來的習慣是，承諾寫得越具體，驗收的時候就越不會吵。The eight steps of a government tender are below; the habit I kept is that the more specific the promise, the quieter the acceptance.

政府標案的八步Eight steps of a government tender

健保署的全台醫院資訊系統巡檢（2021–2024）：HIS、PACS、健保雲端NHIA's nationwide hospital IT reviews (2021–2024): HIS, PACS and the NHI cloud

健保署每年巡檢 30 家醫院的資訊系統。我是計畫主持人底下主要稽核團隊的成員，四年裡每年負責 10 到 12 家。看的是醫院的掛號醫令病歷系統（HIS）、影像系統（PACS），跟連到健保署的健保雲端（NHI MediCloud）之間，資料怎麼流、誰看得到、留了什麼紀錄。The NHIA reviews 30 hospitals' information systems every year. I was a core member of the audit team under the programme lead, responsible for 10 to 12 hospitals a year over four years. The review follows how data moves between the hospital information system (HIS), the imaging system (PACS) and the NHI MediCloud: who can see it, and what gets logged.

30家醫院，每年計畫範圍hospitals in scope each year

10–12家，每年我負責hospitals a year, mine

4年，2021–2024years, 2021–2024

虛線框是醫院端；右邊是健保署看得到的紀錄。Dashed box is the hospital side; the right end is what the NHIA can see.

巡檢看什麼What gets reviewed

健保 VPN 跟憑證：連線只能從指定設備、指定人出去NHI VPN and certificates: connections only from named devices and named people
健保雲端查詢：查了誰的資料、誰查的、有沒有超出就醫目的MediCloud queries: whose record, by whom, within the purpose of care
HIS／PACS 權限：離職帳號、共用帳號、醫師代理登入HIS / PACS access: leavers' accounts, shared accounts, proxy log-ins
備份跟演練：病歷跟影像的備份有沒有真的還原過Backup and drills: have record and image backups actually been restored
個資盤點：去識別化之後才能給研究用Data inventory: de-identified before any research use

跟一般資安稽核不一樣的地方How it differs from an ordinary security audit

醫院不能停。巡檢排在門診空檔，系統演練只能在夜間。Hospitals don't stop. Reviews fit around clinic hours; system drills happen at night.
例外是常態。急診的 break-glass 存取不能擋，但要事後審。Exceptions are normal. Emergency break-glass access cannot be blocked, but it must be reviewed afterwards.
每家醫院的廠商都不同。HIS 有十幾種，所以檢核表寫的是「要達到什麼」，不是「要用哪個設定」。Every hospital runs a different vendor. A dozen HIS products, so the checklist says what to achieve, not which setting to use.

醫院名單不公開。Hospital list withheld.

2021–2022：我主導的 30 多個 ISMS／PIMS 案子，台灣主要銀行2021–2022: thirty-plus ISMS / PIMS engagements I led across Taiwan's major banks

這兩年做的是基本功：ISO 27001 跟 27701 的導入、內稽、年度複查，客戶是台灣主要的銀行。不多寫，因為做法都一樣：界定範圍、風險評鑑、控制對照、證據、驗證。後面每一個案子的紀律都是這裡練出來的。Two years of fundamentals: ISO 27001 and 27701 implementations, internal audits and annual reviews for Taiwan's major banks. Not much to add, because the method is always the same: scope, risk assessment, control mapping, evidence, verification. The discipline in every later engagement was built here.

30+個我主導的 ISMS／PIMS 案子（不含協助的）ISMS / PIMS engagements I led (supporting roles not counted)

2套標準：ISO 27001、27701standards: ISO 27001, 27701

2年，2021–2022years, 2021–2022

範圍先界定，核心、間接、周邊分開，不然稽核永遠做不完。Scope first, core / indirect / peripheral, or the audit never ends.
證據要能讓第三方看懂，不是我們自己懂就好。Evidence has to make sense to a third party, not just to us.
發現事項要有 owner 跟到期日，不然下一年還是同一條。Every finding needs an owner and a due date, or it returns next year.

證券商的 ISO 27001:2022 改版轉換：五家ISO 27001:2022 transition for securities firms: five of them

2022 版把附錄 A 的控制從 114 條整併成 93 條，加了 11 條新控制：威脅情資、雲端服務的資訊安全、資料遮罩、資料外洩防護、監控活動、組態管理這些。五家台灣主要證券商的轉換我都有參與，做法是先做新舊對照表，再補新控制的證據。The 2022 edition consolidates Annex A from 114 controls to 93 and adds 11 new ones: threat intelligence, cloud-service security, data masking, data-leakage prevention, monitoring, configuration management and so on. I worked on the transition at five of Taiwan's major securities firms: old-to-new mapping first, then evidence for the new controls.

5家證券商securities firms

93條控制（原本 114 條）controls (down from 114)

11條新控制要補證據new controls needing evidence

客戶名稱不公開。Firm names withheld.

從一個案子做到 US$4M：台灣金融業第一個 Zero Trust 計畫From one project to US$4M: Taiwan's first Zero Trust programme in financial services

原本只是一個諮詢案，後來變成五大銀行的多年合約：US$4M 已經簽了，路線圖排到 2028。One advisory project became multi-year accounts with the five largest banks. US$4M signed, roadmaps through 2028.

先跟客戶把可以驗證的成果講定，再跟主管機關一起寫指引，讓它變成整個產業的 baseline。評估、建置到維運，全部包在一起做。I locked a verifiable outcome with the client, then co-wrote the guidelines with the regulator so they became the whole sector's baseline. Assessment, build and maintenance in one bundle.

海外合規巡檢（2022–2024）：四個國家，一套評分Overseas compliance reviews (2022–2024): four countries, one rubric

台灣的銀行開在海外的分行，歸當地主管機關管。我帶 6 個人的跨境團隊，把同一套控制分類跟評分套在總行跟每一家分行上，結果才比得出來。A Taiwanese bank's overseas branch answers to the local regulator. With a cross-border team of six, I ran one control taxonomy and one scoring rubric across head office and every branch, so the results could be compared.

地區Where	適用法規Against which rules	審查重點What was reviewed	規模Scale
美國United States 舊金山、聖荷西、洛杉磯、芝加哥San Francisco, San Jose, LA, Chicago	NYDFS Part 500 · FFIEC CAT	AML/KYC 系統稽核、交易監控、IT 一般控制AML/KYC system audits, transaction monitoring, IT general controls	10+ 次審查，兆豐四個分行10+ reviews, Mega Bank's four branches
泰國Thailand 曼谷Bangkok	當地主管機關 · 台灣金管會Local regulator · Taiwan FSC	併購後全行合規審查：KYC、交易監控、兩套 SOP 跟系統設定的對照Post-acquisition bank-wide compliance review: KYC, transaction monitoring, two SOP sets against system configuration	中信 × LH Bank，泰國第五大銀行CTBC × LH Bank, Thailand's fifth-largest
新加坡Singapore	MAS TRM	科技風險治理框架、法遵準備度審查Technology risk governance frameworks, regulatory readiness reviews	台灣大型金融機構的新加坡分行Singapore branches of large Taiwanese financial institutions
香港Hong Kong	HKMA · SFC	治理框架、成熟度評估、HKMA 專案Governance frameworks, maturity assessments, an HKMA-driven project	台灣大型金融機構的香港分行Hong Kong branches of large Taiwanese financial institutions

每次巡檢都走這八步Eight steps, every review

法規對照表：當地法規 × 總行政策，先列出哪些條款分行要另外做Regulation map: local rules × head-office policy, listing what the branch must do on top
界定範圍：哪些系統要納入，分核心／間接／周邊Scope: which systems are in, core / indirect / peripheral
流程 walkthrough：開戶、名單篩檢、警示、申報，看分行實際怎麼做Process walkthrough: onboarding, screening, alerts, reporting, as the branch actually does it
三方比對：實際做法 vs SOP vs 系統設定Three-way check: practice vs SOP vs system configuration
抽樣測試：交易監控的警示跟結案紀錄Sampling: transaction-monitoring alerts and case closures
評分：同一套 rubric，總行跟每個分行放在同一張表Scoring: one rubric, head office and every branch on one sheet
發現事項分級，每一條有 owner 跟到期日Findings tiered, each with an owner and a due date
結案追蹤：下一次巡檢先看上次的有沒有關掉Closure tracking: the next review opens with last time's findings

留下來的東西What I kept from it

同一套評分，每個地方都通用。成熟度那章的 CAT 爬坡圖，就是從這裡來的。One rubric everywhere. The CAT mountain in the maturity chapter came from here.
法規對照表我都當成起點來做。後來寫 KPI card 的時候，第一欄永遠是「對什麼標準」。The regulation map is the starting point, not an appendix. On every KPI card since, "against which standard" is the first column.
發現事項要有 owner 跟到期日，不然下一次來還是同一條。這就是 dashboard 那章「每一條都有人負責」的由來。A finding needs an owner and a due date or it comes back next time. That is where the dashboard chapter's "every line has an owner" comes from.

細節跟數字當面聊。Details and numbers in person.

AI 使用手冊生成系統AI user-manual generation system

這是 iKala 2024 年的一份提案：拿 50 份既有手冊建知識庫，新手冊的初稿一鍵生出來。我從這個案子學到四件事：驗收指標要先寫好、gate 要能停損、資料條件要寫進範圍、方案要分級。An iKala proposal from 2024: build a knowledge base from 50 manuals, generate a first draft in one click. I took four things from it: metrics before build, gates with a stop, data readiness in scope, and an options ladder.

三種導入策略，我們選了 ShaperThree adoption strategies; Shaper was chosen

TTaker直接拿市面上的 GenAI 方案接進既有的工作流程，不做客製。Consume off-the-shelf GenAI via API inside existing workflows; no customisation.

SShaper針對場景把既有模型做部分客製或微調，再整合進工作流程。這個案子是自架開源模型（self-host），需要的時候才微調，打包成 Docker 容器交給客戶，部署在 Azure 上。Partly customise or fine-tune an existing model for the scenario and integrate it. Here: self-hosted open-source model, fine-tuned only if needed, delivered as a Docker container on Azure.

MMaker從頭訓練全新的模型。成本跟人才門檻都最高。Train a new model from scratch. Highest cost and talent bar.

選 Shaper 的理由跟方法論那章講的一樣：每多花一筆錢，都要換得到講得出來的東西。Same reason as the method chapter: the extra money has to buy something you can say out loud.

範圍怎麼收斂How the scope was bounded

試點範圍Pilot target	工業電腦這條產品線，50 份使用手冊（含系列）；成效確認了，才會擴到其他產品線Industrial-computer line, 50 user manuals (incl. series); other lines only after results
資料就緒條件Data readiness	請客戶給 Word 原檔，不收 PDF 掃描檔，這樣 OCR 的誤差才不會跑進訓練集Client supplies Word source files, not scanned PDFs, so OCR error never enters the training set
模型跟所有權Model & ownership	用開源模型；要不要 fine-tune，看初步產出跟需求貼不貼近；最後包成 container 交給客戶Open-source model; fine-tune only if first outputs miss the need; delivered as a container
部署Deployment	Microsoft Azure；用 Azure AD 做登入跟權限Microsoft Azure; Azure AD sign-in and permissions
產出形式Output	一鍵就產出整份初版手冊，使用者還是可以自己編修One-click first draft of the whole manual; the user keeps editorial control

虛線左邊是 AI 模型，右邊是軟體工程。這條線其實就是合約上的分工界線。Left of the dashed line is the AI model, right is the software. That line is who owns what in the contract.

資料怎麼走How data moves

使用者在 UI 上建立新手冊：先定義範圍、章節、規格，再上傳參考文件User creates a manual in the UI: scope, chapters, specs; uploads reference files
Backend 把上傳的文件跟勾選的需求組成 prompt，再送給 AI SystemBackend composes the prompt from uploads and selections and sends it to the AI system
AI System 到 Vector DB 比對，再依關聯性把索引值傳回來The AI system matches against the vector DB and returns relevance-ranked indexes
Backend 靠索引去 Relational DB 把文件段落撈出來；完整的文件跟歷史手冊就放在 Cloud StorageBackend pulls passages from the relational DB by index; full files and past manuals live in cloud storage

這張圖為什麼重要Why this diagram matters

索引會回到 Relational DB 取原文，所以生成的每一段內容都追得到來源，audit trail 的雛形就在這裡。Indexes go back to the relational DB for the original text, so every generated passage traces to a source: the seed of an audit trail.
最前面先過 Azure AD，權限決定你看得到哪些手冊，所以知識來源的治理從登入那一步就開始了。Azure AD sits in front; permissions decide which manuals are visible. Knowledge-source governance starts at sign-in.
模型包成 container 交給客戶，部署在客戶自己的環境，不用綁特定 API 供應商。The model ships as a container; the client owns the deployment and is not tied to an API vendor.

上面這條是文件進來的路，下面這條是問題進來的路。Top row: how documents come in. Bottom row: how a question comes in.

Pre-processing 做什麼What pre-processing does

照目錄（TOC）來切文件，每一章就是一個可以檢索的單位Split by table of contents; one retrievable unit per chapter
建 metadata：規格（Spec）、元件（Components）、產品線Build metadata: specs, components, product line
先跑 Parser、OCR、版面分析、表格結構辨識，再做 embedding 存進 Vector DBParser, OCR, layout analysis, table-structure recognition, then embed into the vector DB

Retrieval 跟生成Retrieval and generation

Query analysis：先斷詞、去掉停用詞，再判斷結構跟意圖Query analysis: tokenise, drop stop-words, read structure and intent
Task dispatch 把任務分給對應的 executor；Multi-way recall 同時從好幾個模型跟來源撈結果；Re-rank 再依關聯性排序Task dispatch routes to the right executor; multi-way recall pulls from several models and sources; re-rank orders by relevance
LLM 把撈回來的 chunk 整理成人看得懂的草稿，盡量保留原本的格式；每一段都附上排名前三的替代版本The LLM turns recalled chunks into a readable draft in the original format, with the top three alternatives per passage

先寫 User Story，再改寫成 Prompt Story，也就是把「產品經理要什麼」翻成「模型要做什麼」。User story first, then a prompt story. That's the translation from what the PM wants to what the model does.

驗收指標在建置前就寫好Acceptance metrics written before the build

	第一階段 · 8/2Stage 1 · Aug 2	第二階段 · 10/11Stage 2 · Oct 11
F1-score	≥ 0.5	0.6 – 0.7
MRR	—	≥ 0.3
資料Data	50 份拿來訓練；每條產品線另外留 3 份做離線驗證；用各產品線的平均來判定50 for training; 3 more per product line held out for offline validation; judged on per-line averages
評估方式Method	用離線評估（短時間內可以多跑幾次），不做 A/B 測試跟滿意度調查（時間長，又有主觀偏誤）Offline evaluation (fast iteration), not A/B or satisfaction surveys (slow, subjective)
停損Stop rule	第一階段沒過，就可以決定要不要繼續這個專案If Stage 1 fails, the client may decide whether to continue

階段跟交付物Phases and deliverables

0	啟動：做 AI VOC 驗證、畫架構草圖、SOW 定稿、開 kickoff 會議Kickoff: AI voice-of-customer validation, architecture draft, SOW final, kickoff
1	系統設計：需求訪談、wireframe、UI、軟體架構、DB schema、API spec、資料清洗、基礎模型的整合驗證；另外先 demo 一章的內容生成Design: interviews, wireframes, UI, software architecture, DB schema, API spec, data cleaning, base-model integration check; one-chapter generation demo
2	開發測試：模型調整跟 prompt 測試、AI 架構建置、模型封裝、API 整合、SIT 報告Build & test: model tuning and prompt tests, AI architecture build, model packaging, API integration, SIT report
3	驗收結案：Azure 環境、UAT、正式上線、文件交齊、驗收單簽好Acceptance: Azure environment, UAT, go-live, document handover, signed acceptance

四個方案，越左邊的越完整Four scope options, fuller to the left

方案一：完整系統1 Full systemUI + 模型 + 串接 + 環境；管理層可以實際評估成效UI + model + integration + environment; management can measure real effect

方案二：精簡軟體工程2 Reduced SW拿掉登入跟封面頁；標準章節預設是英文Drop sign-in and cover pages; standard chapters default to English

方案三：模型 + API3 Model + API前端客戶自己做；模型跟 API 是完整的Client builds the front end; model and API complete

方案四：模型 PoC4 Model PoC只驗核心章節；沒有 API；成效要客戶自己推估Core chapters only; no API; client estimates the effect itself

客戶有疑慮的話，就先做簡化版，之後再分階段追加。用 change order 一階一階往上加。If in doubt, start simple and add contracts stage by stage. Climb by change order.

提案裡的做法In the proposal	對應到我的方法In my method
F1 跟 MRR 的門檻在建置前就寫進驗收標準，也押好了日期F1 and MRR thresholds written into acceptance before build, with dates	Define the number upfront；KPI card 的 metric、target、deadlineDefine the number upfront; the KPI card's metric, target, deadline
第一階段沒過的話，客戶可以決定不要再繼續If Stage 1 fails the client may stop	Gate 是停損點，沒過就停，不是之後再補的檢查；敢把停損寫出來，客戶才會信你。A gate is a stop, not a deferral; trust starts with daring to write the stop
只收 Word 檔，不收 PDF 掃描檔Word only, no scanned PDFs	資料要準備到什麼程度，寫進 client obligations；專案實績那章四個桶子裡的內容問題，在這一步就先擋掉Data readiness as a client obligation; the content bucket from the track-record chapter is blocked here
照 TOC 切塊、建 Spec / Components 的 metadata、索引要能回到原文Split by TOC, build spec/component metadata, index back to source	Nexus 知識層怎麼切塊，還有六個 metadata 欄位；來源都追得回去Nexus knowledge-layer chunking and six metadata fields; source traceability
User Story → Prompt StoryUser story → prompt story	Spec & build literacy：要能把業務需求翻成模型要做的 Input / Process / Output，才有辦法判斷工程師的計畫合不合理Spec & build literacy: translating business need into input / process / output is what lets me verify an engineer's plan
四個方案像階梯，先做簡單的，再分階段追加Four-option ladder; start simple, extend by stage	Find the smarter path，也就是成熟度那章講的「只承諾下一階」Find the smarter path; the maturity chapter's "commit to the next rung only"
先做 50 份、一條產品線，確認成效之後再擴大50 manuals, one product line, scale only after results	照 Validate → Launch → Scale 的順序走；Scale 是過了 gate 之後的事Validate → Launch → Scale; scale comes after the gate

來源：iKala AI Lab 提案 v1.0，2024 年 6 月。圖是我重畫的；金額跟客戶名稱不公開。Source: iKala AI Lab proposal v1.0, June 2024. Diagrams redrawn by me; pricing and client withheld.

我跟客戶說：你們不需要 AIThe time I said no to "use AI"

答案如果是日期、數量或門檻，就交給 workflow；真的需要判斷的地方才用 AI。另一個「問對問題比換模型有用」的故事，在振動 ML 那張卡。If the answer is a date, a count or a threshold, it is workflow; AI is for judgement calls. The other "better question beats better model" story is on the vibration-ML card.

軍品倉儲Defence warehousing

國防客戶想要一套 AI 倉儲系統來管彈藥跟軍品。需求書上真的就寫著「AI 驅動」。A defence client wanted an AI warehouse system for ammunition and supplies. The brief literally said "AI-driven".

前兩次開會都只在談流程：效期就是日期，安全庫存就是門檻，補貨就是規則，沒有一件事需要預測。所以我直接跟他們說，你們其實不需要 AI。最後我們做的是資料模型、規則引擎，加上一個資安做足的 dashboard，全部 on-prem。The first two sessions were all about the process. Expiry is a date. Safety stock is a threshold. Reorder is a rule. Nothing needed predicting. So I told them: you don't need AI. We built a data model, a rules engine and a secure dashboard, all on-prem.

時間跟成本都只花了一小部分，客戶就拿到一套能用、也能稽核的系統。我的原則是：答案如果是日期、數量或門檻，就交給 workflow；真的需要判斷的地方才用 AI。A working, auditable system in a fraction of the time and cost. My rule since: if the answer is a date, a count or a threshold, it's workflow. AI is for when the answer is a judgement.

完整版Full story

我先留了一個空間：等累積一年乾淨的資料，再來談需求預測。角色權限跟日誌從第一天就做進去，因為在封閉網路裡，audit trail 比模型還重要。I left one door open: once the data had been clean for a year, we could talk about forecasting. Role-based access and logging went in from day one, because inside a closed network the audit trail matters more than any model.

Nexus one-boxNexus one-box

就是一台機器，裡面裝好 GPU、私有 LLM、RAG 跟 agent，給不能上公有雲的客戶用。Leadtek 出硬體，iKala 負責模型跟整個導入；夥伴有 NVIDIA、Google、Qualcomm、Wistron。能上雲的客戶就走混合架構。從啟動到出貨花了六個月。One box: GPUs, a private LLM, RAG and agents, for clients who can't use public cloud. Leadtek brought the hardware, iKala owned the model and delivery; NVIDIA, Google, Qualcomm and Wistron in the partner circle. Clients who could use cloud got a hybrid design. Shipped in six months.

One-box單機、少量 GPU，適合單一部門的知識問答跟 agent。第一張單是一家健檢中心，大約 US$100K。Single unit, few GPUs. One department's Q&A and agents. First deal: a health-screening provider, ~US$100K.

Rack-mounted multi-GPU依模型大小跟同時使用人數加 GPU。第二張單是一家資安服務商，AI 伺服器 + WAF + 軟體 bundle，大約 US$600K。GPUs added for model size and concurrent users. Second deal: a security services firm, AI server + WAF + software bundle, ~US$600K.

Cabinet好幾台伺服器，要配合客戶機房的空間跟電力。報價的算法是：模型大小 × 預期併發量 × 機房條件，再回推價格。Several servers, matched to the client's data-centre space and power. Rule: model size × expected concurrency × room conditions, then back into price.

工程師管 pipeline 跟檢索。我管的是放進去的內容，還有答案到底對不對。The engineer owns the pipeline and retrieval. I own what goes in, and whether the answers are right.

AI 答錯的時候，先看它是落在哪個桶子；每個桶子的 owner 跟修法都不一樣。AI got it wrong? First question: which bucket. Each one has a different owner and a different fix.

content~70%
來源沒寫到或寫錯 → 我來補內容、改 metadataSource missing or wrong → I fix content and metadata

retrieval
有寫到但沒抓到 → FDE 去調 chunking、索引、參數Written but not found → FDE tunes chunking, index, parameters

prompt
有抓到但答錯方向 → 一起把 prompt 改掉Found but misdirected → we fix the prompt together

model
前面三個都沒問題，答案還是錯 → 那就換模型或加規則，這種情況最少見。All three right and still wrong → swap model or add rules. Rarest.

比例是經驗值，示意用的。Split is an experience-based illustration.

我的經驗怎麼對應到這個角色，還有前 60 天會怎麼做The mapping,
and the first 60 days

左邊是我做過的事，右邊是這種角色要的能力。點右邊任何一項，會看到它對應到左邊的哪些經驗。Left: what I've done. Right: what the role needs. Tap the right side to see the lines.

這一路是怎麼學來的Where it was learned, in order

從左到右照時間排：先是在台大做醫學影像的機器學習，接著是 Deloitte 的資安跟 Zero Trust，然後是 iKala 的企業 AI，2025 到 2026 年在 INSEAD，中間也去芝加哥 Kellogg 交換。Left to right, in time order: machine learning for medical imaging at NTU, then cyber and Zero Trust at Deloitte, then enterprise AI at iKala, and only in 2025–26 INSEAD and the Kellogg exchange in Chicago.

經驗對到角色Experience to role

Deloitte →

iKala →

新職務的前 60 天（我的做法）First 60 days in a new AI mandate (my approach)

第 1–15 天 · 診斷Days 1–15 · Diagnose對齊要的商業成果，了解營運現況，盤點資料、技術跟風險限制，畫出關係人，把 baseline 量出來。金融業先看監理要求跟資料分級；醫療業先看病人資料跟臨床流程。Align on business outcomes, learn the operating context, assess data, technology and risk constraints, map stakeholders and set baseline metrics. In financial services, regulatory requirements and data classification come first; in healthcare, patient data and clinical workflow.

第 16–30 天 · 排序與設計Days 16–30 · Prioritise and design選出價值最高的場景，定目標營運模式跟效益試算，講清楚治理跟交付誰負責，講定成功怎麼量（每個場景一張 KPI 卡）。Select high-value use cases, define the target operating model and business cases, settle governance and delivery ownership, and agree success measures (one KPI card per use case).

第 31–60 天 · 動起來、證明價值、滾動調整Days 31–60 · Mobilise, prove, adjust on a rolling basis啟動一個排好優先順序的項目或受控試點，開始每週追採用跟價值；照實際的數字滾動調整範圍、資源跟優先順序，解掉關鍵相依，講定擴大的路線圖。Launch a prioritised initiative or controlled pilot and track adoption and value weekly; adjust scope, resources and priorities on a rolling basis as the numbers come in, resolve critical dependencies and agree the scale-up roadmap.

這是我會怎麼做，不是某一份工作的實際紀錄。This is how I would approach it, not a record of a past job.

全部 16 個案子All 16 engagements

可以照產業、能力支柱、案子類型篩選。點任何一張卡，會看到那個案子的圖、數字跟做法。Filter by industry, capability pillar and engagement type. Open any card for its diagram, numbers and approach.

← 回到三個精選案例← Back to the three selected cases

產業Industry 能力支柱Pillar 類型Type

2021–2024 在 Deloitte 經手的客戶（展開）Clients I worked with at Deloitte, 2021–2024 (expand)

70+ 個案子、400+ 次稽核、30+ 個 ISO 導入。下面列的是可以具名的；不方便具名的，見面再聊。70+ engagements, 400+ audits, 30+ ISO implementations. These are the ones I can name; the rest in person.

主管機關與公協會Regulators & associations 金管會 FSCFSC TaiwanZero Trust 指引 2024、數位身分驗證指引 2023 共同主筆 · AI 治理要求草案Co-lead author, Zero Trust Guidelines 2024 and Digital Identity Verification Guidelines 2023 · draft AI governance requirements 保險業（壽險）Insurance industry (life)協助業界起草數位身分驗證自律規範Helped the industry draft its digital-identity self-regulatory rules 期交所 TAIFEXTaiwan Futures Exchange

銀行與保險Banks & insurers 中國信託 CTBCCTBC BankLH Bank 併購後全行合規審查（泰國）Post-acquisition bank-wide compliance review, LH Bank (Thailand) 兆豐銀行 MegaMega Bank美國四家分行的 AML/KYC 與 IT 控制審查（NYDFS Part 500）AML/KYC and IT control reviews, four US branches, NYDFS Part 500 台灣五大金融機構Taiwan's five largest FIs20+ 套治理框架、成熟度評估、法遵整備；Zero Trust 多年合約到 202820+ governance frameworks, maturity assessments, readiness reviews; Zero Trust accounts through 2028 台灣最大商業銀行Taiwan's largest commercial bank董事會核准的治理路線圖，有 owner、有 KPIBoard-approved governance roadmap with owners and KPIs 人壽保險公司Life insurers 其他銀行Other banks

政府、醫療與其他Government, health & others 衛生福利部 MOHWMinistry of Health and Welfare數位長照服務法（2021）共同撰寫，負責醫療部分；ISMS（ISO 27001＋27799），6 人團隊Co-authored the Digital Long-Term Care Services Act (2021), healthcare sections; ISMS (ISO 27001 + 27799), team of six 台大醫院 NTUHNTU Hospital全院性專案，擔任標案負責人Hospital-wide engagement, tender lead 健保署 NHIA · 食藥署 TFDANHIA · TFDA健保署全台醫院資訊系統巡檢 2021–2024，每年 10–12 家；疫苗審查系統的資安NHIA nationwide hospital IT reviews 2021–2024, 10–12 a year; vaccine-review-system security 交通部 · 台北市 · 新北市MOTC · Taipei · New Taipei公部門標案Public-sector tenders 製造業 · 區塊鏈公司Manufacturers · blockchain firmsISO 導入與資安治理；區塊鏈公司的金融法遵ISO implementations and security governance; financial compliance for blockchain firms

醫療與醫材Healthcare & medtech

醫工出身，這條線最長：研究所做醫學影像，同時創業做臨床軟體，後來在 Deloitte 做衛福部跟健保署的案子，最近是健檢中心跟壽險理賠的 AI。Bioengineering first, so this is the longest thread: medical imaging in grad school alongside a clinical-software startup, then MOHW and NHIA engagements at Deloitte, and most recently AI for a health-check group and life-insurance claims.

創業：Encorphin 安可啡 · AIQ，當醫師的第二個助理The startup: Encorphin · AIQ, the doctor's second assistant

門診拖得太晚，醫師一直重複問同樣的病史。我們訪了 100 多位醫師、跑了 40 多家診所，確認瓶頸卡在「聽跟問」之後，才開始寫第一行程式。Clinics ran late and doctors kept asking the same history questions. We interviewed over 100 doctors and visited 40-plus clinics to confirm the bottleneck was listen-and-ask, before the first line of code.

1 · 候診Waiting room病人平板問卷Patient tablet intake按科別設計的專科問卷，病人到診之前先填好。Specialty questionnaire, answered before the consult.

2 · AIQ一頁摘要One-page summary把主訴、病史、需要注意的警訊整理成一頁，醫師看得完。Chief complaint, history and risk flags on one page a doctor can read.

3 · 診間Consult醫師看診Doctor consults重複的問題少問，時間多留給判斷；摘要可以直接編輯。Fewer repeated questions, more decisions; the summary is editable.

4 · 病歷Record寫入病歷、後續追蹤Into the record醫師確認過才會寫進病歷；這些資料也會回饋到問卷設計。Enters the record only after the doctor confirms; data feeds back into the questionnaire.

4 + 2家醫院 + 診所上線hospitals + clinics live

208 → 183分鐘，胸腔科一節門診（−12%）min per chest-medicine session (−12%)

−67%病人等候時間，試點科別patient waiting time, pilot department

3人的開發團隊，由我帶；種子資金約 US$5 萬，來自 Fortune Global 500 投資人跟政府補助-person dev team I led; about US$50K seed funding from a Fortune Global 500 investor and government grants

我在這裡第一次學到：先找到瓶頸，再把工具放進去。後來每個案子我都是這樣開始。SaMD 的資料隱私跟醫療資訊安全（後來的 ISO 27799、27701），我也是從這時候開始在意的。First time I learned it: find the bottleneck, then place the tool. Every engagement since has started the same way. Caring about SaMD data privacy and health-information security (later ISO 27799, 27701) started here too.

encorphin.com ↗

簡介Profile

三個能力支柱Three capability pillars

四個可以驗證的數字Four proof points

關於我About

我在找的角色，以及新創投資What I'm looking for, and startup investing

精選案例Selected cases

能力與方法Capabilities & methods

AAI 策略與轉型AI Strategy & Transformation

B企業 AI 導入與產品化Enterprise AI Delivery & Productisation

CAI 治理、資安與風險AI Governance, Cybersecurity & Risk

我怎麼讓價值兌現How I make value show up

新職務的前 60 天（我的做法）First 60 days in a new AI mandate (my approach)

經歷My story

工作以外：Cat & Dog loverOff the clock: Cat & Dog lover

AIOM 示範AIOM demo

聯絡Contact