Anyone who uses legal AI tools daily quickly notices: output quality depends less on the model than on the quality of the question asked. Prompt engineering – the deliberate crafting of instructions for an AI system – is not a technical hobby for lawyers. It is a practical work technique with a direct effect on output quality, time spent, and reliability. This article covers ten concrete techniques for getting significantly better material out of legal AI applications.
What prompt engineering means in a legal context
A prompt is the input a language model receives. In everyday legal work, these inputs look like "analyse this contract for liability risks" or "summarise the key provisions". The problem: such formulations are extremely vague for an AI system. The model does not know which party to analyse from, which legal framework applies, how detailed the answer should be, or what format to use.
Prompt engineering addresses this by structuring inputs. The goal is not to learn a secret language. It is to provide context that a human associate would have automatically.
The 10 techniques
The simplest way in: treat the model like a capable but brand-new associate. Smart, fast, diligent – and with zero knowledge of your matters, your firm's practice, or your jurisdiction. Anything you would tell that associate when handing over a task belongs in the prompt. The ten techniques are really just a system for doing that.
1. Assign a role
A bare question forces the model to guess which vantage point to answer from, and it guesses the average. Give it a function, and the entire frame shifts.
Weak: "What does this clause say?"
Strong: "You are a contract lawyer specialising in M&A, acting for the buyer. Analyse the following warranty clause."
The role controls two things at once: the perspective (whose interests count) and the assumed prior knowledge (the model skips explanations a specialist would not need). The more specific, the better – "M&A lawyer focused on tech transactions" beats "lawyer".
2. Name the legal framework
In a Swiss context this is the most overlooked technique, because the framework is obvious to you and invisible to the model. Language models carry Swiss, German, Austrian and US law in their training at once. Without a constraint they blend these sources, and a liability assessment under the German BGB is simply wrong in a Swiss matter.
Weak: "Is this liquidated-damages clause valid?"
Strong: "Assess the validity of this liquidated-damages clause under Swiss law, in particular CO Art. 160 et seq. and judicial reduction under Art. 163 para. 3 CO."
Rule of thumb: if the same prompt could apply unchanged to a German or US matter, it is too broad. For special statutes (FADP, financial-market acts) or cantonal law, doubly so.
3. Prescribe the output format
A model with no format instruction returns running text – the least practical format for almost any legal task. If you want to move the result into a client email, a risk matrix or a memo, you end up reformatting by hand.
Weak: "Summarise the risks in this contract."
Strong: "Create a table with the columns clause, risk, severity (low/medium/high), recommendation."
The format instruction saves time, but it also forces a disciplined analysis, because every cell has to be filled. An empty "recommendation" column is obvious at a glance; a point quietly buried in a paragraph is not.
4. Fix the perspective
A contract clause is never neutral. The same limitation of liability protects one party and disadvantages the other. If the prompt does not name the side, the model describes the clause from both angles, and that is useless in a review. It gets delicate when the counterparty submitted the draft.
Weak: "Review this lease."
Strong: "From the tenant's perspective, identify which clauses deviate from default statutory rules to the tenant's disadvantage, and flag the three most critical."
The perspective belongs in the prompt explicitly – including what you are checking for: terms adverse to your own client, not legal correctness in the abstract.
5. Build in negative instructions
Sometimes the problem is not what the model should do but what it should leave alone. Models like to pad answers with background – the general legal position, definitions, context you know cold.
Weak: "Explain the liability in this contract."
Strong: "Do not explain the general legal position on liability. Focus only on clauses that deviate from market standard, and do not propose any wording that changes the place of jurisdiction."
Negative instructions are underused, because the instinct is to instruct positively. Yet the omission is often the bigger lever.
6. Supply context from the document
In long contracts, do not rely on the model to jump between a clause and its defined terms on its own. When the two sit far apart, the model loses the link – result: a formally plausible but substantively wrong answer.
Weak: "Is the warranty in this contract market-standard?"
Strong: "Assess the following warranty clause in conjunction with the definition of 'material defect' in section 1.3: [clause text] [definition text]."
Equally important, and far from a side note in a Swiss data-protection context: whatever you paste into the prompt field has to match the tool's confidentiality level. In consumer tools without zero data retention, client data, personal data and trade secrets have no business in a prompt. This single point decides whether a tool is fit for firm use.
7. Stepwise instructions (chain of thought)
Posing a complex task in a single command leads to omissions – the model jumps to the result without working through the steps. Break the task into a sequence and you force it through the reasoning.
Weak: "Do a due diligence summary of these contracts."
Strong: "First, list all clauses with a liability dimension. Second, assess each one under Swiss law. Third, formulate an overall recommendation with prioritisation."
Chain-of-thought prompting does two things. It reduces missed points, because each step is explicit. And it makes the answer auditable: if the result is off, you can see which step the model took a wrong turn at, instead of discarding a black box.
8. Provide examples (few-shot prompting)
An abstract instruction leaves wide latitude on tone, detail and structure. A concrete example closes it.
Weak: "Draft a liability clause."
Strong: "Draft a liability clause in the style of the following model clause from our firm: [model clause]. Keep the diction and structure, adapt only the facts."
The model then has a calibration point and matches length, diction and structure far more consistently. Especially effective for recurring tasks whose style should stay constant across many documents – standard clauses, summaries, client correspondence.
9. Address knowledge gaps explicitly and ask for sources
Language models have an awkward trait: they sound confident even when guessing. In law that is dangerous – a plausibly worded but wrong statement makes it into a document unchecked. Hallucinated court decisions are not theoretical: more than a thousand cases worldwide have already been documented in which fabricated citations reached real filings, with cost consequences for the lawyers responsible.
Weak: "What case law is there on this question?"
Strong: "Support every legal conclusion with a specific source (Federal Supreme Court decision, cantonal decision, statutory article). If you cannot answer reliably, say so explicitly and flag the passage for legal review."
This does not lower the model's error rate, but it separates safe statements from unsafe ones and gives you a starting point for verification. The duty to cite does not replace the review; it makes it possible. Every citation must be verified independently, with any tool.
10. Work iteratively
The first prompt is almost never the best. Trying to pack everything into one perfectly phrased input usually produces an overloaded monolith the model only partly executes. The opposite is more productive.
Weak: One long prompt with eight requirements, then use the output as is.
Strong: Ask for a rough assessment first, read it, then sharpen – "go deeper on point 3" or "wrong perspective, check from the seller's side".
Each round builds on the context of the last. This is exactly what legal AI platforms with a chat interface are built for: not the one big shot, but the conversation in which the question gets sharper with every answer — like an associate who understands your matter better with each exchange.
How legal AI platforms simplify prompt engineering
Good legal AI platforms already absorb part of the prompt engineering effort. CASUS, a Swiss legal AI platform for law firms and in-house teams, builds its core workflows – contract review, benchmarking, proofreading, and research – so that structured inputs and outputs are built in by default.
In the Risk & Quality Review, CASUS automatically sets the analysis perspective by contract party, prioritises findings by severity (low/medium/high), and delivers concrete drafting suggestions directly in the Word document – without the user constructing a custom prompt. The Benchmark workflow compares a document against an internal playbook or best practices (for example, for NDA or SPA contracts) and shows deviations with a percentage match score and specific recommendations.
For open research questions, the Legal Research mode searches more than 660,000 cantonal and federal court decisions as well as statutory provisions and returns structured, source-based results – with an inline preview of relevant reasoning sections, no click-through required. For complex questions that fall outside a standard workflow, the AI Chat with Agent Mode supports iterative prompt refinement and lets changes be executed directly in the document.
Common prompting mistakes in legal practice
Questions that are too broad. "Analyse this contract" gives the model no anchor for focus, perspective, or depth. The result is correspondingly generic.
Missing Swiss legal context. Without an explicit reference to the CO, CC, or cantonal law, the model may draw on other legal systems. This is a real risk, particularly for liability or contract law questions.
No format specification. Running text is unsuitable for many use cases. A table or structured list can be used immediately; a paragraph needs reformatting first.
Single-shot prompts without iteration. Prompt engineering is a process. Using a first-pass answer directly, without asking whether the question was well formulated, leaves quality potential on the table.
Practical implications for law firms and in-house teams
Prompt engineering does not need to be an individual skill that each team member develops on their own. Law firms can build prompt libraries – a collection of proven inputs for standard tasks such as contract reviews, due diligence checks, or research queries. This makes output quality reproducible and reduces onboarding time for new staff.
For in-house teams with high contract volumes, the AI Data Room is well suited: dozens or hundreds of documents can be analysed in parallel, with extraction fields defined by prompts. Which clauses should be compared? Which deviations should be flagged? The team sets the parameters; the system delivers a tabular overview.
Data protection is not a secondary concern here: CASUS hosts exclusively in Switzerland and the EU, transfers no data to the US, and operates without human review and without data retention. Details are at /security.
Try CASUS
Those who want to test prompt engineering in practice can try CASUS at no cost. The platform runs as a Microsoft Word add-in and as a web app – no IT setup required, no US data transfer. Start for free.
FAQ
What is prompt engineering for lawyers?
Prompt engineering is the deliberate crafting of inputs to an AI system in order to get more precise and usable answers. For lawyers, this means supplying context, naming the perspective, specifying the format, and refining iteratively – rather than asking a general question.
Why do good prompts matter especially in legal work?
Legal texts are precision-sensitive. A wrong perspective, a missing legal framework, or an unclear format specification can make AI output unusable – or worse, can create false confidence. Well-constructed prompts reduce this risk in a measurable way.
Do you need programming skills for prompt engineering?
No. Prompt engineering in a legal context requires no technical background. It relies on clear language, structured thinking, and the ability to describe tasks precisely – skills lawyers already have.
How does prompt engineering differ from a normal search query?
A search query finds documents. A prompt to a language model gives an instruction to process content. The difference lies in interactivity: the model can process context from the document, draw conclusions, and generate structured outputs.
What role does Swiss law play in prompting?
Language models are trained on international data. Without an explicit reference to Swiss law – the CO, CC, or relevant federal statutes – the model may draw on other legal systems. Swiss context must be actively included in the prompt.
Can prompt engineering be standardised?
Yes. Law firms and in-house teams can build prompt libraries: proven inputs for standard tasks such as contract reviews, research queries, or due diligence checks. This makes results reproducible and reduces the burden on individual users.
What is chain-of-thought prompting?
Chain-of-thought prompting breaks complex tasks into sequential steps. Instead of posing a complete task at once, the model is guided through an analytical process: first list, then assess, then recommend. This increases completeness and makes outputs easier to follow.
How secure is legal AI when working with sensitive client data?
This depends heavily on the provider. CASUS hosts exclusively in Switzerland and the EU, transfers no data to the US, operates without human review, and applies zero data retention. Details on the security architecture are available at /security.
