AI Role Competency Matrix 2026+

目标: 为 AI + Architect + Product Manager + BA 的长期成长建立一张可执行的角色能力矩阵. 背景: 面向 2026+ 企业 AI 需求, 重点从 "会做 AI demo" 升级到 "能发现真问题, 设计可评估系统, 推动治理和 adoption, 讲清业务价值". 使用方式: 每月用本文做一次能力自评, 每季度用 ABPA 模板产出一组 evidence artifacts, 每半年整理成面试和作品集叙事.

---

1. 总体定位

2026+ 企业 AI 岗位正在从单点 prompt / chatbot 能力, 转向跨职能的 AI operating capability.

真正有竞争力的复合型人才, 需要同时回答六类问题:

1. Business: 这个问题是否值得用 AI, 不做或不用 AI 的机会成本是什么?
2. Product: 用户是谁, workflow 如何变化, 价值指标和 adoption 指标是什么?
3. BA: 现有流程, 决策, 数据, 规则, 异常, 干系人冲突在哪里?
4. Architecture: 应该用 RAG, workflow, agent, fine-tuning, rule engine, vendor product, or hybrid?
5. EvalOps: 需求如何变成 eval, release gate, drift monitor, incident review?
6. Governance: 如何满足风险, 合规, 审计, 人工监督, model lifecycle, vendor accountability?

本文的核心判断:

• AI BA 不是会议纪要自动化员, 而是 AI 项目的 problem evidence owner.
• AI PM 不是功能排期员, 而是 AI 产品价值, 用户行为改变, adoption 的 owner.
• AI Solutions Architect 不是画大框图的人, 而是需求到架构控制, 集成, 成本, 安全, 可观测性的 owner.
• AI Enterprise Architect 不是只管标准的人, 而是企业 AI capability, portfolio, governance, target architecture 的 owner.
• AI Product Operations / EvalOps 不是 QA 执行者, 而是 AI system quality loop 和 production evidence 的 owner.
• Field AI Engineer / Forward Deployed Engineer 不是纯交付工程师, 而是在客户现场把 ambiguous problem 变成 working AI system 的 owner.

---

2. 角色边界与重叠

2.1 主要差异

• AI BA 从 "what users ask for" 追溯到 "what decision or workflow must improve".
• AI PM 从 "feature backlog" 上升到 "behavior change, value realization, and market positioning".
• AI Solutions Architect 从 "can it call a model" 深入到 "knowledge, permission, latency, cost, fallback, audit, and resilience".
• AI Enterprise Architect 从 "one system design" 上升到 "enterprise capability portfolio and governance operating model".
• EvalOps 从 "testing after build" 前移到 "requirements as eval contracts".
• FDE 从 "implement tickets" 升级到 "discover, design, integrate, iterate, and transfer ownership in the field".

2.2 主要重叠

• AI BA 和 AI PM 重叠在 problem framing, user research, success metrics.
• AI BA 和 Solutions Architect 重叠在 requirements-to-eval, data readiness, domain modeling.
• AI PM 和 EvalOps 重叠在 product quality, launch gates, adoption metrics.
• Solutions Architect 和 Enterprise Architect 重叠在 target architecture, standards, reusable platform patterns.
• Enterprise Architect 和 Governance 重叠在 portfolio risk, policy, operating model, vendor accountability.
• FDE 和所有角色都有重叠, 但更强调现场约束, speed, integration, feedback.

2.3 组合定位

你的长期定位可以写成:

AI Business Architect / AI Product Architect: 将金融零售业务问题, 流程证据, 产品价值, AI 架构, EvalOps, 风险治理和组织 adoption 放进同一条可验证路线图.

---

3. Source Anchors and Standards References

这些标准不是岗位说明书, 而是能力矩阵的 anchor. 使用时要转成 artifact, control, eval, or interview evidence.

Standards-to-artifacts translation:

