Forem: Damir

The Developer’s Guide to the EU AI Act (What Actually Breaks Your Code)

Damir — Wed, 01 Apr 2026 12:51:18 +0000

If you're building AI features into your SaaS in 2026, you've probably heard the panic about the EU AI Act.

Lawyers are charging €300–€500/hour to explain it.

But let’s be honest:

Developers are the ones who actually have to implement compliance.

🧠 The moment it clicked for me

A few days ago, I was auditing a really well-built Node.js + Cloudflare app for a client.

From a product perspective, it was great:

fast
clean UI
solid architecture

But from a compliance standpoint?

It was a ticking time bomb.

🚨 The “innocent” P0 bug

During the audit, I noticed something small:

The app was storing Google OAuth tokens and sensitive user data.

The problem?

No encryption at rest.

In a normal startup MVP, you might think:

“We’ll fix it later.”

Under GDPR (Article 32) and the EU AI Act data governance requirements…

This is a P0 issue.

If your AI system processes that data — or if there’s a breach —

“we’re just a startup” is not a defense.

⚙️ The fix was easy (the problem wasn’t)

The engineering team fixed it in a few hours:

added AES-256 encryption to DB fields
updated access patterns

Simple.

But finding it before:

a regulator
or an enterprise client

…made all the difference.

📝 The real pain: Annex IV

If your system is classified as High-Risk under the EU AI Act…

You are legally required to produce technical documentation.

This is called:

Annex IV

What Annex IV actually means for developers

This is not “legal paperwork”.

It’s engineering documentation.

You need to describe:

your architecture and system components
data flows (training vs inference)
human oversight (Article 14)
logging and traceability

And here’s the catch:

Lawyers can’t write this for you.

They don’t know:

your DB schema
your API flows
your RAG pipeline

You do.

🛠️ How to not lose weeks on this

Instead of reading 300+ pages of regulation, here’s what actually works:

1. Use a real Annex IV template

Don’t start from scratch.

Use a structure that maps directly to the regulation.

I put together a developer-friendly template based on actual requirements:

👉 https://www.complianceradar.dev/annex-iv-template

It translates legal language into:

system sections
architecture blocks
engineering concepts

2. Audit your architecture early

Most teams do this too late.

They build → ship → then ask:

“Are we compliant?”

That’s backwards.

You should be checking:

before deployment
at architecture level

🔍 What to look for

Typical “P0 compliance bugs”:

unencrypted sensitive data
missing transparency
unclear system boundaries
no logging / traceability
no human oversight

⚡ Automate the first pass

If you want a quick baseline:

You can upload your architecture and get:

risk classification
compliance gaps
concrete fixes

👉 https://www.complianceradar.dev

💡 What I learned

The biggest mistake developers make is thinking:

compliance = legal problem

It’s not.

It’s an architecture problem.

And like any architecture problem:

if you catch it early → easy fix
if you catch it late → painful refactor

👇 Question for you

Are you checking compliance before you build…

Or after things are already in production?

We turned EU AI Act compliance into a marketing feature (and it changed everything)

Damir — Fri, 20 Mar 2026 11:28:01 +0000

Most developers treat compliance as a checkbox.

Something you deal with at the end.
Something legal handles.
Something you hope doesn’t block your launch.

I used to think the same.

Until I started building an AI SaaS for the EU market.

🛑 The problem: compliance kills momentum

While building ComplianceRadar (a tool that scans websites and AI systems for EU AI Act + GDPR risks), I kept running into the same issue:

Developers don’t understand the law
Lawyers are too slow and expensive
Teams only think about compliance after launch

By the time they realize something is wrong, it’s already too late.

They need to refactor architecture.
Rewrite flows.
Add missing controls.

It’s painful.

🧠 The shift: compliance is not a cost, it's a signal(!)

At some point, something clicked:

What if compliance isn’t just protection…

What if it’s positioning?

In the EU, trust is everything.

If you can prove your AI is compliant, you immediately:

reduce buyer friction
increase conversion
stand out from competitors

That’s not legal.

That’s marketing.

🔧 What we built

We decided to flip the model.

Instead of hiding compliance in PDFs and internal docs, we made it visible.

1. Pre-launch compliance (PDF scanning)

We added a feature that lets you upload your AI architecture (PDF) and detect risks before writing code.

→ No live product required

→ Annex IV alignment

→ instant feedback

This alone changed how teams think about compliance.

