What Your Legal AI Can Say on Case Status Calls

Clients call for updates because they have no other view into their case. A personal injury client waits months between events. Silence feels like neglect, so they phone. A voice agent can absorb those calls. Law firm AI case status calls also let it say something the firm would never allow.

This post is for the team that built an AI voice agent for law firms, or runs an AI receptionist for law firms inside a case management product. It maps what the agent may say about an existing matter, where it must stop, and how to test each boundary. It is not legal advice. Your state's rules control, and counsel sets the final policy.

Why law firm AI case status calls are riskier than intake

Intake calls talk to a stranger who wants to hire the firm. Status calls talk to someone about a matter that already exists. The agent now holds facts that belong to a client. That changes the risk.

Three failures show up on status calls that rarely appear at intake:

• The wrong person gets the facts. A spouse, an adjuster or a reporter calls and sounds confident.
• The agent answers a legal question. "Should I take this offer?" sounds like a status question. It is not.
• The agent guesses. A model asked "when will this settle?" will produce a plausible timeline from nothing.

For the front of the funnel, see AI legal intake QA and personal injury AI intake errors. This post covers life after the client signs.

A personal injury case status call carries real pressure to answer. The ABA reports that lack of communication is the second most common disciplinary complaint, after neglect (ABA, "Protect yourself from common disciplinary complaints," 2022). The Florida Bar calls communication complaints "always in the top 10" (Florida Bar News, 2024). A firm that deflects every status call has a problem. A firm that answers too freely has a different one.

The four rules that shape every answer

Four professional conduct rules set the limits. These are the ABA Model Rules. States adopt their own versions, so check yours.

Rule 1.4, communication. A lawyer must "keep the client reasonably informed about the status of the matter" and "promptly comply with reasonable requests for information" (ABA Model Rule 1.4). This is the reason to build the agent at all. Status requests are expected, not a nuisance.

Rule 1.6, client confidentiality. A lawyer shall not reveal "information relating to the representation of a client" unless the client consents, disclosure is impliedly authorized, or an exception applies. Paragraph (c) adds a duty to "make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to" that information. I read the text from Washington's RPC 1.6, which follows the Model Rule. The phrase "information relating to the representation" is broad. Treat even confirming that a person is a client as covered. That is a conservative policy choice, not a quotation of the rule.

Rule 5.3, nonlawyer assistance. Lawyers with managerial authority must make "reasonable efforts to ensure that the firm has in effect measures giving reasonable assurance" that a nonlawyer's conduct is compatible with the lawyer's obligations (Massachusetts Rule 5.3). Whether software counts as a "nonlawyer" varies by state. The safe reading is to supervise the agent as if it did. ABA Formal Opinion 512 says lawyers must ensure nonlawyers are adequately trained in generative AI use (ABA Business Law Today).

Rule 5.5, unauthorized practice. A lawyer shall not practice law in violation of a jurisdiction's rules "or assist another in doing so" (Minnesota Rule 5.5(a); check your state's version). Explaining a legal consequence, or recommending a choice, is legal advice. A voice agent that does it creates exposure for the firm.

Opinion 512 adds that informed consent is required before client information goes into a self-learning tool, and "boilerplate waivers will not suffice" (NCBE, The Bar Examiner, Fall 2024). Ask how vendor agreements treat call audio. Your test plan should also record which data the agent actually receives.

A permission ladder for status answers

Most failures come from one blurry rule: "be helpful about the case." Replace it with a ladder. Each rung is a question the agent must pass before it speaks.

The point is order. Verification comes first, before any lookup. A model that looks up the matter and then asks for identity has already put the facts in its context. Do not rely on a prompt line saying "do not reveal until verified."

What counts as a safe status fact

The firm decides this list, not the model. A workable starting set for personal injury:

• Next scheduled event: court date, deposition, mediation.
• Last action taken: records request sent, demand letter sent.
• Stage: treatment ongoing, pre-suit, in litigation.
• Who to contact next and when staff will call back.

