AI Washing, Wishing and Wasting: A Practical Path

“AI wishing, washing and wasting” describes three ways organizations can pursue artificial intelligence without getting dependable value: expecting too much, overstating what a system can do, or spending effort on tools that do not solve a real problem. A practical path starts with a specific task, tests whether AI helps, and measures results before expanding.

What wishing, washing and wasting mean

These terms are useful shorthand, not a formal technical standard. “Wishing” is treating AI as a cure-all: assuming a chatbot, prediction model or automation project will fix a difficult process simply because it uses a prominent technology. “Washing” is presenting ordinary software, limited automation or an unverified capability as more advanced or reliable than it is. “Wasting” is investing in development, licenses, data preparation or staff time without evidence that the system improves an outcome.

The three problems can reinforce one another. An ambitious promise may encourage a rushed purchase; weak evaluation then hides poor performance; and a deployment may continue because the organization has already spent money on it. Avoiding this cycle does not mean avoiding AI. It means treating it as one possible tool among several and requiring evidence proportionate to its impact.

Start with the work, not the technology

Choose a recurring task with a clear user, a recognizable pain point and an outcome that can be observed. For example, a support team might want to draft replies to routine questions, while staff review every draft. That is more testable than a broad goal such as “transform customer service with AI.”

Before selecting a system, map the current process: who does each step, what information is needed, where delays occur, and what errors matter. Then ask whether a simpler intervention—better search, a revised form, conventional software automation or clearer procedures—would solve the problem. AI is not automatically the best answer when rules are stable and inputs are structured.

Define the task narrowly, including what the system must not do.
Identify the people who use or are affected by the result.
Set a baseline, such as current handling time, error rate or review workload.
Choose a measurable target and a period for evaluating it.
Decide who can stop the trial if quality, privacy or cost becomes unacceptable.

Test capability against real examples

AI systems vary by task and can produce plausible but incorrect answers. A demonstration on a few easy examples is not proof of dependable performance. Build a representative test set from cases the organization is allowed to use, including ordinary inputs, edge cases and examples that should trigger refusal or escalation. Keep a separate set for evaluation where feasible, rather than repeatedly tuning the system against the same examples.

Compare AI-assisted work with the existing process. Evaluate not only whether the output looks polished, but whether it is correct, complete, useful and produced at an acceptable cost. For a drafting tool, useful measures might include how often staff accept a draft with minor edits, how often they must rewrite it, and whether important facts are omitted. For a classification system, examine errors by category, especially false positives and false negatives.

Human review is not a magic safeguard. Reviewers need enough time, relevant expertise and authority to reject an output. If staff are pressured to approve suggestions quickly, automation can shift work rather than reduce it. Record failures and near misses, then decide whether they arise from poor inputs, unclear instructions, unsuitable technology or a process that should not be automated.

Check data, privacy and security

Many AI applications depend on data supplied by users or connected systems. Confirm what information the tool receives, where it is processed, how long it is retained, who can access it and whether it may be used to improve a service. These details depend on the particular product and its configuration, so verify them in current documentation and applicable organizational policies rather than assuming all tools behave alike.

Use only data that is appropriate for the task and authorized for that use. Minimize personal or confidential information, restrict access, and test the system with synthetic or appropriately protected examples when that is sufficient. Consider whether outputs could reveal sensitive information or be manipulated by instructions embedded in material the system reads. A model’s response should not be treated as proof that its sources are trustworthy.

For consequential decisions—such as decisions affecting access, employment, eligibility or safety—set stronger controls and involve relevant legal, privacy, security and domain specialists. A general-purpose model should not quietly become the final decision-maker. Explain the system’s role to affected users, provide a route for human review, and retain records appropriate to the task.

Calculate the full cost and compare alternatives

The subscription or computing charge is only part of the cost. Include setup, integration, data cleaning, staff training, quality checks, ongoing monitoring, support and the time people spend correcting outputs. Also account for delays and operational disruption during a rollout. A tool that saves a few minutes per task may still be a poor investment if it adds review work or requires extensive maintenance.

Compare options using the same task and success measures. Alternatives may include leaving the process unchanged, improving documentation, using conventional rules-based automation, buying a specialized tool or building a custom system. Consider how easily the organization can export its data, change providers and maintain the workflow if the product changes or becomes unavailable. Avoid projecting savings from theoretical maximum performance; use observed results from a controlled trial.

Scale only when evidence supports it

A successful pilot is a reason to examine expansion, not an automatic reason to deploy everywhere. Results can change when users, topics, languages, data quality or workload change. Repeat evaluation in the intended setting and define monitoring for performance drift, cost, errors and user feedback. Assign an owner who can investigate problems and pause or roll back the system.

Document the system’s purpose, limitations, approved inputs, review responsibilities and escalation route. Train users to distinguish suggestions from verified facts and to report recurring failures. Revisit the decision when the task, vendor, model or data changes. If the tool does not meet the original target, stop or redesign the trial rather than widening its scope to make the investment appear successful.

Frequently Asked Questions

What is AI washing?
AI washing is overstating or misrepresenting how much a product or service relies on AI, or implying capabilities that have not been demonstrated. Check what the system actually does and look for task-specific evidence, not just marketing language.

How can a company tell whether an AI project is worth doing?
Define a real task, establish a baseline, set measurable success and failure criteria, and compare results with the current process and simpler alternatives. Include operating and review costs, not only software fees.

Does human review make AI outputs safe?
No. Review helps only when reviewers have relevant knowledge, enough time and authority to correct or reject outputs. Important decisions may require additional controls, independent checks and a clear appeal or escalation process.

Should an organization build its own AI system?
Not by default. Compare a custom system with existing tools and non-AI options, considering data requirements, integration, maintenance, control and total cost. Build only when a specific need justifies the added work and risk.

When should an AI pilot be stopped?
Stop or redesign it if it misses predefined quality or cost targets, creates unacceptable privacy or security concerns, shifts too much work to reviewers, or cannot be monitored reliably. A pilot is useful even when it shows that AI is not the right solution.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →