Product

Governable Before Powerful

In a firm, access to information is never uniform. It is the first obstacle to serious AI adoption, and the most rarely named.

In any serious legal organization, access to information obeys a strict structure. A sensitive matter is open only to the team handling it. An internal note stays internal. Certain clients cannot be mentioned before certain teams, due to conflicts of interest. Certain documents are protected by professional secrecy, others by contractual confidentiality commitments. This permissions structure is not an administrative detail one could settle after the fact; it is a constitutive dimension of the craft, on the same footing as legal competence itself.

Consumer AI tools, and even most dedicated tools, almost entirely ignore this structure. They operate on undifferentiated access: if the document is in the system, it is in the system. The model does not distinguish a matter under a Chinese wall from an ordinary one; it does not know that an associate has no legitimate reason to see a neighboring team’s pieces. The AI layer is laid over the organization like a uniform sheet, and in doing so, it flattens the access rules that structure it as if they did not exist.

One must name this obstacle, because it is the most rarely formulated and yet the most decisive. One speaks endlessly of the power of models, the quality of their answers, their speed. One almost never speaks of their governability, that is, of an organization’s ability to control, through them, who accesses what. Yet that is exactly where adoption plays out in a firm: not on what the tool can do, but on what it allows to guarantee.

The question is not whether the AI is powerful. The question is whether it is governable.

The real brake on adoption is not the user

One readily explains the slowness of AI adoption by the supposed resistance of users, their caution, their attachment to habits. In the field, this is rarely the reality. Users want these tools; they even demand them, often impatiently. Those who block are not the users, they are the leaders: partners, legal departments, KM heads, IT departments. And they do not block out of conservatism, but because they cannot, in conscience, validate a deployment that makes their permissions structure invisible to the layer that produces.

Their refusal expresses no distrust of their own teams. It expresses an impossibility of principle: committing a firm’s responsibility on a system unable to say, at any moment, who has access to what through it, is simply untenable. The blockage is therefore not cultural, it is architectural. And an architectural blockage is not lifted with change management or training sessions; it is lifted by changing the architecture. This is why so many adoption programs fail after betting everything on training: they treat an architecture problem as a culture problem.

Adoption does not stumble on users’ will. It stumbles on the impossibility, for leaders, of validating the ungovernable.

A concrete example makes it tangible, because it replays identically in many firms. A project to deploy an AI assistant at scale is launched. It is backed by management, funded, awaited by the teams who tested and loved it. Everything is ready. And the project stops dead at the security committee, on a single question, calmly posed by the compliance officer: can you guarantee me that an associate assigned to matter A will never, by querying the assistant, surface a piece from matter B, placed under a Chinese wall?

If the answer is no, or even a hesitant yes, the deployment will not happen, whatever the elegance of the tool or the enthusiasm of the teams. And this refusal is perfectly rational. A single wall breach suffices to engage the firm’s responsibility, to compromise a mandate, sometimes to have it removed from an entire transaction. Against this risk, the tool’s power weighs nothing. One does not trade an ethical guarantee for a productivity gain, however real. The leader who blocks is not mistaken: they are doing their job.

A single wall breach costs more than a tool will ever save.

What power cannot buy back

There is, in leaders’ refusal, a logic tool designers grasp poorly, because they reason in capabilities when the leader reasons in risks. For a designer, a more powerful tool is a better tool; for a leader, a more powerful but ungovernable tool is a greater risk, because it does more things without one being able to guarantee it will not do the one forbidden thing. Power and governability are not on the same scale: one measures what the tool can do, the other what it can be prevented from doing.

This asymmetry explains why no performance gain buys back a governability defect. A tool that saved two hours a day but could not guarantee the tightness of a Chinese wall will not be adopted, because the two hours saved in no way compensate for the risk of a breach. It is not an ordinary profitability calculation, where one would weigh the pros and cons; it is a threshold, below which nothing is negotiable. Below that threshold, the tool’s power simply does not weigh in the balance, because it is on the wrong side of a line the leader cannot cross.

One then understands why the race for performance, which occupies the whole market, misses what really decides adoption in a firm. To optimize power is to improve what was already not the blocking point. The blocking point is elsewhere, in a box demonstrations never address because it is nothing spectacular: the ability to guarantee, coldly, who sees what. It is this box, and not the brilliance of the answers, that decides whether a tool clears the security committee or not.

Why compartmentalizing upstream does not suffice

It is sometimes objected that it would suffice to compartmentalize the data upstream, to give the tool access only to what each person can see. The idea seems simple and reassuring, but it is unmanageable at the scale of a living firm. For a firm is not a fixed structure where each person would have, once and for all, a stable access perimeter. Teams recompose at each matter, walls go up and come down with mandates, the same person has different rights depending on the matter, sometimes depending on the week.

This permanent mobility is the rule, not the exception. A partner can be barred from a matter on Monday due to a conflict, then admitted on Thursday because the conflict resolved. An associate can work in the morning on a transaction and find themselves, in the afternoon, denied access to a competing matter. Permissions are not a state one configures once; they are a flow, hugging the firm’s movements in real time. A static compartmentalization, configured upstream, is obsolete the very day it is set.

This is why the only tenable answer is not to freeze accesses, but to carry the rules dynamically, at each request. The layer must know, at the precise moment a user queries it, what that user is entitled to see that day, on that matter, given the current state of the walls. This evaluation cannot be delegated to a prior configuration, because configuration does not keep the firm’s pace. It must be done on the fly, at each interaction, by a layer that knows the state of permissions at the instant it answers.

Permissions are not a state you configure. They are a flow you must follow at each request.

Permissions live in the layer, not in the prompt

The lesson is that you do not manage permissions, confidentiality, access regimes and internal walls in a prompt. A prompt is a one-off event; permissions are a permanent structure. You manage them in the architecture, in a layer designed to carry and apply them at each interaction, without exception and without depending on the user’s vigilance. This is why MAX was conceived, from the outset, as a layer above the models and not as an assistant at their level: a layer that knows the organization’s access rules and enforces them by construction.

One must measure what “by construction” means here, for it is the heart of the matter. A layer that applies permissions by construction cannot breach them, even if the user formulates a request that, without it, would lead there. Respecting the walls depends neither on the caution of the one querying, nor on a setting one might have forgotten to update; it is inscribed in the very functioning of the layer, which evaluates rights before answering and never surfaces what the user has no right to see. It is this structural guarantee, and not a promise of good conduct, that leaders demand before authorizing a deployment.

The truly adoptable legal AI is therefore not the fastest nor the most impressive in demonstration. It is the one about which an organization can say, at any moment and without hesitation, who has access to what through it. Governability is not a constraint added to power after the fact; it is the condition for power to be, one day, allowed to serve. An ungovernable tool, however powerful, stays at the firm’s door; a governable tool, even less spectacular, enters and stays.

A layer that does not carry access rules is not an infrastructure. It is a demonstrator that will stay at the door.