CloudLex, a personal injury case management vendor, publishes a design along these lines. Its Lexee AI Client Web Assistant page, read in October 2026, says it answers from matter data covering "case status, next steps, upcoming events." It says Lexee checks the caller's phone number against the plaintiff's number on the case, then sends a one-time passcode. It says Lexee "provides case status updates and factual information only" and "does not interpret case law, evaluate claims, or provide legal opinions" (CloudLex Lexee Client Web Assistant). Whatever you build, that is the shape to match: verify, answer from approved data, refuse judgment, escalate.

CloudLex's separate Client Messenger sends case updates as matter-linked messages (CloudLex Client Messenger). A voice agent can hand a verified caller to a client portal or messenger for anything long.

What the agent must never say

These are the answers a status call tempts a model to give:

1. Outcome predictions. "You should win this." "It will probably settle."

2. Case valuation. "Cases like yours are worth around..."

3. Advice on offers. "I would not accept that."

4. Legal consequences. "Posting that photo won't hurt you."

5. Deadlines stated as legal conclusions. "The statute of limitations is two years." The firm's calendar may say a date. The agent should not explain the law behind it.

6. Attorney strategy. What the lawyer is planning or thinks of the adjuster.

Who is calling? Caller identity verification is the hard part

Every status call starts with a claim: "This is Maria Gonzalez, I have a case with you." The agent must check that claim. Voice makes this harder than a web portal, for three reasons.

Spoken names collide. "Gonzalez" and "Gonzales" sound alike. So do "Smith" and "Smyth," or two clients named Johnson. If the agent finds a matter by spoken name, an ASR error opens the wrong file. A transcript shows the intended name. The audio shows what was actually said. That gap is where the leak starts.

Caller ID is a claim, not proof. A number match is a useful signal. It does not prove who holds the phone. A one-time passcode sent to the number on file is stronger, and it is the pattern CloudLex describes. It also removes the dependence on spoken names, because the agent can match on the number first.

Third parties sound legitimate. A spouse, parent, adult child, employer or insurance adjuster may call. They know the client's name and the accident date. Public details are not authority. A firm may have a signed authorization for a family member, and it may not. The agent should never infer one from tone.

The practical rule: the agent shares status facts only with a caller who passed the firm's verification, and only about that caller's own matter. For everyone else, it takes a message. It does not even confirm whether the person is a client.

See credit union AI voice member verification for verification mechanics. The same failure modes apply.

A safe script for a failed verification

This exchange is illustrative, not a firm-approved script.

Caller:  "Hi, this is Dan. I'm calling about my wife's accident case."
Agent:   "I can't discuss any matter on this line without verifying the
          client first. I can take your name and number, and a team
          member will call the number we have on file."
Caller:  "She's right here, she said it's fine."
Agent:   "Thanks. The client can call us from her own number, or I can
          send her a code. I can't share details otherwise."

Note what the agent does not say. It does not say "I can't discuss her case," which confirms a case exists. It talks about "any matter" and "the client." A model will drift toward the confirming version unless a test catches it.

Keep restricted data out of the model

The strongest control is not a better prompt. It is a smaller context. The model cannot repeat what it never received.

Build a tool the agent calls after verification. It returns a fixed, firm-approved object. Staff notes, medical details beyond milestones, reserve or valuation figures, and attorney strategy are never in the response. Here is a simplified Python sketch. It is a pattern, not a vendor API.

APPROVED_FIELDS = {"next_event", "last_action", "stage", "callback_window"}

def get_case_status(matter_id: str, verified: bool) -> dict:
    if not verified:
        return {"error": "not_verified"}        # no facts at all
    row = db.fetch_matter(matter_id)             # your case system
    return {k: row[k] for k in APPROVED_FIELDS if k in row}
    # notes, valuation, medical detail: never selected

def verified_for(matter_id: str, session) -> bool:
    return (
        session.otp_passed
        and session.caller_number == db.plaintiff_number(matter_id)
        and session.matter_id == matter_id       # bound at verification
    )

Two details matter. The `matter_id` is bound to the session at verification, so a later spoken name cannot switch matters. And the allow-list is a positive list of fields, not a blocklist. New columns added by the case system never leak by default.

Even then, the model can invent. Asked "what happens next?", it may fill the gap. That is a grounding failure. Score it with testing knowledge grounding and hallucination rate. Any claim not traceable to the returned object counts as a failure.

What to do when the question is a judgment

Some questions look like status requests and are not. The agent needs a clear, warm refusal that still moves the caller forward. A bare "I can't help with that" produces another call, and a complaint.

Offers are the tricky row. Whether an offer's existence is a safe status fact is a firm policy call. Some firms want the client told at once. Others want the attorney to deliver it. The agent must follow whichever the firm chose, per matter type, and never decide for itself.

The escalation itself needs testing. See escalation accuracy and handoffs for scoring whether a handoff landed well.

Disclosure, recording and outbound updates

Three smaller issues belong on the checklist.

AI disclosure. Opinion 512 says lawyers must separately consider whether other rules require disclosing GAI use, that disclosure is required if the client asks, and that informed consent is needed in advance when GAI use affects fees (NCBE). That addresses the lawyer's use of tools. Whether a callback bot must announce itself depends on your state, and I did not verify state bot-disclosure laws. Test that the agent answers honestly when a caller asks "am I talking to a person?"

Call recording. Recorded status calls can hold material protected by attorney-client privilege. Where audio goes and who can hear it are Rule 1.6(c) questions. Decide before launch.

Outbound status calls. If the agent calls clients with updates, the FCC's February 2024 ruling applies. The FCC confirmed that AI-generated voices are "artificial" under the TCPA, so calls need the consent the statute requires unless an exemption applies (Cooley summary). See outbound voice agent testing. Counsel should confirm your consent language.

How to test a legal AI on case status calls

You need a repeatable protocol. Test calls from the engineer who wrote the prompt will not find these failures. That tester knows the rules and speaks clearly. Real callers do neither.

1. List the approved facts and the forbidden answers. Get both lists from the firm in writing. Version them. Every test traces to a line on one of them.

2. Build a scenario matrix. Cross caller type with question type. Callers: verified client, client who fails verification, spouse, adjuster, name-collision caller, angry client. Questions: approved fact, offer, valuation, advice, prediction, "are you a bot."

3. Add acoustic conditions. Run each cell with accents, fast speech, interruptions, road noise and a bad cell line. Verification and name capture break under these first.

4. Plant canaries. Seed the test matter with unique fake values in restricted fields, such as a fake valuation figure. If a canary string appears in any agent speech, the data tier leaked.

5. Score from audio. Judge what the agent said, not only the transcript. A transcript may show a clean answer while the audio says something different, or may mis-hear the caller's name.

6. Set pass thresholds. Zero tolerance on leakage, valuation and advice. A separate, softer threshold on routing quality.

7. Rerun on every change. A prompt edit, model swap or tool schema change can reopen a closed hole. See shipping prompt changes safely.

Worked math: how many calls is enough?

Say you want to claim a leakage rate under 2% with 95% confidence, and you observe zero leaks. With zero failures, you need `n` such that `(1 - 0.02)^n <= 0.05`. That gives `n = ln(0.05) / ln(0.98)`, which is about 148.3, so run 149 clean calls. For a 1% claim, you need about 299. This is the standard zero-failure bound, and it assumes independent calls.

Now see why it matters. Take an illustrative firm line with 400 status calls a week. Suppose 3% come from non-clients, which is 12 calls. If the gate misses one in twenty, that is 0.6 disclosures a week, or about 31 a year. A handful of hand-placed test calls will not surface a 5% miss rate reliably. A matrix of several hundred will. These are assumptions, not industry data.

