California’s New Clinical AI Laws Start January 1. A Solo Physician’s Office Is Covered. Here Is What Your Practice Must Change.

1. What California’s two new clinical AI laws require, and who they reach

California’s two new clinical AI laws require every health facility, clinic, solo physician’s office and physician group practice that uses AI clinical decision support to keep licensed clinicians in real control of care decisions and to monitor those tools for biased impacts, starting January 1, 2027. Governor Newsom signed both bills on September 30, 2026, as part of a package his office described as empowering doctors to make the final call. Neither bill contains an urgency clause or a delayed operative date, so each takes effect on the first day of 2027 under California’s default rule.

California AB 1979 and SB 503 are 2026 state laws that regulate how health facilities, clinics and physician practices use artificial intelligence clinical decision support. Starting January 1, 2027, practices must take reasonable steps to preserve clinicians’ independent judgment, may not let AI independently perform licensed clinical functions, and must monitor decision support tools for biased impacts.

The two laws were written to fit together. AB 1979 (Bonta, Chapter 854) adds Business and Professions Code Section 22758.5, which governs how a practice uses decision support. SB 503 (Weber Pierson, Chapter 857) adds Section 22758, which governs bias risk across the whole supply chain, from the company that builds the tool to the office that uses it. Both use substantially the same definition of “clinical decision support system,” so a tool that triggers one almost always triggers the other.

The coverage is the part small practices should read twice. Both statutes reach a “physician’s office,” defined as “an office of a physician in solo practice,” and an “office of a group practice,” defined as two or more physicians legally organized as a partnership, professional corporation or nonprofit corporation. They also reach licensed health facilities and clinics. There is no employee count, revenue floor or patient volume test. A single physician in a rented suite in Fresno who turns on the diagnostic suggestion feature in an EHR is as covered as a 400 bed hospital.

That is a different design from most of California’s 2026 AI package. As we explained in our guide to which of California’s 2026 AI laws reach a small business, several of the new statutes switch on only above a revenue or user threshold. The clinical laws do not. The adoption numbers explain why the Legislature did not bother with one. The American Medical Association’s 2026 Physician Survey on Augmented Intelligence found that 81 percent of the 1,692 physicians surveyed reported awareness or use of AI in their practice, more than double the 38 percent recorded in 2023, with an average of 2.3 use cases per physician. The figures are self reported, and the AMA notes they do not independently verify what practices have actually deployed.

2. Which tools count as a clinical decision support system

A clinical decision support system under both laws is any artificial intelligence system that “produces a prediction, classification, recommendation, evaluation, or analysis that aids clinical decisionmaking related to timing of care, diagnosis, or treatment.” That is a wide net. It catches a sepsis or deterioration alert, an imaging triage flag, a risk score that ranks which diabetic patients get outreach first, a symptom checker that sorts patients by urgency, and a generative assistant that suggests a differential diagnosis or a medication change.

The definition then carves out a specific list. A system is not clinical decision support when it handles appointment management, which the statute describes as booking, canceling and rescheduling, appointment reminders, patient education and previsit materials and preparation, and payment processing. The carve out applies only “to the extent the independent performance of these activities by the system does not require a professional license.” A reminder bot is out. A reminder bot that also decides which patients need to be seen sooner based on their lab values is doing something else.

AB 1979 adds a second exclusion that matters for documentation tools. Section 22758.5(d) says the section does not apply to “automated decision systems for documentation and communication that does not involve the application of professional judgment,” and gives three examples: automated messages telling patients their records were updated, generating reminders, and helping patients find information at their request. The phrase that will do the work is “does not involve the application of professional judgment.” An ambient scribe that transcribes and structures what the physician said is a strong candidate for this exclusion. A scribe that drafts the assessment and plan, proposes diagnoses or suggests orders is applying something that looks a great deal like clinical judgment.

The AMA survey shows how much of current practice sits on that line. Among the physicians surveyed, 30 percent reported using AI to create discharge instructions, care plans or progress notes, 28 percent for documentation of billing codes, charts or visit notes, 19 percent to draft responses to patient portal messages, and 17 percent for assistive diagnosis, according to the AMA’s summary of the nearly 1,700 responses. Assistive diagnosis is plainly in scope. The documentation categories depend on what the tool actually does.

