Make Your AI App EU-Compliant by Dec 2026

The founder's plain-English guide to shipping an AI product that Europe will not fine.

Brussels just delayed its biggest AI rules, and that is precisely why so many founders are about to get caught. In July 2026 the European Union adopted the Digital Omnibus on AI, a simplification package that pushed the heaviest high-risk obligations back to December 2027 and August 2028. Every headline read "EU delays AI Act." A lot of builders heard "we can relax." That is the expensive misreading. The parts of the law that actually bind a normal AI app (transparency, the outright bans, AI literacy, and the entire weight of GDPR) were never delayed at all, and a real, dated obligation lands on 2 December 2026.

This matters because the EU wrote a law that follows consequences, not code. It does not care whether you built a transformer or a decision tree. It cares what your software does to a person: whether it can deny them a loan, screen them out of a job, deceive them into thinking a bot is human, or manufacture a fake image of them. And it reaches you wherever you are. A solo founder in Austin with a handful of users in Amsterdam is inside the same regime as a Paris scale-up, because the Act attaches to output used in the Union, not to where your servers hum.

This guide breaks down exactly what a founder must do, the specific deadlines that survived the delay, how to classify your own product in an afternoon, and where the real money-and-jail-tier risks sit. It is written for the person who is shipping, not for a compliance department, because most AI companies in Europe are now tiny: 20% of EU enterprises used AI in 2025, up from 13.5% a year earlier, and a growing slice of them are one-person and two-person shops. If you are building an app the way founders build now, describing what you want and letting AI assemble the product, you still own the legal exposure. Platforms like Founden can scaffold the compliant surfaces for you (the disclosure, the privacy policy, the data handling), but the classification and the duty stay with you. Let us make them legible.

Contents

1. The one thing everyone got wrong about the delay
2. Does the EU AI Act even apply to you?
3. The risk pyramid: classify your app in an afternoon
4. What actually lands by December 2026
5. Article 50 in practice: chatbots and generators
6. GDPR is the other half, and it never paused
7. If you are high-risk: the runway to December 2027
8. GPAI: only if you train or fine-tune your own model
9. Penalties, enforcement, and what compliance really costs
10. The founder's 30-day compliance sprint
11. What comes next: standards, agents, and the Brussels effect
12. Conclusion: a decision framework you can act on

1. The one thing everyone got wrong about the delay

Start with the structural question, because it reframes everything that follows. The EU did not build the AI Act as a single switch that flips on one date. It built a staggered clock where different duties activate at different times, keyed to how dangerous the use is. When people say "the AI Act was delayed," they are almost always describing one narrow band of that clock: the machinery for high-risk systems. Everything else kept ticking. Understanding which hand of the clock moved is the difference between a compliant launch and a preventable fine.

Here is the timeline as it actually stands in August 2026. The Act ( Regulation (EU) 2024/1689) entered into force on 1 August 2024. The prohibited practices and the AI literacy duty switched on 2 February 2025. The rules for general-purpose AI models, plus governance and the penalty regime, switched on 2 August 2025. Most of the rest, including Article 50 transparency, switched on 2 August 2026. Under the original text, standalone high-risk systems would also have gone live on that August 2026 date, with product-embedded high-risk following in August 2027.

Then came the intervention. On 19 November 2025 the Commission proposed the Digital Omnibus, a package aimed at cutting regulatory burden and, bluntly, at buying time because the technical standards and national authorities the law depends on were not ready. That proposal became law as Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026 - K&L Gates. The single most consequential change: obligations for standalone Annex III high-risk systems moved from 2 August 2026 to 2 December 2027, and product-embedded Annex I high-risk to 2 August 2028.

That is the delay everyone quoted. Now here is what did not move, which is the part that catches people. Article 50 transparency still took effect on 2 August 2026. The prohibitions in Article 5 were untouched and were actually expanded. The AI literacy duty remained live. GPAI obligations stayed on their original schedule. As one law firm titled its client alert, the transparency rules were "Not Delayed, Not Deferred". The deferral was surgical: it removed the near-term burden of conformity assessment, CE marking, and technical files for high-risk systems, and left the duties that apply to the everyday chatbot, image tool, or recommendation feature exactly where they were.

The reason "December 2026" is the honest headline for a founder, rather than "December 2027," is a pair of hard dates the Omnibus itself created. First, providers of generative AI systems already on the market before 2 August 2026 got a short grace window to implement machine-readable marking of their output, and that window closes on 2 December 2026 - Cooley. Second, the Omnibus added a new prohibition on AI systems designed to generate non-consensual intimate imagery ("nudifier" apps) and child sexual abuse material, and that ban bites on 2 December 2026 - Morrison Foerster. So the calendar for a normal AI-app builder is not a distant 2027 problem. It is a this-quarter problem with a December due date.

There is a second, quieter reason not to treat "delay" as "pause." The 16 extra months on high-risk are runway, not amnesty. If your product screens job applicants or scores creditworthiness, the obligations still arrive, and they are heavy enough (risk-management systems, data governance, decade-long documentation) that starting them the week before the deadline is not viable. The founders who use the runway to build compliance into the product now are the ones who will still be shipping in Europe in 2028. The ones who read the headline and closed the tab are the ones who will be re-architecting under pressure. First principles: a delay in a duty you were always going to owe is a gift of preparation time, not a reprieve from the duty.

2. Does the EU AI Act even apply to you?

Before you classify anything, answer the scope question, because a surprising number of founders assume a European law cannot reach an American or Asian company and are simply wrong. The Act was drafted to mirror GDPR's extraterritorial reach, the mechanism people call the "Brussels effect," where a rule written in Europe becomes a de facto global standard because the cheapest path for a global product is to comply everywhere. If you have ever wondered why your favorite US app suddenly shows a cookie banner, you have already met this dynamic. The AI Act extends it to artificial intelligence.

