Applying State-Specific AI Rules at Runtime in a Single LLM Application

Why this is a runtime problem, not a deployment problem

In the absence of federal AI regulation, states have been enacting their own laws. The subject matter varies: disclosure of AI-generated content, limits on AI in mental health contexts, limits on AI in coverage determinations, and protocols that companion chatbot operators must maintain for suicidal ideation or self-harm expression. Some state privacy laws may also apply to AI-enabled applications, depending on the application's features or functions. Critics argue that this patchwork raises compliance burden across states.

Three common responses all have weaknesses. Separate deployments per state multiply operational work and invite drift. Rules written into prompts are hard to update, behave differently across models, and are hard to show to an auditor. Rules hard-coded in application logic need a release for every change and do not cover tools the model calls.

The more durable approach is to keep three concerns apart: jurisdiction resolution (which rules apply to this interaction), policy definition (what those rules require, expressed as versioned policy-as-code), and enforcement (the point in the execution path where policy is applied). Each can then change without touching the others. This guide does not give legal advice, and no single state's rules are treated here as definitive.

Resolving jurisdiction: inputs and failure modes

The signals below are design choices, not requirements drawn from any statute. Reasonable inputs include the user's declared or verified state of residence, tenant or account metadata such as the contracting entity or service location, request context such as the channel or the form being completed, and the data residency of the underlying records. Each has weaknesses. Declared residence can be stale, account addresses may differ from where a person is when they use the application, and data residency describes where data sits, not whose rules govern the person.

Resolve by explicit precedence among signals, and record which signal won. Decide in advance what happens when signals disagree and when they are missing. A defined fallback policy is essential: for example, apply the most restrictive policy in the organization's footprint, or route to human review for higher-risk use cases. Without a fallback, unresolved interactions silently receive no state policy, which is the failure an auditor will look for first.

Bind the jurisdiction context to the request so downstream tool calls inherit it rather than re-deriving it. NIST describes signed mandate statements that define intended outcomes and constraints for agentic actions. That could inform how context is attached to a request, though it is a design option rather than an established method for jurisdiction.

Structuring policies, actions and conflicts

Organize policies by state and use case, because the state requirements described above are use-case specific. A disclosure rule for general consumer chat differs from a limit on AI in coverage determinations or a self-harm protocol for a companion-style experience. A practical layout is a shared baseline policy, then a state layer, then a use-case layer, each versioned. Versioning matters because state laws are being revised and federal positions are shifting. Every interaction should record the exact version applied.

Map each requirement to one of a small set of enforcement actions. Allow when the interaction conforms. Redact when specific content, such as protected data, must not reach a model or a user. Block when an action is not permitted for that jurisdiction and use case. Rate limit where volume or repetition is the concern. Escalate for human approval where a person must decide, such as before a tool call that affects a consumer outcome. Disclosure and notice requirements can often be met by inserting required notices, which is distinct from changing substantive answers.

Plan for conflict and overlap. State rules may differ from each other, and from federal, sector or international requirements. Pick a documented precedence method, for example the stricter control wins unless counsel approves an exception, and keep it in policy rather than in code paths.

Add a federal-conflict review step. As of October 2026, a federal Executive Order states an intent to act with Congress on a national standard that forbids conflicting state laws, and the FTC states that altering AI outputs contrary to consumers' reasonable expectations may deceive consumers under Section 5, even when done to comply with state law. The FTC also states that Congress provided no state-law safe harbors under Section 5. The practical consequence is that policies which modify model outputs should require legal approval before release. Whether redaction or blocking carries different risk than altering substantive answers is a question for counsel.

Evidence a regulator or auditor can use

The question an auditor asks is which rule applied to a specific interaction and what the system did about it. Answering requires records created at the moment of enforcement, not reconstructed from application logs later.

For each model call and tool call, record a unique interaction identifier and timestamp, the resolved jurisdiction with the signals and method used, whether a fallback was applied, the policy set and version, the rule that matched, the action taken (allow, redact, block, rate limit or escalate), the tool or model invoked, and for escalations the approver and outcome. Store a description of what was redacted rather than the redacted content itself unless your retention rules require otherwise.

No standard audit schema is mandated by the guidance reviewed here, so treat this field list as a starting design and confirm it with your compliance team. Evidence should also be exportable and organized by framework. NIST's GenAI Profile suggests comparing outputs against predefined risk tolerances and guidelines and maintaining awareness of AI regulations in relevant jurisdictions. A recurring regulatory-watch process that feeds policy updates, with legal review as a gate, closes the loop between changing law and the policies being enforced.