Lawyers · Edu Ramírez

The three AI risks a lawyer should understand

Wed, 10 Jun 2026 00:00:00 +0000

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.

This article includes a diagram: see it on the web version.

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.

The man from the jungle and the invention of AI

Mon, 18 May 2026 00:00:00 +0000

I had a history teacher in school who had spent time on the banks of the Orinoco. We called him the man from the jungle. Once he told us that in that village the butchers gave away cow brains because no one saw any value in them. He started cooking them for his friends. Within a few months everyone was cooking them, and the butchers put a price on them.

That same teacher taught us Edmundo O’Gorman’s idea: the invention of America. Columbus reached the Caribbean believing he had found the Indies, and died convinced of it. The idea of a new continent existed in no one’s mind. It had to be invented afterward, with cartography and violence, because the European mental map had only three parts. O’Gorman goes further: America was not waiting to be described. The very act of thinking it brought it into existence.

I think again about the man from the jungle. We are in the middle of inventing something, in O’Gorman’s sense.

I’ve been writing software for fifteen years. For the last year and a half I’ve barely written code. I build more, in less time, with fewer people. I founded Trifolia, an AI company for Chilean lawyers. I watch them cross the same threshold I crossed, with the same look of bewilderment. A lawyer friend, one of our most loyal users, told me recently: “When you first mentioned it I kept thinking, how am I going to hand the drafting of a brief over to a machine, it didn’t fit in my head. In the end it was pure blindness.”

It didn’t fit in my head. That’s Columbus’s phrase before the Antilles. What my friend calls blindness was the first moment of every invention. The new category doesn’t fit until the map rearranges itself to receive it.

I still don’t know what this thing I work with is. Some days it looks like a strange crystal: I aim a prompt at it and it projects shapes that were already in the books, on the internet. A big, ancient mirror. Other days it looks like a being that pursues goals, trained to maximize a reward, that we keep in a straitjacket so it drafts without doing harm.

Neither describes something that’s already there. Each metaphor manufactures a different AI, and whoever wins the battle of metaphors will determine what all of this ends up being. The invention produces the continent.

And in inventing it we are inventing ourselves. My friend, who used to think about law from the drafting of briefs, no longer thinks the same way. I, who was a programmer, haven’t for a while either. The butchers of the Orinoco put a price on meat they used to give away, and in doing so they changed their trade without realizing it.

I write this as an invitation. To step away for a moment from the conversation about GDP and existential risk, and enter an older one: how we make room in our heads for something that doesn’t yet fit. Humanity has been through this before. When someone lit a fire. When the Polynesians arrived by canoe at islands that weren’t on their map. Each time it took us generations, and it almost always came at a high cost. This time, hopefully, we’ll be a little more careful.

Originally published on LinkedIn on May 18, 2026.

When an engineer and a lawyer don't understand each other

Wed, 11 Feb 2026 00:00:00 +0000

There’s a conversation that keeps happening. An engineer tries to explain what a language model does and falls back on “neural networks,” “tokens,” “parameters.” Across the table, a lawyer nods with the courtesy of someone who stopped understanding two sentences ago. Then each goes back to their office convinced the other doesn’t speak their language. And both are right.

I’ve seen that gap between the technical and legal worlds up close. Few people cross it with ease, and I want to be good at that, because the problem is real: lawyers make decisions about technology they don’t fully understand, and engineers build tools for a legal context they don’t fully grasp either.

When I founded Trifolia, I was clear about what I didn’t want: another company of engineers selling engineering solutions to lawyers, with the Silicon Valley mindset that technology explains itself. That doesn’t work. What we want is to solve legal problems, to start from legal practice and use technology as a means, not an end. And for that, the first step is education: that the lawyer understands what’s behind these tools. Not to become an engineer, but to stop depending blindly on whoever sells them the software.

With that conviction I put together “Technical Foundations of AI for Lawyers”: 20 interactive slides that run from what an LLM is and how it generates text, to hallucinations, context windows, data privacy, and practical considerations for legal work. The material is completely open (CC BY-NC-SA 4.0): educacion.trifolia.cl.

One clarification: these slides are support material for a live presentation. Some aren’t completely self-contained; I’m working on that.

We’ve used it in two workshops run from Trifolia:

University of Talca (January 2025): in-person workshop, 65 attendees (video available).
Online workshop (February 6, 2025): 100 attendees.

100% of attendees said the content exceeded or met their expectations, and 86.3% felt the level was right. The remaining 13.7% found it too advanced, which tells me we’re treading the right edge.

But satisfaction surveys measure perception, not accuracy. And at this stage what I need most is feedback:

Engineers (especially software and ML): Did I oversimplify anything to the point of making it wrong? Making the complex accessible always runs the risk of distorting it.
Lawyers: Am I falling into unnecessary jargon? Or, on the contrary, am I underestimating what you already know? The sweet spot is hard to find without your eyes.
Law professors: I’d love for this material to help you explain these technologies to your students. If you use it, tell me what works and what doesn’t.

There’s a feedback form in the slides, or you can write to me at educacion@trifolia.cl. The repository accepts issues.

Originally published on LinkedIn on February 11, 2026.