The AI Act's Steep Fines: The Checklist SaaS Founders Actually Need in Europe

Direct answer: If your SaaS product uses AI features and serves European users, non-compliance with the AI Act can now cost you up to €15 million or 3% of your global annual turnover, whichever is higher. The safest path is to audit every AI-driven feature in your product against the Act's risk tiers now, document how each one works, and build compliance checkpoints directly into your engineering process rather than treating it as a legal afterthought.

Euronews reported on August 2, 2026 that non-compliance with the EU AI Act is now exposing companies to fines of up to €15 million or 3% of global turnover, a penalty structure that puts AI regulation in the same league as GDPR enforcement. For SaaS founders building or shipping AI features to European customers, this is not an abstract policy update — it's a direct cost-of-doing-business question that touches product decisions, engineering timelines, and how software gets built from day one. Most early and growth-stage SaaS companies added AI features opportunistically over the last two to three years: a chatbot here, a recommendation engine there, an AI-assisted scoring model bolted onto an existing workflow. Very few of those additions were built with a regulatory audit trail in mind, and that gap is exactly what the AI Act's enforcement regime is now designed to expose. This post breaks down what actually changed, why it matters specifically to SaaS founders selling into or operating within Europe, and the concrete checklist your team needs to work through before your next AI feature ships.

What the AI Act's Fine Structure Actually Means

The EU AI Act didn't appear overnight, but the practical bite of it is what changed. A law with fine language on paper is different from a law with enforcement actions and named penalty amounts circulating in mainstream press. Euronews naming the €15 million / 3% of global turnover figure in early August 2026 signals that the enforcement phase is no longer theoretical — regulators are actively applying, or are widely understood to be actively preparing to apply, these penalties against non-compliant companies.

For a SaaS company, "global turnover" is the detail that should get attention. This isn't a fine scoped to European revenue alone — it's calculated against your entire company's global revenue, which means a company earning most of its money outside Europe but selling even a modest subscription tier to EU customers is still exposed to a fine calculated on its total business. That structural choice, mirroring how GDPR fines work, is deliberate: it removes the incentive to treat European compliance as a rounding error against a small regional revenue line.

Why This Isn't Just a Legal Department Problem

The instinct at many SaaS companies is to route this to legal or a compliance consultant and consider the product and engineering teams uninvolved. That instinct is wrong, and it's wrong in a way that matters for founders specifically. The AI Act's risk categories — unacceptable risk, high risk, limited risk, and minimal risk — are determined by what your software actually does: how it makes decisions, what data it processes, whether it affects things like employment, credit, or access to services, and how transparent its outputs are to the end user. Those are product and engineering questions, not legal ones. A lawyer can tell you what the rules say. Only your engineering team can tell you, precisely, which of your AI features fall into which category, because that requires knowing exactly how each model or feature is built and what it's connected to.

This is also why treating the fine structure as a one-time legal review misses the point. A lawyer reviewing your terms of service can confirm that your privacy language is current, but they cannot tell you whether the scoring logic buried in your onboarding flow quietly reclassifies a user's risk tier based on signals that would count as sensitive under the Act. That distinction — between what a document says and what a system does — is exactly where most SaaS companies are exposed right now, because nobody on the founding team has been assigned to close the gap between the two.

Why the Timing Matters Now, Not Later

Regulatory frameworks tend to have a quiet phase-in period followed by a much noisier enforcement phase, and the language in the Euronews report suggests the AI Act has moved into the latter. Fine amounts that exist only on paper create a different incentive structure than fine amounts that are being actively discussed as a near-term operational risk in mainstream financial and technology press. For a SaaS founder, this shift changes the calculus: a compliance gap that was tolerable to defer six months ago is now a gap that could show up in a board conversation, an investor's due diligence checklist, or a customer's procurement questionnaire before your next fundraising round closes.

Why This Matters Specifically for SaaS Founders in Europe

If you're a SaaS founder with European customers, three things make this trend more urgent for you than for a company selling primarily in a single unregulated market.

