What AI can and cannot do inside a transaction
A capability map rather than a sales pitch. The failure that matters is not a typo, it is a confidently invented fact that was never in the source document.
Most writing about AI in real estate is either a pitch or a warning. What is actually useful is a map: which specific tasks inside a transaction can be handed to software, which cannot, and how the failures show up.
The three things it does well
Extraction. Reading a ratified contract and pulling out the effective date, the parties, the price, the deadlines, and the contingency structure. This is the highest-value automation available in coordination, because it is the task where human failure is most consequential and most predictable: the extraction pass done on day three instead of day one, or done under time pressure and missing a clause.
Requirement determination. Given a county, a transaction type, and a few property facts, producing the correct required-document set. This is where jurisdiction knowledge lives, and it is a lookup rather than a judgment: Montgomery County buyer offer, pre-1978 property, in an association, therefore GCAAR paper plus Maryland disclosure and disclaimer plus lead paint plus the HOA addendum.
Generation from known facts. Producing the documents and correspondence a file needs, from data already in the file. Not inventing content, assembling it.
All three share a property: the output is derived from a source document that exists. That is the condition under which this technology is trustworthy.
The reliable uses all have the same shape: the answer was already in a document, and the work was finding it and reformatting it.
The failure mode that actually matters
It is not typos and it is not misreading. It is producing a plausible value for something the source never specified.
Ask for a financing contingency date from a contract that does not state one clearly, and the weak version of this technology will give you a date. It will be reasonable. It will be formatted correctly. It will be confidently wrong, and it will look exactly like the fifty correct dates next to it.
This is why the design property that matters is grounding: every extracted fact points back to the specific document and location it came from. Not as a nicety, as the mechanism that makes verification take seconds instead of requiring you to re-read everything.
A system that cannot tell you where a value came from is asking you to trust it uniformly, and uniform trust is exactly wrong when the error rate is low but the errors are invisible.
What it cannot do, and why
Decide whether to invoke a contingency. This is a judgment weighing a client's risk tolerance, their alternatives, the market, and their emotional position. It is not a data problem.
Verify a fact it was never given. If the year built is wrong in the source, every downstream conclusion about lead paint is wrong, confidently. Garbage in is not solved by better models.
Interpret an ambiguous clause authoritatively. It can tell you a clause is ambiguous, which is genuinely useful. It cannot tell you what it means in a way anyone should rely on.
Carry responsibility. No vendor agreement transfers professional liability. The licensee is accountable, which means a human decision has to sit somewhere in the chain.
Where the line should sit operationally
A defensible split, and the one we build to:
- Generation and internal drafting run automatically. Producing the documents a transaction needs is the core of the work and should not wait in a queue for a reviewer. A file that sits idle because a human has not clicked approve on a generated form is a worse outcome, not a safer one.
- Anything leaving the file requires a human decision. Sending to a client, a lender, a title company, a counterparty. That is the point where a mistake becomes irreversible and where accountability actually attaches.
The distinction is not how confident the software is. It is whether the action can be taken back.
The question to ask a vendor
Not "how accurate is it." Every vendor says very. Ask: "show me where this value came from."
If the answer is a citation to a specific document and location, verification is cheap and the tool is usable. If the answer is a confidence score, you are being asked to trust a number about a system rather than the system's work, and that is a considerably worse deal.