• NIST AI RMF -> AI Control Pack, risk register, eval gate, monitoring plan.
• EU AI Act -> risk classification memo, transparency checklist, human oversight design, audit evidence.
• IIBA -> stakeholder map, elicitation plan, requirements model, solution evaluation report.
• TOGAF -> capability map, target architecture, transition roadmap, architecture governance pack.
• BPMN -> current-state and future-state workflow with SLA, exception, handoff, control point.
• BIAN -> banking capability map, service domain boundary, semantic API and integration scope.
• OWASP LLM Top 10 -> threat model, prompt/tool/data controls, red team backlog.
• ISO/IEC 42001 -> AI management operating model, responsibility matrix, lifecycle review cadence.

---

4. Cross-Role Capability Matrix

Legend:

• A = Accountable, owns final quality.
• C = Contributor, provides inputs.
• R = Reviewer, sets guardrails or acceptance.
• P = Practitioner, implements or operates.

4.1 Capability output standards

---

5. L1-L5 Role Growth Levels

5.1 AI Business Analyst

L1 - AI-aware BA

• Concrete behaviors: 能描述 AI use case, 区分 automation, copilot, workflow, agent.
• Deliverables: 简单 problem statement, stakeholder list, user story draft.
• Proof artifacts: 1 个 AI Opportunity Canvas v0.1, 1 份访谈问题清单.
• Interview signals: 能说明 "为什么不一定需要 AI", 能把需求改写成可测指标.
• Common failure modes: 把业务要求直接变成 prompt; 只写功能, 不写流程和证据.

L2 - Evidence-driven AI BA

• Concrete behaviors: 主动追问 baseline, volume, error rate, SLA, rework, risk, exception.
• Deliverables: Stakeholder Evidence Map, BPMN current-state, pain metrics baseline.
• Proof artifacts: 3 个业务场景的流程图和痛点量化表.
• Interview signals: 能解释 stakeholder conflict, human-in-the-loop, no-AI boundary.
• Common failure modes: 只访谈 manager, 不访谈一线; 流程图没有异常流和控制点.

L3 - Requirements-to-Eval BA

• Concrete behaviors: 把每条需求绑定 eval data, expected behavior, threshold, owner, fallback.
• Deliverables: Requirements-to-Eval Matrix, decision model, data readiness inputs.
• Proof artifacts: 1 套 golden dataset, 20-50 条测试样本, 需求追溯表.
• Interview signals: 能说明 "需求如何验收", "模型失败时谁处理", "哪些样本最难".
• Common failure modes: 只写 acceptance criteria, 不写 eval design; 把模型准确率当唯一指标.

L4 - AI Transformation BA

• Concrete behaviors: 能跨业务, 风控, 法务, 数据, IT 推动 workflow redesign.
• Deliverables: future-state BPMN, operating model, RACI, adoption risk register.
• Proof artifacts: 端到端 case pack: problem -> workflow -> requirements -> eval -> adoption.
• Interview signals: 能讲清某个 AI 项目上线后岗位, SOP, control, escalation 如何变化.
• Common failure modes: 忽略组织阻力; 只做系统需求, 不设计工作方式变化.

L5 - AI Business Architect

• Concrete behaviors: 能用 capability, value stream, domain model 设计 AI transformation portfolio.
• Deliverables: AI capability map, decision inventory, domain service map, governance roadmap.
• Proof artifacts: 3-5 个金融零售场景组成的 portfolio, 每个都有 evidence artifact.
• Interview signals: 能从战略, 业务能力, 风险, 架构, adoption 讲一个完整 transformation story.
• Common failure modes: 叙事过大但证据不足; 只讲愿景, 不能落到 eval 和 operating model.

5.2 AI Product Manager

L1 - AI feature PM

• Concrete behaviors: 能定义用户, use case, basic PRD, prompt/prototype demo.
• Deliverables: AI Product Brief, user journey, simple success metrics.
• Proof artifacts: 一个可点击原型或 demo recording, 一页 PRD.
• Interview signals: 能说明用户任务, 输入输出, basic constraints.
• Common failure modes: 把 "加 AI" 当价值; demo 有趣但没有 adoption path.