The operative text is Article 2. The Act applies to providers who place AI systems on the EU market, "irrespective of whether those providers are established or located within the Union or in a third country" - Article 2. It applies to deployers established in the Union. And then comes the trigger that catches builders who never intended to serve Europe: it applies to providers and deployers in a third country "where the output produced by the AI system is used in the Union." The bar is "used," which is lower than "targeted." Compliance guidance has compressed this into a memorable rule of thumb: one EU user can be enough. The precise outer edge of "output used in the Union" is untested and genuinely uncertain, but the safe planning assumption is that if Europeans can reach your product, the Act can reach you.

Make that concrete. Imagine a two-person US startup shipping a resume-screening tool to American recruiters, with no European ambitions and servers in Virginia. One customer, a US company with a Berlin office, uses the tool to rank candidates who live in Germany. The output (a ranked list affecting German residents) is now used in the Union, and the Act reaches the Virginia startup even though it never marketed to Europe and never signed a European customer. This is not a hypothetical edge case; it is the ordinary way software leaks across borders through a single multinational customer. The same reasoning caught countless firms under GDPR, which is why the mature response is not to try to wall Europe out (usually impractical) but to build the compliant surfaces once and stop worrying about which user is where.

Scope is only half the question. The other half is which role you occupy, because the Act allocates duties by role and the roles carry very different weights. Article 3 defines a provider as whoever develops an AI system and places it on the market under their own name or trademark, and a deployer as whoever uses an AI system under their own authority in a professional capacity - Article 3. Providers carry the heavy obligation set. Deployers carry a lighter one. Getting your role right is the second gate after scope, and most founders get it wrong in a predictable direction.

Here is the pattern that matters for the modern builder who assembles a product on top of a foundation model. If you build your app on an API from OpenAI, Anthropic, or Google, you are almost always the deployer, and the model maker is the upstream GPAI/model provider - AIActStack. Merely calling an API and shipping a feature does not make you a provider. That is the good news. The trap is Article 25, which flips a deployer into a provider of a high-risk system in three situations. Understanding these three is worth more than any checklist.

• Rebranding: you put your own name or trademark on a high-risk system already on the market.
• Substantial modification: you change a high-risk system so significantly it stays high-risk under a new configuration.
• Purpose change: you repurpose a system (including a general one) so that it becomes high-risk.

The nuance that catches people is the contractual escape hatch, which exists for only one of these. Article 25 lets a rebrander contractually push provider obligations back onto the original maker, but there is no such carve-out for substantial modification or purpose change - A&O Shearman / Praxikon. If you self-host and heavily fine-tune an open model into a hiring tool, or you take a general chatbot and point it at loan decisions, you cannot contract your way out of becoming the provider. The Act deliberately does not define "substantial modification" with precision, which means the boundary is fuzzy and the conservative move is to document your reasoning whenever you are near it. This is the same discipline you would apply when you build software with AI and need to know which layer of the stack you actually own.

One more concrete duty hides here for non-EU high-risk providers. If you are outside the EU and you place a high-risk system on the Union market, Article 22 requires you to appoint, by written mandate, an EU-established authorised representative before you launch, the AI Act's twin of GDPR's Article 27 representative. Most founders will never touch this because most founders are deployers of limited-risk systems. But if you land in high-risk (section 3 tells you how to know), it is a real, concrete, do-not-forget obligation that many US startups will only discover when a European customer's procurement team asks for the representative's contact details.

3. The risk pyramid: classify your app in an afternoon

The Act's backbone is a four-tier risk pyramid, and the good news for founders is that classification is a bounded exercise you can complete in an afternoon rather than a quarter. The Commission's own framing sorts every AI system into unacceptable (banned), high-risk (strict obligations), limited or transparency risk (disclosure duties), and minimal risk (no obligations, which is where the vast majority of AI lives) - European Commission. The pyramid did not change under the Omnibus. What changed is only the calendar for the high-risk tier. So your job is to figure out which shelf your product sits on, and then apply the duties for that shelf.

Start at the top, because the top tier is the one with no compliance path. Article 5 prohibited practices are uses the EU has decided are simply not allowed, and screening against them first is the cheapest, highest-leverage thing you can do. The banned list covers manipulative or deceptive techniques that cause significant harm, exploiting vulnerabilities of age or disability or economic hardship, social scoring, predicting crime from profiling alone, untargeted scraping of facial images to build recognition databases, inferring emotions in workplaces and schools, biometric categorisation to deduce sensitive traits, and real-time remote biometric identification in public for law enforcement - Article 5. These have been enforceable since February 2025. If your product idea lives here, there is no documentation that saves it. The correct response is to pivot the feature.

The Omnibus made this list longer, not shorter, which is the detail that surprises founders expecting deregulation. From 2 December 2026, AI systems designed to produce non-consensual intimate imagery and child sexual abuse material are added to the prohibited tier - European Commission. This is the single most important date for anyone building an image or video generator. It is not enough to say your tool is general-purpose. If it can be trivially steered to produce that content, you need technical safeguards in place by that date, because a breach here sits in the top penalty band. The Commission's January 2026 investigation into X over manipulated explicit images generated by its Grok tool (opened under the Digital Services Act, not the AI Act, but a clear signal of posture) shows regulators are watching exactly this - Help Net Security.

