Reasonable Care Under State AI Laws: What It Requires and How to Evidence It

How state AI laws frame reasonable care

The Colorado AI Act is the clearest example. Its bill summary says a developer of a high-risk AI system must use reasonable care to protect consumers from any known or reasonably foreseeable risks of algorithmic discrimination in that system. The text frames a duty. It does not prescribe a fixed set of controls.

The following reading is interpretation, not statutory text. A policy brief from the Future of Privacy Forum, hosted on the Colorado legislature's site, says both developers and deployers are subject to a duty of care. It describes this as a duty rather than an outright prohibition on algorithmic discrimination, which differs from California AB 2930 (2024) and the District of Columbia's Stop Discrimination by Algorithm Act (2021). The brief expects enforcers to assess actions with a proportionality test that can consider factors, circumstances and industry standards.

Two consequences follow. Reasonableness is judged in context, so a record that shows what you did and why carries more weight than a generic policy statement. And the standard remains unsettled. Enforcement guidance on how reasonable care is assessed is limited, and Colorado has continued to legislate and make rules on automated decision-making technology in 2026. As of October 2026, HB26-1263 (conversational AI service operators) and HB26-1139 (AI in health care utilization review) are both effective January 1, 2027. Obligations and expected evidence may keep shifting, so treat any interpretation as provisional.

What the rebuttable presumption is built on

The Colorado summary ties a rebuttable presumption that a developer used reasonable care to compliance with specified provisions. These include making a statement available to deployers that discloses specified information about the high-risk system, and making a public statement summarizing the types of high-risk systems the developer has built or intentionally and substantially modified and how it manages known or reasonably foreseeable algorithmic discrimination risks. They also include disclosing known or reasonably foreseeable discrimination risks to the attorney general and to known deployers or other developers within 90 days after discovery or after receipt of a credible report from the deployer.

A presumption is not a safe harbor. Documented adherence helps, but it can be rebutted, and its exact legal effect is a question for counsel. It is also worth noticing what these elements are: statements, summaries and disclosures. They are mostly pre-deployment or periodic documents. They show what an organization said about its systems. They do not by themselves show what a system did on a given day.

That gap matters under a proportionality reading. If an enforcer weighs actions against circumstances, evidence that controls operated as described is a natural complement to the documents.

Which parts need documentation and which can be supported at runtime

Runtime enforcement supports some elements of a reasonable care showing and cannot substitute for others. The split below is an editorial mapping, not statutory language.

• Developer statements and public summary: Pre-deployment documentation. Runtime records do not replace them, but should reference the same policies.
• Discrimination risk assessment and outcome testing: Pre-deployment and periodic assessment. Duties that depend on model design, training data or statistical testing are outside what runtime policy can observe.
• 90-day risk disclosure: A documented process with named owners. Durable decision records help reconstruct events once a risk is discovered or a credible report arrives.
• Limits on what a system may do: Defined as policy before deployment, then enforced at runtime on inputs, outputs and tool calls.
• Human review: Periodic outcome review is a documented process. Escalation for approval can record the approver, time and outcome per interaction.
• Ongoing control verification: Repeated verification, with runtime decision records as one input.

Mapping expectations to NIST AI RMF practices

State laws and their commentators commonly point to recognized frameworks, and NIST AI RMF is the most frequent reference. Use it as the structure that links policy to evidence rather than as a certification target.

Much of the framework's measurement guidance is assessment-stage work. NIST's AI Resource Center, built to support operationalizing the AI RMF, offers documents, tools and guidance for testing, evaluation, verification and validation, and measurement practices such as checking that AI metrics and system effectiveness are appropriate. These activities belong before deployment and on a recurring schedule.

The NIST Generative AI Profile adds actions that read differently. One aligns generative AI development and use with applicable laws and regulations. Another calls for regularly assessing and verifying that security measures remain effective and have not been compromised. The second implies repeated verification, which is better served by continuous operational records than by a one-time document.

The practical mapping is a traceable chain. A stated policy maps to a framework function, the framework function maps to an owner and a control, and the control produces records a regulator can follow from stated policy to observed behavior.

Runtime policy enforcement as an evidence source

A runtime enforcement layer sits in the execution path and applies a policy decision to each AI interaction or tool call: allow, redact, block or escalate for human approval. Each decision can be recorded with the policy version that applied and, for escalations, the approver, time and outcome. For a specific interaction, that lets a compliance team answer three questions: what the policy was, what was decided, and who approved any exception.

The limits are real. Runtime controls enforce only what can be expressed as policy on observable inputs, outputs and actions. They do not replace impact assessments, developer disclosures or algorithmic discrimination testing. Evidence should also be retained durably and be exportable, because reconstructing events for a 90-day disclosure window requires records that outlast the incident.

Trussed is one such layer. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to NIST, NAIC and NYDFS expectations, among others. It deploys self-managed in the customer cloud with configurable retention and data residency, and it has run continuously in production at a regulated enterprise for more than 18 months. It is a component of a broader compliance program, alongside assessments, disclosures and legal review.