If Your Website Runs an AI Intake Bot: Disclosure, Conflict Screening, and the Data It Captures

What an AI intake bot actually does on a firm website

An AI intake bot captures matter facts from strangers before any lawyer reviews the file. That places it at the front door of the representation relationship, not off to the side as a marketing widget, and it is where professional duties are most engaged.

An intake bot is the chat widget that greets a visitor, asks what happened, and collects enough detail to route the person to the right place. In its simplest form it captures a name, a phone number, and a short description of the problem. In its more capable form it asks follow-up questions, gathers dates, names of other parties, the nature of an injury or dispute, and sometimes documents, then hands a structured summary to the firm. The more useful the bot, the more matter-specific information it pulls from a stranger before anyone at the firm has looked at the file.

That is the feature and the risk in the same sentence. A form that only takes a name and a callback request collects very little. A conversational bot that draws out the facts of a potential matter is doing intake work that, done by a person, would already be governed by professional duties. The tool does not change what the information is. A description of a dispute, the identity of an adverse party, and the substance of what someone wants a lawyer to do are the same sensitive inputs whether a paralegal writes them down or a model captures them.

So the right way to think about an intake bot is not as a marketing gadget but as the front door to the representation relationship. It sits at the exact point where a prospective client shares information, which is the point the professional rules care about most. Treating it as website furniture, separate from the firm's ethical obligations, is how the three problems in this article get built into a site without anyone deciding to accept them.

The three obligations firms overlook, side by side

Three duties travel with a client-facing intake bot, and they are easiest to see laid out together. The first is disclosure, which is about not misleading the person on the other end. The second is conflict screening, which is about the duties a prospective client can create under Model Rule 1.18 ^[1]. The third is data control, which is about confidentiality under Model Rule 1.6 and what happens to the information the bot captures ^[3]. The table summarizes what each duty asks of a firm and the risk it addresses.

Read the table as a way to structure a conversation with your own counsel, not as a compliance formula. None of these duties is satisfied by a single setting, and the specifics depend on your jurisdiction's adopted rules. The value of the side-by-side view is that it stops any one obligation from being handled while the other two are quietly ignored, which is the usual failure pattern when an intake bot is added to a site.

No single control satisfies these duties. A firm can handle disclosure well and still mishandle conflict screening or data. Work all three, and confirm the specifics with your jurisdiction's rules.

Disclosure: the visitor is talking to a tool, not a lawyer

The first obligation is the most straightforward to state and the easiest to get wrong through omission. A person who lands on a law firm site and starts typing their problem into a chat window may reasonably assume they are reaching the firm, and if the bot is conversational and empathetic, they may assume they are reaching a lawyer. Letting that impression stand creates two related risks: the visitor may believe they have received legal advice, and they may believe they have retained the firm. Neither is true, and clear disclosure is what keeps the impression from forming.

A bot does not itself form an attorney-client relationship simply by answering questions. The risk is not that the software accidentally signs up a client. The risk is that a prospective client is misled about what has happened, which is a problem regardless of the technology's actual legal effect. If someone walks away thinking a lawyer has looked at their situation, or that the firm is now handling their matter, they may miss a deadline, rely on nothing, or disclose more than they should. Plain disclosure at the start of the interaction addresses that directly.

In practice, disclosure means the bot says, before it collects anything, that it is an automated intake assistant and not a lawyer, that the conversation is for gathering information, and that using it does not create an attorney-client relationship or guarantee the firm can take the matter. It means not using scripted language that implies advice is being given. It also means the person can tell they are being routed to human review rather than receiving a decision. This connects to how the firm governs client-facing AI generally, which is worth setting down in a written policy rather than leaving to the vendor's defaults. Our overview of a law firm AI policy covers where a rule like this fits.

A bot does not by itself create an attorney-client relationship. The risk is that a prospective client is misled into thinking one exists, or that advice was given. Clear, up-front disclosure is what mitigates that risk.

Conflict screening: why a prospective client changes the picture

Rule 1.18 means a firm can owe confidentiality to, and be conflicted out by, a prospective client it never signs. An intake bot that gathers detailed matter facts before a conflict check collects exactly the information the rule addresses. Limiting what the bot asks reduces that exposure.

