Does Connecticut require every AI incident to be reported to the Attorney General?

No general provision in Public Act 26-15 creates that rule. Attorney General notice can arise under Section 36a-701b when an event meets the personal-data breach test. The CTDPA also gives the Attorney General exclusive enforcement authority over its duties, but an internal model error does not automatically become a statutory notice event. Large frontier developers have a separate internal process for covered employee reports about catastrophic risk. Run each trigger test and document the result.

What is the deadline for a Connecticut AI-related data breach?

Section 36a-701b requires affected-resident notice without unreasonable delay and no later than 60 days after discovery, unless federal law requires a shorter period or law enforcement requests delay under the statute. Attorney General notice is due no later than the time resident notice goes out. The clock attaches to the qualifying breach, not to the date a team later labels the event "AI-related."

Does a hallucination trigger Connecticut breach notice?

A hallucination alone falls outside the breach definition. The analysis changes when the output reveals personal information through unauthorized access or acquisition, or when the underlying event exposes covered computerized data. Preserve the prompt, response, identity, recipient, and endpoint facts needed for counsel to make that determination. Other consumer-protection or sector rules may still apply to a harmful false output.

Can application logs support the incident review?

They can contribute application state and workflow context, along with the business outcome. An independent request-layer record adds the authenticated actor, classified prompt, endpoint, policy version, and enforcement result at the moment of transmission. Using both gives the investigator a stronger chain. The Connecticut AI audit-evidence guide covers the resulting evidence package.

What sits outside an AI gateway's incident boundary?

Local code execution, host compromise, employee retaliation, direct provider traffic that bypasses the gateway, and legal notice delivery sit outside the authenticated HTTP AI path. Separate controls must cover them. A gateway can inspect and record routed prompts and responses; it cannot manufacture evidence for an event it never received.

Connecticut AI Incident Reporting: Three Triggers, Three Different Records

TL;DR

Connecticut uses separate reporting paths for frontier-model catastrophic risk and personal-data breaches. CTDPA compliance matters follow their own path.
Public Act 26-15 requires an anonymous internal process for covered employees of large frontier developers by January 1, 2027.
A qualifying personal-data breach can require resident and Attorney General notice within 60 days.
Ordinary LLM errors belong in an internal incident register unless facts trigger a specific statute.

Three incident paths begin with one queue

A security analyst opens the Monday queue and finds three tickets. One says an LLM exposed a Connecticut resident's medical detail. Another says a recruiting assistant produced a questionable ranking. The last says a frontier-model evaluator reported dangerous autonomous behavior. The tickets all say "AI incident." Connecticut law sends each one down a different path.

The phrase Connecticut AI incident reporting therefore needs a trigger map before it needs a form. Public Act 26-15 addresses a narrow catastrophic-risk reporting process for frontier developers. Connecticut General Statutes Section 36a-701b governs qualifying breaches of computerized personal information. The Connecticut Attorney General's CTDPA guidance covers consumer rights and assessments. It also covers safeguards and exclusive state enforcement. One event can activate more than one path, but the legal tests remain separate.

SB 2 is a search term rather than the operative law

The 2025 Substitute Senate Bill 2 passed the Senate on May 14, 2025. The Connecticut General Assembly's official bill history shows that it reached the House calendar and stopped there. It never became a public act.

Connecticut enacted a different package in 2026. Substitute Senate Bill 5 became Public Act 26-15, titled "An Act Concerning Online Safety." That distinction matters because an incident plan copied from an SB 2 summary can assign the wrong trigger, recipient, deadline, and evidence requirement. Teams should label their control register with the enacted source and section, while retaining "Connecticut SB 2" only as a search alias for people trying to find the current rules.

My view is blunt: a runbook headed "SB 2 reporting" should fail legal review until every row points to an enacted provision. Bill numbers are poor control identifiers after a legislative session closes.

Frontier-model reports are an internal whistleblower process

Section 2 of Public Act 26-15 applies to frontier developers that train foundation models above the act's compute threshold. Its special internal-reporting duty narrows further to a "large frontier developer," defined by annual gross revenue above the amount stated in the act. The duty arrives on January 1, 2027.

The required process lets a covered employee submit a report anonymously when the employee believes in good faith that company activity poses a specific and substantial danger to public health or safety due to a catastrophic risk. The developer must give reasonable updates about the investigation and responsive actions. Reports and updates generally reach officers and directors at least quarterly, with a carve-out when a report alleges wrongdoing by an officer or director.

This is an internal escalation channel with governance requirements. It is distinct from a general duty for every Connecticut business to report every model failure to the Attorney General. The law also protects covered employees and requires notice of their rights. A deployer calling a hosted LLM for customer support ordinarily falls outside this frontier-developer branch.

Operationally, the report record should contain the submission time, protected reporter token, allegation category, model or evaluation identifier, assigned investigator, status updates, actions, and board-routing history. Access controls must keep the reporter's identity separate from the investigation record when anonymity is promised.

Personal-data breaches use the 60-day path

