What must exist in a company before AI

AI envisioning workshops with boards and management teams are important: they help a company imagine where it wants to go, and the sticky notes they produce are full of good intentions. The trouble starts when those plans land on the desk of whoever has to turn them into something that actually works in production, because at that point, with a regularity I have learned to predict over the past few years, the same three things come up. None of them is an AI problem. They were all there before, and AI simply makes them impossible to postpone any longer.

Over the past months I have written about them on LinkedIn, one post at a time. Here I am trying to put them in a row, because read together they say something you cannot see when they are apart: integrating AI into a company is not a technology project. It is excavation work.

Knowledge lives in people’s heads

AI started by absorbing the shared heritage of the web. Inside a company, though, it has to absorb something far more specific: the knowledge that has settled in the heads of the people who work there, the jargon, the structure of the data, what “that aggregation” means for that department. Take a holiday park: its database has a table that tracks overnight stays and everything looks easy, but with all the variables in play there are four or five possible definitions of “overnight stay”, and the schema does not say which one applies in that property, because only the people who work there know. Ask an AI how many overnight stays you had in July without telling it which definition to apply, and it will answer at random. With great confidence.

Knowing the structure of the data, in other words, is not knowing the company, because in between there is a translation from schema to jargon that no model performs on its own. In the 1970s the hackers at MIT and Stanford wrote the Jargon File, the dictionary of their tribe’s slang, to make a language readable to outsiders that would otherwise have stayed in the heads of those who spoke it. Today the outsider is AI, and the most underestimated phase of any project is precisely the writing of the company’s jargon file: interviewing the people who know, understanding what they mean when they ask for something, and depositing it in prompts, instructions and agent configurations. You cannot buy it and you cannot download it. And for the first time that knowledge becomes an asset of the company, detached from the person who carried it.

Data is fine as long as there is a human in the loop

When we really open up a company’s data, it almost always tells a story of years of acceptable compromises: partly structured, not always up to date, sometimes inconsistent from one system to the next. As long as the data served to produce reports that somebody would read and interpret anyway, it worked, because if a count did not add up there was always a person to trim, review or dig deeper. The moment part of the decisions moves to a system that reasons and acts on its own, that margin disappears, and an AI that decides on mediocre data makes mediocre decisions, only faster: at AI speed, the effects propagate before they can be corrected.

Strangely, very little is said about this. Data quality has become the variable that decides whether AI produces value or noise, and it is perhaps the most neglected topic in the whole conversation about adoption.

Where the data goes, who has access, what it costs

The third thing is governance, and it means asking questions that nobody used to find interesting. When a company gives its employees access to language models, it quickly discovers it needs tools it did not have: where does the data that goes into the prompts end up? Are we working with a hyperscaler or with consumer subscriptions? Who observes what, and who has access to which information when it no longer sits in a database but is obtained by querying a model? What does all this cost, and who is it charged to, with external providers and token prices that can rise beyond any control?

These are questions of corporate governance, not of artificial intelligence, but without an answer adoption struggles to leave the experimental stage, and this is also where the increasingly concrete interest in bringing AI back inside the company’s perimeter comes from. At Interlogica we have met these questions so often that we built ProxyPT on top of them: it starts from governance and gets to the implementation of agents inside real processes. But the product is the consequence; the premise is that the problem existed before any product.

What happens when these three things are in place

When knowledge, data and rules are in order, AI does something different from making an existing process faster. An example we see up close: in many companies, if a manager needs a chart that is not on the dashboard, what starts is a manual extraction or a procurement process involving IT, a quote and purchasing, and the effort of obtaining a piece of data has taught people to stop asking for it, and eventually to stop even imagining they could. A tool that knows the company’s databases and the jargon of whoever is asking, and that resolves a question typed in a chat on its own, does not shorten that queue: it removes it. We are working on this with AskBI, a still experimental platform for querying your own database in natural language, and what interests us is not the speed but the questions nobody used to ask.

Then there is a deeper effect. The challenge for anyone who organises work has always been to build a complex process with the minimum number of people required, and that challenge has not changed; what has changed is the parameter, because the effort needed to obtain a result of good quality has become a fraction of what it took three or four years ago, and at that point cognitive work is no longer optimised, it is reorganised.

Two things to keep in mind

The first: with very little effort, AI produces results of good quality, not always of very high quality. The difference matters, and those who ignore it go from enthusiasm to disappointment without stopping in between.

The second is a question I have not closed. If knowledge moves from people’s heads to a configuration layer that stays with the company, what is left to the person? I do not believe the answer is “less”, but I believe it has to be looked for, and that in most of the POCs I see nobody is asking it: people stumble into it thinking it is a detail, when it is the main manoeuvre.

If you are starting an AI project and recognise yourself in at least one of the three things above, our approach describes how we work on these topics, and the question we always start with is the same: who is writing your jargon file?