The next AI failure in your firm will not look like a failure. It will look like competent work product that nobody authorized. Olga V. Mack made that argument in Above the Law on the last day of August, in a piece called The Next Legal AI Problem Is Not Hallucination. It Is Authorization., and she is right about the shape of the problem. Law firm AI governance is about to stop being a question of whether the machine got it right and start being a question of who let it decide.

Her frame is the corporate one, and that is the right place to notice this first. An agent reads a limitation of liability accurately, measures it against the company standard, decides the deviation is minor, and accepts. The analysis is clean. The decision was never anyone’s to make at that level. Her line for it is the one worth keeping: correct interpretation does not establish permission to act.

What I want to add is that this arrives in a three-lawyer family law firm sooner than it arrives in a legal department, and it lands harder when it does. A corporate agent that accepts a clause has created a contract problem, and contract problems get renegotiated. An agent in my practice that drafts and sends has produced something with a bar number on it.

I met this problem already, and the system said no

This is not speculative for me. I asked an attorney at my firm to have the AI draft the initial pleadings on a live matter. It thought for a long stretch and refused, and it named two blockers. The matter was not covered by any signed agreement, and the intake was not finished. Both were accurate. There were no completed intake forms and there had never been an intake call.

Read that as an accuracy event and you learn nothing. Read it as an authorization event and it is the whole argument. The tool had not misunderstood the file. It understood the file and concluded it lacked permission to act on it, which is exactly the behavior Mack says organizations will need to build and mostly have not. I wrote that afternoon up separately as the day the AI refused to draft the petition, because the refusal was the most useful thing that happened in my office that week.

Then I tried to override it. Search the file and proceed from what you know. That produced nothing either, and it should not have. There is no prompt that manufactures a signed engagement agreement.

Law firm AI governance at three people looks nothing like a delegation matrix

Mack’s answer for a company is an authority layer with decision rights, approved positions, prohibited commitments, permitted deviations, escalation triggers, and a record of who authorized what. Every word of that is right and none of it survives contact with a firm that has no procurement function, no approval workflow tooling, and no policy binder. So the small firm version has to be built out of things a small firm actually has.

The first is posture, written before anything else. Every project I open starts with two lines: where the matter folder is, and what the AI is in this matter. On a mediation the instruction says this is a mediation, you are a neutral, make no assumptions, do not add provisions. On a representation matter it says we are the advocate. Same tool, same firm, materially different authority, decided in one sentence at the top rather than inferred later from tone.

The second is a gate on the front end. Drafting does not begin until a signed engagement agreement covering that specific matter is in the file, the intake form is complete, and the intake call has happened. Not two of the three. A gate inside the system does not make exceptions for a client it likes and does not forget on a short-staffed Tuesday.

The third is the hard stop that never moves. Nothing gets filed with caselaw in it until it has gone through a paid research database. My research capability is built to enforce that from its own side: it flags its own authorities as unverified rather than asserting them, and where it has no research it refuses to research and hands back a prompt to take elsewhere. That architecture is the subject of the research library that refuses to do research, and it is an authority limit wearing accuracy clothing.

The fourth is the scope of what it can read and what it can do with what it reads. Read only on the inbox, not send. Editor on the calendar, because somebody has to be able to put a hearing on it. Nothing at all on the folders where nothing needs creating. Delegation is not a single switch, and treating it as one is what makes staff refuse it, which I worked through in delegate access without reading anyone’s inbox.

And the fifth is the one that does not bend. It never clears a document for filing. The attorney signs. That is not a configuration choice I made for comfort, it is the line the whole arrangement is built around.

Some authority in a law firm cannot be delegated to anyone

Here is where the practice diverges from the procurement case, and it is the part I would press furthest. In Mack’s example the authority to accept an indemnity provision exists somewhere in the company. It sits with a general counsel or a committee, and the design question is routing. In a law firm a category of decisions cannot be delegated at all, to a machine or to a person. A signature on a filing, an opinion on reasonableness, a position conveyed to opposing counsel, a representation to a court. Those attach to a licensed human being and no approval matrix relocates them.

So the authority layer in a firm is not only about who approves. It is also about what is structurally non-delegable, and that list is shorter than lawyers assume and longer than technologists assume. Assembly, retrieval, arithmetic, ledgers, day counts, cross-checks against a document, first drafts, all delegable. Judgment a court will attribute to you is not. Writing that boundary down is the work, and it is legal work rather than technical work, which is Mack’s point about lawyers designing this layer before deployment rather than after.

The rules already exist. They are in one person’s head.

Mack observes that companies will find their answers scattered across policy documents, playbooks, delegation schedules, emails, and the memories of experienced employees, with some of it conflicting and some of it amounting to ask Legal. That is more true in a small firm, not less, and for a sharper reason. There is often no policy document at all. The authority rules are entirely in the owner’s head, they have never been written in any form, and the firm has functioned for years because the only reader was the person who already knew them.

That works until something else starts reading. Then the knowledge that lived in someone’s judgment has to exist in the configuration, it does not, and no amount of careful prompting substitutes for it.

Four questions to answer before you connect anything

So write the authority layer down, and keep it to four questions rather than a governance program. What may it do without asking me. What may it never do regardless of how confident it is or how routine the task looks. What changes those answers, and in family law that list is short and specific: anything sworn, anything with a deadline attached, anything that goes to opposing counsel or the court, anything that moves money, anything a client will read as advice. And who approves the things it cannot do alone, named, so approval is a person rather than a state of mind.

Half a page. It will feel too obvious to be worth writing, and it is the difference between a system that stops and a system that proceeds.

Design for refusal, because confident and wrong is the expensive one

Mack’s closing distinction is the one to sit with. A hallucination is a visible failure. An invented case gets caught, or at least it can be. Unauthorized action looks entirely competent right up until the firm discovers a commitment nobody meant to approve.

For a law firm I would put it slightly differently, because we should want the opposite of what most software vendors are selling. Build for a system that hedges, that flags its own work as unverified, that declines and tells you why. Every one of those behaviors reads as a weakness in a demo and every one of them is the feature, because a tool that never expresses doubt trains you to stop reading it, and the day it is wrong is the day you are not looking. The refusals are not friction in the product. They are the product.

Hallucination is a filter problem, largely solved by configuration. Authorization is a design problem, solved by a lawyer deciding what a system may do and writing it down before the system is capable enough for the question to turn urgent. Mack is right that the question is moving from whether the AI got it right to who gave it the right to decide. In a firm that answers to a bar rather than a board, that question was always going to arrive first.

None of this is legal advice, and your own bar’s rules on supervision, on nonlawyer assistance, and on the use of these tools govern what you may delegate and what stays with you. Verify them against your jurisdiction rather than against this article.

If you want the authority layer built into the systems rather than living in a document nobody opens, that is what the install actually is on my side. Bring the four answers to a custom build strategy session and we will encode them. And read Mack’s original, which is the better statement of the general case than anything I would write about it: The Next Legal AI Problem Is Not Hallucination. It Is Authorization., Above the Law, August 31, 2026.