The capstone: from understanding to decisions
You now know the dolls (Session 1), how neural nets learn (2), embeddings (3), recommendations (4), search (5), how LLMs work (6), and how to use GenAI well (7). Knowing is not deciding. A leader is paid for three calls: how do we get AI (build, buy, or API), what could go wrong (the risk grid), and is it even worth it (ROI versus hype). This session is those three calls, plus the two artifacts that carry them into a real organisation - a scored use-case and a one-page memo. No code, all judgment.
Build, buy, or API? 5 min live
There are three ways to put AI in your product, and they trade off the same way every make-or-buy decision does. Call an API (fast, pay per use, least control, no moat), buy a product (a vendor owns it and fits a workflow), or build your own models and pipelines (expensive, slow, but yours). The literate default: API-first for almost everything, and build only the one thing that is genuinely your edge.
LiveWhy API-first wins for almost everything3 min▶
- Call an API when you want capability now. A foundation model (Session 6) behind a paid endpoint ships in days, costs per call, and needs no ML team. The tradeoff: you have the least control and no moat - so does every competitor calling the same endpoint.
- Buy a product when a vendor has already wrapped AI into your exact workflow (support desk, contract review). You get speed and a supported tool, but you rent the edge and inherit the vendor's roadmap and pricing.
- Build only when AI itself is your differentiator and you have the data and talent to sustain it. Owning models and pipelines is expensive and slow - justified when a better model is literally the product, not a feature of it.
- The default: API-first for capability, buy for a solved workflow, build for the one thing customers pay you for. Most organisations should API almost everything and build almost nothing.
The common, expensive mistake: a team spends two quarters training a custom text classifier when a single API call would have shipped the same quality in a week - burning the budget on plumbing, not product. The rarer but sharper mistake runs the other way: putting your actual moat behind someone else's API, so a pricing change or a shut-down endpoint can end your differentiator overnight. Match the method to whether AI is a feature or the edge.
Self-studyThe hidden costs of "just build it"2 min read▶
The build column hides costs that do not show up in the pitch: you need data pipelines that stay clean, a team that can retrain when the model drifts, evaluation harnesses (Session 7), and someone on call when it breaks at 2am. An API price is a line item; a built model is a standing team. That is why "build" is reserved for your true differentiator - the place where owning the edge is worth carrying that whole organisation. Everywhere else, renting capability is not a compromise, it is the correct answer.
The risk grid 5 min live
Every AI deployment must clear the same five checks before it ships. Name the risk, give a concrete example, attach a one-line mitigation. None of these are exotic - they are the predictable failure modes of probabilistic systems trained on human data. The cross-cutting control that shows up in almost every mitigation is the same one: a human in the loop before anything irreversible happens.
LiveThe five checks, one line each3 min▶
- Hallucination - the model states wrong facts fluently (Session 6). Mitigation: ground it in your own data with retrieval, require citations, and keep a human check on anything that acts on the output.
- Bias - the model learns unfair patterns from historical data. Mitigation: test outputs across groups and monitor real outcomes, because the bias hides in results, not intentions.
- Privacy - what data goes in, and where does it travel? Mitigation: map the data path before you ship, send the minimum, and use vendor terms that forbid training on your data.
- IP and copyright - questions on both sides, the training data and the outputs you generate. Mitigation: check licence and indemnity terms and review generated assets before they go public.
- Security - prompt injection (a webpage or document telling your AI to misbehave) and data leakage. Mitigation: isolate untrusted inputs, give the system least privilege, and never treat model output as trusted.
A well-known hiring tool was trained on a decade of past resumes and quietly learned to downrank a group that had historically been under-hired - the bias lived in the training data, not anyone's intent, and it shipped because no one tested outcomes across groups. A simple review gate (compare pass rates by group before go-live) would have caught it in an afternoon. The same gate catches a chatbot about to leak one customer's data to another: a human check between "the model produced this" and "it reached a person" is the cheapest insurance in AI.
ROI, governance, and the scorecard 5 min live
Not every AI project should exist. ROI is real in a few repeatable shapes and hype everywhere else, and the difference is knowable before you spend. Then a little governance - an owner, a gate, an eval, a kill switch - is what keeps a good use case from becoming a bad headline. And an honest boundary: this is where the literacy arc ends, not where building begins.
LiveReal ROI, thin governance, honest boundary3 min▶
- Where ROI is real: augmenting expensive human time (draft, summarise, triage so an expert reviews instead of starts from scratch), handling messy human input at scale (free text, images, speech - the dolls that earn their cost), and personalisation that would be impossible by hand.
- Where it is hype: AI for its own sake because the board asked for "an AI strategy", or replacing a rule that already works (the right-tool test from Session 1 - a spreadsheet does not need a model).
- Lightweight governance: an approval gate before ship, a named owner who is accountable, an eval with a bar (Session 7), and a kill switch to turn it off fast. Four things, not a committee.
- The honest boundary: this course is literacy - understand, evaluate, decide, govern. It is not an ML engineering course. Where to go next: hands-on builder skills, your vendor's docs, and the data-literacy course that sits underneath all of this (no clean data, no AI).
Self-studyThe AI-adoption memo template2 min read▶
The take-home artifact. One page, answer-first - the recommendation in the first line, exactly like the Minto pyramid from the strategic-thinking course. Six rows:
- Use case - the one task, narrow and specific ("draft first-pass replies to tier-1 support tickets").
- Doll - which one is it really (rule / classic ML / deep learning / GenAI, from Session 1)? If a rule does it, stop here.
- Approach - prompt, RAG, or fine-tune (Session 7), and build / buy / API (Part 1).
- Risks + mitigations - the five from the grid, each with your one-line control.
- Eval bar - how you will measure success and the number that means "ship" (Session 7).
- Owner + review - the named person accountable and when it gets re-checked.
If you cannot fill a row, that is the memo telling you the project is not ready - which is a useful answer, not a failure.
The use-case scorecard ★ 10 min · everyone scores
Take one AI idea from your Session 1 right-tool list and score it honestly. Tick only what is genuinely true. The data row is worth the most - notice why as you go.
Score a real idea from your Session 1 list - be honest, ticking a row you cannot defend only fools you.
Notice the data row is worth the most. Discuss why: no clean, accessible data means no AI, whatever the doll - it is the single biggest predictor of success.
A low score is a useful answer, not a failure. Red usually means a rule would do it or the data is not there - both are cheaper to learn now than after a pilot.
Run the risk grid ★ 6 min · everyone checks
Take one AI use case - yours, or the reply-drafting example - and fill all five rows with a concrete example and a one-line mitigation for each.
Pick a use case. If you do not have one ready, use "an LLM drafts first-pass replies to customer support emails".
For each of the five risks - hallucination, bias, privacy, IP/copyright, security - write one concrete example of how it would show up in THIS use case.
Attach one mitigation per risk. Notice how often "a human reviews before it sends" is the honest answer - that is the cross-cutting control.
Flag the one risk that scares you most. That is the row your governance gate exists to catch.
Write the adoption memo ★ 6 min · everyone drafts
Using the self-study template, draft the one-page answer-first memo for your best use case. Recommendation first, then the six rows.
Open with the recommendation in one line - "we should pilot X using an API, with a human-review gate" - answer-first, like the Minto pyramid.
Fill the six rows: use case, doll, approach (prompt / RAG / fine-tune and build / buy / API), risks + mitigations, eval bar, owner + review.
If a row will not fill, say so in the memo - "data not yet accessible" is a finding, and it tells the decision-maker exactly what to fix first.
One volunteer reads their memo answer-first. The room grades the first sentence: could a busy executive decide from that line alone?
The memos that get funded are the ones a decision-maker can act on from the first sentence. "We recommend piloting AI reply-drafting for tier-1 tickets - API-based, human-reviewed, measured on handle-time" beats three pages of model detail. Answer-first is not a writing style, it is respect for the reader's time - and the fastest way to a yes.
This week ◐ 30 min total
- Score the whole list: run the scorecard on your entire Session 1 right-tool list. The greens are your pilot shortlist; the reds just saved you a wasted quarter each.
- Write one memo for real: take your best-scoring use case and write the one-page adoption memo, answer-first, all six rows.
- Share it with a decision-maker: the memo is only worth writing if it reaches someone who can say yes. Send it.
- Where next: this is the end of the literacy arc. Next steps are hands-on builder skills and your vendor's docs - and remember the data-literacy course sits underneath everything here. No clean data, no AI.
Three questions before you go 🎯 ◐ 90 seconds
1 · When should an organisation build its own AI models instead of calling an API?
Build only your genuine edge; a built model is a standing team and cost. For everything that is a feature, not the product, API-first ships faster and cheaper.
2 · Name a risk from the grid and its mitigation. Which pairing is correct?
Hallucination is fluent-but-wrong output; grounding it in real data plus citations plus a human check is the standard mitigation. Bias is caught by testing outcomes across groups, not by trusting intent.
3 · What separates real AI ROI from hype?
ROI shows up in repeatable shapes - augmenting costly time, messy input at scale, personalisation - and you can measure it. AI with no expensive-time answer and no eval is usually a sticker on something simpler.
Concepts covered & where they come from
The capstone pulls the whole arc together into decisions. Leaders get the three calls and the two artifacts; practitioners get the Self-study lane and the honest boundary of where literacy ends.