Navigating the EU AI Act: Risk Categories and Compliance for Founders. How the upcoming European regulations will impact AI-driven products.21 | Ultimate Guide For Startups

TL;DR: EU AI Act risk categories and compliance for founders

Table of Contents

Navigating the EU AI Act: Risk Categories and Compliance for Founders. How the upcoming European regulations will impact AI-driven products.21 explains how you can spot whether your startup’s AI is minimal, limited, high risk, or banned, so you avoid legal trouble, shorten buyer due diligence, and build trust earlier.

• Your biggest question is not whether you use AI, but whether your product affects jobs, education, health, finance, identity, safety, or public access. If it does, you may face much stricter duties under the EU AI Act.

• The article breaks down the four risk categories in plain language: unacceptable risk means banned uses, high risk brings heavy documentation and oversight duties, limited risk often means transparency rules, and minimal risk still leaves privacy, contract, and discrimination risks on the table. For a broader EU AI Act guide, see this linked resource.

• You get a founder-friendly checklist for classifying features, defining intended purpose, checking vendor exposure, adding real human oversight, and documenting data sources, limits, incidents, and model changes. If your tool wraps another vendor’s API, you still may carry duties. This high-risk AI requirements guide is also useful for sensitive sectors.

• The article’s main benefit is practical action: it gives you a 4-week and 12-week plan to map every AI feature, assign ownership, tighten sales claims, add review gates, and prepare a buyer-facing trust packet without freezing product work.

If you sell AI into Europe, read the full article and classify your features now before a customer, investor, or regulator does it for you.

Check out startup news that you might like:

You’re Not Scaling Content. You’re Scaling Disappointment

When your AI startup realizes the EU AI Act has more risk tiers than your pitch deck has revenue projections. Unsplash

Navigating the EU AI Act: Risk Categories and Compliance for Founders. How the upcoming European regulations will impact AI-driven products.21 starts with one uncomfortable truth: if your startup ships AI into Europe, the law will care less about your hype and more about your risk controls. The EU AI Act is the European Union’s legal framework for placing AI systems into risk buckets and attaching duties to each bucket, from banned uses to strict controls for high-risk systems. For startups, it matters because a product that feels like a harmless feature in a pitch deck can become a regulated system the moment it touches hiring, education, health, finance, identity, or public services.

I am writing this from the point of view of a bootstrapping European founder who has spent years building in deeptech, edtech, IP tooling, and AI-heavy startup systems. My bias is simple: compliance should live inside the workflow, not inside a panic-filled spreadsheet opened the night before procurement asks questions. Founders do not need more vague inspiration. They need infrastructure, plain language, and a way to decide fast whether a feature is low-risk, high-risk, or a very expensive mistake.

Why this matters for startups: the EU AI Act can shape your product scope, sales cycle, vendor choices, model documentation, and support burden long before a regulator ever contacts you. Unlike a pure growth-first approach, early AI governance can help you close enterprise deals, reduce legal exposure, and avoid rebuilding your product after launch.

How the EU AI Act risk categories affect startup products
Which founders face the highest exposure first
What to document before customers or investors ask
How to build a practical compliance plan without freezing product work

What is the EU AI Act, and why should founders care now?

The EU AI Act is a European regulation for AI systems that uses a risk-based model. It sorts uses of AI into categories such as unacceptable risk, high risk, limited risk, and minimal risk. The higher the risk to people’s rights, safety, or access to opportunities, the more duties the provider, deployer, importer, or distributor must carry.

For founders, the practical question is not “Do we use AI?” but “Where does our AI sit in the risk stack, and who is legally responsible for what?” A startup can be caught by the Act even when it uses third-party models, wraps another vendor’s API, or sells outside Europe but serves EU users. That reach is one reason many teams building cross-border products should also read the European startup playbook early, before product and go-to-market assumptions harden.

Here is why founders should care now. Enterprise buyers are already adding AI questionnaires into procurement. Hiring products are under scrutiny. Workplace AI creates bias and privacy exposure. And Europe is building a model where governance is part of market access, not a side topic. Europe’s AI strategy diverging from Silicon Valley captures this shift well: Europe is betting on trust, regulated sectors, and technical accountability.

What challenge do startups face with the EU AI Act?

The startup problem is not the text of the law alone. The real problem is ambiguity inside products. Founders often ship AI as a feature, not as a regulated system. A recommendation engine becomes a hiring screener. A chatbot becomes a health triage assistant. A productivity model starts ranking workers. The feature creeps into a higher-risk use case, and nobody updates the controls.