2. The public trust badge

Then we built something unexpected:

A compliance badge.

Something you can embed on your site that says:

“Audited via ComplianceRadar.dev”

Now compliance becomes:

visible
shareable
part of your product

🚀 The result

Instead of asking:

“Are we compliant?”

Teams now ask:

“How do we show that we are compliant?”

That’s a completely different mindset.

💡 What I learned

If you’re building an AI product for Europe:

Don’t treat compliance as a blocker
Don’t wait until after launch
Don’t hide it in documentation

Turn it into something your users can see.

Because in 2026:

Trust is a feature.

🔍 If you want to test this

I built a tool to help with this:

scan live apps
upload architecture (PDF)
generate compliance insights

👉 https://www.complianceradar.dev

I Almost Launched an "Illegal" AI SaaS Today. Here’s How I Fixed It (EU AI Act Guide).

Damir — Tue, 17 Mar 2026 12:47:09 +0000

Building an AI wrapper or SaaS in 2026 is easy.

Launching it legally in the EU? Not so much.

Today, I was doing final checks before launching my project, ComplianceRadar, a tool that scans websites for GDPR, ePrivacy, and EU AI Act issues.

Everything looked green:

clean code
Stripe fully integrated
security checks (including IDOR protection)
production-ready UI

I was ready to ship.

Then I did one last thing.

I ran my own tool… against my own website.

The Result

Score: 65/100

Wait… what?

The Problem

I was missing an AI Transparency Page.

Which means:

I was building a compliance tool… that was technically not compliant.

Specifically, I hadn’t fully addressed transparency expectations for AI deployers under the EU AI Act.

So I did something most developers hate:

Code freeze.

I paused the launch and spent the morning fixing it properly.

The Misconception

A lot of developers think:

“AI transparency means open-sourcing your code or exposing your prompts.”

That’s not true.

You can be compliant without exposing your secret sauce.

Here’s what actually matters.

What You Actually Need to Document

1. Model Architecture & API Usage

Don’t hide what you’re using.

In my case:

Google Gemini 2.5 Flash
via a secure Enterprise API

Why this matters:

B2B clients want to know you’re not running a random open-source model on an unprotected server.

2. The “Zero Data Retention” Guarantee

This is one of the strongest trust signals you can have.

I explicitly documented that:

user inputs (URLs + extracted content) are processed ephemerally
no customer data is used to train models

This is possible because of enterprise API guarantees.

3. Prompt Governance (Technical Guardrails)

I didn’t expose my prompts.

But I documented how the system is controlled.

For example:

forcing strict application/json outputs
limiting free-form responses
treating the model as a structured scoring engine

This reduces hallucination risk and improves determinism.

4. Human-in-the-Loop Disclaimer

This one is critical.

AI is not perfect.

So I clearly state:

The system is an assistive co-pilot, not a replacement for professional advice.

This is both:

a compliance requirement
a liability safeguard

The Result (After Fixing It)

✅ SaaS launched
✅ Transparency implemented
✅ Compliance improved
✅ Trust factor increased significantly

Final Thought

If you’re building AI tools for the European market:

Don’t just build fast, build compliant.

The hardest part isn’t writing code.

It’s understanding what your system is allowed to do.

Want to See It in Production?

I made the transparency page public:

👉 https://www.complianceradar.dev/ai-transparency

You can also scan your own site and see how your system performs.

Is Your AI App High-Risk? A Simple EU AI Act Guide for Developers

Damir — Mon, 16 Mar 2026 14:14:52 +0000

If you're building an AI wrapper, a chatbot, or integrating LLMs into your SaaS right now, you've probably heard about the EU AI Act.

It's the world's first comprehensive AI regulation.

And yes, it applies to you even if your servers are in the US but your users are in the EU.

The problem?

Most developers and indie hackers have no idea where their product falls under this law.

We're used to writing code, not reading 300-page legal documents.

But getting this wrong can become an expensive mistake.

So here's a simple, developer-friendly breakdown of how to classify your AI product.

🔺 The Risk Pyramid: Where Do You Belong?

The EU AI Act doesn't care about how your AI works.

It doesn't matter if you're using:

GPT-4
Claude
Llama
a custom model

What the law actually cares about is the use case.

In other words:

What is your AI being used for?

The Act divides AI systems into four categories.

🚫 Prohibited AI (Banned)

These systems are outright illegal.

Examples include:

