Regulation used to be a slide in the investor deck. Now it's a line item in your sprint plan. The EU AI Act is phasing in on a real timetable, the United States is running a patchwork of executive action, state laws and procurement rules, and China keeps its own regime evolving. If you ship models or ship on top of models, here's the practical version of what matters right now — with the caveat that this is analysis, not legal advice.
The EU AI Act is real now, not theoretical
The Act entered into force in 2024 and its obligations phase in over time. The prohibitions on unacceptable-risk practices kicked in first, general-purpose model obligations followed, and the high-risk system requirements are the part that will land hardest for most product teams. Timelines have been debated in Brussels and there has been talk of adjusted dates and simplified guidance for smaller companies, so treat exact deadlines as fluid and check the official text before you plan a launch. The structure, though, is settled: risk tiers, obligations proportional to those tiers, and enforcement with actual teeth.
If your system touches hiring, credit, education, critical infrastructure, biometrics or law enforcement, you're probably in high-risk territory. That means a documented risk-management process, data governance, technical documentation, logging, human oversight, and conformity assessment before deployment. It is emphatically not a checkbox exercise you bolt on after launch.
General-purpose models: the GPAI tier
Frontier model providers carry their own obligations: technical documentation, training-content summaries, copyright compliance policies, and — for models above compute thresholds presumed to carry systemic risk — adversarial testing, incident reporting and cybersecurity measures. If you fine-tune an open model and ship it as your own product, talk to a lawyer about where you fall; open-weight doesn't mean obligation-free, though the Act does carve out more lenient treatment for genuinely open models in some respects. The details matter and they're moving.
For API consumers, the buck mostly stops upstream — your provider owes the GPAI obligations. But your deployer duties don't disappear: transparency to end users, human oversight, and monitoring. "The model vendor handles it" is not an answer a regulator will accept for a high-risk deployment you chose to run.
The US: no single law, lots of gravity
The US still has no comprehensive federal AI statute. What it has is a gravitational pull from several directions. A federal executive posture that has swung between safety-first and competition-first depending on the administration. State laws — Colorado's AI Act being the usual reference point — that impose duties around high-risk consequential decisions. Procurement rules: if you want government contracts, you'll meet AI requirements there first. And agency guidance, FTC enforcement on deceptive AI claims, and sector regulators (health, finance, housing) applying existing law to AI systems with increasing confidence.
The practical read: if you're compliant for the EU, you're 80% of the way to a defensible US posture. The remaining 20% is state-by-state paperwork, contract language, and not claiming your product does things it doesn't. The biggest US enforcement risk right now isn't a novel AI law — it's an old consumer-protection law applied to an overhyped demo.
Elsewhere on the map
China continues to iterate on its generative AI and algorithm rules, with filing requirements and content obligations that foreign builders rarely encounter directly but should know exist. The UK is keeping its principles-based, sector-regulator approach and hosting plenty of AI safety work while legislating cautiously. Canada, Japan, Korea and Brazil all have frameworks at various stages. None of this is a reason to panic; it is a reason to keep one person, or one fractional expert, watching the map.
Where the risk actually concentrates
Most AI deployments are minimal-risk and will stay that way: spam filtering, draft assistance, internal summarization, developer tooling. The anxiety in the press is wildly out of proportion to where the enforcement and the harms actually live. The genuine hot zones are decisions with legal or physical consequences: who gets hired, who gets credit, who receives medical triage, who gets surveilled, who gets a loan. If your product does any of those, you should assume a regulator or a plaintiff's lawyer will eventually read your documentation, your logs and your eval reports. Write them accordingly.
A quieter risk is procurement creep. Even if you never touch a regulated use case, your enterprise customers will push AI obligations into contracts — indemnities, audit rights, "the AI did what" liability clauses. Sales deals now include security review questionnaires with AI sections. If legal hasn't seen your model card and your data-flow diagram, the deal will stall there. Building the documentation once and reusing it is far cheaper than scrambling per deal.
Contracts are compliance too
Half the "regulation" builders will feel arrives as contract language, not statute. Enterprise customers now demand AI-specific terms: no training on their data, breach notification within hours, audit rights over your subprocessors, explicit liability allocation if the model output causes damage, and termination assistance if they want out. Model-vendor agreements often contradict what your customer wants, and you're stuck in the middle. Get your standard DPA and MSA templates updated before a deal forces the issue mid-negotiation. Cheap to do once; painful to do at 11 p.m. with a signature deadline.
What enforcement looks like in practice
Strip away the headlines and enforcement is mostly unglamorous: someone asks for your technical documentation and you can't produce it; someone audits your high-risk hiring tool and finds no human oversight log; someone claims your chatbot pretended to be a human or gave dangerously confident advice. Regulators tend to start with the boring, provable violations because those are the easy wins. The companies that get burned are usually not evil — they're just undocumented. The fix is procedural, not moral: inventory, classification, logging, review. Nothing in that list requires a bigger model or a bigger budget, just adult supervision.
Sector regulators are the real sheriffs
General AI rules get the press, but the day-to-day risk lives in the sector regulators applying existing law to AI-shaped products. Health agencies asking how your clinical decision tool was validated. Financial regulators expecting model risk management for credit and trading models, which is an older and stricter discipline than anything in the AI Act. Housing regulators scrutinizing tenant screening. Employment agencies probing automated hiring. If you operate in any of those sectors, the binding text was often written before transformers existed and applies anyway — algorithmic accountability baked into consumer-credit, fair-lending and consumer-protection doctrine. The right move is to loop in the counsel who already knows your sector, not just the generalist "AI lawyer" of Instagram threads. They'll ask for validation studies, monitoring plans and human-escalation paths, and they'll be right to.
Provenance and training data: the quiet audit
The regulatory frontier nobody wants to think about is training data. Lawsuits and regulator inquiries are converging on a simple question: can you show what went into your model and under what rights? If you fine-tune on client data, licensed corpora or web scrapes, keep a provenance file — sources, licenses, consent records, filter decisions and dates. It sounds bureaucratic until a customer's counsel asks for exactly that document during procurement, or a regulator does. The teams with a clean provenance file breeze through; the teams reconstructing it from Slack archaeology lose the deal or the audit.
For most product teams, this is about hygiene, not guilt: know which public datasets you used, which licenses they carry, what your vendor contracts say about their training data, and where the outputs flow. Open-weight models help here — inspectable model cards and published data summaries are a genuine compliance asset, not just an open-source nicety. And if you ever use synthetic data to patch gaps, document the generator, the seed prompts and the review process. Regulators are learning this vocabulary, which means your customers will too — sooner rather than later.
Start small: one provenance document per model or fine-tune, updated on every training run. Fifteen minutes now, months of scrambling avoided later.
A note on open models and compliance
Running an open-weights model locally genuinely simplifies some things — your data stays put, your stack is inspectable — and complicates others, because you may inherit obligations the original model provider handled. Fine-tuning makes you a modifier, and depending on your use case and jurisdiction, that can shift who's accountable for what. The Act's treatment of open models is more lenient in several respects, but "it's open source" is not a force field against deployer duties. Read the license, log your fine-tunes, and keep the eval evidence either way.
What to actually do
- Inventory your AI systems. You can't comply with a tier system you haven't mapped. Most teams discover three shadow AI features they forgot about.
- Classify against the EU tiers. Prohibited, high-risk, limited-risk, minimal. Write the classification down; regulators love written reasoning.
- Document the boring parts. Data sources, eval results, human oversight design, incident logging. Boring paperwork is the whole game.
- Transparency by default. Tell users when they're talking to AI, label generated content where feasible, and give humans a real off-switch.
- Contracts with your model vendors. Know what they owe you on data, incidents and GPAI compliance — before the incident.
- Review quarterly. This space moves; a compliance doc older than six months is a draft, not a policy.
My honest take
The regulation is mostly reasonable people trying to make software accountable, implemented by people who don't always understand the software. Compliance theatre is real, but so is the genuine harm in high-risk deployments. The builders who'll feel this least are the ones who already do logging, evals and human oversight because they're good engineers — not because a PDF told them to.
One last thing: keep your receipts. Regulators and enterprise auditors both respond to the same evidence — dated eval reports, incident logs, oversight decisions, training summaries. A company that can produce that file in an afternoon looks trustworthy regardless of what the rulebook says this quarter. A company that can't is one bad week away from a consent decree or a dropped deal.
Don't wait for a final, stable rulebook. It isn't coming. Build the compliance muscle now, keep it proportionate, and spend your energy on the parts that actually protect users. That tends to be the same work that makes products better anyway.