First, SaaS products iterate fast, and iteration speed is precisely what regulatory compliance struggles to keep pace with. A feature that ships in a sprint and is reworked the next sprint doesn't naturally generate the kind of documentation trail regulators expect. If your engineering culture optimizes purely for shipping velocity, you likely don't have records of when an AI feature changed, what data it was trained or fine-tuned on, or how its risk classification might have shifted as the feature evolved.

Second, SaaS companies frequently embed AI features from third-party providers — a large language model API, a recommendation engine, a fraud-detection vendor — without necessarily understanding or documenting how those upstream systems make decisions. Under the AI Act, you as the deploying company can still carry compliance obligations even when the underlying model was built by someone else. Founders often assume that using a well-known AI provider transfers the compliance burden to that provider. It does not automatically do so, and this assumption is one of the more expensive mistakes a growing SaaS company can make.

Third, European enterprise buyers are increasingly asking about AI Act compliance directly in procurement conversations. Even setting aside the fine risk, a SaaS company that can't clearly answer "which risk tier does your AI feature fall into and what's your documentation" is going to lose deals to a company that can answer that question cleanly and quickly.

There's a fourth factor worth naming directly, because it's specific to the founder stage rather than the enterprise stage: cap tables and investor terms. A fine calculated against global turnover is exactly the kind of contingent liability that shows up in an acquisition or later-round due diligence process as a material risk item. Founders who assume this only matters once they're large enough to be "on the radar" are underestimating how thoroughly diligence processes now probe AI-related regulatory exposure, precisely because so many SaaS companies added AI features without a compliance plan attached.

The Compounding Cost of Waiting

Retrofitting compliance into a product built without it in mind is materially more expensive than designing for it from the outset. This mirrors a pattern seen across other engineering disciplines: fixing rate limiting and API security after a system has already shipped without it requires reworking authentication flows, logging, and monitoring that should have existed from day one. AI Act compliance follows the same logic — the earlier documentation, risk classification, and human-oversight mechanisms are built into a feature's architecture, the cheaper and less disruptive they are to maintain as the product grows.

The compounding effect is worth spelling out concretely. A feature built with a logging hook for human-oversight decisions from day one adds a modest amount of engineering time up front. Bolting that same hook onto a feature that's already processing live production traffic, has downstream systems depending on its current output format, and has no existing audit trail to build from, generally takes several times longer and carries a real risk of introducing regressions into a system your customers already rely on. Founders who have been through a late-stage security remediation or a GDPR retrofit will recognize this pattern immediately — it's the same dynamic, just with a different regulatory trigger.

What Changes in Practice for Your Product and Codebase

Understanding the trend intellectually is different from knowing what to actually change in your product. Here's where the AI Act's requirements touch real engineering and product decisions.

Documentation Becomes a Build Requirement, Not an Afterthought

Every AI-driven feature needs a record of what it does, what data feeds it, what its intended use is, and what its known limitations are. This isn't a marketing description — it needs to be technical and specific enough that an auditor or regulator could review it and understand the system's actual behavior. If your team doesn't already maintain this kind of documentation as part of the development workflow, building that habit now is far cheaper than reconstructing it under audit pressure later.

In practice, this looks like adding a lightweight but mandatory documentation step to your feature-definition process, alongside whatever your team already does for API contracts or database schema changes. A short technical brief for each AI feature — what problem it solves, what inputs it consumes, what its outputs mean, and how a reviewer can trace a specific decision back to the inputs that produced it — is enough to satisfy most of the documentation expectation, provided it's kept current as the feature changes. The failure mode to avoid is writing this documentation once at launch and never updating it as the model, the data pipeline, or the feature's scope evolves.

Human Oversight Mechanisms Need to Be Designed In

For higher-risk AI applications — anything touching hiring decisions, credit scoring, access to essential services, or biometric processing — the Act expects a mechanism for human review or override of automated decisions. If your product currently lets an AI model make a fully autonomous decision with no review path, that's a structural gap, not a settings toggle you can flip later. Building this into the architecture from the start, with clear logging of when a human reviewed or overrode a model output, is a design decision that belongs at the same level as your data model or your API contract.