social scoring systems
biometric manipulation
AI exploiting vulnerable populations

If you are building something in this category…

You should probably stop.

⚠️ High-Risk AI (Heavy Compliance)

This is where things get serious.

Typical examples include AI used for:

CV screening or hiring decisions
credit scoring
medical devices
law enforcement

If your system falls here, compliance becomes a serious engineering task.

👀 Limited Risk (Transparency Rules)

This category includes things like:

chatbots
deepfake generators
emotion recognition systems

The main requirement here is simple:

Users must clearly know they are interacting with AI.

✅ Minimal Risk (Almost No Restrictions)

This is where most everyday AI lives.

Examples include:

spam filters
AI features in video games
recommendation engines
inventory prediction

If your system falls here, you're mostly free to build without heavy regulatory overhead.

⚙️ Why Risk Classification Matters (For Your Codebase)

If your app falls into the High-Risk category, things change dramatically.

You can't just deploy to production and move on.

The EU AI Act requires several architectural and operational changes.

Risk Management System

You must continuously test for:

bias
errors
unintended outcomes

Human Oversight

Your UI/UX must allow a human to intervene.

That could mean:

override mechanisms
manual review
emergency shutdown features

Logging & Traceability

Your infrastructure must keep clear logs of AI decisions.

Think:

inputs
outputs
model behavior
timestamps

Technical Documentation (Annex IV)

This is the scary one.

You must produce formal documentation describing your entire system.

Things like:

system architecture
training data description
evaluation procedures
risk management methods

🧩 The Hard Part: Understanding Annex III

Ironically, the hardest part of compliance isn't writing documentation.

It's figuring out whether your system is high-risk in the first place.

The rules (especially Annex III of the AI Act) are complicated.

For example:

A simple HR chatbot might be Limited Risk if it only answers FAQs.

But the moment it filters candidates based on resumes, it suddenly becomes High-Risk AI.

The boundary is extremely blurry.

🛠️ A Simple Self-Assessment Tool

I recently ran into this problem while auditing my own AI projects.

After spending hours reading legal documents, I got frustrated.

So I did what most developers would do.

I built a tool to automate the classification.

It's a simple EU AI Act Risk Classification Quiz.

It takes about 2 minutes and based on your use case it estimates which risk tier your AI system falls into.

🔗 Check your AI app's risk level here:

https://www.complianceradar.dev/ai-act-risk-classification

💡 Final Thought

When it comes to the EU AI Act, ignorance won't help you.

But the real difficulty isn't compliance itself.

It's understanding where your product sits on the risk pyramid.

Once you know your classification, the path forward becomes much clearer.

And then you can go back to doing what you do best:

building and shipping software.

💬 What kind of AI app are you building right now?

Drop your use-case in the comments and let's figure out your risk tier together.

SEO is Dead? How I Optimized My Next.js SaaS for ChatGPT & Perplexity (AEO)

Damir — Sat, 14 Mar 2026 07:27:29 +0000

Everyone is still playing the Google SEO game: stuffing keywords, buying backlinks, and fighting for Page 1.

But if you are building a B2B SaaS in 2026, your target audience (developers, founders, CTOs) has already changed their behavior.

They aren't Googling anymore.

They are asking:

ChatGPT
Perplexity
Claude
Google AI Mode

When I launched my micro-SaaS ComplianceRadar (an automated EU AI Act risk scanner), I realized something interesting:

Getting to the top of Google might take 6 months.

But getting cited by an LLM as an authoritative source can happen almost instantly if you structure your site correctly.

Welcome to AEO — AI Engine Optimization.

Here are the three things I implemented on day one to make my Next.js SaaS machine-readable for AI systems.

1. The Secret Weapon: `llms.txt`

Just like robots.txt tells search engines where to go, the new llms.txt concept helps AI agents understand what your company actually does.

AI crawlers like:

OpenAI's crawler
Anthropic crawlers
Perplexity indexing systems

prefer high-signal text over visual layout.

They don't care about your beautiful Tailwind gradients.

They want structured facts.

I created an llms.txt file and placed it in the public/ folder so it lives at:
complianceradar.dev/llms.txt

Example structure:

# ComplianceRadar

> Automated EU AI Act Risk Tier Classification for Developers

## Primary Services

- AI Risk Scanner: Analyzes an AI application's feature set and outputs a strict risk classification.
- Compliance Roadmaps: Technical and legal summaries based on Annex III.

