ALTA Best Practices and AI: What a Small Title Agency Should Document

Document every AI tool as a vendor in a single log: what it does, who owns it, what data it can reach, the due diligence you did, the contract position and the next review date. ALTA Best Practices 5.0 defines Vendor to include AI chatbots, agents and assistants, so the log feeds your written information security plan and Pillar 7.

I read the 5.0 framework dated 8 October 2026 and its release notes for this tutorial, and quote its wording where it matters. ALTA's "Vetting a Vendor" guidance is member-only and I have not read it, so check it alongside this. Nothing here is legal advice; ask your underwriter, lender partners or counsel where the answer affects you.

Follow me on Instagram@sagnikteaches

What changed in version 5.0, and why AI is now a vendor question

The ALTA Board approved version 5.0 on 23 June 2026, and it took effect on 8 October 2026. ALTA's release notes say it reviews Best Practices every year and moved the numbering to 5.0 "to align with the significant changes being implemented in Pillar 7", which is now Vendor Management. Complaint handling, the old Pillar 7, moved into Pillar 4. The notes also list a new defined term for "Vendor", a defined term for multi-factor authentication, extra requirements for the written information security plan in Pillar 3.A, and an updated "Vetting a Vendor" guidance, v1.01.

Connect on LinkedInSagnik Bhattacharya

The definition is the part that reaches AI. The framework defines a Vendor as an entity that sells or provides goods, services or resources to the company, with or without a contract or compensation, and says a Vendor also includes AI agents, chatbots, virtual assistants and similar AI products "even if the Company engages a provider by merely sharing Company data or information". The same definition also covers social media platforms used for business operations, advertising or data processing. So a staff member pasting a file into a chatbot has, under that wording, engaged a vendor. Your log is how you show you knew and managed it.

Subscribe on YouTube@sagnikteaches

Pillar 3 reinforces the point. Its procedure on selecting vendors and third-party systems whose security policies are consistent with your written information security plan lists, among the software that may hold or access nonpublic personal information, "automated or artificial intelligence processes that integrate with other internal or external systems", automated status or communication processes, API data integrations and add-ins or plug-ins. The Pillar 7 note also points to the requirements on vendors in Pillars 2, 3 and 4, and says that includes analysing how the vendor itself uses AI and the risks that brings.

Which pillars an AI log touches

Pillar 1 now also requires documentation of compliance with ALTA's Policy Forms Licensing requirement in the certification package. It has nothing to do with AI, but it shows 5.0 is about evidence you can hand over, and the AI log belongs in that same folder.

The AI-use log, column by column

One table, one row per tool. Keep it as a spreadsheet in the same place as your WISP, with an owner and a version date. These are the columns I would use:

1. Tool and vendor name. The product and the company behind it, plus the plan you are on.
2. What it is used for. One line: "summarises inbound emails", "drafts status updates".
3. Owner. A named person who answers for it, not a team.
4. Data it can reach. None, internal, client personal information, or files and funds details. Be literal: if staff could paste anything in, say so.
5. Vendor under 5.0? Yes or no with a reason, using the definition above.
6. Due diligence done. What you asked for and received, with dates: security summary, data terms, training use, retention, sub-vendors.
7. Contract position. Terms accepted, data-processing wording, breach notice, and any insurance points.
8. Approved uses and banned uses. What staff may and may not do with it.
9. Last review and next review. Dates, and who did the review.
10. Incidents. Any problem, with the date and what you changed.

Pillar 7 sets out what due diligence should cover when a vendor can reach nonpublic personal information or funds: confirming the vendor understands and can comply with its legal and financial responsibilities, asking whether it trains and supervises staff who deal with consumers, putting clear expectations and enforceable consequences in the contract, and understanding the vendor's own use of sub-vendors, including whether it applies equivalent security controls, notifies you of sub-vendor breaches and is liable for their actions. It also asks you to review periodically whether the vendor is meeting those expectations. The 5.0 release notes add that the updated vetting guidance says to consider being named as an additional insured on the vendor's insurance and to check whether your own insurance covers a vendor's actions.

A filled-in log for a six-person agency

Illustrative: a small agency with an escrow officer, two processors, a closer, an office manager and a principal. The rows below are examples, not recommendations of products.

The first row shows the most common weakness. An email assistant built into your mail platform is easy to forget because nobody installed it, yet it can read everything in the mailbox. If it is on, it belongs in the log.

Writing the policy wording that sits above the log

The log is the evidence; the policy is the rule. Two or three paragraphs are enough, added to your WISP or kept as a one-page AI-use policy that the WISP refers to. Sample clauses to adapt, with your counsel or underwriter:

1. Scope. This policy covers any AI product, including chatbots,
assistants, agents and AI features inside other software, used for
company work.

2. Approved tools. Only tools listed in the AI-use log may be used
with company or client information. The log owner is [role].

3. Data. No nonpublic personal information, account numbers, wiring
details, identity documents or file contents may be entered into a
tool unless the log records it as approved for that data.

4. Vendors. Each approved AI tool is assessed as a Vendor under the
Vendor Management procedures before use and reviewed at least
annually.

5. Incidents. Staff report suspected misuse or a data exposure to
[role] the same day.

What you would fix in a first draft: the word "approved" needs a process behind it. Add a line on how someone requests a tool, who decides, and how long that takes, or staff will use whatever is quicker. The wider mechanics of writing and rolling out an AI policy are in how to write an AI usage policy, and a security-plan template aimed at another professional group is in AI tools in a written information security plan.

Checking whether a tool is a Vendor: a five-question test

1. Does the tool send company data, in any form, to a provider outside the agency?
2. Does it run inside software you already use as a feature or add-in?
3. Could a staff member paste or upload client information into it?
4. Does it act on its own, such as sending messages or updating records?
5. Would losing or misusing its data harm a consumer or a party to a transaction?

A yes to any of the first three puts it in scope under the definition quoted above, which covers products even if you only share data with the provider. A yes to the fourth or fifth raises the level of due diligence. Illustrative: an AI spell-checker that runs entirely on your device and sends nothing away is a no on all five, and you can note it in the log as "reviewed, no data leaves the device, not a vendor". Be careful with that conclusion and verify it from the vendor's documentation; many tools that sound local are not.

Where the real exposure sits: accuracy and fraud

Documentation covers data. Title work also depends on accuracy and on fraud resistance, so the log should carry a column for "what we check before relying on it". An ALTA news item of 3 September 2026 reported a DataTrace review of 200 residential title files in which public-record-only AI search missed at least one meaningful title matter in 40.8 percent of the searchable files. That is one company's analysis, reported by ALTA, so treat it as a warning to test your own tools, not as a statistic about all AI. The practical rule it supports is clear: AI output on search, examination or commitment work is a draft that a person checks against source records.

For fraud, AI cuts both ways. Tools may help screen documents, while the same technology makes forged documents and cloned voices easier to produce. Pillar 2 asks for a written wire transfer procedure that is tested at least annually and a written wire fraud response procedure that is reviewed at least annually. Add "AI-generated or AI-altered content" to the scenarios you test, using the call-back method in real estate wire fraud and voice-clone calls.

A worked example: approving a transcription tool for closings

Illustrative: the escrow officer asks to use an AI note-taker on closing calls to save writing up. Walk it through the log in order. The tool would hear names, loan amounts and sometimes account details, so data reach is high and it is plainly a Vendor. Ask the provider where recordings and transcripts are kept, how long, whether they are used to train models, who its own sub-vendors are, how it will notify you of a breach, and what its staff can access. Record each answer and the date.

Then decide the use. Say the answers are acceptable for internal meetings but the provider will not commit to deleting transcripts on request. The log row reads "approved for internal staff meetings; not approved for client calls or closings", with the reason, and the policy says so too. The officer still has a tool, the file shows a decision, and no client conversation went into an unvetted system. That outcome, a partial approval with a written reason, is what a log is for. A tool you refused and documented shows the process works as well as a tool you approved.

If the tool had been proposed for remote closings, the release notes add another point to check: for remote online notarisation, ALTA's 5.0 text says platform selection can require considering the requirements where both the notary and the property are located. An AI feature inside a signing platform would be reviewed in that same decision, not separately.

Training staff on the policy in twenty minutes

A policy nobody has heard of fails the first time someone is in a hurry. A short session is enough for a small agency. Cover three things with examples from your own log. What is approved: show the five tools and what each may be used for. What never goes in: client personal information, account numbers, wiring details and identity documents, into anything not logged for that data. And what to do when unsure: ask the log owner, who answers the same day.

Then run a quick exercise. Give each person three scenarios on paper and ask whether the action is allowed: summarising a long public court notice in a public chatbot, pasting a buyer's bank letter into an email assistant, asking the built-in assistant to tidy a status email with no figures. Review the answers together. Keep a signed attendance sheet with the date and the policy version; it is simple evidence that staff were told. Repeat at onboarding and whenever the policy changes.

What to say when a lender or assessor asks about AI

You will be asked sooner or later, probably by a lender partner reviewing your Best Practices compliance. A good answer takes thirty seconds and points to paper: "We keep a log of every AI tool, who owns it, what data it can reach, and the vendor review we did. Our policy bans entering client information into unlogged tools, and we review the log every January and whenever a tool changes." Then hand over the log and the policy.

