生醫工程出身，顧問業訓練出來的。我對結果負責。Bioengineer by background, consultant by training. Accountable for the result.
按 Enter，或點任何地方Press Enter, or click anywhere
這個網站會記錄來訪的 IP、所在地區、裝置，還有看過哪些章節，只用來知道有誰來過、看了什麼。資料保留 90 天，不會拿去反查個人，也不會交給第三方。This site logs each visit's IP, region, device and the chapters read, only to know who came and what they read. Data is kept for 90 days, never used to identify individuals and never shared.
INSEAD MBA '26Kellogg exchangeISO/IEC 42001 LAISO/IEC 27001 LACISA (exam passed)ISO/IEC 27799NVIDIA AI Infra & OpsJHU AI for Cybersecurity
從問題的兩端開始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 outcome 怎麼控制：就靠一個迴路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.
這一章只是靜態示意；完整互動版放在This chapter is a static sketch; the working version is the AIOM Outcome Cockpit ↗
試行 vs 未試行的對照已經成立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 高、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
誤報率 ≤ 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
有些 KPI 是一段爬坡The progressive KPI: climbing the ladder
有些成果像爬梯子，要爬上這一階才看得到下一階在哪。所以 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 card。量的是這一階的條件做到了多少。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
複評分數與自評差 ≤ 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 = Σ(wd × leveld) ÷ Σ wd · Gate = 下一季只承諾「下一級」，由第一次自評當 baselinecommit only to the next level per quarter, first self-assessment as baseline
我畫過的一座山：ESG 成熟度模型One I drew: an ESG maturity model
在 Deloitte 時我起草了這個四構面的模型，拿了事務所的創新首獎，後來成為台灣證交所 ESG 評鑑的基礎。下面是它的骨架，格子裡是示意用的描述；點一格看那一級要拿出什麼證據。At Deloitte I drafted this four-dimension model; it won the firm's innovation first prize and became the basis of the Taiwan Stock Exchange's ESG evaluation. 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 outcomeL4 了，但事故沒變少、停機沒變短。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
對照用：跟客戶解釋金管會指引的分級是從哪裡來的，哪些活動對銀行其實太重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 cardL1 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
100%，有獨立驗證，會向董事會跟主管機關報告100%; independently verified; reported to board and regulator
我爬過的另一座山：在 Deloitte 的時候起草的四構面 ESG 成熟度模型，拿了 Deloitte 創新首獎，後來變成台灣證交所 ESG 評鑑的基礎。Another mountain I've drawn: the four-dimension ESG maturity model I drafted at Deloitte won the firm's innovation first prize and became the basis of the Taiwan Stock Exchange's ESG evaluation.
第二個例子：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
這裡放兩張參考圖。FSC 的 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 · reference figure (Napkin)Zero Trust Maturity Journey · reference figure
同一套梯子拿來套在 AI 上。每一階都有自己的 KPI 跟 gate。The same ladder, applied to AI. Each rung has its own KPI and gate.
AI 治理：三根柱子，每根都要拿得出證據AI model governance: three things, each with evidence
要讓 AI 安全、透明地接進客戶的系統，就三件事：有人在看、留得下紀錄、風險評得出來。我用做了六年的那幾套標準，把這三件事變成客戶驗收得了的東西。Integrating AI securely and transparently stands on three pillars: oversight, audit trails, risk scoring. I turn them into things a client can accept, using the standards I've worked with for six years.
風險評分我分兩層。第一層先把 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
模型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.
從 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 閘門，另一個是 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)
把採用率當 leading 指標，看 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
先把目標設好，再看現況，收尾一定要有人簽字。上面是 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.
資料拿得到、API 開得通、使用者可以來參加訓練Data accessible, API available, users available for training
—
Change control
政府案就走公文變更；企業案就走 change orderOfficial correspondence for government; change orders for enterprise
政府、銀行，然後是企業 AIGovernment, banks, enterprise AI
政府的案子教我怎麼把文件做對，銀行教我稽核跟跨境，企業 AI 教我蹲現場跟談續約。Government taught me paperwork. Banks taught me audit and cross-border work. Enterprise AI taught me on-site builds and renewals.
創業：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人的開發團隊，我自己帶；U-Start 第一階段 NT$50 萬-person dev team I led; U-Start phase one NT$500K
這是我第一次學到：先找到瓶頸，再把工具放進去。後來每個案子都是這樣開始的。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.
第一次自己帶團隊：衛生福利部的標案（2021）First time leading a team: a Ministry of Health and Welfare tender (2021)
第一次帶 5 個人。政府案教會我一件事：交付物不等於成果，每一條都會有人查。My first team of five. Government work taught me that a deliverable isn't an outcome, and every line gets checked.
留下來的習慣：承諾寫得越具體，驗收的時候就越不會吵。The habit I kept: the more specific the promise, the quieter the acceptance.
民間企業跟跨境：併購之後的全行合規審查Private sector and cross-border: a post-acquisition bank-wide compliance review
中信買下泰國第五大銀行之後，第一次做的全行合規審查。兩套制度、兩個主管機關、兩種語言。CTBC had just bought Thailand's fifth-largest bank. First bank-wide compliance review. Two operating models, two regulators, two languages.
我把 KYC 跟交易監控從開戶到申報整條流程都對映一遍，看分行實際上怎麼做、SOP 跟系統設定有沒有對得上。I mapped KYC and transaction monitoring end to end, and checked whether what the branch did, what the SOP said and what the system was set to actually agreed.
海外案子怎麼做的細節，當面聊。The overseas details are better in person.
海外專案：美國分行的 AML/KYC 跟 IT 控制審查Overseas delivery: AML/KYC and IT control reviews for US branches
兆豐在美國的四個分行：矽谷、舊金山、洛杉磯、芝加哥。做了十次以上的 AML/KYC 跟 IT 控制審查。Mega Bank's four US branches: Silicon Valley, San Francisco, LA, Chicago. Ten-plus AML/KYC and IT control reviews.
同一套評分套在總行跟每一個分行，結果才比得出來。成熟度那章的成熟度爬坡就是從這裡來的。One scoring rubric across head office and every branch, so results actually compare. The maturity climb in the maturity chapter comes from here.
海外合規巡檢（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 矽谷、舊金山、洛杉磯、芝加哥Silicon Valley, San Francisco, 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 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
流程走查：開戶、篩查、警示、呈報，分行實際怎麼做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. The CTBC and Mega engagements are the buttons above.
官股民營：資策會（2022–2023，18 個月）Government-affiliated, privately run: III (2022–2023, 18 months)
民營的組織，但有官方的背景。用民間的速度做事，用公部門的紀律把證據留下來。Private organisation, public mandate. You work at private-sector speed but keep public-sector paperwork.
18 個月。有點像新加坡那種國家級機構，兩邊都要顧到。Eighteen months. A bit like Singapore's national bodies: you serve both sides.
從一個案子做到 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.
企業 AI：on-site 建置跟續約（iKala, Dec 2024 – Jan 2026）Enterprise AI: on-site builds and renewal (iKala, Dec 2024 – Jan 2026)
12 個月開出 US$2M+ 的 pipeline，自己親手成交了 6 家。還跟 FDE 一起進客戶現場。A US$2M+ pipeline in twelve months, six accounts closed myself. On site with the engineers.
下一章講的是怎麼做的。The next chapter shows how.
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），需要的時候才 fine-tune，用 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.
模型用容器交給客戶，部署在客戶自己手上，不綁 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 analyze：先分詞、去掉停用詞，再理解結構跟意圖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: AI voice-of-customer validation, architecture draft, SOW final, kickoff
1
系統設計包含：需求訪談、wireframe、UI、軟體架構、DB schema、API spec、資料清洗、基礎模型的整合驗證；另外做一章內容生成的 demoDesign: 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；專案實績那章四個桶子裡的 content 問題，在這裡就先堵住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.
兩次我跟客戶說：你們不需要 AITwo times I said no to "use AI"
軍品倉儲Defence warehousing
C
國防客戶想要一套 AI 倉儲系統來管彈藥跟軍品。需求書上真的就寫著「AI 驅動」。A defence client wanted an AI warehouse system for ammunition and supplies. The brief literally said "AI-driven".
A
前兩次開會只講流程。效期就是日期，安全庫存就是門檻，補貨就是規則。沒有一件事需要預測。我跟他們說：你們不需要 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.
R
只花一小部分的時間跟成本，就拿到一套能用、也能稽核的系統。我的規則是：答案如果是日期、數量或門檻，那就是 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
我留了一扇門：等資料乾淨一年之後，再來談需求預測。角色權限跟日誌從第一天就做進去，因為在封閉網路裡面，稽核軌跡比模型還重要。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.
震動感測器 → 手扶梯Vibration sensors → escalators
C
感測器客戶以為現在的 AI 可以直接預測機械手臂故障。我們收了震動資料，也收了第一筆錢，團隊就準備從 FFT 從頭做起。A sensor client believed today's AI could predict robotic-arm failures out of the box. We had the vibration data, we'd taken a first payment, and the team was about to build FFT features from scratch.
A
我問了兩件事。第一，物理 AI 平台都已經有了，為什麼還要用手工建？第二，更大的問題是：我們有很多震動資料，但幾乎沒有標好的故障。沒有故障，就沒有東西可以預測。所以我回去提了一個有標籤的案子：捷運手扶梯。I asked two things. One: physics-AI platforms already exist, why are we hand-building this? Two, the bigger one: we had lots of vibration data and almost no labelled failures. No failures, nothing to predict. So I went back with a case that had labels: metro escalators.
R
成交大約 US$150K，做出來的是一個有 baseline 的預測維修模型。機械手臂留到第二階段再做。學到一課：最聰明的路很少是更好的模型，而是把問題問對。Closed at about US$150K, delivered a predictive-maintenance model with a real baseline. The robotic arm became phase two. The lesson: the smartest path is rarely a better model. It's a better question.
完整版Full story
我提的是 NVIDIA PhysicsNeMo 這類有物理資訊的代理模型，也問過能不能用物理模型去生成合成的故障樣本。這個提議本身沒有被採用，但它把真正的問題挖出來了：標籤不夠。What I raised was physics-informed surrogate modelling, NVIDIA PhysicsNeMo and the like, including whether physics models could generate synthetic failure samples. That route wasn't taken, but asking is what exposed the real problem: no labels.
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 Taiwan零信任指引 2024 主筆 · 數位身分驗證指引 2023 共同作者 · AI 治理要求草案Lead author, Zero Trust Guidelines 2024 · co-author, Digital Identity Verification Guidelines 2023 · draft AI governance requirements保險業（壽險）Insurance industry (life)數位身分驗證自律規範，協助產業起草Helped the industry draft its digital-identity self-regulatory rules證交所 TWSETaiwan Stock Exchange四構面 ESG 成熟度模型，成為 ESG 評鑑的基礎Four-dimension ESG maturity model, basis of the ESG evaluation期交所 TAIFEXTaiwan Futures Exchange（內容待補）(details to come)
銀行與保險Banks & insurers中國信託 CTBCCTBC BankLH Bank 併購後全行合規審查（泰國）Post-acquisition bank-wide compliance review, LH Bank (Thailand)兆豐銀行 MegaMega Bank美國四分行 AML/KYC 與 IT 控制審查，NYDFS Part 500AML/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（名稱與內容待補）(names and details to come)其他銀行Other banks（名稱與內容待補）(names and details to come)
政府、醫療與其他Government, health & others衛生福利部 MOHWMinistry of Health and Welfare2021 標案，第一次帶 5 人團隊2021 tender, first team of five台大醫院 NTUHNTU Hospital全院案，標案負責人Hospital-wide engagement, tender lead健保署 NHIA · 食藥署 TFDANHIA · TFDA標案負責人；疫苗審查系統資安、長照雲端服務法遵也在這幾年Tender lead; vaccine-review-system security and long-term-care cloud compliance fall in these years交通部 · 台北市 · 新北市MOTC · Taipei · New Taipei公部門標案Public-sector tenders資策會 IIIIII官股民營，18 個月Government-affiliated, 18 months製造業 · 區塊鏈公司Manufacturers · blockchain firmsISO 導入與資安治理；區塊鏈公司的金融法遵ISO implementations and security governance; financial compliance for blockchain firms
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.
我的經驗怎麼對上這個角色，還有前 90 天The mapping, and the first 90 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 →
前 90 天First 90 days
Day 1–30接手兩個還在進行中的案子，把每個案子的 KPI card 重做一遍，找出沒有 baseline 或沒有 client owner 的，然後把 dashboard 立起來。Take over two live engagements, redo each KPI card, find the ones with no baseline or no client owner, stand up the dashboard.
Day 31–60每個案子都做一次 built vs promised 稽核，自己親手驗證至少一個技術 milestone（跑一次 pipeline、看一次 eval set）。有 drift 的，就帶著解法往上報。One built-vs-promised audit per engagement; personally verify at least one technical milestone (run the pipeline, read the eval set). Escalate drift with a fix attached.
Day 61–90每個案子都寫 evidence pack 跟下一個機會，至少要有一個真的進到提案；再把 KPI card 跟 dashboard 的模板變成整個團隊共用的。Evidence pack and next opportunity per engagement, at least one into proposal; make the KPI card and dashboard templates team-wide.