Research and reporting around AI in employment already point to where this gets painful. EU AI Act impacts on AI hiring standards shows how hiring systems are drawing attention because they directly affect people’s access to work. Separately, legal advisors keep warning companies that bias audits, risk reviews, and vendor oversight are becoming hard evidence of good-faith behavior, not nice extras. You can also see parallel pressure in the workplace through AI workplace bias and legal risk.

For founders, this creates four immediate pressures:

Limited team capacity because product, legal, and sales tasks land on the same people.
Fast feature release cycles that outpace policy and documentation.
Vendor dependence because many startups rely on foundation models, plug-ins, and external data tools.
Cross-border exposure because a startup outside the EU can still fall under EU rules if it targets or affects people in the EU.

That is why I keep repeating one founder rule: if your product touches people’s rights, jobs, money, health, identity, or safety, assume the law will eventually ask hard questions.

What are the EU AI Act risk categories founders need to know?

Let’s break it down. The EU AI Act is built around risk categories. This is the mental model every founder, product lead, and technical co-founder should know cold.

1. Unacceptable risk

These are uses the law bans because they are considered too harmful. The exact scope depends on the final legal text and guidance, but think of uses that manipulate behavior in harmful ways, exploit vulnerable groups, or enable certain forms of prohibited social scoring or biometric misuse.

Why founders care: if your product concept sits here, there is no “fix it later” strategy. You need to cut the use case, pivot the feature, or change the market.

2. High risk

This is the category that will hit founders hardest. High-risk AI includes systems used in areas such as employment, education, access to public or private services, certain safety components, law enforcement uses, migration contexts, and other domains where AI decisions can materially affect a person’s life chances.

Why it matters: high-risk systems face duties around risk management, data governance, technical documentation, record keeping, human oversight, transparency, accuracy, cyber controls, and post-market monitoring. If you pitch into HR, health, insurtech, fintech, proptech screening, or edtech scoring, stop assuming you are “just SaaS.”

3. Limited risk

These systems mainly trigger transparency duties. The classic examples are AI systems that interact with people, produce synthetic content, or create outputs that should not be mistaken for human-made or authentic material without disclosure.

Why it matters: many chatbot and generative AI products live here unless they cross into a high-risk domain. That does not make them “safe” in a business sense. Liability, privacy, and deceptive marketing risks can still pile up, as seen in chatbot tort and privacy risks.

4. Minimal risk

These are uses with low apparent harm under the Act, such as many internal productivity helpers or benign recommendation features. Minimal risk does not mean zero risk. It simply means the AI Act places fewer duties on that use case.

Why it matters: founders often confuse “minimal under the AI Act” with “safe under privacy, contract, IP, discrimination, or consumer law.” Those are not the same thing.

How do you tell whether your startup product is high risk?

Ask these questions in order. If you answer “yes” to any of them, your product deserves deeper legal and product review.

Does the system influence who gets hired, promoted, fired, or ranked at work?
Does it score students, shape admissions, or influence educational access?
Does it affect access to credit, insurance, housing, benefits, or other important services?
Does it process biometric data, identity checks, or emotion-related inference?
Does it support decisions in health, medical triage, or safety-sensitive contexts?
Does it sit inside a regulated sector where a wrong output can materially harm people?
Does it generate outputs that users may treat as authoritative without human review?

A simple founder shortcut is this: if the output can block a person from work, money, movement, care, education, or dignity, assume higher scrutiny.

In my own work across startup tooling and deeptech, I learned that teams fail when they classify systems by technical glamour instead of human consequence. Regulators care far more about consequence. A mediocre model in hiring can be more legally dangerous than a very advanced model that writes harmless internal summaries.

What are the main compliance duties for founders under the EU AI Act?

If your system is high risk, expect duties across the full product life cycle. Different actors have different duties, but founders should understand the whole chain because buyers will ask for answers even when some duties sit with a vendor upstream.

Risk management system that identifies, tests, and reduces foreseeable harms.
Data governance covering training, validation, and testing data quality, relevance, bias checks, and data provenance.
Technical documentation explaining intended purpose, system design, limitations, performance, and controls.
Logging and record keeping so important events and outputs can be traced.
Human oversight so people can review, intervene, and override where needed.
Accuracy and cyber safeguards appropriate to the intended use.
Instructions for use that explain proper setup, limits, and operator duties.
Post-market monitoring so issues found after launch feed back into fixes and reporting.