Next tier down is high-risk, and this is where classification gets subtle enough to be worth real care. A system is high-risk if it falls into one of the eight Annex III use-case areas: biometrics, critical infrastructure, education, employment and worker management, access to essential services (which explicitly names credit scoring and insurance pricing), law enforcement, migration, and administration of justice - Annex III. The classification follows the use case, not the technology, which is the single most common founder misconception. A plain logistic-regression credit model is high-risk because credit scoring is named in the Annex, while a sophisticated deep-learning content recommender is minimal-risk, because recommending videos is not on the list. Technical complexity is irrelevant. Human consequence is everything.

There is an escape hatch, and there is a trapdoor inside it. Article 6(3) says an Annex III system is not high-risk if it poses no significant risk to health, safety, or fundamental rights and it only performs a narrow procedural task, improves a completed human activity, detects patterns without replacing human judgment, or does preparatory work - Article 6. But the same article contains a profiling kill-switch: any system that profiles a natural person "shall always be considered to be high-risk," full stop. Because HR screening, credit decisioning, and insurance underwriting inherently profile people, the escape hatch is usually shut for exactly the products founders most want to build. The Commission's guidance stresses that these conditions are read narrowly and that a "generous interpretation will not survive regulatory scrutiny" - Norton Rose.

The third tier, limited or transparency risk, is where most consumer AI apps actually land, and it is governed by disclosure duties rather than the full high-risk stack. Customer-support chatbots, coding assistants, and content generators generally do not map to any Annex III domain, so the system itself avoids high-risk status and owes only Article 50 transparency plus the Article 5 screen - Promise Legal. The important caveat is that a chatbot becomes high-risk the moment it starts driving decisions on essential services, for example if your support bot starts approving or denying refunds tied to creditworthiness. Context pulls a tool up or down the pyramid. The base tier, minimal risk, is the catch-all for everything else (spam filters, game AI, inventory optimization, most recommendation), and it carries no mandatory obligations at all.

To calibrate expectations with data rather than vibes, look at what happens when practitioners actually classify real systems. When the German nonprofit appliedAI ran 106 enterprise AI systems through the framework, it found 18% high-risk, 42% low-risk, and 40% genuinely unclear - appliedAI. That 40% ambiguous share is the real story, and it is why the Commission issued dedicated Article 6 guidelines and why founders near the line should document their self-assessment carefully. Separately, in a survey of EU AI startups, 33% believed their systems would be high-risk, far above the Commission's original 5-15% projection - IAPP. Self-assessment probably overstates true exposure, but the gap tells you something real: builders find this harder to call than lawmakers expected, so budget time to get it right and, if you land in high-risk, get counsel.

4. What actually lands by December 2026

Now assemble the near-term picture, because the whole point of understanding the delay is to know what you actually have to do this year. Strip away the deferred high-risk machinery and you are left with a compact live obligation set that applies to essentially every AI product touching Europe. This is the chapter to act on, and it is far more manageable than the "10,000 pages of EU regulation" panic implies. Four duties are on the clock, and none of them require a notified body, a CE mark, or a six-figure consultant.

The first live duty is AI literacy under Article 4, binding since 2 February 2025 with no grace period and supervised from August 2026 - Travers Smith. Providers and deployers must ensure the people operating their AI systems have a sufficient level of AI literacy, scaled to what the system does and who it affects. For a tiny team this is genuinely proportionate: you do not need to appoint an AI officer, you do not need to test staff, and you do not need a board. What you cannot do is nothing, or merely tell people to skim a manual. The compliant minimum is tailored, documented training that covers what your systems do, their risks, and the relevant rules, with records kept. The Commission even provides free support through an AI literacy Q&A and a living repository of practices.

The second live duty is the prohibitions in Article 5, which we covered in section 3, plus the two new December 2026 bans on non-consensual intimate imagery and CSAM generation. The third is the entire weight of GDPR, which never came under the Omnibus delay at all and which section 6 treats in full. The fourth, and the one most consumer AI apps underestimate, is Article 50 transparency, which took effect 2 August 2026 and gives pre-existing generative systems until 2 December 2026 to implement machine-readable content marking - Freshfields. Section 5 shows exactly how to satisfy it.

The reason this compact set deserves your full attention, rather than the distant high-risk regime, is a simple matter of probability and penalty. High-risk conformity is a heavy lift, but it only applies if you are actually in an Annex III use case, and even then not until December 2027. The four live duties apply to almost everyone, right now, and two of them (Article 5 breaches and the new bans) sit in the top fine tier of up to 35 million euros or 7% of global turnover. A founder optimizing for expected legal risk should spend the next quarter on transparency, literacy, prohibited-use screening, and GDPR, in that order, and treat high-risk as a parallel workstream only if classification put them there.

There is one more reason to internalize the "delayed is not paused" framing, and it is about credibility with your own customers. European businesses buying software now put AI Act clauses in their procurement, and a B2B founder who cannot answer "which role are you, and how do you handle Article 50" will lose deals long before any regulator calls. The obligation and the sales requirement have merged. Being able to describe your classification, your disclosure, and your data handling in one paragraph is now part of the product, in the same way that being able to describe your authentication choices or your data layer is part of the product. Compliance has quietly become a feature you sell, not just a risk you manage.

5. Article 50 in practice: chatbots and generators

Article 50 deserves its own chapter because it is the duty that touches the most builders and because it is genuinely implementable in an afternoon once you understand its shape. The article splits into two families: duties on providers (build the disclosure into the system) and duties on deployers (surface the disclosure to your users). Both families reach the ordinary AI app, and neither requires exotic technology. What they require is deliberate, visible honesty about the fact that a user is dealing with a machine, and a durable mark on anything the machine generates.