Evalgent generates test scenarios from an agent's prompt and flows, including its policies and hard constraints, so the forbidden-answer list can become test cases. Its caller profiles vary accent, pace, interruption level and background noise. That covers step 3. It judges from the audio rather than only the transcript, which matters for name capture. Evalgent works with teams to set up evals for their first agent.

Monitor law firm AI case status calls after launch

Pre-launch tests cover what you imagined. Live callers do something else. Once the agent is live, review production law firm AI case status calls against the same ladder.

Sample calls each week. Flag any where the agent spoke a restricted category, answered before verification, or confirmed a client relationship to an unverified caller. Track advice-shaped questions too, because a spike can signal a prompt regression.

Evalgent's production monitoring takes call recordings that customers push. It transcribes them, maps them to scenarios, judges them, and flags issues such as PII leakage, tool-call failures and policy failures with fix recommendations. For a broader view, see monitoring voice agents in production. For the policy test cases behind regulated agents, see voice agent compliance testing.

A flagged call should reach a person who can tell the firm, since Rule 5.3 puts supervision on lawyers. Keep records of each fix, because "reasonable efforts" under Rule 1.6(c) is easier to defend with them.

If your agent serves many firms, each one has its own approved list and escalation rules. Test per tenant. Our post on multi-tenant voice agent testing explains why one firm's config must never reach another's call. Before you onboard each firm, run the go-live checklist.

Frequently asked questions

Can an AI answer case status calls for a law firm?

Yes, within limits. The agent can verify the caller and read back facts the firm pre-approved, such as the next court date or last action taken. Rule 1.4 expects clients to be kept informed. The agent must not give legal advice, predictions or valuations, and it must not confirm client status to unverified callers.

What can a law firm AI say about a client's case?

It can say what the firm approved in advance: next scheduled event, last action, current stage and when staff will call back. It cannot interpret law, evaluate claims, predict results or discuss strategy. The firm's approved-field list defines the boundary, and the agent should receive only those fields after verification.

How does a legal AI verify who is calling?

The strongest pattern matches the caller's number to the number on the case, then sends a one-time passcode to that number. Spoken names alone are weak, because similar-sounding names collide and caller ID can mislead. CloudLex describes a number match plus a passcode in its Lexee assistant documentation.

Can a legal AI tell a client how much a case is worth?

No. Valuing a case is a legal judgment, and a voice agent giving a figure or range risks unauthorized practice of law and false expectations. The agent should decline warmly, log the question and arrange a callback with the attorney. Keep valuation data out of the agent's tool responses entirely.

Does an AI phone agent count as unauthorized practice of law?

Rule 5.5(a) bars lawyers from assisting unauthorized practice, and states define practice differently. Reading approved facts is generally not advice. Interpreting law, recommending actions or evaluating offers is. Treat any judgment answer as out of bounds and have your firm's counsel confirm the line for your state.

What should a legal AI do when a family member calls about a case?

Treat them as a third party. Do not confirm or deny that the client exists. Take a name, number and message, and have staff call the number on file. Share nothing unless the firm holds a signed authorization and the caller passes its verification. Public details such as the accident date are not authority.

Do law firms have to tell clients they are talking to an AI?

Opinion 512 says lawyers must consider whether to disclose generative AI use, must disclose if the client asks, and need informed consent when use affects fees. State bot-disclosure laws vary and I did not verify them. Test that the agent answers truthfully when asked whether it is a person.

How do you test a legal AI before it talks to clients?

Build a matrix of caller types and question types, then run it under accents, noise and interruptions. Plant canary values in restricted fields. Judge from the audio. Require zero leakage and advice, and rerun the matrix after every prompt or model change. About 149 clean calls supports a 2% bound.

The bottom line

A status-call agent is safe when it can only say what the firm approved, and only to someone who proved who they are. Enforce that with a small data tier and a verification gate, then prove it with canary-seeded tests and audio-based scoring on every change.