Enterprise AI is not decided on infrastructure, nor on tooling: it is decided on the people who can carry it into the real work, and change it when the time comes.
«Let's extend it to everyone.» The request almost always arrives in those words, and it arrives on IT's desk. Whoever brings it has every reason to: the technology is mature, it costs little, and keeping it in a pen would be absurd. And whoever receives it — myself included — answers instinctively along two tracks, both reassuring and both, in my view, off target. The first is infrastructure: cloud, or a server of our own, closed and protected? The second is tooling: let's give everyone a chat window and see what happens. These are answers to the question where and to the question what, while the real problem is another one: who, and to do what.
A paradox in plain sight tells us that it is the wrong question. Artificial intelligence is already everywhere in companies, and it is used for very little. A presentation put together in a hurry, a retouched image, an email made smoother: useful gestures, of course, but closer to a weekend pastime than to professional use. If this is what we mean when we say «artificial intelligence in the enterprise», then we have spent a great many words to obtain a more sophisticated proofreader. And that gap — between what this technology could do to the work of a department and what we are in fact asking of it — is closed neither by a server of our own nor by a chat window for everyone.
The knot that looks big
Let me clear the ground straight away of the knot that looks largest and is in fact collateral: the fear of entrusting confidential documents and information to the cloud. We have been entrusting our documents to other people's servers for years, every day, without flinching — we do it with email, with shared files, with cloud office suites. The storage risk we accepted and regulated long ago. Artificial intelligence does not reopen that chapter; it adds a different one, the processing risk: a document deposited on a remote disk sits still, encrypted, until someone opens it, whereas a model reads that content, recombines it, acts upon it. It is a real delta, but a delta that closes — with contracts, available today in any serious offering, guaranteeing that data is not retained and not trained upon; and with architecture, that is, by deciding upstream what enters the model and at whose hand. Keeping data on European servers, meanwhile, satisfies the GDPR but not industrial secrecy: it is a slice of the problem, not the problem. And the speed at which the technology evolves — the argument most often used to invoke a fortress of our own — leads to exactly the opposite conclusion: chaining ourselves to our own infrastructure, which depreciates while the frontier moves every quarter, is the real strategic risk. The cloud, here, is not a surrender: it is a way to stay free to change. I say this quickly on purpose, because this is not where the match is decided.
From generation to cognition
The match is decided on what a grown-up use of these tools actually means. Most people stop at generation: I ask the machine to produce something in my place. That is the ground floor. The upper floor is another thing, and it is cognition: the machine that reasons alongside me.
Let me give an example, because abstraction does not help here. Imagine a meeting in which one of the participants is not a person but a model — not to write the minutes, but to take part in the reasoning. The group is about to settle on a choice that seems sensible; the model, which has in front of it the constraints nobody has in mind at that moment, observes that the decision contradicts a commitment made the previous quarter, or exceeds a limit set elsewhere. It does not decide in the group's place: it keeps the discussion anchored to its objectives when it drifts, records the choices as they form, compares them in real time with existing processes and boundaries — up to and including, if one wants, running a brainstorming session. It is the difference between a vending machine and a thinking partner. The first saves you a few minutes; the second changes the quality of what you think.
This is not a laboratory hypothesis. It is what I have seen happen inside Sophron, the system we work with in house: there the model acts as analyst, as executor and as sentinel, and what struck me is not what it does to the work — that part is easy to tell — but what it does to the people who work. Those who step inside start framing better questions, and their way of reasoning changes even when the machine is not there.
Nor is it an isolated case. The same leap happens when, instead of asking «write me this proposal», I ask «take this proposal apart: where does it contradict itself, where does it promise what we cannot deliver, what objection would my most difficult client raise». Or when an action repeated by hand every week — reconciling two lists, checking that a case complies with an internal rule — stops being a mechanical task and becomes a reasoned check, in which the model flags the exception instead of merely executing. In all these cases AI does not produce for me: it thinks with me. And yet almost nobody, today, imagines using it that way. Everyone thinks of the slide, of the photo retouch. And that, precisely, is the threshold beyond which most people's imagination does not go.
Not a problem of use, a problem of imagination
Why do so few reach the upper floor? One would be tempted to call it an adoption problem, but it is not: people are already using artificial intelligence, and plenty of it. It is a problem of imagination. And imagination is not distributed by internal memo. You can buy the best tool on the market and stand there watching it being used to make prettier presentations. The tool does not carry with it the vision of what it could do; that vision lives in people, or it lives nowhere. This is why nobody reaches the upper floor on their own: you get there only if someone, in the department, has already seen what is possible and has the patience to show it to the others.
It is here that the very definition of success must be turned around. We tend to measure it by counting how many small problems we have solved with standard tools, built to last. But this is a domain that punishes stability. That technology changes too quickly for a solution to survive I have already argued elsewhere — it is the end of maintenance I wrote about in The Logical Architect beyond the CMS — and I will not repeat it. The reason I had not seen back then is a different one, and it is economic: over-engineering for durability costs more time and more effort, but obsolescence arrives all the same, so that the «robust» solution we sweated over turns out to be as ephemeral as the quick one — except that it cost us more. To which one should add that the target itself is moving: the small repetitive actions we want to simplify change over time too, and shift with the department. Moving target, moving tool. Provisionality, then, is not a renunciation of quality: it is coherence with reality.
It follows that success is not a catalogue of little problems solved, nor is it a single well-built system — because even the most successful system is a solution, and solutions age. Success is an organisation capable of adopting quickly and safely, of simplifying what is done mechanically today, of governing over time what it has adopted — keeping it authorised, under control, inside a perimeter — and above all of readapting: to a new need, to a new model, to a new way of working, without fossilising on the first pleasant experience some tool has offered. It is the exact reversal of the logic IT has always worked by. Normally one invests in solutions, which must be durable, and treats people as users of those solutions. Here the solutions are disposable, and the durable investment is people. You do not collect a fleet of solutions: you cultivate a capability.
«Solutions are disposable; the only investment that compounds year after year is the people able to change them.»
— Giovanni Aduso
Those who translate
This capability has a precise shape, and it is not the one usually imagined. It is not enough to appoint an AI expert for the whole company: it is necessary, it acts as a stimulus, but on its own it is a voice in the desert. Nor is it enough to put simple tools into the hands of those at the base of the organisation: with nobody to adapt them, those tools stiffen quickly, produce little, and do not propagate. Between the two extremes there is a figure that decides everything: those who translate.
I am fond of the etymology of this verb. To translate comes from trans-ducere, to lead across: those who translate lead the potential of artificial intelligence across the threshold that separates technology in the abstract from the concrete work of a department. It is a bilingual person, who speaks the language of the process and the language of the technology, and who has the patience to sit beside those who would not get there alone.
And here the skill that matters is not the one my own trade would name first: it is not technical. It is the intimate knowledge of how the work is really done — inside which exceptions, with which shortcuts, against which friction — together with the ability to evolve without growing attached to a solution. That knowledge does exist in IT, the department from which everyone's processes are visible; but it is not IT's prerogative, and it is never found whole in a single point of the company.
Which brings me to the most delicate point. The aptitude this moment rewards does not coincide with roles, it does not coincide with seniority, it does not coincide with the org chart. And it is scarce for everyone: it is a skill that until yesterday did not exist, that nobody could demand nor write into a job advert, because it simply was not needed. For this reason the task is not to judge who is up to it. It is to discover where this aptitude already lives — and it lives in unexpected places: in someone who knows a process in its guts and has the mind to change quickly, in profiles no procedure would ever have flagged. Recognising it where it was not expected takes a form of institutional humility: the willingness to look beyond the title on the business card.
And literacy, consequently, comes in layers, and it has a sequence. It starts with those who can act as translators, because they are the multiplier: without them the central expert goes unheard and the tools at the base stay inert. Only downstream, once there is someone able to bring artificial intelligence down into the concrete, does it make sense to reach those further down.
Removing the burden of discernment
Those at the base, in fact, must not be asked to discern. One does not put to them the question that puts even experts in difficulty: what may I upload and what may I not, how far can I trust this answer, where does help end and error begin. That burden is designed outside the tool. One prepares a curated environment, with the right documents already inside and the perimeter decided upstream; one offers a space in which it is hard to go wrong because the risky choices were made earlier, by those who knew how to make them. Trust is not placed in the person: it is embedded in the architecture. It is also the way an organisation governs AI while spreading it — not by forbidding, but by laying the rails — and it is the most respectful way of bringing it precisely to those who need it most, who need it most because today they perform those very actions mechanically, and perhaps with the wrong tools.
A footnote, and no more
Since February 2025 the European regulation on artificial intelligence has required companies to ensure an adequate level of AI literacy among those who use these systems — employees and external collaborators alike — with enforcement phasing in through 2026. It is right to know this. But the law, here, does not create the need: it certifies a gap that already exists. Anyone who governs a company understands it unaided, without Brussels having to write it down. The rule is an authoritative footnote, not the thesis.
The only thing that lasts
In the end, the question we started from — cloud or our own server, one tool for everyone or a closed package — dissolves by itself the moment we accept that none of it is the durable part. The infrastructure we will change. The tools we will change. The models we will change, perhaps ten times over. Even the best-built system, one day, we will build again. The only thing that lasts, that compounds year after year, is an organisation made of people able to adopt them and govern them alongside us, while they change. Everything else is provisional. They are not.