The chatbot duty is the simplest. Under Article 50(1), any AI system that interacts with people must inform them they are dealing with an AI, "at the latest at the time of the first interaction," in a clear and distinguishable way - Article 50. The only exception is where it is already obvious to a reasonably observant person. In practice this means a visible "You are chatting with an AI" notice at the start of the conversation, in the chat surface itself, not buried in your terms of service and not hidden behind a settings menu. The duty falls on the provider to design it in, but a deployer must still ensure the notice actually appears to the end user. If you are shipping a support agent for your site, this is the one non-negotiable line of UI copy.

The generative-content duty is where the real engineering sits. Article 50(2) requires providers of generative AI to mark synthetic audio, image, video, and text in a machine-readable format that is detectable as artificially generated, and the marking must be effective, interoperable, robust, and reliable "as far as technically feasible." Assistive edits like spell-check and minor, non-substantive alterations are exempt. The Act itself is deliberately technology-neutral: it does not name a standard in its operative text. But in June 2026 the European AI Office released a voluntary Code of Practice on Transparency of AI-Generated Content that points clearly at two mechanisms working together: cryptographically signed, tamper-evident metadata (in practice, the C2PA / Content Credentials standard) and imperceptible watermarking.

For a content-generation app, the concrete implementation is well-trodden. You embed a signed C2PA manifest into each output, declaring that the content was AI-generated, with a timestamp and a claim-generator field, and you pair that metadata with an invisible watermark so the mark survives screenshots and format conversions - C2PA Viewer. Signing certificates come from certificate authorities on the C2PA trust list. Tampering breaks the signature, which is what makes the mark "reliable." The pattern in code is not exotic:

# Sign each generated asset with a C2PA manifest (Content Credentials)
from c2pa import Builder, create_signer, SigningAlg

manifest = {
    "claim_generator": "your-app/1.0",
    "assertions": [
        {"label": "c2pa.actions",
         "data": {"actions": [{"action": "c2pa.created",
                               "digitalSourceType": "trainedAlgorithmicMedia"}]}}
    ],
}

signer = create_signer("cert_chain.pem", "private.key", SigningAlg.ES256, "https://timestamp.digicert.com")
builder = Builder(manifest)
builder.sign_file(signer, "generated_image.png", "signed_image.png")

Machine-readable marking is only half of it, and this is the mistake that trips up teams who think a watermark discharges the whole duty. The deployer-facing, human-readable label is separate and additional. Under Article 50(4), deployers of deepfakes must visibly disclose that content is artificially generated, and the disclosure must be perceivable at first exposure - European Commission FAQ. What fails the "clear and distinguishable" standard is tiny footer text, a label that flashes for a second, or a disclosure buried in the fine print. What passes is a persistent visible label on an image or video, an audible disclaimer on audio, and a language-adapted text label. The rule of thumb: a signed manifest satisfies the machine, and a visible label satisfies the human, and Article 50 wants both.

A few carve-outs keep this proportionate, and knowing them prevents over-engineering. Purely artistic, satirical, or fictional works need only an "appropriate" disclosure of existence that does not spoil the experience. Text that has undergone substantive human editorial review, where a person or entity holds editorial responsibility, is exempt from the public-interest-text duty. Short symbol sequences, source code, and machine-to-machine outputs are outside scope. And there is a grace period worth knowing: generative systems already on the market before 2 August 2026 have until 2 December 2026 to get their marking live, while anything you launch after that date must mark from day one. If you are shipping a new generator this autumn, you do not get the grace window, so build the marking in before launch.

6. GDPR is the other half, and it never paused

Here is the frame that separates founders who stay out of trouble from those who do not: the AI Act is the new law everyone talks about, but GDPR is the law that is actually fining companies today, and it applies to your AI the moment your AI touches a person's data. The two regimes overlap, they do not substitute, and the Omnibus did not delay GDPR one day. In fact, almost every marquee "EU blocked an AI product" story of the last three years was a GDPR story, not an AI Act story. If you optimize only for the shiny new statute and ignore the old one, you are defending the wrong flank.

The first thing to internalize is that a GDPR Data Protection Impact Assessment (DPIA) and the AI Act's Fundamental Rights Impact Assessment (FRIA) are two different documents and one cannot stand in for the other - DPLIANCE. A DPIA under Article 35 GDPR is mandatory when processing is likely to result in high risk, which covers most systematic profiling, large-scale processing, or special-category data, so it captures a great many AI features. For an AI product, a good DPIA explicitly addresses bias, explainability, data quality, and the uncomfortable fact that personal data can persist inside model parameters. A high-risk system under the AI Act therefore faces a dual obligation: a DPIA for the data and, for certain deployers, a FRIA for the fundamental-rights impact.

The lawful-basis question is where AI gets genuinely hard, and the regulators have spoken. In December 2024 the European Data Protection Board issued Opinion 28/2024 on personal data in AI models. The headline for builders: legitimate interest can, in principle, serve as a lawful basis for developing and deploying AI, but only after a rigorous three-step test (a real and specific interest, a necessity check, and a balancing against the rights of data subjects). The Board refused an all-or-nothing view of anonymity, requiring a case-by-case assessment of whether a model trained on personal data can be considered anonymous, and it warned that a model built on unlawfully processed data can taint its downstream deployment. Translation for a founder: "we used legitimate interest" is a conclusion you must earn and document, not a checkbox.

Automated decisions carry their own landmine, and it predates the AI Act. Article 22 GDPR restricts decisions "based solely on automated processing" that produce legal or similarly significant effects, and the Court of Justice's Schufa ruling ( Case C-634/21) held that generating a credit score is itself automated decision-making when a lender "draws strongly" on it. That ruling reaches far beyond credit bureaus. If your AI produces a score, a ranking, or a recommendation that a third party leans on to accept or reject a person, you may be inside Article 22, which means you owe transparency, a route to human review, and a lawful ground. This is the legal spine underneath why AI hiring and lending tools are treated so seriously.

