Twenty-nine states. No federal law. That’s the number a tech-insider.org piece put on America’s AI regulation situation, and it’s the number I keep coming back to every time I sit down to ship something.
I build bots. That’s the job. I write the retrieval layer, tune the prompts, wire up the tool calls, handle the edge cases where a model confidently invents a refund policy that never existed. Regulation used to feel like somebody else’s department, filed under things lawyers worry about. It isn’t anymore, and the reason is arithmetic. One national rulebook is a constraint. Twenty-nine of them is an architecture problem.
Why a Builder Should Care About a Patchwork
A law firm analysis from Spencer Fane framed the current moment as models moving faster than the rules. From where I sit, that gap doesn’t show up as abstract policy tension. It shows up as questions I can’t answer during a client call.
Say you’re building a customer support bot that will be used by people in every state. Reasonable questions follow immediately. Do you have to disclose that the user is talking to a machine? Do you need consent before the conversation gets logged for fine-tuning? What happens when the bot’s output affects a hiring decision, a loan, a housing application? Under a single federal standard, you answer once and encode it. Under a patchwork, the honest answer is “it depends where they’re sitting,” and that sentence has to become code.
Which means jurisdiction stops being metadata and becomes a routing decision. Disclosure text becomes configurable per region. Retention windows become variables instead of constants. Audit logging stops being a nice-to-have you add before a big enterprise deal and becomes the thing you build on day one, because you don’t yet know which of twenty-nine definitions of “automated decision” your feature will land under.
The Political Pressure Is Structural, Not Seasonal
ChinaTalk has been making the case that AI turns into a political crisis rather than staying a technical story, and that reframing matters for anyone shipping product. Technical debates get settled by benchmarks. Political ones get settled by whoever shows up. Carnegie Endowment for International Peace has published work on the labor question specifically, laying out three different views on the future of work — three, not one, which is itself the point. When serious analysts can’t converge on whether AI displaces workers, augments them, or does something messier, legislators aren’t going to converge either. They’ll each pick a view and write it into statute.
Carnegie has also been arguing for what it calls a compute coalition, an approach to building AI’s future among free-world countries. So the axis of disagreement isn’t only state-versus-federal. It’s also national-versus-international, and it involves the physical layer — chips, data centers, power. That’s a long way from my usual concerns about token limits and vector index freshness. It also directly determines what inference costs me next year.
What I’m Actually Changing in My Stack
I’m not going to pretend I’ve read twenty-nine statutes. I haven’t. But uncertainty of this shape has a known engineering response, and it’s the same one you use for any dependency you don’t control.
- Make policy a config layer, not a code path. Disclosure language, consent flows, retention rules — pull them out of the application logic and into something you can change without a deploy.
- Log decisions, not just outputs. Which model version, which retrieved documents, which system prompt. If anyone ever asks how a bot reached a conclusion, “we don’t store that” is a bad answer.
- Keep a human override on anything consequential. Hiring, credit, health, housing. Not because a specific law demands it today, but because every proposed framework I’ve seen gestures at it.
- Avoid single-vendor lock-in where you can. Compute policy is now geopolitics. Abstraction at the model layer is cheap insurance.
- Write down what your bot is for. A one-page statement of intended use and known limits costs an hour and answers half the questions a regulator or enterprise buyer will eventually ask.
None of that is exciting. All of it is cheaper to do now than to retrofit.
The Uncomfortable Part
The gap between model capability and rule-making isn’t going to close because someone asks nicely. Models ship on a cadence measured in months. Legislation moves in sessions and election cycles. That mismatch is permanent, structural, and unlikely to resolve in a direction that makes life simpler for people writing code.
So the practical stance for builders is neither waiting for clarity nor ignoring the whole thing. It’s designing systems where the rules can change underneath you without breaking what you shipped. That’s not a compliance mindset. It’s just good engineering applied to a dependency that happens to be written in legislative language instead of Python.
🕒 Published: