I sat in with a friend last month where he was talking about a VP at his company who had presented a slide titled "AI Transformation Roadmap." It had six workstreams, a maturity model, a timeline that somehow ended with "full AI integration" by Q4, and enough buzzwords to fill a conference keynote. What it didn't have was an answer to the most basic question anyone should ask before spending money on anything: why are we doing this?
I don't mean "why is AI important." That question answers itself at this point. Why are we doing this, here, in this organization, for this specific problem, right now? What breaks if we don't? What gets better if we do? How would we know?
From the discussion with my buddy… nobody in that room had probably even thought about that. What they had was urgency because an executive leader had asked about AI. All their competitors were announcing AI initiatives and processes. Their executive had just come back from a conference with a head full of demos and a sudden concern that the company was falling behind technologically. So now everybody needed an AI strategy, and they needed it fast, and nobody was going to slow down long enough to ask whether the strategy they were building actually connected to anything the business needed.
I see this pattern everywhere, and I've been part of it myself. The instinct to adopt something because it exists, because it's available, because everyone else seems to be doing it, is a powerful feeling. It feels like common sense, it looks like leadership and in a lot of cases, it's neither. It's a reaction dressed up as vision.
I recently read an article by Dr. Grace Crossette-Thambiah for CDO Magazine on this topic. She built a three-pillar framework: Need, Efficiency and Financials, and Data Quality with Governance and Ethical Implementation. It's a solid framework, but frameworks have a way of staying on slides instead of changing behavior, so I want to take her pillars and drag them through the mud of what actually happens in organizations when the AI conversation starts. Because the gap between "we should adopt AI responsibly" and "we are adopting AI responsibly" is roughly the same size as the gap between "we have a cybersecurity program" and "we are secure." The policy exists. The behavior does not always follow.
Let's start with Need, because it's the pillar that gets skipped the most and matters the most.
The question isn't "can we use AI for this?" The question is "should we use AI for this, and what happens to the problem if we don't?" Those are different questions with different answers, and the second one is the one that tells you whether you're solving a real problem or just adding a technology to your org chart so someone can put it in a quarterly update.
I've watched organizations deploy AI-powered tools to automate processes that didn't need automating. A team that processes fifty invoices a week doesn't need an AI system to do it. They need a spreadsheet and someone who knows how to use it. But "we automated invoice processing with AI" sounds a lot better in a board deck than "we trained Karen on pivot tables," so the AI project gets funded, deployed, and eventually abandoned when it turns out that the integration costs more to maintain than Karen's salary. Meanwhile, Karen is now doing something else because her job was "automated," and the invoices are being processed by a system that nobody on the team fully understands and everyone is afraid to touch.
I want to be clear: I'm not anti-AI. AI is genuinely transformative for the right problems. I use AI tools in my own work. But the "right problems" qualifier is doing a lot of heavy lifting in that sentence, and most organizations aren't rigorous enough about defining what their right problems actually are before they start writing checks.
Dr. Crossette-Thambiah uses the example of a hospital adopting an AI diagnostic tool. If the tool measurably reduces misdiagnosis rates, that's a clear win tied to the hospital's core mission. Notice how specific that sentence is. It's not "we deployed AI in healthcare." It's "we deployed this specific tool to address this specific problem, and here's how we'll measure whether it's working." That level of specificity is rare in most of the AI adoption conversations I've seen. They tend to operate at a much higher altitude, where everything sounds strategic and nothing is measurable.
The reason Need gets skipped is that it requires leaders to admit they might not actually need the thing they're excited about. That's a hard conversation to have when executives are asking questions and the competitive pressure feels real. It's much easier to skip to "how do we implement this" than to sit with "do we need to implement this" long enough to get an honest answer. I've been guilty of this myself, not with AI specifically, but with other tools during my career. I've bought technology because it solved a problem I was worried about rather than a problem I could prove existed. The difference between those two things is the difference between fear-driven spending and need-driven spending. I've done both. I've gotten better.
The second pillar is Efficiency and Financials, and this is where most AI business cases live and where most of them quietly fall apart.
The standard AI pitch goes something like this: we automate X, which saves Y hours per week, which translates to Z dollars in labor savings. Multiply by the number of employees affected, project forward three years, and you've got an ROI that makes any CFO smile. I've seen this math done dozens of times. The problem is that the math is almost always wrong, not because the numbers are fabricated, but because the assumptions underneath them are wishful.
The labor savings calculation almost never accounts for the labor required to implement, integrate, train on, monitor, and maintain the AI system itself. It doesn't account for the meetings. The vendor calls. The change management. The inevitable period where the old process and the new process are running in parallel because nobody trusts the new one yet. It doesn't account for the fact that "freeing up employee time" doesn't automatically translate to "employees doing higher-value work." Sometimes it just translates to "employees doing the same amount of work with a new tool they didn't ask for bolted onto their workflow." I've seen automation projects that technically saved time but made the affected employees so frustrated with the new process that turnover increased, which is not a cost that shows up in the original ROI calculation but absolutely shows up in the budget.
Dr. Crossette-Thambiah makes a distinction between efficiency and efficacy that I think is genuinely important and consistently overlooked. Efficiency is doing the thing faster. Efficacy is doing the thing better. They're related but they're not the same, and a lot of AI implementations optimize for the first one while claiming credit for the second. An AI system that processes customer service tickets faster isn't necessarily making your customer service better. It might be routing complex issues through a pipeline that handles simple problems well and complex problems badly, which means your average resolution time looks great while your customer satisfaction on difficult cases craters. You won't see that in the efficiency metrics. You'll see it six months later when the satisfaction rate drops and nobody can figure out why.
The financial case for AI adoption needs to be more honest about costs and more modest about projected returns. Not because AI doesn't deliver value, but because the gap between projected value and realized value is consistently larger than anyone wants to admit. I've sat in enough post-implementation reviews to know that the original business case almost never survives contact with reality. The timeline slips. The integration is harder than expected. The vendor's actual capabilities don't quite match how everything worked during the demo. The internal team that was supposed to own the tool doesn't have the skills or the bandwidth to actually use it. None of these things are unusual. All of them are predictable. Very few of them make it into the original ROI model.
If your AI adoption decision was predicated on a financial case that turns out to be 40% optimistic, you haven't just made a bad investment. You've eroded the credibility of the next technology initiative, because the organization's institutional memory now includes the time the AI project didn't deliver what was promised.
This brings us to the third pillar, the one I care about the most because it lives in my world: Data Quality, Governance, and Ethical Implementation. I'm going to say something that will not surprise anyone who works in data or security but consistently surprises the executives driving AI adoption: your data probably isn't ready.
Not "your data might have some issues." Your data probably has significant quality problems that will directly affect the output of any AI system you build on top of it. Duplicate records. Inconsistent formatting. Missing fields. Legacy data entered under different standards than current data. Categorization schemes that changed three times in five years without anyone reconciling the old records. Data that was accurate when it was entered and hasn't been validated since.
This isn't a criticism of any specific organization. This is the reality of data management in essentially every enterprise I've ever seen. The data that exists was created to serve the operational needs of the systems that collected it, not to serve as training data for machine learning models. Those are different requirements, and the gap between them is where AI projects go to die.
Dr. Crossette-Thambiah calls for data that is "accurate, complete, relevant, and representative." I'd add "understood" to that list. Someone in the organization needs to actually understand what the data represents, where it came from, how it was collected, what changed over time, and what its limitations are. That's not a technology question. That's an institutional knowledge question, and institutional knowledge is the first thing that gets lost when organizations reorganize.
The governance piece is where my security brain starts firing. Data governance isn't just about making sure your data is clean. It's about controlling who can access it, how it moves, where it's stored, who can modify it, and who's accountable when something goes wrong. When you feed organizational data into an AI system, you are creating a new attack surface. The model itself becomes a repository of patterns derived from your data. The training pipeline becomes a target. The API endpoints become an access point. The outputs become a potential data leak if the model has been trained on sensitive information and someone asks it the right question.
I think about this through the lens of something we deal with constantly in security: shadow IT. For years, the biggest risk in most organizations wasn't the systems we knew about. It was the ones we didn't. The SaaS app someone signed up for with a corporate email, or the spreadsheet with customer data sitting on a personal laptop. AI is creating the same dynamic at a much larger scale. Employees are already feeding company data into public AI tools. They're uploading financial models to get help with formulas. They're doing it because it's useful and because nobody told them not to (or because someone did and they're doing it anyway, because the tool works and the policy doesn't). Every one of those interactions is a data governance event that most organizations have no visibility into and no controls around.
Most governance conversations I've witnessed treat security as an afterthought. The data team talks about quality. The ethics committee talks about bias. The business team talks about ROI. Nobody talks about what happens when the model gets compromised, when the training data gets poisoned, when the API gets abused, or when an adversary uses prompt injection to extract information the model was never supposed to reveal. These aren't theoretical risks. They are documented, demonstrated, and increasingly common attack vectors against production AI systems. Just this month, researchers demonstrated self-propagating payloads that spread from one AI agent to another through system prompt files.* Autonomous AI agents have escaped testing sandboxes and compromised real infrastructure.** If you think your governance framework is ready for that, I'd love to see it.
The ethical dimension is the one that makes people most uncomfortable, which is usually a sign that it's the most important one to talk about. Bias in AI systems is not a future risk. It's a current reality. Models trained on historical data inherit the biases embedded in that data, and those biases don't announce themselves. They hide in the outputs, looking like objective analysis, until someone notices that the hiring model is systematically downranking candidates from certain zip codes, or the credit scoring model is producing different outcomes along demographic lines that nobody intended but the data made inevitable. If the training data reflects historical discrimination (and it probably does), then the model will reproduce that discrimination unless you actively intervene to prevent it. Active intervention means someone has to look for it, test for it, measure it, and fix it. That takes time, expertise, and organizational commitment that goes beyond putting "fairness" in the AI principles document.
Human-in-the-loop oversight is the standard recommendation, and it's a good one as far as it goes. But "human in the loop" means different things in different contexts, and the version that actually works (where a qualified person reviews AI outputs before they affect real decisions and has the authority to override them) is expensive and slow and runs directly counter to the efficiency gains that justified the AI investment in the first place. That's the tension nobody wants to name. You can have fast, automated, AI-driven decision-making, or you can have careful, human-reviewed, accountable decision-making. You can sometimes have both, but not always, and the places where you can't are usually the places where the stakes are highest.
I think the question organizations should be asking isn't "how do we adopt AI responsibly?" It's a set of smaller, uglier, more specific questions. Do we actually know what problem we're solving? Can we measure whether we've solved it? Is our data good enough to support this, and how do we know? Who is accountable when the AI makes a decision that turns out to be wrong? What does our incident response plan look like when the AI system itself becomes the attack surface? Have we tested for bias, and I mean actually tested, not just checked a box? Are we being honest about the real costs, including the organizational friction, the maintenance burden, and the opportunity cost of everything else we're not funding because this got funded instead?
None of those questions are fun. All of them are necessary. The organizations that answer them honestly before they start building will build something that works and lasts. The organizations that skip them will build something that looks impressive in a board deck and falls apart under pressure.
I keep coming back to something Dr. Crossette-Thambiah wrote about AI being "a trustworthy partner." I like that framing, but I'd push it further. Trust isn't a feature you ship. It's something you earn through consistent, verifiable behavior over time. If your AI system makes a decision, you should be able to explain why it made that decision, trace the data that informed it, identify the assumptions baked into the model, and demonstrate that you tested for failure modes before deploying it. If you can't do those things, you don't have a trustworthy partner. You have a black box that's making decisions on your behalf while you hope for the best.
I realize this entire piece sounds like I'm telling people not to adopt AI. I'm not. I'm telling people to adopt AI with clear objectives, honest financial analysis, clean and governed data, real security considerations, genuine ethical guardrails, and the humility to admit when you're not ready. "Not ready yet" is not a failure. "Deployed anyway and broke things" is.
The race to adopt AI is real. The pressure is real. The competitive dynamics are real. But doing the wrong thing quickly is not better than doing the right thing carefully. We know this. We say it about cybersecurity all the time: you can't secure what you don't understand, the fastest patch is worthless if it breaks production, the cheapest solution is usually the most expensive one eventually. The same principles apply here. The fact that we have to keep relearning this lesson with every new technology wave is either deeply human or deeply embarrassing. Probably both.
AI is a tool. A powerful one. An important one. Possibly the most important one of our professional lifetimes. That's exactly why we should be thoughtful about how we use it, not despite the urgency, but because of it.
The next time someone puts an "AI Transformation Roadmap" on a screen in a room you're sitting in, ask them one question: what specific problem does this solve that we can't solve without it?
If the room goes quiet, you have your answer.
* Anthropic and EPFL researchers demonstrated this in a preprint released Aug. 10, 2026; reported in The Hacker News, "AI 'Mind Viruses' Can Spread Between Agents Through Persistent Prompt Files." The authors describe it as a "real but currently limited risk," with no evidence of successful propagation in the wild.
** The July 2026 OpenAI–Hugging Face incident: an autonomous agent escaped an OpenAI evaluation sandbox and breached Hugging Face production infrastructure. See Hugging Face's security disclosure (July 2026); CNN Business, "An OpenAI test model escaped and broke into a real company's servers" (July 22, 2026); and Malwarebytes, "OpenAI's agent escaped its sandbox during a security test."