## Target Audience

- Indie Hackers
- AI Startups
- Compliance Officers

## Trust & Methodology

The classification engine maps user inputs directly against the official text of the EU AI Act using a strict decision tree.

2. Injecting Heavy Structured Data (JSON-LD)

LLMs rely heavily on the semantic web.

Having an tag is nice.

But giving the AI a literal JSON object describing your product is much more powerful.

Inside my Next.js App Router, I injected JSON-LD schemas into core routes.

Main schemas used:

Organization

WebSite

SoftwareApplication

FAQPage

Example:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "ComplianceRadar",
  "applicationCategory": "BusinessApplication",
  "description": "Automated EU AI Act risk classification tool",
  "offers": {
    "@type": "Offer",
    "price": "29",
    "priceCurrency": "EUR"
  }
}

This explicitly tells AI systems:

what the product is

what category it belongs to

how it is priced

Structured data = AI-friendly content.

3. The "Authority Anchor" Technique (Official Citations)

Here is the biggest mistake founders make with content marketing:

They write great opinion pieces but provide zero hard sources.

LLMs are designed to prioritize authoritative and corroborated information.

If your blog post says:

EU AI Act fines are 7% of global revenue

without linking to a primary source, an AI model may ignore it.

To fix this, I added explicit outbound links to primary legal sources.

For example:

official EU law documentation
EUR-Lex legislation pages
regulatory summaries

By doing this, the article becomes a bridge between complex legislation and developer-friendly explanations.

This signals to AI systems:

This source is aggregating verified regulatory information.

And that increases the chances of being cited.

The Result

Building an interactive SaaS is only half of the battle.

The other half is distribution.

By implementing:

llms.txt
structured JSON-LD
authoritative citations

ComplianceRadar is no longer just waiting for Google indexing.

It is actively feeding structured, trustworthy data into the AI models developers use every day.

Final Thought

If you are building a SaaS in 2026, especially for developers:

Stop optimizing only for Google.

Start optimizing for the machines your users are actually talking to.

Try the Scanner

If you're building an AI feature and want to understand potential regulatory risks under the EU AI Act, you can try my free scanner here:

ComplianceRadar

Forem: Damir

The Developer’s Guide to the EU AI Act (What Actually Breaks Your Code)

🧠 The moment it clicked for me

🚨 The “innocent” P0 bug

⚙️ The fix was easy (the problem wasn’t)

📝 The real pain: Annex IV

What Annex IV actually means for developers

🛠️ How to not lose weeks on this

1. Use a real Annex IV template

2. Audit your architecture early

🔍 What to look for

⚡ Automate the first pass

💡 What I learned

👇 Question for you

We turned EU AI Act compliance into a marketing feature (and it changed everything)

🛑 The problem: compliance kills momentum

🧠 The shift: compliance is not a cost, it's a signal(!)

🔧 What we built

1. Pre-launch compliance (PDF scanning)

2. The public trust badge

🚀 The result

💡 What I learned

🔍 If you want to test this

I Almost Launched an "Illegal" AI SaaS Today. Here’s How I Fixed It (EU AI Act Guide).

The Result

The Problem

The Misconception

What You Actually Need to Document

1. Model Architecture & API Usage

2. The “Zero Data Retention” Guarantee

3. Prompt Governance (Technical Guardrails)

4. Human-in-the-Loop Disclaimer

The Result (After Fixing It)

Final Thought

Want to See It in Production?

Is Your AI App High-Risk? A Simple EU AI Act Guide for Developers

🔺 The Risk Pyramid: Where Do You Belong?

🚫 Prohibited AI (Banned)

⚠️ High-Risk AI (Heavy Compliance)

👀 Limited Risk (Transparency Rules)

✅ Minimal Risk (Almost No Restrictions)

⚙️ Why Risk Classification Matters (For Your Codebase)

Risk Management System

Human Oversight

Logging & Traceability

Technical Documentation (Annex IV)

🧩 The Hard Part: Understanding Annex III

🛠️ A Simple Self-Assessment Tool

💡 Final Thought

SEO is Dead? How I Optimized My Next.js SaaS for ChatGPT & Perplexity (AEO)

1. The Secret Weapon: llms.txt

2. Injecting Heavy Structured Data (JSON-LD)

3. The "Authority Anchor" Technique (Official Citations)

The Result

Final Thought

Try the Scanner

1. The Secret Weapon: `llms.txt`