Over the last couple of years we have had hundreds of conversations with leaders trying to figure out what to do about AI in their business. The companies are different. The industries are different. The technical sophistication is different. But the questions are remarkably consistent. The same ten or so themes come up in almost every first conversation, and the quality of the answers usually shapes whether the company makes good early decisions or wastes a year on the wrong things.
The list below is the questions we hear most often, with the answers we actually give. It is not a sales pitch. The honest version of these answers is more useful than the polished version, both because business leaders can tell the difference and because the wrong answer to any of these questions tends to be expensive.
1. Where Should We Start With AI?
This is by far the most common opening question, and the answer almost never starts with technology. The right place to start is with a small number of real internal use cases where the people doing the work can describe a specific time consuming task in detail. Customer support summaries, sales call notes, contract review, marketing drafts, internal knowledge search, and routine data analysis are the usual candidates. They share three properties. The work is language or data heavy. The output is mostly used internally so the cost of an occasional error is bounded. The current process is well understood, which makes the AI version testable.
The wrong place to start is with a flagship customer facing product or a board level transformation initiative. Those have their place, but they are not where the first wins come from. The first wins come from giving a small team a tool that makes a clearly defined part of their week noticeably faster, then learning from what happens when they actually use it.
2. How Much Will This Cost?
The honest answer is that it depends, and not in the evasive consulting sense. The cost varies by two or three orders of magnitude depending on what you are doing.
A simple AI assistant built on existing tools, used by a small team, can be live in a few weeks for a few thousand dollars in subscriptions and a modest amount of internal time. A custom internal tool that wraps a general purpose model with your own data and processes typically lands somewhere between fifty and two hundred and fifty thousand dollars for the first version. A production system that processes customer facing transactions at scale, with the surrounding work on evaluation, monitoring, and change management, can run into the millions. These ranges vary materially with the readiness of your data, the scope of compliance requirements, and the depth of integration with existing systems.
The cost question is almost always the wrong question on its own. The right question is what the expected return looks like at each scale, and which scale is appropriate for the problem at hand. We usually push hard to start at the smaller end and earn the right to the larger ones rather than the reverse.
3. What Is the ROI, and How Soon Will We See It?
Return on a well chosen AI project comes from a small number of patterns. Time saved on routine work that previously consumed expensive staff hours. Faster cycle times that translate into more deals closed, more support tickets resolved, or more content produced. Higher quality output in places where quality directly affects revenue or retention. Reduced cost of error in processes where mistakes were previously expensive. Occasionally, a genuinely new capability that the business could not previously offer at all.
For internal productivity work, we typically see measurable hours saved within the first sixty days of a focused rollout when the use case is well chosen and the team actually adopts the tool. For customer facing improvements, the timeline is usually three to six months because the surrounding process work takes longer than the build. For more ambitious projects, the first year is often about learning and the larger return shows up in years two and three. Actual timing depends on data readiness, integration depth, and the level of change management investment.
The pattern we warn against is the case where the return is calculated in a spreadsheet using optimistic assumptions and then never measured against reality. The disciplined version is to define a small number of metrics up front, measure a baseline before the project starts, and review the actual delta on a regular cadence. The companies that do this tend to be the ones that get real value out of AI. The ones that do not tend to drift.
4. Is Our Data Safe?
This is almost always the second or third question, and it deserves a careful answer rather than a reassuring one.
The honest version starts with what data you are sending where. If you are using consumer AI tools with default settings, you should assume that anything pasted into them may be used for purposes beyond your immediate query, depending on the provider and the plan. If you are using enterprise versions of the major AI products, the providers typically include no training on your data commitments under their enterprise terms, along with enterprise grade security and privacy controls, though the specific terms and scope vary by provider, plan, and region and should be read carefully rather than assumed. If you are using AI through a cloud provider's API, the data handling is typically governed by your existing cloud contracts. If you are running an open model on your own infrastructure, the data never leaves your environment at all.
The right answer for any specific company depends on what the data is, what regulations apply, and what the actual risk surface looks like. For most companies, the right pattern is to standardize on enterprise tools with strong contractual protections, to keep the most sensitive data in tightly controlled internal systems, and to write a clear acceptable use policy that everyone understands. The risk is real but manageable. It is not a reason to avoid AI. It is a reason to deploy AI deliberately rather than informally.
5. Will AI Replace Our People?
The honest answer is more nuanced than either the marketing version or the doomsday version.
For most established companies, AI will not eliminate roles wholesale in the short term. It will change what those roles spend their time on, automate parts of the work that were previously manual, raise the expected output per person, and gradually shift the mix of skills the company hires for. Some specific roles, particularly those that were essentially routine information processing, will shrink or disappear over time. Other roles, including ones that did not previously exist, will grow.
The practical pattern we see in the companies that handle this well is honesty with employees about what is changing, investment in training so people can use the new tools effectively, willingness to reorganize work rather than just bolting AI onto unchanged processes, and a focus on growing the business with the new capability rather than only on cutting cost. The companies that handle this badly tend to either pretend nothing is changing or treat AI as a quiet headcount reduction strategy. Both approaches damage trust and tend to produce worse business outcomes than the more honest path.
6. Should We Build, Buy, or Use Off the Shelf Tools?
The default answer in 2026 is buy or use off the shelf for the vast majority of use cases, with a small amount of custom integration around the edges. The reasoning is straightforward. The general purpose AI products from the major providers are very capable, are improving quickly, and are priced low enough that the build versus buy math almost always favors buying. The cost of building and maintaining a custom model is rarely justified when a provider already offers something better for less.
The cases where building or running your own model still makes sense are narrower than they used to be. They include specialized domains where general models perform poorly, situations where data cannot leave a controlled environment for regulatory reasons, very high volume use cases where inference cost becomes the dominant factor, applications where the model needs to behave in ways that the major providers will not support, and edge or low latency workloads where round trips to a hosted API are not acceptable.
The middle ground, which is where most real work happens, is a custom application built on top of a general purpose model, often with retrieval over your own data and with workflows specific to your business. This is neither pure build nor pure buy. It is the pattern that has produced most of the real value we have seen.
7. What About Hallucinations and Wrong Answers?
Hallucinations are a real and well documented behavior of language models, in which the model produces output that sounds confident but is factually wrong or unsupported by any actual source. They cannot currently be eliminated. They can be managed.
The pattern that works is to design the system so that the cost of any individual error is bounded. Use AI as a first draft for human review rather than as the final word in places where accuracy matters. Ground answers in retrieved source material rather than relying on the model's parametric knowledge. Use lower sampling temperatures for factual tasks. Require the model to cite sources and to flag uncertainty. Validate outputs against external systems where possible. Run regular evaluations that specifically check factual accuracy on representative inputs.
The honest framing for clients is that AI output is a draft from a fast, knowledgeable, sometimes wrong colleague. Treated that way, it is enormously valuable. Treated as an authoritative source whose outputs do not need to be checked, it is a liability. The design of the surrounding workflow is what determines which one you actually get.
8. How Long Will It Take?
The technical build is almost never the bottleneck. The bottleneck is everything around it. Picking the right use case takes weeks of conversation. Getting clean access to the right data takes weeks more. Defining what good output looks like, building an evaluation, training the people who will use the tool, integrating with existing systems, and managing the change in how work is done, all of these take real time.
A focused internal productivity pilot, scoped tightly, can go from kickoff to first useful version in four to six weeks. A custom internal tool that touches existing systems usually takes three to six months for a first production release. A customer facing application that involves regulatory review, security assessment, integration, and change management often takes nine to twelve months, sometimes more.
The pattern we warn against is the assumption that because the AI itself is fast, the project will be fast. The AI is fast. The organization around it is not. Plans that account for the organizational work tend to land on time. Plans that do not, do not.
9. Which AI Model or Tool Should We Use?
This question used to have a clear answer for a few months at a time and then change with the next release cycle. In 2026 the picture is more stable. The top three providers, OpenAI, Anthropic, and Google, each offer general purpose models that are good enough for almost any common business use case. The differences between them are real but small relative to the gap between using a strong model well and using a weak one badly.
The practical advice is to pick the provider that fits your existing technology stack, your security and compliance requirements, and your team's preferences, and to commit to it for a year rather than chasing every release. For most companies on Microsoft, that is OpenAI through Azure. For most companies on Google Cloud, that is Gemini through Vertex. For organizations that prioritize Anthropic's posture on safety and reasoning, Claude through AWS Bedrock or directly is a strong default. For sensitive or specialized workloads, open weight models like Llama or Mistral on managed infrastructure are also viable.
The much more important question than which model is which use case. A good use case on any of the major models will produce real value. A poor use case on the best model will not.
10. How Do We Get Our People to Actually Use It?
This is the question that separates the companies that get real value from AI from the companies that buy licenses and then watch them go unused. The technology side of an AI rollout is usually the smaller part of the work. The change management side is the larger part.
The patterns that work are consistent. Pick a small number of clear use cases tied to the actual work people are already doing. Provide real training, not a fifteen minute webinar. Have visible internal champions who use the tools in front of the team and share what worked. Make the tools easy to access, ideally embedded in the systems people already live in rather than as a separate destination. Track usage and quality, share the results internally, and adjust based on what people are actually finding useful. Recognize that the first few months are about learning rather than productivity, and protect the time for that learning.
The companies that skip this work tend to find six months later that adoption is low, the tools are blamed for not delivering, and the budget for the next phase is harder to defend. The companies that invest in it tend to find that the same tools become genuinely embedded in how the work happens, and the second phase is much easier to fund because the first one produced visible results.
The Pattern Underneath the Questions
If you look at the ten questions together, they fit a pattern. The technology is rarely the hard part. The hard parts are picking the right problem, deploying the technology into a real workflow, managing the data and trust implications, communicating honestly with employees and customers, measuring whether the work actually produced value, and treating AI as a serious operational capability rather than as a magic upgrade.
None of this is unique to AI. The same pattern applies to almost any meaningful technology investment. What is unique is the speed at which the underlying capability is improving and the breadth of work it touches. The companies that do well are the ones that build a sustainable habit of evaluating new capabilities, picking real problems, deploying carefully, and learning from the results. The ones that do not tend to either avoid AI entirely or jump into large unfocused initiatives that produce more headlines than outcomes.
The Questions We Wish Clients Asked More
A few questions come up less often than they should, and the conversations that include them tend to go better than the ones that do not.
What does success look like in twelve months, in measurable terms. How will we know if a project is not working, and what is the trigger to stop it. What capabilities do we want to build internally versus rely on partners for. How will the work change for the people most affected, and what investment will we make in their growth. What are we not going to do, and why. Each of these surfaces decisions that often go unmade in early conversations and then quietly drive how the program actually unfolds.
The Bottom Line
The questions on this list are common because they are the right questions. Where to start. What it costs. What the return looks like. How to handle data, people, build versus buy, accuracy, time, model choice, and adoption. The companies that answer them well tend to get real value from AI in the medium term. The companies that skip them tend to spend money and time on activity that does not translate into outcomes.
The honest meta point is that the answers are usually not surprising. They are mostly the application of normal good business judgment to a new and fast moving technology. The reason the questions matter so much is that the speed of the technology can tempt smart people to skip the boring parts of doing the work well. The boring parts are where the value comes from. That is true for AI today, and it is likely to remain true even as the underlying capability keeps changing.