Product with Attitude

Product with Attitude

Are You a Vibe Coder? Don’t Ship Straight Into the Provider Trap

For my fellow builders: go compliance-native before 2 August 2026.

Karo (Product with Attitude)'s avatar
Karo (Product with Attitude)
Apr 29, 2026
∙ Paid
TL;DR: The EU AI Act is in force, and the high-risk obligations under Annex III apply on 2 August 2026. If you wrap Claude 4.7, GPT-5.5, or Gemini 3.1 Pro in your own UI and sell it under your brand, you are the provider under Article 3(3), not the deployer. Compliance-native building means designing AI products so classification, documentation, transparency, logging, and testing are built into the product workflow from day one. This piece gives you the provider trap, the dates that matter, the founder penalty math, and a 30-minute checklist.
EU AI Act compliance timeline for builders — 1 Aug 2024, 2 Feb 2025, 2 Aug 2025 passed; 2 Aug 2026 high-risk Annex III deadline; 2 Dec 2027 and 2 Aug 2028 might move.

Thousands of builders wrapped a frontier model in their own UI, added a logo, and started selling subscriptions.

With vibe coding, all of that can happen in a day.

If you’re one of these builders, Article 3(3) of the EU AI Act made you the provider that day.

OpenAI, Anthropic, or Google still remain responsible for the general-purpose AI model they created. But you became responsible for the product you built on top of that model. And if your use case touched Annex III, you inherited every high-risk obligation in the regulation.

That’s the provider trap.

Builders, indie founders, and vibe coders are shipping fast, scaling faster, and stepping into the provider trap before they know it exists.

The way out is what I started calling compliance-native building.

EU AI Act compliance timeline showing 2 August 2026 high-risk AI deadline under Annex III, plus penalty tiers up to €35M or 7% revenue with Article 99 SMB caps.
Section divider

Hey, I’m Karo Zieminski 🤗

I ship physical AI products at a named company in Europe, I build indie products on the side, I live under EU AI Act compliance, I parent AI-native kids, and I write about critical AI literacy for 18,000 people.

If you’re new here, welcome! Here’s what you might have missed:
→ The Only AI Prompting Guide That Works On Reasoning Models (And Our Cognition)

→ Is GPT-5.5 Reliable For Citations? No. It’s The Worst Flagship For That Job

SUBSCRIBE

Section divider

What’s Inside

  • What compliance-native building means.

  • Why it beats compliance-by-design.

  • The provider trap, broken down with the exact chat-wrapper scenario.

  • A decision tree for am I in scope and at what risk tier.

  • The dates that already passed, the date that matters, and the proposal that might move it.

  • Penalties translated for founders.

  • A 30-minute checklist for builders.

Transparent divider.

Compliance-Native Building, Defined

Compliance-native building means designing AI products so classification, documentation, transparency, logging, and testing are built into the product workflow from day one.

We had cloud-native. Then AI-native.

So when I needed a name for building regulation into the product itself, compliance-native made sense.

  • Cloud-native made software scalable.

  • AI-native made intelligence part of the product.

  • Compliance-native makes regulation part of the build.

Compliance-native building treats the EU AI Act as a system constraint, not a paperwork tax.

You don’t build the product, then add compliance on.
You build the product so compliance is the default behavior of the system.

Transparent divider.

What it isn’t

It’s not compliance-by-design. That phrase is the consultant pitch. It often means someone sells you a framework, a risk register, and a recurring meeting.

Useful for enterprises with legal teams. Useless if you’re a one-person startup with zero budget and your “legal department” is you and ChatGPT.

What it is

You bake five behaviors into the product. The behaviors are the compliance. You document them once. You log them by default.

  1. Classify first.
    Before you write code, decide what kind of AI system you are building: prohibited under Article 5, high-risk under Annex III, or limited-risk under Article 50. Write it down. Keep it in the repo.

  2. Document as code.
    Your technical documentation and conformity assessment should live where the product lives. Same repo, same version history, same review process as a pull request.

  3. Transparency by default. Always.
    Users should know when they are interacting with AI. If they’re talking to AI, or seeing AI-generated content, the interface should say so plainly.
    When the output is synthetic, Article 50 makes disclosure mandatory.

  4. Logging by default.

    For high-risk systems, every decision needs a record. Who asked. What model responded. What output was generated. What happened after. Article 12 makes automatic logging mandatory, so don’t leave it for “later.” Later is where compliance tasks go to become expensive.

  5. Sandbox first.

    Before you test high-risk behavior on real customers, use the regulatory sandbox. Article 57 requires each Member State to have at least one by 2 August 2026, with free priority access for SMEs.

These five behaviors are the compliance-native stack. The rest is documentation.

Transparent divider.

Share this with your vibe coder friend.

Share

Section divider

The Trap That Catches Most Builders

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2026 Karolina Zieminski · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture