Ask most companies what’s hard about adopting AI and they’ll point at the model. Which one to use, how capable it needs to be, what it costs. In my experience running IT support operations, that part is comparatively straightforward. The hard part is the piece that usually gets skipped in the rush: the data you’re about to point it at.
Everybody wants to turn AI on and aim it at whatever data they already have, then they’re surprised when the first answer it gives a customer is wrong. A wrong answer to a customer isn’t a small thing. That interaction is often someone’s first impression of your company, and first impressions are hard to walk back.
Get the data right before you get the model
When I say data hygiene, I don’t just mean the data is tidy. It’s the whole picture: how clean it is, how much of it you have, how relevant and representative it is, and how old it is. It also means knowing where the data came from, whether you have the right to use it, and whether the person asking the question is authorized to see it. Feed a model a thin, stale, narrow knowledge base and it will do exactly what you’d expect a confident intern to do with bad notes. It will fill the gaps and sound sure of itself while doing it.
Even when you guardrail an AI to a specific, approved set of documents, it can still drift and still hallucinate. Constraining the inputs lowers the risk without eliminating it. That’swhy a real data strategy has to come before the pilot or deployment. Teams that skip it tend to find out the hard way, usually in front of a customer.
Data readiness also isn’t a one-time gate. Sources change, permissions change, and models change. The answers have to be tested before deployment and monitored after it, with someone clearly responsible for correcting the system when the underlying information no longer supports the response.
This is why I tell people the sequence matters more than the software. Get the data right, decide what the model is allowed to touch, then turn it on. In that order, the technologytends to look smart. Run it backwards, and you spend the next year explaining why it doesn’t work.
The question that quietly kills projects
The second problem is the one I hear about most from customers who have a legal team: who owns the AI’s answer?
If the system tells a user something wrong, who’s accountable? The customer who deployed it? The vendor who runs the support? The company that built the model? Right nowthe industry doesn’t have one universal answer. Nobody wants to own an inaccurate output, and everybody wants someone else to.
Ownership and accountability are also not the same thing. One question is who owns or can legally use the generated content. Another is who is contractually and operationally responsible when that content is wrong. The model provider, platform provider, integrator, managed services provider, and customer may each own a different part of that responsibility. A contract can allocate those responsibilities, but it cannot make the consequences of a bad answer disappear.
I’ve watched how this plays out inside organizations. Business users tend not to worry about it. They see the upside and want to move. Then the project reaches legal, compliance, and security, and that’s where it stalls. The technology didn’t fail. Nobody settled the accountability question before they started.
There’s a related question that makes lawyers even more cautious. When you use a cloud AI provider and configure your environment so your data won’t be used to train the model, how do you actually confirm that’s happening? Usually you can’t independently observe every step of the provider’s backend processing. You have to combine the provider’s commitments with contractual terms, technical configuration, retention controls, data residency requirements, independent audits, and other evidence appropriate tothe risk. For plenty of use cases that’s a perfectly reasonable arrangement, but it isn’t certainty, and it’s worth being honest with clients about the difference.
If you’re a leader weighing an AI project, settle at least these questions on paper before anyone writes a line of prompt: where the data lives, whether you have the right to use it, who can access it, how long it will be retained and who is accountable for the output. The teams that do this tend to ship. The ones that don’t are usually still circling the same pilot a year later.
Automate at the pace people can actually handle
Once the data and the accountability are handled, the problems stop being technical and start being human. The mistake I see across the market is organizations dragging their customers and their own employees into full automation faster than anyone is comfortable going.
The better path is to move at the pace your users can absorb, and not because caution is a virtue in itself. It genuinely works better. People should be able to opt out of the AI and reach a live person whenever they want, and you should be able to expand what the AI handles gradually rather than flipping one switch. They should also know when they are interacting with AI and a clear escalation path when the system is uncertain, the situation is sensitive, or the answer affects an important decision. Let it start as the front door that gathers basic information, and let it take on a full request end to end only once it’s earned that trust. The goal is to bring people along with you, not to pull them somewhere they didn’t agree to go.
That discipline becomes even more important as AI moves from answering questions to taking actions. Once a system can reset a password, change an entitlement, close a ticket, or update a production system, output risk becomes action risk. Those workflows need least-privilege access, defined approval thresholds, reversible actions, and a complete audit trail.
Start small and specific rather than big and sweeping. Don’t open with a grand automation program. Take one high-volume request type, something like password resets, and move it off the live queue into automated chat with proper identity verification and multi-factor authentication enforced by deterministic security controls outside the model. The end user gets a faster fix, the resolution costs a fraction of what a live agent does, and the result is easy to measure. That one proof point earns you the room to try the next thing, and that’s usually how adoption builds, one narrow win at a time.
AI mostly connects things you already have
It helps to be honest about what this technology actually is. When Uber launched, everyone called it revolutionary, but none of the parts were new. Cars, smartphones, GPS, and digital maps had all been around for years. What Uber did was connect them into a single experience.
Most useful enterprise AI works the same way. The models already exist, your knowledge base already exists, even if it is fragmented across systems, and so do the people who will use it. The value doesn’t come from inventing something new. It comes from orchestrating what you already have into something a customer can actually use, and from being disciplined enough to lean on proven platforms instead of building fragile custom machinery you’ll be maintaining forever. But choosing a proven platform doesn’t transfer your accountability to the vendor. Organizations still need control over access, auditability, and the portability of their data and workflows.
So before you go shopping for a smarter model, look down first. Is your data clean, current, relevant, representative, permissioned, and well-governed enough to trust? Do you know who is accountable for the answer when it’s wrong? Can the people using it move at their own speed? Get those three things right and many capable enterprise models will look smarter than they are. Get them wrong and the best model on the market won’t save you, because the model was never the hard part.
![]()
Executive Bio – Sean Kirby
Chief Technology Officer
Sean Kirby is the Chief Technology Officer at Buchanan Technologies, where he leads the company’s technology vision, enterprise architecture, software engineering, and enterprise AI strategy. He is responsible for developing the technologies that power Buchanan’s managed services, helping organizations modernize IT, improve service delivery, and accelerate business outcomes through intelligent automation and customer-focused innovation.
With more than two decades of enterprise technology leadership experience, Sean blends operational excellence with strategic innovation. During his first tenure at Buchanan, he helped build and scale the company’s international Service Desk organization into a high-performing operation supporting enterprise clients across North America, establishing a foundation that continues to influence Buchanan’s approach to service delivery.
Sean later joined NCR Voyix, where he led digital transformation and integration initiatives for some of the world’s largest restaurant brands around the globe, overseeing strategic advisory, experience design, software development, and business process outsourcing programs. His work helped enterprise restaurant brands accelerate adoption of cloud, mobile, analytics, and digital technologies before returning to Buchanan in 2024 to lead the company’s technology strategy.
Today, Sean is leading Buchanan’s enterprise AI roadmap, driving the development of intelligent automation solutions including the company’s Virtual Omni Channel Assistant (VOCA) platform. His focus is on delivering practical AI solutions that improve user experiences, streamline IT operations, and empower teams with intelligent decision support. He believes AI should enhance human expertise—not replace it—while delivering measurable business value.
Sean’s passionate about helping organizations transform technology from a support function into a strategic driver of growth, resilience, and innovation. He believes technology delivers its greatest value when it enables people, simplifies complexity, and creates measurable business outcomes.