L2 - Workflow PM

• Concrete behaviors: 从用户 job 和 workflow friction 定义产品机会, 而不是从模型能力出发.
• Deliverables: JTBD, metric tree, MVP scope, prototype test plan.
• Proof artifacts: 5 人 usability test notes, before/after workflow comparison.
• Interview signals: 能讲清用户何时信任 AI, 何时需要人工复核, 何时拒绝使用.
• Common failure modes: 只优化 UI, 不改变 workflow; 只看 usage, 不看质量和风险.

L3 - Eval-native AI PM

• Concrete behaviors: 将产品需求写成 eval-backed requirements, 定义 launch gate.
• Deliverables: PRD + Requirements-to-Eval Matrix, release criteria, adoption dashboard.
• Proof artifacts: 1 个产品的 metric tree, eval suite, release decision memo.
• Interview signals: 能平衡 precision/recall, time saved, trust, error cost, compliance risk.
• Common failure modes: 只追模型 benchmark; 不定义 bad answer 的业务损失.

L4 - AI Growth and Operations PM

• Concrete behaviors: 管理从 pilot 到 rollout 的 adoption funnel, cohort, training, feedback loop.
• Deliverables: rollout plan, SOP, training, feedback taxonomy, ROI model.
• Proof artifacts: 30/60/90 launch dashboard, user cohort analysis, business case.
• Interview signals: 能解释 why pilot succeeds but enterprise rollout fails.
• Common failure modes: pilot 后不跟踪行为改变; 忽略 manager incentives 和 process ownership.

L5 - AI Product Strategy Lead

• Concrete behaviors: 能定义 AI product portfolio, build-vs-buy, platform leverage, moat.
• Deliverables: product strategy, portfolio roadmap, vendor strategy, executive narrative.
• Proof artifacts: 3 个产品线的 prioritization model, investment memo, portfolio evidence map.
• Interview signals: 能连接市场机会, enterprise architecture, governance cost, product velocity.
• Common failure modes: 只讲愿景和路线图; 无法证明优先级和 ROI 假设.

5.3 AI Solutions Architect

L1 - AI application architect

• Concrete behaviors: 能画基本 LLM app 架构, 了解 model API, vector DB, RAG, prompt layer.
• Deliverables: high-level C4, component list, integration assumptions.
• Proof artifacts: 一个 RAG 或 copilot demo 的 architecture note.
• Interview signals: 能解释 RAG 和 fine-tuning 的基本取舍.
• Common failure modes: 架构图只有 LLM box; 忽略权限, 审计, fallback, latency.

L2 - Enterprise RAG / workflow architect

• Concrete behaviors: 能设计 ingestion, chunking, metadata, retrieval, rerank, citation, RBAC.
• Deliverables: RAG ADR, data flow, security design, observability events.
• Proof artifacts: Enterprise RAG ADR, eval sample, source citation policy.
• Interview signals: 能说明 freshness, source-of-truth, access control, grounding 失败处理.
• Common failure modes: 把 vector search 当知识治理; 没有 data lifecycle 和 content ownership.

L3 - Agentic architecture architect

• Concrete behaviors: 能设计 tool gateway, policy check, state, memory, approval, idempotency, audit.
• Deliverables: agent workflow C4, tool risk classification, control pack, cost model.
• Proof artifacts: agent ADR set, OWASP LLM threat model, eval and red team plan.
• Interview signals: 能解释 excessive agency, prompt injection, tool abuse, human approval boundary.
• Common failure modes: 过早多 agent; agent 可直接执行高风险动作; 无停止条件.

L4 - Production AI architect

• Concrete behaviors: 能管理 model gateway, prompt/versioning, telemetry, eval gate, incident response.
• Deliverables: production readiness review, SLO/SLI, runbook, governance integration.
• Proof artifacts: release gate checklist, trace design, incident review template.
• Interview signals: 能从 reliability, security, compliance, cost, data quality 讲上线条件.
• Common failure modes: 只做 PoC; 没有 rollback, audit trail, budget guardrail, vendor exit.