Founders also need to sort out their role. Are you the provider building and placing the AI system on the market, or a deployer using someone else’s system inside your company? If you modify another provider’s tool enough, you may pull more responsibility onto your own startup.

This is where privacy law and contract hygiene become tightly linked to the AI Act. If personal data is involved, you should already have your data map, lawful basis, retention logic, and vendor controls in order. If not, start with a GDPR compliance step-by-step guide and clean up your foundations before layering AI duties on top.

What are the fundamentals founders often miss?

Core concept 1: Intended purpose

Definition: intended purpose is the use you define for the AI system, including who uses it, for what task, and under what conditions. This sounds dry, but it shapes your legal exposure.

Why it matters for startups: if sales promises outrun product documentation, your real-world use case may become broader than your stated purpose. That can drag you into a tougher category.

Startup example: a founder sells a “candidate screening assistant” and claims humans make the final decision. In practice, recruiters auto-reject applicants based on the score. The system now carries much more weight than the product page admits.

Related terms: use case, deployer, provider, human review, decision support.

Core concept 2: Human oversight

Definition: human oversight means people can understand when the system matters, review outputs, and intervene before harm becomes automatic.

Why it matters for startups: many founders add a human checkbox and call it a day. Real oversight needs role design, escalation rules, training, and enough time for a person to disagree with the machine.

Startup example: an edtech platform flags students as “dropout risk.” A school counselor must see why the flag appears, what the model cannot know, and when to ignore it. Otherwise the human is decorative, not protective.

Related terms: override, review queue, false positives, decision support system.

Core concept 3: Data governance

Definition: data governance covers where data came from, whether it was appropriate for the task, how bias was checked, who had access, and how records are maintained.

Why it matters for startups: weak data discipline creates legal and commercial risk at the same time. You can lose deals, fail security review, and train bad outputs with the same sloppy pipeline.

Startup example: a B2B tool fine-tunes a model on customer support logs that contain personal and confidential data. Without proper vendor terms and data handling limits, the startup may create privacy and contract exposure in one move.

Related terms: training data, validation data, provenance, bias testing, retention schedule.

How can founders implement EU AI Act readiness step by step?

You do not need a giant legal department to get started. You do need discipline. Here is a practical 12-week plan built for startups.

Phase 1: Assessment and planning, weeks 1 to 2

Step 1.1: Audit your current AI use

List every AI feature, model, API, prompt chain, and automated decision path.
Mark whether each one is customer-facing, employee-facing, or internal only.
Note whether personal data, sensitive data, or biometric data is involved.
Identify who is affected by the output: applicant, employee, patient, student, buyer, child, citizen.
Map where human review exists and where it is fake or rushed.

Tools for this phase: a simple spreadsheet, your product map, vendor contracts, support logs, and call recordings from sales or onboarding.

Step 1.2: Define your risk position

Sort each feature into minimal, limited, high, or potentially prohibited use.
Write one sentence of intended purpose for each feature.
List legal unknowns and product unknowns separately.
Set a red flag rule for features that touch work, health, education, identity, or finance.

Step 1.3: Build internal ownership

Assign one founder or product lead as AI compliance owner.
Give engineering, sales, and support a shared vocabulary.
Ban unreviewed sales claims about fairness, accuracy, or autonomous decision-making.
Create one source of truth for policy, testing, and incidents.

Phase 2: Foundation building, weeks 3 to 6

Step 2.1: Choose your control structure

For early-stage startups, the control structure can be lean. You need an AI use register, a model card or system sheet for each material feature, a vendor review form, an incident log, and a release checklist. Keep it boring and usable.

Step 2.2: Set up your documentation baseline

Document intended purpose and known limits.
Write who should not use the system and for what.
Record what training or testing data was used and where it came from.
Define acceptable performance thresholds for the use case.
Set review rules for false positives, false negatives, and edge cases.

If outside vendors process data for you, tighten contracts now with a startup DPA guide. AI compliance falls apart fast when vendor roles, data use rights, and breach duties are fuzzy.

Step 2.3: Build human oversight into the product

Add review queues for sensitive outputs.
Show confidence signals and limitations where useful.
Create easy override and appeal paths.
Log when humans overrule outputs and why.
Train operators on when not to trust the system.

