This month’s edition covers four developments shaping AI governance and data privacy risk. Colorado has enacted a new AI decision-making framework with significant contract implications. Connecticut has substantially overhauled its privacy law — a preview is included here, with a full dedicated analysis to follow later this week. The EU is finalizing AI Act classification guidance with a feedback deadline of June 23. And agentic AI systems are creating governance exposure that most organizations have not yet addressed.
We advise in-house legal and privacy teams on AI governance, privacy compliance, regulatory strategy, and post-deployment risk remediation. Across industries, the pattern is consistent: organizations are already deploying AI in ways that create exposure — often before legal teams have visibility.
01 Regulatory Update — Colorado SB 26-189: AI Compliance Framework & Contract Obligations
02 Regulatory Update — Surveillance Pricing under the CTDPA
03 Regulatory Update — EU AI Act: Classification Guidance & Revised Enforcement Timelines
04 Operational Risk — The “We Already Launched It” Problem: How DPOs Must Evolve
05 Emerging Risk — When the AI Manages the Manager: Legal Risks of Agentic Systems
LK Law Firm is one of only two NYC firms ranked in Chambers Spotlight 2026 New York for Privacy & Data Security and is recognized as a “go-to firm for major companies.”
01
Regulatory Update
Colorado SB 26-189: AI Compliance Framework & Contract Obligations
On May 14, 2026, Colorado enacted SB 26-189, repealing and replacing prior AI legislation with a targeted framework focused on automated decision-making technology (ADMT) used in consequential decisions. Effective January 1, 2027, the law imposes distinct obligations on both developers and deployers of covered ADMT.
Developer Obligations
Developers must provide deployers with technical documentation covering the system’s intended uses, categories of training data, known limitations, and instructions for appropriate use and human review. Developers must also notify deployers of material updates or modifications.
Deployer Obligations
Deployers must provide clear and conspicuous notice to consumers at the point of interaction. Where covered ADMT results in an adverse consequential decision, deployers must provide a plain-language description of the system’s role within 30 days. The Attorney General must adopt rules clarifying post-adverse-outcome disclosure requirements by January 1, 2027.
Consumer Rights
Consumers may request personal data and correction of factually incorrect data used by covered ADMT, and may request meaningful human review and reconsideration following any adverse consequential decision.
Recordkeeping & Enforcement
Both developers and deployers must retain compliance records for at least three years. Enforcement runs through the Colorado Consumer Protection Act; violations constitute deceptive trade practices. Before initiating action prior to January 1, 2030, the AG must provide a 60-day cure notice. No new private right of action is created, but the act establishes fault allocation between developers and deployers in existing discrimination claims.
Contract Drafting Alert — Indemnification Provisions
SB 26-189 voids indemnification clauses in developer-deployer contracts that purport to shield a party from liability for its own acts or omissions in violation of Colorado anti-discrimination law. Any provision indemnifying, defending, or holding harmless a party from liability arising from its own discriminatory use of ADMT — in violation of the Colorado Anti-Discrimination Act or related statutes — is declared contrary to public policy and void.
Practical implications:
- Audit existing ADMT vendor agreements for broad indemnification language
- Do not rely on indemnification provisions as a backstop against discrimination liability under Colorado law
- Ensure fault allocation clauses reflect the actual developer/deployer responsibility split
This provision applies notwithstanding any other provision of law — parties cannot contract around it.
Contract Drafting Alert — Liability Allocation Between Developers and Deployers
The statute establishes a fault-based (not joint and several) liability framework for discrimination claims. The liability boundary tracks directly to what the developer “intended, documented, marketed, advertised, configured, or contracted for” — making precise contract language a live liability issue.
How fault is allocated:
- Developers are liable only where the ADMT was used as intended, documented, and contracted for, and materially influenced the discriminatory outcome
- Developers are not liable for deployer use outside those parameters — provided the developer complied with its documentation obligations
- Deployers’ independent acts and out-of-scope use remain fully actionable regardless of developer compliance
Practical implications:
- Developers: define permitted use cases precisely — use outside those boundaries shifts liability to the deployer
- Deployers: vendor compliance with developer obligations does not shield you from liability for your own deployment decisions
- Both parties: ensure contracts and technical documentation are internally consistent — inconsistencies create ambiguity about where liability falls
- Review scope-of-use clauses and limitation-of-liability provisions in light of this fault-allocation framework
The practical risk: deployers who customize or expand use beyond documented intended scope bear full liability for that deviation, with no recourse to the developer.
Key Takeaways for Legal & Compliance Teams
- Map AI deployments against Colorado’s ADMT triggers before year-end — January 1, 2027 is closer than it appears
- Audit developer and deployer contracts for indemnification provisions that Colorado’s void-as-public-policy rule would invalidate
- Review scope-of-use and intended-use contract language — the fault-allocation framework makes precise use-case definitions a liability issue
- Confirm recordkeeping processes are in place to retain compliance records for at least three years
02
Regulatory Update
Surveillance Pricing under the CTDPA
Surveillance pricing based on your income, browsing history, or location is a different story after October 1. In-house counsel and privacy leaders at companies in e-commerce, travel, food delivery, ride-sharing, entertainment, ticketing, and marketplaces should pay special attention.
Connecticut’s amended data privacy law puts real teeth behind “surveillance pricing” — using an individual consumer’s personal data to set or raise their specific price. This isn’t a novel theory: New York’s Algorithmic Pricing Disclosure Act has required a similar disclosure since November 2025. Maryland’s new law hits the same October 1 deadline as Connecticut’s, though its ban is narrower — food retailers and third-party delivery only.
If personal data plays into your pricing model and you touch Connecticut residents, you may need to display:
“THIS PRICE WAS INCREASED USING YOUR PERSONAL DATA”
— clearly, at the point of sale, whenever that price is advertised online. This is an unfair/deceptive trade practices issue, enforceable by the CT AG, not just a privacy footnote.
I’m advising clients to move on four things now:
- Map your footprint — Connecticut, Maryland, and New York each define scope and obligations differently, so build one governance process that can flex across jurisdictions rather than three separate playbooks.
- Audit pricing logic — flag anywhere personal data (e.g. device signals, browsing behavior, third-party data) influences price.
- Check the exceptions — several carveouts exist (loyalty programs, cost/geography differences, promotional discounts, and others), and which one applies (if any) depends on the specifics of your pricing model.
- Document your position — whether you’re relying on an exception or building the disclosure into your UX, keep contemporaneous evidence to support it.
If you’re trying to figure out whether your pricing model triggers this, or which exception (if any) applies, that’s the kind of analysis I help clients work through. Send me a message.
03
Regulatory Update
EU AI Act: Classification Guidance & Revised Enforcement Timelines
The European Commission has published draft guidance on classifying high-risk AI systems under Article 6 — open for feedback until June 23, 2026 — alongside a May 7, 2026 provisional agreement under the Digital Omnibus adjusting key compliance timelines. The classification guidance introduces a structured self-assessment methodology, sector-specific examples, and analysis of how intended purpose drives classification outcomes. For companies building or deploying AI in regulated product environments, this will be the operational framework they work through once finalized.
Proposed Timeline Adjustments
If formally adopted, the Digital Omnibus agreement would introduce the following compliance dates:
| Effective Date | Requirement |
|---|---|
| Dec. 2, 2027 | Compliance for standalone high-risk AI systems (Annex III) |
| Aug. 2, 2028 | Compliance for high-risk AI embedded in regulated products |
| Dec. 2, 2026 | Transparency requirements for AI-generated content |
Important — These Changes Are Not Yet Legally in Force
Until formal adoption and publication in the Official Journal, the original August 2, 2026 deadline remains operative. For legal and compliance teams, the practical implication is clear:
▶ The timeline may shift — but the work required to reach compliance does not.
Why This Matters Now
For many organizations, the risk is misreading the extension as additional time to delay. In practice, AI system mapping, classification, and governance framework development require significant lead time. Organizations that wait for formal adoption will compress implementation into an already constrained window — particularly those with AI embedded in regulated products, where the technical and documentation requirements are most demanding.
The agreement also introduces targeted amendments worth tracking: it clarifies the term “safety component,” reduces regulatory overlap where sectoral legislation already addresses comparable AI risks, and reinstates mandatory registration in the EU high-risk database for providers relying on an Article 6(3) exemption. For global companies, a persistent compliance gap remains: AI systems are deployed across jurisdictions, but governance frameworks remain fragmented or U.S.-centric.
Key Takeaways for Legal & Compliance Teams
- Treat extended timelines as a planning assumption, not a basis for delay — the original August 2, 2026 deadline remains operative until formal adoption
- Begin EU classification and governance work now — regardless of final adoption timing
- Where uncertainty exists, prioritize early mapping and documentation — these steps are required under either timeline
- If relying on an Article 6(3) exemption, confirm registration obligations in the EU high-risk database
04
Operational Risk
The “We Already Launched It” Problem: How DPOs Must Evolve in the Age of AI
One of the most consistent risks we see across organizations is not regulatory complexity — it is deployment without legal or privacy visibility. A stakeholder mentions an AI integration in passing, and the legal or privacy team discovers that a system involving personal data has already been deployed — sometimes for months. This is no longer an edge case. It is the defining operational risk for AI governance.
Three Common Failure Points
Scenario 1 — The “Wellness” App
A consumer-facing application deploys AI features processing sensitive data without triggering a DPIA or notifying privacy teams.
Scenario 2 — The Silent HR Tool
An automated recruiting system creates obligations under GDPR Article 22 or similar frameworks without legal involvement.
Scenario 3 — The LLM Integration
Customer or internal data is shared with a third-party model provider before contractual protections or data flow assessments are in place.
The common thread: DPOs and legal teams positioned as passive reviewers will always be reacting after risk is created. Large organizations struggle with fragmentation and scale; mid-sized organizations move quickly with limited formal controls. The pattern is consistent regardless of size.
Listen — The Role of Data Protection Officers in the AI Era
Lena Kempe joined Donata Stroink-Skillrud, President of Termageddon and Chair of the ePrivacy Committee of the American Bar Association, on the Privacy Lawls podcast to discuss how AI is reshaping the modern DPO’s role — and what compliance teams should actually do when these situations arise. The episode walks through the three scenarios above and the practical steps privacy leaders can take when an AI system has already been deployed without their input.
Listen to the full episode: termageddon.com/podcast/ep-33-the-role-of-data-protection-officers-in-the-a-i-era
What to Do Now
If you have deployed AI in the past 12–18 months, assume gaps exist. Immediate priorities:
- Establish a mandatory AI intake and review process enforceable across business units
- Conduct a targeted audit of existing AI and LLM deployments for undisclosed data flows and missing contractual protections
- Reassess whether your DPIA and risk triggers reflect AI-specific use cases
We are increasingly supporting clients with rapid post-deployment audits, AI governance program design, and vendor and data flow remediation — if any of the scenarios above are familiar, that is the right starting point.
05
Emerging Risk
Agentic AI: Governance Frameworks Are Not Keeping Up
A growing category of systems — often called agentic AI — introduces risks that most privacy and governance programs are not designed to handle. Unlike traditional automation, these systems can take multi-step autonomous actions, retain information across interactions, and influence human decision-makers. My recent analysis of these issues, including practical strategies for in-house counsel and privacy leaders, was published in Bloomberg Law.
Four Issues That Require Immediate Attention
Ongoing data retention across interactions may conflict with deletion and minimization obligations under GDPR, CCPA, and similar frameworks — a conflict most governance programs have not yet mapped.
Complex multi-step workflows may make it difficult to explain outcomes in a legally defensible way — directly undermining explainability requirements under applicable law.
If human oversight is shaped or influenced by AI outputs, regulators may question whether that oversight is truly independent — threatening compliance with mandatory human-review requirements.
Some agentic systems incorporate emotional inference capabilities that may trigger obligations under laws such as Illinois BIPA — even without demonstrated harm, exposure alone is sufficient to bring a claim.
What This Means for Your Organization
Many organizations are experimenting with these systems informally — without documented safeguards, updated retention policies, or clear assignment of responsibility. If you are piloting or deploying these tools, your existing governance model likely does not cover them.
What to Do Now
- Identify whether any systems include persistent memory or autonomous decision workflows
- Evaluate whether your explainability and human oversight requirements are achievable in practice given system architecture
- Review whether any features — including emotional inference — could trigger biometric or sensitive data obligations under applicable law
My Bloomberg Law analysis explores these issues in depth and is available via the link in my AI Law Blog at lklawfirm.net/emotion-aware-agentic-ai-legal-risks/.
Leave a Reply