[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QB7GEG7CFEPMHSRSRPG0RE":3,"skill-same:01M6QB7GEG7CFEPMHSRSRPG0RE":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6QB7GEG7CFEPMHSRSRPG0RE","chief-ai-officer-advisor",null,"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\u002FML skills.","Tashima-Tarsh\u002FDisha6.6","Tashima-Tarsh","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F269906498?v=4","01M6PBH98X03XERH0HFT4PFB1P","NITISH KUMAR","01M6PBH9DA0M6KM3Z12P848F0K",0,"MIT","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchief-ai-officer-advisor\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"chief ai officer advisor","chief","advisor","risk classification","ai governance","economics","sequencing","act","leadership","self","ai team","selection","classifier","only","model","team","api","tuning","NIST","model selection","2026-11-10 10:12:30",false,"---\nname: \"chief-ai-officer-advisor\"\ndescription: \"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\u002FML skills.\"\nlicense: MIT\nmetadata:\n  version: 1.0.0\n  author: Alireza Rezvani\n  category: c-level\n  domain: chief-ai-officer-leadership\n  updated: 2026-05-12\n  python-tools: model_buildvsbuy_calculator.py, ai_risk_classifier.py, ai_cost_economics.py\n  frameworks: model-buildvsbuy, ai-risk-governance, ai-economics, ai-team-org\n---\n\n# Chief AI Officer Advisor\n\nStrategic AI leadership for startup CAIOs and founders without one. **Four decisions, no AI hype:**\n\n1. **Should we use an API, fine-tune, or build our own?** — model build-vs-buy with 3-year TCO\n2. **Is this AI use case high-risk under regulation, and how do we govern it?** — EU AI Act + NIST AI RMF + US state patchwork\n3. **When do we switch from API to self-hosted, and at what cost?** — token economics with breakeven analysis\n4. **What AI role do we hire next?** — stage-to-role map (AI engineer ≠ ML engineer ≠ research scientist)\n\nThis skill does **not** cover tactical AI\u002FML engineering. For RAG implementation, agent design, prompt engineering, eval infrastructure, model deployment, or cost optimization, see `engineering\u002Frag-architect\u002F`, `engineering\u002Fagent-designer\u002F`, `engineering\u002Fprompt-governance\u002F`, `engineering\u002Fself-eval\u002F`, `engineering\u002Fllm-cost-optimizer\u002F`.\n\n## Keywords\n\nCAIO, 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\n\n## Quick Start\n\n```bash\n# Decision A: API vs fine-tune vs build\npython scripts\u002Fmodel_buildvsbuy_calculator.py                          # embedded customer-support sample\npython scripts\u002Fmodel_buildvsbuy_calculator.py path\u002Fto\u002Fuse_case.json\n\n# Decision B: Risk classification under EU AI Act + US state laws\npython scripts\u002Fai_risk_classifier.py                                   # embedded hiring-AI sample\npython scripts\u002Fai_risk_classifier.py path\u002Fto\u002Fuse_case.json\n\n# Decision C: API vs self-hosted economics\npython scripts\u002Fai_cost_economics.py                                    # embedded 5M tokens\u002Fday sample\npython scripts\u002Fai_cost_economics.py path\u002Fto\u002Fworkload.json\n```\n\n## Key Questions (ask these first)\n\n- **What does this AI need to be good at, and how would you measure it?** (If no eval set, no ship.)\n- **What's the SLO on hallucination \u002F error rate?** (Without one, \"AI quality\" is a vibe.)\n- **What happens when the model is wrong?** (Fallback behavior, human-in-the-loop, blast radius.)\n- **What's the risk tier under EU AI Act, and is conformity assessment required?** (Determines product launch timeline.)\n- **At what monthly token volume does self-hosting beat API?** (Almost never below 100M tokens\u002Fmonth at frontier quality.)\n- **Are we hiring an AI engineer or an ML research scientist?** (Different jobs; founders confuse them.)\n\n## Core Responsibilities\n\n### 1. Model Build-vs-Buy\n\nThe 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.\n\n**Default path: API (frontier model)**\n- Use when: well-served by frontier (Claude, GPT, Gemini), QPS \u003C 100, latency budget > 1s, cost \u003C $50K\u002Fmonth\n- Why: frontier APIs are 10-100x more capable than what most teams can fine-tune in-house\n- Failure mode: API rate limits at scale, vendor lock-in, capability drift between model versions\n\n**Fine-tune a smaller model**\n- Use when: domain-specific behavior the API can't be prompted into (medical coding, legal redlining), high volume reducing API cost, latency budget \u003C 500ms, specific style\u002Fformat consistency required\n- Approaches: full fine-tune (rare), LoRA\u002FQLoRA (common), RLHF\u002FDPO (when alignment matters)\n- Failure mode: fine-tuned model lags frontier capability within 6-12 months; ongoing retraining cost\n\n**Build from scratch \u002F pre-train**\n- Use when: almost never. You're a foundation-model company, OR you have a unique data corpus, $50M+ funding, and 18+ month patience.\n- Failure mode: by the time you ship, frontier models have caught up and your sunk cost is unrecoverable\n\n**Run** `model_buildvsbuy_calculator.py` for a use-case-specific recommendation with 3-year TCO. See `references\u002Fmodel_buildvsbuy_strategy.md` for full decision tree.\n\n### 2. AI Risk Classification & Governance\n\nThe 2026 question every founder is facing: **does this AI use case trigger high-risk regulatory obligations?**\n\n**EU AI Act (in force 2026) tiers:**\n\n| Tier | Examples | Obligations |\n|---|---|---|\n| **Prohibited** | Social scoring, real-time biometric surveillance, manipulative AI | Cannot deploy in EU |\n| **High-risk** | Employment screening, credit scoring, education access, critical infrastructure, law enforcement, biometric ID | Conformity assessment, registration, post-market monitoring, transparency, human oversight |\n| **Limited-risk** | Chatbots, deepfakes, emotion recognition | Transparency: user must know they're interacting with AI |\n| **Minimal-risk** | Recommendation systems, spam filters, most B2B SaaS internals | No specific obligations |\n\n**Run** `ai_risk_classifier.py` to classify a use case and get the required-controls list.\n\n**US state patchwork (non-exhaustive):**\n\n- NYC LL 144 — Automated Employment Decision Tools (AEDTs) require annual bias audit + candidate notice\n- Colorado AI Act \u002F SB 21-169 — AI in consumer decisions (credit, insurance, employment, housing)\n- Illinois HB 53 — AI in interview\u002Fhiring\n- California SB 1001 — Bot disclosure\n- Texas TCPA — Biometric identifier capture\n- Federal NIST AI RMF — voluntary; increasingly referenced in contracts\n\n**Industry-specific overlays:**\n\n- Healthcare: FDA AI\u002FML guidance (2023), MDR (EU) for medical-device AI, 510(k) pathway for AI\u002FML-enabled medical devices\n- Financial: NYDFS Reg 23, FTC Section 5, ECOA for credit decisions\n- Insurance: NAIC model bulletin, state insurance commissioner rules\n\nSee `references\u002Fai_risk_governance.md` for the full regulatory landscape + governance program checklist.\n\n### 3. AI Cost Economics\n\n**The breakeven question:** at what monthly token volume does self-hosted inference beat API costs?\n\n**Key components:**\n\n- **API cost** — variable, per-token. Frontier models 2026: Claude Sonnet 4.6 ~$3\u002F$15 per M tokens (input\u002Foutput), GPT-4o ~$2.50\u002F$10, Gemini 2.5 ~$1.25\u002F$5\n- **Self-hosted cost** — fixed (GPU commitment) + variable (electricity). H100 spot ~$2-5\u002Fhour, A100 spot ~$1-3\u002Fhour. Llama 3.1 70B \u002F Qwen 2.5 72B: ~$0.50-2.00 per million output tokens at 70% utilization\n- **Hidden costs of self-hosting** — ops on-call, monitoring, model updates, scaling overhead, idle time penalty\n- **Hidden costs of API** — rate limits requiring multi-vendor failover, vendor lock-in, capability drift between versions, data residency\n\n**Typical breakeven (frontier-quality):** 100M–500M tokens\u002Fmonth, depending on model size and acceptable quality tradeoff. Below this, API wins. Above this, run the calculator.\n\n**Run** `ai_cost_economics.py` with workload characteristics for a breakeven point + sensitivity to GPU rates and model size.\n\nSee `references\u002Fai_cost_economics.md` for the full economics model and operational considerations.\n\n### 4. AI Team Org Evolution\n\n**The wrong question:** \"Should we hire an ML engineer or a research scientist?\"\n**The right question:** \"What's the next AI capability we need to ship, and what role unblocks that?\"\n\nStage-to-role map:\n\n| Stage | First AI hire | Then | Then |\n|---|---|---|---|\n| Pre-PMF | Founder + 1 ML-curious engineer playing with prompts | — | — |\n| Series A | **AI engineer** (applied, full-stack; owns prompts\u002Fevals\u002Fdeployment) | Second AI engineer for evals\u002Fquality | — |\n| Series B | AI\u002FML platform engineer (inference, evals, observability) | Third AI engineer for production reliability | Data scientist if model is core IP |\n| Series C | Manager of AI | ML research scientist (only if model IS the product) | AI safety \u002F red team (if customer-facing AI) |\n| Late-stage | Head of AI → CAIO | Multiple research scientists, platform team, safety\u002Fred team | Federated AI leads per business unit |\n\n**Critical distinctions:**\n\n- **AI engineer** ≠ **ML engineer** ≠ **research scientist**\n  - AI engineer: full-stack + prompts + evals + deployment. Most startups need this, not the others.\n  - ML engineer: production deployment, monitoring, retraining infrastructure. Hire after data engineer.\n  - Research scientist: model invention, novel architectures. Only at Series C+ if model is core IP.\n\n**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.\n\nSee `references\u002Fai_team_org_evolution.md`.\n\n## Workflows\n\n### Workflow 1: Model Selection Decision (1 hour)\n**Goal:** Decide whether a specific use case should use API, fine-tune, or build.\n\n```bash\n# 1. Define use_case.json (volume, latency, accuracy, team size, budget)\npython scripts\u002Fmodel_buildvsbuy_calculator.py use_case.json\n# 2. Review 3-year TCO + breakeven\n# 3. Cross-check with cs-cfo-advisor on budget commitment\n# 4. Cross-check with cs-cto-advisor on engineering capacity (esp. for fine-tune)\n# 5. Log via \u002Fcs:decide; consider \u002Fcs:freeze 60 on multi-year vendor commitment\n```\n\n### Workflow 2: AI Risk Classification (2-4 hours)\n**Goal:** Classify a use case under EU AI Act + US state laws, identify required controls.\n\n```bash\n# 1. Define use_case.json (decisions affected, users, geography, sector)\npython scripts\u002Fai_risk_classifier.py use_case.json\n# 2. For HIGH-RISK: budget conformity assessment + registration\n# 3. For LIMITED-RISK: implement transparency requirements\n# 4. Cross-check with cs-general-counsel-advisor on contractual implications\n# 5. Cross-check with cs-ciso-advisor on technical safeguards\n# 6. Log via \u002Fcs:decide\n```\n\n### Workflow 3: API-to-Self-Hosted Breakeven (1 day)\n**Goal:** Decide when (and whether) to migrate from API to self-hosted inference.\n\n```bash\n# 1. Build workload.json (tokens\u002Fday, model size, latency, quality tolerance)\npython scripts\u002Fai_cost_economics.py workload.json\n# 2. Run sensitivity scenarios (low\u002Fmid\u002Fhigh GPU rates)\n# 3. Estimate migration cost (engineering time + risk)\n# 4. Cross-check with cs-cfo-advisor on capex commitment\n# 5. Cross-check with cs-cto-advisor on platform readiness\n# 6. Log via \u002Fcs:decide; pair with \u002Fcs:freeze if signing GPU commitment\n```\n\n### Workflow 4: AI Team Roadmap (1 week)\n**Goal:** Sequence next 18 months of AI hires aligned to capabilities to ship.\n\n1. List top 5 AI capabilities the product needs in 12 months\n2. Map each capability to the role that ships it (see `ai_team_org_evolution.md`)\n3. Sequence hires (one role at a time, ramp before next)\n4. Cross-check with cs-chro-advisor on comp + leveling\n5. Identify the centralize-vs-embed trigger\n\n## Output Standards\n\n```\n**Bottom Line:** [one sentence — decision and rationale]\n**The Decision:** [one of: model selection | risk classification | economics | next hire]\n**The Evidence:** [numbers from the tool, not adjectives]\n**How to Act:** [3 concrete next steps]\n**Your Decision:** [the call only the founder can make]\n```\n\n## Adjacent Skills\n\n- `c-level-advisor\u002Fskills\u002Fchief-data-officer-advisor\u002F` — Training data rights, data product strategy (chains directly to model decisions)\n- `c-level-advisor\u002Fskills\u002Fcto-advisor\u002F` — Architecture capacity, scaling cliffs (esp. for self-hosted inference)\n- `c-level-advisor\u002Fskills\u002Fciso-advisor\u002F` — Threat modeling for AI (prompt injection, jailbreak, training data poisoning)\n- `c-level-advisor\u002Fskills\u002Fgeneral-counsel-advisor\u002F` — AI contracts (vendor liability, output ownership, training-data licensing)\n- `c-level-advisor\u002Fskills\u002Fcfo-advisor\u002F` — Build-vs-buy TCO math, multi-year vendor commitments\n- `c-level-advisor\u002Fskills\u002Fchro-advisor\u002F` — AI team hiring + comp\n- `engineering\u002Fskills\u002Frag-architect\u002F` — Tactical RAG implementation\n- `engineering\u002Fskills\u002Fagent-designer\u002F` — Tactical agent architecture\n- `engineering\u002Fprompt-governance\u002F` — Tactical prompt management\n- `engineering\u002Fskills\u002Fself-eval\u002F` — Tactical eval infrastructure\n- `engineering\u002Fllm-cost-optimizer\u002F` — Tactical inference cost optimization\n\n## References\n\n- [model_buildvsbuy_strategy.md](references\u002Fmodel_buildvsbuy_strategy.md) — Full decision tree + 3-year TCO components + when each path fails\n- [ai_risk_governance.md](references\u002Fai_risk_governance.md) — EU AI Act + NIST AI RMF + US state patchwork + industry overlays + governance program\n- [ai_cost_economics.md](references\u002Fai_cost_economics.md) — API pricing 2026 + GPU rental economics + utilization realities + migration cost\n- [ai_team_org_evolution.md](references\u002Fai_team_org_evolution.md) — Stage-to-role map + role definitions (AI engineer ≠ ML engineer ≠ scientist) + anti-patterns\n\n---\n\n**Version:** 1.0.0\n**Status:** Production Ready\n**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.\n","# Chief AI Officer Advisor\n\nStrategic AI leadership for startup CAIOs and founders without one. **Four decisions, no AI hype:**\n\n1. **Should we use an API, fine-tune, or build our own?** — model build-vs-buy with 3-year TCO\n2. **Is this AI use case high-risk under regulation, and how do we govern it?** — EU AI Act + NIST AI RMF + US state patchwork\n3. **When do we switch from API to self-hosted, and at what cost?** — token economics with breakeven analysis\n4. **What AI role do we hire next?** — stage-to-role map (AI engineer ≠ ML engineer ≠ research scientist)\n\nThis skill does **not** cover tactical AI\u002FML engineering. For RAG implementation, agent design, prompt engineering, eval infrastructure, model deployment, or cost optimization, see `engineering\u002Frag-architect\u002F`, `engineering\u002Fagent-designer\u002F`, `engineering\u002Fprompt-governance\u002F`, `engineering\u002Fself-eval\u002F`, `engineering\u002Fllm-cost-optimizer\u002F`.\n\n## Keywords\n\nCAIO, 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\n\n## Quick Start\n\n```bash\n# Decision A: API vs fine-tune vs build\npython scripts\u002Fmodel_buildvsbuy_calculator.py                          # embedded customer-support sample\npython scripts\u002Fmodel_buildvsbuy_calculator.py path\u002Fto\u002Fuse_case.json\n\n# Decision B: Risk classification under EU AI Act + US state laws\npython scripts\u002Fai_risk_classifier.py                                   # embedded hiring-AI sample\npython scripts\u002Fai_risk_classifier.py path\u002Fto\u002Fuse_case.json\n\n# Decision C: API vs self-hosted economics\npython scripts\u002Fai_cost_economics.py                                    # embedded 5M tokens\u002Fday sample\npython scripts\u002Fai_cost_economics.py path\u002Fto\u002Fworkload.json\n```\n\n## Key Questions (ask these first)\n\n- **What does this AI need to be good at, and how would you measure it?** (If no eval set, no ship.)\n- **What's the SLO on hallucination \u002F error rate?** (Without one, \"AI quality\" is a vibe.)\n- **What happens when the model is wrong?** (Fallback behavior, human-in-the-loop, blast radius.)\n- **What's the risk tier under EU AI Act, and is conformity assessment required?** (Determines product launch timeline.)\n- **At what monthly token volume does self-hosting beat API?** (Almost never below 100M tokens\u002Fmonth at frontier quality.)\n- **Are we hiring an AI engineer or an ML research scientist?** (Different jobs; founders confuse them.)\n\n## Core Responsibilities\n\n### 1. Model Build-vs-Buy\n\nThe 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.\n\n**Default path: API (frontier model)**\n- Use when: well-served by frontier (Claude, GPT, Gemini), QPS \u003C 100, latency budget > 1s, cost \u003C $50K\u002Fmonth\n- Why: frontier APIs are 10-100x more capable than what most teams can fine-tune in-house\n- Failure mode: API rate limits at scale, vendor lock-in, capability drift between model versions\n\n**Fine-tune a smaller model**\n- Use when: domain-specific behavior the API can't be prompted into (medical coding, legal redlining), high volume reducing API cost, latency budget \u003C 500ms, specific style\u002Fformat consistency required\n- Approaches: full fine-tune (rare), LoRA\u002FQLoRA (common), RLHF\u002FDPO (when alignment matters)\n- Failure mode: fine-tuned model lags frontier capability within 6-12 months; ongoing retraining cost\n\n**Build from scratch \u002F pre-train**\n- Use when: almost never. You're a foundation-model company, OR you have a unique data corpus, $50M+ funding, and 18+ month patience.\n- Failure mode: by the time you ship, frontier models have caught up and your sunk cost is unrecoverable\n\n**Run** `model_buildvsbuy_calculator.py` for a use-case-specific recommendation with 3-year TCO. See `references\u002Fmodel_buildvsbuy_strategy.md` for full decision tree.\n\n### 2. AI Risk Classification & Governance\n\nThe 2026 question every founder is facing: **does this AI use case trigger high-risk regulatory obligations?**\n\n**EU AI Act (in force 2026) tiers:**\n\n| Tier | Examples | Obligations |\n|---|---|---|\n| **Prohibited** | Social scoring, real-time biometric surveillance, manipulative AI | Cannot deploy in EU |\n| **High-risk** | Employment screening, credit scoring, education access, critical infrastructure, law enforcement, biometric ID | Conformity assessment, registration, post-market monitoring, transparency, human oversight |\n| **Limited-risk** | Chatbots, deepfakes, emotion recognition | Transparency: user must know they're interacting with AI |\n| **Minimal-risk** | Recommendation systems, spam filters, most B2B SaaS internals | No specific obligations |\n\n**Run** `ai_risk_classifier.py` to classify a use case and get the required-controls list.\n\n**US state patchwork (non-exhaustive):**\n\n- NYC LL 144 — Automated Employment Decision Tools (AEDTs) require annual bias audit + candidate notice\n- Colorado AI Act \u002F SB 21-169 — AI in consumer decisions (credit, insurance, employment, housing)\n- Illinois HB 53 — AI in interview\u002Fhiring\n- California SB 1001 — Bot disclosure\n- Texas TCPA — Biometric identifier capture\n- Federal NIST AI RMF — voluntary; increasingly referenced in contracts\n\n**Industry-specific overlays:**\n\n- Healthcare: FDA AI\u002FML guidance (2023), MDR (EU) for medical-device AI, 510(k) pathway for AI\u002FML-enabled medical devices\n- Financial: NYDFS Reg 23, FTC Section 5, ECOA for credit decisions\n- Insurance: NAIC model bulletin, state insurance commissioner rules\n\nSee `references\u002Fai_risk_governance.md` for the full regulatory landscape + governance program checklist.\n\n### 3. AI Cost Economics\n\n**The breakeven question:** at what monthly token volume does self-hosted inference beat API costs?\n\n**Key components:**\n\n- **API cost** — variable, per-token. Frontier models 2026: Claude Sonnet 4.6 ~$3\u002F$15 per M tokens (input\u002Foutput), GPT-4o ~$2.50\u002F$10, Gemini 2.5 ~$1.25\u002F$5\n- **Self-hosted cost** — fixed (GPU commitment) + variable (electricity). H100 spot ~$2-5\u002Fhour, A100 spot ~$1-3\u002Fhour. Llama 3.1 70B \u002F Qwen 2.5 72B: ~$0.50-2.00 per million output tokens at 70% utilization\n- **Hidden costs of self-hosting** — ops on-call, monitoring, model updates, scaling overhead, idle time penalty\n- **Hidden costs of API** — rate limits requiring multi-vendor failover, vendor lock-in, capability drift between versions, data residency\n\n**Typical breakeven (frontier-quality):** 100M–500M tokens\u002Fmonth, depending on model size and acceptable quality tradeoff. Below this, API wins. Above this, run the calculator.\n\n**Run** `ai_cost_economics.py` with workload characteristics for a breakeven point + sensitivity to GPU rates and model size.\n\nSee `references\u002Fai_cost_economics.md` for the full economics model and operational considerations.\n\n### 4. AI Team Org Evolution\n\n**The wrong question:** \"Should we hire an ML engineer or a research scientist?\"\n**The right question:** \"What's the next AI capability we need to ship, and what role unblocks that?\"\n\nStage-to-role map:\n\n| Stage | First AI hire | Then | Then |\n|---|---|---|---|\n| Pre-PMF | Founder + 1 ML-curious engineer playing with prompts | — | — |\n| Series A | **AI engineer** (applied, full-stack; owns prompts\u002Fevals\u002Fdeployment) | Second AI engineer for evals\u002Fquality | — |\n| Series B | AI\u002FML platform engineer (inference, evals, observability) | Third AI engineer for production reliability | Data scientist if model is core IP |\n| Series C | Manager of AI | ML research scientist (only if model IS the product) | AI safety \u002F red team (if customer-facing AI) |\n| Late-stage | Head of AI → CAIO | Multiple research scientists, platform team, safety\u002Fred team | Federated AI leads per business unit |\n\n**Critical distinctions:**\n\n- **AI engineer** ≠ **ML engineer** ≠ **research scientist**\n  - AI engineer: full-stack + prompts + evals + deployment. Most startups need this, not the others.\n  - ML engineer: production deployment, monitoring, retraining infrastructure. Hire after data engineer.\n  - Research scientist: model invention, novel architectures. Only at Series C+ if model is core IP.\n\n**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.\n\nSee `references\u002Fai_team_org_evolution.md`.\n\n## Workflows\n\n### Workflow 1: Model Selection Decision (1 hour)\n**Goal:** Decide whether a specific use case should use API, fine-tune, or build.\n\n```bash\n# 1. Define use_case.json (volume, latency, accuracy, team size, budget)\npython scripts\u002Fmodel_buildvsbuy_calculator.py use_case.json\n# 2. Review 3-year TCO + breakeven\n# 3. Cross-check with cs-cfo-advisor on budget commitment\n# 4. Cross-check with cs-cto-advisor on engineering capacity (esp. for fine-tune)\n# 5. Log via \u002Fcs:decide; consider \u002Fcs:freeze 60 on multi-year vendor commitment\n```\n\n### Workflow 2: AI Risk Classification (2-4 hours)\n**Goal:** Classify a use case under EU AI Act + US state laws, identify required controls.\n\n```bash\n# 1. Define use_case.json (decisions affected, users, geography, sector)\npython scripts\u002Fai_risk_classifier.py use_case.json\n# 2. For HIGH-RISK: budget conformity assessment + registration\n# 3. For LIMITED-RISK: implement transparency requirements\n# 4. Cross-check with cs-general-counsel-advisor on contractual implications\n# 5. Cross-check with cs-ciso-advisor on technical safeguards\n# 6. Log via \u002Fcs:decide\n```\n\n### Workflow 3: API-to-Self-Hosted Breakeven (1 day)\n**Goal:** Decide when (and whether) to migrate from API to self-hosted inference.\n\n```bash\n# 1. Build workload.json (tokens\u002Fday, model size, latency, quality tolerance)\npython scripts\u002Fai_cost_economics.py workload.json\n# 2. Run sensitivity scenarios (low\u002Fmid\u002Fhigh GPU rates)\n# 3. Estimate migration cost (engineering time + risk)\n# 4. Cross-check with cs-cfo-advisor on capex commitment\n# 5. Cross-check with cs-cto-advisor on platform readiness\n# 6. Log via \u002Fcs:decide; pair with \u002Fcs:freeze if signing GPU commitment\n```\n\n### Workflow 4: AI Team Roadmap (1 week)\n**Goal:** Sequence next 18 months of AI hires aligned to capabilities to ship.\n\n1. List top 5 AI capabilities the product needs in 12 months\n2. Map each capability to the role that ships it (see `ai_team_org_evolution.md`)\n3. Sequence hires (one role at a time, ramp before next)\n4. Cross-check with cs-chro-advisor on comp + leveling\n5. Identify the centralize-vs-embed trigger\n\n## Output Standards\n\n```\n**Bottom Line:** [one sentence — decision and rationale]\n**The Decision:** [one of: model selection | risk classification | economics | next hire]\n**The Evidence:** [numbers from the tool, not adjectives]\n**How to Act:** [3 concrete next steps]\n**Your Decision:** [the call only the founder can make]\n```\n\n## Adjacent Skills\n\n- `c-level-advisor\u002Fskills\u002Fchief-data-officer-advisor\u002F` — Training data rights, data product strategy (chains directly to model decisions)\n- `c-level-advisor\u002Fskills\u002Fcto-advisor\u002F` — Architecture capacity, scaling cliffs (esp. for self-hosted inference)\n- `c-level-advisor\u002Fskills\u002Fciso-advisor\u002F` — Threat modeling for AI (prompt injection, jailbreak, training data poisoning)\n- `c-level-advisor\u002Fskills\u002Fgeneral-counsel-advisor\u002F` — AI contracts (vendor liability, output ownership, training-data licensing)\n- `c-level-advisor\u002Fskills\u002Fcfo-advisor\u002F` — Build-vs-buy TCO math, multi-year vendor commitments\n- `c-level-advisor\u002Fskills\u002Fchro-advisor\u002F` — AI team hiring + comp\n- `engineering\u002Fskills\u002Frag-architect\u002F` — Tactical RAG implementation\n- `engineering\u002Fskills\u002Fagent-designer\u002F` — Tactical agent architecture\n- `engineering\u002Fprompt-governance\u002F` — Tactical prompt management\n- `engineering\u002Fskills\u002Fself-eval\u002F` — Tactical eval infrastructure\n- `engineering\u002Fllm-cost-optimizer\u002F` — Tactical inference cost optimization\n\n## References\n\n- [model_buildvsbuy_strategy.md](references\u002Fmodel_buildvsbuy_strategy.md) — Full decision tree + 3-year TCO components + when each path fails\n- [ai_risk_governance.md](references\u002Fai_risk_governance.md) — EU AI Act + NIST AI RMF + US state patchwork + industry overlays + governance program\n- [ai_cost_economics.md](references\u002Fai_cost_economics.md) — API pricing 2026 + GPU rental economics + utilization realities + migration cost\n- [ai_team_org_evolution.md](references\u002Fai_team_org_evolution.md) — Stage-to-role map + role definitions (AI engineer ≠ ML engineer ≠ scientist) + anti-patterns\n\n---\n\n**Version:** 1.0.0\n**Status:** Production Ready\n**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.\n",{"name":5,"license":15,"metadata":44,"description":7},{"author":45,"domain":46,"updated":47,"version":48,"category":49,"frameworks":50,"python-tools":51},"Alireza Rezvani","chief-ai-officer-leadership",1778544000000,"1.0.0","c-level","model-buildvsbuy, ai-risk-governance, ai-economics, ai-team-org","model_buildvsbuy_calculator.py, ai_risk_classifier.py, ai_cost_economics.py","main","0da4485785ee599388900be50db1635489d53056",".agents\u002Fskills\u002Fchief-ai-officer-advisor","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6","https:\u002F\u002Fdisha6.6.thenitishkr.in\u002F","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh","www.thenitishkr","thenitishkr | AI • Cyber-security • Research\r\n","2026-11-08 03:33:25",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add Tashima-Tarsh\u002FDisha6.6 --skill chief-ai-officer-advisor",{"tool":67,"command":68},"bunx","bunx skills add Tashima-Tarsh\u002FDisha6.6 --skill chief-ai-officer-advisor",{"tool":70,"command":71},"pnpm","pnpm dlx skills add Tashima-Tarsh\u002FDisha6.6 --skill chief-ai-officer-advisor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchief-ai-officer-advisor\u002FSKILL.md",true,[],[76,108,133,160,185,209],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":87,"publishedAt":39},"01M6QRD07D4TGNDK6VJ4EHF8BV","youtube-full","Use when the user needs YouTube transcripts, video search, channel browsing, playlist extraction, or content monitoring. Trigger phrases: 'get the transcript for', 'search YouTube for', 'what are the latest videos on', 'list this playlist', 'monitor this channel', or any request involving a YouTube URL, video ID, or @handle. Do NOT use for downloading video or audio files, YouTube engagement data (likes, comments), or private\u002Fage-restricted videos.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fyoutube-full\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107],"youtube full","youtube","full","transcript","search","monitoring","data","Video","Audio","list","files","do","get","age","trigger","URL","for","browsing","request","youtube transcripts",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":39},"01M6QRCJ3112VYPA97YG7KGMC2","x-twitter-growth","X\u002FTwitter growth engine for building audience, crafting viral content, and analyzing engagement. Use when the user wants to grow on X\u002FTwitter, write tweets or threads, analyze their X profile, research competitors on X, plan a posting strategy, or optimize engagement. Complements social-content (generic multi-platform) with X-specific depth: algorithm mechanics, thread engineering, reply strategy, profile optimization, and competitive intelligence via web search.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fx-twitter-growth\u002FSKILL.md",[],[115,116,117,118,92,119,120,121,122,123,124,125,126,127,128,129,130,131,132,104],"twitter","x twitter growth","growth","research","content","engineering","plan","web search","competitors","analyze","engine","write","strategy","use","platform","grow","posting","competitive",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":142,"publishedAt":39},"01M6QRBN3EHQNJY42RERP7A149","write-a-skill","Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, build, or author a new skill.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwrite-a-skill\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000023","Skill与智能体开发",[143,126,144,145,146,147,148,149,128,150,151,52,152,153,154,155,156,157,158,159],"write a skill","github","create","https","productivity","matt pocock","direct","example","build","new skill","structure","new agent","resources","with","tree","progressive disclosure","author",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":39},"01M6QRB6G8P33PNGAF9Y69EJ9T","wrap-up","Close out a launched Claude Managed Agent — recap every primitive the founder now owns, regenerate the single-file overview page, and suggest the next 1-2 upgrades. Use when the user says \"wrap up\", \"close this out\", \"what do I own now\", \"give me the summary\", \"recap the agent\", or when the orchestrator routes phase=wrap-up. primitives_inventory.py tables everything owned (agent, environment, session, memory, outcome, deployment); overview_page.py regenerates a self-contained .\u002Fmy-agent\u002Fagent-overview.html; upgrade_suggester.py ranks the next moves from recorded deferrals plus standing hardening steps. Companion to run-without-you; the last stop before phase=done.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwrap-up\u002FSKILL.md",[],[167,168,169,170,171,172,173,174,175,128,176,99,177,178,179,180,181,182,183,184],"wrap up","up","wrap","gemini","deployment","run","file","hardening","closeout","stop","upgrade","founder","close","companion","you","tables","directions","phase",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":192,"publishedAt":39},"01M6QRA5AYC1RBFZ39GTWGS3N8","workflow-builder","Design and write deterministic multi-agent workflow scripts (.js files in .claude\u002Fworkflows\u002F) for Claude Code's Workflow tool. Use when a user wants to build, create, author, scaffold, or run a custom Claude Code workflow, orchestrate sub-agents (fan-out, pipeline, loop, judge-panel), or automate a repeatable multi-step task across fresh-context agents.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fworkflow-builder\u002FSKILL.md",[191],{"categoryNo":140,"categoryName":141,"taxonomyType":85,"taxonomyTypeDesc":86},[193,194,195,196,197,145,172,198,199,200,201,202,126,203,98,204,205,206,207,208],"workflow","workflow builder","builder","design","workflows","code","orchestrate","pipeline","loop","multi-agent","context","across","fresh","scripts","judge","claude code workflow",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":39},"01M6QR7QMCZESKQA0ERW1E657M","weekly-review","Use when someone wants to run a weekly review, close open loops, audit stalled projects and commitments, get their system back to trusted, restart a lapsed review habit, or says \"\u002Fcs:weekly-review\". Walks David Allen's three-phase loop — GET CLEAR, GET CURRENT, GET CREATIVE — with deterministic scripts that inventory open loops, gate the checklist with named gaps, and score commitment health 0-100.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[216,217,218,219,220,221,222,223,34,201,224,225,226,227,228,229,100,230,231,184],"review","weekly review","weekly","deterministic scripts","reflect","feeds","inventory","open","projects","project-management","scanner","conversation","back","project","sprint","cadence"]