Something visible is happening in legal practice. Lawyers are automating their own work with AI: Claude Skills, custom GPTs, Copilot agents, shared prompt libraries. A skill packages instructions for a recurring task and turns a general-purpose chatbot into something that feels like a specialised assistant. Contract clauses reformatted in seconds, first drafts of standard letters, judgments summarised, documents converted to house style.
Let us be clear from the start: this is a good development. The time savings on routine tasks are real, and lawyers who build their own skills are learning first-hand how these systems behave. That literacy will serve them well.
But there is a ceiling, and it sits exactly where legal work becomes legal work. This post maps it.
What a skill actually is
A skill is packaged know-how: instructions, examples, sometimes a template or a small script, that steer a general-purpose model through a task, the way a good briefing steers a junior associate. That is genuine value, and it explains the productivity gains.
It is also the limit. A skill changes what you ask. It does not change what the model knows, where your data is processed, or whether anyone checks the output. Those three things are decided by the platform underneath the skill, and in legal work all three are decisive.
The first wall: client data
The safe zone for skills is work on non-confidential material: formatting, structure, boilerplate, public documents. The moment a client file enters the chat window, the picture changes. The document is processed on infrastructure the firm does not control, usually abroad, under terms that vary by provider, plan, and settings. In every jurisdiction, lawyers are bound by professional secrecy and by data protection law (in Switzerland, Art. 321 of the Criminal Code and the Federal Act on Data Protection), and under both, that is not a detail. And when individual lawyers do it through personal accounts, the firm cannot even answer the basic question a client may one day ask: where did my data go?
The standard workaround is anonymization, and it fails three times over. It is manual work, which consumes the very time the skill was meant to save. It is fail-open: one overlooked name or reference in a long exhibit is already a breach. And it often does not anonymize at all, because facts identify people. A dispute between a mid-sized Zug foundation and its former CTO is recognisable without a single name, and professional secrecy covers the facts of a mandate, not just the names in it.
The result is an uncomfortable pattern: skills deliver most where the stakes are lowest, and are excluded precisely from the highest-value work.
The second wall: the model's memory
Simple skills answer from the model's training data, and for Swiss legal work that memory has three problems.
It is frozen. A model knows the law as it stood when its training ended. It does not know which provisions were revised this spring or what the Federal Supreme Court decided last month, and no instruction inside a skill can update it.
It is skewed. Training corpora are dominated by English-language, common-law material. Swiss law is federal, trilingual, and much of its doctrine is not freely available online, so it is thinly represented in exactly the place a skill draws from. The popular legal prompt libraries circulating on GitHub reflect the same bias: most are written for US practice and assume common-law concepts that do not transfer.
It is unverified. Nothing in a plain skill retrieves sources or checks citations, so the model remains free to produce the confident inventions we described in our post on hallucinations. A skill can tell the model to be careful; it cannot hand it sources it does not have, and it cannot check the citations it produces. Which means the entire burden of verification stays with you, and the minutes saved in drafting are spent re-checking every claim.
The third wall: when a skill becomes software
The sophisticated answer to the second wall is to connect the model to live sources: scripts, APIs, MCP connectors that fetch legislation or case law at question time. This genuinely helps, and it is roughly how professional systems are built. But notice what just happened: the skill became software.
Now client data flows through connectors and a cloud model, so the first wall still stands. Every connector is a dependency and a new attack surface: a poisoned web page or document can inject instructions into the pipeline. The underlying model is updated by its vendor on its own schedule, so behaviour shifts silently, and nothing catches the regression, because no law firm maintains a test suite for its prompts. And the scripts themselves need someone to fix broken keys, changed interfaces, and version bumps.
A firm that goes down this road has not adopted software. It has started developing it, without engineers, without quality assurance, and without anyone whose job it is to keep it running. Lawyers are excellent at many things; being their own software vendor should not have to be one of them.
Read backwards, the ceiling is a requirements list
Turn the three walls around and you get the specification for professional-grade legal AI:
- Confidentiality by architecture. Processing on hardware the firm owns, so client data never leaves the office. Not a policy, a physical property.
- Grounding by design. Answers composed from official sources retrieved at question time, legislation as published by the state and decisions from the courts themselves, rather than from the model's memory.
- Verification built in. Every citation checked against the evidence, fail-closed, with anything unconfirmed flagged to you instead of hidden.
- Maintained as a product. Versioned, tested, and supported by people whose job that is, so it keeps working when models and sources change underneath it.
That is not a skill. It is a system, and it is exactly what we are building with Legal Intelligence.
The honest bottom line
Keep your skills. For formatting, structure, and boilerplate on non-confidential material they are the right tool, and building them is the best AI education a lawyer can get. Just draw the line where client data or legal substance begins. Past that line, the useful question is no longer which prompt, but which architecture, and the answer should guarantee a process rather than promise perfection: official sources, verified citations, and data that stays in the office.