DEV Community: Damir

AI Should Explain Technical Validation, Not Invent It

Damir — Fri, 29 May 2026 14:09:39 +0000

Modern AI tools are becoming very good at producing plausible answers. That is useful in many contexts, but it becomes dangerous when we move into technical validation: CAD layouts, BIM models, engineering specifications, compliance checks, safety constraints, or any workflow where the answer must be correct for a defined reason.

In these environments, the question is not simply:

“Can the AI answer?”

The better question is:

“What is the source of truth, and can the system explain it?”

That distinction matters. If we allow an LLM to freely decide whether a technical system is valid, we are giving a probabilistic language model responsibility for something that should often be handled by deterministic logic. The better architecture is different: let deterministic rules validate the system, then let AI explain the result.

The problem with free-form AI validation

A typical AI chatbot is optimized to be helpful. If you ask it whether something looks correct, it will often try to answer even when it does not have enough evidence. That behavior is useful for brainstorming, but risky for engineering workflows.

Imagine a system that reviews a warehouse layout, a building plan, or a BIM model. The user might ask:

“Does this layout comply with the required accessibility constraints?”

A free-form AI assistant may produce a confident answer based on partial context. It might infer missing information, smooth over uncertainty, or explain something that was never actually checked. That is not acceptable when the output affects design decisions.

In technical validation, “sounds right” is not enough. The system needs to know:

Which rule was checked?
Which object or element was evaluated?
What evidence supports the result?
Was the result pass, fail, or unknown?
What data was missing?
Which part was deterministic and which part was AI-generated?

Without this separation, AI explanations can become dangerous because they appear authoritative while hiding uncertainty.

Deterministic rules should be the source of truth

For technical validation, deterministic code should own the actual decision whenever possible.

That means rules should be implemented in a way that produces predictable outputs. For example:

if (door.width < requiredMinimumWidth) {
  return {
    status: "fail",
    rule: "MIN_DOOR_WIDTH",
    evidence: {
      actualWidth: door.width,
      requiredWidth: requiredMinimumWidth,
      doorId: door.id,
    },
  };
}

This kind of logic is not glamorous, but it is reliable. It gives us a clear reason for the result. It can be tested. It can be reviewed. It can be improved. Most importantly, it does not invent missing information.

The AI layer should not replace this logic. Instead, it should receive the structured result and explain it in a way that is useful to the user.

The rule engine says:

{
  "status": "fail",
  "rule": "MIN_DOOR_WIDTH",
  "actualWidth": 820,
  "requiredWidth": 900,
  "element": "Door D-14"
}

The AI explains:

Door D-14 does not meet the minimum required width. The detected width is 820 mm, while the required minimum is 900 mm. This means the opening is 80 mm too narrow and should be reviewed before the layout is accepted.

That is a much safer pattern.

The AI is not deciding truth.
The AI is translating verified evidence into a human-readable explanation.

The architecture pattern: rules first, AI second

The pattern I prefer looks like this:

Technical model / document / structured data
        ↓
Normalization layer
        ↓
Deterministic validation engine
        ↓
Evidence object
        ↓
AI explanation layer
        ↓
User-facing explanation

Each layer has a clear responsibility.

The normalization layer turns messy input into a consistent internal structure. In CAD/BIM-style workflows, this could mean converting Revit or AutoCAD-related data into a simpler JSON representation: levels, rooms, doors, zones, measurements, constraints, and relationships.

The deterministic validation engine checks explicit rules. It does not guess. It returns pass, fail, or unknown.

The evidence object stores the reason behind the result. This is crucial. If there is no evidence, the AI should not be allowed to pretend that there is.

The AI explanation layer receives only the validated context. Its job is to explain, summarize, translate, and guide. It should not silently create new facts.

Unknown should remain unknown

One of the most important states in AI-assisted technical systems is:

“Unknown”

Many systems only think in terms of pass or fail. But in real workflows, missing data is common.

A model may not contain a required measurement. A document may not specify a threshold. A layout may be incomplete. In those cases, the correct answer is not a confident pass or fail. The correct answer is:

“The system cannot determine this from the available evidence.”

This is where AI needs strong constraints. It should not fill the gap just because the user expects an answer.

For example:

{
  "status": "unknown",
  "rule": "EMERGENCY_EXIT_DISTANCE",
  "reason": "Missing travel distance data",
  "requiredEvidence": ["exit location", "path distance", "room occupancy"]
}

The AI can then explain:

This requirement cannot be validated because the model does not include enough information about travel distance to the emergency exit. To complete the check, the system needs the exit location, path distance, and room occupancy data.

That is much better than hallucinating a compliance result.

A trustworthy AI system should be comfortable saying:

“I do not know based on the available data.”

Why this matters for CAD, BIM, and engineering workflows

CAD and BIM workflows are built around structured technical information. They are not just drawings or visuals. They contain relationships, constraints, dimensions, layers, objects, spaces, and specifications.

That makes them a strong fit for AI-assisted workflows, but only if the architecture respects the nature of the data.

