The EU AI Act Is Live. American Product Teams Are Not Off the Hook.

On August 2nd, 2026, the bulk of the EU AI Act takes effect. The instinct in a lot of American boardrooms is to scroll past the headline. That law is over there, our customers are over here, and the world keeps moving.

That instinct is wrong, or at least incomplete; the Act applies extraterritorially. If the output of your AI system touches a user in the EU, you’re in scope. And even for teams with no European footprint at all, the Act sketches the shape of regulation the US could eventually catch up to.

So the real question for a CIO right now is not whether to panic. It’s what changes today, and what stays the same regardless of which regulator is loudest this quarter.

Risk Doesn’t Just Concern the Tech. It’s About the Blast Radius.

The EU AI Act sorts AI into four buckets: unacceptable, high, limited, and minimal. That framing is useful, but it’s not how working developers actually evaluate a system. Steve Anderson, Principal Developer and AWS Architect at Slingshot, starts somewhere more practical: “What does the AI have access to? Can it write data? What data can it read? Does it have network access? What is your blast radius?”

Blast radius is the keyword. It collapses risk into something a team can actually answer in a planning meeting. A chatbot that summarizes public marketing pages has a small blast radius. An agent with write access to your CRM, your inbox, and your finance system has a very large one. The law cares regarding manipulation and public harm. The builder also has to care about what an unpredictable system can touch.

Doug Compton, Principal AI Developer at Slingshot, named the gap between those two lenses plainly: “The EU is looking at how AI could manipulate and mislead the public. That’s real, but you should also think about the security aspects. What data does it have access to, what could it do with that data.” Regulators are watching for harm to the public. Builders have to watch for harm the system can cause from the inside out. A CIO has to hold both at once.

Liability Follows the Logo, Not the Code

Most CIOs read about the EU AI Act’s liability and assume the vendor that built the system is on the hook; that’s not how the Act works. The Act defines a ‘provider’ as whoever places the AI system on the market under their own name or trademark. In a standard build engagement, the client, not the builder, is the one. If your brand is on the product, you are the provider, and the fines sit with you.

Doug Compton actually flagged this: “You should assume the risk goes on the client, the one publishing it out there,” he said. That doesn’t let the builder off the hook entirely. 

Steve frames the builder’s real duty as a professional one: “There’s a due diligence and a moral responsibility to do what’s correct. There are industry standards you apply regardless of what the client asks for.” 

That standard is what a good builder owes you. It’s not, however, what the regulator enforces. The regulator enforces against the name on the product.

So the procurement conversation shifts in a useful way. The question isn’t whether your vendor is compliant; the question is what happens to you, the named provider, when something goes wrong.

Two things become worth asking out loud: how your contract handles indemnification and warranty for AI Act fines, and whether your builder is documenting data sources and testing in a form you can hand to a regulator.

AI Security Is a New Discipline, Whether You Call It That or Not

Ask whether AI security is a new field or just an extension of cybersecurity, and Doug’s answer is yes to both. “There is overlap, but a large section of it’s brand new because of AI. Prompt injection didn’t exist three years ago. Model poisoning, data poisoning, none of that was on the standard threat model.”

The Act names several AI-specific attack vectors that developers must handle: data poisoning, model poisoning, adversarial examples, and confidentiality attacks. The CIO’s takeaway isn’t that every standup needs to include these terms. The takeaway is that your security posture probably doesn’t yet account for them, and your vendor questionnaires probably don’t ask the right questions.

A few pragmatic implications follow. Your application security review needs an AI lane. Your threat modeling needs to treat the LLM as untrusted external input rather than as part of your trusted stack. And your incident response runbook needs entries for prompt injection and data exfiltration through model outputs. None of that is exotic work; it’s just work most teams haven’t done yet.

Human in the Loop Is a Design Decision, Not a Slogan

The AI Act gets specific about human monitoring for high-risk systems, requiring operators to understand the output, spot automation bias, override the system, and trigger a stop. That’s the regulatory floor. The product question is what oversight should look like even when the law doesn’t require it.

Steve set the bar simply: “An AI should not make an automated decision with business-critical impact. Just like you wouldn’t have a single human approver for those decisions, you shouldn’t have AI be a single approver either.” That’s a useful design principle for a CIO to enforce internally. Wherever the cost of being wrong is high, a human checkpoint stays in. The AI does the heavy lifting, surfaces the recommendation, and a person makes the decision.

