If Your Software Decides Things About People, 2027 Just Got Real: Colorado, California and Canada's Bill C-36

For two years the story of AI regulation in North America was a story of delay. Colorado's landmark AI Act kept getting pushed back. Canada's AIDA died on the order paper. Washington talked about wiping out state AI laws altogether. Plenty of product teams took the hint and parked the question. That position stopped being safe this year. Between May and June 2026, Colorado rewrote its law instead of repealing it, California's automated decision rules moved onto a fixed countdown, and Ottawa tabled Bill C-36 to replace PIPEDA. The details differ, but the direction is the same on both sides of the border: if your software makes or shapes decisions about people, those people are about to be owed a notice, an explanation and a way to reach a human.

This is not a legal memo, and it is not a substitute for one. It is the view from the people who actually build these systems, written for founders, product owners and engineering leads who need to know what to put on the roadmap. The short version: the legal deadlines are still months away, but the features these laws require take longer to build properly than most teams expect, and they are much cheaper to design in than to bolt on.

What actually changed in 2026

Three developments matter most, and it helps to see them side by side before going into each one:

• Colorado repealed and replaced its 2024 AI Act with Senate Bill 26-189, signed in May 2026 and taking effect January 1, 2027. The new law drops the broad "high-risk AI system" framing and focuses squarely on automated decision-making technology used in consequential decisions about consumers.
• California's privacy regulator finalised rules on automated decision-making technology, risk assessments and cybersecurity audits under the CCPA. Businesses that use automated tools to make significant decisions about consumers must comply with the ADMT requirements from January 1, 2027, with risk-assessment obligations phasing in behind them.
• Canada published its National AI Strategy, "AI for All", on June 4, 2026, and on June 15 the Minister of Artificial Intelligence and Digital Innovation, Evan Solomon, tabled Bill C-36. It would replace the private-sector part of PIPEDA with a new Protecting Privacy and Consumer Data Act — including explicit transparency obligations for automated decision systems.

Notice what is missing from that list: a sweeping, standalone AI law in either country. Both governments are regulating what AI does to people rather than what AI is. For software teams, that is actually the more demanding version, because it attaches obligations to ordinary product features — a screening step, a risk score, an approval workflow — rather than to some exotic category of system you can decide you are not building.

Colorado: narrower, clearer, and still coming

The original Colorado AI Act was the first comprehensive state AI law in the US, and it was widely criticised as vague and hard to comply with. After repeated delays, the legislature did not abandon it — it rebuilt it. SB 26-189 regulates the use of automated decision-making technology when it materially influences a consequential decision about a consumer: the kinds of decisions that shape a life, such as employment, housing, lending, insurance, education and access to essential services.

The obligations split between the company that builds the technology and the company that uses it:

• Developers must give deployers technical documentation covering the tool's intended uses, the categories of data it was trained on, its known limitations, and instructions for appropriate use and human review — and must tell deployers about material updates.
• Deployers must give consumers a clear notice before the technology is used to materially influence a consequential decision about them.
• After an adverse outcome, deployers must send an individualised disclosure within thirty days, describing in plain language what the decision was and the role the technology played in it, and how to request more information.
• Consumers get the right to see and correct factually incorrect personal data the system used, and to request meaningful human review and reconsideration of an adverse outcome.

If you sell software to other businesses, read the developer half carefully. A lot of SaaS vendors assume the compliance burden sits with their customers. Under the Colorado model, your customers cannot meet their obligations without documentation only you can produce — which means it will increasingly show up as a requirement in procurement questionnaires and contracts, whether or not you have a single user in Colorado.

California: the rules with the widest reach

California matters more than its population suggests because the CCPA already applies to a very large number of businesses across North America, and its regulator has now moved from transparency into substantive governance of automated decisions. Under the finalised regulations, a business that uses automated decision-making technology to make significant decisions about consumers — again, areas like employment, housing, lending, education and healthcare — must give a pre-use notice, honour access requests about how the technology is used, and in many cases offer a way to opt out or appeal to a human reviewer.

Alongside the ADMT rules sit risk assessments. Businesses doing higher-risk processing, including using automated tools for significant decisions, have to document what they are doing, why, and how they are managing the risk, with the first assessments for existing processing due by the end of 2027 and summary information submitted to the regulator after that. The practical implication is that "we use an AI model somewhere in our screening flow" is no longer a sentence you can say without a written record behind it.

Canada: Bill C-36 and a framework without a single AI law

Canada's approach this year is the clearest example of regulating AI through the side door. There is no revived AIDA. Instead, the National AI Strategy sets out a plan built on adoption, domestic capacity and public trust, and the government signalled that AI risks will be handled through privacy reform, online safety, consumer protection, standards and sector-specific rules rather than one comprehensive statute.

Bill C-36 is the centrepiece of that approach and the first serious overhaul of federal private-sector privacy law in more than 25 years. For product teams, three parts stand out:

• Automated decision systems are defined broadly — not just machine learning and neural networks, but rules-based systems, regression analysis and predictive analytics. If your "AI" is a scoring spreadsheet wired into a workflow, it is very likely in scope.
• Organisations would need to be transparent about their use of these systems and able to explain, in plain language, how an automated system produced a decision affecting a person.
• Children's personal information would receive stronger protection, and the enforcement regime has real teeth, with administrative penalties scaled to global revenue for the most serious contraventions.

