Chief AI officer advisor
Chief AI Officer advisory for startups: model build-vs-buy decisions (API vs fine-tune vs in-house), AI risk classification under EU AI Act + US state patchwork, AI cost economics (API-to-self-hosted breakeven), and AI team org evolution.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/chief-ai-officer-advisor, including the files SKILL.md points to. - Describe your job in plain words. Claude Code follows the skill from there.
npx degit alirezarezvani/claude-skills/c-level-advisor/chief-ai-officer-advisor/skills/chief-ai-officer-advisor#main ~/.claude/skills/chief-ai-officer-advisorFor one project only, change the path to .claude/skills/chief-ai-officer-advisor. This skill also uses model_buildvsbuy_calculator.py, ai_risk_classifier.py, ai_cost_economics.py, use_case.json, workload.json, ai_team_org_evolution.md — copying SKILL.md alone won't be enough. See the folder on GitHub.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Chief AI officer advisor
Show the full text237 lines
| name | description | license | metadata |
|---|---|---|---|
| chief-ai-officer-advisor | Chief AI Officer advisory for startups: model build-vs-buy decisions (API vs fine-tune vs in-house), AI risk classification under EU AI Act + US state patchwork, AI cost economics (API-to-self-hosted breakeven), and AI team org evolution. Use when deciding whether to call an API or fine-tune, classifying AI use cases for regulatory risk, calculating when self-hosting pays off, sequencing AI hires, or when user mentions CAIO, AI strategy, model selection, foundation model, fine-tuning, EU AI Act, NIST AI RMF, AI governance, model risk, or AI economics. Strategic only — does not duplicate engineering AI/ML skills. | MIT | version: 1.0.0 author: Alireza Rezvani category: c-level domain: chief-ai-officer-leadership updated: 2026-05-12 python-tools: model_buildvsbuy_calculator.py, ai_risk_classifier.py, ai_cost_economics.py frameworks: model-buildvsbuy, ai-risk-governance, ai-economics, ai-team-org |
Chief AI Officer Advisor
Strategic AI leadership for startup CAIOs and founders without one. Four decisions, no AI hype:
- Should we use an API, fine-tune, or build our own? — model build-vs-buy with 3-year TCO
- Is this AI use case high-risk under regulation, and how do we govern it? — EU AI Act + NIST AI RMF + US state patchwork
- When do we switch from API to self-hosted, and at what cost? — token economics with breakeven analysis
- What AI role do we hire next? — stage-to-role map (AI engineer ≠ ML engineer ≠ research scientist)
This skill does not cover tactical AI/ML engineering. For RAG implementation, agent design, prompt engineering, eval infrastructure, model deployment, or cost optimization, see engineering/rag-architect/, engineering/agent-designer/, engineering/prompt-governance/, engineering/self-eval/, engineering/llm-cost-optimizer/.
Keywords
CAIO, chief AI officer, AI strategy, model selection, foundation model, fine-tuning, RLHF, DPO, LoRA, QLoRA, build vs buy, AI build-vs-buy, model risk tier, EU AI Act, AI Act Article 6, Article 9, Article 10, Annex III, prohibited AI, high-risk AI, NIST AI RMF, AI risk management framework, NYC Local Law 144, Colorado SB 21-169, Illinois HB 53, model card, eval set, eval harness, hallucination rate, jailbreak risk, prompt injection, AI red team, AI safety, alignment, model lifecycle, model registry, API-to-self-hosted breakeven, GPU economics, A100, H100, inference cost, fine-tuning cost, AI team, AI engineer, ML engineer, research scientist, MLOps, AI platform
Quick Start
# Decision A: API vs fine-tune vs build
python scripts/model_buildvsbuy_calculator.py # embedded customer-support sample
python scripts/model_buildvsbuy_calculator.py path/to/use_case.json
# Decision B: Risk classification under EU AI Act + US state laws
python scripts/ai_risk_classifier.py # embedded hiring-AI sample
python scripts/ai_risk_classifier.py path/to/use_case.json
# Decision C: API vs self-hosted economics
python scripts/ai_cost_economics.py # embedded 5M tokens/day sample
python scripts/ai_cost_economics.py path/to/workload.json
Key Questions (ask these first)
- What does this AI need to be good at, and how would you measure it? (If no eval set, no ship.)
- What's the SLO on hallucination / error rate? (Without one, "AI quality" is a vibe.)
- What happens when the model is wrong? (Fallback behavior, human-in-the-loop, blast radius.)
- What's the risk tier under EU AI Act, and is conformity assessment required? (Determines product launch timeline.)
- At what monthly token volume does self-hosting beat API? (Almost never below 100M tokens/month at frontier quality.)
- Are we hiring an AI engineer or an ML research scientist? (Different jobs; founders confuse them.)
Core Responsibilities
1. Model Build-vs-Buy
The decision is not "use AI or not" — it's API vs fine-tune vs in-house for each use case. Each path has a different TCO curve, latency profile, and capability ceiling.
Default path: API (frontier model)
- Use when: well-served by frontier (Claude, GPT, Gemini), QPS < 100, latency budget > 1s, cost < $50K/month
- Why: frontier APIs are 10-100x more capable than what most teams can fine-tune in-house
- Failure mode: API rate limits at scale, vendor lock-in, capability drift between model versions
Fine-tune a smaller model
- Use when: domain-specific behavior the API can't be prompted into (medical coding, legal redlining), high volume reducing API cost, latency budget < 500ms, specific style/format consistency required
- Approaches: full fine-tune (rare), LoRA/QLoRA (common), RLHF/DPO (when alignment matters)
- Failure mode: fine-tuned model lags frontier capability within 6-12 months; ongoing retraining cost
Build from scratch / pre-train
- Use when: almost never. You're a foundation-model company, OR you have a unique data corpus, $50M+ funding, and 18+ month patience.
- Failure mode: by the time you ship, frontier models have caught up and your sunk cost is unrecoverable
Run model_buildvsbuy_calculator.py for a use-case-specific recommendation with 3-year TCO. See references/model_buildvsbuy_strategy.md for full decision tree.
2. AI Risk Classification & Governance
The 2026 question every founder is facing: does this AI use case trigger high-risk regulatory obligations?
EU AI Act (in force 2026) tiers:
| Tier | Examples | Obligations |
|---|---|---|
| Prohibited | Social scoring, real-time biometric surveillance, manipulative AI | Cannot deploy in EU |
| High-risk | Employment screening, credit scoring, education access, critical infrastructure, law enforcement, biometric ID | Conformity assessment, registration, post-market monitoring, transparency, human oversight |
| Limited-risk | Chatbots, deepfakes, emotion recognition | Transparency: user must know they're interacting with AI |
| Minimal-risk | Recommendation systems, spam filters, most B2B SaaS internals | No specific obligations |
Run ai_risk_classifier.py to classify a use case and get the required-controls list.
US state patchwork (non-exhaustive):
- NYC LL 144 — Automated Employment Decision Tools (AEDTs) require annual bias audit + candidate notice
- Colorado AI Act / SB 21-169 — AI in consumer decisions (credit, insurance, employment, housing)
- Illinois HB 53 — AI in interview/hiring
- California SB 1001 — Bot disclosure
- Texas TCPA — Biometric identifier capture
- Federal NIST AI RMF — voluntary; increasingly referenced in contracts
Industry-specific overlays:
- Healthcare: FDA AI/ML guidance (2023), MDR (EU) for medical-device AI, 510(k) pathway for AI/ML-enabled medical devices
- Financial: NYDFS Reg 23, FTC Section 5, ECOA for credit decisions
- Insurance: NAIC model bulletin, state insurance commissioner rules
See references/ai_risk_governance.md for the full regulatory landscape + governance program checklist.
3. AI Cost Economics
The breakeven question: at what monthly token volume does self-hosted inference beat API costs?
Key components:
- API cost — variable, per-token. Frontier models 2026: Claude Sonnet 4.6 ~$3/$15 per M tokens (input/output), GPT-4o ~$2.50/$10, Gemini 2.5 ~$1.25/$5
- Self-hosted cost — fixed (GPU commitment) + variable (electricity). H100 spot ~$2-5/hour, A100 spot ~$1-3/hour. Llama 3.1 70B / Qwen 2.5 72B: ~$0.50-2.00 per million output tokens at 70% utilization
- Hidden costs of self-hosting — ops on-call, monitoring, model updates, scaling overhead, idle time penalty
- Hidden costs of API — rate limits requiring multi-vendor failover, vendor lock-in, capability drift between versions, data residency
Typical breakeven (frontier-quality): 100M–500M tokens/month, depending on model size and acceptable quality tradeoff. Below this, API wins. Above this, run the calculator.
Run ai_cost_economics.py with workload characteristics for a breakeven point + sensitivity to GPU rates and model size.
See references/ai_cost_economics.md for the full economics model and operational considerations.
4. AI Team Org Evolution
The wrong question: "Should we hire an ML engineer or a research scientist?" The right question: "What's the next AI capability we need to ship, and what role unblocks that?"
Stage-to-role map:
| Stage | First AI hire | Then | Then |
|---|---|---|---|
| Pre-PMF | Founder + 1 ML-curious engineer playing with prompts | — | — |
| Series A | AI engineer (applied, full-stack; owns prompts/evals/deployment) | Second AI engineer for evals/quality | — |
| Series B | AI/ML platform engineer (inference, evals, observability) | Third AI engineer for production reliability | Data scientist if model is core IP |
| Series C | Manager of AI | ML research scientist (only if model IS the product) | AI safety / red team (if customer-facing AI) |
| Late-stage | Head of AI → CAIO | Multiple research scientists, platform team, safety/red team | Federated AI leads per business unit |
Critical distinctions:
- AI engineer ≠ ML engineer ≠ research scientist
- AI engineer: full-stack + prompts + evals + deployment. Most startups need this, not the others.
- ML engineer: production deployment, monitoring, retraining infrastructure. Hire after data engineer.
- Research scientist: model invention, novel architectures. Only at Series C+ if model is core IP.
Centralize-vs-embed for AI: AI starts centralized (one team) and stays there longer than data team, because the surface area is smaller. Embed only when AI is being deployed in 4+ product surfaces.
See references/ai_team_org_evolution.md.
Workflows
Workflow 1: Model Selection Decision (1 hour)
Goal: Decide whether a specific use case should use API, fine-tune, or build.
# 1. Define use_case.json (volume, latency, accuracy, team size, budget)
python scripts/model_buildvsbuy_calculator.py use_case.json
# 2. Review 3-year TCO + breakeven
# 3. Cross-check with cs-cfo-advisor on budget commitment
# 4. Cross-check with cs-cto-advisor on engineering capacity (esp. for fine-tune)
# 5. Log via /cs:decide; consider /cs:freeze 60 on multi-year vendor commitment
Workflow 2: AI Risk Classification (2-4 hours)
Goal: Classify a use case under EU AI Act + US state laws, identify required controls.
# 1. Define use_case.json (decisions affected, users, geography, sector)
python scripts/ai_risk_classifier.py use_case.json
# 2. For HIGH-RISK: budget conformity assessment + registration
# 3. For LIMITED-RISK: implement transparency requirements
# 4. Cross-check with cs-general-counsel-advisor on contractual implications
# 5. Cross-check with cs-ciso-advisor on technical safeguards
# 6. Log via /cs:decide
Workflow 3: API-to-Self-Hosted Breakeven (1 day)
Goal: Decide when (and whether) to migrate from API to self-hosted inference.
# 1. Build workload.json (tokens/day, model size, latency, quality tolerance)
python scripts/ai_cost_economics.py workload.json
# 2. Run sensitivity scenarios (low/mid/high GPU rates)
# 3. Estimate migration cost (engineering time + risk)
# 4. Cross-check with cs-cfo-advisor on capex commitment
# 5. Cross-check with cs-cto-advisor on platform readiness
# 6. Log via /cs:decide; pair with /cs:freeze if signing GPU commitment
Workflow 4: AI Team Roadmap (1 week)
Goal: Sequence next 18 months of AI hires aligned to capabilities to ship.
- List top 5 AI capabilities the product needs in 12 months
- Map each capability to the role that ships it (see
ai_team_org_evolution.md) - Sequence hires (one role at a time, ramp before next)
- Cross-check with cs-chro-advisor on comp + leveling
- Identify the centralize-vs-embed trigger
Output Standards
**Bottom Line:** [one sentence — decision and rationale]
**The Decision:** [one of: model selection | risk classification | economics | next hire]
**The Evidence:** [numbers from the tool, not adjectives]
**How to Act:** [3 concrete next steps]
**Your Decision:** [the call only the founder can make]
Adjacent Skills
c-level-advisor/skills/chief-data-officer-advisor/— Training data rights, data product strategy (chains directly to model decisions)c-level-advisor/skills/cto-advisor/— Architecture capacity, scaling cliffs (esp. for self-hosted inference)c-level-advisor/skills/ciso-advisor/— Threat modeling for AI (prompt injection, jailbreak, training data poisoning)c-level-advisor/skills/general-counsel-advisor/— AI contracts (vendor liability, output ownership, training-data licensing)c-level-advisor/skills/cfo-advisor/— Build-vs-buy TCO math, multi-year vendor commitmentsc-level-advisor/skills/chro-advisor/— AI team hiring + compengineering/skills/rag-architect/— Tactical RAG implementationengineering/skills/agent-designer/— Tactical agent architectureengineering/prompt-governance/— Tactical prompt managementengineering/skills/self-eval/— Tactical eval infrastructureengineering/llm-cost-optimizer/— Tactical inference cost optimization
References
- model_buildvsbuy_strategy.md — Full decision tree + 3-year TCO components + when each path fails
- ai_risk_governance.md — EU AI Act + NIST AI RMF + US state patchwork + industry overlays + governance program
- ai_cost_economics.md — API pricing 2026 + GPU rental economics + utilization realities + migration cost
- ai_team_org_evolution.md — Stage-to-role map + role definitions (AI engineer ≠ ML engineer ≠ scientist) + anti-patterns
Version: 1.0.0 Status: Production Ready Disclaimer: AI regulation is evolving rapidly. This skill surfaces decisions and tradeoffs as of 2026 but cannot replace qualified AI counsel for binding compliance decisions, especially under EU AI Act conformity assessments.
| 1 | |
| 2 | name "chief-ai-officer-advisor" |
| 3 | description "Chief AI Officer advisory for startups: model build-vs-buy decisions (API vs fine-tune vs in-house), AI risk classification under EU AI Act + US state patchwork, AI cost economics (API-to-self-hosted breakeven), and AI team org evolution. Use when deciding whether to call an API or fine-tune, classifying AI use cases for regulatory risk, calculating when self-hosting pays off, sequencing AI hires, or when user mentions CAIO, AI strategy, model selection, foundation model, fine-tuning, EU AI Act, NIST AI RMF, AI governance, model risk, or AI economics. Strategic only — does not duplicate engineering AI/ML skills." |
| 4 | license MIT |
| 5 | metadata |
| 6 | version 1.0.0 |
| 7 | author Alireza Rezvani |
| 8 | category c-level |
| 9 | domain chief-ai-officer-leadership |
| 10 | updated 2026-05-12 |
| 11 | python-tools model_buildvsbuy_calculator.py, ai_risk_classifier.py, ai_cost_economics.py |
| 12 | frameworks model-buildvsbuy, ai-risk-governance, ai-economics, ai-team-org |
| 13 | |
| 14 | |
| 15 | # Chief AI Officer Advisor |
| 16 | |
| 17 | Strategic AI leadership for startup CAIOs and founders without one. **Four decisions, no AI hype:** |
| 18 | |
| 19 | **Should we use an API, fine-tune, or build our own?** — model build-vs-buy with 3-year TCO |
| 20 | **Is this AI use case high-risk under regulation, and how do we govern it?** — EU AI Act + NIST AI RMF + US state patchwork |
| 21 | **When do we switch from API to self-hosted, and at what cost?** — token economics with breakeven analysis |
| 22 | **What AI role do we hire next?** — stage-to-role map (AI engineer ≠ ML engineer ≠ research scientist) |
| 23 | |
| 24 | This skill does **not** cover tactical AI/ML engineering. For RAG implementation, agent design, prompt engineering, eval infrastructure, model deployment, or cost optimization, see `engineering/rag-architect/`, `engineering/agent-designer/`, `engineering/prompt-governance/`, `engineering/self-eval/`, `engineering/llm-cost-optimizer/`. |
| 25 | |
| 26 | ## Keywords |
| 27 | |
| 28 | CAIO, chief AI officer, AI strategy, model selection, foundation model, fine-tuning, RLHF, DPO, LoRA, QLoRA, build vs buy, AI build-vs-buy, model risk tier, EU AI Act, AI Act Article 6, Article 9, Article 10, Annex III, prohibited AI, high-risk AI, NIST AI RMF, AI risk management framework, NYC Local Law 144, Colorado SB 21-169, Illinois HB 53, model card, eval set, eval harness, hallucination rate, jailbreak risk, prompt injection, AI red team, AI safety, alignment, model lifecycle, model registry, API-to-self-hosted breakeven, GPU economics, A100, H100, inference cost, fine-tuning cost, AI team, AI engineer, ML engineer, research scientist, MLOps, AI platform |
| 29 | |
| 30 | ## Quick Start |
| 31 | |
| 32 | |
| 33 | # Decision A: API vs fine-tune vs build |
| 34 | python scripts/model_buildvsbuy_calculator.py # embedded customer-support sample |
| 35 | python scripts/model_buildvsbuy_calculator.py path/to/use_case.json |
| 36 | |
| 37 | # Decision B: Risk classification under EU AI Act + US state laws |
| 38 | python scripts/ai_risk_classifier.py # embedded hiring-AI sample |
| 39 | python scripts/ai_risk_classifier.py path/to/use_case.json |
| 40 | |
| 41 | # Decision C: API vs self-hosted economics |
| 42 | python scripts/ai_cost_economics.py # embedded 5M tokens/day sample |
| 43 | python scripts/ai_cost_economics.py path/to/workload.json |
| 44 | |
| 45 | |
| 46 | ## Key Questions (ask these first) |
| 47 | |
| 48 | **What does this AI need to be good at, and how would you measure it?** (If no eval set, no ship.) |
| 49 | **What's the SLO on hallucination / error rate?** (Without one, "AI quality" is a vibe.) |
| 50 | **What happens when the model is wrong?** (Fallback behavior, human-in-the-loop, blast radius.) |
| 51 | **What's the risk tier under EU AI Act, and is conformity assessment required?** (Determines product launch timeline.) |
| 52 | **At what monthly token volume does self-hosting beat API?** (Almost never below 100M tokens/month at frontier quality.) |
| 53 | **Are we hiring an AI engineer or an ML research scientist?** (Different jobs; founders confuse them.) |
| 54 | |
| 55 | ## Core Responsibilities |
| 56 | |
| 57 | ### 1. Model Build-vs-Buy |
| 58 | |
| 59 | The decision is not "use AI or not" — it's **API vs fine-tune vs in-house** for each use case. Each path has a different TCO curve, latency profile, and capability ceiling. |
| 60 | |
| 61 | **Default path: API (frontier model)** |
| 62 | Use when: well-served by frontier (Claude, GPT, Gemini), QPS < 100, latency budget > 1s, cost < $50K/month |
| 63 | Why: frontier APIs are 10-100x more capable than what most teams can fine-tune in-house |
| 64 | Failure mode: API rate limits at scale, vendor lock-in, capability drift between model versions |
| 65 | |
| 66 | **Fine-tune a smaller model** |
| 67 | Use when: domain-specific behavior the API can't be prompted into (medical coding, legal redlining), high volume reducing API cost, latency budget < 500ms, specific style/format consistency required |
| 68 | Approaches: full fine-tune (rare), LoRA/QLoRA (common), RLHF/DPO (when alignment matters) |
| 69 | Failure mode: fine-tuned model lags frontier capability within 6-12 months; ongoing retraining cost |
| 70 | |
| 71 | **Build from scratch / pre-train** |
| 72 | Use when: almost never. You're a foundation-model company, OR you have a unique data corpus, $50M+ funding, and 18+ month patience. |
| 73 | Failure mode: by the time you ship, frontier models have caught up and your sunk cost is unrecoverable |
| 74 | |
| 75 | **Run** `model_buildvsbuy_calculator.py` for a use-case-specific recommendation with 3-year TCO. See `references/model_buildvsbuy_strategy.md` for full decision tree. |
| 76 | |
| 77 | ### 2. AI Risk Classification & Governance |
| 78 | |
| 79 | The 2026 question every founder is facing: **does this AI use case trigger high-risk regulatory obligations?** |
| 80 | |
| 81 | **EU AI Act (in force 2026) tiers:** |
| 82 | |
| 83 | | Tier | Examples | Obligations | |
| 84 | |---|---|---| |
| 85 | | **Prohibited** | Social scoring, real-time biometric surveillance, manipulative AI | Cannot deploy in EU | |
| 86 | | **High-risk** | Employment screening, credit scoring, education access, critical infrastructure, law enforcement, biometric ID | Conformity assessment, registration, post-market monitoring, transparency, human oversight | |
| 87 | | **Limited-risk** | Chatbots, deepfakes, emotion recognition | Transparency: user must know they're interacting with AI | |
| 88 | | **Minimal-risk** | Recommendation systems, spam filters, most B2B SaaS internals | No specific obligations | |
| 89 | |
| 90 | **Run** `ai_risk_classifier.py` to classify a use case and get the required-controls list. |
| 91 | |
| 92 | **US state patchwork (non-exhaustive):** |
| 93 | |
| 94 | NYC LL 144 — Automated Employment Decision Tools (AEDTs) require annual bias audit + candidate notice |
| 95 | Colorado AI Act / SB 21-169 — AI in consumer decisions (credit, insurance, employment, housing) |
| 96 | Illinois HB 53 — AI in interview/hiring |
| 97 | California SB 1001 — Bot disclosure |
| 98 | Texas TCPA — Biometric identifier capture |
| 99 | Federal NIST AI RMF — voluntary; increasingly referenced in contracts |
| 100 | |
| 101 | **Industry-specific overlays:** |
| 102 | |
| 103 | Healthcare: FDA AI/ML guidance (2023), MDR (EU) for medical-device AI, 510(k) pathway for AI/ML-enabled medical devices |
| 104 | Financial: NYDFS Reg 23, FTC Section 5, ECOA for credit decisions |
| 105 | Insurance: NAIC model bulletin, state insurance commissioner rules |
| 106 | |
| 107 | See `references/ai_risk_governance.md` for the full regulatory landscape + governance program checklist. |
| 108 | |
| 109 | ### 3. AI Cost Economics |
| 110 | |
| 111 | **The breakeven question:** at what monthly token volume does self-hosted inference beat API costs? |
| 112 | |
| 113 | **Key components:** |
| 114 | |
| 115 | **API cost** — variable, per-token. Frontier models 2026: Claude Sonnet 4.6 ~$3/$15 per M tokens (input/output), GPT-4o ~$2.50/$10, Gemini 2.5 ~$1.25/$5 |
| 116 | **Self-hosted cost** — fixed (GPU commitment) + variable (electricity). H100 spot ~$2-5/hour, A100 spot ~$1-3/hour. Llama 3.1 70B / Qwen 2.5 72B: ~$0.50-2.00 per million output tokens at 70% utilization |
| 117 | **Hidden costs of self-hosting** — ops on-call, monitoring, model updates, scaling overhead, idle time penalty |
| 118 | **Hidden costs of API** — rate limits requiring multi-vendor failover, vendor lock-in, capability drift between versions, data residency |
| 119 | |
| 120 | **Typical breakeven (frontier-quality):** 100M–500M tokens/month, depending on model size and acceptable quality tradeoff. Below this, API wins. Above this, run the calculator. |
| 121 | |
| 122 | **Run** `ai_cost_economics.py` with workload characteristics for a breakeven point + sensitivity to GPU rates and model size. |
| 123 | |
| 124 | See `references/ai_cost_economics.md` for the full economics model and operational considerations. |
| 125 | |
| 126 | ### 4. AI Team Org Evolution |
| 127 | |
| 128 | **The wrong question:** "Should we hire an ML engineer or a research scientist?" |
| 129 | **The right question:** "What's the next AI capability we need to ship, and what role unblocks that?" |
| 130 | |
| 131 | Stage-to-role map: |
| 132 | |
| 133 | | Stage | First AI hire | Then | Then | |
| 134 | |---|---|---|---| |
| 135 | | Pre-PMF | Founder + 1 ML-curious engineer playing with prompts | — | — | |
| 136 | | Series A | **AI engineer** (applied, full-stack; owns prompts/evals/deployment) | Second AI engineer for evals/quality | — | |
| 137 | | Series B | AI/ML platform engineer (inference, evals, observability) | Third AI engineer for production reliability | Data scientist if model is core IP | |
| 138 | | Series C | Manager of AI | ML research scientist (only if model IS the product) | AI safety / red team (if customer-facing AI) | |
| 139 | | Late-stage | Head of AI → CAIO | Multiple research scientists, platform team, safety/red team | Federated AI leads per business unit | |
| 140 | |
| 141 | **Critical distinctions:** |
| 142 | |
| 143 | **AI engineer** ≠ **ML engineer** ≠ **research scientist** |
| 144 | AI engineer: full-stack + prompts + evals + deployment. Most startups need this, not the others. |
| 145 | ML engineer: production deployment, monitoring, retraining infrastructure. Hire after data engineer. |
| 146 | Research scientist: model invention, novel architectures. Only at Series C+ if model is core IP. |
| 147 | |
| 148 | **Centralize-vs-embed for AI:** AI starts centralized (one team) and stays there longer than data team, because the surface area is smaller. Embed only when AI is being deployed in 4+ product surfaces. |
| 149 | |
| 150 | See `references/ai_team_org_evolution.md`. |
| 151 | |
| 152 | ## Workflows |
| 153 | |
| 154 | ### Workflow 1: Model Selection Decision (1 hour) |
| 155 | **Goal:** Decide whether a specific use case should use API, fine-tune, or build. |
| 156 | |
| 157 | |
| 158 | # 1. Define use_case.json (volume, latency, accuracy, team size, budget) |
| 159 | python scripts/model_buildvsbuy_calculator.py use_case.json |
| 160 | # 2. Review 3-year TCO + breakeven |
| 161 | # 3. Cross-check with cs-cfo-advisor on budget commitment |
| 162 | # 4. Cross-check with cs-cto-advisor on engineering capacity (esp. for fine-tune) |
| 163 | # 5. Log via /cs:decide; consider /cs:freeze 60 on multi-year vendor commitment |
| 164 | |
| 165 | |
| 166 | ### Workflow 2: AI Risk Classification (2-4 hours) |
| 167 | **Goal:** Classify a use case under EU AI Act + US state laws, identify required controls. |
| 168 | |
| 169 | |
| 170 | # 1. Define use_case.json (decisions affected, users, geography, sector) |
| 171 | python scripts/ai_risk_classifier.py use_case.json |
| 172 | # 2. For HIGH-RISK: budget conformity assessment + registration |
| 173 | # 3. For LIMITED-RISK: implement transparency requirements |
| 174 | # 4. Cross-check with cs-general-counsel-advisor on contractual implications |
| 175 | # 5. Cross-check with cs-ciso-advisor on technical safeguards |
| 176 | # 6. Log via /cs:decide |
| 177 | |
| 178 | |
| 179 | ### Workflow 3: API-to-Self-Hosted Breakeven (1 day) |
| 180 | **Goal:** Decide when (and whether) to migrate from API to self-hosted inference. |
| 181 | |
| 182 | |
| 183 | # 1. Build workload.json (tokens/day, model size, latency, quality tolerance) |
| 184 | python scripts/ai_cost_economics.py workload.json |
| 185 | # 2. Run sensitivity scenarios (low/mid/high GPU rates) |
| 186 | # 3. Estimate migration cost (engineering time + risk) |
| 187 | # 4. Cross-check with cs-cfo-advisor on capex commitment |
| 188 | # 5. Cross-check with cs-cto-advisor on platform readiness |
| 189 | # 6. Log via /cs:decide; pair with /cs:freeze if signing GPU commitment |
| 190 | |
| 191 | |
| 192 | ### Workflow 4: AI Team Roadmap (1 week) |
| 193 | **Goal:** Sequence next 18 months of AI hires aligned to capabilities to ship. |
| 194 | |
| 195 | List top 5 AI capabilities the product needs in 12 months |
| 196 | Map each capability to the role that ships it (see `ai_team_org_evolution.md`) |
| 197 | Sequence hires (one role at a time, ramp before next) |
| 198 | Cross-check with cs-chro-advisor on comp + leveling |
| 199 | Identify the centralize-vs-embed trigger |
| 200 | |
| 201 | ## Output Standards |
| 202 | |
| 203 | |
| 204 | **Bottom Line:** [one sentence — decision and rationale] |
| 205 | **The Decision:** [one of: model selection | risk classification | economics | next hire] |
| 206 | **The Evidence:** [numbers from the tool, not adjectives] |
| 207 | **How to Act:** [3 concrete next steps] |
| 208 | **Your Decision:** [the call only the founder can make] |
| 209 | |
| 210 | |
| 211 | ## Adjacent Skills |
| 212 | |
| 213 | `c-level-advisor/skills/chief-data-officer-advisor/` — Training data rights, data product strategy (chains directly to model decisions) |
| 214 | `c-level-advisor/skills/cto-advisor/` — Architecture capacity, scaling cliffs (esp. for self-hosted inference) |
| 215 | `c-level-advisor/skills/ciso-advisor/` — Threat modeling for AI (prompt injection, jailbreak, training data poisoning) |
| 216 | `c-level-advisor/skills/general-counsel-advisor/` — AI contracts (vendor liability, output ownership, training-data licensing) |
| 217 | `c-level-advisor/skills/cfo-advisor/` — Build-vs-buy TCO math, multi-year vendor commitments |
| 218 | `c-level-advisor/skills/chro-advisor/` — AI team hiring + comp |
| 219 | `engineering/skills/rag-architect/` — Tactical RAG implementation |
| 220 | `engineering/skills/agent-designer/` — Tactical agent architecture |
| 221 | `engineering/prompt-governance/` — Tactical prompt management |
| 222 | `engineering/skills/self-eval/` — Tactical eval infrastructure |
| 223 | `engineering/llm-cost-optimizer/` — Tactical inference cost optimization |
| 224 | |
| 225 | ## References |
| 226 | |
| 227 | [model_buildvsbuy_strategy.md] — Full decision tree + 3-year TCO components + when each path fails |
| 228 | [ai_risk_governance.md] — EU AI Act + NIST AI RMF + US state patchwork + industry overlays + governance program |
| 229 | [ai_cost_economics.md] — API pricing 2026 + GPU rental economics + utilization realities + migration cost |
| 230 | [ai_team_org_evolution.md] — Stage-to-role map + role definitions (AI engineer ≠ ML engineer ≠ scientist) + anti-patterns |
| 231 | |
| 232 | |
| 233 | |
| 234 | **Version:** 1.0.0 |
| 235 | **Status:** Production Ready |
| 236 | **Disclaimer:** AI regulation is evolving rapidly. This skill surfaces decisions and tradeoffs as of 2026 but cannot replace qualified AI counsel for binding compliance decisions, especially under EU AI Act conformity assessments. |
| 237 |
Discussion
Browse more free Claude skills or everything in Development.