The Pros and Cons of AI: An Executive Decision Ledger, Not a Listicle

Halfway through a portfolio review with a manufacturing client last year, the COO put a slide on the screen that I have now seen, in some form, in a dozen boardrooms. Two columns. On the left, the advantages of AI: productivity, speed, cost reduction, 24/7 availability, consistency, scale. On the right, the disadvantages: cost, bias, job displacement, security, regulatory burden, loss of control. Twelve items, neatly balanced, the kind of slide a competent analyst produces in an afternoon. The COO asked the room whether, on balance, the company should be doing more AI or less. The question is the one the slide was built to answer, and it is the wrong question, because the slide is the wrong instrument.

The pros-and-cons list is the wrong tool for an AI decision for a structural reason: it implies a symmetry that does not exist. A two-column layout invites you to weigh the left against the right as if they were the same kind of thing measured on the same scale. They are not. The productivity benefit on the left accrues to an operating team, in unit-cost terms, starting in year two. The regulatory burden on the right lands on the general counsel, in licence-to-operate terms, starting whenever the enforcement calendar says so. These do not net. Summing them into an “on balance” verdict is the analytical equivalent of adding a temperature to a distance and asking which is bigger.

I am writing this page because “pros and cons of ai” and “advantages and disadvantages of ai” are among the most-searched framings of the AI decision, and the content that serves them is almost entirely the symmetric-listicle form that misleads the decision-maker who acts on it. The honest version is not a longer list. It is a different instrument — a ledger that keeps the benefits and the costs on their own terms, names where each lands, and replaces the “on balance” verdict with the per-application judgement the decision actually requires.

The pros are real, and they are narrower than the slide suggests

AI’s genuine advantages are not in dispute, and I will not pretend they are. Where the conditions are right, the productivity case is real and frequently understated by the people most sceptical of the hype. The error is not in claiming the benefits; it is in claiming them for the wrong applications.

The benefits cluster on a specific kind of work: high volume, clear evaluation criteria, and tolerance for a known error rate. Document processing, code assistance, first-line support triage, structured extraction from unstructured data, content drafting under human review. The common thread is that the work is repetitive enough to amortise the build cost over many uses, measurable enough that you can tell whether the system is actually working, and forgiving enough that an occasional wrong answer is a managed cost rather than a catastrophe. Code assistance is the cleanest example in 2026 — the productivity gain for experienced engineers on well-scoped tasks is large, measurable, and durable, because the engineer is the evaluation layer that catches the model’s errors before they ship.

The mechanism behind the real benefit is leverage on volume, not magic on judgement. AI is good at doing a moderately hard thing ten thousand times at near-constant marginal cost, which is exactly the shape of work that is expensive to staff and tedious to do. That is a genuine and large advantage. It is also a narrower advantage than “AI improves productivity” implies, because it holds only where the three conditions hold together. The slide’s left column lists the benefits as if they were properties of AI in general. They are properties of AI applied to a particular class of work, and the strategy discipline is to find that class rather than to assume the whole organisation is it.

The cons are real, and they are asymmetric to the pros

The disadvantages are equally real, and the reason they cannot be netted against the benefits is that they live on different axes. A benefit is a recurring gain on a unit cost. A cost is sometimes a recurring expense, sometimes a one-time catastrophe, sometimes a slow-building exposure that is invisible until it is not. Putting both in a balanced list hides the difference that matters most: the costs have a tail the benefits do not.

The recurring expense is the unit economics, and it is more volatile than most business cases assume. The cost-per-call figure that justified an application is a snapshot of a fast-moving pricing market and will be a different number within a year. The catastrophe is the confident wrong answer in a high-stakes context — the failure that converts a capability problem into a reputational event. The slow-building exposure is regulatory and dependency risk, which accrue quietly while the system works and surface when a provider deprecates a model or an enforcement deadline arrives. I have written the full taxonomy of these as the risks of AI — six categories, each with an owner and an exposure — because “the cons of AI” deserves more than a column of nouns. The point for this ledger is that the cons are heterogeneous in a way the pros are not, and a balanced list flattens that heterogeneity into a false equivalence.

The funding mistake this produces is specific and common. Executives apply AI to the flagship, customer-facing, judgement-heavy decision precisely because it is visible and strategic — and that is the application where the costs are catastrophic-tailed and the benefits are least certain. The defensible early applications are the unglamorous high-volume back-office tasks where the benefit is real and the downside is bounded. Visibility and suitability are inversely correlated more often than the strategy deck assumes. The most-funded pilots are frequently the least likely to survive production, and the cost of those failures is itemisable: customer-facing generative work fails against its original business case at roughly 70%, infrastructure-facing AI at roughly 30%. Same technology, opposite odds, because the applications sit on opposite ends of the suitability axis.