C-36 is still a bill, and its final shape will depend on committee work in Parliament this fall. But Quebec businesses already live under Law 25, which requires organisations to inform people when a decision about them is made exclusively by automated processing and to let them have it reviewed by a person. Between Law 25 today and C-36 tomorrow, "explain the decision and offer a human" is becoming the Canadian baseline, not a future possibility.

What about federal preemption in the US?

The most common reason teams give for waiting is that Washington will override the states. It is worth being precise about where that stands. A December 2025 executive order created a Department of Justice task force to challenge state AI laws seen as unduly burdensome, and Congress has debated a preemption statute. As of September 2026, no such statute has passed, the leading bipartisan draft has stalled since June, and the proposals under discussion focus mainly on laws that regulate how AI models are developed — not laws about how AI is used in decisions about consumers, and not privacy and consumer protection rules like California's.

That distinction matters. Even the most aggressive preemption scenario on the table leaves the core obligations in this article — notice, explanation, correction and human review in consequential decisions — largely intact. Betting your roadmap on those rules disappearing is a bet against the direction every jurisdiction in this article is moving.

None of these laws ask you to stop using automation. They ask you to be able to answer a simple question from the person on the other end: what did your system decide about me, why, and how do I talk to someone about it?

Are you in scope? A quick test

You do not need a legal opinion to know whether this deserves a place on your roadmap. If you can answer yes to any of the following, it does:

• Does your product rank, score, filter or recommend people — job applicants, tenants, borrowers, students, patients, policyholders?
• Does any automated step, including a simple rules engine, approve, reject, flag or route someone in a way that affects their access to a job, housing, credit, insurance, education or a service?
• Do you use a third-party AI model or API to summarise, classify or assess people, even if a human signs off at the end?
• Do you sell software to businesses that do any of the above, so that their compliance depends on documentation you would need to provide?

The "a human signs off at the end" answer deserves particular suspicion. All three regimes care about technology that materially influences or substantially drives a decision. A reviewer who approves ninety-eight percent of what the system recommends, in seconds, is not the kind of human oversight any of these laws have in mind.

What to build now: compliance as product features

The good news for engineering teams is that these obligations translate into a fairly consistent set of features, and most of them make your product better regardless of the law. This is what we are recommending to clients building or maintaining decision-making software:

• A decision log. Record every automated decision with the inputs it used, the model or rules version that produced it, the output, and who (if anyone) reviewed it. Without this, you cannot explain a decision after the fact, correct it, or defend it — and every regime above assumes you can.
• Reason codes, not just scores. Design your models and rules to emit the top factors behind each outcome in terms a person can understand. Retrofitting explanations onto a black-box score is far harder than capturing them at decision time.
• Notice at the right moment. Build configurable pre-use notices into the flows where automation is involved, and templated adverse-outcome messages that can be sent within the required window, per jurisdiction.
• A real human review path. An in-product way to request reconsideration, routed to a reviewer who can see the decision log, override the outcome and record why. Track how often humans actually disagree with the system — it is one of the best quality signals you have.
• Data access and correction. Let people see the personal data a decision relied on and flag what is wrong, with corrections flowing back into re-evaluation rather than into a support inbox.
• Model and vendor documentation. Maintain a living record of each model's purpose, training data categories, known limitations and changes over time. If you are a vendor, this becomes a deliverable; if you buy AI from a vendor, demand it.
• Jurisdiction-aware configuration. Rules differ between Colorado, California, Quebec and federal Canada, and they will keep changing. Treat notices, retention periods and review requirements as configuration, not hard-coded logic.

We made a similar argument about accessibility earlier this year: when deadlines move, the teams that keep building are the ones that end up ahead, because the underlying expectation never moved. The same is true here. Explainability, auditability and a human escape hatch are what users and enterprise buyers increasingly expect from any AI-assisted product — and if you are building AI agents that take actions on people's behalf, those same foundations are what make them trustworthy enough to deploy.

A realistic timeline

January 1, 2027 sounds far away until you map it against a normal release cycle. A sensible plan for the next three months looks like this. In October, inventory every place your product makes or shapes a decision about a person, and classify which ones touch consequential or significant decisions. In November, add decision logging and reason codes to the highest-risk flows and draft your notices with counsel. In December, ship the human review path and data-correction flow, and test the whole loop end to end — including what happens when a reviewer overturns the system. Canadian teams should run the same exercise against Law 25 now and treat C-36 as the next revision rather than a separate project.

The bottom line

The headline fights over AI regulation — federal versus state, one big law versus many small ones — will keep making news. Underneath them, a quieter consensus has formed across Colorado, California, Quebec and Ottawa: people are entitled to know when software is deciding things about them, to understand why, and to reach a human when it gets it wrong. Build those three things into your product and you are ready for almost any version of the rules that eventually lands. Leave them out and every new law becomes an emergency.

If you are not sure where automation is hiding in your product, or you want a second opinion on how to add explainability and human review without rebuilding everything, that is exactly the kind of problem we like working through with teams.