Connecticut LLM Requirements: Scope the Use Before You Build the Control

TL;DR

• Connecticut has no universal set of LLM controls. Obligations follow four facts: provider role, user, data, use case.
• Public Act 26-15 covers AI subscriptions from October 1, 2026 and companion rules from January 1, 2027.
• Employment technology duties focus on covered deployments beginning October 1, 2027.
• CTDPA duties can apply when an LLM processes Connecticut consumer personal data, including profiling and sensitive data.

One model can trigger several rules

The same model can sit behind five products: a paid writing assistant, a recruiting ranker, a customer-support bot, an emotional companion, a state benefits service. Connecticut assigns different duties to each one. The model name barely matters.

The main enacted source is Public Act 26-15, Substitute Senate Bill 5's 2026 online-safety package. On the privacy side, the Connecticut Attorney General's CTDPA page supplies the official consumer-rights and controller-obligation guidance, and the General Assembly's CTDPA chapter provides the underlying definitions and statutory structure.

I want to map the common LLM routes before discussing controls. Connecticut LLM requirements start with the use and the role. Data classification comes next, and a platform team can then attach each route to the right notice and assessment, then to the policy and evidence record.

The SB 2 label points to a bill that stopped in the House

Substitute Senate Bill 2 passed the Connecticut Senate on May 14, 2025. Then it stalled. The official General Assembly history shows House calendar action two days later and no enacted public act, yet its title and summaries still dominate searches for Connecticut AI rules, which is why teams keep asking for "SB 2 LLM requirements."

Point the control register at Public Act 26-15 and the CTDPA instead. That act defines the technology broadly, then creates narrower categories: companions, automated employment decisions, foundation models, frontier developers, generative systems. Each category opens its own set of duties.

A single inventory field called "uses LLM" misses the controlling facts. Add these: user type, product marketing, interaction design, decision role, personal-data categories, state-agency status, subscription terms, output medium, model-development role. Together they let counsel and engineering classify a route without reading source code for every release.

Paid AI subscriptions require terms disclosures

Section 1 of Public Act 26-15 takes effect October 1, 2026, and it applies to a subscription-based provider doing business in Connecticut that offers AI technology to a Connecticut consumer in exchange for compensation.

Two moments carry the duty. Before entering or renewing a subscription, the provider must give written notice of key terms and conditions, and the consumer must provide written acceptance. For an initial subscription, the notice includes quantitative or qualitative limits and the provider's discretion to limit access or reduce functionality. Renewal notice covers new or modified limits and changed discretion.

For an LLM product, the compliance owner needs a versioned link between product configuration and the accepted terms. Configuration moves faster than legal copy. Model quotas, feature availability, context limits, moderation restrictions, and access conditions all change without a single word of the terms changing. Store the terms version, acceptance time, account, plan, disclosed limits, applicable product configuration.

The HTTP model gateway can record route and model use. The subscription notice and acceptance happen at the product layer, so keep those ownership lines clear. A per-request record supports later questions about which feature ran; it cannot create the consumer's written acceptance.

AI companions have behavior and disclosure duties

Sections 4 through 6 take effect January 1, 2027. The act defines an AI companion as AI with a natural-language interface that gives adaptive, human-like responses and can sustain a relationship across multiple interactions. Exclusions exist. They cover business, support, education, health, gaming, assistant, and narrow-task uses when the stated conditions hold.

A covered operator must implement a protocol using evidence-based methods to detect clear expressions of suicide, self-harm or imminent physical violence. The protocol must prevent outputs that encourage those harms, refer users to appropriate resources, and appear in a prominent public location. The operator also needs measures preventing the companion from claiming it is human or contradicting the disclosure that it is artificial.

When a reasonable person could believe the companion is human, the operator provides a clear notice. The act specifies static or periodic disclosure patterns and tighter treatment for users younger than 18. Minor-facing companion rules add restrictions on harmful, sexual, manipulative, dependency-forming interactions, plus screen-time and account tools.

A white chat bubble blinking on a phone at 1:17 a.m. is the real control surface. The disclosure has to stay visible or recur on the statutory pattern while the conversation continues. A policy document in the compliance drive does nothing there.

Employment LLMs require classification and notice

An LLM becomes automated employment-related decision technology when it processes personal data and produces an output that substantially influences a covered employment decision. Public Act 26-15 names six output forms: predictions, recommendations, classifications, rankings, scores, other information. Incidental systems stay outside the definition. So does purely descriptive or diagnostic information that carries no material decision influence.

For covered deployments beginning October 1, 2027, the developer supplies information the deployer needs for its duties, subject to the act's conditions and contracting option. A deployer provides plain-language disclosure when an employee or applicant interacts with the technology, unless the interaction is obvious. Before a covered employment decision, the deployer gives written notice covering the technology, purpose, decision, trade name, personal-data categories, assessment method, sources, contact details.

Tag employment routes at the application layer. Record the applicant or employee reference, decision purpose, model route, data categories, notice version, output role. Keep the person's stable reference separate from the authenticated operator identity, because that one distinction supports rights and case reconstruction without pretending the recruiter and the applicant are the same principal.

The Connecticut AI controls mapping shows how route tags and identity become enforceable request policy.

CTDPA rules follow consumer personal data

