Your AI Strategy Is Probably Just a Shopping List

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

SPEAKER_00 0:05

This is AI Security Multipliers. AI, Cybersecurity, Governance with Steve. This week, your AI strategy is probably just a shopping list. Organizations are buying co-pilots, deploying agents, and announcing ambitious AI investments. But is any of it actually making the business better? Here's Steve.

SPEAKER_01 0:30

Picture the executive meeting. It's Tuesday. Again. There's a very expensive coffee machine, a rather impressive screen, and an agenda item entitled Our Artificial Intelligence Transformation Journey, which is already three words longer than it needs to be. The technology leader begins. We've purchased thousands of AI licenses. Wonderful. We've launched 14 pilots. Splendid. We've deployed six agents. Terrific. The board slides show upward arrows, glowing brains, and a photograph of people shaking hands with a robot. So far, so strategic. Then someone at the far end of the table asks a slightly awkward question. What business outcome has actually improved? Silence. Someone mentions adoption. Someone else says innovation. A third person points to the number of prompts entered last month. And then the finance director asks whether any of that has improved revenue, margin, customer experience, or operating costs. This meeting is fictional, but I suspect the situation will feel familiar. I've seen organizations buy technology on the strength of the last presentation they attended. A vendor demonstrates something genuinely impressive, everyone gets excited, and suddenly a purchasing decision is masquerading as a strategy. Now, I'm not against buying AI, quite the opposite. I use it, I see enormous potential. But a shopping list tells you what you intend to acquire. A strategy tells you what you're trying to achieve, why it matters, what you're prepared to change, and how you'll know whether it worked. I'm Steve, and this is AI Security Multipliers. Today we're talking about why your AI strategy might be a little more than a shopping list and how to turn it into something that actually changes your business. Let's be fair, not every organization is buying AI because the CEO watched a particularly enthusiastic keynote. Some have very real problems to solve. Too much repetitive work, slow customer responses, poor access to information, expensive manual processes, missed sales opportunities. AI can genuinely help with those things. Others are investing because their competitors are doing it. Analysts are asking about it, and every quarterly earnings call seems to require the phrase artificial intelligence at least 17 times. Nobody wants to be the executive who explains, two years from now, that they decided to wait and see. Fear of missing out isn't always useless. Sometimes it gets an organization moving. Experimentation can reveal opportunities that a planning committee would never have identified. But curiosity and competitive pressure aren't substitutes for a business case. Here's the other difficulty. AI is advancing so quickly that a traditional three-year strategy document may be out of date before the ink is dry. You cannot freeze the technology landscape, spend 18 months writing a plan, and then expect the world to sit politely while you execute it. So the strategy needs two things that sound contradictory: a stable direction and flexible execution. The direction is about the business. Improve service, accelerate delivery, reduce errors, create capacity, protect customers, grow margin. Those goals shouldn't change every time a new model arrives. The tools and use cases can change. They probably should. I would rather see a short, living strategy with clear priorities, decision rights, and review points than a magnificent hundred-page document that nobody opens after the board meeting. Strategy should guide decisions. If it cannot tell you which exciting AI project to reject, it's probably not doing its job. And yes, saying no matters. Not every process needs an agent. Not every department needs its own AI platform. Sometimes the best use of AI is surprisingly modest, helping a person find the right information in less time. A smaller investment with a genuine purpose beats an expensive collection of demonstrations that never become useful. When I think about a genuine enterprise AI strategy, I think about the whole business. Not a technology roadmap with the word AI pasted across the top. Start with the outcomes. What is the organization trying to improve? Customer satisfaction? Sales conversion? Manufacturing throughput? Quality? Employee experience? Risk management? If we don't know what success looks like, we're already in trouble. Then identify the use cases. Where is the friction? Which processes are slow, repetitive, error prone, or difficult to scale? Talk to the people who actually perform the work. You may discover that the glamorous use case on the executive slide isn't the one causing the most pain. And you may discover the process is broken before AI gets anywhere near it. Automating a broken process is a remarkably efficient way of producing broken results faster. Next, look at capabilities. Do we have the data? Is it accurate, accessible, and appropriately protected? Do we have people who understand the technology and the business? Can we integrate it with the systems that matter? Are we educating employees or merely sending them an email announcing that the future has arrived? Then, governance. Who can approve a use case? What information can the system access? Who accepts the risk? How do we test quality, security, privacy, and reliability? Who monitors it after launch? And when something goes wrong, who has the authority to stop it? Finally, delivery and change. How will the organization adapt its processes, roles, controls, and measures of success? Who owns the benefits? How do we fund, prioritize, and retire initiatives? That's what I mean by a 360-degree strategy. Vision, business use cases, data, technology, education, governance, investment, and organizational change all connected. Miss one of those pieces and you may still deploy a working product. You just might not get the outcome you paid for. And there's a cybersecurity point here. Security shouldn't be the department that receives the finished solution three days before launch and is asked to bless it. Cybersecurity, data governance, privacy, architecture, and risk need to be involved early enough to shape the design. That doesn't mean they get to veto every idea. It means the business can innovate without discovering, rather late, that its shiny new assistant has been granted access to everything. I've been involved in major technology transformations over the years, and one lesson keeps coming back. A technically successful implementation is not the same as a successful business transformation. The software goes live, the integrations work, the project team celebrates, the steering committee closes the project, and six months later the business is still doing almost exactly what it did before, only now there are more screens involved. Why? Because we treated technology as the change, instead of as an enabler of change. Organizational change management is often the bit that gets squeezed. We budget for licenses, consultants, infrastructure and configuration. We produce detailed project plans. Then we assume people will simply adopt new ways of working because the software is available. As if an announcement email and a 40-minute training video can change years of habit. With AI, this matters even more. Imagine a team that spends hours gathering information for a weekly report. AI can draft that report in minutes. Brilliant! But what if nobody asks whether the report is still necessary? What if the approval chain remains unchanged? What if managers still expect employees to spend Thursday afternoon copying the same figures into a different spreadsheet? We've accelerated one step without redesigning the process. The real opportunity is to ask what work should look like now that certain tasks are easier? What should people stop doing? What decisions can happen sooner? Where should human judgment remain? What new skills do employees need? And how do we bring them along rather than presenting AI as something happening to them? People need a reason to trust the change. They need education, support, room to experiment, and honest conversations about how their jobs may evolve. Some work will change dramatically. Some roles may change too. But treating employees as an inconvenient obstacle to the technology is a reliable way to make the transformation fail. I also think we should resist the temptation to describe every efficiency gain as a headcount reduction. Sometimes the benefit is better customer service, less frustration, faster decisions, and employees spending their time on work that requires a human brain. Those are real outcomes. We should be able to explain them and, where possible, measure them. Technology doesn't walk into a business and transform it. People do. The technology just gives them new possibilities. Let's take Microsoft Copilot as an example. I've seen adoption at considerable scale. Often it starts in small pockets. Someone discovers they can draft a document faster. Someone else uses it to summarize a long meeting. A manager realizes they can create a first version of a presentation without spending an entire evening wrestling with PowerPoint. Then the uses broaden. Meeting notes become more useful. People find information buried in documents and conversations. Employees can discover institutional knowledge that previously depended on knowing the one person who remembered where it lived. That's powerful. And yes, it can be genuinely delightful to ask a question and get an answer without conducting an archaeological expedition through SharePoint. But now comes the harder question. How do we measure the value? License activation isn't value. A thousand active users isn't automatically a return on investment. Even hours saved can be a slippery number. If someone saves 30 minutes writing a report, what happened to those 30 minutes? Did the business save money? Did the employee serve another customer? Did they improve the quality of the work? Did they get home on time for once? I suspect most people don't spend the saved time doing nothing. They redirect it. They engage with customers, they learn, they take on work that previously had to wait. They may feel less exhausted by repetitive administrative tasks. That last point matters too. Employee well-being is not merely a soft afterthought, even if it doesn't fit neatly into a spreadsheet cell. The right measures depend on why you invested in the first place. If the goal was faster customer response, measure response time and quality. If the goal was better sales conversion, measure conversion and revenue. If the goal was lower operating cost, measure actual cost. If the goal was employee capacity, define what additional capacity is expected to achieve. Distinguish hard savings from softer benefits, and don't pretend every minute saved is a dollar in the bank. I would also look for unintended costs. Reviewing AI output takes time. Incorrect information creates rework. Additional licenses, integrations, support, and controls cost money. If the benefit case assumes perfect outputs and zero supervision, perhaps revisit the arithmetic. A good investment has a clear hypothesis, a baseline, a measurement plan, and an owner accountable for the outcome. We don't need to measure everything perfectly. We do need to measure something more meaningful than how many times somebody clicked the shiny button. Now for a particularly dangerous phrase. It's only a pilot. I've heard variations of that throughout my career. It's only a test system. It's only a proof of concept. It's only being used by one team. Six months later, the test system is processing essential business information, three departments depend on it, and nobody remembers who approved the original access. AI makes that progression faster. Someone builds an assistant to help with a small workflow. It's useful. Colleagues ask to use it. Someone connects another data source. Another person adds a tool that can update records. Before long, an experiment has quietly become a production service, complete with dependencies, users, and risks that were never assessed. And now try taking it away. Suddenly, the supposedly temporary experiment is business critical. The horse hasn't merely bolted, it's bought a house in the next county and changed its mailing address. This is why I believe governance belongs in the experimentation stage, not just at the end. I'm not suggesting every experiment needs a committee meeting, a 30-page risk assessment, and ceremonial approval from someone wearing a particularly serious tie. We can create safe environments that let people explore. Use approved tools, limited data sets, scoped permissions, spending limits, and clear restrictions on connecting production systems. But define the boundary between experimentation and operational use. What triggers a formal review? Access to sensitive data? A live customer interaction? An automated decision? A production integration? A financial transaction? Whatever the criteria, make them understandable and enforceable. Then provide a path forward. If a pilot proves valuable, help the team move it into a supported environment with a business owner, security controls, monitoring, documentation, and an operating model. Don't make the approved route so slow that people simply avoid it. This is the balance. Enough freedom to discover value, enough discipline to prevent an accidental production estate. Governance should make successful experimentation sustainable. Otherwise, you end up with a collection of clever prototypes that the business cannot safely live with, or live without. So who actually owns the AI strategy? The CIO? The chief AI officer? The CISO? A committee with a suitably futuristic name? My view is that the CEO and executive leadership team must own it collectively. AI affects how the business sells, serves, operates, makes decisions, manages risk, and develops people. It isn't simply a technology installation. You cannot delegate all of those outcomes to IT and then act surprised when the benefits don't materialize. That doesn't mean everyone owns everything. The business must own its priorities and results. Technology teams provide platforms, architecture, integration, and operational support. Data leaders ensure information is fit for purpose. Cybersecurity and risk teams help define guardrails, visibility, and response. Human resources and business leaders support workforce development and organizational change. Finance helps establish whether the investment makes economic sense. Somebody still needs to coordinate the whole thing. But coordination isn't the same as sole accountability. An executive committee can provide direction, resolve competing priorities, and make trade-offs. The individual initiatives need named owners who can explain what they are delivering and why. And the board has a role beyond approving a large number with a pound or dollar sign in front of it. Before asking for another 5 million for AI, I would want to hear the board's view of the opportunity. What do they believe AI should change about the organization? Where do they see the risks? What growth, margin, service, or resilience outcomes matter to them? How often do they want updates, and on which decisions do they expect to be engaged? That conversation builds alignment. It also prevents an awkward moment a year later when the project team reports technical success and the board asks why none of the promised business benefits are visible. The best organizations over the next few years won't necessarily be the ones with the most agents, the most licenses, or the longest list of experiments. I suspect they'll be the ones that choose focused use cases, bring the workforce along, redesign processes, and govern what they deploy well enough that the benefits last. In other words, the ones that can tell the difference between activity and progress. And that brings us to the multiplier. Before your organization buys another AI product, approves another agent, or launches another pilot, have one conversation. Not with a vendor, with the people who are accountable for the business. Ask, what outcome are we trying to improve? Not what technology do we want to buy? What needs to be better? Ask, how will we know? What's the baseline? What will we measure, and who owns the benefit? Ask, what must change beyond the technology? Which processes, roles, skills, and ways of working need to move with it? Ask, what could go wrong? What data, access, oversight, and operational controls will we need even while experimenting? And ask, are we aligned? Does the executive team share the same vision? And how does the board want to remain involved as the initiative evolves? Those questions won't guarantee success. Nothing will. But they will expose the difference between a business strategy and a purchasing exercise remarkably quickly. Here's the multiplier. Every AI investment should have a business outcome, an accountable owner, a way to measure success, and a plan for the organizational change required to realize it. I am optimistic about AI. I think it can remove drudgery, improve insight, speed up work, and give people more time for the parts of their jobs that actually need them. But we won't get those benefits simply by collecting tools. And we won't get them by writing a strategy so rigid that it becomes obsolete before implementation. Keep the business direction clear. Keep the technology choices adaptable. Bring the people with you and measure what matters. The success of your AI strategy won't be measured by how much AI you've deployed. It'll be measured by how much better your business operates because of it. I'm Steve. Thanks for listening to AI Security Multipliers. And if your strategy document is currently a list of software products with prices beside them, well, at least you've made a start on the shopping. I'll see you next time.