SB 574's Confidentiality Rule Makes Access-Controlled AI Law

On September 30, 2026, Governor Newsom signed a bill that quietly ended the era of generative AI as a professional-responsibility gray area for California lawyers. SB 574 is the first comprehensive statute in the country to govern how attorneys use generative AI in practice — and buried inside it is a single clause that will force every AmLaw 200 firm with California-licensed attorneys to re-examine its AI architecture, not just its AI policy.

That clause, codified at Business & Professions Code §6068.1(a)(3)(A), bars lawyers from entering confidential or personally identifying client information into a generative AI system unless input access is restricted to the attorney and other individuals authorized to access the information. It takes effect January 1, 2027. For the fifteen months between signing and enforcement, firms have a narrow window to answer a question that most have so far dodged with policy memos and user training: does our AI stack actually restrict access by design, or does it just ask users nicely not to paste in client data?

What SB 574 Actually Requires

SB 574 isn't a single prohibition — it's a four-part duty structure layered onto California's existing rules of professional conduct. Under the new §6068.1, attorneys must:

• Restrict input access — confidential or personally identifying client information entered into a generative AI system must be accessible only to the attorney and authorized individuals (§6068.1(a)(3)(A))
• Verify and correct output — attorneys cannot rely on AI-generated work product without independently checking its accuracy
• Personally verify citations — legal citations produced by AI tools must be confirmed by the attorney, not delegated back to another AI tool or assumed correct
• Disclose AI use to courts — where court rules or orders require it, attorneys must affirmatively disclose generative AI use in filings

Each duty maps to a documented failure mode already working its way through courtrooms nationally. The citation-verification requirement is a direct legislative response to incidents like Mata v. Avianca, where fabricated case citations generated by ChatGPT made it into a federal filing, and the dozens of similar sanctions orders that have followed since — Stanford RegLab researchers found that general-purpose AI tools hallucinate legal facts or citations in 58% to 82% of benchmark queries, depending on the model and task. The disclosure requirement responds to judges increasingly issuing standing orders on AI use in their courtrooms. But the confidentiality provision is different in kind. It isn't about catching bad output after the fact — it's about controlling where client data goes before a model ever generates a response.

The Provision That Changes the Compliance Calculus

Most firm AI policies written in 2023 and 2024 treated data confidentiality as a matter of user discipline: don't paste privileged material into public chatbots, use approved tools, route sensitive matters through IT-vetted vendors. These were best practices, enforced through training and spot audits, with violations handled as internal HR matters.

SB 574 converts that best practice into a statutory duty with teeth. Three enforcement mechanisms now attach to the same conduct that used to generate, at worst, a stern email from risk management:

1. CCP §128.7 sanctions — courts can sanction attorneys (and the statute makes clear firms are jointly responsible) for filings or conduct that violate the confidentiality or verification duties
2. State Bar discipline — §6068.1 sits in the statute governing attorney duties, meaning violations are now a disciplinary matter, not just a malpractice exposure
3. Malpractice and client-relations fallout — a confidentiality breach traceable to an uncontrolled AI input is now a per se statutory violation, not a negotiable standard-of-care argument

The practical effect: a firm can no longer point to a written AI-use policy as its compliance artifact. The policy has to be backed by an architecture that makes the prohibited conduct structurally difficult, because "we told our associates not to do that" is a materially weaker defense against a statutory violation than it ever was against a vague ethical guideline. This is the same shift the legal industry saw with cybersecurity and data breach notification laws a decade ago — once a practice becomes a statutory duty, the audit question changes from "what does your policy say" to "what does your system actually enforce."

Why "Restricted Access" Is an Architecture Question, Not a Policy Question

The statutory language — access restricted to the attorney and authorized individuals — describes a technical access-control model, not a behavioral guideline. That distinction matters because the generative AI tools currently in widest use across law firms were not built with this model in mind.

Most consumer and many enterprise-cloud AI tools are architected around pooled or vendor-visible data: prompts and documents pass through multi-tenant infrastructure, may be logged or retained by the vendor, and in some product tiers can be used to improve the underlying model unless the firm has specifically negotiated opt-outs. Even where vendors offer enterprise agreements with no-training clauses, the fundamental architecture still routes full client documents — not just the relevant fragments — to infrastructure outside the firm's direct control, governed by the vendor's logging, retention, and access policies rather than the firm's own.

That's the gap SB 574 exposes. A firm can have excellent contractual terms with a vendor and still fail the statute's plain language if the system design means input access extends beyond "the attorney and other individuals authorized to access the information." Authorization under a client engagement letter doesn't automatically include a vendor's infrastructure engineers, a model-training pipeline, or a multi-tenant log store that other customers' queries also pass through.

