Governing AI focused only on following the rules can make a company cautious where the risk is small and careless where it is large; worrying about being compliant does not necessarily mean deciding with awareness
The same company, two tables
There is a scene that repeats, with small variations, in many organizations.
At one table, someone has proposed using a language model to clear a backlog of requests that today keeps three full-time people busy. The project is on hold. Not because it doesn't work: it works, it has been tested. It is on hold because "first we need to be sure everything is compliant," and nobody quite knows what that means, or who is supposed to say so, or when the wait will end. In doubt, the company waits. The three people stay on the backlog.
At another table, meanwhile, the same company has just uploaded its internal documents into a convenient, inexpensive subscription service run by a provider on the other side of the world. Nobody asked what happens if that provider doubles its price tomorrow, changes its terms of use, shuts down that feature, or is simply unreachable on the day it is needed. It all went smoothly: no meeting, no review, no doubt.
Two tables, two mistakes. And they are mirror images. Where the risk is small, everything was blocked out of caution. Where the risk is structural, nobody raised an eyebrow. The same company, in the same month, is at once too timid and too reckless.
It is worth taking seriously the question this scene suggests: are companies really thinking about AI and its adoption? Or are they only trying not to fail in the way that would show the most?
The caution that shows, the cost that counts
When a company talks about governing AI, it almost always means one thing: staying compliant. Respect for the rules, attention to compliance, the need to be (and to feel) in order, not to find someone tomorrow deciding in our place because we didn't do it ourselves. It is a legitimate concern, and in many cases a well-founded one. But it is a defensive concern, and a defensive concern gives rise to a defensive question: what can't we do. Almost never the opposite one, what could we do and aren't doing.
The difference is not a matter of nuance. Whoever starts from "what can't we do" measures every project by its worst side, and waits when in doubt. There is the concern to protect users and stakeholders. Waiting seems the safe choice, the one that costs nothing. And here lies the mistake: waiting has a cost, it just doesn't appear anywhere at first.
Prudence and protection are legitimate, when handled with awareness.
A backlog of requests that stays long, three people who keep doing work a machine would handle in a quarter of the time, a service that stays mediocre when it could improve: none of this ends up in any budget. There is no line that says "this year we lost so much because we didn't adopt." Being compliant is often a state you can display and claim; the benefit you gave up is, in many cases, barely visible, and nobody claims it. So one column weighs and the other doesn't, even when, put on the scale for real, they would tip the other way.
Giving up a clear benefit is a decision, exactly like adopting it. It has consequences, it has a price, and someone should put it on the record. When instead the choice to forgo disguises itself as a non-decision, as "we're just waiting to be sure," it drops out of the count. It is not prudence, it is apparent prudence: real prudence weighs both sides and chooses, this one looks at only one and calls not choosing safety.
And there is an asymmetry that makes the whole thing almost comical, if it weren't costly. A small internal experiment, harmless, that at most produces a draft to be checked by hand, ends up being asked for a mountain of guarantees, opinions, reassurances before it gets the go-ahead. The same guarantees that, at the other table, are not asked at all of a far more demanding choice. Caution is not proportional to risk: it is proportional to how visible that risk is.
The carelessness that doesn't show
Let's go back to the other table, the one where no problem had been raised.
Suppose the convenient, inexpensive service has worked well for months. A real part of the work has come to rest on it: the first reply to customer requests, the sorting of incoming mail, a draft summary for every case. Nothing flashy, but by now the workflow runs on it. People have reorganized themselves around that tool, and at that point the tool is no longer an experiment: it is a piece of infrastructure, even if nobody has ever called it that.
Then, one morning, it doesn't work. Not because of a fault, not because someone forgot to pay. It works perfectly, just not for you. The model the workflow was built on has been made unavailable to those on your side of the world: a decision taken elsewhere, in another jurisdiction, for reasons that have nothing to do with the quality of your work and over which you have no say. You open the service and read, more or less, that the model may not exist, or that you may not have access to it. It has already happened, and it is not a hypothetical scenario.
Here dependence stops being an abstraction. It is not fear of the cloud, it is not technological-sovereignty talk: it is a very concrete question, one that should have been asked earlier. If that piece switches off, does the company stop? And if the answer is yes, is it an answer someone chose, or just what happened because nobody had thought about it?
There is an enormous difference between a system that switches off and one that degrades. One stops working; the other keeps working worse: slower, less brilliant, perhaps falling back for a few days on a more modest in-house solution while the situation clears up. The second is almost always possible. But it is a possibility that exists only if it has been prepared in advance. The day the service doesn't respond is too late to invent it.
And here is a path that is rarely named, even as it is constantly invoked. There is much talk, these days, of privacy, of technological sovereignty, of not depending on those far away. They are the right words. But often they stay words: they are waved like flags, and then nobody goes to check whether there is a concrete way to give them substance. There are models that can be run in-house, on your own infrastructure, without sending data anywhere; and there are use cases, not all but more than one would think, in which a local model, perhaps less brilliant than the fashionable service, would be more than enough. Almost nobody goes to verify it. It is easier to repeat the principle than to measure it against the concrete case.
The suspicion, in certain settings, is that speaking in slogans ends up becoming almost inevitable: it is convenient, it makes you look as if you have taken a stance without the obligation to dig deeper. But it is a mistake that can be paid for dearly. The day the distant service is switched off, the slogan about sovereignty keeps no workflow running. What would have kept it running was only the work, done in time, of figuring out whether an in-house alternative was really possible.
And here lies the point that ties this section to the previous one: this risk doesn't frighten as much as staying compliant does. It is slow, it is invisible until it shows itself, it has no article of law that names it, and nobody will come to call you to account for it. That is why nobody puts it on the record. Dependence on a technology that someone else can decide to cut off from us is not a less serious risk than a breach of a rule. It is only a risk that frightens less, because it has no institutional face to embody it. And so it stays uncovered precisely where, elsewhere, every caution had been taken.
It's not goodwill that's missing, it's a language
At this point one might think the two lines describe two different companies: one too timid, the other too distracted. Instead they are the same company, and the two behaviors come from the same place. Not from bad will, not from laziness. From a void.
The void is this: a common language for deciding is missing. Shared criteria are missing to say, of any project, how risky it really is, how critical it is to everyday work, how much it depends on someone outside who can change their mind. Without these criteria every project is judged by feel. And feel does not follow the real weight of things: it follows what frightens most in the most visible way, that is, not being compliant, having to answer to someone. The risk with a recognizable face always wins over the risk without one, even when the second weighs more.
It is the same thing, seen from two sides. At the table of the internal experiment, feel says "careful, here we could fail in a way that shows," and brakes. At the table of the external service, feel says nothing, because that danger does not have the shape we are used to fearing, and we go ahead. Two opposite reactions, the same missing criterion.
From here a question worth asking out loud: is there a shared way of talking about these things? A common taxonomy, a vocabulary on which two people in the same company, or two different companies, mean the same thing when they say "high risk" or "critical" or "we can handle it in-house"? The honest answer, today, is no, or not enough. Even the names for the different levels at which one can approach these technologies are missing: there are those who use them in passing, those who build a process on them, those who bring them into decisions that affect people, and all of this often falls under a single word, "AI," as if it were the same thing. It isn't, and treating it as if it were is exactly what leads to being cautious where it isn't needed and careless where it would be.
You can't govern what you don't know
The common language that is missing, the one just mentioned, is not a form to fill in. You don't build it by buying a template or calling a meeting. To build it you have to know the subject, and to know it you first have to do something organizations find difficult: admit they don't know it well enough yet.
Admitting "we don't have a command of this" sounds, inside a company, like a weakness, all the more for whoever is supposed to govern that topic. So one often prefers to go ahead with an air of confidence, a little superficiality, a little presumption, as if having heard of it were enough. But you can't govern what you don't know well. Governing a technology you haven't understood is not governing it: it is hoping it goes well, and calling that governance.
Understanding AI means several things, and almost none of them has to do with the rules. It means understanding what it is and what it is not, taking apart a bit of the magic word. It means recognizing the levels at which it can be integrated into an organization, because a tool used now and then and a system that enters into decisions affecting people are not the same thing, and are not governed the same way. It means seeing its implications: technical, methodological, and also social, on work and on those who do it. None of this can be improvised. It takes competence, study, training, time.
And here is the point, almost a provocation. It is right, perfectly right, to dedicate resources to reading the rules, to being advised by those who know them, to going deeper into the legal aspects: it is needed, it must be done. But is it equally right, and above all is it equally done, to dedicate resources to understanding the technology, the method, the social implications? Often not. Often the legal column has a budget and the understanding column has a couple of webinars and a lot of self-confidence. That imbalance is itself a symptom: it says the organization still thinks governing AI is a legal matter, and not also, first of all, a matter of knowing.
There is nothing to be ashamed of in saying "on this we need to study, we need to train." If anything, if there is to be any embarrassment, it lies in deciding on something one has chosen not to understand. You can't govern from the outside what you have never been willing to look at from the inside.
The real question
When a company asks itself whether it is governing AI well, the question it asks, almost always, is just one: are we compliant? It is a good question, but it is the question of the floor, not of the direction. It says where you can't go below, not where you want to go.
The real question is another: do we know how to decide about AI? Do we know how to tell where the risk is real and where it is only imagined, where it is worth waiting and where waiting costs more than moving, which tools we can trust and which are tying our hands without our noticing? Staying compliant is a constraint, and it must be respected. But it is the floor. The compass is something else, and almost nobody is looking for it, because they are convinced the floor is enough.
Let's go back, to close, to the two tables of the beginning, and to the question we started from: are companies really thinking about it? Looking at those two tables, the answer is that for the most part they are not thinking: they are reacting. They respond to what frightens most in the most visible way, and they give that reaction the name of governance. The project frozen out of caution and the service adopted without questions are not two unconnected episodes: they are the same company that, having no way to weigh things, puts caution where it shows and removes it where it doesn't. As long as the question stays "are we compliant?", those two tables will keep coexisting, each blind to the other. The first thing to do is not one more rule. It is to realize that the question we are asking is not the right one.