In my AI workshops for lawyers, the questions almost always point to the same risk: what happens to what I type into the chat, who sees it, whether the provider keeps it. It’s a good question, and I’m glad the profession has taken it on board. But it’s the first of three. The third is the one that has me writing today: there are lawyers running programs downloaded from the internet, programs they can neither read nor audit, on the same machines where they keep case files under professional secrecy. The news of these past weeks shows how badly that can end, even for experts. Let’s go in order, but if you keep a single idea, make it the third one.
The first: where does what you write end up?
When you paste the draft of a lawsuit into a chatbot, that text travels to the provider’s servers. The important question is what happens next: whether it gets deleted, whether it stays stored, whether it gets used to train future models. The answer depends on the product and the plan: free consumer versions tend to offer fewer guarantees than professional plans, where no-retention and no-training agreements can be negotiated. The practical rule: before putting a client’s information into a tool, know what the contract says about those two points. And if you don’t know, work as if everything gets stored: anonymize.
The second: who answers for the application in the middle?
Between the lawyer and the language model there is almost always an application: the legal tool that receives your documents, processes them and sends them on. That middle layer is a company, with its servers, its practices and its security, and the market has filled with applications built in weeks. There are objective signals for evaluating them: security certifications audited by third parties (ISO 27001 is the most recognizable), clarity about where data is stored, data processing agreements. At Trifolia we went through that certification, and even so we offer an on-premise option, installed on the firm’s own infrastructure, for clients whose policies demand keeping third-party risk to a minimum. I mention it because it works as a yardstick: it’s the level of answer you should be able to demand from any provider that touches your clients’ data.
The third: what are you running on your computer?
Here is the new part. A surprising number of lawyers are using Claude Code, an AI programming tool built for developers, and others like it. I understand them perfectly: to someone coming from outside, what these tools achieve looks like magic, and I use it myself every day. But it’s a tool from another trade: it’s designed for people who can read what the assistant does and undo what it breaks, and a good part of its power consists, precisely, of running programs on your computer with your permissions.
Around these tools there also circulate “skills”: files that teach the assistant workflows and that get shared on social media as if they were Word templates. I’ve seen skills shared with enthusiasm that invoke programs the author never attached: whoever downloads them gets an incomplete recipe that, luckily, doesn’t run. I say this without any mockery: the good faith is plain. But it shows something uncomfortable: code is being shared and run without quite understanding what it does or what it needs.
And what can go wrong? What happened these past weeks. A computer worm called Miasma is infecting code projects and hides its payload precisely in the files that configure these AI assistants: opening a contaminated project is enough for it to try to steal your credentials. It even reached Microsoft, and days later the complete attack kit was published on the internet, ready for copycats. In May, on top of that, GitHub itself, the platform where the world stores its code, acknowledged an intrusion that began with a poisoned extension for a code editor: a single compromised computer was enough to expose thousands of its internal projects.
On skills there are numbers: a security firm reviewed almost four thousand shared on community sites and confirmed 76 malicious ones. And my favorite example is the quietest one: an email connector that worked normally for fifteen versions, until an update added a single line that forwarded every email, as a blind copy, to the attacker.
The victims of all of the above were professional developers: people who review code and dependencies because it’s part of their trade, in companies with security teams. If it reached them, a lawyer who downloads a skill recommended in a post and runs it without being able to read it takes a greater risk, on the worst possible machine: the one that holds case files under professional secrecy.
That’s why my suggestion, at least for now, is caution with tools from another trade. If you can’t read what a skill executes, and you don’t have someone you trust nearby who can read it for you, that experiment can wait. The efficiency you’re after also exists in tools made for your profession, where the technical side comes solved and someone answers for it.
Walking away from AI entirely would mean losing an efficiency the profession needs. The reasonable path is to adopt it with the diligence the profession already applies to everything else, and that diligence fits in three questions: what happens to what I write, who answers for the application, and what am I running on my computer.
I close with the idea that sums all of this up: the more magical a tool looks, the more professional judgment it demands. I work at that crossing between law and engineering, building tools that absorb the technical part so lawyers don’t carry risks they can’t assess, and I want to keep writing about these translations between the two worlds. The questions from the workshops are the best guide I have; I read every letter.