A common standoff happens when companies start discussing artificial intelligence.
Business leaders ask IT what the organization should be doing with AI. IT asks the business which problem it wants to solve. Both questions make sense, but the conversation often ends there.
IT may experiment with a few tools or build a demonstration. Managers attend the presentation and agree that the technology looks promising. Then everyone returns to their usual priorities. Nobody has committed to changing an actual business process, so the demonstration stays a demonstration.
This helps explain why so many machine-learning projects fail to reach production. The technology may work perfectly well. The organization simply hasn't worked through how it will be used.
Where responsibility gets lost
IT can assess platforms, security, architecture, integrations, and data access. It can explain what a model or automation is capable of doing.
It can't independently decide which customer problem matters most, how much an operational delay costs, what kind of error the business can tolerate, or how employees should respond when the system gets something wrong.
Managers understand those questions because they understand the operation. What they may not understand is where AI fits. They hear terms such as machine learning, predictive models, agents, and generative AI without a practical sense of what each one can accomplish.
That leaves a gap. IT waits for business direction while the business waits for IT to recommend a use case. A pilot may still get built, but it has no committed owner and no clear route into daily work.
Leaders need some working knowledge
Managers don't need to learn how to train a model. They do need enough knowledge to participate in the decisions that will determine whether the project succeeds.
A predictive model produces an estimate rather than a fact. A customer identified as likely to leave hasn't necessarily decided to leave. A transaction flagged as suspicious isn't automatically fraudulent.
Generative AI has its own limitations. It can produce a convincing answer that is incomplete or wrong. It might summarize the wrong document, miss an exception, or sound more confident than the available evidence supports.
Managers need to understand these characteristics because they affect how the process should work. Some results can be acted on automatically. Others should be reviewed by an experienced employee. The right choice depends on the business consequences of a mistake.
Dirty hands prevent cold feet
Eric Siegel, author of The AI Playbook, describes the problem well: "The stakeholders who have not gotten their hands dirty … get cold feet." (Deloitte AI Institute interview)
The hesitation often appears when a pilot is ready to become operational. Until that point, the project has been interesting and relatively safe. Moving into production means using real customer information, changing employee responsibilities, connecting business systems, and accepting accountability for the results.
A manager who only saw the occasional presentation may not feel ready to approve that change. A manager who helped define and test the use case is better prepared. They understand what the system produces, how employees will use the result, where human judgment remains necessary, and how performance will be measured.
Getting involved doesn't guarantee approval. It makes approval or rejection an informed decision.
Start with the business operation
Siegel's The AI Playbook treats machine learning as a business practice rather than a technology installation. His approach begins with deployment and requires business and data professionals to work through the project together. (MIT Press overview of The AI Playbook)
A project to implement machine learning has no useful destination. A project to reduce preventable customer cancellations, identify incomplete applications, or shorten contract-review time does.
Consider a model intended to identify customers who might leave. The model is only one part of the solution. Someone must decide which customers should be evaluated, what counts as a likely departure, who will respond to the prediction, and what that employee is allowed to offer.
These decisions shape the model and the process around it. Leaving them until the technical work is finished almost guarantees delays.
The questions managers should ask
A useful conversation can begin with a few straightforward questions.
What exactly will the system produce? "Predict customer churn" is too broad. The team needs to agree on which customers, which behaviour, and which period it is trying to predict.
What information will the system use? The required data may be incomplete, inconsistent, or restricted. People who work with it every day will often know about problems that aren't visible in a database diagram.
What will happen after the result appears? A prediction, summary, or recommendation has no value unless it changes an action.
What happens when it is wrong? An awkward internal summary carries little risk. An incorrect price, contract clause, or customer decision could be expensive.
How will the business measure improvement? Model accuracy matters, but it doesn't prove that the operation got better. The useful measures may be reduced processing time, fewer missed renewals, faster response, lower rework, or improved conversion.
IT needs business stakeholders to answer these questions. Business stakeholders need IT to explain what is technically realistic and where the risks lie.
Use the pilot to learn together
A pilot should answer a specific question rather than provide a general display of AI's capabilities.
Can the system find the correct information? Can it recognize the cases that matter? Will employees understand the recommendation? Does it still save time after review and correction are included?
Managers and frontline employees should participate in that testing. They should challenge the output and bring forward unusual cases. Those cases reveal how the real process differs from the official one and where additional controls may be needed.
The goal isn't to prove that the technology never makes mistakes. It is to understand the mistakes well enough to decide whether the resulting process can be trusted.
A useful place to start
Choose one workflow the business already wants to improve. Bring together a manager, an experienced employee, and someone from the technology team.
Map what happens today, including the searches, handoffs, approvals, spreadsheets, and delays. Identify one point where prediction, summarization, classification, or information retrieval might help.
Define what the system should produce and what an employee will do with the result. Discuss the cost of a mistake and choose one business measure that should improve.
Then build the smallest pilot capable of testing those assumptions. Use representative information and include the difficult examples. Review the results as a group and record what employees accept, change, or reject.
Business leaders don't need to understand every line of code. They need enough understanding to make decisions, challenge assumptions, and take responsibility for the outcome. When the business and technology teams do that work together, a promising experiment has a much better chance of becoming something useful.