Clinical AI Oversight in California: What SB 503 Asks of Physicians and Developers

Pouyan Golshani, MD · Interventional Radiologist; Founder, GigHz · October 2026

Written in a personal capacity. Disclosure: the author is a partner in a California medical group and the founder of Pogosh CDS and GigHz Precision AI. Both are clinical decision-support products that fall within the law's definitions, so the author has a financial interest in how the law is implemented. This brief takes no position on the law itself.

Summary

SB 503 (Weber Pierson; Chapter 857, Statutes of 2026) adds Section 22758 to the Business and Professions Code. It requires the developers and the users of AI clinical decision-support systems to identify, document, and monitor risks of biased impacts on patients. The author both builds these tools and uses them in practice. This brief sets out what the text requires, where practical questions arise, and options for making the requirements workable. The Governor signed the bill on September 30, 2026. It takes effect January 1, 2027.

1. What the law requires

• Developers and deployers must make reasonable efforts to identify systems that have a known or reasonably foreseeable risk of biased impacts.
• Developers must make reasonable efforts to mitigate that risk, and must give deployers a statement of intended uses and risks plus supporting documentation.
• The documentation covers the types of data used to train the system, including its demographic representativeness when that data is available; how the system was evaluated; data governance measures; intended benefits; known risks; and recommendations for use and monitoring.
• Deployers must regularly monitor these systems and take reasonable and proportionate steps to mitigate the risk.
• Complying with the section is not a defense to a claim of unlawful discrimination.

2. Who is covered

A deployer is a health facility, clinic, solo physician's office, or group practice office that uses such a system. A developer is anyone who designs, codes, substantially modifies, or otherwise produces one for commercial or public use, and the definition expressly includes deployers that do so. One organization can be both.

A clinical decision support system is an AI system that produces a prediction, classification, recommendation, evaluation, or analysis that aids clinical decisionmaking related to timing of care, diagnosis, or treatment. Scheduling, reminders, patient education materials, and payment processing are excluded.

3. How this sits beside federal oversight

The FDA's public record shows where federal review of medical AI has been concentrated. In a peer-reviewed analysis of all 1,430 AI/ML-enabled device authorizations from 1995 through 2025, devices reviewed by the Radiology panel made up 76.5%. Radiology, Cardiovascular, and Neurology together made up 90.6%. No authorizations were recorded under a psychiatry or behavioral health panel.

Federal law also exempts certain clinical decision-support software from device regulation. The text of SB 503 draws no distinction between FDA-authorized devices and other tools, so it reaches both. For specialties with few authorized devices, a state documentation requirement may be the main formal oversight these tools receive. That makes the content of the documentation important.

4. Practical questions

• Monitoring takes volume. Detecting a difference in performance across patient groups requires enough cases in each group and reliable demographic data. A solo office is a deployer under the law, but will rarely have either.
• Key terms are undefined. The section does not define "regularly," "reasonable," or "proportionate," and it names no enforcing agency or penalty.
• Training data may not be visible to the developer. Many tools are built on general-purpose models licensed from another company. The developer of the clinical tool may not be able to describe how the underlying model was trained.
• "Substantially modifies" is unclear at the margin. A practice that adapts a purchased tool with its own templates or instructions may not know whether it has become a developer.
• Overlap with existing disclosures. FDA labeling and federal health IT certification rules already require some transparency information for certain tools. A separate state format would mean producing similar content twice.

5. Options for implementation

• Name the standards that satisfy the documentation duty. The law allows developers to rely on nationally recognized standards. Identifying which ones qualify would give developers and purchasers a clear target.
• Allow pooled monitoring. Let small practices meet the monitoring duty through monitoring performed by the developer, a medical group, or a network across many sites, where numbers are large enough to be meaningful.
• Use one documentation template. Align it with information already produced for FDA labeling and federal health IT certification, so that one document serves several purposes.
• Clarify "substantially modifies." Examples of what does and does not make a practice a developer would reduce uncertainty for clinicians who customize tools.

These are implementation options for the period before the law takes effect on January 1, 2027, and after. They could be addressed through guidance or later legislation. They are offered from operating experience; they are not findings from a study.