EU AI Act for Startups: What to Build Before August 2026
By Ergini, Software & AI Developer
TL;DR
The EU AI Act's main obligations apply from August 2, 2026, and they land on you even if you only deploy OpenAI or Claude rather than train a model. Most startup features are limited-risk and need just transparency plus logging; a few are high-risk and need the full control set. This guide maps the tiers to concrete engineering work so you build it in now instead of retrofitting under deadline.
The deadline that should be on your roadmap
If your startup ships AI to anyone in the EU, the date to put on your roadmap is August 2, 2026. That is when the main body of the EU AI Act's obligations applies, including most of the requirements for high-risk systems. The Act entered into force in 2024 and has been switching on in phases: the bans on prohibited practices came first in February 2025, the rules for general-purpose AI models in August 2025, and now the big one.
This post is not a legal explainer - there are plenty of those, mostly written by law firms. This is a builder's guide: what the Act actually asks you to put in your code, what is realistically required for a typical startup feature versus a high-risk one, and how to build it in now so you are not retrofitting compliance under deadline or failing an enterprise security review six months from now. I build these controls for clients, so this is the practical version.
One disclaimer up front, and I mean it: I am an engineer, not a lawyer. Classifying your system and signing off on conformity is a legal call that belongs with your counsel or DPO. What I can tell you is how to build the system so that when they make that call, the answer can be yes.
The risk tiers, in plain language
The Act sorts AI systems into four buckets by risk. You need to know which one you are in, because the work is wildly different across them.
| Tier | Examples | What it means for you |
|---|---|---|
| Unacceptable (prohibited) | Social scoring, manipulative or exploitative systems, most real-time public biometric ID | Do not build it. Banned since Feb 2025. |
| High-risk | Recruiting and HR, credit scoring, biometrics, critical infrastructure, certain education and medical | The full control set: risk management, data governance, logging, human oversight, accuracy testing, docs, monitoring. |
| Limited-risk | Chatbots, generative content, most assistant features | Transparency: tell users it is AI, mark AI-generated content. |
| Minimal-risk | Spam filters, AI in games, most internal tooling | No specific obligations. Voluntary best practice. |
The honest reality for most startups: you are limited-risk. A support bot, a copilot, a summarizer, a recommendation feature - these carry transparency obligations and not much more under the Act itself (GDPR is a separate matter). The startups that are high-risk usually know it, because they are operating in a regulated domain - hiring, lending, health, education, biometrics. If that is you, budget seriously. If it is not, do not let consultants scare you into enterprise-grade governance you do not need.
The trap: "we just call the OpenAI API, so we are fine"
This is the single most common misconception I hear, and it is wrong. Using Claude or GPT through an API does not move the obligations onto Anthropic or OpenAI. They carry the general-purpose AI model obligations (documentation, training-data transparency, copyright policy) that switched on in August 2025. You, the company putting an AI system in front of users, are the deployer - and often the provider of the overall system - and the deployment obligations are yours: transparency, human oversight, logging, and risk management for how your product uses that model.
Think of it like cloud hosting. AWS is responsible for the security of the cloud; you are responsible for security in the cloud. Same shape here. The model vendor handles the model; you handle what you built on top of it.
What to actually build: limited-risk
If you are limited-risk, the engineering is small and concrete. Do these and you have covered the Act's transparency requirements for your AI-facing features.
1. Tell users they are interacting with AI. Article 50 requires that people know when they are talking to an AI system rather than a human. For a chatbot that is a clear label or an opening message. Do not disguise the bot as a person. This is a one-line product decision and a small UI change.
2. Mark AI-generated content. Where your product generates synthetic text, image, audio, or video, it should be detectable as AI-generated, in a machine-readable way where feasible. For most text features a visible label is enough; for media, consider provenance metadata.
3. Keep basic logs. Even when not strictly mandated at your tier, lightweight event logging - what was asked, what the model returned, which version, any human override - is cheap to add and saves you in every later conversation: a security review, a customer dispute, a GDPR data-subject request, or an upgrade to high-risk. This is the same logging you want for observability anyway.
That is genuinely most of it for a limited-risk feature. Days of work, not months, if you build it in rather than bolt it on.
What to actually build: high-risk
If you are genuinely high-risk, the bar is much higher, and this is where budget and lead time matter. The control set, in engineering terms:
- Risk management system. A documented, living process that identifies and mitigates risks across the lifecycle - not a one-time PDF.
- Data governance. Training and input data that is relevant, representative, and checked for bias, with documented lineage. This overlaps heavily with GDPR data governance.
- Automatic logging. Tamper-evident records over the system lifecycle - the audit trail that proves what happened.
- Human oversight. Real human-in-the-loop controls: the ability for a person to understand, override, and stop the system, with the decisions logged.
- Accuracy, robustness, and security. Tested and documented performance, including an eval harness and defenses against prompt injection.
- Technical documentation and post-market monitoring. The dossier that demonstrates conformity, plus ongoing monitoring once live.
None of this is exotic engineering. It is the same discipline that makes an AI system good - evals, logging, guardrails, human review - formalized and documented. The difference between a startup that sails through and one that scrambles is almost always whether these were designed in from week one.
Build-it-in-now, not retrofit-later
Here is the practical sequencing I recommend to founders, in priority order, whether you are limited or high-risk:
Now, cheap, do it regardless of tier: AI disclosure in the UI, content marking, and structured event logging. These are small, they help your product and your GDPR posture, and they are table stakes for any enterprise sale.
Next, if you touch personal data: data minimization, EU-region data residency where required, retention limits, and a working deletion path. This is GDPR work that also serves the AI Act. Covered in depth in my GDPR-compliant AI service.
Before any high-risk launch: the eval harness, human oversight controls, and technical documentation. These take weeks, so start early. If data residency is a hard requirement, a self-hosted model in the EU may be the cleanest answer.
Frequently asked questions
When does the EU AI Act apply to my startup?
It applies in phases. Prohibited practices since February 2025, general-purpose AI model obligations since August 2025, and the main body of obligations - including most high-risk requirements - from August 2, 2026. Some embedded high-risk cases extend to 2027. If you ship AI to EU users, plan around August 2026.
Does the AI Act apply if I only use the OpenAI or Claude API?
Yes. Using a third-party model does not exempt you. You are the deployer (and often the provider of the overall system), so transparency, human oversight, record-keeping, and risk management are your obligations. The model vendor carries the separate general-purpose AI obligations.
Is my product high-risk?
Probably not. High-risk is a defined list - recruiting and HR, credit scoring, biometrics, critical infrastructure, certain education and medical uses. A support bot, writing assistant, or internal automation is usually limited-risk. Classification is a legal determination, so get a read from counsel if you are near the line.
What are the penalties?
Tiered: up to 35 million euros or 7 percent of global turnover for prohibited practices, up to 15 million or 3 percent for most other breaches, up to 7.5 million or 1 percent for supplying incorrect information. For startups the near-term risk is usually a failed enterprise procurement before it is a fine.
What is the cheapest path to compliance?
Build the controls in from the start. A limited-risk feature is mostly AI disclosure plus logging - days of work. The expensive path is shipping with no logging, eval, or data governance and rebuilding under deadline.
Is this the same as GDPR?
No, but they overlap heavily. GDPR governs personal data; the AI Act governs AI systems by risk. The engineering - data governance, logging, human review - serves both, so build once and satisfy both.
Bottom line
The EU AI Act is far less scary for the typical startup than the headlines suggest, and far more manageable if you build the controls in early. Figure out your tier (most likely limited-risk), ship the transparency and logging basics now, do the GDPR data work if you touch personal data, and reserve the heavy control set for genuinely high-risk systems. Pair the engineering with a real legal read - I do the build half, your counsel does the legal half.
If you want a senior engineer to implement the technical controls and get your AI system audit-ready, that is exactly what my EU AI Act compliant development service is for. For the official text, the EU AI Act resources are the canonical reference.