Before We Ask What AI Can Do

A convincing AI demonstration can rearrange a roadmap in an afternoon. A model turns an untidy document into a polished summary, responds fluently to a specialist question or classifies examples that once required manual review. The immediate reaction is understandable: where can we put this?

That question begins with the tool and searches for a destination. It can produce useful experiments, but it is a weak basis for consequential systems. Fluency makes capability feel like purpose, and soon the project is measured by whether the model can perform a task rather than whether the task should change.

Direction begins earlier. What outcome deserves attention? Perhaps clinicians spend too much time locating information across disconnected systems. Perhaps residents cannot understand the status of a public application. Perhaps a support team repeatedly answers questions caused by unclear product design. Each situation contains a real need, but none automatically calls for AI.

Once the desired change is explicit, alternatives become visible. Better search may help clinicians more reliably than generated summaries. A clear status page may serve residents better than a conversational assistant. Fixing the product may reduce support demand more effectively than automating replies. A spreadsheet, a rules engine or an additional colleague can sometimes outperform a model when cost, risk and maintenance are counted.

This comparison is not anti-AI. It protects AI for problems where its distinctive qualities matter: working with varied language, helping people explore large bodies of material, supporting creative iteration or identifying patterns whose boundaries cannot be fully specified in advance. Purpose makes it easier to see those opportunities clearly.

It also improves evaluation. “The model produced a plausible answer” is not an outcome. If the purpose is to help staff find policy information, evaluation should include whether they reach the correct source, how long it takes, whether uncertainty is visible and what happens when the source changes. If the purpose is to make a service more accessible, the team must involve people with different access needs and test the entire journey, not only the generated text.

The people affected should influence the definition of success. An automation that saves an organisation time by transferring correction work to customers is not necessarily efficient. A tool that raises average productivity while making unusual cases harder to resolve may harm those who already struggle to be heard. An assistant that appears friendly but prevents access to a person can turn conversational design into a barrier.

Environmental and operational consequences belong in the direction too. Model size, request volume, data movement and hardware requirements affect resource use. A project can set a performance and energy budget before implementation, then test whether a smaller model, retrieval method or conventional feature meets the need. The point is not to calculate a perfect footprint. It is to prevent technical abundance from making consumption invisible.

Governance becomes more practical when tied to purpose. Instead of a generic principle that humans should remain in control, a service can specify which decisions require human judgement, what information the reviewer receives and whether they have enough time and authority to disagree. Instead of promising transparency, it can tell a user when generated material is present, link to relevant sources and provide a route to challenge an outcome.

A short project charter can hold these choices together. It should state the intended improvement, affected groups, rejected simpler options, key risks, evaluation method and stopping condition. The document will not settle every ethical question. It gives the team a shared reference when an impressive demonstration, a vendor promise or delivery pressure threatens to move the project away from its original purpose.

Finally, direction gives a project an exit. If evidence shows that the tool does not improve the chosen outcome, the team can stop without declaring the technology a failure. The model may be capable and still be wrong for this setting. A defined purpose allows that distinction.

The question “What can AI do?” remains valuable. It opens imagination and reveals unfamiliar possibilities. It simply should not carry the whole decision. Follow it with harder questions: What should improve? For whom? At whose cost? What would count as evidence? What simpler paths exist? What must remain possible if the system is wrong?

Capability opens the door. Direction decides whether walking through it leads somewhere worth going.