Data-subject rights are the part builders most often forget, and they collide with how models actually work. GDPR gives every person the right to access, correct, and erase their personal data, and those rights do not stop at your database. If a user asks you to delete their data, and their data was used to train or fine-tune a model, the honest engineering question is whether the model still "contains" them. The EDPB's refusal to declare trained models automatically anonymous means you cannot assume erasure from the database discharges the duty. The practical mitigations are unglamorous but real: keep training data separate and deletable, prefer retrieval over fine-tuning for anything containing personal data, log what went into each model version, and be able to explain your retention honestly. A product that cannot answer "where is this person's data and can you remove it" is not GDPR-ready, no matter how clean its AI Act classification looks.

Now the enforcement reality, told honestly, because the truth is more instructive than the headline. In December 2024 the Italian Garante fined OpenAI 15 million euros over ChatGPT's data handling, citing training without an adequate legal basis and a lack of age checks - The Hacker News. But in March 2026 the Court of Rome annulled that fine, ruling the Garante lacked jurisdiction once OpenAI's Irish subsidiary made the Irish regulator its lead authority - Wilson Sonsini. Read carefully: the fine fell on a procedural, one-stop-shop technicality, not because the training was found lawful. The conduct was never blessed. The lesson is not "GDPR is toothless," it is that enforcement is real, messy, and jurisdictionally fragmented, and you cannot bank on a competitor's escape.

Other enforcement is cleaner and instructive about where the lines are. Italy blocked DeepSeek entirely in January 2025 after the company gave "completely insufficient" answers about storing Italian users' data in China - Euronews. Earlier, the Garante fined Clearview AI 20 million euros for scraping facial biometrics without a legal basis and ordered deletion of all Italian data - EDPB. The through-line across all of these is data governance: where the data comes from, whether you had a basis to use it, whether users were told, and whether you can honor their rights. Which is exactly why founders who care about not shipping products that quietly corrupt or mishandle data already have a head start on GDPR.

The practical defense is a vendor due-diligence packet you assemble once per model provider and keep with your records. Enterprise privacy reviewers expect five things before they clear a deal: a signed Data Processing Agreement, Standard Contractual Clauses for US transfers, a zero-data-retention arrangement, an EU region pin, and a documented Transfer Impact Assessment - OpenEmpower. The API terms matter, not the consumer terms: both OpenAI and Anthropic contractually do not train on your API data by default under commercial terms. OpenAI offers EU data residency with zero retention through Europe-region Projects, though it must be set on a new Project - OpenAI. Anthropic offers a Console DPA and no-training-by-default, but guaranteed EU residency currently routes through AWS Bedrock EU or Google Vertex EU rather than the direct API - compound.law. Confirm both live, because these terms move, and choosing the right model to build on now includes reading its data terms, not just its benchmarks.

7. If you are high-risk: the runway to December 2027

If section 3 landed you in high-risk, this chapter is your map, and the framing to hold in your head is runway. The Omnibus gave you until 2 December 2027 for standalone Annex III systems and 2 August 2028 for product-embedded ones, but the obligations themselves are substantial enough that the extra 16 months are not slack, they are exactly the preparation time a serious high-risk product needs. The mistake is to file "high-risk" under "future problem." The teams that win here start the risk-management and documentation work now, while the code is still malleable, rather than retrofitting it onto a frozen system under deadline pressure.

The obligations form a coherent system once you see the logic connecting them, so learn the logic rather than memorizing the article numbers. At the center is a risk-management system under Article 9: a continuous, documented, lifecycle process that identifies foreseeable risks to health, safety, and fundamental rights, estimates them under both intended use and reasonably foreseeable misuse, and drives mitigation until residual risk is acceptable - Article 9. Feeding it is data governance under Article 10: training, validation, and test data that is relevant, representative, and as error-free as feasible, with examined and mitigated bias. Wrapping both is a quality management system under Article 17, the written accountability framework that ties compliance strategy, testing, record-keeping, and incident procedures together.

Around that core sit the duties that make the system inspectable and controllable. These are the ones a founder should treat as product requirements, not paperwork, because they change how you build.

• Technical documentation (Article 11 + Annex IV): a nine-part file covering design, architecture, data, metrics, and risk, kept for 10 years.
• Automatic logging (Article 12): the system records events over its lifetime, with logs retained at least six months.
• Human oversight (Article 14): real interfaces that let a person understand, override, and stop the system, not decorative checkboxes.
• Accuracy, robustness, cybersecurity (Article 15): declared performance metrics and defenses against data poisoning and adversarial attacks.
• Instructions for use (Article 13): clear documentation so your deployers can operate the system correctly.

Those five are not bureaucratic garnish; they are the difference between a system a regulator can audit and one it cannot. Human oversight in particular is the one founders tend to fake, shipping a "review" step where the reviewer has neither the time, the context, nor the authority to actually disagree. The Act wants genuine review capacity, with overrides that are logged and consequential. Build the stop button and the audit trail into the architecture early, because bolting real oversight onto a system that was designed to be fully autonomous is a rewrite, not a patch.

Walk it through with a real product to see how the pieces connect. Suppose you build an AI hiring tool that ranks applicants for your customers. Classification puts you in Annex III (employment), and the profiling kill-switch closes the Article 6(3) exemption, so you are a high-risk provider. That means the risk-management system must analyze how the model could disadvantage protected groups; data governance must show your training data is representative and bias-tested (and Article 10 lets you process special-category data strictly to detect and correct that bias); human oversight must give a recruiter the ability to see why a candidate ranked low and override it; and the technical file must document all of it for a decade. Your customer, the employer, is the deployer, so they owe worker notification and, because employment decisions affect fundamental rights, they may owe a FRIA. None of this is optional by December 2027, and none of it can be sprinkled on at the end. It shapes the data pipeline, the model choice, and the UI from the first commit, which is exactly why the runway matters and why starting now beats scrambling later.

Then comes the conformity machinery, which is lighter than the CE-marking reputation suggests for most high-risk startups. For Annex III points 2 through 8 (which is most high-risk use cases, including employment and credit), the route is internal self-assessment under Annex VI, with no notified body required - Article 43. Only certain biometric systems under Annex III point 1 may need a third-party notified body. After a successful assessment you draw up an EU declaration of conformity, affix the CE marking, and register the system in the EU database before placing it on the market - Article 49. The Omnibus tried to scrap registration for self-assessed non-high-risk systems but the final text kept a simplified registration instead, so do not rely on drafts that promised it would vanish - Gibson Dunn.

Two role-specific duties round out the picture. Deployers of high-risk systems carry their own Article 26 obligations (human oversight, input-data control, six-month log retention, worker notification), and a Fundamental Rights Impact Assessment under Article 27 is required specifically of public bodies, public-service providers, and deployers of credit-scoring and insurance-pricing systems before first use - Article 27. After launch, post-market monitoring (Article 72) and serious-incident reporting (Article 73) apply, with tiered deadlines of 15 days by default, 10 days for a death, and 2 days for widespread infringement or critical-infrastructure disruption. The honest summary for a high-risk founder: this is a real engineering-and-governance program, it is achievable for a small team with counsel on the edge cases, and December 2027 is closer than it looks when the documentation alone runs to a nine-part file kept for a decade.

8. GPAI: only if you train or fine-tune your own model

This chapter is a filter, and for most readers the filter says "skip." The AI Act has a whole separate regime for general-purpose AI models, the foundation models themselves, and it is genuinely important, but it lands on the model maker, not on the app builder who calls an API. Before you spend an hour worrying about GPAI obligations, confirm you are actually in scope, because the great majority of founders are downstream deployers for whom these duties sit entirely with OpenAI, Anthropic, Google, or Mistral.

The GPAI obligations took effect 2 August 2025 and require a provider to maintain technical documentation, provide information to downstream users, publish a copyright policy, and release a public summary of training data using the Commission's template - European Commission. There is a heavier tier for models with systemic risk, presumed when training compute crosses 10^25 FLOP, which adds model evaluations, adversarial testing, incident reporting, and cybersecurity duties - MmowW. A voluntary GPAI Code of Practice signed by OpenAI, Google, Anthropic, Microsoft, Amazon, IBM, and Mistral gives signatories a presumption of conformity, while Meta declined and xAI signed only the safety chapter. This is the layer the labs operate in, and it is why your model vendor's model card and documentation exist.

The question that actually matters to a builder is: when does fine-tuning make me a GPAI provider? The answer is quantitative and reassuring for normal use. If you fine-tune a model that already carries systemic risk, you are presumed to become a provider only if your added compute exceeds a third of the systemic threshold (currently 3 x 10^24 FLOP); if you fine-tune a non-systemic model, you become a provider only if the cumulative compute crosses the full 10^25 FLOP - EU AI Act guidance. Those are enormous numbers. A founder doing a LoRA fine-tune on domain data, or prompt-engineering a hosted model, is nowhere near them. You would need to be running a serious pre-training or continued-training effort to trip this wire.

So the practical guidance is a two-line decision. If you consume a foundation model through an API and build a product on top, you are a deployer: the GPAI duties are the model maker's problem, and your job is transparency (section 5), GDPR (section 6), and risk classification (section 3). If you train or heavily continue-train your own base model at frontier scale, you have become a GPAI provider and you need the documentation, copyright policy, and training-data summary, plus the systemic-risk duties if you cross the threshold. For the reader building an AI-native company on top of commercial models, which is nearly everyone, GPAI is a chapter you can note and move past.

There is one downstream benefit worth extracting from the GPAI regime even as a deployer: it makes your vendor diligence easier. Because GPAI providers must publish documentation and training-data summaries, you can (and should) read them when choosing a model, both to satisfy your own GDPR lawful-basis reasoning and to answer your customers' procurement questions. The training-data summary in particular is designed partly to support copyright and data-protection enforcement, so it is a genuine input into your own compliance story. Use the transparency the labs are now forced to provide, rather than treating it as their private paperwork.

9. Penalties, enforcement, and what compliance really costs

Founders make better decisions when they can see the actual downside and the actual cost, so let us put real numbers on both. The penalty structure is a three-tier system under Article 99. Breaching the prohibited practices carries up to 35 million euros or 7% of global turnover, whichever is higher. Most other breaches, including high-risk duties and Article 50 transparency, carry up to 15 million euros or 3%. Supplying incorrect information to authorities carries up to 7.5 million euros or 1% - Article 99. GPAI model providers are fined separately by the Commission under Article 101, up to 15 million or 3%.

The headline numbers look apocalyptic, but there is a crucial protection for small companies that changes the risk calculus entirely. For SMEs and startups, the fine is capped at the lower of the fixed sum or the percentage, the exact reverse of the "whichever is higher" rule for large undertakings - Article 99. A startup with 500,000 euros of revenue does not face a 35 million euro fine for a prohibited-practice breach; it faces 7% of turnover, which is 35,000 euros. That is still a serious sum, but it is a proportionate one, and it reflects a deliberate policy choice to keep the Act from crushing small builders. The Act also mandates priority sandbox access, simplified documentation, and reduced conformity fees for SMEs. The delay-plus-SME-relief combination means the near-term existential risk for a small AI app is genuinely low, provided you avoid the prohibited tier and handle transparency and GDPR.

