Start with the document problem, not the model
The first use case should locate and organize information that already exists, not produce a legal opinion. The team can ask which documents address a clause, a contractual obligation, or an event, and receive references to examine. Interpreting the content, choosing an action, and assessing risk remain outside the scope of the automation.
Before selecting a tool, define an observable task. Examples include finding contracts for a particular supplier, separating signed versions from drafts, identifying documents related to a notice, or gathering clauses about term and termination. A specific task makes it possible to measure whether triage produced relevant documents without turning a textual response into a legal decision.
- Separate documents by subject, business unit, contract, language, date, and document status.
- Preserve the original file, name, version, and origin of every item.
- Treat missing fields as unknown, never as confirmation of a fact.
Sources and references: [1]
Design a triage workflow with clear limits
An initial workflow can have five stages. First, it receives files from authorized repositories and records metadata. It then extracts text and divides the content into searchable passages. Next, it retrieves documents through a natural language query, applies filters such as date, region, type, or status, and assembles an evidence list. Finally, it generates a triage record with references and routes the case to the appropriate queue.
Semantic search is useful because it can find related passages even when the query does not repeat the same words as the document. In systems that use vector indexes, files can be divided, converted into numerical representations, and indexed for search. This improves discovery, but it does not prove that the result is complete, current, or legally applicable. The interface should display the source file and retrieved passage instead of showing only a conclusion.
- Input: file, origin, date, version, classification, and permissions.
- Search: a natural language question combined with metadata filters.
- Output: documents found, passages, extracted fields, and identified gaps.
- Routing: operational category, priority defined by internal policy, and analysis owner.
Sources and references: [1]
Use structured outputs to contain extrapolation
Instead of asking AI to say whether the company is right or wrong, request limited fields such as identified parties, mentioned dates, related clauses, expressly described obligations, cited documents, and conflicts between versions. For each field, also allow “not located” or “inconclusive.” This reduces pressure to fill gaps with assumptions and makes the result easier to check.
The system can produce an operational summary, but it should separate found text from inference. A good triage record shows the passage, location, document type, available date, and reason for routing. It should not classify a clause as valid, abusive, sufficient, or breached. It is also prudent to block external actions, such as sending notices, changing contracts, or sharing files, during the first phase.
- Define a fixed response schema with required fields and permitted values.
- Require a file and passage reference for every extracted item of information.
- Include an uncertainty category for illegible, conflicting, or outdated documents.
- Prohibit commands that alter data, send messages, or assume commitments.
Sources and references: [2]
Control access, untrusted content, and quality
Legal documents may contain instructions directed at the reader or at the system itself. Text inserted into a contract, email, or attachment must not be able to change the workflow rules. Separate system instructions, retrieved data, and user requests. Restrict available sources by role and purpose, record which files were used, and avoid sending the model more content than the task requires.
Quality should be measured with a representative set of cases, including conflicting versions, missing attachments, poor OCR, vague questions, and documents in different languages. Assess whether search retrieves the correct file, whether fields were extracted without invention, and whether routing followed the defined rules. Repeat the evaluation when the index, prompts, filters, or routing logic change, because model responses can vary.
- Test ordinary documents, edge cases, and texts that attempt to induce improper instructions.
- Compare retrieval with a list of expected documents for each scenario.
- Record queries, retrieved sources, workflow version, and routing reason.
- Define a stop route for results without evidence, conflicting results, or requests outside the scope.
Hypothetical example of implementation in a company
Consider, hypothetically, a company with contracts scattered across department folders. The first workflow accepts only signed contracts and amendments from one specific segment. It labels each file with supplier, business unit, date, status, and document type. In response to the question, “which documents mention automatic renewal?”, search retrieves passages and presents an ordered list without answering whether renewal can be applied to the specific case.
The triage record could report related documents, located clauses, mentioned dates, versions that appear to differ, cited attachments that were not found, and outstanding questions. Routing sends cases with version conflicts to the queue defined by the company and leaves cases without evidence as inconclusive. The legal team uses the record as an investigation map, checks the original document, and decides the next step outside the automated system.
This design also supports gradual expansion. After measuring retrieval on a small, controlled set, the company can include other document types, provided it keeps permissions, metadata, and stop criteria separate for each workflow. The decisive question is not whether AI can write a convincing answer, but whether it delivers findable evidence and understandable limits to the person analyzing the case.
- Pilot: one contract type, one document source, and a small number of triage categories.
- Pass criterion: retrieved evidence, completed fields, and traceable routing.
- Blocking criterion: no source, unresolved conflict, or a request for a legal decision.
Put it into practice
- Choose a specific document task and define what will explicitly remain outside the scope.
- Catalog sources, versions, metadata, permissions, and documents that must not enter the workflow.
- Design a structured output with references, gaps, uncertainties, and routing categories.
- Test ordinary cases, conflicts, missing attachments, manipulative texts, and ambiguous queries.
- Define stop criteria, technical logging, and responsibility for the team analyzing each routed case.
Common questions
Can AI say whether a clause is valid or whether the company should act?
Not in this design. It can locate passages, organize documents, and identify extracted information, but validity, interpretation, strategy, and decisions should remain with the responsible team.
What should happen when search finds conflicting documents?
The output should mark the conflict, show the versions, and route the case for analysis. The system should not choose one version as correct merely because it appeared first or received a higher relevance score.
What is a good first pilot for a legal team?
Choose a limited collection, such as signed contracts from one process, and a clearly defined location question. Measure retrieved evidence, gaps, and routing before expanding access.
Sources and references
- OpenAI: Retrieval ↗Accessed on September 18, 2026
- OpenAI: Safety in building agents ↗Accessed on September 18, 2026
- OpenAI: Evaluation best practices ↗Accessed on September 18, 2026



