Conveyancing is the part of Irish legal practice that quietly drives most firms' revenue and most of their stress. It is high-volume, deadline-driven, document-heavy, and unforgiving — one missed folio number, one stale searches result, one undischarged judgment mortgage, and a closing falls over. It is also, mechanically, the most automatable area of property law if you have the right tooling. Not "automated" in the sense of removing the solicitor — automated in the sense of removing the seventy small clerical acts that surround each file. This article walks through how an on-premise intelligence brain actually slots into a conveyancing workflow, file by file, document by document.
Why conveyancing is the right place to start
If you run a mixed practice and you are looking at AI tooling, conveyancing is where I would point you first. The reason is structural. Conveyancing files have a finite shape. There is a contract, a title pack, a set of requisitions on title, planning and BER documents, searches, a mortgage pack, and a closing. The variation between files is real but bounded. A litigation file can go anywhere. A conveyancing file moves through roughly the same checkpoints whether the property is a terraced house in Clonmel or an apartment in Dublin 8.
That bounded structure is what makes conveyancing AI tractable. You can teach a system the shape of a Section 72 declaration. You can teach it what a Land Registry folio looks like, what burdens look like, and what a Form 17 looks like. You cannot teach a system the shape of "all litigation". The bounded surface area is also why title checking AI is the first place real productivity shows up — the documents are standardised enough that pattern recognition does useful work.
The intake workflow: contract pack arrives
The first practical workflow is contract pack intake. A vendor's solicitor sends a contract for sale, copy folio, copy file plan, BER, planning documentation, and usually a bundle of declarations. In a traditional firm, a solicitor or experienced assistant opens the email, downloads the attachments, names them according to local convention, and starts reading.
An intelligence brain handles the mechanical parts. It ingests the email and attachments, classifies each document (contract, folio, file plan, BER cert, planning permission, commencement notice, certificate of compliance, declaration of identity, family home declaration, and so on), extracts the structured fields (folio number, county, address, vendor names, purchase price, closing date, deposit, special conditions reference numbers), and writes them into the matter record. It flags missing items against a checklist — for example, if the contract references a planning permission but no grant is attached, that becomes a task.
The important engineering point: this is extraction and classification, not judgement. The solicitor still reads the contract. What changes is that by the time they read it, the file is already populated, the checklist is already running, and the obvious gaps are already raised as queries to the vendor's side.
Title checking: where the real work lives
Title checking is where conveyancing AI either earns its keep or doesn't. The job is to read the folio, read the burdens, read any deeds (in unregistered or partially registered title), and answer a specific set of questions: who owns it, what charges or burdens affect it, are any of those a problem, and what needs to be discharged on or before closing.
The workflow I have built into the brain runs in three layers. First, a structural extraction: parse the folio, list the burdens with their entry numbers, identify the registered owner(s), pull the property description and map references. Second, a classification pass: each burden is tagged — charge in favour of a named lender, right of way, right of residence, judgment mortgage, Section 97 notice, restriction on alienation, and so on. Third, a reasoning pass against the contract: do the burdens match what the vendor disclosed? Is there a charge that the contract says will be discharged? Is there a burden that needs a release, a vacate, or a Section 31 declaration?
The output is not "the title is good". The output is a structured note for the solicitor: here are the eleven burdens, here is what each one is, here are the four that need action before closing, here is the draft requisition wording for each. The solicitor reviews and signs off. That is property law AI doing the legwork without pretending to be the lawyer.
Requisitions on title and replies
The Law Society Requisitions on Title document is long, repetitive, and largely the same on every file with local variation. Generating the requisitions from the file is straightforward — the brain knows the property type, the title type, whether it's a new build, whether there's a management company, whether planning issues are flagged — and produces a draft set of requisitions with the relevant sections enabled and the property-specific fields populated.
The harder direction is the inbound one: replies to requisitions arrive from the vendor's side and need to be checked. A good intelligence brain reads the replies, matches each numbered reply to the requisition it answers, flags any "see attached" responses where the attachment is missing, identifies replies that say "not applicable" where the file says it is applicable, and surfaces replies that contain conditional language ("subject to confirmation from…") that need follow-up.
Again, this is mechanical. The solicitor's job is to read the replies and form a view on whether the title is acceptable. The brain's job is to ensure they are reading a complete, cross-referenced, gap-flagged set of replies rather than a PDF they have to manually map back to a numbered list.
Searches, undertakings, and the closing checklist
Closing day is where files go wrong. The standard closing pack includes up-to-date Land Registry searches, Judgments Office searches, Companies Office searches where a corporate party is involved, planning searches, and a set of undertakings exchanged between the solicitors. Each of those has a freshness window. A search done six weeks ago is not a closing search.
The workflow here is monitoring. The brain tracks the date of each search, knows the firm's policy on search freshness, and surfaces the searches that need re-ordering before closing. It reads the search results when they come back and compares them against the prior set — has a new judgment been registered? Has a new burden been added to the folio since the contract was signed? It also tracks undertakings, both given and received, and flags any that are unfulfilled at closing.
The closing checklist itself becomes a live object rather than a Word document. Each item is either complete (with the supporting document attached and the brain having verified the basics — right parties, right amount, right date), in progress, or outstanding. The solicitor sees one screen and knows what is missing. This is the part of the brain configured for property work that property solicitors tend to notice first, because closing day stress is so concentrated.
Why on-premise matters for irish conveyancing
One thing I am stubborn about: this kind of system has to run on infrastructure the firm controls. Conveyancing files contain PPS numbers, dates of birth, mortgage details, marital status declarations, and the full sale price of someone's home. That is not data you push into a third-party cloud LLM and hope for the best. It is also data that the Law Society and the Data Protection Commission take a clear view on.
The architectural choice in the Intelligence Brain is that the model, the document store, and the reasoning all sit inside the firm's environment — on a server in the office, or on a tenant the firm controls. Documents do not leave. Extracted fields do not leave. The brain is trained and configured against the firm's own precedents and templates, not a generic model trained on someone else's data. For Irish conveyancing specifically, that means the system can be configured against Irish forms, Irish title structures, Irish search providers, and Law Society templates without any of those flowing through an external service.
Where to start this week
If you are a property solicitor reading this and wondering where to begin, do not start with "implement AI in the firm". Start with one workflow. Pick contract pack intake. For one week, log every minute spent on the mechanical parts of intake — downloading, naming, filing, checklist building, raising the obvious queries. That number is your baseline. Then have a serious conversation about what an on-premise system would do to it. The case for conveyancing AI in an Irish firm is not a strategic one, it is an arithmetic one — and the arithmetic is best done on your own files, not on someone else's slide deck.