L5 - AI platform and transformation architect

• Concrete behaviors: 能抽象 reusable AI platform capabilities, 支持多个业务域的受控复用.
• Deliverables: reference architecture, platform capability map, standards, migration roadmap.
• Proof artifacts: AI platform blueprint, build-vs-buy matrix, multi-use-case control model.
• Interview signals: 能说明何时平台化, 何时场景定制, 如何降低 marginal delivery cost.
• Common failure modes: 平台先行但无业务拉动; 标准过重导致交付停滞.

5.4 AI Enterprise Architect

L1 - AI-aware EA

• Concrete behaviors: 能把 AI 项目放入业务能力, 应用, 数据, 技术视图.
• Deliverables: simple capability map, context diagram, architecture principles draft.
• Proof artifacts: 一个 AI use case 的 business/data/application/technology view.
• Interview signals: 能解释 AI capability 和普通 application capability 的差异.
• Common failure modes: 把 AI 当单独应用; 不关心业务能力和 operating model.

L2 - Capability and portfolio EA

• Concrete behaviors: 用 capability-based planning 对 AI use cases 分组和排优先级.
• Deliverables: AI capability heatmap, use case portfolio, dependency map.
• Proof artifacts: 10 个金融零售 AI use cases 的 scorecard 和 roadmap.
• Interview signals: 能说明 value, risk, readiness, reuse, regulatory exposure 的权衡.
• Common failure modes: 按部门需求排队; 不评估数据和治理 readiness.

L3 - Target architecture EA

• Concrete behaviors: 设计 enterprise target architecture: model gateway, knowledge, eval, governance, observability.
• Deliverables: target architecture, transition states, standards, architecture review checklist.
• Proof artifacts: TOGAF-style roadmap, architecture decision log, transition architecture.
• Interview signals: 能连接 business strategy, data architecture, security, product delivery.
• Common failure modes: 架构原则抽象; 无迁移路径和 funding logic.

L4 - AI governance EA

• Concrete behaviors: 将 NIST/EU/ISO/OWASP 映射为企业级政策, 控制, review cadence.
• Deliverables: AI governance model, risk tiering, architecture review board pack.
• Proof artifacts: risk classification matrix, control library, compliance evidence map.
• Interview signals: 能解释 high-risk AI, human oversight, transparency, model lifecycle.
• Common failure modes: 合规 checklist 化; 没有 owner, evidence, exception handling.

L5 - Enterprise AI transformation EA

• Concrete behaviors: 能设计从 local pilots 到 enterprise AI operating model 的演进.
• Deliverables: 18-month roadmap, platform operating model, investment portfolio, capability maturity model.
• Proof artifacts: multi-domain transformation deck with financial retail examples and measurable gates.
• Interview signals: 能和 CIO/CTO/CRO/COO 讨论组织能力, 技术架构, 风险和价值.
• Common failure modes: 太战略, 不可执行; 不知道一线 adoption 和 eval data 如何生产.

5.5 AI Product Operations / EvalOps

L1 - AI QA operator

• Concrete behaviors: 能执行人工测试, 记录 bad outputs, 跟踪问题.
• Deliverables: test checklist, bug report, sample failure log.
• Proof artifacts: 20 条 AI 输出测试记录和分类.
• Interview signals: 能描述 hallucination, refusal, grounding failure, unsafe answer.
• Common failure modes: 只看 pass/fail, 不建 failure taxonomy.

L2 - Eval analyst

• Concrete behaviors: 能设计 gold questions, labels, rubrics, human review protocol.
• Deliverables: golden dataset, evaluation rubric, sampling plan.
• Proof artifacts: 50-100 条样本, grader rubric, reviewer agreement notes.
• Interview signals: 能解释 exact match, semantic grading, human review, adversarial cases.
• Common failure modes: 样本太容易; 没有 hard cases, negative cases, edge cases.

