California SB 574: What It Means for Legal AI Architecture

On October 1, 2026, California became the first state to put a number on what managing partners have been quietly worrying about for two years: the moment a client's privileged document becomes a training signal, a retention artifact, or a subpoena target inside someone else's cloud. SB 574, signed this week, doesn't ban AI in legal practice. It does something more consequential — it codifies liability around exactly the behaviors that most firms' current AI tools quietly encourage: pasting confidential text into a chat window, letting an agent "figure it out" without attorney review, and trusting a vendor's privacy policy as a substitute for an architecture decision.

This is not a reason to pause adoption. It's a reason to audit what you've already deployed, because a meaningful share of pilot programs running inside AmLaw 200 firms today would not survive a straightforward reading of this statute.

What SB 574 Actually Says — And Why It's Narrower Than the Headlines Suggest

Strip away the alarmist framing and SB 574 does two specific things.

First, it restricts attorneys from delegating core legal-practice functions — judgment calls, substantive analysis, final advice — to an AI system without meaningful attorney supervision. This tracks existing ABA Model Rule 5.3 guidance on supervising non-lawyer assistance, but puts state statutory teeth behind it for the first time. An agent that drafts a memo is fine. An agent that decides the litigation strategy without a lawyer reviewing the reasoning is now a bar discipline and malpractice exposure issue, explicitly.

Second, and more operationally urgent, it restricts entering confidential or personal information into AI tools that don't provide adequate data protection guarantees. The statute doesn't define "adequate" with a bright-line technical standard — which is exactly the point. It shifts the burden to the firm to demonstrate the safeguard was reasonable, in writing, at the time the data moved.

That burden-shifting is the detail most coverage has buried. It means the relevant question for a GC or managing partner is no longer "did we have an AI policy?" It's "can we show, document by document, what left our environment, where it went, under what contract terms, and who authorized it?" Most firms cannot currently answer that question for their own Copilot, ChatGPT Enterprise, or browser-based AI assistant usage.

The Exposure Most Firms Don't Realize They Have

Industry surveys consistently put unauthorized or unmanaged AI tool usage inside law firms at 60-75% of associates and paralegals, even at firms with a stated AI policy. That's not a hypothetical compliance gap — it's the default state of most practices going into this statute.

The mechanics matter here. When an attorney pastes a client contract into a general-purpose AI chat tool to "summarize the indemnification clause," three things typically happen that SB 574 now puts under a legal microscope:

• The full document — not just the relevant clause — transits to a third-party server, often outside any firm-negotiated data processing agreement.
• Retention and training-use terms are governed by the consumer or prosumer tier of a vendor's terms of service, which frequently differ materially from enterprise agreements firms believe they've signed.
• No firm-controlled log captures that the transfer happened, what document it was, or who authorized it — meaning if a client or opposing counsel asks, the firm has no audit trail to produce.

None of this requires malicious intent. It's the natural behavior of convenient, consumer-grade AI tools layered onto legal workflows without architectural guardrails. SB 574 makes that convenience a liability line item.

A Quick Diagnostic: Where Is Your Firm Today?

If your firm is answering "high exposure" to two or more rows, SB 574 isn't abstract risk. It's a current-state compliance gap with a signed statute now attached to it.

Why "Minimized Exposure" Is the Architecture SB 574 Is Pointing At

Here's the honest version of this argument, because the lazy version — "other tools send your data out, we never do" — isn't true and isn't useful. Every serious legal AI platform, including RAGbase Legal, ultimately calls an LLM provider. Someone's model does the reasoning. The question SB 574 forces firms to answer isn't whether a third-party model touches your data — it's how much data, in what form, under whose terms, and with what record of it afterward.

That's an architecture question, not a vendor-loyalty question.

Shared-cloud legal AI platforms — the category that includes most per-seat SaaS tools currently in AmLaw pilot programs — typically operate by ingesting firm documents into the vendor's cloud environment, indexing them there, and running the full agentic workflow (retrieval, reasoning, drafting, memory) on vendor infrastructure. The firm's full corpus, its permission structure, and its usage logs all live outside firm walls, governed by the vendor's infrastructure decisions and subject to the vendor's breach notification timeline, not the firm's.

