MODULE 1 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolWhat You Are Actually Accountable For
The finding that defines this course
In July 2025, MIT's Project NANDA published The GenAI Divide: State of AI in Business 2025. Its headline was uncomfortable: despite something in the range of $30–40 billion of enterprise investment, roughly 95% of generative AI projects were producing no measurable business return. A small minority — around 5% — were extracting substantial value.
Treat the exact number with care. The report has been publicly criticised over its methodology, and secondary accounts of that methodology disagree with each other on the details; what is consistently described is a mix of interviews with leaders, a survey of employees, and an analysis of a few hundred publicly disclosed deployments. A contested statistic is still worth knowing, provided you know it is contested.
What matters more than the number is the stated cause, because it is not the one most people assume. The failures were not attributed to weak models, missing talent, insufficient infrastructure or regulation. They were attributed to a learning and integration gap: tools that never entered the workflow they were bought to change.
Read that again, because it is this course's entire thesis. The models mostly work. The projects mostly fail. What fails is everything between the model and the work — and almost all of that is a manager's responsibility rather than an engineer's.
The division of accountability
A useful way to hold it:
Notice the shape. The technical team owns how well the thing works. You own whether working changes anything.
That distinction explains the MIT finding. A pilot can succeed entirely on the technical team's terms — the model hits its accuracy target — and produce nothing, because the output never reached the workflow, or reached it in a form nobody could act on, or reached people who did not trust it.
The decisions that are yours
Six, and they are worth securing explicitly before work begins rather than discovering later that nobody owns them.
1. The problem. Not "we should use AI" but a named task, done by named people, a known number of times a week.
2. The threshold. What performance makes this worth deploying. Agreed in advance, in writing, with the metric named — because "accuracy" is frequently the wrong metric and the choice between competing errors is a business judgement.
3. The exception path. What happens to cases the system cannot handle, and who handles them. This is a resourcing decision and it is invariably yours.
4. The trade-off between error types. Whether missing one fraudulent claim is worse than wrongly flagging fifty legitimate ones. No technical team can decide this for you, and if you do not decide it, it gets decided by default.
5. Adoption. Whether the people whose work changes will use it, and what you are doing to make that true.
6. The stop decision. Under what conditions you would end it. Set this early, while it is still cheap to be objective.
Accountability does not transfer to a vendor
One thing that repeatedly surprises managers: buying a system does not move the accountability. If an AI tool your team deployed produces a discriminatory outcome, a customer harmed by a confident falsehood, or a regulatory breach, the answer "the vendor's model did it" satisfies nobody — not your customer, not your regulator, and increasingly not the law.
This is not an argument against buying. Module 5 will make the case that buying is usually right. It is an argument for buying with your eyes open, and for the governance module later in this course.
Take any AI proposal on your desk and draw two columns.
Left column: what the technology must do. "Extract the invoice total with 98% accuracy." "Classify the ticket into the right queue." "Draft a reply the agent would send with minor edits."
Right column: what must be true for that to matter. This is the column that gets left blank, and it is where projects die. It typically contains things like:
- The extracted total has to land in the finance system automatically, not in a spreadsheet somebody re-keys.
- The person receiving the classification has to see it inside the tool they already have open, not in a separate dashboard.
- Someone must have decided what happens to the 2% it gets wrong, and staffed it.
- The finance team must trust it enough to stop double-checking, or the saving is zero — you have added a step, not removed one.
- Somebody must own it in twelve months when the invoice layouts change.
Now count. If the left column has three items and the right column has eleven, you are looking at a project that is mostly not a technology project — and the right column is entirely yours.
This exercise takes twenty minutes and it is the highest-return thing in this module. It will also tell you, quite often, that the correct next step is not to build anything, but to fix the thing in the right column that would have blocked it anyway.
A pilot hits its accuracy target and is declared a technical success, but six months later nothing about the business has changed. According to the MIT NANDA report's stated cause, what most likely went wrong?
The GenAI Divide finding
Click to flipMIT Project NANDA, July 2025. Around 95% of generative AI projects were producing no measurable business return against $30–40bn of enterprise investment, with roughly 5% extracting substantial value. The figure is contested; the stated cause — a learning and integration gap rather than model quality — is the durable part.
Click to flip backMost AI pilots produce nothing, and the reported cause is not weak models but tools that never entered the workflow they were bought to change — which is a management failure, not an engineering one. The technical team owns how well the system works; you own whether that changes anything. Secure six decisions before work starts: the problem, the threshold, the exception path, the error trade-off, adoption, and the conditions under which you would stop.