Every compliance vendor in real estate now says the word “AI.” Very few will tell you what their system does when it is not sure. That single design decision separates a reader you can put in front of a broker’s files from one that quietly waves problems through. We build and run one, so here is what actually works, what does not, and why the architecture matters more than the model.
Does AI compliance review actually work?
For the mechanical parts, yes: is a document present, is a signature block filled, do dates agree. For judgment about whether a term is appropriate, no. The real question is not whether AI can read a contract. It is what it does when unsure.
A file review is mostly a lot of careful, boring checking. Is the lead-based paint disclosure in the file. Is the addendum initialled by both parties. Does the closing date on the addendum match the one on the commission instructions. That work is real, it is high-volume, and people get worse at it as the stack gets taller. It is exactly what software should do.
What software should not do is decide that an ambiguous case is fine. And that is where most of the difference between systems lives, not in which model they use.
How does an AI reader actually read a contract?
Not the way people assume. A contract is not one kind of document. Some pages have a text layer; some are scans with none. The pages that matter most, signatures and initials, carry almost no text. A reader treating every page alike misses them.
Our reader works in mixed mode, choosing a method per page rather than per document:
- Pages with a text layer are read as textFast and exact. Most of a modern e-signed contract falls here, and there is no reason to pay for anything heavier.
- Pages with no text layer get OCRFlattened, scanned, or printed-and-rescanned pages go through optical character recognition at 300 DPI to recover the text.
- Sparse pages get looked atWhen a page comes back with almost no recoverable text, that is the signal it is a signature, initials, or checkbox page. Those get rasterised to an image and handed to a vision model with one instruction: verify the signatures.
Why the last pages are never skipped. Long files get truncated by systems with a page budget, and the execution pages sit at the end. Our reader always includes the final pages regardless of length, because the place a compliance problem hides is precisely the place a naive truncation drops.
The reader also reports how many pages it actually read versus how many exist, and which pages OCR failed on. If it could not read something, that is visible; there is no silent truncation.
Can AI tell whether a document is signed?
Yes, but only if it is allowed to look at the page as an image. Signature detection is a visual problem, not a text problem. A system that only reads extracted text is guessing about the single thing a broker most needs verified.
This is the practical reason a clean, fully executed e-signed document can still get flagged. The signature block renders as an image with no underlying text, so a text-only pipeline sees a blank. The fix is not a better prompt. It is sending the page to something that can see.
Because looking at images costs meaningfully more than reading text, the budget for it is limited and spent deliberately, reserved for the pages that actually need eyes rather than sprayed across every page of a 60-page file.
What happens when the AI is not sure?
It says so. Every finding carries a confidence score, and a “pass” the model is not confident about is automatically demoted to “needs a human look.” The system is built so that uncertainty produces a flag, never a quiet approval.
This is the design decision that matters most, and it is the one worth asking any vendor about directly. A reader optimised to look accurate will pass marginal cases, because passing is what makes the dashboard green. A reader built for a broker who carries the liability has to do the opposite: when in doubt, escalate.
Each finding lands in one of four states rather than a binary:
| Status | What it means | Who acts |
|---|---|---|
| Pass | Compliant, and the model was confident enough to say so | Nobody; the file moves |
| Fail | A real problem: missing, blank, or unsigned | Coordinator fixes before approval |
| Flag | Ambiguous, or a low-confidence pass that was demoted | A person glances at it |
| Error | The reader could not process the page and says so | A person reads it manually |
There is one more guard worth naming. Every finding quotes the passage it relied on, and that quote is checked against the actual text of the page. If the model cites language that is not there, the finding does not survive. A confident, well-written, entirely invented justification is the characteristic failure of language models, and it is the one thing you cannot allow into a compliance record.
Where does AI file review still fail?
On judgment, on unusual documents, and on rules it was never given. AI file review is only as good as the checklist behind it, and checklists are per-state, uneven, and go stale when regulations move.
- Judgment calls. Whether a term is unusual enough to warrant a conversation is not a document-completeness question. That is a broker’s call, and it should stay one.
- Thin state coverage. Our own checklists vary in depth: some are built from a real written SOP for that state, others from general knowledge and are thinner. Pretending otherwise would be the dishonest part. A reader is strong where its rules are strong and weaker everywhere else.
- Documents it has not seen. A local form or an unusual addendum needs to be taught. In our system that happens by correcting the reader on a real example, which becomes a reference for future files, rather than by filing a feature request.
- Anything not in the file. A reader cannot tell you about a disclosure that was never uploaded. Presence checks run against the document set, so a missing document is reported as missing, but no software can review what nobody sent.
Should a brokerage replace human review with AI?
No, and any vendor promising that is selling you the liability, not removing it. The realistic gain is inversion: software does the exhaustive mechanical checking on every file, and people spend their attention only on what got flagged.
The value is not that a machine reviews the file. It is that every file gets the same exhaustive check, at 4pm on a Friday in the same way as at 9am on a Tuesday, and that the broker’s limited attention lands on the exceptions instead of being spread evenly across a stack where most files are fine.
The responsibility does not move regardless. The designated broker answers to the state regulator for the file whether it was reviewed by a person, by software, or by both, which is exactly why “the system was confident” is not a defence, and why a reader that never returns an uncertain answer should worry you rather than reassure you.
For what a review checks and who carries the duty, see what a broker file review is and who is responsible for transaction compliance. For the rest of the operation beyond compliance, see where the automation line sits across a brokerage’s operations.
Common questions about AI compliance review
Is AI file review accurate enough to rely on?
For document presence, execution, and internal consistency it is strong. For judgment about whether a term is appropriate it is not, and should not be asked to be. Treat it as an exhaustive first pass that never gets tired, not as a replacement for the broker’s review.
Why did the system flag a file that looks completely fine?
Usually because a signature page carried no readable text, or because the model’s confidence fell below the floor and the pass was demoted to a flag. Both are the system behaving correctly. A reader that never flags a clean-looking file is not being careful, it is being quiet.
Can AI compliance review handle different state requirements?
Only through explicit per-state rules. There is no general model that knows what your state requires. Ours runs state-specific checklists, and their depth varies by state; some are built from a written SOP, others are thinner and get improved as the team corrects them.
Does using AI reduce the broker’s liability?
No. The designated broker remains accountable to the state regulator regardless of who or what performed the review. Software can make the review more consistent and better documented, which helps in an audit, but it does not transfer responsibility.
How does the system learn from mistakes?
By being corrected on real files. When a reviewer marks a finding wrong, that correction becomes a reference the reader uses on similar documents in that state. The people doing the work teach it, which matters because they are the ones who notice the pattern first.
Exhaustive checking, human judgment
Empower Transactions reviews transaction files at enterprise volume against state-specific requirements nationwide: software for the mechanical pass, experienced coordinators for everything that needs a person. It is delivered as outsourced compliance operations, not a tool your team has to staff and run.
Since this piece was published, the AI compliance reader has become a product category of its own. What the new readers can and cannot do, and the three parts of a complete compliance operation around them, is covered in the reader vs. the system.
Read next
- Outsourcing brokerage compliance operations — the program AI review plugs into.
- How Empower supports brokers — services for brokerages and their leadership.
- Broker file review requirements by state — the state-by-state rules the review satisfies.
