![\"\"](\"https:\/\/kexino.com\/wp-content\/uploads\/2026\/03\/AI-cannnot-fix-a-borken-business-1200x1200.jpg\")
<\/div>\n<\/p>\n
Most of the AI-implementation conversations happening right now are focused around what we might gain. Speed, efficiency, cost reduction, competitive advantage, and so on. I don\u2019t think many people who\u2019d disagree these are clear tangible business benefits, and organizations treating AI as a passing fad are clearly making an expensive mistake. <\/p>\n
But there\u2019s another version of this question that almost never gets asked: What might we be giving away in the process, and would we even know?<\/strong><\/p>\n One of the things AI can do really well, and it can do many, is that it can accelerate whatever is already happening. Feed it a well-understood, clearly documented process and it will run that process faster, at scale, with less friction. But if we feed it something poorly defined, inconsistently executed, or built around assumptions nobody has tested in years, and it will do that at scale too.<\/p>\n AI amplifies both good and bad inputs.<\/a> An error a human makes once can be amplified thousands of times before anyone notices, because the machine never has an off day that prompts a second look. AIIM\u2019s industry research<\/a> showed that 80% of organizations believed their data was AI-ready before deployment; but 95% of those same businesses ran into significant data problems when they actually tried to do it.<\/p>\n We tend to evaluate AI through an economic lens. Faster execution, lower costs, improved margins. FTI Consulting\u2019s analysis of AI transformation describes this as the dominant framing among organizations that later discover they were asking the wrong questions.<\/a> We measured the speed of the output without first checking whether the output was worth producing quickly. The businesses that were already operating with process fragility they\u2019d been managing around for years find that AI removes the humans who were, it turned out, actually doing all the managing.<\/p>\n McKinsey\u2019s State of AI research found that 88% of organizations now regularly use AI in at least one business function, while only around 5.5% are driving significant value from the deployment<\/a>. Is underperforming tech the root cause of that huge gap? Nope \u2013 the real reason is that businesses deployed AI into processes they hadn\u2019t understood clearly enough for acceleration to help.<\/p>\n A question to ask before deploying AI into a workflow isn\u2019t which tool to use. It\u2019s whether we understand the underlying business processes \u2013 our business \u201coperating system\u2019, if you will \u2013 well enough to explain it to a machine. Because if the answer is no, the machine will fill in the blanks itself, consistently, and at scale.<\/p>\n For most of the past century, businesses built themselves around a particular logical process. We hire the people, design the workflow around them, then buy the systems and\/or software needed to support it. This is still how most organizations operate, which is precisely the problem.<\/p>\n The reason is because the sequence that served us so well over the past 100+ years has now flipped, and today is running the other way. Today, it makes far more sense to start with what the technology can actually reliably do, and work backwards from there. What that capability makes possible in the real world, determines how the workflow should be structured, which in turn determines what kind of organization is needed to run it. We can then see clearly the types of people we need to hire, how to train them, and what kind of underlying culture<\/a> glues the whole thing together.<\/p>\n Most businesses are skipping straight from \u201chere\u2019s the tool<\/em>\u201d to, \u201cHow do we fit this into what we already do?<\/em>\u201d That\u2019s the path of least resistance, and explains why so many AI deployments produce incremental gains rather than structural ones. Making a broken process 10% faster isn\u2019t transformational. It\u2019s a more efficient version of the original problem. Trying to emulate with tech the way we did things with people, is doing things exactly the wrong way round.<\/p>\n All those AI-deployment success stories we read about are by businesses who looked at implementing AI capability as a reason to ask a much more fundamental business question: What would this organization look like if we were building it now, knowing what the technology can actually do?<\/strong> That\u2019s a very different question from \u201cwhere can we shoehorn AI into what we\u2019re already doing?<\/em>\u201d It requires thinking about the shape of the operation itself. Which functions look different when AI is doing the reasoning-intensive work? Which roles exist now because the process required them, rather than because the outcome requires them? Where are we staffing for process friction that AI removes?<\/p>\n This is both an organizational design question, and a cultural question. Businesses that treat it primarily as a technology question tend to end up with expensive software sitting inside structures that were never designed to use it well. Meanwhile, the characteristics that make AI deployment actually work, such as the willingness to rethink assumptions, or being comfortable with uncertainty, are all cultural. You won\u2019t find that kind of stuff in the release notes.<\/p>\n The economists and finance people won\u2019t like me saying this (since they\u2019re looking at AI purely as a way to reduce costs and maximize profits), but the more AI capability a business deploys, the more the quality of its people matters. A team that\u2019s clear on what it\u2019s trying to accomplish and understands the strategy well enough to make good decisions about what to hand to a model and what to keep human, will use AI capability in ways that a disengaged, confused, or poorly led team simply won\u2019t. The gap between those two outcomes is larger with AI than it was without it.<\/p>\n Whether they\u2019ll admit it or not, most businesses are running on knowledge and process that has never been formally documented. There\u2019s a huge difference between the way a client relationship actually gets managed, for example, compared to how the account management template says it should. Research estimates that around 90% of the total knowledge in an organization exists in this tacit form.<\/a> It lives in people<\/strong>, rather than documents, because it was developed over the years through experience rather than taught through formal instruction. That\u2019s also what makes it hard to replicate. While the competition can copy our pricing model, our service structure, or our sales spiel, it\u2019s much harder to emulate 15 years of learned judgment about how to handle a particular kind of client problem.<\/p>\n So when businesses feel forced to implement AI in some part of their organization, it obliges them to ask questions and deliberate processes that most of them haven\u2019t fully worked through. When we automate a process that runs on undocumented expertise we\u2019re making a choice, probably without realizing we\u2019re making it. We can do the slow, painful work of surfacing and documenting what we actually know before<\/em> we automate, or we can let the AI infer the process from available data and just get on with it. Yes, option 2 gets us to launch faster, but it\u2019s also how institutional knowledge gets replaced by an approximation of itself that the organization no longer owns, and didn\u2019t notice when it left the building.<\/p>\n CoBase did a study on some engineering and science companies, looking to see they handled knowledge management within the organization. They discovered 40-60% of valuable insights, information that could potentially be useful within the business, were not being effectively reused<\/a> because nobody could locate the information when they needed it. The knowledge existed somewhere within the organization, but was inaccessible to the point that it may as well not have existed at all. While AI solves this accessibility problem, in the wrong conditions it solves it on behalf of a third-party vendor platform rather than the organization itself.<\/p>\n Deploying AI doesn\u2019t just change how efficiently we execute a business model, but changes the model itself as a (probably undesired) side effect. Since AI makes our internal operational efficiencies the same as every else\u2019s, instead of presenting a differentiated proposition, the inevitable result is trying to compete on the lowest common denominator, which is most often one of price<\/a>. Our defence of profit margins moves towards proprietary assets, domain expertise, and brand. A big part of the client value of many B2B businesses (especially those selling services) is around how they think about a client problem, rather than simply what they produce in response to it. This kind of accumulated thinking is often considered as being a feature<\/em> of what\u2019s being sold, but in fact it\u2019s the actual product<\/strong>. When this kind of position becomes uploaded and assimilated into a third-party AI platform to create some kind of business tool, what we fail to recognize is we\u2019ve spent our own money training something that (unless we\u2019re careful) will become available to our competitors.<\/p>\n When we base such foundational constructs on a third-party platform that, as far as the smallprint is concerned, is free to reuse and repackage it however they see fit, vendor dependency becomes strategic instead of technical. CTO Magazine did an analysis of AI platform risk<\/a> and outlines how we\u2019re openly walking into proprietary APIs, closed data formats, and training pipelines that can\u2019t be reversed without significant cost and resources. Whenever an AI vendor changes their business terms, decides to alter their pricing model, or simply stops trading and goes under, every business that was fully or partly built on such a closed system may be screwed. The language used in enterprise AI architecture research to describe this point<\/a> doesn\u2019t mince words. By blindly diving head first into a someone else\u2019s algorithm we\u2019re outsourcing our infrastructure as well as our competitive intelligence. The keys to the car we\u2019re driving now belong to someone else.<\/p>\n The safer, if not so headline-grabbing way of deploying AI within a business starts with a deep and scrupulous interrogation of our own processes, without worrying what kind of skeletons we might dig up. The objective should be to work out whether the underlying (manual) processes are actually sound, and whether we can articulate what made them work without being reliant on the people who, if they left the company, would take all that institutional memory with them. The problem with pulling such threads is that you often uncover things that you probably didn\u2019t want to know. Workflows that held together with Scotch tape and string, running on Jurassic machines because the software doesn\u2019t support a newer OS, or because of a person who left 5 years ago and didn\u2019t teach anyone else before they left. We pretend to customers, and to ourselves, that we\u2019re squeaky clean and state-of-the-art. But the truth is all those micro-processes, those instances that don\u2019t fit the protocols we\u2019ve built, were never as employee-agnostic and consistent as we\u2019d all assumed.<\/p>\n Finding those things before AI touches them may not be many people\u2019s idea of fun, but certainly beats finding out this stuff after the fact once the dysfunction is automated and running continuously. MIT Technology Review did a survey on AI and industry disruption and found that 60% of survey respondents expect generative AI to substantially reshape their industry within five years<\/a>. But the reality is that, for most businesses, this kind of disruption is already internal. AI pulls away the curtain and exposes process fragility that was always there. It\u2019s just more visible now, because a machine is running it faster than our manual workarounds could hide the truth.<\/p>\n Then there\u2019s the question of informational sovereignty. Don\u2019t forget that every piece of organizational knowledge that we upload into a proprietary, closed AI system is a potential transfer of a valuable business asset. Before we give away the farm, it\u2019s worth us knowing which parts of our business model are defensibly proprietary, which can survive commoditization, and which would be swallowed-up into an AI platform and no longer be (just) ours. I think a tiny number of businesses are even bothering to have that conversation right now, and the pressure toward commoditization<\/a> won\u2019t wait around until the CEO (or the Board) decide to address such a question.<\/p>\n To be clear: I\u2019m not arguing against businesses deploying AI \u2013 quite the opposite, to be honest. Our agency has been helping our clients implement AI-powered systems intelligence and customer value tools for years. I don\u2019t think sitting on the fence waiting to see what everyone else ends up doing isn\u2019t a viable plan. By playing the waiting game, businesses run the risk of \u201cAI intuition debt\u201d that accumulates a continually-compounding deficit that will just get more and more expensive to close<\/a>. <\/p>\n The case for moving forward with AI is clear. But the case for moving forward with our eyes wide open is even clearer.<\/p>\nFast is only an advantage if you were already headed in the right direction<\/span><\/h2>\n
The sequence most businesses have backwards<\/span><\/h2>\n
The knowledge nobody thought to write down<\/span><\/h2>\n
AI changes our business model, even if we didn\u2019t want it to<\/span><\/h2>\n
Asking the harder question first<\/span><\/h2>\n
\n
\nBlowing our own trumpet<\/span><\/h4>\n