Treat the middle column as a working classification, not a legal conclusion. As of the date of this article, we are not aware of final regulations, licensing board guidance or judicial construction applying the definition. The safer course for any borderline tool is to inventory it as clinical decision support and apply the controls in section 10, because the cost of over including a tool is a few hours of documentation and the cost of under including one is an unmonitored system the statute was written to reach.

3. AB 1979: keeping the clinician’s judgment real, not ceremonial

AB 1979’s core duty is that a covered practice “shall take reasonable steps to ensure that a licensed health care provider, acting within their scope of practice, retains the ability to exercise independent professional judgment in their care of a patient whenever that care is informed by the output of a clinical decision support system.” The duty sits on the organization, not only on the individual clinician. It applies whenever care is “informed by” the output, which is a lower bar than care that is decided by the output.

The drafting history shows what the Legislature deliberately chose not to require. The spring Assembly version would have required practices to ensure that no clinical decision is based solely on decision support output. A Board of Behavioral Sciences legislative analysis of the July 2, 2026 version records that Senate amendments made after the Board’s May 8 support vote deleted that requirement and replaced it with the current “reasonable steps” and “retains the ability” formula. The enacted law does not ban reliance on AI output. It bans structuring the practice so that the clinician cannot meaningfully disagree with it.

“Retains the ability” is a practical test, and most of the failure modes are operational rather than technical. A clinician does not retain the ability to exercise independent judgment if the tool’s recommendation auto populates the order and overriding it takes six clicks and a free text justification. The same is true if productivity targets assume every AI suggestion is accepted, if the clinician cannot see the inputs or rationale behind a score, or if staff are told the vendor’s output is the standard of care. Fox Rothschild’s analysis of the law frames the test as whether the clinician has both the theoretical and practical ability to override the output.

“Reasonable steps” is not defined, and neither statute authorizes regulations to define it. In practice a licensing board or a plaintiff’s expert will ask what the practice did and whether it wrote it down. A one page decision support policy, a list of tools with a named clinical owner for each, an override workflow that takes no more effort than acceptance, short training on each tool’s known limitations, and a quarterly review of override rates would be a defensible set of reasonable steps for a five physician group. None of those items is named in the statute, and none is a safe harbor, but each one produces evidence.

4. The two things AI may not do in a California practice

AB 1979 flatly prohibits a covered practice from using or deploying a tool, system or device that includes AI to do either of two things. Under Section 22758.5(b)(1)(A), AI may not “direct, guide, supervise, or instruct unlicensed personnel in their performance of any clinical function that is required by law to be performed by a person with a professional license.” Under (b)(1)(B), AI may not “independently perform any clinical function that is required by law to be performed by a person with a professional license.”

The first prohibition is the one most likely to catch a small practice by surprise, because it targets a staffing model rather than a technology. A medical assistant following an AI generated triage script to tell a caller whether to come in today, go to urgent care or wait, is performing a function that in most cases requires a licensed nurse or physician. The AI is not acting alone, and the assistant is not acting alone, but the combination substitutes the tool for the licensee. That is the arrangement (b)(1)(A) prohibits.

The second prohibition reaches patient facing tools that act without a licensee in the loop. A website chatbot that reviews a patient’s symptoms and tells them a specific medication change is appropriate, or a refill workflow that approves prescriptions without a prescriber’s review, would be independently performing a licensed function. The same “required by law” qualifier limits both prohibitions, so they bite only on functions that California licensing law actually reserves for licensees. General health information, navigation help and answering questions at the patient’s request fall within the 22758.5(d) exclusion.

There is one express exception. Section 22758.5(b)(2) says the prohibitions do not stop “a trainee as part of a supervised course of study or training program while working toward licensure” from using a tool. Residency programs, clinical rotations and supervised associates working toward a license keep their access. The exception covers the trainee’s use within a supervised program, not a practice that uses trainees to stand between AI output and patients outside that structure.

This licensure line resembles the one several other states drew for psychotherapy in 2025 and 2026, but California did not adopt a therapy specific version. Governor Newsom vetoed SB 903, the therapy specific bill, on September 30, so California has no statute equivalent to the seven state AI therapy laws we covered in our analysis of state AI therapy restrictions. AB 1979 applies to behavioral health clinics and physician practices like any other covered setting, but a solo therapist’s office that is neither a physician’s office nor a licensed clinic is not obviously within its definitions.

5. SB 503: the bias duties, and when a practice becomes a developer