Section 36a-701b applies when unauthorized access or acquisition reaches computerized data containing specified personal information and the information lacks protection that renders it unreadable or unusable. The statutory definition includes combinations such as a name with a Social Security number, government identifier, financial credential, medical information, health-insurance identifier, biometric information, or precise geolocation. Login credentials receive their own treatment.

A covered person must notify affected Connecticut residents without unreasonable delay and no later than 60 days after discovering a qualifying breach, subject to the statute's law-enforcement delay and harm determination. Notice to the Attorney General is due no later than resident notice. A company maintaining data for someone else must notify the owner or licensee immediately after discovery when Connecticut resident data was affected or reasonably believed affected.

The LLM is relevant only through the facts. A prompt sent to an unauthorized endpoint can create a breach question. So can a response exposed to the wrong account or a trace containing unprotected medical information. A hallucinated answer with no unauthorized access to covered personal information follows a different incident process.

The incident record needs enough detail to make that legal classification defensible: discovery time, affected system, Connecticut residency basis, data elements, encryption state, unauthorized actor or destination, containment action, investigation finding, harm analysis, and notice timestamps.

CTDPA events require a compliance and rights analysis

The CTDPA protects Connecticut residents acting in an individual or household context. The Attorney General's guidance states that it excludes individuals acting in an employment context. It gives consumers rights over personal data and requires controllers to conduct data protection assessments or impact assessments for processing that presents heightened risk, including profiling and sensitive-data processing.

An AI event can expose a CTDPA control failure without satisfying the breach statute. Examples include a model route that ignores a consumer opt-out, a profiling system that lacks the required assessment, an LLM workflow that uses personal data for a materially new incompatible purpose without consent, or a rights-response process that omits AI-derived inferences. These matters belong in the privacy incident register and remediation workflow.

The Attorney General has exclusive CTDPA enforcement authority. That makes evidence quality important even when resident breach notice stays out of scope. Preserve the consumer identifier, purpose, route, model endpoint, policy version, assessment reference, rights request, decision, and remediation. The Connecticut AI controls mapping shows where those fields can be captured during an HTTP model call.

Employment AI follows Public Act 26-15's employment provisions and Connecticut antidiscrimination law rather than the CTDPA consumer branch. A recruiting incident needs its own legal owner even when the technical event enters through the same LLM gateway.

A four-stage triage runbook

The first stage classifies the event before anyone chooses a reporting channel. Record the system, owner, model, deployment purpose, affected people, data classes, and event time. Mark the organization's role: frontier developer, AI subscription provider, companion operator, employment-technology developer or deployer, CTDPA controller or processor, data owner, or data maintainer. More than one role can apply.

The second stage runs separate trigger tests:

Frontier catastrophic risk: Was the reporter a covered employee and was the organization a covered frontier developer? Did the allegation concern the act's catastrophic-risk definition?
Security breach: Did unauthorized access or acquisition reach computerized data containing a statutory personal-information combination, and what protection covered the data?
CTDPA compliance: Did processing defeat a consumer right, assessment, consent, purpose, sensitive-data, or safeguard duty?
Employment or companion rule: Did the event occur in an automated employment decision or covered companion interaction governed by Public Act 26-15?

The third stage sets clocks and recipients independently. Qualifying breach notice carries the 60-day outer limit. January 1, 2027 is the date for establishing the large frontier developer's internal channel. Internal severity targets can be shorter, but the incident file should label them as company policy.

The fourth stage preserves one event identifier across legal, security, privacy, and AI records. That prevents four teams from creating four timelines for the same request.

Request-layer evidence supports the incident file

For an LLM event, the strongest operational record starts at the authenticated HTTP request. Capture the initiating user or agent, application route, model endpoint, prompt classification, policy version, allow or block decision, response handling, and time. Add a stable request identifier so the privacy team can connect the event to notices and remediation without copying full prompt text into every case system.

This evidence helps answer factual questions. It can show that a prompt containing a medical identifier reached a model endpoint or that a consumer suppression flag was evaluated. It can also show that an employment route ran under a named policy. The AI audit trail requirements by regulation explain why the policy version and actor belong together.

A request-layer record has boundaries. It cannot investigate local Python execution, inspect STDIO traffic, determine whether a covered employee suffered retaliation, deliver resident notices, or make the final legal judgment that Section 36a-701b applies. Those tasks sit with application security, HR, privacy, legal, and incident response. The gateway supplies evidence for traffic that actually crossed the authenticated user-or-agent-to-LLM HTTP path.

DeepInspect

DeepInspect sits inline between authenticated users or agents and HTTP LLM endpoints. It evaluates identity, prompt classification, route, and policy before traffic reaches the model, then writes a per-decision audit record outside the calling application's write path. A blocked request and a permitted request carry the same core evidence fields, which gives incident responders a consistent starting point.

For Connecticut triage, DeepInspect can show which identity sent which classified content to which endpoint, which policy ran, and what decision followed. It cannot operate the frontier-developer whistleblower channel, decide statutory applicability, notify the Attorney General, or cover activity that bypassed the routed HTTP path. Those boundaries belong in the runbook beside the controls it does provide.

Book a technical deep dive at deepinspect.ai.