AI doesn’t fail because of the model

AI doesn't fail because of the model. The customer asked their new AI assistant what should have been a simple question. How many of our people are using Teams? It answered in about four seconds with total confidence, and it was wrong. It had read a directory export that hadn't been reconciled in months, counting thousands of levers as active users. Nobody caught this, and so the inflated number was used in a license renewal. The model did exactly its job. It read what it was given and answered the question asked. The data was the problem, and no amount of model capability would have saved it. Recently, I wrote about why AI needs an automation fabric, not another script. The idea that AI can generate code but not the judgment or domain expertise to know what's worth building. Domain knowledge tells you what is worth building. But judgment applied to the wrong numbers still produces the wrong decision confidently and considerably faster than before. Which leads me to the second question in this series. What is the AI actually reading? It comes down to the environment the model operates within. AI requires access to trusted day data, governed processes, and automation that can execute tasks consistently. It also depends on integrations across systems that were never designed to work together. Without these foundations in place, even the most advanced AI becomes another disconnected tool rather than a meaningful part of the enterprise workflow. This is why the conversation needs to shift from AI capabilities to AI readiness. Trusted data is the real competitive advantage. AI models are increasingly accessible, and in many ways, the technology itself is rapidly commoditizing. What is far more difficult to replicate, however, is high quality operational data that reflects how an organization runs. Trusted carries a lot of weight in that sentence, so it is worth being specific about what it means. In practice, it is four things, and most enterprise operational data fails at least one of them. 1. Current, meaning reconciled in hours rather than quarters, and a state of any size changes faster than most reporting cycles can track. 2. Accurate, meaning it reflects what the systems did rather than what the CMDB says they should have. 3. Complete, meaning it covers the whole estate rather than the tenants and regions somebody remembered to onboard. 4. Contextual, meaning it carries enough surrounding information to tell whether a number is good or bad. The fourth is the one that organizations consistently underestimate. The first three are hygiene problems, which are solvable with effort. Context is not something you can clean your way into. It must come from somewhere outside your own organization. Enterprises generate vast amounts of information across collaboration platforms, communication systems, Microsoft 365, security tools, and core business applications. Within that data are patterns that can improve decision making, highlight inefficiencies, predict issues before they occur, and automate routine work. The real value is not simply knowing what is happening, but understanding what good looks like in context. It is one thing to know your Microsoft Teams adoption figure. It is another thing to know that large enterprises, five thousand plus employees, typically sit at 96% adoption, while sectors like retail and hospitality average under 55%. So a 60% figure means something very different depending on your size and sector. Meeting rooms tell a similar story. Industry benchmarks put healthy utilization at 60-80% of booked hours, yet most portfolios run at 38-40%, with close to three in ten booked rooms sitting empty on any given day. Customers sitting well below that healthy range are usually paying for the capacity they forgot they bought. License allocation, call quality, and ticket volumes all behave the same way. When viewed in isolation, these are just metrics. But when compared against meaningful benchmarks, they become powerful indicators of performance. Benchmarking and trend analysis transform raw operational data into actionable business intelligence. As organizations accumulate more of this data over time, the insights become increasingly valuable, not because AI generated them, but because AI is able to interpret trusted operational data in context. In this way, data itself becomes a durable, competitive advantage. It is also the network effect I described in the first post seen from the other side. Every deployment sharpens the benchmark, and the benchmark is what makes the next deployment's data legible on day one rather than in year three. This is why VOSS is evolving beyond communications management. Our technology already sits across the systems this data lives in: Identity, Collaboration, Communications, Licensing, ITSM which means we see the operational estate as one model rather than as numerous disconnected exports reconciled by hand each month. That is what makes the numbers current and complete. And because we do it across many customer estates, it is what makes them comparable. Customers can bring whatever AI models they prefer whenever they are ready. What we make sure of is that those models are reading something true. Being right is not the same as being useful. Domain knowledge tells you what is worth doing. Trusted data tells you whether it is true. Between them, they will get you to a recommendation you can stand behind, which is further than most enterprises are today and further than the customer mentioned in this post ever got. And then nothing happens. Because a recommendation, however well grounded, does not act on itself. You can have the judgment, and you can have the data and still watch the answers sit in a chat window while the estate continues exactly as it was. That is the third question and the last one in this series, which I will address in coming weeks. Once the AI is right, who does the work? If you would like to talk about this in the meantime, please get in touch.