The second obligation is the one firms are least likely to see coming, and it turns on a rule that exists precisely for this situation. ABA Model Rule 1.18 governs duties to a prospective client, meaning a person who consults with a lawyer about the possibility of forming a relationship, even if no engagement ever follows ^[1]. Under that rule, a lawyer who receives information from a prospective client owes a duty of confidentiality with respect to that information, and receiving significantly harmful information can conflict the lawyer, and potentially the firm, out of representing someone else in the same or a related matter.

An AI intake bot that gathers matter facts is, functionally, receiving information from prospective clients at scale. If the bot draws out the substance of a dispute, the identity of the parties, and what the person wants done, it is collecting exactly the kind of information Rule 1.18 addresses ^[1]. The concern is concrete: a firm could gather significantly harmful information about a matter through its bot, from someone who never becomes a client, and later find that information complicates or bars its ability to represent the opposing side. The bot does not have to sign anyone up to create the problem. Collecting the wrong details is enough.

This is why the design of the bot matters as much as the disclaimer attached to it. A bot that is deliberately limited, taking a name, a general category, and a request for a callback, gathers far less of the information that triggers Rule 1.18 concerns than a bot that interrogates the facts before any conflict check has run. Rule 1.18 itself recognizes that limiting the information a lawyer receives from a prospective consultation can reduce the risk of disqualification ^[1]. Building that limitation into the intake flow, so the detailed facts arrive only after a conflict screen, is a design choice with direct ethical consequences. Confirm how your jurisdiction applies Rule 1.18, because states adopt and interpret it differently.

How the bot's questions can create duties before an engagement

It helps to trace the sequence, because the duty attaches earlier than most intake designs assume. A visitor opens the chat, the bot asks what happened, and the visitor describes a dispute in enough detail to be useful. At that moment the firm has received information from a prospective client, and Rule 1.18's confidentiality duty with respect to that information is engaged, whether or not anyone at the firm has read it yet and whether or not the firm will ever take the matter ^[1]. The engagement decision comes later. The duty does not wait for it.

This is different from confidentiality under Rule 1.6, and the difference is worth holding onto. Rule 1.6 is the general confidentiality duty that applies to information relating to the representation of a client the firm actually has ^[3]. Rule 1.18 extends a related, more limited duty to people who are only prospective clients, which is the category almost everyone who talks to an intake bot falls into ^[1]. A firm that thinks about confidentiality only in terms of its existing clients misses the population its bot actually interacts with, which is strangers who may never sign anything.

Neither of these is the same as attorney-client privilege, which is a separate evidentiary protection that courts decide on the facts and that can be waived by disclosure. This article is about the confidentiality duties under Rules 1.18 and 1.6, not about privilege. Keeping those apart matters because a firm can handle its confidentiality obligations carefully and still face a distinct, unsettled question about privilege if a matter is later litigated. For the confidentiality duty across an actual representation, see our overview of client confidentiality and AI.

Rule 1.18 duties to a prospective client can attach the moment the bot receives matter information, before any engagement decision. That is distinct from Rule 1.6 confidentiality for existing clients, and both are distinct from evidentiary privilege, which courts decide separately.

The data the bot captures, and where it goes

The third obligation is about the information itself: what the bot logs, where that data travels, and how long it stays. An intake conversation can contain names, contact details, the facts of a dispute, the identity of adverse parties, and sometimes uploaded documents. Under Rule 1.6, information relating to a representation must be protected, and the prospective-client information a bot gathers carries related confidentiality duties under Rule 1.18 ^[1][3]. So the question of where that data goes is not an IT detail. It is a confidentiality question with the bot's architecture as the answer.

Several parts of the pipeline deserve specific attention. The first is the third-party model. Many intake bots send the visitor's text to an external AI service to generate responses, which means the substance of a prospective client's matter may leave the firm's control and enter a vendor's systems. Whether that vendor trains on the input, how long it retains it, and who can access it are all questions a firm should be able to answer before deploying the bot, not after. ABA Formal Opinion 512 addresses confidentiality when client-related information enters generative AI tools, including consent considerations, and its reasoning is relevant even though it is written about representation rather than intake specifically ^[2].