A good AI assistant in this context should not behave like a generic chatbot. It should behave more like a technical reviewer:

grounded in model facts
aware of constraints
clear about missing information
able to explain validation results
unable to invent unchecked conclusions

For architects, engineers, and design teams, this distinction is important. They do not need an AI that confidently says “looks good.” They need a system that can say:

“This passes because these three constraints were satisfied.”

or:

“This fails because this measurement is below the required threshold.”

or:

“This cannot be validated because the model is missing this data.”

That is where AI becomes useful: not as a replacement for engineering judgment, but as an interface for understanding structured validation.

A small prototype: AI-assisted spec validation

I recently built a small prototype to explore this idea: an AI-assisted specification validator.

The goal was not to build a full production CAD or Revit integration. The goal was to test an architectural pattern:

deterministic validation first, AI explanation second.

The prototype works with structured technical input and produces validation results based on explicit rules. The AI assistant can then explain those results, but only within the available evidence.

The key principles were:

The rule engine is the source of truth.
AI explains results; it does not create them.
Missing data produces an unknown state.
Outputs should be structured and reviewable.
The user should be able to trace why a result was produced.

This is the same mindset I believe should apply to many AI systems in technical domains: compliance, security questionnaires, CAD/BIM validation, document analysis, and engineering review.

Where LLMs are useful

This does not mean LLMs are not valuable. They are extremely useful when used in the right layer.

LLMs are strong at:

explaining technical results in plain language
summarizing complex evidence
mapping user questions to relevant checks
translating domain terminology
helping users understand what to fix
generating structured drafts from verified context
guiding users through incomplete information

They are weaker at:

being the source of truth
guaranteeing correctness
performing hidden validation without evidence
knowing when data is missing unless explicitly constrained
maintaining consistency without structured inputs and guardrails

So the question should not be:

“Can AI validate this?”

The better question is:

“Which parts should be deterministic, and which parts should AI explain?”

That framing leads to better systems.

Testing matters more than demos

A demo can look impressive even if the underlying system is fragile. That is especially true with AI. A model can produce one excellent answer during a demo and fail silently in edge cases.

For technical validation systems, testing needs to cover both deterministic logic and AI behavior.

The deterministic layer should have normal unit and integration tests:

does the rule pass when the data is valid?
does it fail when the measurement is below the threshold?
does it return unknown when required evidence is missing?
are edge cases handled correctly?

The AI layer needs a different kind of evaluation:

does the explanation stay within the evidence?
does it avoid adding unsupported claims?
does it clearly communicate uncertainty?
does it preserve the correct rule status?
does it help the user understand the next action?

The AI output is not just a text response. It is part of the user’s decision-making process. That means it needs to be evaluated carefully.

The practical takeaway

In technical workflows, AI should not be treated as a magical reasoning engine that replaces deterministic validation.

A better pattern is:

Use code for truth.
Use AI for explanation.
Use evidence as the boundary.

That architecture is less flashy than a fully autonomous agent, but it is much more trustworthy.

If a deterministic rule can check something reliably, let code check it. If the result needs to be explained, translated, summarized, or made useful to a human, let AI help.

The future of AI in engineering will not be built only on more powerful models. It will be built on better system design: clear boundaries, structured evidence, deterministic checks, and AI explanations that know what they are allowed to say.

AI should explain technical validation.

It should not invent it.

The EU AI Act is Here: A Pragmatic Compliance Checklist for Devs & SaaS Founders

Damir — Fri, 17 Apr 2026 16:40:33 +0000

TL;DR:

Building an AI wrapper or full-stack AI SaaS in 2026?

The EU AI Act doesn’t care what model you use.

It cares what your product does.

If your app touches hiring, finance, or critical decisions, you might already be deploying a High-Risk system.

Here’s the developer-focused checklist to stay compliant.

Let’s Skip the Legal Jargon

If you're building software in Europe (or for EU users), the EU AI Act is no longer theoretical.

It directly affects:

how you build
how you ship
how you document your AI features

The Biggest Misconception

Many developers think:

“I’m just calling OpenAI or Anthropic APIs — compliance is their problem.”

That’s dangerously wrong.

You are the deployer. The liability is yours.

The 7-Step Compliance Checklist

Run this before pushing your next AI feature to production.

1. What Does Your AI Actually Do?

Use case > model

The law regulates the application, not the model.

Markdown summarizer → nobody cares
Resume ranking tool → heavily regulated

If you don’t clearly define your AI’s behavior, you can’t design compliance properly.

2. Determine Your Risk Tier

The EU AI Act defines four categories:

🚫 Prohibited → Social scoring, biometric categorization
⚠️ High-Risk → Hiring, credit scoring, medical, education
👀 Limited Risk → Chatbots, deepfakes, generated content
✅ Minimal Risk → Everything else

👉 Your entire compliance strategy depends on this step.

3. UI/UX Transparency (Don’t Ghost the User)

If you fall into Limited Risk (most SaaS chatbots do):