L3 - Release gate owner

• Concrete behaviors: 将 eval 连接 CI/release, product metrics, monitoring, incident workflow.
• Deliverables: release gate, daily eval dashboard, regression test suite.
• Proof artifacts: evaluation report with threshold, trend, release decision.
• Interview signals: 能说明何时不发布, 何时回滚, 何时增加人工审核.
• Common failure modes: 阈值随意; release gate 与业务风险不匹配.

L4 - AI quality operations lead

• Concrete behaviors: 建立 production feedback loop: trace, sampling, drift, complaint, incident, retraining input.
• Deliverables: EvalOps runbook, telemetry schema, incident review, change control.
• Proof artifacts: 30-day production quality review, failure taxonomy trend, corrective actions.
• Interview signals: 能讲清 AI system quality 如何持续维护, 而不是上线即结束.
• Common failure modes: 只做离线 eval; 不监控 real workflow impact 和 user trust.

L5 - Enterprise EvalOps architect

• Concrete behaviors: 定义跨产品 eval platform, rubric standards, governance reporting, quality portfolio.
• Deliverables: enterprise eval framework, model/product scorecard, risk-tiered eval policy.
• Proof artifacts: 多场景 eval library, evaluator calibration protocol, executive quality dashboard.
• Interview signals: 能将 eval 变成企业 AI 管理体系的一部分.
• Common failure modes: eval 平台化过早; 忽略每个业务域的不同 error cost.

5.6 Field AI Engineer / Forward Deployed Engineer

L1 - AI implementation engineer

• Concrete behaviors: 能根据明确需求接入 model API, RAG, simple workflow.
• Deliverables: prototype, integration script, demo notes.
• Proof artifacts: 一个 end-to-end demo with README and limitations.
• Interview signals: 能解释实现边界和已知风险.
• Common failure modes: 只追 demo speed; 不记录假设和现场约束.

L2 - Discovery-to-prototype FDE

• Concrete behaviors: 在客户现场快速访谈, 抽取 workflow, 2-3 天做可试用原型.
• Deliverables: field discovery notes, prototype, pilot test plan.
• Proof artifacts: before/after workflow video or annotated screenshots, user feedback.
• Interview signals: 能讲清如何从 ambiguous requirement 找到 first wedge.
• Common failure modes: 用户说什么做什么; 没有 problem framing 和 success metric.

L3 - Integration and deployment FDE

• Concrete behaviors: 能处理 SSO, RBAC, data connector, audit log, environment, monitoring.
• Deliverables: integration adapter, deployment checklist, observability plan, handoff doc.
• Proof artifacts: pilot deployment pack with risks, rollback, access control.
• Interview signals: 能说明 enterprise environment 中最容易卡住的技术和组织问题.
• Common failure modes: 本地可跑但企业不可部署; 忽略 security review 和 data access.

L4 - Field product architect

• Concrete behaviors: 将多个客户现场反馈抽象为 reusable product / platform capability.
• Deliverables: field pattern catalog, product gap analysis, reference implementation.
• Proof artifacts: 3 个现场案例的共性需求和产品化建议.
• Interview signals: 能在 customization 和 productization 之间做取舍.
• Common failure modes: 永远定制; 不能沉淀 reusable architecture.

L5 - Strategic FDE / Forward Deployed Architect

• Concrete behaviors: 能与客户高层定义 AI transformation case, 同时带队完成 pilot 到 production.
• Deliverables: executive roadmap, joint success plan, production scale plan, value report.
• Proof artifacts: end-to-end transformation case: discovery -> architecture -> pilot -> launch -> ROI.
• Interview signals: 能跨 business, engineering, legal, security, operations 形成共同决策.
• Common failure modes: 现场英雄主义; 缺少可移交的 operating model 和 internal owner.

---

6. Financial Retail Examples

6.1 AML / KYC Investigation Copilot

