A prospective client calls your firm at 11:14 p.m. about a contract dispute. Your AI voice agent answers. Within 90 seconds, the caller has disclosed the name of the company they are considering suing. Your firm has represented that company in unrelated transactional matters for the last six years.
What are your obligations under ABA Model Rule 1.18, and which choices in your AI voice intake configuration make those obligations harder or easier to discharge?
This post is not legal advice. It is a working overview of how Model Rule 1.18 applies to AI voice intake, written for managing partners and intake managers evaluating vendors. We have tried to be specific about what the rule covers, where AI intake creates new wrinkles, and which vendor-architecture choices map directly to your duties as the responsible attorney.
What Rule 1.18 actually says
Model Rule 1.18 was added to the ABA Model Rules in 2002 as part of the Ethics 2000 revisions. It defines a "prospective client" and the duties a lawyer owes to one even when no client-lawyer relationship is formed. The rule has been adopted with minor variations in nearly every state. The four operative pieces:
- Definition. A "prospective client" is a person who consults with a lawyer about the possibility of forming a client-lawyer relationship (1.18(a)). The consultation itself does not have to result in engagement. The protections attach the moment information is exchanged.
- Confidentiality. Even when no representation results, the lawyer must not use or reveal information learned in the consultation, except as Rule 1.9 would permit with respect to information of a former client (1.18(b)). In plain language: prospective-client information is protected on the same terms as former-client information.
- Conflict. A lawyer who received from a prospective client information that "could be significantly harmful to that person in the matter" must not later represent another client with materially adverse interests in the same or a substantially related matter (1.18(c)). The disqualification is imputed to the lawyer's whole firm unless screening procedures are properly implemented (1.18(d)).
- Exceptions. Both informed written consent from the affected clients, and proper screening with timely notice to the prospective client, can lift the disqualification (1.18(d)).
The new question for 2026 is what happens to each of these duties when the first conversation with the prospective client is held by an AI voice agent operating on the firm's behalf.
Everything the AI captures is protected from the first second of the call
The first practical consequence of Rule 1.18 for AI voice intake is the simplest and most often missed: the protections attach the moment the prospective client begins disclosing information, regardless of whether any human at the firm has heard the recording, read the transcript, or even logged into the dashboard.
This matters because AI intake systems capture more structured information per minute than a typical human intake call. A 4-minute AI conversation may capture caller name, contact information, opposing party identity, jurisdiction, factual posture, statute-of-limitations status, prior counsel, and reason for the consultation. Every one of those data points is protected under Rule 1.18(b). The firm is responsible for that information from the second it is captured.
Three immediate implications:
- Storage. Call recordings and transcripts must be stored under access controls consistent with Rule 1.6 confidentiality. Vendor-side cloud storage with broad vendor-employee access is not automatically compatible with this duty.
- Use restrictions. The information cannot be used for training the vendor's model, for marketing, for analytics surfaced across tenants, or for any purpose other than serving the prospective client and the firm. Vendor terms of service that grant broad data-use rights are a Rule 1.18(b) problem dressed up as boilerplate.
- Retention and deletion. A prospective client can later request the firm to delete their information, just as a former client could. The firm needs to be able to honor that request inside the AI vendor's system, end-to-end. If the vendor cannot guarantee deletion across logs, backups, and analytics caches, the firm cannot honor its own duty.
The cleanest test for vendor compatibility with Rule 1.18(b) is one question: can the vendor's data architecture support the same confidentiality posture as a paralegal who took the same call? If the answer is no, the firm has a duty problem the vendor cannot solve unilaterally.
Conflict checks must happen during intake, not after
The second consequence is about timing. Rule 1.18(c) creates a disqualification risk based on receipt of "significantly harmful information." The longer the AI intake conversation runs before a conflict check is performed, the more harmful information has been received, and the harder it is to argue the firm did not receive disqualifying information.
The firm-side design question is: at what point in the call should the AI run a conflict check?
Three patterns we have seen in practice:
- Conflict check after intake. Easiest to build. Firm reviews the call transcript the next morning, runs the conflict check against the firm's database, decides whether to take the matter. This pattern maximizes Rule 1.18(c) exposure. By the time the firm runs the check, the AI has captured the prospective client's full theory of the case.
- Conflict check at first opposing-party disclosure. The AI is configured to pause the call as soon as the caller names an opposing party, run the conflict check against the firm's CRM or conflict system, and either continue or terminate the call with appropriate language. This is the pattern that maps cleanest to Rule 1.18(c).
- Conflict check before substantive discussion. The AI captures enough identifying information (caller name, opposing party, matter type) before any discussion of facts, runs the check, and then either proceeds with substantive intake or stops with a referral. This is the safest pattern but feels mechanical to callers and increases call abandonment.
Pattern 2 is the working compromise. It requires the AI to be integrated with the firm's conflict system in real time, which is a non-trivial vendor capability. Most AI voice intake vendors in 2026 do not support this. Most firms accept Pattern 1 by default and absorb the Rule 1.18(c) risk without naming it.
"When does your AI voice agent run a conflict check?" is a Rule 1.18 question, not a feature question.
Your vendor's multi-tenant architecture is a Rule 1.18 question
The third consequence is the one most likely to cause an unexpected ethics inquiry, and the one that almost no AI voice vendor surfaces during sales conversations.
Most AI voice intake vendors run multi-tenant infrastructure: many firms' calls are processed through shared models, shared analytics pipelines, sometimes shared transcription services. The standard contractual framing is that data is "logically segregated" by tenant. Logical segregation is fine for SOC 2 controls. It is a more interesting question under Rule 1.18.
Three failure modes worth explicit attention:
- Shared analytics or training pipelines. If the vendor uses aggregated call data to improve its underlying models, prospective-client information is being used outside the consenting relationship between caller and firm. Rule 1.18(b) does not allow this. A clean vendor commitment reads: "we never train on customer call data, period." Anything softer is a problem.
- Cross-tenant employee access. If vendor support staff can access call recordings from any customer's tenant, that access is not categorically inconsistent with Rule 1.18, but the firm must be able to demonstrate that access was bounded, documented, and limited to incident response. "We do not access customer data without a documented support ticket from the customer" is a defensible posture.
- Cross-tenant conflicts. The rarest scenario and the most uncomfortable. Imagine Vendor X provides AI intake to Firm A and Firm B. Firm A and Firm B are on opposite sides of the same litigation. The vendor has both firms' call recordings in its infrastructure. Could that create an information-flow concern between the firms via the vendor? The firm's duty under Rule 1.18 is fact-specific, but the question is real, and most vendors have not thought about it.
The right vendor-side architecture for legal intake is what the security industry calls tenant isolation: no shared training, no shared analytics that surface across tenants, vendor employee access logged and limited. Most general-purpose AI voice vendors do not advertise this because it costs them flexibility on the model side. Firms doing serious diligence should ask anyway.
Three vendor-evaluation questions for Rule 1.18 alignment
The right diligence pass with an AI voice intake vendor takes about 30 minutes. The three questions that matter most for Rule 1.18:
- What is your data-use posture for customer call recordings and transcripts? The acceptable answer is "never used for any purpose other than serving the customer's calls." Any softer answer is a Rule 1.18(b) issue.
- At what point in an intake call can the AI run a conflict check against my firm's existing system? The acceptable answer is real-time integration with the firm's CRM or conflict-check database, triggered at first opposing-party disclosure. Anything later is a Rule 1.18(c) issue the firm has to mitigate manually.
- Show me your retention and deletion architecture. Specifically: if a prospective client asks the firm to delete their information, what does the vendor's system require to fully honor that request, including across backups and logs? This is the implementation of Rule 1.6 and Rule 1.18(b) that most vendors have not built.
If a vendor cannot answer all three in writing, they have not done the work for legal-intake use. This is the diligence pass most firms skip and then regret when they end up briefing an ethics opinion.
What "significantly harmful" actually means in 2026
The disqualification standard in Rule 1.18(c) is not triggered by any information disclosed during a prospective consultation. It is triggered by information that "could be significantly harmful" to the prospective client in the matter. The case law on this standard is thin and fact-specific, but a few patterns have emerged:
- Disclosure of legal theories or strategy materially harms the prospective client.
- Disclosure of factual posture (e.g., known weaknesses, settlement floor, witness availability) materially harms.
- Generic disclosure of opposing party identity, matter type, or jurisdiction usually does not, by itself, cross the threshold.
For AI intake, this matters because well-designed intake schemas often move from name and opposing party to factual posture in under 90 seconds. The significantly-harmful threshold can be crossed early in the call. Pattern 2 above (real-time conflict check at first opposing-party disclosure) keeps the firm on the safe side of the threshold. Pattern 1 (next-morning review) does not.
The cost of getting Pattern 1 wrong, in a contested matter where the firm later represents the adverse party, is full-firm disqualification under Rule 1.18(d) unless screening with timely notice was implemented. That is rarely possible after the fact.
The real risk is not the AI
The most defensible reading of Rule 1.18 in the AI voice intake era is that the AI itself is not the regulatory exposure. The exposure is the firm's choice of vendor architecture and intake configuration.
A firm using a vendor with clean data isolation, real-time conflict integration, and clear retention semantics is operating with a Rule 1.18 posture better than most firms had with their phone tree five years ago. A firm using a vendor with shared training data, no conflict integration, and opaque retention is operating in worse shape than they realize.
The diligence pass is short. The questions are concrete. The downside is real. The firms that do this work proactively are the ones least likely to need it.
For the inbound-call regulatory companion piece, see TCPA and AI voice intake. The full architecture for legal intake is mapped on the legal use cases page. To see how we answer all three diligence questions in writing, book a demo.