Reclaim Your AI Sovereignty and Your Ethical Walls
Somewhere in most legal AI procurement conversations, usually right after the demo has gone well, a version of the following gets said out loud: to get real value, the system needs broad access to your data. It is delivered calmly, by someone who has said it a hundred times before. In my experience, nobody in the room objects, because it sounds like a detail of implementation. The infosec questionnaire will sort it all out.
The implied proposition being made across the legal market with increasing confidence is that a firm has to choose between using AI or securing their data. The returns from AI genuinely do require deep access, because a system reasoning over a thin slice of your precedent gives thin answers. But the solutions that labs and vendors are selling do not acknowledge or respect the deep and layered ethical walls you’ve invested so heavily in. They build their own permission structures, control centers, dashboards, and sharing widgets. If you misconfigure how a folder is shared, or assign the wrong role, or don’t check the audit trail - it’s your fault, not the vendor’s.
That tradeoff is not real. You don’t need to compromise your own ethical walls and systems to use AI. Your most valuable assets are your knowledge and the access map that governs it. It should never be rebuilt in someone else’s system, format, and subject to their roadmap.
Last month, I published an article on Artificial Lawyer urging firms to reclaim their AI Sovereignty from model labs and vendors by looking beyond Zero Data Retention (ZDR) and building an ontology. Here I want to share more about how you can adopt AI’s potential without sacrificing your ethical walls.
Governance is not the same as enforcement
Several security frameworks are circulating at the moment and they tend to ask a consistent set of questions. Can administrators adjust permissions quickly as teams and matters change? Can access be reviewed and audited on a regular cadence? Can leadership see who is using the tools, where adoption is concentrated, which groups need training?
These questions are important but they all only measure governance: which folder or document is shared with whom, what documents are in the system, who has which role?
What a firm is actually accountable for is ensuring their security walls are rigidly enforced, not just publishing a dashboard. At the instant a partner asks a question, does the system know, for each document it is about to reason over, whether that specific person is actually cleared to see it? Did a client give permission to use it? Not whether a user or administrator remembered to configure it. Enforcement is where your governance controls actually interact with the real world.
Your goal should be to allow any lawyer to share a folder of documents with their colleagues without worrying about every document within it - let the system enforce permissions, not the user.
You should only have one permission model–fragmentation increases risk
The firm's existing access controls have to be the only source of truth. When another tool checks whether a lawyer can see a document, it needs to ask the Document Management System (DMS) as that lawyer using that individual's own identity. The vendor should be a consumer of your access model and never a source of it.
If the vendor's console can grant a user access your DMS would deny, that vendor has become a second administrator of your ethical walls. You are then forced to choose between administering multiple access controls, or simply limiting the availability of sensitive data to these tools. Your goal should be to permit maximum data with minimal risk–you can’t do this when surrendering access control to a different system.
Check permissions at the prompt, not when the data was added
This is the most important criteria, and the one most often hand-waved through, because "we respect your permissions" is technically true of a system that set them up last month.
There are two places a system can decide what a user is allowed to see. Almost every solution out there I’ve seen chooses to decide at data ingestion, baking permissions into the content as soon as it’s pulled in. But permissions in a law firm change frequently and at the worst possible moments. A lateral attorney arrives on Monday with conflicts that require a screen by Monday afternoon. A client asks you to stand down on one side of a dispute. A matter turns sensitive because of something that happened in a hearing that morning. Under this permissioning model, every one of those changes opens a security gap that stays open until somebody goes into each tool to resolve it. Even worse, now you’re relying on a lawyer or admin in your tool to make the right decision about who is allowed to see what.
Instead, you should adopt a model that applies permissions at the moment of each request, checking the prompt against the live state of your firm’s access controls in the DMS before any response reaches the user. This should work no differently than when a user accesses the DMS directly, with no additional compute load or overhead. Update your permissions once in your system of record, and they should flow downstream automatically into all of your tools.
Blocklists the model actually obeys
Some material has to be unavailable to the system even for people entitled to read it. A matter under a protective order. A client whose outside counsel guidelines forbid AI processing of their material, which is now a common clause and getting more common. A situation sensitive enough that the firm decides no machine touches it.
Your system needs blocklists that can control content at the client, matter, document, or even clause-level. User permissions answer whether a given person may see a document. A blocklist defines whether this material may ever enter a system or be exposed to an LLM. Some tools might only have a version of the first, or just rely on user judgement not to import sensitive data.
You can still retain the option to bring data into your tool and sovereign infrastructure while holding it back from AI. Building a dedicated AI blocklist allows lawyers to still read and interact with sensitive documents in the tool while blocking their language from being sent to AI models. This gives you further control and options on where and how your documents get used.
You should also ask what happens to content already in the system when a blocklist rule is created - can you ensure you’re also looking backwards to remove data that shouldn’t be there anymore?
Keep your own audit trail
Ask your vendor where the audit trail lands.
If the answer is a dashboard inside the vendor's product, you now have two records of who accessed what: the one your DMS has kept for years, and a new one that a committee has to reconcile with it. If instead the system also records its access events back into your DMS under the individual user's own identity, then your existing audit reporting sees AI access the same way it sees every other access, and nothing needs reconciling. A vendor dashboard is a second source of truth about access, you should insist on keeping your existing one.
No bespoke integration for each identity provider
If enforcing your walls requires a custom integration project against your specific identity stack then you’re still introducing another layer of complexity and brittleness. Your access controls are already integrated with your DMS, you shouldn’t need a vendor to build yet another integration layer, just use the permission APIs your DMS already exposes. There is a sovereignty edge here too: a permission integration built bespoke for you, using a vendor's model of your access structure, is one more thing that does not travel when you decide to switch vendors.
Ethical walls are about AI sovereignty
The reason this false choice between AI enablement and ethical walls keeps persisting is that it gets portrayed as a security tradeoff when it is really a question of ownership. A firm that hands over its document corpus and lets a vendor rebuild or replicate its permissions has not simply accepted some confidentiality risk. It has moved two of its most valuable assets, the knowledge and the access map governing it, into somebody else's system, in somebody else's format, subject to somebody else's roadmap.
I’ll ask the same question I asked in my AI sovereignty piece for Artificial Lawyer: If you had to leave this vendor tomorrow, what would you take with you? And while you’re here, who decides who sees what, and where does that decision physically get made?
The right answers are that the knowledge is yours in a form you can export, and that your firm maintains a single source of truth for access controls. Every tool you use should respect those controls as they exist at the moment an individual makes a request, rather than maintaining its own version of them. Those are not competing requirements. That is the standard we hold ourselves to at Draftwise, and I would encourage firms to hold the rest of the market to it, too.