A poor answer is "We do not use AI", given by an agency whose staff use the assistant in their email platform. Know the true position before you say it, and do not claim a review you have not carried out. If you have gaps, the honest answer is better: "We have found these two tools and are completing the review by this date."

Review rhythm and evidence

Put dates in the calendar, not in your head. Illustrative schedule: a full log review each January, a review of any tool within 30 days of a major change to its terms or features, a quick check each quarter that staff are still using only approved tools, and a test of the incident process once a year. Record each review in the log with the reviewer's name and date. The evidence you want on file, for each in-scope tool, is: the log row, the data terms or security summary you reviewed, the approval decision, any contract wording and the review history.

A before and after. Before: the principal says "we only use a couple of AI things", and cannot list them. After: the log lists five tools with owners and dates, the policy bans two uses, and a new tool request waits for a log entry. An assessor, a lender partner or an underwriter asking "how do you manage AI?" gets a table, not a shrug. Put the review dates on your compliance calendar alongside licences and insurance renewals.

Gaps that weaken a small agency's AI log

• Built-in AI features nobody logged. Email, document and meeting tools now ship assistants. Walk through each major platform's settings once, and list what is switched on.
• Personal accounts. A processor using a personal chatbot account for convenience. The policy says no client information, and training makes it real.
• Vendor claims taken at face value. "Bank-grade security" is not due diligence. Ask for the specific documents the framework's procedure points to: data handling, training of staff, sub-vendors and breach notice.
• No owner. A log with no named owner decays within a quarter.
• No link to the WISP. If your written information security plan does not mention AI, a reader cannot tell the log is part of it. Add a cross-reference.

If you are choosing a first AI tool, picking and pricing a first AI pilot for a title agency helps you start with something small enough to log properly. And if the tool is an answering service, read AI answering for title companies: cost and status-call rules before you sign.

A one-page checklist to start this week

1. List every AI product in use, including features inside email, documents, meetings and the production system. Ask each staff member, not only the IT contact.
2. Create the log with the ten columns above and fill in one row per tool.
3. Mark each as Vendor or not, using the five questions and the definition.
4. Do and file the due diligence for each in-scope tool that can reach client information or funds.
5. Write the one-page policy and link it from the WISP.
6. Name the log owner, set the review dates and add them to the calendar.
7. Read ALTA's current Best Practices page for the framework, release notes and "Vetting a Vendor" guidance, and compare your log with them.

Questions small title agencies ask about AI and ALTA Best Practices

Does ALTA Best Practices mention AI directly?

Yes. The version 5.0 framework dated 8 October 2026 defines Vendor to include AI agents, chatbots, virtual assistants and similar AI products, even when you only share company data with the provider. Pillar 3 also lists automated and AI processes among tools that may touch nonpublic personal information.

Do we need a separate AI policy?

The framework does not demand a document with that name. It expects written procedures, and your written information security plan and vendor procedures should cover AI tools. A short AI-use policy that feeds into both is the simplest way to show it, and an assessor can read it in minutes.

What should the AI-use log record?

For each tool: what it does, who owns it, what data it can reach, whether it counts as a Vendor, the due diligence done, the contract position, when it was last reviewed and the next review date. Keep it in one table that a new manager could understand without you.

Do free AI tools count as vendors?

The definition covers providers whether or not there is a contract or payment, and it includes AI products where you merely share company data. A free chatbot your staff paste files into is therefore in scope. The safer policy is to ban unapproved tools for work involving client information.

Further reads

• Does a Five-Person Business Really Need an AI Policy? — Decide how formal your AI policy needs to be.
• AI Acceptable Use Policy for a Small Professional Firm — Compare a policy written for another professional firm.
• Insurance Broker AI App: A Buying Checklist for a Small Brokerage — Use a buying checklist when vetting an AI app.
• AI for Real Estate Attorneys: Closing Checklists and Title Review — See how closing checklists use AI on the legal side.
• What to Check in an AI Tool's Privacy Policy and Terms — Read a tool's privacy terms before approving it.
• How to Spot Deepfake Voice and Video Scams Aimed at Your Business — Add AI-made fakes to your fraud scenarios.
• Title Commitment Review With AI: Exceptions, Requirements and Checks — Build an exceptions and requirements table from a title commitment with AI, cross-check it to the deed and payoff letters, and keep the examiner's sign-off.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: ALTA Best Practices 5.0 framework (10-08-2026) and its 5.0 release notes, both downloaded from alta.org on 4 November 2026, plus ALTA's 3 September 2026 news item on DataTrace's AI title-search review. ALTA's Vetting a Vendor guidance and assessment procedures were not read in full; check them before you rely on this.