The CTDPA protects Connecticut residents acting in an individual or household context. Its consumer definition excludes employment context, so employment LLM analysis belongs in the preceding branch. Controllers handling in-scope information must address notice, purpose, minimization, security safeguards, rights, opt-outs, processor relationships. Sensitive categories require consent, and heightened-risk processing brings assessment duties.

The Attorney General's guidance says consumers can access personal data and derived inferences, learn whether their data is used for profiling, correct inaccuracies, request deletion, obtain portable copies, exercise specified opt-outs. The guidance also identifies data protection assessments and impact assessments for targeted advertising, sale, profiling, sensitive-data processing.

An LLM prompt can contain personal data even when the product team calls it unstructured text. Retrieved account history and health details remain part of the data analysis. So do precise location and model-generated inferences. Classify the assembled request just before transmission, because the template omits what runtime adds: tool output, retrieval, conversation history.

The AI data classification guide covers that request-level mechanism. CTDPA rights still require a data map beyond the gateway, including stores holding conversations, embeddings, account records, downstream decisions.

State-agency LLMs add inventory and public assessment

Sections 37 and 38 of Public Act 26-15 take effect October 1, 2026. The Department of Administrative Services must maintain an annual inventory of state-agency AI systems, and that inventory includes vendor, capabilities, uses, decision role, assessment status and date, access to personally identifiable information, known risks.

A state agency using AI for public-assistance functions or functions materially affecting rights, civil liberties, safety, or welfare must follow standards established by the Office of Policy and Management and Department of Administrative Services. Authorized procurement requires an AI impact assessment. The agency submits and posts it at least 60 days before deployment, with permission to redact personally identifiable information.

For a state LLM route, preserve the inventory identifier in configuration and request records. That single field joins the public system entry to the live endpoint and policy. The Connecticut AI risk-assessment guide explains the design and validation file in detail.

Procurement, public posting, accessibility, records management, and state policy compliance all sit outside an HTTP gateway. Request records support the assessment. They do not replace those functions.

Frontier and provenance rules have narrow scope

Public Act 26-15 defines a frontier developer through model training and a compute threshold. Large frontier developers face a covered-employee internal-reporting process for catastrophic risk by January 1, 2027. An enterprise calling a provider's hosted LLM is usually a deployer or customer rather than a frontier developer. The Connecticut incident-reporting guide separates that process from privacy breach notice.

Section 15 covers certain publicly accessible generative systems with more than the stated monthly-user threshold, but its operative provenance duty focuses on audio, image, video, combined content. It requires provenance data where commercially and technically reasonable and names the Coalition for Content Provenance and Authenticity standard as an example. Pure text output falls outside that specific content-provenance requirement.

That limitation matters for an LLM article. A multimodal provider producing images or audio may enter the section. A text-only enterprise assistant has other Connecticut duties when its role, data, or use triggers them, though Section 15's provenance mechanism should not be stretched into a universal watermark rule for every text response.

A route-level requirement matrix

Turn the legal branches into route metadata rather than one company-wide AI flag:

• Consumer paid assistant: subscription terms version, written acceptance, limits, account, route, model.
• Covered companion: age state, disclosure state, safety-protocol version, escalation event, interaction duration, output policy.
• Employment workflow: decision purpose, substantial-factor classification, notice version, personal-data categories, sources, route, reviewer.
• CTDPA consumer workflow: purpose, consumer reference, data class, consent or opt-out state, processor, assessment, endpoint, retention rule.
• State-agency route: inventory ID, assessment ID, posting date, approved purpose, personally identifiable information flag, policy.
• Frontier development: developer role, covered employee process, model evaluation, catastrophic-risk category, governance routing.

My opinion is that a spreadsheet row labeled "ChatGPT approved" is worse than an empty row, because it creates confidence without identifying a use. Route metadata lets the same model receive different policy according to the function invoking it.

Enforcement at the HTTP request boundary

For traffic between an authenticated user or agent and an LLM endpoint, policy can evaluate identity, role, purpose, route, prompt classification, destination, consumer context before transmission. The decision record preserves those inputs with the policy version and result.

This boundary supports CTDPA data controls, state inventory validation, employment-route evidence, and companion output policy when the application supplies the required context. It also records model destination across providers. That matters on the day a configuration change quietly moves a route while the assessment still names the old endpoint.

Several obligations remain out of scope: user-interface disclosures, subscription acceptance, companion clinical protocol design, population-level anti-bias testing, public impact-assessment posting, local tool execution, STDIO activity, model training, frontier-employee protections. Those need controls at other layers: product, HR, procurement, model development, governance.

DeepInspect

DeepInspect enforces the request-layer portion of Connecticut LLM requirements. It sits between authenticated users or agents and HTTP model endpoints, classifies the assembled prompt, evaluates identity-aware policy and destination, then creates a per-decision audit record before forwarding traffic. Different product routes can carry different policies even when they call the same model.

The application supplies the route, identity, purpose, age or consumer state, plus any other business context the decision needs. DeepInspect can then permit, redact, block, or route the request and record what happened. It cannot display the companion disclosure, collect written subscription acceptance, publish a state assessment, or govern local execution that never enters the HTTP model path.

Book a technical deep dive at deepinspect.ai.