Legal AI is moving from answers to legal deliverables

Defining the documents and issues table

The assignment should consequently define the documents to be produced, rather than stopping at the question to be answered. It can identify the agreement, the parties’ roles, the relevant legal framework, the purpose of the review, and the intended recipient of each output. It can specify that the issues table is for the negotiation team, that proposed wording must remain adjacent to the affected clause, and that the client memorandum must distinguish legal analysis from factual assumptions. Output design becomes part of the legal instruction itself.

The first component is an issues table. For each relevant clause, the table can record the applicable requirement, the language found, the character of the issue, and the recommended action. A useful classification separates potential defects against mandatory processor terms from commercial preferences and points requiring factual confirmation. A subprocessor clause, for example, may raise a legal question about the authorization mechanism and a separate factual question about which providers actually support the service. Combining those questions under a vague “risk” label would obscure the decisions required.

Proposed wording and the negotiation position

The second component contains proposed wording. It should not appear as an isolated bank of polished clauses, because that breaks the connection between each edit and the problem it addresses. Every proposal should identify the existing provision, the reason for the change, and the intended effect. Depending on the mandate, the work product may be an editable drafting document or clear instructions for marking up the contract. Either way, the lawyer should be able to locate the intervention, understand its purpose, and adapt it without reconstructing the analysis.

The third component is the negotiation position. Not every point carries the same legal or commercial weight, so an undifferentiated amendment list is of limited use to the client. For each item, the pack can identify the preferred position, its priority, the reason for it, and an acceptable fallback. A point treated as necessary for the applicable Article 28 framework should not be managed like a commercial preference about notice timing or cost allocation. Fallbacks also reveal whether the proposed clauses and the overall recommendation are genuinely consistent.

The client-ready recommendation and five tests

The fourth component is the client-ready recommendation. The memorandum should not reproduce the entire issues table. It should synthesize the decision: whether the agreement can progress, which amendments are essential, which commercial exposures remain, and what information is missing. It may list questions for security, procurement, or technical teams about processing locations, incident procedures, deletion practices, or subprocessors. This prevents a factual unknown from being presented as a legal conclusion and gives the file a transparent record of the assumptions behind the advice.

Five tests make the finished work product easier to assess. Completeness asks whether the relevant clauses and all promised components were covered. Internal consistency checks whether the issues table, proposed wording, fallback positions, and recommendation support the same strategy. Traceability connects each conclusion to the affected clause and relevant requirement. Editability asks whether the lawyer can adapt the documents without rebuilding them. Fitness for the intended recipient checks whether the client, negotiator, and technical reviewer each receive the right level of detail and a clear next action.

This approach changes what it means to evaluate legal AI. The decisive question is no longer simply whether a system can provide a convincing account of Article 28. It is whether the system can support the assembly of related legal work products that serve the matter from analysis through negotiation. Fluency remains useful, but it cannot compensate for an omitted clause, a fallback that conflicts with the recommendation, or a memorandum that leaves the client unsure what to approve. Deliverable quality is visible in the structure and relationships between outputs.

Evaluating Wisanna through the negotiation pack

Wisanna is a private and secure legal-AI workspace built for lawyers. Its public product surfaces include AI Chat, a Microsoft Word add-in, and Wisanna Draft for editable legal documents. In the agreement scenario, the useful product question is therefore not how elegantly the workspace can answer a standalone compliance question. It is which part of the defined negotiation pack it can help the lawyer prepare for this particular file, using an output form that matches the work the lawyer must ultimately deliver.

Wisanna belongs to the shift toward useful legal work products, but its outputs are not automatically correct or final. A meaningful evaluation or demonstration should be organized around the agreement, the matter, and the required documents: the issues table, connected clause proposals, fallback positions, and client memorandum. That test keeps attention on the deliverable rather than on conversational performance. As legal AI evolves, its value will increasingly be judged by whether it helps assemble coherent, editable, traceable work products that fit a real recipient and decision.