SB 503 requires both developers and deployers of clinical decision support to “make reasonable efforts to identify” systems that “are known or have a reasonably foreseeable risk of biased impacts resulting from deployment of the system in health programs or activities.” A deployer is defined as “a health facility, clinic, physician’s office, or office of a group practice that uses a clinical decision support system.” Every covered practice that uses an in scope tool is therefore a deployer from January 1, 2027. The identification duty reaches all of its decision support tools, while the monitoring and mitigation duty attaches to the systems it identifies as carrying a known or reasonably foreseeable risk.

The deployer’s ongoing duty is in Section 22758(a)(8). Deployers “shall regularly monitor” identified systems “and take reasonable and proportionate steps to mitigate the known or reasonably foreseeable risk of biased impacts.” The word “proportionate” is the most useful word in the statute for a small practice. A two physician family medicine office is not expected to run the statistical monitoring program of an academic medical center. It is expected to do something regular, sized to its risk and resources, and to be able to show what it did.

“Biased impact” means “an adverse impact, including diminished access to health care, quality of care, or outcomes, on an individual based on their protected characteristics.” Protected characteristics are borrowed from Civil Code Section 51(b), the Unruh Civil Rights Act, which lists sex, race, color, religion, ancestry, national origin, disability, medical condition, genetic information, marital status, sexual orientation, citizenship, primary language and immigration status. Some secondary summaries list age. Section 51(b) does not include age, so SB 503 does not reach age based impacts on its own terms, although federal law does, as section 7 explains.

Primary language is the characteristic small practices tend to overlook. A triage model that performs worse on portal messages written in Spanish or Vietnamese, or a scribe whose transcription quality drops for patients who speak through an interpreter, can produce diminished quality of care based on a listed characteristic. California’s patient population makes this a real exposure rather than a theoretical one, and it is a test a practice can run itself by sampling outputs across its own patient mix.

The developer definition is the trap. A “developer” is anyone, explicitly including a deployer, that “designs, codes, substantially modifies, or otherwise produces a clinical decision support system for commercial or public use.” Section 22758(b) confirms that one organization “may be both a developer and a deployer.” A practice that builds its own risk model in a spreadsheet tool with machine learning, fine tunes a model on its own records, or significantly reconfigures a vendor’s model may have crossed into developer territory and picked up the developer’s mitigation and documentation duties. The statute does not define “substantially modifies.” Our interpretation, which is not a statutory or regulatory determination, is that changing alert thresholds is probably not enough and retraining is probably more than enough.

There is a relief valve for homegrown tools. Under Section 22758(a)(7), a deployer that also develops a system “for internal use” does not have to generate the separate developer documentation package if information consistent with the developer transparency requirements in (a)(3)(B) “is readily available to the deployer.” The identification, mitigation and monitoring duties still apply. Only the paperwork written for an outside customer is waived.

6. What to demand from your vendor before January 1

SB 503 gives every California practice a statutory right to a defined documentation package from the developer of any clinical decision support system that carries a known or reasonably foreseeable risk of biased impacts. Under Section 22758(a)(5), the documentation must be made available “upon request or at the time of initial sale, whichever is earlier,” and again with material updates. A practice does not need to negotiate for it. It needs to ask in writing and keep what comes back.

The required package has two parts. The first is a statement of the system’s intended uses and known or reasonably foreseeable risks. The second is documentation covering seven items: high level summaries of training data, including demographic representativeness where demographic data is available; how the system was evaluated for performance, limitations and mitigation of biased impacts; high level summaries of data governance measures; intended benefits and expected outputs; known or foreseeable risks of biased impacts and mitigation efforts; recommendations for how the system should be used, monitored and risk mitigated; and any other documentation reasonably necessary to help deployers understand outputs and monitor for biased impacts.

Section 22758(a)(4) lets developers satisfy the requirement by adhering to “nationally recognized or widely adopted industry standards” developed through multistakeholder consensus, or by providing results from regularly conducted algorithmic impact assessments. Expect vendors to answer with a model card, a certification or an assessment report rather than a bespoke document. That is acceptable under the statute if it actually covers the listed items. Check it against the list rather than accepting the format as proof.

