By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: ActiveFencePublished April 25, 2026

TL;DR: California’s SB 243 and AB 489 shift AI safety from voluntary guidance into enforceable product obligations for companion and health-adjacent systems, with disclosure, harm-prevention, and anti-misrepresentation requirements now tied to real liability, according to ActiveFence. The broader signal is that AI governance is becoming operational, not aspirational, and product teams must treat user-facing behaviour as a control surface, not just a design choice.


At a glance

What this is: California’s SB 243 and AB 489 turn AI safety and product transparency into enforceable obligations for companion and health-adjacent systems.

Why it matters: For IAM, NHI, and broader identity programmes, the article matters because it shows how behavioural disclosure, trust boundaries, and accountability are becoming regulated control points across human and machine-facing systems.

👉 Read ActiveFence's analysis of California's AI safety laws and 2026 compliance impact


Context

California’s new AI laws address a familiar governance gap: AI systems can present themselves as supportive, authoritative, or harmless while still making unsafe or misleading outputs. That gap matters to identity and access practitioners because the same trust assumptions that govern who or what can act in a system now extend to how a system represents itself to users and how it responds under risk.

The article is really about compliance moving closer to production controls. For teams working across IAM, NHI, and AI governance, the important shift is that user-facing behaviour is no longer only a product issue. It becomes part of the control environment, especially where AI systems interact with minors, patients, or other vulnerable users.


Key questions

Q: How should teams govern AI systems that can take actions as well as generate outputs?

A: Treat the agent as a governed actor, not just a model output stream. Require action-level logging, tool-call traceability, authorization boundaries, and approval gates before the system can write to records or invoke downstream tools. If an AI system can change state, its authority must be scoped, monitored, and revocable like any other privileged non-human identity.

Q: Why do AI companion and health-adjacent tools create higher governance risk?

A: These tools shape user trust through empathy, reassurance, and apparent expertise, which makes users more likely to rely on them during vulnerable moments. That elevates risk because the harm comes from influence as much as from factual error. When the product can change user behaviour, safety controls must cover the full interaction, not just the model output.

Q: What breaks when AI disclosure is inconsistent across sessions?

A: Inconsistent disclosure weakens the user’s ability to understand what the system is and what it is not, which undermines informed reliance. It also creates compliance gaps because the organisation cannot prove that the system met its obligations every time. For regulated or vulnerable-user contexts, consistency is part of the control, not an optional UX choice.

Q: Who is accountable when an AI system makes a harmful decision?

A: Accountability should follow the identity chain that authorized, configured, or triggered the action, including the human owner, the platform team, and any delegated agent or tool account. If the organisation cannot name that chain, the governance model is too weak for regulated AI use.


Technical breakdown

AI disclosure as a control surface

SB 243 treats disclosure as more than a policy statement. If a system is designed to feel human, the law requires it to state that it is not human, and to repeat that disclosure for known minors at defined intervals. That is a behavioural control, not a branding choice. From a governance perspective, the system’s presentation becomes part of its risk envelope because users may rely on it as if it were a person, counsellor, or authority figure. In identity terms, this is about trust signalling and expectation management at runtime, especially where the system can influence user decisions.

Practical implication: teams should inventory every user-facing AI system that creates human-like trust and map disclosure requirements to product telemetry and policy enforcement.

Harm prevention and escalation workflows

The law also requires safeguards that detect and interrupt harmful conversations, including routing users to crisis services when needed. That means the control is not limited to content moderation after the fact. It is about operational escalation paths, intervention thresholds, and auditable response handling. For AI governance teams, this is similar to any safety-critical control loop: the system must recognise a dangerous state, decide when to intervene, and then route to a safe outcome. The compliance burden increases because failures are visible in individual interactions, not just aggregate product behaviour.

Practical implication: define escalation thresholds, test intervention paths, and retain evidence that the system can route harmful interactions to appropriate human or crisis support.

Why interface cues now matter under compliance review

AB 489 targets a subtle but important problem: users infer authority from language, titles, and interface design even when disclaimers say otherwise. That means compliance is not just a matter of what the model outputs, but also how the product frames those outputs. The law effectively converts tone, terminology, and UI hierarchy into regulated risk factors. This is especially relevant to AI systems operating near identity, health, or support functions, where users may assume expertise from the product experience itself. Governance has to evaluate persuasion risk, not only factual accuracy.

Practical implication: review prompts, labels, and interface language as part of risk controls, not just UX, and remove any design cues that imply unsupported authority.


Threat narrative

Attacker objective: The objective is to exploit user trust in AI presentation so misleading or unsafe guidance is treated as credible and acted on.

  1. Entry occurs when an AI system presents itself as a companion or health-adjacent advisor and gains user trust through human-like cues or authoritative framing.
  2. Escalation follows when the user accepts the system’s guidance as legitimate, allowing unsafe advice, emotional dependence, or clinically implied direction to shape decisions.
  3. Impact is realised when the system contributes to harm, misinformation, or crisis mismanagement, creating legal exposure and user injury.

NHI Mgmt Group analysis

