Ask a Better Question Before You Adopt AI

The first question is not what the system can do. It is what decision deserves assistance. This distinction matters because a demonstration can be impressive without being useful, and a useful capability can still be wrong for the decision at hand. Before discussing models, vendors, or automation, an institution should name the choice it is trying to improve, who currently makes it, and what a better result would mean.

Tool capacity, decision authority, and responsibility are different things. A system may classify documents, draft explanations, or notice patterns at a speed no team can match. None of those abilities decides whether a case should be approved, which error is tolerable, or who must answer when the result causes harm. Capacity belongs to the tool; responsibility remains with the institution. Treating those as separate design questions prevents technical possibility from quietly becoming policy.

Consider a hypothetical public-service team facing a growing queue of applications. Someone proposes AI to “solve the backlog.” That phrase conceals several possible problems: incomplete forms, inconsistent review, slow retrieval of records, or a shortage of people authorized to make the final decision. A drafting assistant might help reviewers explain missing information. A retrieval tool might surface the relevant rule. Automatic ranking, however, could amplify an unclear policy and make appeals harder. The same technology label covers very different interventions.

The team should therefore write a decision brief before a procurement brief. It can specify the affected people, the evidence required, the acceptable role of automation, and the point at which a human must intervene. It should also identify failure modes in ordinary language. What happens when information is missing? Can the person affected challenge the result? Will staff understand why a recommendation appeared? These questions turn an abstract ambition into an operating choice.

A useful pilot should clarify a decision before it accelerates a workflow. In the hypothetical queue, the smallest worthwhile experiment may be assistance with completeness checks rather than a model that predicts approval. The pilot could be time-limited, reviewed by the staff who use it, and compared with the existing process. Its purpose would be to learn where the tool helps, where it distracts, and which assumptions the team needs to revise.

This approach has limits. Some problems are urgent, some institutions lack clean process maps, and not every effect can be known in advance. Better questions do not remove uncertainty or guarantee a fair outcome. They make assumptions discussable and give people a basis for stopping, narrowing, or changing course. That is valuable precisely when a technology is moving faster than the institution’s shared understanding of it.

Before the next AI proposal advances, ask one actionable question: which specific decision will change, and who will remain accountable for that change? If the answer is vague, the work is not yet to select a system. It is to define the problem well enough that success, failure, and responsibility can be recognized.