Phase 3: Testing, release, and scale, weeks 7 to 12

Step 3.1: Test on narrow scopes first

Launch first in one workflow, one region, or one customer segment.
Measure error patterns across groups if the use case affects people materially.
Document incidents, complaints, and override frequency.
Pause release if operators keep bypassing the controls.

Step 3.2: Create feedback loops

Weekly review of incidents and edge cases.
Monthly review of vendor changes and model updates.
Quarterly review of use-case drift.
Fast channel between support, legal, and product when harm signals appear.

My founder view is blunt here. Education must be experiential and slightly uncomfortable. The same is true for AI governance. If your team never rehearses failure, appeal requests, bad outputs, or customer audit questions, you do not have a real compliance habit. You have a policy graveyard.

What best practices actually work for founders in 2026?

Practice 1: Classify by human consequence, not by model type

What it is: judge the product by what happens to the person affected, not by whether you use a fancy model, rules engine, or prompt wrapper.

Why it works: legal exposure follows impact. A simple ranker used in hiring can create more risk than a large model used for harmless drafting.

List outputs that can affect rights, income, health, or access.
Rank them by harm if wrong.
Build the strongest controls around the top five first.

Common pitfall: teams focus on the model vendor’s marketing instead of their own use case.

How to avoid it: write a one-line “decision impact statement” for every material AI feature.

Metrics to track: override rate, complaint rate, appeal rate.

Practice 2: Treat transparency as a product feature

What it is: tell users when they interact with AI, what the system is for, and where its limits sit.

Why it works: clear notice reduces deception risk, sets expectations, and gives operators better judgment.

Add visible AI notices where the user interacts with the system.
Explain what data the system uses in plain language.
Offer a human channel when the matter is sensitive.

Common pitfall: burying AI disclosures in legal terms no user reads.

How to avoid it: place disclosures at the moment of interaction and decision.

Metrics to track: user confusion tickets, disclosure visibility rate, human-escalation rate.

Practice 3: Control vendors like they can sink your startup

What it is: review model vendors, data processors, plug-ins, and external tools as if their failure becomes your problem. Because it does.

Why it works: your customers will often blame your startup first, not the upstream provider.

Ask vendors about training data sources, logging, retention, changes, and security.
Get written terms on data use, incident notice, and audit support.
Recheck after major vendor model updates.

Common pitfall: founders assume the biggest vendor equals the safest vendor.

How to avoid it: keep a vendor risk sheet and update it quarterly.

Metrics to track: vendor review completion, contract coverage, incident response time.

Practice 4: Make compliance visible to buyers, invisible to users

What it is: keep the controls inside the workflow so the product behaves correctly by default, while buyer-facing proof lives in clear documentation.

Why it works: founders win when users are not forced to become junior lawyers. This principle shaped my work in IP-heavy deeptech too. Engineers should not need to study doctrine before they can behave safely inside a tool.

Build default guardrails into product flows.
Create a buyer packet with policy, testing summary, and data map.
Train support and sales to answer tough questions consistently.

Common pitfall: writing policy without changing the product.

How to avoid it: every policy control should map to one product behavior or one operating routine.

Metrics to track: security questionnaire pass rate, procurement cycle time, repeat buyer objections.

What mistakes do founders make with the EU AI Act?

Mistake 1: Assuming “we only use an API” means “the law is not about us”

Why founders make it: outsourcing the model feels like outsourcing the risk.

The impact: your startup can still carry duties based on how the system is configured, sold, and used.

Review your role in the chain: provider, deployer, distributor, importer.
Check whether your modifications change the legal picture.
Do not copy vendor claims into your own materials without verification.

Mistake 2: Treating hiring, scoring, and ranking as harmless automation

Why founders make it: ranking feels admin-heavy and neutral, but it often shapes life outcomes.

The impact: discrimination claims, buyer rejection, and higher scrutiny under EU rules.

Test for disparate effects where relevant.
Add human review that can genuinely change the result.
Document what the system should never be used to infer.

Mistake 3: Mixing AI law with privacy law and doing neither well

Why founders make it: the same data often sits under both issues, so teams blur the duties.

The impact: confused ownership, weak controls, and slow enterprise deals.

Separate your AI use register from your privacy records, but connect them.
Map what personal data enters each AI feature.
Review your public site notices too, including cookie consent compliance if tracking and profiling feed your product or analytics claims.