AI safety regulation is becoming a runtime governance problem, not a policy document. California’s laws matter because they move the control objective from written principles to observable product behaviour. That changes how teams test, evidence, and monitor AI systems, especially where the system interacts directly with users. For practitioners, the lesson is that governance now has to be measurable in production, not just approved in review.

Human-like presentation is now a regulated trust boundary. The article shows that disclosure, tone, and interface cues can no longer be treated as cosmetic. When an AI system is perceived as human or authoritative, users are more likely to over-trust it, which creates a governance failure even if the underlying model is technically safe. For identity teams, this is a reminder that trust signalling is itself a control surface.

Named concept: compliance-by-interaction. These laws illustrate a shift where each user interaction can create a separate compliance event, particularly in health-adjacent or vulnerable-user contexts. That raises the value of logging, escalation evidence, and product-level auditability. Practitioners should assume that safety controls will be assessed at the interaction layer, not only at the model layer.

AI governance and identity governance are converging around accountability for delegated judgement. The more a system is allowed to speak, advise, or influence, the more it resembles a governed actor rather than a passive tool. That has implications for IAM, NHI, and AI governance programmes because delegated authority without clear boundaries becomes a compliance liability. Practitioners should treat AI behaviour as part of access governance, especially where systems shape user decisions.

What this signals

AI regulation is starting to influence how product teams prove control effectiveness, not just how they describe policy intent. For identity and governance programmes, that means auditability, disclosure, and escalation evidence will matter more in user-facing AI than abstract claims of safety. The control conversation is moving toward interaction logs, approval boundaries, and response traceability.

Compliance-by-interaction: as more AI systems influence vulnerable users, each output can become a governance event that needs traceability. That is a useful lens for teams aligning AI risk management with NIST AI Risk Management Framework expectations and with broader identity governance where delegated behaviour must be bounded.

The practical next step is to connect AI safety reviews with access governance and incident response. If a system can shape decisions, route distress, or imply expertise, then the organisation needs a way to prove who owns the control, who reviews failures, and what happens when the system crosses its intended boundary.


For practitioners

  • Map user-facing AI systems to legal exposure points Identify every companion, wellness, and support-oriented AI system that serves California users, then map disclosure, escalation, and safety obligations to each product flow. Prioritise systems that create human-like trust or claim advisory authority.
  • Build interaction-level audit evidence Log disclosure events, harmful-content detections, escalation decisions, and user-visible responses so legal and security teams can reconstruct each interaction. Treat each decision path as evidence, not just telemetry.
  • Review prompts and interface language for implied authority Remove titles, phrasing, and visual cues that imply medical or human expertise unless that expertise is actually present and approved. Test product language with the same scrutiny used for regulated communications.
  • Align safety controls with escalation ownership Define who receives alerts when a system detects self-harm, dependency, or clinically risky language, and verify the handoff works before release. Ownership should be explicit across product, legal, and incident response functions.

Key takeaways

  • California’s new AI laws turn disclosure, harm prevention, and misleading presentation into enforceable product controls.
  • The governance burden shifts from policy intent to interaction-level evidence, especially for systems that influence vulnerable users.
  • Practitioners should align product, legal, and security ownership now, because compliance failures will be judged at the point of user impact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF and NIST CSF 2.0 set the technical controls, while EU AI Act and GDPR define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST AI RMFGOVERNThe article is about AI governance obligations and accountability controls.
EU AI ActThe article addresses enforceable AI safety expectations and user-facing risk controls.
NIST CSF 2.0GV.OC-02The article focuses on governance, outcomes, and organisational accountability for AI risk.
GDPRArt.5User-facing AI interacting with minors or health contexts can implicate data handling and transparency duties.

Check whether AI interaction logging, disclosures, and user-facing notices align with data minimisation and transparency requirements.


Key terms

  • AI Companion: An AI companion is a conversational system designed to interact in a socially present, character-driven way rather than as a purely functional assistant. In gaming and entertainment, it must balance immersion, user trust, and behavioural safety because the system is expected to stay in role while remaining bounded.
  • Interaction-Level Audit Evidence: Records that show what an AI system said, when it disclosed its nature, how it handled risky content, and whether it escalated appropriately. This evidence is essential when compliance, safety, or legal teams need to prove the system behaved within its intended boundaries.
  • Implied authority: Implied authority is the sense that an AI system knows or is licensed to act as an expert, even when it has not said so explicitly. It can come from tone, wording, interface design, or persistence, and it creates governance risk because users may trust the output more than they should.

What's in the full article

ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:

  • Step-by-step breakdown of SB 243 and AB 489 obligations for AI product teams
  • Practical examples of disclosure, escalation, and anti-misrepresentation controls in regulated AI products
  • How the laws interact with federal AI policy tension and state-level enforcement expectations
  • The article's own view on implementation timing, product design implications, and legal risk management

👉 ActiveFence's full post covers the legal requirements, product design implications, and enforcement considerations in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security and identity practitioners build the control thinking needed for delegated systems, access boundaries, and runtime accountability.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org