The legal AI market is crowded with products that look impressive in a demo.
That is not the hard part anymore.
A polished interface, fast output, and a good prompt can get almost anyone to something that feels useful in a sales call. Most vendors are building on the same small set of frontier models. The model alone is rarely the real differentiator.
The real difference is what the vendor built around it.
That is where the market splits between actual products and wrapper software with legal branding.
The Demo Usually Hides the Important Part
In a demo, almost everything looks competent.
Upload a document. Ask a question. Get a summary. Draft a clause. Generate a research memo. The output is fluent, fast, and often genuinely helpful.
That surface-level capability matters, but it is not where legal buyers should be concentrating their attention.
The most important question is not whether the system can generate something useful.
It is what happens next.
What happens to that output between generation and the attorney's signature?
If the vendor cannot answer that clearly, you are probably not looking at a legal product. You are looking at a prompted interface sitting on top of a general model.
The Tell Is What Happens After Generation
This is where the difference shows up.
A wrapper product treats generation as the product. Text appears, the user sees it, and the vendor more or less stops there. Review is implied. Supervision is assumed. Auditability is vague. Workflow responsibility is pushed back onto the firm.
A real product treats generation as one step inside a controlled system.
The output has a state. It lives in a workflow. It can be reviewed, revised, approved, rejected, or held. The system can tell you what was generated, what changed, who approved it, and what happened before anything acquired legal effect.
That is not a feature add-on. That is the product.
The gap between those two approaches is where most legal AI marketing gets misleading.
What a Real Legal AI Product Is Trying to Do
A real legal AI product is not just trying to produce text.
It is trying to make machine-generated work usable inside a professional system that has supervision, confidentiality, responsibility, and consequences.
That means the architecture has to account for more than generation quality.
It has to account for:
- what the system can access
- what the system can retrieve
- what the system can change
- what the system can do without approval
- what records exist if something later has to be explained
That is the difference between software built for legal work and software that was prompted into a legal demo.
The Questions Buyers Should Actually Ask
If you are evaluating a legal AI vendor, ask questions that force the system to reveal whether it was designed for legal workflow or just for impressive output.
Ask:
- What happens to output between generation and attorney approval or signature?
- What records are kept of what was generated, what was edited, and what was approved?
- What actions require explicit human approval before they have legal effect?
- How is data isolated between firms, matters, clients, and users?
- What can the system retrieve, and what is it structurally prevented from retrieving?
- If I need to explain what happened in a matter later, what audit trail exists?
Most wrapper products break down somewhere in that sequence.
They can tell you how fast the model is. They can tell you which provider they use. They can tell you the interface is secure and the output is reviewed by the user. But once you ask how work moves from generation into accountable legal workflow, the answers get soft very quickly.
That softness is the signal.
The Architecture Signals That Matter
You do not need a computer science degree to evaluate this well. You just need to ask whether the system behaves like legal software or like a prompt with a billing page.
The strongest signals of a real product are architectural, not cosmetic.
Does the system treat attorney judgment as a constraint or as a disclaimer?
Does it create visible review states, or does it just assume the user will be careful?
Does it preserve matter-level auditability, or does output simply appear and disappear in a chat log?
Does it enforce retrieval and data boundaries, or does everything go into one large undifferentiated context window?
Does it require approval before legal effect, or does it leave the most important control point to informal user behavior?
Those questions matter more than whether the demo felt magical.
Why This Matters More in Legal Than Almost Anywhere Else
In many software categories, a weak wrapper product creates inconvenience.
In legal, it can create professional and client risk.
An output that looks finished can still be wrong in ways that matter. A clean draft can still waive something. A confident summary can still misread the posture. A system with weak boundaries can still cross confidentiality lines.
That is why legal buyers should stop evaluating these products as if the only question is whether the model is smart.
The harder question is whether the system was engineered for the environment it is entering.
The Honest Version
The model is no longer the most interesting part.
What matters is what the vendor built around it: review boundaries, approval gates, auditability, data isolation, bounded retrieval, and workflows that treat attorney judgment as something the system has to support, not merely something the user is assumed to provide.
That is how you tell whether a legal AI vendor built a product or prompted one.
FlowCounsel is the AI-native operating system for legal teams. FlowLawyers is the consumer-facing legal help platform with attorney discovery, legal aid routing, state-specific legal information, and document tools. Neither provides legal advice. Attorney supervision of all AI output is required.