Which Connecticut entities need an AI impact assessment?

Public Act 26-15 creates a specific assessment and publication process for covered state-agency procurement and use. The CTDPA separately requires covered controllers to assess personal-data processing that presents heightened risk. Other provisions create use-specific duties for employment technology and minors, along with companions and frontier developers. Determine the role and data before selecting the assessment form. Then determine the use.

Is an LLM automatically subject to a Connecticut risk assessment?

The technology label alone does not decide the issue. A controller using an LLM for profiling or sensitive-data processing may trigger the CTDPA assessment branch. A state agency procuring it for a covered function reaches Section 38. Employment use can activate Public Act 26-15's employment provisions. A private internal drafting assistant using no consumer personal data can sit outside those specific branches while remaining subject to company risk policy and other law.

What must the state agency post 60 days before deployment?

Section 38 requires the AI impact assessment to be submitted to the Commissioner of Administrative Services and posted on the agency website at least 60 days before deployment. The assessment follows standards set by the Office of Policy and Management and Department of Administrative Services. The act allows redaction of personally identifiable information from the posted version.

Does a CTDPA assessment replace technical testing?

The assessment documents purpose and risk, plus controls and residual exposure. Technical tests show that the configured system follows that design. Sample permitted and redacted requests, plus blocked requests. Verify consumer opt-out handling and endpoint restrictions, then retain the policy version. The Connecticut audit-evidence guide describes the artifacts reviewers can inspect.

Can one assessment cover several LLM applications?

A shared control annex can cover the common gateway and identity services, plus logging and classification. Each materially different purpose, data set, affected population, model route, and decision role still needs a scoped analysis. A customer-support summarizer and an applicant-ranking system may share infrastructure while carrying different Connecticut triggers and harms.

What gateway evidence belongs in the assessment file?

Include representative request identifiers, actor and agent identity, route and prompt classification, destination and policy version, decision and timestamp, plus the link to the applicable control test. Store sensitive prompt content under a minimization and access policy. The evidence should prove control operation without turning the assessment repository into a duplicate prompt archive.

Connecticut AI Risk Assessment: Separate the State, Consumer, and Employment Tests

TL;DR

Connecticut has several assessment branches, each tied to a role and use case rather than to AI in general.
Public Act 26-15 requires covered state agencies to complete an AI impact assessment before authorized procurement and post it at least 60 days before deployment.
CTDPA controllers assess processing that presents heightened consumer risk, including profiling and sensitive data.
Runtime request evidence tests whether the deployed system matches the filed assessment.

Scope determines the assessment

A Connecticut AI risk assessment begins with a scope decision. A state agency buying a benefits chatbot and a retailer profiling consumers each face a different source of authority. An employer using an LLM to rank applicants faces another. Putting all three into one generic "AI risk" worksheet hides the legal trigger that makes each control testable.

The enacted anchor is Public Act 26-15. Its state-agency provisions require an AI impact assessment for authorized procurement and public posting before deployment. The Connecticut Attorney General's CTDPA guidance separately says controllers must conduct data protection assessments and impact assessments before processing personal data in a manner presenting heightened risk, including profiling and sensitive-data processing. The CTDPA statutory chapter supplies five definitions that shape that analysis: controller, consumer, personal data, profiling, significant decision.

SB 2 never supplied the final assessment rule

The 2025 Substitute Senate Bill 2 generated the keyword that many teams still use. The General Assembly's bill history records Senate passage on May 14, 2025 and House calendar action on May 16. It records no public act. Risk teams should therefore cite the enacted statute governing their role rather than carry SB 2 language into an assessment template.

Public Act 26-15 became law through Substitute Senate Bill 5 in 2026. Its 74 pages cover distinct subjects: frontier developers, AI companions, automated employment technology, content provenance, state systems, platforms used by minors. The act avoids one universal private-sector AI assessment. Its obligations branch by role.

That structure changes the opening question. Ask who operates the system and whose data enters it. Then ask what decision or service it supports and assign the governing assessment. A model inventory entry alone cannot answer those questions because the same hosted LLM can support an internal drafting tool at 9:00 and a consumer credit workflow at 9:05.

State agencies have a procurement and publication branch

Section 38 of Public Act 26-15 takes effect October 1, 2026. It covers state-agency use of AI technology in functions related to public-assistance benefits or functions with a material impact on the rights, civil liberties, safety, or welfare of people in Connecticut. It also covers state-agency procurement of AI technology, including purchase and acquisition, under policies and standards set by the Office of Policy and Management and Department of Administrative Services.

An authorized procurement requires an AI impact assessment that complies with those policies and standards. The agency submits it to the Commissioner of Administrative Services and posts it on the agency website at least 60 days before deployment. Personally identifiable information may be redacted from the posted assessment.

Section 37 strengthens the inventory side. By December 31, 2026 and annually after that, the Department of Administrative Services inventory must include the system and vendor, capabilities and uses, decision role, assessment status and date, access to personally identifiable information, plus known risks. The risk entry covers state employees as well as individuals and communities.

A useful state assessment therefore carries deployment date and posting date, procurement authority and owner, vendor and purpose, affected service and decision role, data access and risks, mitigations and test owner, plus residual-risk approval. On a conference-room wall, the deployment timeline should visibly place the publication milestone 60 days before go-live. That small physical detail catches a late assessment faster than another policy paragraph.

CTDPA controllers have a personal-data branch

The CTDPA applies to a controller that determines the purpose and means of processing consumer personal data and meets the act's applicability conditions. The consumer definition focuses on Connecticut residents acting in an individual or household context and excludes employment activity. This branch follows the data and processing purpose rather than the model category.