• Business problem: alert backlog 高, false positive 多, case narrative 质量不稳定.
• AI BA focus: alert triage workflow, investigator pain, SAR / case narrative decision rules.
• AI PM focus: investigator time saved, first-pass quality, reviewer acceptance, adoption.
• Architect focus: evidence retrieval, case graph, policy RAG, audit trail, HITL approval.
• EvalOps focus: groundedness, citation correctness, suspicious typology coverage, unsafe recommendation.
• Governance focus: human oversight, explainability, audit evidence, model risk management.
• Proof artifacts: AML Opportunity Canvas, BPMN, Requirements-to-Eval Matrix, AI Control Pack, SAR quality eval.

6.2 Lending Underwriting Assistant

• Business problem: loan review cycle time 长, policy interpretation 不一致, manual exception 多.
• AI BA focus: underwriting decision inventory, policy exception flow, credit officer workflow.
• AI PM focus: approval cycle time, applicant experience, override rate, adverse action compliance.
• Architect focus: policy RAG, scoring system integration, decision support only, audit log.
• EvalOps focus: policy-grounded answer, missing-data detection, bias monitoring, manual review trigger.
• Governance focus: high-risk AI exposure, fair lending, explainability, appeal process.
• Proof artifacts: lending decision model, data readiness pack, human oversight memo, release gate.

6.3 Fraud Operations Copilot

• Business problem: fraud queue volatility, chargeback response time, analyst overload.
• AI BA focus: case intake, evidence gathering, escalation, exception paths.
• AI PM focus: analyst throughput, false positive handling, case closure quality.
• Architect focus: event stream, feature store, rule/model explainability, tool action limits.
• EvalOps focus: hard-negative cases, emerging typology sampling, drift and incident review.
• Governance focus: customer harm, account freeze controls, dual approval for high-impact actions.
• Proof artifacts: fraud workflow BPMN, tool risk matrix, incident playbook, eval dashboard.

6.4 Service Copilot

• Business problem: customer service AHT 高, policy answers inconsistent, escalation unclear.
• AI BA focus: intent taxonomy, knowledge source ownership, escalation criteria.
• AI PM focus: containment, customer satisfaction, agent trust, coaching loops.
• Architect focus: contact center integration, retrieval permissions, response guardrails, citation.
• EvalOps focus: answer correctness, tone, refusal, escalation, compliance phrase checks.
• Governance focus: transparent AI use, privacy, complaint handling, human fallback.
• Proof artifacts: service journey, RAG ADR, gold Q&A set, adoption dashboard.

6.5 Payments Operations

• Business problem: payment exceptions, reconciliation breaks, refund disputes, settlement delays.
• AI BA focus: exception taxonomy, reconciliation decision flow, SLA and ownership.
• AI PM focus: ops productivity, break resolution time, error reduction, merchant experience.
• Architect focus: payment gateway data, ledger constraints, idempotency, tool permissions.
• EvalOps focus: numeric consistency, source traceability, action safety, regression samples.
• Governance focus: financial loss, auditability, segregation of duties, change control.
• Proof artifacts: payment exception BPMN, domain model, ADR for read-only vs write tools.

6.6 Wealth Advisory Compliance

• Business problem: advisors need compliant research support, suitability review, disclosure consistency.
• AI BA focus: suitability constraints, advice boundary, disclosure workflow, review evidence.
• AI PM focus: advisor productivity, compliance confidence, client communication quality.
• Architect focus: policy RAG, portfolio data access, role-based guardrails, no personalized advice without controls.
• EvalOps focus: suitability red flags, hallucinated product facts, prohibited recommendation language.
• Governance focus: advisor oversight, regulatory disclosure, audit trail, model output retention.
• Proof artifacts: wealth advisory control pack, eval rubric, human approval workflow, compliance memo.

---

7. Practical Evidence Artifacts from Existing ABPA Templates

Use the existing templates under docs/abpa/templates/ instead of inventing new formats.