Concretely, this usually means three things exist together: a queue or interface where a designated reviewer can see pending or flagged decisions, a way for that reviewer to change the outcome, and a persistent log recording that the review happened, who performed it, and what the original versus final decision was. Many SaaS teams already have something adjacent to this for other purposes — a manual review queue for fraud flags, for instance — which means the pattern isn't unfamiliar. The gap is usually that it hasn't been extended to cover every AI-driven decision that qualifies as higher risk under the Act's criteria.

Transparency Requirements Reach into Your UI

Users interacting with an AI system generally need to know they're interacting with one, and outputs that could materially affect them often need some explanation of how the system arrived at its conclusion. This is where product decisions and interface language intersect directly with compliance. How you phrase an AI disclosure, how prominently you surface it, and how clearly you explain an automated decision are all questions of UX writing and microcopy as much as they are legal requirements — the two disciplines now overlap in a way they didn't two years ago.

Monitoring and Auditability Extend Beyond the Feature Itself

Once an AI feature ships, the Act generally expects ongoing monitoring — tracking how the system performs, whether it drifts from its intended behavior, and whether incidents need to be reported. This connects directly to product analytics discipline. A team that already understands how to instrument and interpret mobile app analytics and the metrics that actually matter has a real head start here, because the instinct to track behavior rigorously rather than superficially is exactly what AI Act monitoring requires — just applied to model behavior and decision outcomes rather than user engagement funnels.

What SaaS Founders Should Actually Do About It

Here is the practical checklist, roughly in the order it should happen.

1. Inventory every AI-touching feature. List every place in your product where a model, a third-party AI API, or an automated scoring/ranking/recommendation system makes or influences a decision. Most founders are surprised by how long this list is once they look carefully.
2. Classify each feature by risk tier. For each item on the inventory, determine what category it likely falls into under the Act's framework, based on what the feature does and who it affects.
3. Document data provenance and model behavior for each feature. Where did the training or fine-tuning data come from, what does the model output, and what are its known failure modes.
4. Build or retrofit human-oversight paths for higher-risk features. Identify where a human review or override mechanism is missing and prioritize adding it.
5. Update user-facing language for AI transparency. Review every screen where an AI system interacts with or affects a user and make sure the disclosure and explanation are clear, not buried.
6. Establish ongoing monitoring for AI feature behavior. Set up tracking that flags drift, errors, or unexpected outcomes, not just uptime and usage.
7. Reassess with every new AI feature, not once and done. Compliance isn't a project with an end date; it's a checkpoint that belongs in your development process going forward.

For most SaaS founders, working through this list touches architecture, backend logic, and product interface simultaneously, which is exactly the kind of cross-cutting work that benefits from experienced Custom Software Development support rather than trying to bolt compliance onto an existing codebase piecemeal. Getting the risk classification and technical documentation right the first time avoids a much more expensive rebuild later.

It's worth being honest about sequencing here too. Founders often want to jump straight to step four or five — building the oversight mechanism or rewriting the disclosure language — because those feel like the most visible, tangible fixes. But skipping the inventory and classification steps means you risk over-engineering compliance for features that don't need it while missing genuine exposure in a feature nobody thought to flag. The order above exists because each step depends on the accuracy of the one before it: you can't classify risk correctly without a complete inventory, and you can't prioritize oversight work correctly without an accurate risk classification.

What This Kind of Work Typically Costs

Compliance-driven engineering work varies significantly based on how many AI features you have and how deeply they're embedded in your product, but it's useful to frame against Scult's standard service tiers to understand roughly where this kind of project lands.

Tier	Typical scope	Fits this kind of work when...
Essential — $1,000	Focused feature-level work, single-system audits and fixes	You have one or two AI features to document, classify, and adjust
Growth — $2,000	Multi-feature audits, oversight mechanism builds, UI transparency updates	Your product has several AI-driven flows across different parts of the app
Enterprise — $4,000+	Full-product AI risk inventory, architecture-level compliance rebuilds, ongoing monitoring systems	AI is core to your product and touches high-risk categories like hiring, credit, or biometric data

These figures reflect the kind of engagement scope typical for this category of work, not a fixed quote — actual cost depends on your product's specific architecture and how many features are involved.

Key Takeaways