Two contract points follow. First, add a clause requiring the vendor to deliver SB 503 documentation for current tools before January 1, 2027, and with every material update afterward. Second, do not treat the vendor’s package as the end of your obligation. Section 22758(d) says compliance with SB 503 “shall not be used as a defense to a claim of unlawful discrimination,” and the deployer’s own monitoring duty is independent of anything the developer says. A vendor document tells you where to look. It does not do the looking.

7. How the new laws stack with AB 3030, Section 1557 and FDA guidance

AB 1979 and SB 503 add to existing obligations rather than replacing them, and a California practice using clinical AI now answers to at least three other regimes. SB 503 says so directly in Section 22758(d): it “is in addition to and does not supplant or replace any other applicable provision of state law regulating the use of artificial intelligence or automated decision systems.”

The first is AB 3030, now Health and Safety Code Section 1339.75, in effect since January 1, 2025. When a covered practice uses generative AI to produce patient communications about clinical information, each communication needs a disclaimer that it was AI generated and instructions for reaching a human. The format rules are specific: at the start of a letter or email, throughout a chat or video interaction, and verbally at both the start and end of an audio interaction. The requirement falls away when a licensed or certified provider reads and reviews the communication. AB 3030 regulates the message. AB 1979 regulates the decision behind it.

The second is federal. Under 45 CFR 92.210, part of the HHS Section 1557 nondiscrimination rule, a “covered entity” (a defined term with its own scope and exceptions, which reaches many providers receiving federal financial assistance from HHS) must make reasonable efforts to identify patient care decision support tools in its health programs or activities that use input variables measuring race, color, national origin, sex, age or disability, and to mitigate the risk of discrimination from those tools. It is not a general duty to audit every AI tool for every form of bias. Those identification and mitigation duties applied 300 days after July 5, 2024, which was May 1, 2025, and the section remains in the eCFR as current as of October 13, 2026. The federal rule includes age. SB 503 does not, but it adds primary language, immigration status and several other characteristics the federal rule does not list.

The third is the FDA. The agency’s Clinical Decision Support Software guidance, issued January 6, 2026 and reissued January 29, 2026, explains which decision support functions fall outside the medical device definition. One of the statutory criteria for that exclusion is that the clinician can independently review the basis for the recommendation, which mirrors AB 1979’s concern. The FDA also reports it has authorized over 1,600 AI enabled medical devices as of September 2026. FDA clearance answers whether a product may be marketed. It does not answer whether your practice used it in a way that preserved clinician judgment or monitored for biased impacts, and neither California law exempts FDA cleared devices.

The overlap is good news for a practice that builds one program instead of four. A single inventory of decision support tools, one bias review that covers the union of the federal and state characteristic lists, and one override and escalation workflow can satisfy the substance of AB 1979, SB 503 and 92.210 at the same time. Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 give that program a recognized structure, although neither is named in either California statute and neither is a safe harbor.

8. Enforcement: who can act and what is at stake

Neither AB 1979 nor SB 503 creates its own fine, and SB 503 does not name any enforcer at all. AB 1979 Section 22758.5(c) makes a physician’s violation “subject to the jurisdiction of the Medical Board of California or the Osteopathic Medical Board of California,” and where a violation amounts to practicing a health care profession without a license, it lets the relevant licensing board seek an injunction or restraining order under Business and Professions Code Section 125.5. It also preserves any other remedy a board or enforcement agency already has.

For a physician, licensing board jurisdiction is not a small thing. A board complaint does not need a fine schedule to cost a practice months of legal fees and a public record. The other route to trouble is indirect. A malpractice plaintiff may seek to use AB 1979 as evidence of the standard of care or of reasonable practice expectations, although the statute does not itself create a private cause of action. SB 503 likewise creates no standalone private action; a discrimination claim under the Unruh Act would still have to establish its own elements, including causation, but SB 503 expressly says compliance with it is no defense to such a claim.

AB 1979 also has a privacy component with real dollar figures attached. It amends the Confidentiality of Medical Information Act so that any business offering a “health care chatbot” to consumers to manage their information or for diagnosis, treatment or management of a medical condition is deemed a provider of health care subject to the CMIA. The definition reaches generative AI systems with a natural language interface that are marketed as supporting health services and use health information a consumer provides or that the chatbot collects, generates or infers. We covered the patient intake side of this in our article on patient intake chatbot compliance.

