What the AI Act's Steep Fines Means for SaaS Founders in Europe

Direct answer: If your SaaS product uses AI in any customer-facing or decision-making capacity and you have EU users, the AI Act's enforcement regime now applies to you regardless of where your company is incorporated, and the penalties for getting it wrong — up to €15 million or 3% of global annual turnover — are large enough to threaten a startup's runway outright.

For most of the two years since the AI Act passed, "compliance" was something founders filed away as a someday problem, the kind of thing you'd get to once you had a legal team and a Series B. That window is closing. As of August 2026, non-compliance with the AI Act is now risking fines up to €15 million or 3% of global turnover, whichever is higher, according to reporting from Euronews earlier this month. That figure isn't a proposal or a draft threshold anymore. It's the number regulators are working from as enforcement actions start moving from warning letters to actual penalty proceedings.

The reason this matters more for SaaS founders specifically than for almost any other type of company is structural. A SaaS product ships continuously, it accumulates AI features incrementally (a recommendation engine here, an AI support bot there, an automated underwriting or scoring feature somewhere in the middle), and none of those additions individually feel like "building an AI system" in the regulatory sense. But the AI Act doesn't care how incrementally a feature was added. It cares what the feature does, who it affects, and whether the company built the documentation and oversight the regulation requires. We build a lot of the underlying software for early and growth-stage SaaS teams through our custom software development work, and this is one of the few moments where a slow, careful architectural response is genuinely the fast path — retrofitting compliance into a system that wasn't designed for it is far more expensive than building it in from the start.

What Actually Changed in the AI Act's Enforcement This Year?

The AI Act itself isn't new — it was adopted in 2024 with a staggered implementation timeline, and different obligations came into force at different points as the EU phased in prohibitions, then transparency requirements, then the heavier high-risk system obligations. What's changed by August 2026 is that enforcement infrastructure has caught up to the law on paper. National competent authorities across EU member states now have functioning complaint intake processes, and the European AI Office has started coordinating cross-border cases involving companies that serve EU users without an EU headquarters.

For a founder, the practical shift is this: a year ago, the AI Act was a compliance item on a due diligence checklist that investors sometimes asked about. Today, it's an active enforcement regime with real financial teeth, and the fine structure was deliberately modeled on the same "percentage of global turnover" logic that made GDPR fines credible threats rather than theoretical ones. A €15 million fine on a company doing €2 million in annual revenue isn't proportional in any meaningful sense, but the regulation doesn't scale down for small companies the way founders sometimes assume it will. The percentage-of-turnover mechanism exists specifically so that a large company can't treat the fine as a rounding error, and a small company doesn't get a pass just because its absolute exposure is smaller than a competitor's.

Does This Apply to You If Your Company Isn't Based in the EU?

This is the question we hear most often from founders who assume the AI Act is a European problem for European companies. It isn't. The AI Act applies extraterritorially in the same way GDPR does: if your product's output is used within the EU, or if you're marketing an AI system to users located in the EU, the regulation reaches your company regardless of where you're incorporated or where your servers sit.

For a US-based, India-based, or anywhere-based SaaS company with even a modest EU customer base, this means the compliance obligation exists the moment you have EU users interacting with an in-scope AI feature — not the moment you open an EU legal entity. We don't have a specific figure for how many non-EU SaaS companies currently have EU-facing AI features without a compliance program in place, and we're not going to invent one. What we can say with confidence, reasoning from the structure of the regulation itself, is that any company treating "we're not based there" as a shield is working from an outdated read of how extraterritorial digital regulation has actually played out over the last decade.

The Practical Test

A reasonable working test for founders: if you can see EU-based accounts, EU-based usage, or EU-based revenue in your own analytics dashboard, and any part of your product's decision-making, content generation, scoring, or recommendation logic runs on a model or algorithm, you should assume you're in scope until a lawyer tells you otherwise. Don't wait for the ambiguity to resolve itself — the fine structure isn't forgiving of "we weren't sure."

What Counts as "High-Risk" AI in a Typical SaaS Product?

The AI Act uses a tiered risk classification, and most of the enforcement attention (and nearly all of the €15 million-tier exposure) sits with systems classified as "high-risk." The category is broader than most founders initially assume. It's not just facial recognition and autonomous vehicles. In a typical SaaS context, high-risk classification frequently applies to:

• AI used in employment decisions — resume screening, candidate ranking, or performance evaluation tools
• AI used in credit, insurance, or financial risk scoring
• AI that makes or materially influences decisions about access to essential services
• AI systems used in educational assessment or admissions contexts
• Certain categories of biometric identification, even when used for something as mundane as fraud prevention

Lower-risk categories — a support chatbot, a content recommendation feed, an internal productivity tool — carry lighter obligations, mostly centered on transparency (telling users they're interacting with AI) rather than the full high-risk compliance package. But the line between "assistive tool" and "decision-making system" is often thinner than it looks from the product roadmap. A support bot that only answers FAQs is low-risk. The same bot, once it starts approving or denying refund requests autonomously, has crossed into a different regulatory category, and most teams don't notice the crossing because it happened through a series of small feature additions rather than one deliberate decision.

What Does Compliance Actually Look Like Inside Your Codebase?

This is where the AI Act stops being a legal document and starts being an engineering problem, and it's the part founders consistently underestimate. Compliance isn't a policy you write and file away. For a high-risk system, it requires:

• A documented risk management system covering the AI feature's full lifecycle, not just its initial design
• Data governance records showing what data trained or feeds the system, where it came from, and how quality and bias were assessed
• Technical documentation detailed enough that a regulator could reconstruct how the system makes decisions
• Logging and traceability — the system needs to record its own decisions in a way that supports after-the-fact audit, which means your architecture needs structured, queryable logs, not just application debug output
• Human oversight mechanisms — a genuine ability for a human to review, override, or halt an automated decision, not a rubber-stamp "human in the loop" that never actually intervenes
• Ongoing monitoring for performance drift and failure modes after deployment, not just a one-time pre-launch check

Every one of these is a software requirement before it's a legal one. Logging and traceability in particular is almost always underbuilt in early-stage SaaS products, because founders optimize early architecture for shipping speed, not auditability. Retrofitting structured, decision-level logging into a system that was built around simple application logs is a real engineering project — sometimes a bigger one than the original AI feature took to build. This is the kind of gap that shows up specifically in custom software development work, because off-the-shelf AI feature toolkits rarely ship with regulator-grade audit trails out of the box.

If your product also handles the kind of customer data that AI decisions typically touch — financial records, health information, employment history — the compliance work here overlaps heavily with the broader discipline covered in our SaaS Security Checklist: Protecting Customer Data From Day One. The two problems, AI Act compliance and baseline data security, tend to get solved by the same underlying architectural decisions: strict access control, auditable data flows, and a system that was designed to be inspected rather than one that merely works.

What About Data You've Already Collected From EU Users?

A question we get from teams doing this retroactively: does the AI Act reach backward into historical data, or only into decisions made from the compliance date forward? The safer working assumption is that any data currently feeding a live high-risk system needs to meet the same governance standard as new data, even if it was originally collected before you were thinking about the AI Act at all. Practically, this usually means an audit of your existing training and feature data to confirm you can answer basic provenance questions — where it came from, whether it was collected with appropriate consent, whether it's been assessed for bias — rather than a requirement to delete and re-collect everything from scratch. Most teams find the gap is documentation, not the underlying data itself.

Who's Actually Liable When an AI Feature Gets It Wrong?

Founders often assume that using a third-party model — OpenAI's API, Anthropic's API, a fine-tuned open-source model hosted elsewhere — pushes the compliance burden onto the model provider. It doesn't, not fully. The AI Act draws a distinction between the provider of a general-purpose AI model and the deployer who integrates that model into a product and puts it in front of end users. As the deployer, you inherit substantial obligations regardless of whose model sits underneath your feature, particularly around how the system is used, what it's used for, and what oversight exists around its outputs in your specific product context.

This liability question — who's actually on the hook when an automated system produces a bad outcome — is a genuinely unsettled area that goes well beyond the AI Act's specific fine structure, and it's worth understanding in more depth than a single article section can cover. We wrote a longer breakdown of how this plays out across governance frameworks in AI Agent Governance and Liability: Who's Actually on the Hook When Agents Act, which is worth reading in full if your product includes any autonomous or semi-autonomous AI behavior.

How Much Does This Cost to Address?

There's no single number here, because the cost depends entirely on how far your current architecture is from what the regulation requires, and that gap varies enormously between a company that built AI features with logging and access control in mind from day one, and a company that bolted an API call onto an existing feature over a weekend. That said, most compliance-driven engineering engagements for SaaS products fall into a few recognizable tiers of scope:

Tier	Typical scope	Investment
Essential	Risk classification review, transparency notices, basic decision logging added to one or two AI features	$1,000
Growth	Full audit trail architecture across all AI-touching features, human oversight controls, documented data governance	$2,000
Enterprise	Multi-system compliance program, ongoing monitoring infrastructure, integration with existing compliance/legal tooling, ongoing retainer support	$4,000+

These figures reflect what a project like this typically costs to build or fix as a one-time engineering engagement — they don't include legal counsel fees for the underlying risk classification opinion, which is a separate (and necessary) line item most founders will want from an EU-qualified lawyer regardless of the engineering scope. The engineering cost and the legal cost solve different halves of the same problem: the lawyer tells you what the regulation requires of your specific product, and the engineering work makes your product actually capable of demonstrating that requirement is met.

How Long Does This Actually Take?

For a single AI feature with a clear risk classification, a focused compliance-oriented engineering pass — adding structured logging, building a basic human-override path, documenting the data flow — typically runs two to four weeks for a small, well-scoped feature. For a SaaS product with AI touching multiple parts of the user journey (onboarding scoring, in-app recommendations, an automated support layer), the realistic timeline stretches to six to twelve weeks, largely because the audit and documentation work has to happen feature by feature rather than as one blanket change.

The timeline pressure point most founders miss is that this work doesn't need to block your existing roadmap, but it does need to start before your existing roadmap adds more AI surface area. Every new AI feature shipped without compliance architecture in place is additional retrofit debt, and that debt compounds the same way technical debt always does — the second AI feature is harder to retrofit than the first because now two systems need to talk to a shared audit layer that doesn't exist yet.

What Happens If You Just Wait This Out?

Some founders reason that enforcement against a small, non-EU-headquartered SaaS company is unlikely enough to be worth the risk, at least until the product has more revenue and can absorb the compliance cost more comfortably. There are a few problems with that bet. First, enforcement doesn't require the EU to seek you out proactively — a single complaint from an EU-based customer, competitor, or even a disgruntled former employee is enough to trigger a review, and that review doesn't wait for you to be "big enough to notice." Second, the fine structure is percentage-based specifically so that waiting until you're bigger doesn't reduce your exposure — it increases it, because 3% of a larger revenue base is a larger number. Third, and often overlooked, is that enforcement isn't the only consequence: EU enterprise customers doing vendor security and compliance reviews are increasingly asking AI Act compliance questions directly during procurement, which means non-compliance can cost you deals long before it costs you a fine.

There's also a fundraising angle worth naming plainly. Investors doing technical or legal due diligence on a SaaS company with EU exposure are starting to ask AI Act compliance questions as a matter of course, the same way GDPR became a standard diligence line item after 2018. A founder who can't answer clearly is signaling a gap that a careful investor will price into the deal, or walk away from entirely.

Build vs Retrofit: Why This Is an Architecture Problem, Not a Legal One

The single most expensive mistake we see is treating AI Act compliance as a document-writing exercise that happens after the product is built. Compliance documentation is only credible if it accurately describes a system that was actually built to produce it — a data governance policy that claims data lineage tracking is worthless if your codebase has no mechanism to actually trace where a given training example or input came from. Regulators reviewing high-risk systems aren't just reading policy documents; they're checking whether the technical reality matches the paper claim.

This is exactly why we treat this as a custom software development problem rather than a legal-templates problem. Building compliance in as an architectural layer — structured event logging at the point of every automated decision, a permissions model that supports genuine human override rather than a checkbox, a data pipeline that preserves provenance metadata by default — costs meaningfully less than retrofitting the same capability into a system that was never designed to expose it. The pattern is the same one that shows up in every other flavor of technical debt: a decision that would have taken an extra day at design time can take weeks once three other features have been built on top of the assumption that it wasn't needed.

If you're still early enough in your build that this can be designed in from the start rather than bolted on afterward, that's a materially better position to be in, and it's a conversation worth having at the same stage you'd think about MVP Development Company for Startups — architecture decisions made at MVP stage are exactly the ones that determine how painful this retrofit will be later. You can see how we approach these kinds of builds end-to-end on our case studies page.

Key Takeaways

• The AI Act's fines now reach €15 million or 3% of global turnover, whichever is higher, and enforcement infrastructure has caught up to the law as of August 2026.
• The regulation applies extraterritorially — having EU users interacting with an in-scope AI feature is enough to bring your company into scope, regardless of where you're incorporated.
• "High-risk" classification covers more SaaS use cases than founders typically assume, including employment, credit, and access-to-services decisions.
• Compliance requires real engineering work — structured logging, genuine human oversight, documented data governance — not just a policy document.
• Retrofitting compliance into an existing system is significantly more expensive than building it in from the start, which makes early action the financially rational choice, not just the cautious one.
• Using a third-party AI model doesn't transfer your liability as the deployer of that model inside your product.

Given the size of the fines and how quickly retrofit costs escalate, this is worth a real conversation before your next AI feature ships rather than after a compliance gap gets flagged — book a meeting with our team to walk through where your product currently stands.

Frequently Asked Questions

How much does AI Act compliance typically cost for a small SaaS company?

It depends heavily on how many AI features you have in production and how far your current logging and data governance already are from what the regulation requires. A single, well-scoped feature can often be brought into compliance for around $1,000 to $2,000 in engineering work, covering risk classification support, basic audit logging, and a human oversight mechanism. A product with AI touching multiple parts of the user journey — onboarding, recommendations, support — typically runs into the $2,000 to $4,000+ range once you account for documentation and monitoring infrastructure across every feature. This figure covers engineering work only; legal counsel for the actual risk classification opinion is a separate cost most companies also need.

Is AI Act compliance a one-time cost or an ongoing expense?

Both, in practice. There's an initial build cost to bring an existing AI feature into compliance — logging infrastructure, documentation, oversight mechanisms — but the regulation also expects ongoing monitoring for things like performance drift and new failure modes after deployment. Most companies end up treating this similarly to security maintenance: a defined initial project, followed by a lighter ongoing review cadence (quarterly or per major feature release) rather than a one-time certificate you get and forget about.

Does the cost of compliance scale with the number of AI features in my product?

Yes, generally, though not linearly. The first AI feature you bring into compliance is usually the most expensive relative to its size, because you're building the shared infrastructure — the audit logging system, the oversight framework — that every subsequent feature can plug into. Each additional feature after that typically costs less to bring into compliance because it's extending an existing pattern rather than inventing one from scratch, which is why doing this work proactively across your whole product tends to be cheaper than doing it feature-by-feature under pressure.

Can a very early-stage startup get away with a minimal compliance budget?

You can scope the work down to what's proportionate to your actual risk exposure, but "minimal" should mean "focused," not "skipped." If you have one AI feature and a small EU user base, a focused Essential-tier engagement covering risk classification and basic logging for that one feature is a reasonable starting point. What doesn't hold up is treating compliance as optional because the company is small — the fine structure doesn't scale down for company size, only for revenue, and even a modest fine relative to the maximum can be existential for an early-stage company's runway.

What's typically included in a Growth-tier compliance engagement?

A Growth-tier engagement generally covers full audit trail architecture across every AI-touching feature in your product, a genuine human oversight and override mechanism (not just a checkbox), and documented data governance showing what data feeds each system and where it came from. It's the right scope for a company with more than one or two AI features already in production, or one actively expanding its AI surface area, where a single-feature fix wouldn't hold up under real audit scrutiny.

Are there compliance costs beyond the initial engineering build, like audits or legal fees?

Yes. The engineering cost covers making your system technically capable of demonstrating compliance — logging, oversight, documentation infrastructure. Separately, most companies need a lawyer qualified in EU regulation to produce the actual risk classification opinion for their specific product, since that's a legal judgment call, not an engineering one. Depending on your risk tier, you may also eventually need a third-party conformity assessment, which carries its own cost and is distinct from both the legal opinion and the engineering build.

How long does a full AI Act compliance audit take for an existing product?

For a single feature with a clear risk classification, two to four weeks is typical for the engineering side once the risk classification itself is settled. For a product with AI woven through multiple parts of the user journey, six to twelve weeks is more realistic, because the audit and remediation work has to happen feature by feature. The risk classification opinion from legal counsel can run in parallel with early engineering discovery work, which is usually the fastest way to compress the overall timeline.

What's the fastest path to compliance if we're facing an active enforcement inquiry?

If you're already facing an inquiry, the immediate priority is documentation of what exists today, not a full rebuild. Get a clear, honest technical inventory of what your AI features actually do, what data they touch, and what oversight currently exists, and get that in front of legal counsel immediately so they can manage the regulator relationship with accurate information. Engineering remediation should start in parallel on the highest-risk gaps first — usually missing audit logs or absent human override — rather than waiting for a perfect, comprehensive fix before doing anything.

Can compliance work happen alongside a product launch, or does it delay the launch?

It doesn't have to delay a launch if it's planned in from the start, which is exactly why addressing this early is cheaper than addressing it later. Building structured logging and oversight into a new AI feature as it's developed adds relatively little time to the build. What actually causes delays is discovering the gap after a feature has already shipped and needs load-bearing architecture changes retrofitted around live user traffic and existing data.

How often do we need to re-assess compliance after the first pass?

At minimum, any time you materially change an AI feature's function, add a new AI capability, or change the data feeding an existing system. Beyond that, a quarterly review of your highest-risk systems is a reasonable baseline cadence, checking for performance drift, new failure modes, or edge cases the original oversight mechanism didn't anticipate. Treat it the way you'd treat a security review — a fixed cadence, not something that only happens when someone flags a problem.

What documentation does the AI Act actually require from a SaaS product?

For a high-risk system, expect to need: a documented risk management process covering the feature's full lifecycle, records of what data trained or feeds the system and how it was assessed for quality and bias, technical documentation detailed enough to reconstruct the decision logic, and records demonstrating human oversight capability. The exact depth required scales with risk classification — a lower-risk transparency-only system needs far less than a high-risk decision-making system.

Do I need a human reviewing every single AI decision my system makes?

Not every individual decision, but you do need a genuine mechanism by which a human can review, override, or halt the system's decisions, and that mechanism needs to actually function rather than exist only on paper. For high-volume systems, this is usually implemented as sampling-based review plus an escalation path for flagged or disputed decisions, rather than literal human review of every single output, which wouldn't be operationally realistic for most SaaS products.

What is a "conformity assessment" and does my product need one?

A conformity assessment is a formal evaluation — sometimes self-administered, sometimes requiring a third-party notified body — confirming that a high-risk AI system meets the AI Act's requirements before it's placed on the market or put into service. Whether you need one, and which type, depends on your system's specific risk classification, which is why getting a clear legal opinion on classification early is a prerequisite for knowing your actual compliance path rather than guessing at it.

Do I need to log every single AI decision my system makes?

For high-risk systems, yes, at a level of detail sufficient to reconstruct how and why a given decision was made after the fact. This is usually implemented as structured event logging tied to each decision point — inputs considered, output produced, confidence or scoring detail where relevant — rather than raw application debug logs, which typically aren't structured or retained in a way that supports genuine audit.

What technical changes are typically needed to make an AI feature auditable?

The most common gaps are: application logs that capture errors but not decisions, no clear mapping between a given output and the inputs that produced it, and no mechanism for a human reviewer to intervene on a live decision. Closing these gaps usually means adding a structured logging layer at the decision point itself, storing enough context to reconstruct the decision later, and building an internal review interface or workflow rather than relying on raw database queries when a question comes up.

Does using a third-party LLM API shift compliance liability away from us?

No, not fully. The AI Act distinguishes between the provider of the underlying model and the deployer who integrates it into a product for end users. As the deployer, you retain obligations around how the system is used in your specific context, what oversight exists, and what you disclose to users — regardless of whose model sits underneath the feature. Our piece on AI agent governance and liability goes deeper into how this liability split actually plays out.

What is "risk classification" and how do I determine my system's tier?

Risk classification is the process of determining which regulatory tier — prohibited, high-risk, limited-risk (transparency obligations), or minimal-risk — a given AI use case falls into under the AI Act. It depends on what the system does and who it affects, not on the underlying technology. Determining your classification accurately requires legal judgment applied to your specific product, so while engineering teams can flag which features are likely candidates for higher scrutiny, the final classification call should come from qualified counsel.

Do recommendation engines or personalization algorithms count as high-risk?

Usually not, on their own — a content or product recommendation engine typically falls into a lower-risk tier with lighter transparency obligations. The classification changes if the recommendation materially affects access to something like credit, employment, insurance pricing, or essential services, at which point what looked like an ordinary personalization feature crosses into high-risk territory. The determining factor is the consequence of the decision, not the sophistication of the algorithm.

What's the difference between a general-purpose AI model obligation and a high-risk system obligation?

General-purpose AI model obligations apply to the companies building and releasing foundation models themselves (transparency about training data, capability disclosures, and similar), and mostly don't fall on companies simply using those models via an API. High-risk system obligations apply to whoever deploys an AI system — built on any underlying model — into a specific high-risk use case, and that's the category that applies to most SaaS companies building products on top of third-party models.

How does data provenance tracking fit into AI Act compliance?

Data governance requirements under the AI Act expect you to be able to show what data trained or feeds a given AI system and how its quality and potential bias were assessed. Without provenance tracking built into your data pipeline, you can't credibly answer that question after the fact, which is why data lineage tracking tends to be one of the first infrastructure gaps that shows up during a genuine compliance review, even for teams that assumed their data practices were already solid.

What actually happens during an AI Act enforcement investigation?

A national competent authority (or, for cross-border cases, coordination through the European AI Office) typically opens an investigation following a complaint or a proactive review, requests documentation demonstrating your risk classification and compliance measures, and evaluates whether your actual technical implementation matches what your documentation claims. Gaps between paper policy and technical reality are where most penalties originate, which is exactly why documentation that isn't backed by real system capability is a liability rather than a protection.

Who enforces the AI Act against a company based outside the EU?

Enforcement against non-EU companies typically runs through the national authority in the member state where the affected users or the complaint originated, coordinated where necessary through the European AI Office for cross-border cases. Being headquartered outside the EU doesn't remove you from this process — it just means the practical mechanics of the investigation (document requests, response deadlines) happen at a distance rather than in person.

Can a single customer complaint really trigger an investigation?

Yes. Regulatory enforcement under frameworks like this typically doesn't require the regulator to have proactively identified you — a complaint from an affected user, a competitor, or even an internal whistleblower is a standard and common trigger. This is part of why waiting to be "found" isn't a reliable risk-management strategy; you don't control who files the complaint or when.

What's the liability split between us and our AI vendor if something goes wrong?

This is genuinely one of the murkier areas of current AI regulation, and it varies by contract terms with your vendor as well as by the specific regulatory framework in question. In broad terms, the vendor providing the underlying model carries obligations around the model itself, while you as the deployer carry obligations around how that model is used inside your product and what oversight you provide. We cover this liability question in more depth in AI Agent Governance and Liability.

Does having a written AI compliance policy protect us if our implementation doesn't match it?

No — and this is one of the more common and costly misunderstandings. A policy document that describes oversight and logging capabilities your system doesn't actually have is, if anything, evidence against you during an investigation, since it demonstrates the company knew what was required and didn't build it. Documentation needs to accurately reflect real technical capability, not aspirational intent.

Are fines the only real consequence of non-compliance, or are there others?

Fines are the headline consequence, but not the only one. Regulators can also require a non-compliant system to be withdrawn from the market or have its use restricted, which is operationally far more disruptive for a SaaS company than a one-time financial penalty. Beyond direct enforcement, non-compliance increasingly shows up as lost enterprise deals during vendor security reviews, and as a red flag during investor due diligence.

Does AI Act non-compliance affect fundraising or M&A due diligence?

Increasingly, yes. Investors and acquirers doing technical and legal diligence on companies with EU exposure are starting to ask AI Act compliance questions as standard practice, similar to how GDPR became a routine diligence item after 2018. A gap here doesn't necessarily kill a deal, but it does get priced in, either as a valuation discount, an escrow holdback, or a required remediation condition post-close.

Is there a grace period or reduced enforcement for startups and small companies?

The regulation doesn't build in a formal exemption or reduced fine structure based on company size or stage — the percentage-of-turnover mechanism naturally produces smaller absolute fines for smaller companies, but it doesn't create a compliance grace period. In practice, enforcement priority may lean toward larger or higher-impact cases first, but that's a matter of regulator resourcing and discretion, not a guaranteed protection you should plan around.

Is it cheaper to just avoid the EU market entirely rather than deal with compliance?

For a company with minimal or no EU user base already, this is a legitimate strategic option worth weighing against the market opportunity you'd be giving up. For a company that already has EU users or revenue, withdrawing isn't usually cheaper once you account for the customer and revenue loss, and it doesn't retroactively resolve any exposure from before the withdrawal. It's a decision worth making deliberately with legal input, not a default assumption.

Should we build AI Act compliance in-house or bring in outside help?

It depends on whether you already have engineering capacity that understands both your existing architecture and the specific technical requirements the regulation implies — most early-stage teams don't have both, since compliance-grade audit logging and oversight design isn't something most product engineers build regularly. Bringing in outside expertise, either through a specialized legal advisor for classification or a development partner for the engineering build, is usually faster and more reliable than a from-scratch in-house effort, particularly under time pressure.

How does the AI Act compare to GDPR in terms of enforcement strictness?

The two are structurally similar — extraterritorial reach, percentage-of-turnover fines, national authority enforcement coordinated at the EU level — and the AI Act's fine structure was deliberately modeled on GDPR's proven approach. What's different is that AI Act enforcement infrastructure is younger and still building case law and precedent, which means there's currently more ambiguity in how aggressively different national authorities will pursue borderline cases, compared to the now well-established GDPR enforcement pattern.

Are US-based or other non-EU competitors facing the same compliance pressure?

Any company with EU users faces the same regulatory reach, regardless of headquarters location, so a US-based or India-based competitor serving EU customers has identical exposure to a company physically located in the EU. The practical difference is often awareness rather than obligation — non-EU founders are statistically less likely to have this on their radar yet, which is a temporary information gap, not a real difference in legal exposure.

Is hiring a compliance consultant enough, or do we need engineering work too?

A compliance consultant or lawyer can tell you what's required and help with risk classification, but they generally can't build the actual technical capability — the logging infrastructure, oversight mechanisms, and data governance tooling — that your compliance documentation needs to accurately describe. You need both: legal judgment on what's required, and engineering work to make your product actually capable of it.

Should we use a compliance-as-a-service tool instead of custom development?

Off-the-shelf compliance tooling can help with parts of this, particularly documentation templates and basic transparency notices, but most such tools weren't built to integrate deeply with your specific data flows and decision points, which is where the substantive audit-trail and oversight requirements actually live. For anything beyond the lowest-risk tier, custom integration work into your actual codebase is usually necessary rather than optional.

What if we're pre-revenue and can't afford a full compliance build yet?

Scope the work to your actual current risk rather than skipping it. If you have one AI feature and few or no EU users yet, a focused, minimal engagement covering risk classification and basic logging for that one feature is a reasonable and affordable starting point. What you shouldn't do is treat "we can't afford it" as a reason to do nothing, since the exposure exists the moment you have EU users interacting with the feature, not once you can comfortably afford to address it.

What if our AI feature is provided entirely by a third-party vendor, not built by us?

You still carry deployer obligations for how that feature is used and disclosed inside your product, even if you didn't build the underlying model. Review your vendor contract for what compliance support or documentation they provide, but don't assume it covers your own obligations around oversight and disclosure in your specific product context — those typically remain yours to address.

What if we already shipped a non-compliant AI feature — can it be fixed retroactively?

Yes, in almost all cases. Retroactive remediation is exactly what most compliance engineering engagements involve, since very few companies built AI Act compliance in from the start. It's more expensive and slower than building it in originally, but it's a normal, common project, not an unusual or unfixable situation.

What if we're not sure whether our product even counts as an "AI system" under the regulation?

The AI Act's definition of an AI system is broad enough to capture most machine learning and many rule-based automated decision systems, not just large language models. If there's genuine ambiguity, that's exactly the kind of question to bring to legal counsel early rather than assume your way out of scope — a wrong assumption here is the single most common way companies end up unintentionally non-compliant.

What if we only have a handful of EU customers — is it really worth addressing now?

A small EU user base doesn't remove your legal exposure, but it does mean the scope of remediation work is typically smaller and more affordable to address now, while it's still contained. Addressing it while your EU footprint is small is meaningfully cheaper than addressing it after that footprint has grown alongside an unaddressed compliance gap.

What if we plan to pivot away from the EU market later — does the compliance work go to waste?

No. The engineering work involved — structured audit logging, human oversight mechanisms, documented data governance — is generally good practice regardless of geography, and it overlaps substantially with security and auditability work that benefits any SaaS product, EU-facing or not. It's not spend that becomes worthless if your market focus shifts.

What if our AI feature is still experimental or in beta?

Beta status doesn't exempt a feature from the AI Act if it's accessible to real EU users, even a limited group. If the feature is genuinely internal-only and not exposed to any external users, it's typically outside scope until launch, but the moment it goes live to any EU-based customer, even in a limited beta, the same obligations apply as they would for a fully launched feature.

What if we can't get a clear answer from national regulators about our specific case?

This is a common and reasonable frustration, since enforcement guidance is still maturing across member states. In the absence of clear regulator guidance, the safer approach is to build toward the more conservative interpretation of your obligations with qualified legal counsel, document your reasoning, and treat that documentation itself as part of your compliance record — a good-faith, documented interpretation is a meaningfully better position than no analysis at all.

What's the first thing we should actually do this week?

Get a plain-language inventory of every place in your product where an algorithm or model influences a decision, ranking, recommendation, or outcome that reaches an end user — not just your obvious "AI features" but anything with automated decision logic. That inventory is the input both your lawyer and your engineering team need before either can tell you what's actually required.

Who inside the company should own this — engineering, legal, or product?

It needs to be a joint effort, but someone specific needs to own coordination, usually a founder or a senior engineering leader at an early-stage company, since no single function has the full picture on their own. Legal determines classification and requirements, engineering builds the actual capability, and product needs to understand the constraints well enough to avoid shipping new gaps while the existing ones are being closed.

How do we find out which regulatory category our AI system falls into?

Start with a plain description of what the feature does and who it affects, then get that in front of counsel qualified in EU AI regulation for a formal classification opinion. Don't rely on generic online checklists for a final answer — they're useful for initial orientation, but the actual classification is a legal judgment specific to your product's context and consequences.

Should we pause new AI feature development until compliance is settled on existing features?

Not necessarily, but new AI features should be built with compliance architecture in mind from day one rather than added to the pile of features needing retrofit later. Pausing entirely is rarely necessary or commercially realistic; building new features on top of a compliance-aware foundation, even while older features are still being remediated, is usually the more practical path.

What does a typical engagement with Scult look like for this kind of work?

We typically start with a technical discovery pass across your existing AI-touching features to map out where the actual architecture gaps are relative to what compliance requires, then scope the engineering work into the tier that matches your risk exposure — from a single-feature Essential engagement up to a full Enterprise-level compliance program. Where legal classification hasn't already been done, we'll flag that as a parallel workstream you'll need alongside the engineering build, since we handle the software architecture side, not the legal opinion itself.

Can we self-certify our AI Act compliance, or do we always need a third-party assessment?

It depends on your risk classification. Many high-risk categories currently allow self-assessment against the regulation's requirements, provided you maintain the documentation to back it up, while certain categories require assessment by an accredited third-party notified body before the system can be placed on the market. This is another area where the specific answer depends on your product's classification rather than a general rule, so it's worth confirming directly with counsel rather than assuming either path applies by default.

What if we're acquired by or merge with an EU-based company — does their compliance obligation extend to our existing product?

Generally yes, in the sense that once your product is offered under or integrated into an EU-based entity, the same extraterritorial logic that already applies to EU users now applies through the parent or merged company's own EU presence. In practice, this scenario often surfaces compliance gaps during acquisition due diligence rather than after the deal closes, since a careful acquirer will want assurance on this before taking on the liability themselves — which is another reason addressing this proactively protects deal value rather than just avoiding a fine.

How do we get started with Scult on this?

The most useful first step is a conversation about your current AI feature set and where you stand today, so we can give you a realistic sense of scope before any commitment. You can book a meeting directly, and if you're earlier in your build than a full compliance engagement makes sense for, it's worth reading MVP Development Company for Startups first to see how we think about building the right foundation from the start.