You must clearly disclose AI usage.

Dev actions:

Add visible AI disclaimers in UI
Label generated content
Update Terms of Service

Don’t try to make your AI look human.

4. Architect Human-in-the-Loop (HITL)

For High-Risk systems, fully autonomous decisions are a red flag.

Dev actions:

Build admin dashboards
Allow human overrides
Track decision states

Your system must support human intervention at any point.

5. Technical Documentation (Beyond README.md)

High-risk systems require Annex IV documentation.

This is NOT:

your GitHub README
your API docs

This IS:

system architecture
data governance
risk management
evaluation & bias monitoring

If an enterprise asks for compliance docs and you send a Notion page, you lose the deal.

6. Data Privacy & Vector DBs

The EU AI Act works closely with GDPR.

Dev actions:

sanitize prompts before sending to LLMs
avoid sending PII to third-party APIs
define how data is stored in vector DBs (Pinecone, pgvector, etc.)

Privacy by design is not optional.

7. Logging, Observability & Audit Trails

For regulated systems:

“It’s a black box” is not a legal defense.

Dev actions:

log prompts + responses
track retrieved context (RAG pipelines)
store decisions securely

You must be able to explain:

👉 why the AI made a decision

⚠️ The Real Risk: Feature Creep

This is where most teams fail.

You start with:

internal chatbot → minimal risk

Then you add:

employee evaluation → suddenly high-risk

One merged PR can change your entire legal classification.

Quick Self-Check

Ask yourself:

Does my system influence hiring?
Does it impact finances?
Does it affect user rights?

If yes:

👉 You may already be in High-Risk territory

Need a Quick Sanity Check?

Reading legal docs is great for insomnia, terrible for shipping.

So I built a simple tool:

👉 https://www.complianceradar.dev

It gives you:

risk classification
compliance signal
in under 60 seconds

No signup required.

Final Thought

Most AI products won’t fail because of bad code.

They’ll fail because of misunderstood regulation.

Understand your risk early — and build with confidence.

💬 What are you building with AI right now?

Drop your use case below — I’ll help you classify it.

Is your AI wrapper a "High-Risk" system? (A dev's guide to the EU AI Act)

Damir — Wed, 08 Apr 2026 18:29:21 +0000

If you're building AI features right now, you and your team are probably arguing about the tech stack:

Should we use LangChain or LlamaIndex?
Should we hit the OpenAI API or run Llama 3 locally?

Here is the harsh truth about the upcoming EU AI Act:

Regulators do not care about your tech stack.

They don’t care if it’s a 100B parameter model or a simple Python script using scikit-learn.

The law only cares about one thing:

Your use case.

Why This Matters

Your use case determines your risk category.

If your product falls into the High-Risk category, you are legally required to implement:

human oversight
risk management systems
detailed technical documentation (Annex IV)

Getting this wrong doesn’t just mean “non-compliance”.

It means:

failed procurement audits
blocked enterprise deals
serious regulatory exposure

🔍 5 Real-World AI Scenarios

Here are practical examples to help you understand where your system might fall.

1. AI Chatbot for Customer Support

Use case:

routing tickets
answering FAQs

Classification:

👉 Limited Risk

Dev requirement:

Add UI elements disclosing that users are interacting with AI.

The trap:

If your bot starts making decisions (e.g. auto-refunds, banning users), you might cross into High-Risk territory.

2. AI for CV Screening / Hiring

Use case:

parsing resumes
ranking candidates

Classification:

👉 High-Risk (explicitly listed under Annex III)

Dev requirement:

bias monitoring
human-in-the-loop (HITL) flows
full decision logging

3. E-commerce Recommendation Engine

Use case:

tracking user behavior
suggesting products

Classification:

👉 Minimal Risk

Dev requirement:

Almost none under the AI Act (GDPR still applies).

4. AI Credit Scoring System

Use case:

determining loan eligibility

Classification:

👉 High-Risk

Dev requirement:

Full traceability — you must be able to explain decisions made by the system.

5. AI Generating Marketing Content

Use case:

generating blog posts
writing ad copy

Classification:

👉 Minimal to Limited Risk

Dev requirement:

Minimal — unless generating deepfakes (then disclosure/watermarking applies).

🛠️ The Real Risk: Feature Creep

The biggest danger isn’t writing documentation.

It’s this:

Your system can move from Limited Risk to High-Risk with a single merged PR.

A small feature change can completely change your regulatory obligations.

Quick Self-Check

If you’re targeting the EU market, ask yourself:

Does my system influence hiring decisions?
Does it impact financial outcomes?
Does it affect people’s rights or opportunities?

If yes:

👉 You may already be in High-Risk territory.

🧪 A Simple Way to Check

If you're not sure, I built a free developer tool to calculate this instantly:

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

No signup required.

Final Thought

Most AI products won’t fail because of bad code.

They’ll fail because of misunderstood regulation.

Understand your risk level early — and build with confidence.

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

Drop your use case below and we can try to classify it together.

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