6.1 AI strategy and readiness¶

Overview and motivation¶

Artificial intelligence has gone from research novelty to a core capability that large organizations are now expected to deploy responsibly and at scale. For enterprises and government agencies, the real question is no longer whether AI can do something impressive in a demo. It is whether a specific investment solves a real problem better than the alternatives, can be operated safely for years, and can survive audit, procurement, and public scrutiny. AI strategy is the discipline of deciding where to apply AI, where to avoid it, and what foundations you need before the first model reaches production.

For large teams, scale and inertia raise the stakes. A poorly framed initiative can burn budgets, distract talented engineers, and erode trust with regulators and citizens when it fails in public. A well-chosen one can automate drudgery, surface insight from data you could never reach before, and free skilled people for higher-value work. The difference is rarely the model itself. It comes down to how well you frame the problem, how ready your data and talent are, and how honest your business case is.

Government and regulated contexts add more constraints. Public bodies must justify spending, guarantee transparency, avoid unlawful discrimination, and stay accountable to elected officials and the public. Procurement rules may forbid sole-source lock-in, demand explainability, and require that vendors expose model behavior. Here, treat compliance, auditability, and exit options as first-class requirements, not afterthoughts.

Key principles¶

• Start from a problem worth solving, not from a technology looking for a use.
• Prefer the simplest approach that meets the need; AI is one option among many, and often not the best.
• Treat data readiness, talent, and platform maturity as prerequisites, not parallel work streams to sort out later.
• Make build-versus-buy decisions explicitly and revisit them as the market and your capabilities change.
• Quantify the total cost of ownership, including operation, monitoring, and eventual replacement, not just the license or the pilot.
• Design for exit from day one: avoid architectures that make switching vendors or models prohibitively expensive.
• In regulated and public settings, treat transparency, procurement compliance, and accountability as design constraints.
• Measure the cost of not acting alongside the cost of acting.

Recommendations¶

Frame the problem before choosing a technology¶

Write a one-page problem statement. Name the decision or task you want to improve, the current baseline, the measurable outcome you want, and what happens when the system gets it wrong. Then ask whether the problem even suits AI. Is there enough relevant data? Is the task pattern-based rather than rule-based? Can you tolerate probabilistic answers? Can a human check the output? Many problems are better solved with deterministic software, better process design, or simply better data hygiene. Write down explicitly where AI is not a good fit: for example, decisions that must be perfectly explainable by law, or where the cost of a rare error is catastrophic and impossible to catch.

Use a build-versus-buy-versus-fine-tune-versus-prompt decision tree¶

Move from cheapest and fastest to most expensive and most controlled:

1. Prompt an existing hosted model. If a general-purpose model (such as Anthropic's Claude, or comparable offerings from other providers) solves the problem with careful prompting and retrieval, do that first. Lowest cost, fastest iteration, no training infrastructure.
2. Augment with retrieval or tools. If the gap is knowledge or actions, add retrieval-augmented generation (RAG), which fetches relevant documents at query time and supplies them to the model as context, and tool use before touching model weights.
3. Fine-tune or adapt. If prompting cannot achieve the needed accuracy, tone, or format consistently, fine-tune a smaller model on your data: that is, further-train a pretrained model on your examples to specialize it. This buys control at the cost of an MLOps (machine learning operations) pipeline.
4. Buy a specialized product. For well-defined domains (document processing, fraud scoring), a mature vendor product may beat anything you build.
5. Build from scratch. Reserve training foundation models (large models pretrained on broad data and adaptable to many tasks) for organizations with unique data, deep talent, and strategic reasons. For almost all enterprises and agencies, this is the wrong choice.

Establish data, talent, and platform prerequisites¶

Audit your data for availability, quality, labeling, lineage, and legal basis for use. Confirm you actually have the right to use it for AI, including any personal or third-party data. Assess talent honestly: you need data scientists, and also ML engineers, data engineers, product managers who understand probabilistic systems, and reviewers who can evaluate outputs. Before you scale, stand up a platform baseline: experiment tracking, a model registry (the system of record for trained model versions and their approval status), monitoring, and secure serving, so each new use case does not reinvent operations.

Handle regulated and government contexts deliberately¶

Bring in procurement, legal, and risk teams early. Require vendors to disclose model provenance, training-data practices, evaluation results, and known limitations. Prefer contracts that grant portability of your data and prompts, and avoid proprietary formats that trap you. Where appropriate, publish the purpose and safeguards of public-facing AI systems, and give people a channel to contest automated decisions. Align to recognized frameworks (see chapter 6.5) so audits find a documented, defensible process.

Compute total cost of ownership and guard against lock-in¶

Model the full lifecycle cost: inference or licensing, data pipelines, human review, monitoring, retraining, incident response, and decommissioning. Compare it to the cost of the status quo and of the alternatives. Reduce lock-in by putting the model behind an internal interface, keeping prompts and evaluation datasets portable, and testing a second provider from time to time.

Trade-offs: pros and cons¶

The dominant trade-off is control versus cost and speed. Prompting gives you the most speed and flexibility but the least control; building gives you the most control but demands resources few organizations should spend. Most large teams should live in the middle: prompt and retrieve first, fine-tune selectively, and buy for commodity needs. Lock-in trades short-term convenience for long-term risk, and that matters especially in government, where multi-year exit obligations are common.

Examples¶

Startup. A five-person scheduling startup wanted to add a natural-language "book me a meeting" feature without pulling its two engineers off the core product. It picked the smallest problem that mattered, parsing a request into a proposed time, and shipped it with a hosted model behind a thin internal API so it could switch providers later. The team set a hard monthly spend cap, tracked whether users accepted the suggested times, and agreed to revisit a fine-tuned model only if volume ever justified the extra work.

Enterprise. A multinational insurer wanted to speed up claims triage. Instead of training a bespoke model, it framed the problem narrowly (route and summarize incoming claims), prototyped with a hosted model plus retrieval over its policy documents, and measured against human handling time and accuracy. Only after proving value did it fine-tune a smaller model for the highest-volume claim type to cut per-call cost. It kept the model behind an internal API so it could swap providers, and it modeled a three-year TCO that included human review of low-confidence cases.

Government. A national tax authority considered an AI assistant to help staff answer citizen queries. Because those answers touched legal obligations, the agency insisted on transparency: the system could only surface official guidance with citations, never invent policy, and a human reviewed every automated suggestion before it went out. Procurement required the vendor to disclose model limitations and grant data portability, and the agency published a plain-language description of the system and an appeals route. It kept AI out of final assessment decisions entirely, reserving those for accountable officers.

Business case: motivations, ROI, and TCO¶

AI strategy exists to help you avoid two mirror-image failures: over-investing in AI that never pays off, and under-investing while competitors or peer agencies pull ahead. ROI comes from labor saved, cycle time reduced, error rates lowered, and new capabilities enabled. Measure these against a genuine baseline, and discount for the real cost of human oversight, which rarely disappears.

TCO has to include the unglamorous line items: data pipelines, monitoring, retraining as the world drifts, security review, and eventual decommissioning. A pilot that looks cheap can turn expensive once it runs at scale for years. Present the cost of not adopting too: slower service, higher manual cost, and strategic drift. Make the case to leadership with a portfolio view: a few high-confidence bets, clear success metrics, kill criteria for failures, and a readiness assessment showing that data and talent foundations exist. Ask leaders to fund readiness explicitly; skip it, and you guarantee expensive rework.

Anti-patterns and pitfalls¶

• Solution in search of a problem. Buying AI because peers did, then hunting for a use case.
• Skipping data readiness. Launching models on data that is unavailable, unlabeled, or legally unusable.
• Demo-driven decisions. Committing based on a polished demo without a production-quality evaluation.
• Ignoring the human loop. Assuming full automation and under-budgeting review, which is where most cost hides.
• Silent lock-in. Building deeply on one vendor's proprietary features with no exit plan.
• Underestimating operations. Treating deployment as the finish line rather than the start of a maintenance obligation.
• Compliance as an afterthought. Retrofitting transparency and auditability after design, at multiples of the cost.

Maturity model¶

1. Initial. Ad hoc experiments, no shared strategy, decisions driven by hype and individual enthusiasm.
2. Developing. Problem framing exists for some projects; a first platform baseline appears; build-versus-buy is discussed but inconsistent.
3. Defined. A portfolio of AI use cases with clear metrics, a documented decision tree, readiness assessments, and lock-in and TCO analysis for each.
4. Optimizing. AI strategy is integrated with business and risk planning; readiness is continuously maintained; the organization routinely retires, replaces, and re-scopes AI systems based on evidence.

Ideas for discussion¶

• How do you decide when a problem is genuinely unsuited to AI, and who has authority to say no?
• What readiness threshold should gate a project from pilot to production?
• How much lock-in is acceptable in exchange for faster time to value?
• In government, how should transparency obligations shape the build-versus-buy choice?
• How do you keep TCO estimates honest when vendors and enthusiasts have incentives to understate them?
• Who owns the AI portfolio, and how are kill decisions made?

Key takeaways¶

• Strategy starts with a real problem and an honest baseline, not with a technology.
• Prefer the simplest option: prompt, then retrieve, then fine-tune, then buy, and rarely build from scratch.
• Data, talent, and platform readiness are prerequisites; funding them is part of the plan.
• Regulated and government contexts require transparency, procurement compliance, and exit options by design.
• Model full TCO and the cost of inaction, and guard against vendor lock-in from the first architecture decision.

References and further reading¶

• Ajay Agrawal, Joshua Gans, and Avi Goldfarb, Prediction Machines: The Simple Economics of Artificial Intelligence.
• Eric Siegel, The AI Playbook: Mastering the Rare Art of Machine Learning Deployment.
• Andriy Burkov, The Hundred-Page Machine Learning Book.
• National Institute of Standards and Technology, AI Risk Management Framework (AI RMF 1.0).
• Organisation for Economic Co-operation and Development, OECD AI Principles.
• Thomas H. Davenport, The AI Advantage: How to Put the Artificial Intelligence Revolution to Work.