Enforcement capacity, meanwhile, is uneven in a way that both reduces and complicates near-term risk. Enforcement is split: the Commission's AI Office polices GPAI models, national market-surveillance authorities police everything else, and the EDPS covers EU institutions - European Commission. But as of a March 2026 assessment, only 8 of 27 member states had fully designated their authorities and single points of contact - aiacto.eu. Ireland, Italy, and Spain are the most advanced; several large states were behind. No public AI Act fine had been issued by mid-2026, and the AI Office's stated opening posture is "technical compliance dialogues" before formal proceedings. This is a grace period in practice, not in law: your obligations exist regardless of whether your member state has stood up its regulator, and the gap will close.

Now the cost side, which is where the hype needs filtering hardest. The most-quoted figures (a quality-management system costing 193,000 to 330,000 euros, or 29,277 euros per high-risk system) come from the Commission's 2021 impact assessment, and the think tank that produced them, CEPS, later argued they were widely misused and overstated - CEPS. Those numbers describe a one-time QMS build for a firm that has no quality system at all, and they apply to high-risk providers, not to the limited-risk chatbot builder who makes up most of the market. Treat any "AI Act compliance costs six figures" claim as a modeling assumption about the worst case, not as what a normal AI app will actually spend.

The real spending decision is about tooling, and here the range runs from free to enterprise. Free, official, and usable today are the Commission's AI Act Service Desk (a compliance checker plus an expert helpline) and the Future of Life Institute's free compliance checker. Open-source tools like Fairlearn (bias measurement) and Project Moonshot (LLM red-teaming) cost nothing and produce real evidence of testing. ISO/IEC 42001 certification, the emerging AI-management-system standard, runs roughly 15,000 to 40,000 dollars for an SME. Commercial governance platforms (Credo AI, Holistic AI, OneTrust) are almost all quote-only and priced for enterprises.

Because a founder choosing a governance tool is comparing more than five options, it helps to score them on the criteria that actually matter to a small builder rather than to a Fortune 500 compliance team. The table below ranks the main options on cost and accessibility, EU AI Act fit, SME and founder friendliness, and EU data residency, weighted for how a startup would actually decide. The scores are one builder's read of publicly available information, not vendor-audited, and the free tools deliberately score high because for most limited-risk apps they are genuinely sufficient.

Criteria explained: Cost & access (35%) weights price and whether a founder can start without a sales call, because budget is the binding constraint for a small team. AI Act fit (30%) measures how directly the tool maps to the Act's obligations. Founder-friendly (20%) captures onboarding and whether a non-lawyer can use it. EU residency (15%) rewards European hosting for data-transfer comfort. The clear read: for a limited-risk app, the free official tools plus an open-source testing library cover you, and you only need a paid platform when you are genuinely high-risk or selling into enterprises that demand a governance dashboard. Spending 90,000 dollars a year on a chatbot's compliance is a category error.

10. The founder's 30-day compliance sprint

Enough theory. Here is the sequence a solo founder or small team can actually run, compressed into a month, ordered so that each step feeds the next. The philosophy is proportionate: do the cheap, high-leverage work first, document as you go, and escalate to counsel only where the classification is genuinely hard. This is the same operating posture that lets one person run a whole company on AI or automate the back office: make the ambiguous legible, then systematize it.

Week one is inventory and scope. List every AI feature, every model provider, every automated decision, and for each one note its purpose, its users, its personal-data touchpoints, and where it is deployed - annexops. Confirm you are in scope (if Europeans use it, you are). This inventory is a living record, not a one-time snapshot, because every new feature can change your classification. The discipline of maintaining it is the single most useful habit, because it turns "are we compliant?" from a panic into a lookup.

Week two is classification and role. Run each system through the section-3 decision tree: screen for prohibited use first, then Annex III, then the profiling kill-switch, then the Article 6(3) filter. For each, record whether you are a provider or a deployer, remembering that an API does not automatically exempt you if you substantially modify or rebrand. The output of this week is a one-line legal characterization per feature, with the reasoning written down. The founder guides converge on a blunt heuristic: "if the output can block a person from work, money, movement, care, education, or dignity, assume higher scrutiny" - mean.ceo.

Week three is the live-duty implementation, and it is mostly product work you can ship. The core moves are concrete and bounded:

• Chatbot disclosure: add the "you are talking to AI" notice at first interaction.
• Content marking: implement C2PA signing plus a visible label on generated media.
• AI literacy: run and document a short, tailored training for whoever operates the AI.
• Privacy surfaces: publish a privacy notice naming your model provider as processor.
• Prohibited-use screening: confirm no feature can be steered into a banned use, especially before 2 December 2026.

That list is a week of focused work for a small team, and every item is evidence you can show a customer or a regulator. The point is not perfection, it is a defensible, documented good-faith effort, which is exactly what proportionate enforcement rewards. Note that human oversight and logging belong here too: even for a limited-risk app, logging automated decisions, incidents, and complaints, and gating material AI changes behind a review, costs little and pays off the moment anyone asks how your system behaves.

Week four is GDPR and vendor hardening. Write a DPIA for any feature that profiles or processes at scale. Assemble your vendor packet per model provider: signed DPA, SCCs, zero data retention, EU region, transfer impact assessment. A well-documented, roughly one-day setup exists for exactly this on the major APIs, from executing the DPA to requesting zero retention to stripping identifiers before calls - Janus Compliance. The clean division of labor is the takeaway: a founder can DIY the inventory, classification, transparency, literacy, DPIA drafting, and vendor packet; you want counsel for high-risk edge cases, Annex IV validation, and audit response - annexops.

