Everyone is selling your organisation AI. Learn to judge it.

Every week, somewhere in a boardroom or procurement meeting, a leader approves an AI vendor on the strength of a confident sales deck, an impressive demo, and a reassuring set of certifications. Six months later, that same leader discovers the tool does not perform as expected on their actual data, that customer information has been used to train a model they do not control, and that switching would cost more in time and disruption than they would care to admit. The problem here is rarely a bad vendor. It is a due diligence process that has not caught up with the technology it is meant to evaluate. AI procurement is genuinely different from buying conventional software. The quality of an AI system is not fixed at the point of delivery; it can degrade silently over time. The data you feed it may have consequences you did not anticipate. The vendor's product may be a thin wrapper over a third-party foundation model, a large general-purpose AI system trained on broad datasets, that introduces its own risks and limitations. And as of 2026, the regulatory environment places increasing accountability on the organisations that deploy these tools, not just the companies that build them. This lesson gives you a structured checklist: three categories of scrutiny that separate good due diligence from the superficial kind.

Your organisation is evaluating a new AI system, perhaps a tool that screens job applications, flags performance issues, or forecasts staffing requirements. Someone sends you a document: the AI Impact Assessment. It runs to forty pages. Where do you even start? This lesson gives you a practical reader's map. An AI Impact Assessment, or AI IA, is a structured document that evaluates the risks, benefits, limitations, and organisational implications of deploying a specific AI system in a specific context. Think of it like a structural survey before buying a building. The surveyor does not decide whether you proceed; that is your call. But a good survey tells you precisely what you are taking on, what has been fixed, and what risk remains. Your signature on an AI IA carries the same weight: you are not endorsing the engineering, you are accepting the residual risk as described. AI IAs are fast becoming mandatory. The EU AI Act requires conformity assessments from providers of high-risk systems, including recruitment and performance-management tools, and fundamental rights impact assessments from certain deployers, chiefly public bodies, private organisations providing public services, and users of credit-scoring and insurance systems; even where no assessment is legally required, many organisations now mandate an AI IA as internal governance. The challenge for leaders is not locating the document. It is knowing what a good one looks like, what a thin one conceals, and what questions to ask before you sign.

For most of the past decade, artificial intelligence sat comfortably on the technology committee's agenda. It was a subject for the CTO to report on, interesting and occasionally concerning, but ultimately a technical matter. That framing is now a liability. As of 2026, AI is embedded in the operations of organisations across every sector: insurance underwriting, recruitment screening, supply-chain forecasting, customer service, and fraud detection. In many cases these systems make consequential decisions at scale, faster than any human could review, and the organisations deploying them carry legal and reputational accountability for what they do. This is not a technology story. It is a governance story. The analogy that tends to land in boardrooms is simple: no board processes payroll, but every board approves the financial controls framework that governs how payroll is processed. AI deserves the same logic. You do not need to understand how a large language model is trained in order to govern its deployment responsibly. You do need to understand what questions to ask, what risks to own, and what accountability structures your organisation must have in place. This lesson will not turn you into a data scientist. It will turn you into a more effective governor of organisations that use AI.

Every conversation about AI adoption eventually lands on the same question: where do we start? The better question, and the one far fewer leaders ask, is where do we stop. Knowing when not to use AI is one of the most valuable judgements a leader can develop. Not because AI is dangerous in some abstract sense, but because deploying it in the wrong context creates real risk: reputational damage, regulatory liability, and decisions that are worse than the ones your team would have made alone. With the EU AI Act's high-risk obligations due to apply from December 2027, the cost of a misjudged deployment is no longer just operational. It is legal. This lesson does not make the case against AI, which delivers genuine value across a wide range of leadership and organisational tasks. The case here is more specific: a well-calibrated sense of AI's limits is not scepticism, it is competence. The leaders who get the most out of AI are usually the ones who understand it clearly enough to know when to put it down. By the end you will have a practical framework for assessing proposed use cases, a sharper understanding of the psychological trap that makes human oversight harder than it sounds, and clear criteria for the categories of decision where AI should not be the primary input.

Every conversation about AI eventually arrives at the same question: where should we use it? The more useful question, and the one leaders rarely ask, is where should we not. The pressure to deploy is real, with boards asking for it and vendors promising transformation. Amid all of that, the frameworks for deciding when not to proceed get buried. That is a problem. A poorly chosen AI deployment does not just waste money; it can erode customer trust, invite regulatory scrutiny, and produce decisions that are wrong at scale in ways a human process never would have been. AI genuinely creates value in the right contexts, but it creates the most value when leaders can articulate why the specific situation suits it, not simply why deploying it feels overdue. That distinction separates organisations that use AI well from those that simply use it a lot. By the end of this lesson you will have a practical framework for deciding whether a proposed use case belongs in the go column. The four conditions we will explore are grounded in how AI systems actually work.