Recommended evidence packages:

• AI BA package: Opportunity Canvas + Stakeholder Evidence Map + BPMN + Requirements-to-Eval Matrix.
• AI PM package: Product Brief + Metric Tree + Prototype Report + Adoption Dashboard + Business Case.
• Solutions Architect package: Data Readiness Pack + Architecture ADR Set + Control Pack + C4 diagrams.
• Enterprise Architect package: Capability Map + Target Architecture + Operating Model + Roadmap + Review Pack.
• EvalOps package: Golden Dataset + Rubric + Release Gate + Failure Taxonomy + Production Quality Review.
• FDE package: Field Notes + Prototype + Integration Adapter + Pilot Report + Handoff Pack.

Portfolio conversion rule:

• Every artifact should answer: what decision does this support?
• Every artifact should show: what evidence backs it?
• Every artifact should state: what uncertainty remains?
• Every artifact should propose: what should be tested next?

---

8. 30 / 60 / 90 / 180-Day Growth Roadmap

First 30 days - foundation and role clarity

• Week 1: Read this matrix, ABPA README, source anchors, and existing AML Copilot docs.
• Week 1 output: personal role positioning memo: AI BA vs AI PM vs Architect vs EvalOps.
• Week 2: Build one AML/KYC AI Opportunity Canvas and Stakeholder Evidence Map.
• Week 2 output: 8 stakeholder groups, 10 interview questions, 5 explicit assumptions.
• Week 3: Create current-state BPMN for AML or payments operations.
• Week 3 output: BPMN with exception flow, SLA, handoff, rework, control points.
• Week 4: Convert 10 requirements into eval-ready form.
• Week 4 output: Requirements-to-Eval Matrix with gold samples, thresholds, owners, failure modes.
• 30-day interview signal: 能从业务问题讲到 eval, 而不是只讲 AI 技术.

First 60 days - architecture and governance

• Week 5: Produce Data Readiness Pack for AML, lending, or service copilot.
• Week 6: Write Architecture ADR Set: RAG vs long context, workflow vs agent, model gateway, HITL.
• Week 7: Map OWASP LLM Top 10 and NIST AI RMF risks into an AI Control Pack.
• Week 8: Create one executive decision memo with go/no-go recommendation.
• 60-day interview signal: 能讲清 "why this architecture", "why now", "why safe enough", "what to monitor".

First 90 days - pilot and operations

• Week 9: Build or document a small prototype, even if mock-based, tied to a real workflow.
• Week 10: Design EvalOps release gate and failure taxonomy.
• Week 11: Build Adoption Dashboard: usage, trust, quality, time saved, fallback, escalation.
• Week 12: Write Business Case with baseline, cost, benefit, sensitivity, risk adjustment.
• 90-day interview signal: 能展示 one end-to-end case: problem -> workflow -> architecture -> eval -> launch gate -> business case.

First 180 days - portfolio and senior narrative

• Days 91-120: Add two more scenarios: lending assistant and service copilot.
• Days 121-140: Build enterprise AI capability map and target architecture across all scenarios.
• Days 141-160: Create vendor assessment and build-vs-buy matrix for one scenario.
• Days 161-180: Assemble portfolio evidence map and 10-minute executive story.
• 180-day interview signal: 能同时胜任 AI BA / AI PM / Solutions Architect 讨论, 并能升级到 Enterprise Architect 视角.

---

9. Weekly Training Loop

Use one business scenario per week. Do not only read. Every week must produce artifact evidence.

Monday - Problem and baseline

• Pick one scenario: AML/KYC, lending, fraud, service copilot, payments ops, wealth compliance.
• Write one measurable problem statement.
• Identify baseline metric: cycle time, false positive rate, AHT, error rate, rework, backlog, cost per case.
• Write one no-AI alternative.

Tuesday - Stakeholders and workflow

• Map users, approvers, risk owners, data owners, IT, audit, legal, operations.
• Draft 8-12 interview questions.
• Draw current-state flow with exception path.
• Mark pain, wait, handoff, control, evidence point.