This is also where the way you build the product matters, because compliance is far cheaper when it is scaffolded from the start than when it is retrofitted. When you generate an application with an autonomous builder like Founden, the compliant surfaces (a privacy policy, terms of service, an AI-interaction disclosure in the chat UI, and sane data handling) come with the app rather than as a later scramble, and the deployment already sits in your own infrastructure so the data-residency question has a clean answer. That does not transfer the legal duty off your shoulders (you still own the classification), but it removes the busywork so the month above is mostly decisions rather than plumbing. A founder starting a company in 2026 should treat "does my build tool scaffold the compliance surfaces" as a real selection criterion, the same way they weigh payment platforms or hosting.

A brief author's note fits here, because the person behind this guide has lived the high-risk corner of it. Yuma Heymans (@yumahey), who builds Founden, also co-founded HeroHunt.ai, an autonomous AI recruiter that operates squarely in the employment-screening category the Act flags as high-risk, so the classification questions in this piece are not abstract to him but the daily reality of shipping AI into one of Europe's most scrutinized use cases.

11. What comes next: standards, agents, and the Brussels effect

Look forward, because a compliance posture built only for today's text ages badly, and the moving parts here are unusually active. The most important pending piece is the harmonized standards from CEN-CENELEC's JTC 21, which as of mid-2026 remained unpublished, with the first quality-management standard (EN 18286) only reaching approval stage - CEN-CENELEC. Their absence was a core reason the high-risk deadline slipped, because without them there is no presumption of conformity to lean on. When they land (targeted for late 2026), they will turn today's abstract obligations into concrete, checkable requirements, and following one will become the practical route to demonstrate compliance. Watch for them, because they will define what "good" actually looks like.

The second moving piece is the GDPR side of the Omnibus, which is a separate, slower file that is not yet law. The Commission proposed easing the lawful basis for AI training and adjusting the definition of personal data, but the EDPB and EDPS issued a cautionary joint opinion in January 2026, and privacy practitioners argued the amendments "miss the mark". The blunt implication for founders: do not assume you can now train freely on personal data, because the rules that would allow it are contested and unadopted. Plan on today's stricter GDPR reality and treat any relaxation as a future upside, not a present permission.

The third and most interesting frontier is AI agents and autonomous businesses, where the Act's assumptions start to strain. The law was written around AI systems with identifiable providers and deployers, but the emerging pattern is software that acts continuously and semi-independently across many tasks. When an agent negotiates, transacts, or makes decisions on a founder's behalf, the provider-deployer line and the "automated decision" question from Schufa get harder, not easier. This is the structural tension at the heart of the autonomous business model, and it is why builders working on selling to AI agents or agent-run operations should treat compliance as a live design constraint rather than a settled checklist. The regulation will chase the technology, and the builders closest to the frontier will shape how.

The deepest point is strategic, and it inverts the usual founder complaint about regulation. The AI Act's extraterritorial reach means it functions as a global floor: comply for Europe and you have largely complied everywhere, because the cheapest architecture for a global product is one that meets the strictest applicable rule. That turns compliance from a pure cost into a moat. A small builder who can credibly say "we are EU-compliant, here is our classification and our data handling" can sell into European enterprises that will not touch a vendor who cannot. The rise of the solopreneur and the one-person AI company is real, and in a regulated market the operators who treat legibility as a feature will out-sell the ones who treat it as friction, especially when they are pitching the European investors and accelerators who now ask about it in diligence.

12. Conclusion: a decision framework you can act on

Step back to the first principle, because it collapses a thousand pages of regulation into a decision you can make. The EU regulates AI by consequence and by reach: it asks what your software does to a person and whether that reaches Europe, and it scales the duty to the answer. Every specific obligation in this guide is downstream of those two questions. Get them right and the rest is procedure. Get them wrong and no amount of tooling saves you.

So here is the framework, in the order a founder should run it. First, screen for prohibited use, because that tier has no compliance path and now includes the December 2026 bans on intimate-imagery and CSAM generation. Second, classify against Annex III, remembering that the profiling kill-switch usually closes the escape hatch for HR, credit, and insurance, and that most chatbots and generators land safely in limited-risk. Third, fix your role, knowing that building on an API makes you a deployer until Article 25 flips you. Fourth, ship the live duties now: Article 50 transparency and content marking by 2 December 2026, AI literacy, and the full weight of GDPR that never paused. Fifth, if you are high-risk, use the runway to December 2027 to build the risk-management, documentation, and oversight program, because it is real engineering, not a last-minute form.

The honest bottom line for a small AI builder in 2026 is more reassuring than the headlines suggest and more demanding than the "it got delayed" relief implies. The existential fines sit in the prohibited tier, which you can avoid by design, and the SME cap takes the worst case down to a proportionate percentage of turnover. The heavy high-risk machinery is deferred and, for most founders, does not apply at all. What is left, transparency, literacy, prohibited-use screening, and GDPR, is genuinely achievable in a focused month, largely with free tools and clear documentation. The teams that treat that month as a product investment rather than a tax will find that "EU-compliant" is a phrase that opens doors in the world's second-largest economy, and that building the compliant surfaces in from the start, whether by hand or with a builder like Founden that scaffolds them for you, is far cheaper than retrofitting them under a deadline. Do the classification, ship the disclosures, document your reasoning, and you will be shipping in Europe long after the panic has passed. For the deeper build questions underneath all of this, from what it costs to build an app with AI to how to build one at all, the same principle holds: understand the structure, then let the tools handle the rest.

This guide reflects the state of EU AI regulation as of August 2026. The Digital Omnibus (Regulation (EU) 2026/1744), the pending GDPR-side Omnibus, the CEN-CENELEC harmonized standards, and vendor data terms are all moving. Dates, thresholds, and requirements change: verify current details, and take qualified legal advice for any high-risk system, before you ship. This is general information, not legal advice.