Mistake 4: Waiting for legal to fix product decisions after launch

Why founders make it: speed feels cheaper than caution.

The impact: retrofitting controls is usually slower, more expensive, and more humiliating in front of buyers.

Add one compliance check before release for sensitive AI features.
Run a pre-mortem on misuse and user harm.
Pause launches that cannot explain their intended purpose in one sentence.

Which metrics should founders track to measure AI compliance readiness?

Founders love growth dashboards. Good. Build one for AI risk too. If you do not measure the control system, you are guessing.

Foundational metrics to track first

Percentage of AI features classified by risk category
Percentage of AI features with documented intended purpose
Percentage of vendors reviewed for AI and data handling
Percentage of sensitive outputs with a human review path
Incident count and time to resolution
Override rate for human reviewers
Customer audit or procurement questions passed on first response

Advanced metrics after three months

Error rate by user group where fairness concerns apply
Appeal success rate
Model or prompt change frequency versus incident spikes
Average time from vendor change notice to internal review
Sales cycle delay caused by missing AI documentation

Dashboard elements:

Live view of classified systems
Trend view by week and month
Incident and complaint feed
Vendor review status
Document status for each high-risk or sensitive feature

Use whatever your team already trusts: Notion, Airtable, Linear, Jira, or a private dashboard in your analytics stack. The tool matters less than the routine.

How does the EU AI Act affect startups at different stages?

Pre-seed and seed stage

Your reality: tiny team, messy product scope, founder-led sales, little room for waste.

Keep an AI feature register from day one.
Avoid entering high-risk domains by accident through careless sales promises.
Use standard intake questions before adding AI to sensitive workflows.

Prioritize: classification, intended purpose, vendor checks, privacy basics.

Defer: heavy formalism that does not match your real risk level.

Success looks like: you can answer a buyer, accelerator, or early investor without bluffing.

Series A stage

Your reality: product-market fit may be emerging, sales motion is maturing, enterprise buyers ask harder questions.

Formalize documentation and buyer-facing AI policies.
Build incident handling and model change review.
Train sales, customer success, and product managers on approved claims.

Prioritize: human oversight, testing records, procurement readiness.

Defer: over-engineering low-risk internal tools.

Success looks like: AI questionnaires stop derailing deals.

Series B and beyond

Your reality: more products, more markets, more vendor sprawl, more exposure.

Standardize AI governance across business units.
Set thresholds for central review of risky use cases.
Run periodic audits and board-level reporting on AI use and incidents.

Prioritize: consistency, auditability, cross-border controls.

Defer: nothing that touches regulated sectors or vulnerable users.

Success looks like: the company can scale without every new AI feature becoming a legal improvisation exercise.

What should founders do in the next four weeks?

Week 1: Research and alignment

List every AI feature and vendor.
Mark any use touching jobs, health, education, finance, identity, or public access.
Review public claims on your site and sales decks.
Check country-specific legal exposure with a startup legal checklist by country if you sell across borders.

Week 2: Planning and resource check

Assign one owner for AI risk and documentation.
Decide which features need legal review first.
Create a simple template for intended purpose and known limits.
Collect all vendor terms in one folder.

Week 3: Build the first control layer

Add AI notices and human escalation paths where needed.
Write internal rules for sales claims.
Set a release gate for sensitive AI features.
Start an incident log, even if it is just a structured document.

Week 4 and beyond: Test and tighten

Review the first incidents and user complaints.
Fix weak points in human review.
Update docs after every material model or prompt change.
Prepare a short buyer-facing AI trust packet.

Glossary founders should know

AI system: a machine-based system that generates outputs such as predictions, recommendations, scores, or content that can influence environments or decisions.

Provider: the party that develops an AI system or places it on the market under its own name.

Deployer: the party that uses the AI system in its own operations.

Intended purpose: the specific use defined by the provider, including users, context, and boundaries.

Human oversight: measures that let people understand, supervise, and intervene in the system’s operation.

Post-market monitoring: review after launch to detect issues, incidents, and misuse in the real world.

Data governance: the rules and records around data source, quality, access, retention, and bias review.

What is the founder takeaway?

The EU AI Act is not just a legal event. It is a product design filter, a sales filter, and a trust filter. Founders who understand the risk categories early can decide what to build, what to avoid, and how to document their choices before a buyer, regulator, or journalist asks ugly questions.

If you remember five things, remember these:

Classify your AI by human consequence.
Do not sleepwalk into high-risk use cases.
Vendor risk is still your risk.
Human oversight must be real, not decorative.
Compliance works best when it is built into the workflow.

My own founder view is probably less fashionable than the usual “move fast” slogan. I prefer this: build fast where the harm is low, and build carefully where human futures are on the line. That is not fear. That is mature product strategy in Europe. And for many startups, it will also be the difference between shipping into the EU with confidence and getting blocked at the first serious diligence call.

FAQ

Does open-source use reduce a founder’s obligations under the EU AI Act?

Not necessarily. Open-source components may reduce some upstream burden, but once your startup packages, fine-tunes, deploys, or markets an AI-enabled feature in the EU, your own role matters more than the license. Focus on the actual use case, customer impact, and whether your product changes model behavior materially.

How should founders handle model updates without breaking their compliance posture?

Treat major model, prompt, retrieval, or workflow changes like product releases with legal consequences. Re-check intended purpose, performance thresholds, user disclosures, and human oversight after each material update. A lightweight change log and rollback plan can prevent silent drift into a higher-risk AI system classification.

Can a startup be exposed if customers repurpose its tool for high-risk decisions?

Yes. If misuse is foreseeable, regulators and buyers may ask what safeguards you built. Limit dangerous use through contracts, permissions, UI warnings, restricted workflows, and audit logs. If customers can easily turn your assistant into a hiring or credit scoring engine, your design choices will matter.

What procurement questions should founders expect before closing enterprise AI deals?

Expect questions on training data sources, data retention, subprocessors, explainability, bias testing, human review, incident response, and model change notices. Enterprise buyers increasingly use AI diligence as a gate. If you sell across borders, the European Startup Playbook helps frame these market-access expectations.

What is the safest way to market an AI product in Europe without overclaiming?

Avoid absolute claims like unbiased, fully autonomous, compliant by default, or error-free. Write narrower product language tied to intended purpose, operator responsibility, and known limits. Sales decks, website copy, and onboarding flows should match the product’s real behavior so marketing does not expand legal exposure.

How do founders decide whether to build compliance in-house or buy tooling?

Start in-house if your AI footprint is small and your use cases are low consequence. Buy tooling when you need repeatable workflows for audits, documentation, approvals, vendor reviews, or incident tracking. The trigger is not company size alone, but regulatory complexity, buyer pressure, and number of sensitive features.

Are general-purpose AI features automatically low risk for startups?

No. A generic model can become high risk when embedded in employment, education, insurance, healthcare, or identity workflows. Founders should classify the downstream application, not just the base model. A useful shortcut is to review an EU AI Act enterprise guide against your actual customer journey.

What internal team should own AI compliance in an early-stage startup?

One accountable owner is essential, but not enough alone. Product should define intended purpose, engineering should manage controls and logs, legal or ops should handle policies and vendors, and sales should avoid risky claims. In small startups, a founder often coordinates this until responsibilities can be formalized.

How can founders prepare for complaints, appeals, or regulator questions?

Create a simple response system before launch: incident logging, named reviewers, preserved records, escalation rules, and user-facing appeal paths. If someone challenges an automated outcome, speed and traceability matter. Startups that can explain what happened, why, and what changed afterward are in a stronger position.

What is the smartest first step if the product’s risk level is still unclear?

Run a feature-by-feature classification workshop with product, engineering, and commercial input. Document affected users, likely harms, role in decision-making, and presence of human review. If the tool touches jobs, credit, health, education, or identity, pause assumptions and escalate review before expanding distribution.

Violetta Bonenkamp

Violetta Bonenkamp, also known as Mean CEO, is a female entrepreneur and an experienced startup founder, bootstrapping her startups. She has an impressive educational background including an MBA and four other higher education degrees. She has over 20 years of work experience across multiple countries, including 10 years as a solopreneur and serial entrepreneur. Throughout her startup experience she has applied for multiple startup grants at the EU level, in the Netherlands and Malta, and her startups received quite a few of those. She’s been living, studying and working in many countries around the globe and her extensive multicultural experience has influenced her immensely. Constantly learning new things, like AI, SEO, zero code, code, etc. and scaling her businesses through smart systems.

Navigating the EU AI Act: Risk Categories and Compliance for Founders. How the upcoming European regulations will impact AI-driven products.21 | Ultimate Guide For Startups | 2026 EDITION