• The AI Act's fines — up to €15 million or 3% of global turnover — are calculated against your whole company's revenue, not just European revenue, so exposure is larger than founders often assume.
• Compliance is a product and engineering responsibility, not something that can be fully delegated to a legal team, because risk classification depends on how features actually work.
• Using a third-party AI provider doesn't automatically transfer compliance obligations to that provider — you likely still carry responsibility as the deploying company.
• Documentation, human-oversight mechanisms, and transparent UI language need to be built into the feature itself, not added after the fact.
• Ongoing monitoring of AI feature behavior is an explicit expectation, not a one-time audit.
• Retrofitting compliance into an already-shipped product costs meaningfully more than designing for it from the start.

Getting ahead of this now is far less disruptive than reacting to it under audit pressure later. If you want help auditing your product's AI features and building a compliance-ready roadmap, book a meeting with our team.

Frequently Asked Questions

What is the EU AI Act in plain terms?

The EU AI Act is a regulation that classifies AI systems by risk level and imposes requirements — ranging from documentation to outright bans — based on that classification. It applies to companies operating in or serving the EU market, regardless of where the company is headquartered.

Does the AI Act apply to my SaaS company if we're not based in Europe?

Yes, if your product serves users located in the EU, the Act's obligations generally apply to you regardless of where your company is incorporated. This is similar in structure to how GDPR applies based on user location rather than company location.

What exactly did Euronews report on August 2, 2026?

Euronews reported that non-compliance with the AI Act now risks fines of up to €15 million or 3% of a company's global turnover, whichever is higher, signaling that enforcement of these penalties is becoming a real operational risk rather than a theoretical one.

Is the 3% figure based on EU revenue or total company revenue?

It's calculated against global turnover, meaning your company's total worldwide revenue, not just the portion earned in Europe. This makes the fine exposure significant even for companies with a small European customer base.

How do I know if my AI feature is "high risk" under the Act?

Risk classification depends on what the feature does and who it affects — features touching employment decisions, credit scoring, access to essential services, or biometric identification tend to fall into higher-risk categories. A technical audit of each feature against the Act's criteria is the only reliable way to classify it accurately.

We just use a third-party AI API — are we still responsible for compliance?

In many cases, yes. Deploying a third-party model inside your product can still make you responsible for certain compliance obligations, even though you didn't build the underlying model yourself.

What counts as an "AI feature" for this purpose?

Anything where a model, algorithm, or automated system makes or meaningfully influences a decision — recommendation engines, chatbots, scoring systems, fraud detection, content moderation, and personalization systems can all qualify depending on how they're used.

Do simple recommendation algorithms count, or just advanced generative AI?

The Act isn't limited to generative AI or large language models — traditional machine learning systems used for scoring, ranking, or decision-making can also fall under its scope depending on their application and impact.

What documentation do we actually need to keep?

Generally, documentation covering what the feature does, what data it uses, its intended purpose, known limitations, and how outcomes are monitored over time. The specific depth required scales with the feature's risk classification.

How long does an AI feature audit typically take?

It depends heavily on how many AI-touching features your product has and how well-documented they already are. A single-feature audit can be a short, focused engagement, while a full-product inventory across a mature SaaS platform takes considerably longer.

Can we handle this compliance work internally, or do we need outside help?

Many teams can handle straightforward classification and documentation internally if they have the bandwidth. Where it tends to help to bring in outside support is when the audit needs to happen quickly, spans multiple product areas, or when the team lacks spare engineering capacity to do it alongside regular roadmap work.

What happens if we're found non-compliant but fix it quickly?

Regulatory processes generally consider remediation efforts, but the specifics of any given enforcement action depend on the regulator and circumstances. The better strategy is avoiding non-compliance in the first place rather than relying on a fast fix after the fact.

Does this affect our fundraising or due diligence process?

Increasingly, yes. Investors and enterprise customers doing due diligence on SaaS companies with AI features are starting to ask about regulatory exposure, and a company that can answer clearly is in a stronger negotiating position.

How does this connect to GDPR compliance we already have?

There's overlap, particularly around data provenance and user transparency, but the AI Act adds requirements specific to automated decision-making and model behavior that go beyond what GDPR alone covers. Having GDPR compliance in place is a helpful foundation, not a substitute.

