Originally published at ictcrm.com
Connecticut became the first US state to write a right of access to inferences into statute, effective 1 July 2026. In plain terms: the lead score your CRM software calculated, the churn rating it assigned, the persona tag nobody on your team chose, are now data a resident can ask you to hand over. Most CRMs cannot produce that list.
I want to be careful here, because this is the kind of topic where confident blog posts get things wrong. I'm not a lawyer and none of this is legal advice. But the operational question underneath the legal one is the same whichever way your counsel reads it, and it's a question you can answer today: does your system know which of its fields it made up?
What actually changed on 1 July
Connecticut's amended privacy law does two things that matter to anyone running a CRM. It makes inferences explicitly personal data, and it gives people a statutory right to access them. That closes an argument controllers have leaned on for years, which went roughly: your name is your data, but our model's prediction about you is our work product.
That argument is finished in Connecticut. Colorado had already gone part of the way, where the access right reaches final profiling decisions, inferences, derivative data and marketing profiles. Connecticut just made it a clean statutory line rather than something you dig out of rulemaking.
The second change is quieter and I'd argue more awkward. Connecticut's opt-out for automated decisions no longer hinges on the decision being solely automated. A human who glances at a screen and clicks approve used to break the chain. Now a rubber stamp doesn't shield the decision. If you built a workflow where a rep confirms whatever the model suggested, you built exactly the thing the amendment is aimed at.
The fields you forgot were data
Pull up any contact record in your CRM and mentally split it into two columns. One holds things the person told you or you asked for. The other holds things your system worked out on its own.
Every CRM on the market exports the left column. It's the right column that causes trouble, and it's grown fast over the last two years. Lead scores were always there. What's new is the pile that arrived with AI features: sentiment on a call recording, a one-paragraph summary of a support thread, a suggested next action, a predicted close date, a tag that says this account looks like the ones that churned last quarter.
Here's the uncomfortable part. Ask your CRM to list every derived field on a contact and most of them can't. The score sits in a column next to the phone number with nothing marking it as different. There's no provenance, no record of which inputs produced it, no timestamp for when the model last recalculated it. So when a request lands, whoever handles it exports the contact record and quietly ships an inference with no explanation attached, or misses it entirely.
Where a score stops being marketing
This is where a lot of coverage overstates things, so let's be precise. California's finalised ADMT rules under the CCPA took effect on 1 January 2026, with compliance required for significant decisions by 1 January 2027 and risk assessments from 1 April 2027. A significant decision means one affecting finances, housing, education, employment or health care. Advertising is specifically carved out.
So no, ranking leads for who gets called first isn't a significant decision under California's rules. Neither is picking which email someone gets. If you read a vendor blog telling you every lead score now needs a pre-use notice, that vendor is selling something.
The risk isn't the score itself. It's drift. A field built for campaign targeting gets useful, so someone wires it into the discount a rep can offer without approval. Then into who qualifies for net-30 terms. Then into which accounts get the priority support queue. Nothing was rebuilt and nobody filed anything, but the same number quietly walked across the line into decisions about finances and service eligibility.
I've watched this happen at three companies now, and it never looks like a compliance event while it's happening. It looks like someone being resourceful in a spreadsheet.
What your CRM software has to be able to do
Five things, in the order I'd tackle them.
Mark derived fields as derived. A flag on the field definition, not a naming convention people remember for six weeks. You want to be able to query the schema and get a list back.
Keep provenance for each one. Which model or rule produced it, when, and what it read. This is the difference between answering a request and guessing at an answer. It's also what you'll want the first time someone asks why a score is what it is.
Export the derived fields with everything else. Your subject access export should include the right column, labelled, with plain-language descriptions. Not raw column names. Someone has to read it.
Make the opt-out actually propagate. If a person opts out of profiling, the flag has to stop the scoring job, not just hide the number in the UI. I'd test this by opting out a test contact and then checking whether the nightly job still writes to it. In my experience it usually does.
Apply retention to inferences. Scores are recalculated constantly and almost nobody prunes the history. If you keep every nightly score for three years, that's three years of profiling history you'd have to produce and defend.
None of that is exotic engineering. It's a field-level flag, an audit row and a job that respects a boolean. The reason it doesn't exist in most systems is that nobody asked for it until now.
Why this is less painful on open source CRM software
I'll declare the bias up front, since we build one. But the structural point holds regardless of vendor.
When the scoring logic is a rule set you can read, answering "why does this contact score 74" is a support question. When it's a hosted model behind an API, it's a vendor ticket, and the answer that comes back is frequently a description of the feature rather than an explanation of the number. You can't forward that to someone exercising an access right.
Self-hosting also means the derived fields sit in a database you control, so adding a provenance table is a migration rather than a roadmap request. And if a regulator or a customer asks what the model was trained on, you can answer without a subpoena. We wrote about the wider case for keeping customer data in your own estate in our piece on the 2026 state privacy patchwork, and this is the same argument arriving one layer deeper.
The honest counterweight: open source doesn't make you compliant. It makes the work possible. Plenty of self-hosted deployments have exactly the same unlabelled score column sitting in exactly the same table.
What I'd do this month
Start with an inventory, because you cannot do anything else until it exists. Open your lead and contact schema and write down every field your system populates without a human typing into it. For most teams that list runs to somewhere between eight and thirty fields, and about a third of them turn out to be things nobody remembers switching on.
Then trace each one forward. Who reads this field, and what changes because of it? The ones that only feed reports and campaign filters, leave alone for now. The ones that touch pricing, credit, eligibility or access to support are the ones to document properly, and they're the ones your counsel needs to see.
Last, run a dry subject access request against your own system using a real contact record. Not a spec review, an actual export. What comes out will tell you more in twenty minutes than a week of policy work. If the lead score isn't in the file, you've found your gap.
FAQ
Does this apply to my business if I'm not in Connecticut?
The Connecticut right applies to Connecticut residents, and the thresholds are about how many residents' data you process rather than where your office is. In practice, most teams selling across the US end up building to the strictest rule they're subject to rather than maintaining a different export per state. That's what happened with GDPR and it's happening again here.
Is a lead score really an inference?
If a person didn't tell you the number and your system calculated it from other data about them, yes, that's the shape of an inference. Simple rule-based scoring counts as much as a machine-learning model does. The technology used doesn't change what the field is.
Do I need to explain how the score was calculated?
Access and explanation are different rights and they vary by state. But being able to say which inputs fed a score is useful well beyond compliance, and if you can't say it, you also can't debug the score or defend it to a customer who thinks it's wrong.
What about AI-written summaries of calls and tickets?
They're derived text about an identifiable person, so treat them the same as a score. These are the ones teams forget most often, because they read like notes rather than data. Worth checking whether yours are stored on the contact or hidden in an activity log.
Does deleting the contact delete the inferences?
Only if they're stored on the contact. Scores copied into a reporting warehouse, a marketing tool or a model's training set survive the delete, and that's the cleanup most teams discover late. Map where derived fields get copied before you need to answer a deletion request.
Can ICTCRM do this today?
Field-level export and self-hosted storage, yes. A formal provenance table for derived fields is something we're working through now, and if you're running into this we'd rather hear the specific shape of your problem than guess at it. The features page covers what ships today.
If you want to look at this on a system where the scoring rules are readable and the data sits on your own server, take ICTCRM for a spin and check the derived-field question yourself on day one.
Top comments (0)