The Attorney General's guidance identifies assessment duties for processing that presents heightened risk. It specifically names targeted advertising and sale, plus profiling and sensitive-data processing. For an LLM workflow, the assessment should describe the personal data placed in prompts and derived inferences. It should also describe the intended purpose and model destination, the processor relationship and retention, consumer rights and opt-out handling, plus security safeguards and foreseeable harms.

Profiling deserves its own decision map. The statutory definition covers automated processing used to evaluate, analyze, or predict personal aspects: economic situation, health, preferences, reliability, behavior, location, movements. A summarization feature can become profiling when its output evaluates a person for a significant decision. The assessment must follow the actual use.

The Connecticut AI compliance checklist translates this branch into implementation actions. The risk assessment is the design record; request evidence shows how the design operated during the review period.

Employment technology follows a separate use-case analysis

Public Act 26-15 defines automated employment-related decision technology broadly enough to reach an LLM when it processes personal data and generates a prediction, recommendation, classification, ranking, score, or other output that is a substantial factor in an employment decision. The definition excludes incidental systems. It also excludes purely descriptive or statistical information, including diagnostic information, that the decision maker does not rely on materially.

The employment provisions apply to hiring and promotion, discipline and discharge, renewal, training or apprenticeship selection, tenure, plus material terms or conditions. For covered deployments beginning October 1, 2027, the act requires plain-language interaction disclosure in relevant cases and a written notice before a covered employment decision. That notice identifies the purpose and decision. It also identifies the trade name and personal-data categories, the assessment method and data sources, plus the deployer contact.

The assessment file should test the substantial-factor threshold with evidence. Record where the LLM output enters the workflow and who sees it. Record what weight or constraint it carries and how a reviewer can override it. Anti-bias testing can become evidence in a discrimination proceeding under the act's amendment to Connecticut employment law, but a test report leaves the deployment's actual use unproven.

The CTDPA consumer branch excludes employment context. Conflating the two leads to the wrong rights language and misses Public Act 26-15's employment notices.

The assessment should describe one real request path

A credible assessment traces a representative transaction. Start when an authenticated person or agent initiates the workflow. Follow the personal data into the prompt, through retrieval and tool output, across the HTTP request to the model, into the response, then onward to the business decision. Name each system that stores or transforms the data.

For every step, record:

Purpose and authority: the approved use and legal owner. Record the affected Connecticut role.
Identity: the human or agent that initiated the request and any delegated actor.
Data: categories in the assembled context. Include retrieved material and derived inferences.
Destination: model provider, endpoint, region, processor relationship.
Decision role: informational, advisory, substantial factor, independently determinative.
Controls: classification, redaction, opt-out resolution, routing, access policy, review, retention.
Evidence: policy version, test result, request record, incident link, approval.

The Connecticut controls mapping can supply control owners and enforcement points. Keep the assessment focused on the risk argument: harm and likelihood basis, mitigation and residual exposure, plus acceptance authority.

Runtime validation closes the design-to-deployment gap

An assessment freezes a design at a point in time. LLM deployments change through prompts, retrieval sources, model versions, routing, tools, policy configuration. Validation compares the live path with the assessed path.

Select at least one permitted request and one blocked request for each material route. Confirm the actor and purpose, the personal-data classification and model endpoint, the policy version, the decision, plus the time. A profiling sample should include a request tied to a consumer opt-out and show that suppression state reached the policy decision. Employment validation uses a request that informed a decision, with its route tag and notice linkage. State-agency reviewers compare the endpoint and data access with the public inventory entry.

Change control should define reassessment triggers. Seven changes can alter the risk analysis: a new model endpoint, a new personal-data category, a new consequential use, a new tool, a new retrieval source, a changed population, a changed decision weight. The assessment owner records the trigger. The owner then chooses a full reassessment or targeted addendum, or records a documented no-change decision.

My opinion is that an assessment without a sample request ID is an architecture memo. Connecticut reviewers need a record that connects the memo to the deployed system.

Coverage boundaries for an HTTP AI gateway

A gateway at the authenticated user-or-agent-to-LLM HTTP boundary can enforce and record identity, prompt classification, model destination, and policy version. It records whether the request was allowed, redacted, or blocked. Those artifacts support the data-flow and control-operation portions of a Connecticut assessment, plus validation.

Several assessment areas remain outside that boundary. A gateway cannot establish organizational applicability or draft a public state-agency posting. It also cannot evaluate employment discrimination across an applicant population, validate training-data quality, inspect local code execution, supervise STDIO tools, or prove that a human reviewer exercised meaningful judgment. Separate owners also cover procurement terms, workforce training, user-interface notices, consumer request handling, plus board approval.

State those exclusions directly in the assessment. Partial coverage is useful when the document names the part covered and the evidence source. It must also name the owner for the remainder. Claiming complete coverage creates a gap for the reviewer to find.

DeepInspect

DeepInspect supplies the request-layer control and evidence portion of this assessment. It sits inline between authenticated users or agents and HTTP LLM endpoints and classifies the assembled prompt. It evaluates identity-aware policy and destination, then records the decision before the request proceeds. The record includes the context needed to compare live behavior with the assessed route.

For Connecticut controllers and state agencies, that means an assessor can sample a request and see the caller and data class, the endpoint and policy version, plus the result in one place. DeepInspect requires the application to provide reliable identity and purpose, along with consumer context. Other systems and owners remain responsible for population-level bias testing, legal scope, public posting, procurement, user notices, local runtime behavior.

Book a technical deep dive at deepinspect.ai.