Private, on-premise AI architecture — the model behind private AI deployment — inverts which layer sits where. The full document corpus, the retrieval index, the vector store, the permission system, and the query/response logs all remain on firm-controlled infrastructure. When a user asks a question, the system retrieves only the specific chunks relevant to answering it — typically a few hundred to a few thousand tokens out of a document that might run tens of thousands — and sends only those chunks to the selected LLM provider, under API terms the firm has chosen and can audit.

The distinction in plain terms:

  "Contract terms for the LLM call" | Vendor's negotiated terms (often undisclosed to firm) | Firm's own API agreement with chosen provider |

| Defensibility under SB 574-style audit | Depends on vendor cooperation | Firm can produce full audit trail independently |

This is precisely the structure SB 574 rewards. Not because confidential data never reaches a model — it does, because that's how the reasoning happens — but because the volume, framing, and record-keeping of what leaves the building are under the firm's direct control, auditable on demand, and minimized by design rather than by policy memo.

The Competitive Landscape Just Got a New Variable

Tools like Harvey, CoCounsel, Lexis+ Protege, Legora, and Claude Cowork have driven real adoption momentum over the past 18 months, and each has made legitimate enterprise security claims — SOC 2 attestations, zero-retention agreements, encryption at rest. Those commitments matter and shouldn't be dismissed.

But SB 574 asks a different question than "is the vendor secure." It asks "can the firm demonstrate control and minimization," and that's an architectural property, not a certification. A vendor can be fully SOC 2 compliant and still require the firm to upload entire documents into vendor-managed storage to make the product work — which satisfies a security audit but doesn't satisfy a minimization-and-firm-custody standard.

For firms evaluating tools through 2027, the practical diligence question shifts from "what's your security certification" to three sharper ones:

1. Does the full document ever leave firm infrastructure, or only retrieved fragments?
2. Who holds the audit log of what was sent to the model and when — the firm, or the vendor?
3. If a regulator or opposing counsel demands a full accounting of data movement on a specific matter, can the firm produce it without the vendor's cooperation?

Firms running case search and research workflows against sensitive matter files should be running this diligence now, not at renewal.

What Managing Partners and GCs Should Do This Quarter

SB 574 compliance isn't a one-time memo. It's an operating discipline, and the firms that get ahead of it will treat it as a procurement and architecture decision rather than a training slide.

• Inventory current AI tool usage, including shadow usage. Survey data suggests the gap between sanctioned and actual AI usage at most firms is wide; close it before a regulator or malpractice carrier closes it for you.
• Require a data-flow diagram from every AI vendor, not a security questionnaire. Ask specifically what leaves firm infrastructure and in what form — full document, summary, or minimized chunk.
• Separate supervision policy from architecture. A firm can have a perfect AI-use policy on paper and still be exposed if the underlying tool doesn't structurally support the controls the policy describes.
• Audit logs need to be firm-owned, not vendor-provided-on-request. If producing a log requires a vendor support ticket, it isn't defensible under a statute built around burden-shifting.
• Treat this as a multi-state issue starting now. California's privacy and AI legislation has a documented pattern of becoming the de facto national standard within two legislative cycles — firms with any California-licensed attorneys or California clients should assume this reaches them regardless of headquarters.

For firms building a broader AI roadmap, the AI for law firms guide walks through how to sequence adoption against exactly these risk categories rather than treating security and capability as separate workstreams.

The Forward View

SB 574 will not be the last statute of this kind, and it won't be the strictest. What it establishes — burden-shifted accountability for data minimization and attorney supervision — is a template, not an endpoint. Expect New York, Texas, and Illinois bar associations to reference similar language in ethics opinions within 12-18 months, and expect malpractice carriers to start asking about AI data architecture in renewal questionnaires well before any of those statutes pass.

The firms that treat this as validation rather than obstruction will move faster, not slower, over the next two years. The ones that keep layering consumer-grade AI tools onto confidential workflows and hoping their usage policy covers them will find out, probably during discovery in someone else's case, exactly how thin that cover was.

If you're reassessing your firm's AI architecture against SB 574 — or anticipating that your state will follow California's lead — the right first step isn't a new policy document. It's a data-flow audit of the tools already in use, matched against where your most sensitive matters actually sit.