What's the difference between "limited risk" and "high risk" AI systems under the Act?

Limited-risk systems generally carry transparency obligations, like disclosing that a user is interacting with an AI system. High-risk systems carry more substantial requirements, including human oversight, detailed documentation, and ongoing monitoring.

Should we pause shipping new AI features until we're compliant?

Not necessarily, but any new AI feature should go through risk classification and documentation as part of its build process rather than being shipped first and evaluated later. Building compliance into the development workflow avoids the need to pause anything.

How do human-oversight requirements actually work in a live product?

In practice, this usually means a mechanism where a person can review, override, or intervene in a decision the AI system made — logged in a way that shows the oversight actually happened, not just that it was theoretically possible.

What if our AI feature is fully automated with no human in the loop today?

That's a common starting point, but for higher-risk features it represents a gap that needs addressing. Adding a review or override mechanism is an architectural change, so it's worth planning for rather than treating as a quick patch.

Does the size of our company matter for enforcement risk?

Smaller companies aren't automatically exempt, though enforcement priorities can vary. The turnover-based fine structure means the absolute fine amount scales with your revenue, but the compliance obligations themselves generally apply regardless of company size.

How often should we reassess our AI features for compliance?

Reassessment should happen whenever a feature changes meaningfully — a new model, a new use case, a new data source — rather than as a one-time exercise. Treating it as a recurring checkpoint in your development process is more sustainable than an annual audit alone.

What's the risk of just ignoring this until it becomes a problem?

Given the fine structure reported by Euronews, waiting until a regulator or auditor flags an issue is considerably more expensive and disruptive than addressing it proactively, both in direct fine exposure and in the cost of an emergency remediation project.

Can our existing engineering team handle the technical documentation requirements?

Often yes, especially with guidance on what format and depth regulators expect. The main challenge is usually finding the time within existing roadmap priorities rather than a lack of technical capability.

Does this apply to internal AI tools we use, not just customer-facing features?

The Act's focus is generally on AI systems that affect people's rights, safety, or access to services, so purely internal tools with no external impact may carry different obligations than customer-facing ones. It's still worth reviewing internal tools that touch employment or HR decisions, since those can qualify as higher risk.

What's the first thing we should do this week if we haven't started?

Start with the inventory step: list every AI-touching feature in your product. You can't classify or document risk for features you haven't identified yet, so this is the foundational first move.

How does UI language factor into compliance?

Users need to understand when they're interacting with an AI system and, in many cases, understand how an automated decision affecting them was reached. This makes clear, honest interface copy a compliance requirement, not just a UX nicety.

What if our product operates in multiple regions with different AI regulations?

You'll likely need to design for the strictest applicable requirement across your markets, or build region-specific handling for features that trigger obligations only in certain jurisdictions. This adds architectural complexity worth planning for early.

Are there specific AI use cases the Act treats as unacceptable, not just high-risk?

Yes, certain use cases are treated as carrying unacceptable risk and are prohibited outright rather than merely regulated, generally involving things like manipulative techniques or certain forms of biometric surveillance. Reviewing your feature list against these prohibited categories should be an early step in any audit.

How does monitoring for AI drift actually work in practice?

It typically involves tracking model outputs and decision patterns over time to detect when behavior shifts from what was originally documented and validated, similar in spirit to how you'd monitor any production system for anomalies, but focused on decision quality and fairness rather than uptime alone.

What role does data provenance play in compliance?

Knowing where your training or fine-tuning data came from, how it was collected, and whether it introduces bias is part of the documentation expected for many AI features, particularly higher-risk ones.

Is there a certification or approval process we need to go through?

Requirements vary by risk category, with some high-risk systems requiring more formal conformity assessment processes. Lower-risk features generally require self-documentation and monitoring rather than external certification.

How do we handle AI features built on open-source models we've fine-tuned ourselves?

You generally carry more direct responsibility for models you've fine-tuned yourself, since you're closer to the training data and behavior than if you were using an unmodified third-party API. Documentation obligations tend to be more detailed in this case.

What's a realistic timeline for getting a mid-sized SaaS product compliant?

