NDA Review Agents

An NDA review agent reads an incoming non-disclosure agreement, flags risk, and reports where its clauses depart from the organisation’s own playbook. It does that in minutes rather than the days a manual legal review takes. This note sets out how Bluesphere Digital builds systems in this class, and why most of their reliability comes from the layers around the model rather than the model itself.

FormatEngineering note
DomainLegal operations
PatternWritten policy, applied at volume
Decision-makerAlways human

The problem

Large organisations receive NDAs constantly, and almost all of them are variations on a small number of standard forms.

The review work is therefore repetitive and, at the same time, unforgivable. The reviewer is looking for the one clause in forty that departs from the position the business has decided it will accept.

Slow review has a cost beyond delay — where turnaround takes days, organisations quietly develop workarounds, signing counterparty paper unreviewed or letting low-value agreements sit for weeks. Both are risks created by process rather than legal position.

The task suits document intelligence precisely because the standard of comparison already exists in writing: the playbook. The job is consistent application of it, at speed.

Why an agent, and where the line is drawn

Not every AI feature should be an agent, and we are conservative about the pattern.

It earns its place here because the work genuinely requires several steps over several tools:

  • Parse a document that arrives in an inconsistent format.
  • Segment it into clauses.
  • Classify each clause against a taxonomy.
  • Compare it to the relevant playbook position.
  • Assemble a report a lawyer can act on.

What the agent must not do is decide.

Where the human sits is the most consequential design choice in a system like this, and it is a legal question as much as a technical one. Because nothing is auto-approved, a change that makes the model more sensitive costs reviewer minutes rather than creating exposure — which is also what makes the system safe to improve.

The hard part: being right about clauses that matter

The engineering challenge in this class of system is never summarisation; it is precision on the small number of things that carry risk.

A non-standard clause nobody examined
A legal exposure
Invisible until it matters
A clause flagged that did not need to be
A wasted minute
Dismissed in one click

The two are not symmetric. So the system is tuned to be noisy rather than quiet, with an interface where dismissing a false flag is trivial.

Underneath, clause segmentation has to survive formatting it has never seen — clauses split across page breaks, defined terms introduced in schedules, numbering conventions that vary by firm. Getting segmentation wrong does not produce an obvious failure; it produces a clause that was never examined, which is exactly the failure mode the system exists to eliminate.

Keeping it accurate as the playbook changes

A playbook is not a fixed artefact.

Positions change as the business’s risk appetite changes, and a system that was accurate at launch drifts silently unless something measures it.

That turns a playbook update into a routine operation, and a model upgrade into a measurement rather than a debate. A regression on one clause class is visible before anything reaches a reviewer.

It is the same practice we run on our own product, ProfileIQ.

Where the pattern applies

Any process where trained people apply a documented policy to inconsistent documents at volume fits this shape.

  • Normalise the document.
  • Structure before you generate.
  • Compare against an explicit written standard.
  • Keep a human as the decision-maker.
  • Measure continuously.

What does not transfer is the assumption that a language model is the whole solution. In a system like this the model does one part of the work, between deterministic parsing before it and deterministic reporting after it. Most of the reliability comes from those two ends.

If this describes a process in your business, a Discovery Sprint is the cheapest way to find out whether it is viable. The proof-of-concept targets the AI component first, because that is where the risk concentrates.

Frequently asked questions

Can I see examples of your work?

Yes. ProfileIQ, our own AI SaaS product, is live at profileiq.ai and you can use it today. It is the build we can show end to end: concept, architecture, launch, and day-to-day production. Client engagements are under NDA and are not described on this site — no names, no screenshots, no engagement details, and no phrasing designed to imply them.

What we publish instead are engineering notes on how we build the classes of system we are asked about most. We are happy to go deeper on a call, under your own NDA if you prefer.

Who owns the code and intellectual property?

You own 100% of the code and intellectual property from day one — not at handover, and not after final payment. Source code, designs, documentation and infrastructure configuration all belong to you. You have full repository access throughout the build, so you can read every commit as it lands.

There is no proprietary framework to license from us afterwards, and nothing that makes moving to another engineering team expensive. If an engagement ends early, everything built up to that point is still yours.

Talk to Bluesphere Digital

If your business applies a written policy to inconsistent documents at volume, tell us about it — that is the shape this pattern fits.

Start a conversationBook a call