Why “on balance” is the wrong verdict

The COO’s question — more AI or less, on balance — cannot be answered at the level it was asked, and the attempt to answer it is where strategy goes wrong. “AI” is not a single investment with a single risk-return profile; it is a method applicable to thousands of distinct tasks, each with its own benefit magnitude, cost trajectory, and downside. Asking whether AI’s pros outweigh its cons is like asking whether software’s pros outweigh its cons. The honest answer is that it depends entirely on what you build, and the question that produces value is the per-application one.

The mechanism that makes the portfolio view necessary is that the benefits and costs are not just asymmetric in kind but independent in distribution. A high-benefit application can be low-cost and low-risk (back-office document processing) or high-cost and high-risk (autonomous customer-facing decisioning). The two-column slide cannot represent this, because it has already aggregated across applications before the analysis begins. By the time the pros and cons are on the slide, the information that would have made the decision — which applications, with which profiles — has been averaged away. The slide is not a simplification of the decision; it is a deletion of it.

This is why the strategy work is application-level triage, not a balance-sheet verdict. The output of a good AI strategy is not “we are pro-AI” or “we are cautious on AI”; it is a ranked list of specific applications, each scored on benefit, cost, and downside, with the marginal ones named as marginal and owned by a named executive. An organisation can be aggressive on the high-benefit bounded-downside tier and conservative on the catastrophic-tail tier at the same time, and that combination is not a contradiction — it is the correct posture, and the two-column slide makes it impossible to express.

The ledger that replaces the list

The instrument I use in place of the pros-and-cons slide scores each candidate application on three axes, kept separate rather than summed. The first is benefit magnitude and timing: how large is the gain, how soon does it accrue, and how certain is it. The second is cost and its volatility: the build cost plus the model-pricing exposure that moves over the application’s life. The third is downside and ownership: which risk category bites if it fails, how large the exposure is, and which executive is accountable for it.

An application that scores well on all three is a clear yes, and the strategy should move fast on it — these are the under-funded back-office wins that get passed over for the flagship. An application that scores badly on all three is a clear no, however strategically appealing it looks on a slide. The judgement work — the actual work — is the middle, where you are accepting a real cost or a real downside for a real benefit, and the discipline is to make that trade explicit and to name the owner of the residual risk rather than letting it sit unassigned in a column. A trade that is named and owned is governable. A trade that is averaged into an “on balance” verdict is not.

The ledger also handles timing, which the symmetric list cannot. Benefits and costs that arrive in different years should be discounted differently and owned by whoever holds the relevant year’s P&L. A benefit in year two and a cost in year three are not contemporaneous and should not be weighed as if they were. The framework hub holds the diagnostic structure for scoring applications against posture, cost ceiling, timeline pressure, and failure tolerance; this ledger is the input to it — the honest accounting of what AI gives and takes, kept on terms that do not pretend the two are the same currency.

What I would do on Monday morning

If someone hands you a pros-and-cons slide and asks for an on-balance decision, decline the framing rather than the request. Ask instead for the three or four specific applications under consideration, and score each on benefit, cost, and downside separately. The conversation will get harder and shorter at the same time, because most of the disagreement that lives in the abstract “more or less AI” debate dissolves once the question is “this application, with this profile.” People who disagree about AI in general frequently agree about a specific application once its three axes are on the table.

If you are writing the strategy rather than defending it, build the application ledger before you write the narrative. The narrative — the posture, the principles, the board-facing story — should be the conclusion that falls out of the ledger, not the premise that justifies it. A strategy whose pro-AI or cautious-AI stance was decided before the applications were scored is a strategy that will fund the wrong tier, because the stance will pull the application choices toward consistency with itself. Score first, conclude second. The honest version of the pros and cons of AI is not a balanced list; it is a ranked ledger of specific bets, each with its benefit, its cost, and the name of the person who owns the downside.

---

Sources & methodology

• NIST AI Risk Management Framework, v1.0 — the public-domain reference for the downside-categorisation discipline behind the third axis of the ledger
• Stanford HAI AI Index — the public source for industry-level adoption and productivity-gain ranges referenced in the benefits section
• EU AI Act, Regulation (EU) 2024/1689 — the regulatory anchor for the slow-building-exposure class of cost
• Methodology: the per-cluster benefit and failure ranges, the suitability-versus-visibility observation, and the three-axis scoring approach are drawn from approximately forty enterprise AI programmes audited or run between 2023 and 2026, anonymised. Figures are medians from mid-sized European enterprise engagements and will differ by geography and sector.

If your decision involves an application whose profile this ledger does not obviously fit, send it and I will work the three axes with you.