It depends heavily on how many AI features are in scope and how much documentation already exists, but treating it as a phased project — inventory, classification, documentation, oversight mechanisms, monitoring — tends to be more realistic than trying to complete everything at once.

Can non-compliance affect our ability to sell to enterprise customers in Europe?

Increasingly yes, as procurement teams at larger European companies are starting to ask about AI Act compliance directly during vendor evaluation, independent of the fine risk itself.

What's the relationship between API security and AI Act compliance?

They're related but distinct — strong API security and rate limiting protects your systems from abuse, while AI Act compliance governs how your AI features make decisions and how transparent and accountable those decisions are. Both matter for a mature, defensible product.

Does this affect how we track and interpret product analytics?

Yes, in the sense that monitoring AI feature behavior needs the same rigor teams already apply to broader app analytics and metrics tracking, just extended to cover model decisions and outcomes rather than only engagement and usage.

What if we're a very early-stage startup — does this still apply to us?

If you have European users interacting with AI features in your product, the obligations generally apply regardless of company stage, though the scope and complexity of what you need to do will typically be smaller for an early-stage product with fewer features.

How should we prioritize which features to audit first?

Start with features most likely to fall into higher-risk categories — anything touching hiring, credit, access to services, or biometric data — since those carry the most significant compliance obligations and the most severe consequences if mishandled.

What's the cost difference between building compliance in now versus retrofitting later?

Retrofitting typically requires reworking architecture decisions that are much cheaper to make correctly the first time, similar to how adding security or scalability considerations after launch costs more than designing for them upfront.

Do we need a dedicated compliance team, or can this be handled by existing product and engineering staff?

For many SaaS companies, existing product and engineering staff can handle this with the right guidance and process changes, without necessarily needing a dedicated compliance hire, at least in the early phases.

How do we explain an AI Act audit project to our board or investors?

Frame it as risk management tied to a specific, quantifiable exposure — the fine structure reported by Euronews — paired with a competitive advantage in enterprise sales conversations where compliance readiness increasingly matters.

What if our AI feature only affects a small percentage of our user base?

Scope of impact can factor into risk assessment, but even a feature affecting a small user segment can carry meaningful compliance obligations if it touches a high-risk category like employment or credit decisions.

Are there ongoing costs after the initial compliance work is done?

Yes, ongoing monitoring and periodic reassessment are expected to continue as your product evolves, rather than being a one-time project with a fixed end date.

How does this interact with our existing terms of service and privacy policy?

Your terms of service and privacy policy may need updates to reflect AI-specific disclosures required under the Act, in addition to whatever technical and architectural changes are needed within the product itself.

What's the biggest mistake SaaS founders make with AI Act compliance?

Assuming it's purely a legal or paperwork exercise rather than something requiring real engineering and product changes. The features themselves, not just the documentation around them, often need to change.

Can we use AI to help us with AI Act compliance itself?

AI tools can help with parts of the documentation and monitoring process, but the underlying risk classification and architectural decisions still require careful human judgment, especially given how much is at stake financially.

How do we handle compliance for AI features still in beta or experimental stages?

It's worth applying the same risk-classification discipline to beta features as to fully launched ones, since regulatory obligations generally aren't contingent on a feature's launch status.

What should be in our incident response plan for an AI feature that behaves unexpectedly?

A plan that includes detection, a clear escalation path, a way to disable or roll back the feature, and documentation of what happened and how it was resolved — treating an AI incident with the same seriousness as a security incident.

How do we keep this from slowing down our product velocity long-term?

Building risk classification, documentation, and oversight checks into your standard feature development process — rather than as a separate compliance gate — keeps things moving without treating each new AI feature as an emergency review.

Where should we start if we want outside help with this?

Start with an inventory and initial risk assessment conversation to understand the scope of work involved, which is exactly the kind of engagement Custom Software Development support is built to handle for SaaS products with AI features embedded across the product.

What does the future of AI regulation in Europe look like beyond this fine structure?

Enforcement is likely to become more active and specific over time as regulators build case history, which means the compliance bar will likely rise rather than stay static — building good habits now positions your team well for whatever comes next.