Architecture Comparison Under SB 574

The rightmost column isn't a marketing claim — it's a description of where document custody physically sits. In a private or private AI deployment, the firm's full document corpus, its retrieval index, its vector store, its permissioning layer, and its audit logs all remain on infrastructure the firm controls. The only thing that leaves that environment is the minimal set of retrieved passages needed to answer a specific query, sent to whichever LLM provider the firm has selected, under API terms the firm has negotiated. That's a meaningfully different data path than uploading a client's deposition transcript wholesale into a shared chat interface.

RAGbase Legal's Position: Minimized Exposure, Not Zero Exposure

It's worth being precise here, because the honest version of this argument is more defensible than the simplistic one. RAGbase Legal's architecture also calls out to large language model providers to generate responses — it does not eliminate every external data touchpoint, and firms should be skeptical of any vendor claiming otherwise. What changes is the shape of what leaves the firm's control.

In a retrieval-augmented architecture, the agentic scaffolding, the connectors into document management and practice systems, the retrieval and indexing layer, the vector stores, the permissions model, and the activity logs all sit on the firm's own infrastructure. When an attorney queries the system, the retrieval layer pulls the specific passages relevant to that query — not the full document set, not the full client file — and sends only those minimized chunks to the selected model provider to generate a response. The firm chooses which provider, under what data-handling terms, and can swap providers without re-architecting its entire knowledge base.

That's the distinction that matters under §6068.1(a)(3)(A): full corpus and agent infrastructure under client-authorized, firm-controlled access, versus minimized, task-specific fragments sent to a model under terms the firm itself negotiated — rather than a vendor's standard multi-tenant product terms applied uniformly across thousands of customers. For a firm conducting case search across a sensitive litigation file, that difference determines whether the underlying client documents ever leave the firm's environment at all, versus only a narrow, purpose-limited excerpt.

What Compliant Deployment Looks Like Before January 2027

Firms have roughly fifteen months to move from policy-based to architecture-based compliance. Based on how the statute is written, three deployment characteristics will matter most to regulators and to plaintiffs' counsel looking for a sanctions angle:

• Matter-level access control — the system must be able to demonstrate that only attorneys and authorized individuals on a specific matter could access the confidential information entered, not a firm-wide or vendor-wide pool
• Provenance and audit logging — firms need to produce records showing what data went where, which is difficult if logs live on vendor infrastructure the firm doesn't fully control
• Verification workflows built into the tool — since §6068.1 also requires citation verification and output correction, tools that surface source documents alongside generated text (rather than opaque, unsourced answers) make the attorney's verification duty operationally feasible rather than theoretical

Firms evaluating their current stack against this checklist should expect uneven results. A tool procured in 2023 under a general enterprise software RFP, without specific attention to data residency and access granularity, is unlikely to pass a rigorous reading of the new statute without renegotiation or replacement. Our AI for law firms guide walks through the procurement questions this raises in more detail, including how to audit existing vendor contracts for exactly these gaps.

Beyond California: Why This Won't Stay a California Problem

California's bar has historically functioned as a bellwether for professional-responsibility rules that spread nationally — its approach to conflicts of interest and billing disclosure rules were both widely copied by other state bars within a few years of adoption. SB 574's confidentiality provision is a strong candidate for the same trajectory, for a simple reason: it doesn't require a new ethical theory, it just operationalizes existing confidentiality duties (already present in every state's version of Model Rule 1.6) against a new technology.

State bar ethics opinions in New York, Florida, and Texas have already issued guidance treating generative AI inputs as subject to existing confidentiality duties — SB 574 is novel mainly in converting that guidance into a statute with sanctions and disciplinary teeth attached, rather than in the underlying principle. Firms operating across multiple states should assume that whatever architecture they build to satisfy California's attorneys by January 2027 will become their de facto national standard within two to three years, simply because maintaining two parallel AI environments — one access-controlled, one not — is operationally harder than building to the stricter standard everywhere.

The firms that will be caught flat-footed in 2027 aren't the ones that banned AI outright — they're the ones that approved shared-cloud tools under policy memos and assumed training sessions would substitute for access controls. SB 574 doesn't ask firms to stop using generative AI. It asks them to be able to show, concretely, who could access a client's confidential information once it entered the system. Before the next AI procurement cycle, it's worth asking vendors a direct question: if a regulator or opposing counsel demanded proof of who had access to a specific client input, could you produce it in an afternoon — or would you need to call the vendor and wait?