Wednesday - Requirements and evals

• Write 5-10 requirements.
• For each requirement, define gold sample, expected behavior, grader, threshold, owner.
• Add at least 3 negative or adversarial cases.
• Define when the system must ask for human help.

Thursday - Architecture and data

• Draft C4 context/container diagram in text or Mermaid.
• Write 2 ADRs: one about RAG/knowledge, one about workflow/agent/action boundary.
• Check data readiness: source, owner, access, freshness, labels, PII, lineage.
• Identify one vendor or platform option and one build option.

Friday - Risk, governance, and operations

• Map top risks to NIST AI RMF, EU AI Act logic, OWASP LLM Top 10, ISO/IEC 42001.
• Define controls: RBAC, citation, HITL, approval, logging, rate limits, tool permissions, red team.
• Define release gate and monitoring metrics.
• Write incident scenario and rollback trigger.

Saturday - Business case and adoption

• Estimate value: time saved, quality improvement, risk reduction, revenue, cost avoidance.
• Estimate cost: model, engineering, data prep, review, vendor, governance, training.
• Define adoption funnel: eligible users, active users, repeated users, trusted outputs, abandoned flows.
• Create rollout plan: pilot group, training, champion, support, feedback cadence.

Sunday - Portfolio story

• Write a 10-minute narrative.
• Structure: situation, baseline, root cause, options, architecture, eval, risk, value, adoption, next step.
• Update 12-portfolio-evidence-map.md with artifact links.
• Write one interview answer in STAR-T format.

---

10. Common Cross-Role Failure Modes

• Demo trap: building a slick prototype without business baseline or adoption plan.
• Model trap: optimizing model score while ignoring workflow, data ownership, and human review.
• Governance trap: writing compliance checklists with no owner, evidence, or release gate.
• Architecture trap: drawing target architecture without transition states and funding logic.
• BA trap: accepting stakeholder requests as truth without evidence and conflict analysis.
• PM trap: measuring usage while ignoring quality, trust, cost, and risk.
• Eval trap: testing easy examples and missing hard negatives, adversarial inputs, policy boundaries.
• FDE trap: over-customizing one client solution without productizing reusable patterns.
• Enterprise trap: creating standards so heavy that teams bypass them.
• Portfolio trap: listing many artifacts without a crisp story of decisions and proof.

---

11. Self-Assessment Rubric

Score each capability from 1 to 5 every month.

Monthly review: identify the strongest role, the bottleneck role, the weakest artifact evidence, the best financial retail proof scenario, the source anchor to refresh, and the interview story to rehearse.

---

12. Recommended Portfolio Structure

Use a portfolio folder or index with six tabs:

1. Problem and Business Case.
2. Workflow and Requirements.
3. Data and Domain Model.
4. AI Architecture and Governance.
5. EvalOps and Production Quality.
6. Adoption and Executive Story.

Each case should have:

• One-page executive decision memo.
• Current-state and future-state workflow.
• Requirements-to-Eval Matrix.
• Architecture ADR Set.
• AI Control Pack.
• Adoption Dashboard.
• Business Case.
• Interview script.

Minimum portfolio by 180 days:

• AML/KYC Copilot: strongest governance and eval case.
• Lending Assistant: strongest high-risk AI and policy reasoning case.
• Payments Operations Copilot: strongest architecture and operational reliability case.
• Service Copilot: strongest adoption and customer workflow case.
• Wealth Advisory Compliance: strongest compliance, human oversight, and product boundary case.

---

13. Final Operating Principle

The target is not to become six separate people.

The target is to become the person who can translate across the six roles:

• from business pain to measurable baseline,
• from stakeholder conflict to decision evidence,
• from process model to AI workflow,
• from requirement to eval,
• from architecture to control,
• from pilot to adoption,
• from artifact folder to executive story.

That translation ability is the durable advantage for 2026+ enterprise AI roles.