Doug described how that plays out in Slingshot’s current work. “Most of what we are building right now is human-in-the-loop. The AI does the work behind the scenes, but we present the outcome to the person to accept, reject, or change. Down the road, when a product has a long history of behaving well, you might automate more of it. Right now, we want to be sure what it’s doing is sound.”

Steve put it more plainly: “I tend to treat AI like a person. People make mistakes, so you need to assume the AI will make mistakes, too.” The mental model that makes this stick is to treat AI like a capable junior developer. It performs well, but it makes mistakes. So put AI where mistakes are recoverable and keep a human on the final call.

Over time, as a system builds a track record, you can hand it more. But you earn that trust before you grant it, the same way you would with any new hire.

Documentation Is the New Source Code

The Act requires extensive documentation for high-risk systems, and most developers’ gut reaction is to groan. The interesting twist is that AI itself is already pulling documentation forward in the build process.

“AI-enabled development teams are creating more documentation now because the AI needs it to write the software in the first place,” Doug noted. “More effort is going into the front end, documenting how the system should work and all the edge cases around it. I’m seeing more documentation than we used to have.”

That is a quiet structural shift. Documentation used to be the last thing developers wrote, if at all. With AI-assisted development, teams must clearly document the spec, edge cases, and system intent so the AI can build against them. Regulatory paperwork requirements suddenly stop feeling like overhead and start feeling like the artifact you already needed.

If a CIO wants one durable habit to install before regulation tightens, it’s this one. Treat documentation as a first-class deliverable, not an afterthought. The teams already doing this will breeze through whatever audit shows up. The teams that aren’t will be reconstructing reasoning from Slack threads late at night.

Build for the Regulation You Cannot Yet See

The United States has no federal AI law. A handful of states are moving, but nothing close to the EU AI Act exists at the federal level, and the working assumption inside the industry is that nothing will for a while.

Doug put it bluntly: “For the next couple of years, the US will do nothing like this. It’d slow down innovation, and keep companies from progressing. I don’t see a law that even comes close to this happening here anytime soon.”

That’s realistic, not cynical. It’s also not an excuse to ignore the question. Three things are true at the same time: regulation will eventually come, AI products evolve faster than legislators can draft new rules, and the companies that suffer most under new regulation are the ones who treated their existing systems as finished.

So the practical move for a US CIO is not to compliance-proof everything against a law that doesn’t exist. It’s to design for the principles the EU is codifying, because those principles tend to outlast the specific statute.

Disclose AI use to your customers. Keep a human in the loop on consequential decisions. Document your data sources, your testing, and your assumptions. Treat your AI security posture as its own discipline. None of that requires a regulator to be reasonable.

Most of This Is Common Sense in a Suit

For all the four-tier risk framing and seven-figure fines, most of what the Act bans, good builders already refuse to build.

Doug’s read landed the takeaway cleanly: “Most normal business use for AI isn’t affected by a lot of what the act shows. As long as you’re doing it in the ‘don’t-be-evil’ way of doing things, the worst thing you’ll have to do is make sure you’re publicizing that you’re using AI in your chatbots. It’s about disclosure at that point.”

Steve put it more bluntly: “Honestly, a lot of that legislation is just common sense. Don’t disguise an AI as a person. Don’t ship something you know is unsafe. Don’t manipulate the people using your product. If you’re already building that way, the Act mostly just asks you to write it down and disclose when AI is in the loop.”

That’s the through-line a CIO should hold onto. The Act is not a foreign rulebook descending on American teams. It’s a written version of the line careful builders already hold. The teams that should worry are the ones who would have been worth worrying about anyway.

The Quiet Compliance Project Is Already Underway

The EU AI Act will not ensnare most American product teams in 2026. That’s the honest read. The Act mostly codifies what careful builders already do, and the worst-case scenario for most teams is a disclosure requirement and a documentation lift.

But the Act is doing more than enforcement. It is naming the practices that will define mature AI development for the next decade. Blast-radius thinking. Builder accountability. AI security as its own discipline. Real human control. Documentation as a deliverable.

The teams that internalize those habits now will look up in three years and realize they have already done the work everyone else is scrambling to start. There is no revolutionary ethics here. Build things that respect the people using them. Disclose when AI is in the loop. Catch the mistakes before they catch you.

The regulator might not be in the room yet. But the next builder you compete with will be.

Slingshot