The CMIA’s penalties are concrete. Under Civil Code Section 56.36, a patient can recover nominal damages of $1,000 for negligent release without proving actual damages, plus actual damages. A negligent disclosure carries an administrative fine or civil penalty of up to $2,500 per violation. Knowing and willful misuse by an entity other than a licensed professional carries up to $25,000 per violation, and misuse for financial gain up to $250,000 per violation plus disgorgement. A licensed practice is already a CMIA provider, so the chatbot amendment matters most for the vendors and direct to consumer apps a practice partners with, which now carry the same confidentiality duties the practice does.

Holland and Knight’s review of the package notes the same signing day also produced SB 947, which requires human review of automated employment decisions. That law reaches the practice as an employer rather than as a provider, and we covered its requirements in our SB 947 analysis. A practice that uses AI to schedule, evaluate or discipline staff has a second January 1 problem.

9. What the text leaves unresolved

Five questions remain open in the enacted text, and a practice should plan around them rather than wait for answers. Neither statute authorizes rulemaking, so clarification will have to come from licensing board guidance, enforcement actions or litigation. As of the date of this article, we are not aware of any of those applying these provisions.

First, the office definitions are written around physicians. A “physician’s office” is a solo physician’s office, and a group practice is two or more physicians. A dental practice, an optometry practice, a chiropractic office or a nurse practitioner owned practice that is not a licensed clinic is not clearly within either statute’s list of covered settings. AB 1979’s prohibition on AI independently performing licensed functions reflects licensing law those practices are already subject to, so the safer assumption is that the principle applies even where the statute does not.

Second, “reasonable steps,” “reasonable efforts,” “regularly monitor” and “reasonable and proportionate” are all undefined. There is no frequency for monitoring and no method for measuring biased impact. Third, “substantially modifies” in the developer definition has no threshold. Fourth, SB 503 names no enforcer, which leaves open whether the Attorney General would proceed under general consumer protection law, whether licensing boards treat noncompliance as unprofessional conduct, or whether the duties surface mainly in private litigation. Fifth, the phrase “health programs or activities” is borrowed from the federal Section 1557 vocabulary but is not defined in SB 503.

None of these gaps reduces the duty. Each one increases the weight a regulator or court will put on what the practice documented, because an undefined standard is judged by the facts of the case.

10. An 11 week plan to be ready by January 1, 2027

A small practice can build a credible initial compliance baseline for AB 1979 and SB 503 in the roughly 11 weeks between mid October and January 1, 2027, without hiring compliance staff. The plan below assumes a practice of one to ten physicians using a commercial EHR and a handful of AI tools. It is a baseline, not a safe harbor.

Weeks 1 and 2: inventory. List every tool that uses AI, including features switched on inside the EHR, the portal, the phone system and any scribe. For each one, record what it does, who uses it and what output it produces, and classify it against the definition in section 2. Assign a named clinical owner for every tool classified as clinical decision support. Most practices find two to three more AI features than they expected.

Weeks 3 and 4: vendor requests. Send each decision support vendor a written request for the SB 503 statement and documentation package under Section 22758(a)(3), and ask whether the vendor considers the tool to carry a known or reasonably foreseeable risk of biased impacts. File the responses. Note any vendor that cannot answer.

Weeks 5 and 6: workflow review. Walk through each tool’s workflow with the clinician owner. Confirm that overriding a recommendation is no harder than accepting it, that the clinician can see the basis for the output, and that no unlicensed staff member acts on AI output in a way that substitutes for a licensed function. Retire or rebuild any workflow that fails.

Weeks 7 and 8: policy and training. Write a short decision support policy covering clinician authority, override expectations, escalation of suspected errors, and the AB 3030 disclaimer rules for generative AI messages. Train every clinician and front desk staff member on it, and keep the attendance record.

Weeks 9 to 11: monitoring. Set a quarterly review that samples outputs across the practice’s own patient mix, with attention to primary language, disability and the other characteristics in Civil Code Section 51(b), plus age for federal purposes. Record override rates per tool. Schedule the first review for the first quarter of 2027, and put the inventory, vendor responses, policy, training record and review schedule in one folder that a board investigator could read in 20 minutes.

That folder is the deliverable. Both statutes ask whether the practice took reasonable steps, and the folder is the answer.

This article is provided for general informational purposes and reflects the state of the law as of October 2026. It is not legal advice. Regulations in this area are changing quickly. Confirm current requirements and consult qualified counsel before making decisions for your organization.