The second is retention and isolation. Prospective-client conversations that are stored indefinitely, mingled with everything else, become a growing pool of confidential information that also carries the Rule 1.18 conflict risk described above. A firm that isolates prospective-client intake data, applies a defined retention period, and keeps it separate from matters it has declined is in a better position than one that lets the transcripts accumulate. The third is consent: telling the visitor, in terms they can act on, that their information will be processed by an automated tool and what that involves. None of this is a single setting, and the right configuration depends on the vendor, the model, and your jurisdiction.

• Third-party model exposure: does the visitor's text leave the firm for an external AI service, and does that vendor train on or retain it ^[2]?
• Retention: how long are intake transcripts kept, and are declined-matter conversations purged on a defined schedule?
• Isolation: is prospective-client data separated from existing-client matters and from matters the firm has turned down ^[1]?
• Consent: is the visitor told, in plain terms, that an automated tool is processing their information, and what that entails ^[2]?
• Access: who inside and outside the firm can read the captured conversations, and is that access logged?

Where the bot's data goes is a confidentiality question, not just an IT question. Third-party model exposure, retention, isolation, and consent each need a deliberate answer before the bot is live, confirmed against your jurisdiction's rules.

Consent and disclosure under ABA Opinion 512

Opinion 512 addresses confidentiality when client-related information enters AI tools, including consent considerations. It is written about representation, so applying it to a public intake bot takes care, but its core concern maps onto intake. It is guidance, not a checkbox, and states adopt it differently.

ABA Formal Opinion 512, issued in 2024, addresses the confidentiality duties that arise when information relating to a representation enters generative AI tools, and it treats informed consent as a consideration rather than an automatic requirement ^[2]. The opinion is written primarily about lawyers using AI in the course of representing clients, so applying it to a public intake bot requires care. The bot is interacting with prospective clients, not existing ones, and the information it gathers falls under Rule 1.18 as much as Rule 1.6. Still, the opinion's underlying concern, that confidential information should not flow into an AI system without appropriate attention to how the tool handles it, maps directly onto the intake context ^[2].

The practical read is that a firm should think about consent and disclosure together at the point of intake. Disclosure tells the visitor they are talking to a tool and not a lawyer. Consent, in the sense Opinion 512 gestures at, is about the visitor understanding that an automated system, possibly involving a third-party model, is processing what they type ^[2]. These are two facets of the same up-front honesty. A bot that opens by saying it is an automated assistant, that it is gathering information for the firm to review, and that the person's input will be handled by software, is addressing both at once, in language the visitor can actually act on.

What Opinion 512 does not do is convert any of this into a mechanical checkbox, and this article does not either. The opinion is guidance, states adopt it differently, and the intake setting sits at the edge of what it was written to address. Treat it as a reason to be deliberate about disclosure and data handling at the front door, and take the specific application to your own counsel. For a fuller walkthrough of the consent question in the representation context, see our piece on whether you must tell a client you used AI under Opinion 512.

Setting up a compliant intake bot, step by step

The three obligations are easier to meet if they are built into the intake flow from the start rather than bolted on after launch. The sequence below is a structuring aid that maps to disclosure, conflict screening, and data control, and it is written to keep the risky steps, gathering detailed facts and sending data to a model, behind the protective ones. It is not legal advice and it does not replace your jurisdiction's rules or your own counsel's judgment on your specific setup.

Work the steps in order, and stop to change the design at the first point where the honest answer says the bot is collecting more than it should before the firm is ready to receive it. The goal is a bot that is genuinely useful for routing prospective clients while gathering as little of the Rule 1.18-triggering detail as possible until a conflict screen has run ^[1].

