Dan Haiem is the founder and CEO of AppMakers USA, helping business leaders design, build and scale apps that deliver real-world impact.
The thing about AI regulations is that they are usually whispered during product meetings, unknowingly.
A lot of leaders today still file AI regulation under “we’ll deal with it later.” It gets treated like a compliance checkbox. To be fair, that feels reasonable because it’s hard to justify slowing down for rules that seem vague, evolving or far away.
But from where I sit as a CEO building software for real businesses, AI regulation shows up as a product decision that teams keep trying to postpone. And that delay has an operational cost that hits timelines, budgets and trust. Obviously, we can’t afford that.
Don’t get me wrong, AI regulation rarely dramatically blocks a product. That’s the irony of it. But it, for sure, introduces uncertainty into the build, and uncertainty is where momentum dies.
Why Regulation Affects Products Before Anyone Notices
Regulation usually shows up in the form of questions that sound simple, but aren’t: Can we use this dataset? Do we have permission to store it this way? Can we explain how the model reached this output? What happens if a user challenges a decision?
The tricky part is that these questions often surface before the rules feel settled. You can see it in the Colorado AI Act, which targets what it calls high-risk AI systems.
Even before enforcement, the law signaled that developers may need to do more than “build the model and ship.” It points toward duties like impact assessments, documenting foreseeable risks and keeping records that can be reviewed later.
For product teams, that translates into real design work.
Colorado’s law also sparked enough debate that lawmakers revisited parts of it. But that’s exactly the point. When rules are still being interpreted and adjusted, teams don’t get clarity. They get uncertainty, and uncertainty slows decisions long before anyone is fined.
Those questions don’t come from a regulator knocking on your door. They come from your own team, usually mid-build, when someone realizes the feature technically works but may be hard to defend later.
I’ve seen this happen even with teams that have good intentions and strong security practices. A client asks for an AI feature, everyone gets excited, the prototype looks great and then the real questions surface.
When those decisions are not made early, the project doesn’t stop. It slows. You get “soft pauses.” Meetings multiply. Work gets reworked. Teams start building “temporary” paths that become permanent because no one wants to reopen the decision later.
That’s the first quiet way AI regulation becomes a product constraint.
How Waiting For Clarity Creates Risk
A common leadership instinct is to wait until the rules are clearer. I understand the impulse. No one wants to over-correct or invest in compliance theater. But waiting usually costs more, because the build becomes harder to change once momentum kicks in.
In practice, regulation shows up as product and architecture work you either plan for early or pay for later. The late-stage version of this looks like:
• A feature that now needs explainability, but the system was not designed to track decisions.
• A data pipeline that worked for training, but now needs consent, retention rules or audit trails.
• A workflow that assumed the AI is always right, but now needs human review and override mechanisms.
That is why AI regulation is not only policy. It changes what “good product” means. You end up making more defensible choices around what data you use and keep, what you log, how you version and monitor models, how you roll back behavior and how you communicate limits to users.
If those considerations are an afterthought, you end up with a product that feels impressive in a demo but brittle in the real world.
Asking The Right Questions
At some point, it became clear to me that regulation wasn’t the problem. Our uncertainty about it was.
My team stopped treating AI regulation like a final review. We treated it like a design constraint, similar to performance, privacy or security. Something you build around early because fixing it late is painful.
The shift should not be “build less AI.” It's “build AI you can stand behind.”
That means asking better questions during discovery and early architecture decisions: Can you explain this in plain language if a user asks? Can you audit it if a client needs proof? Can you override it if it starts behaving badly? Can you adjust it quickly if expectations change?
When those questions move upstream, the work actually gets smoother. Fewer surprises mid-build. Fewer late-stage rewrites. Better alignment with clients, because you are honest about tradeoffs early instead of improvising later.
The Leadership Shift
Let’s face it, AI regulation isn’t going away, and it won’t settle neatly. But waiting for perfect clarity is not a strategy. It’s a delay.
From my experience, the real cost of AI regulation is the hesitation that shows up too late in the build, not compliance. Regulation is not something you solve at the end. It’s something you design around from day one.
The companies that move forward are the ones that make product decisions they can defend, and they design systems flexible enough to adapt.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?