1. Lead with disclosureOpen the conversation by stating that the bot is an automated intake assistant and not a lawyer, that it is gathering information for the firm to review, and that using it does not create an attorney-client relationship.
2. Limit what you ask up frontDesign the initial flow to collect a name, contact detail, and a general category, not the detailed facts of the matter, so the bot gathers less of the information that triggers Rule 1.18 concerns before a conflict check ^[1].
3. Run a conflict screen before deep intakeRoute the person to a conflict check against the general category and parties before the bot or a human draws out significantly harmful matter details, reducing disqualification exposure ^[1].
4. Map the data pathDocument what the bot logs, whether text is sent to a third-party model, whether that vendor trains on or retains it, and who can access the transcripts ^[2][3].
5. Isolate and set retentionKeep prospective-client intake data separate from existing matters and from declined matters, and apply a defined retention and purge schedule.
6. Capture consent and disclosure in the recordKeep a record that the disclosure was shown and that the visitor proceeded, so the firm can show what the person was told rather than merely assert it.

This sequence is a structuring aid, not legal advice. The right configuration depends on your vendor, your model, and your jurisdiction's adopted rules. Apply it with your own counsel.

Attesting what the bot captured and that confidential material stayed isolated

Whatever a firm decides, there is a gap between configuring the bot correctly and being able to show, later, that it behaved as configured. A firm can lead with disclosure, limit early questions, and isolate prospective-client data, and still, months on, be unable to demonstrate that the disclosure was actually shown, that a given conversation stayed out of a third-party model, or that declined-matter transcripts were purged on schedule. The controls become assertions about what the software usually does rather than a record of what it did in a specific instance.

This is the narrow thing verification tooling can help with, and it is worth being precise about the claim. RankShield Legal's approach is designed to attest what an intake bot captured and that any privileged or confidential material stayed isolated, whether by being withheld from a third-party model, redacted, tokenized, or handled locally, binding the interaction, the disclosure shown, the firm's policy, and the captured consent into a record that can be verified independently later. That attests to architecture and to consent. It does not attest to a legal conclusion about whether duties were satisfied. The attestation gateway for intake is a roadmap item, not a shipped product, and this article labels it as such.

The honest boundary holds here as it does elsewhere. An attestation can show that isolation functioned as designed and that disclosure and consent were captured. It cannot decide whether a Rule 1.18 duty attached, whether a conflict exists, or whether privilege was preserved, because those are legal determinations, not controls a vendor can enforce. What it changes is not the rules. It changes whether a firm can show what its bot actually did, at the moment someone asks. The isolation mechanics are covered in our note on privilege isolation.

Attestation evidences that disclosure and consent were shown and that material was isolated. It does not decide whether a Rule 1.18 duty attached or whether privilege was preserved, which are legal determinations. The intake attestation gateway is a roadmap item, not shipped.

Factors to work through with your own counsel

None of this has to be reinvented for every site. The same handful of questions comes up whenever a firm puts a conversational tool at its front door, and answering them before the bot goes live means the three obligations are handled by design rather than discovered after a problem. These questions map to the disclosure, conflict, and data duties laid out above, and they are meant to structure a conversation with a licensed attorney in your jurisdiction, not to substitute for one.

This article is general information from a founder who builds verification tools for law firms, not legal advice, and not an opinion on any specific matter. ABA opinions and model rules are adopted and interpreted differently from state to state, the confidentiality duties under Rules 1.18 and 1.6 are distinct from evidentiary privilege, and how Rule 1.18 applies to an automated intake tool is a question your own counsel should answer for your practice. Use the questions below as a starting point.

• Does the bot clearly disclose, up front, that it is an automated tool and not a lawyer, and that using it does not create an engagement?
• How much matter detail does the bot gather before a conflict check, and could that information trigger Rule 1.18 duties to a prospective client ^[1]?
• Does the visitor's text reach a third-party model, and does that vendor train on or retain it ^[2]?
• Is prospective-client intake data isolated from existing matters and declined matters, with a defined retention schedule ^[3]?
• Can the firm later show, not just assert, that disclosure was shown and that sensitive material was isolated?
• How does your jurisdiction apply Rule 1.18 and its confidentiality duty to information gathered through an automated intake tool ^[1]?

This is informational, not legal advice. Because these are ethics questions that vary by jurisdiction and by facts, consult a licensed attorney in your jurisdiction before relying on any AI intake workflow.