Beyond the Headlines: What the EU AI Office's Enforcement Launch Really Means for B2B Companies in Europe

Direct answer: The EU AI Office has started active enforcement, working alongside national market surveillance authorities in each member state, which means AI-related obligations under EU law are no longer theoretical for B2B companies operating in Europe. If your product touches AI in any customer-facing or decision-making capacity, you now need documented evidence of how that system works, not just a privacy policy that mentions "AI" in passing.

For years, European AI regulation existed mostly as a planning exercise — something legal teams flagged in slide decks while engineering teams kept shipping. That changed in August 2026, when the EU AI Office confirmed it has begun active enforcement in coordination with national authorities across member states, according to Digital Strategy EC, Aug 2026. This is a structural shift: enforcement bodies that previously issued guidance are now positioned to open inquiries, request documentation, and act on complaints. We don't have a public figure yet on how many inquiries have been opened or which sectors are first in line, and it would be irresponsible to guess — but the pattern from other EU regulatory rollouts (GDPR being the obvious precedent) is that enforcement tends to start with visible, high-traffic digital products before broadening. B2B companies selling into European markets, or running European operations, are exactly the kind of mid-to-large digital footprint that tends to get looked at once an enforcement body is staffed and operating. This post is about what that shift practically means for how you build, document, and maintain the software and AI-adjacent features your business runs on.

What Actually Changed, and Why It's Real

It's worth being precise about what "enforcement launch" means, because the phrase gets thrown around loosely. A regulatory body issuing guidance is different from a regulatory body opening cases. Guidance tells you what's expected; enforcement is when non-compliance has consequences — inquiries, requests for documentation, potential penalties. The EU AI Office moving into active enforcement alongside national authorities means the EU AI Act's obligations have crossed from "read the framework" territory into "produce the evidence" territory.

Why This Isn't Just Another Compliance Headline

B2B companies have seen plenty of regulatory announcements that turned out to be slow-moving. What makes this one different is the coordination structure: the EU AI Office isn't acting alone, it's working alongside national market surveillance authorities. That two-tier structure — a central office plus distributed national enforcement — is the same shape GDPR enforcement took, and it's the shape that eventually produced real fines and real operational change across industries. A coordinated enforcement structure with defined authority is a signal that the exploratory phase is ending. Companies that treated their AI Act obligations as "something to revisit later" no longer have the luxury of an undefined timeline.

The Part That Gets Missed

Most coverage of this story focuses on large AI vendors — the companies literally building foundation models. But the AI Act's obligations, and by extension this enforcement activity, apply much more broadly than that. If your B2B product uses an AI system for anything from lead scoring to automated customer support to risk assessment in a workflow tool, you are a deployer or provider under the Act's framework, and that status carries its own documentation and transparency obligations. This is where a lot of B2B companies are exposed without realizing it — not because they built a foundation model, but because they integrated one into a customer-facing product without formalizing the governance trail around it.

Why This Matters Specifically to B2B Companies in Europe

If you're a B2B company selling software, services, or platforms into European markets — or headquartered there — this enforcement shift changes your risk calculus in a few concrete ways.

First, your customers will start asking. Enterprise buyers in Europe increasingly run vendor due diligence that includes AI governance questions, and a live enforcement environment gives procurement teams a sharper reason to ask them earlier and more specifically. A vague answer about "responsible AI practices" that was acceptable eighteen months ago now reads as a red flag to a buyer's legal team doing its own risk assessment.

Second, the burden of proof has shifted toward documentation you may not currently have. It's one thing to build a feature responsibly; it's another to have the paper trail — model documentation, data provenance notes, human-oversight processes — that an inquiry would actually ask for. B2B companies whose engineering and product teams move fast and iterate constantly are the ones most likely to have gaps here, simply because documentation tends to lag behind shipping velocity.

This is a familiar pattern to anyone who has watched a fast-growing company scale past its own record-keeping. A feature ships under deadline pressure, works well, gets iterated on repeatedly by different engineers over time, and by the time anyone asks "how exactly does this decide what to show a customer," the honest answer is that no single person fully remembers, and no document captures it either. That's not a sign of poor engineering — it's a completely normal outcome of shipping quickly without a deliberate documentation habit. The problem only becomes acute once an external party has both the authority and the intent to ask the question formally.

Third, this affects vendor selection, not just your own product. If you rely on third-party AI tools or embedded models inside your own stack, you inherit some exposure from how well-documented and compliant those tools are. A B2B company that can't explain what an embedded AI vendor's system actually does, or how it was trained, has a harder time answering its own customers' due diligence questions — and a harder time responding to a regulator's request, too.

Fourth, there's a competitive dimension that's easy to overlook. In any market where buyers start asking harder questions of every vendor at once, the companies that already have clean answers gain a real edge over those still scrambling. A sales conversation where one vendor can produce documentation on request and a competing vendor needs three weeks to "check with engineering" doesn't stay neutral for long — procurement teams remember which vendor made their own due diligence process easier. Treating this shift as an opportunity to differentiate, rather than purely a defensive obligation, is a more useful frame for most B2B companies than treating it as pure overhead.

What Changes in Practice for Your Website, Product, and Internal Tools

This is the part that tends to surprise teams: enforcement readiness isn't primarily a legal-team project, it's an engineering and architecture project. A privacy policy update doesn't produce a documented decision trail for how your product's AI features actually behave. That has to be built into how the software itself is structured.

Documentation as a Design Requirement, Not an Afterthought

If an AI-driven feature in your product — a recommendation engine, an automated triage tool, a scoring model — can't be explained in plain terms (what data it uses, what decision it makes, what a human can override), that's a gap regardless of whether anyone has asked yet. Building that explainability in from the start is far cheaper than retrofitting it under time pressure once a customer or regulator asks. This is a strong argument for treating custom software architecture as the place where compliance actually lives, rather than trying to bolt governance onto a black-box third-party tool after the fact. Custom software development gives you the visibility and control to document exactly how a system reaches a decision, because you built the decision logic rather than licensing it opaquely.

Auditability of AI-Touching Features

Every feature that uses AI to make or influence a decision for a European customer needs, at minimum: a plain-language description of what it does, a record of what data feeds it, and a way to show a human reviewed or can override its output where relevant. If your product's AI features are scattered across different vendor integrations with inconsistent documentation, this becomes a genuine engineering problem to solve, not a checkbox to tick. Structured logging and clear service boundaries around AI-driven logic — the same practices that make software easier to maintain and debug — are exactly what make it auditable under this kind of scrutiny.

Your Public-Facing Site Also Matters

It's not only backend logic. If your marketing site or product pages make claims about "AI-powered" capabilities, those claims need to match what the system documented behind them actually does — overstating AI capability publicly is its own kind of exposure once regulators are actively looking. This is also a good moment to make sure your technical content is structured clearly for both human readers and search engines; if you haven't already implemented structured data on your key pages, now is a reasonable time to add schema markup to your website so that product and service claims are represented cleanly and consistently across your site.

Architectural Choices That Help or Hurt

Teams running fragmented front-end architectures — several independently deployed micro-frontends stitched together — sometimes find that AI-driven features live in isolated modules with no shared documentation standard between them. That's not automatically a problem, but it does mean governance has to be deliberately coordinated across those modules rather than assumed. If you're evaluating whether a micro-frontend approach makes sense for a product with multiple AI-touching surfaces, it's worth reading through when micro-frontend architecture makes sense (and when it doesn't) before committing to a structure that could make consistent AI documentation harder to maintain later.

There's a related architectural question worth raising early: how many different teams can independently ship an AI-touching feature without anyone else reviewing it first? In a tightly coupled monolith, a single review gate can catch most new AI features before they reach customers undocumented. In a distributed architecture with many independently deployed services or frontends, that gate has to be replicated deliberately at each boundary, or features slip through with no one accountable for their documentation. Neither structure is inherently wrong for compliance purposes, but the distributed model demands more explicit process discipline to achieve the same level of coverage.

What to Do About It Now

The practical response here isn't panic, it's sequencing. A few steps, done in order, get most B2B companies to a defensible position without a ground-up rebuild.

1. Inventory every AI-touching feature. List every place in your product, internal tools, and customer-facing workflows where an AI system makes or informs a decision. Most teams are surprised by how long this list actually is once support bots, scoring logic, and third-party embedded models are counted.
2. Assess documentation gaps against each item. For each feature, ask: could we produce a plain-language explanation, a data-source record, and evidence of human oversight if asked this week? Where the answer is no, that's your priority list.
3. Fix architecture where it's blocking documentation. If a feature's logic is opaque because it's buried in a third-party black box, evaluate whether a custom-built alternative gives you the transparency you need going forward — this is precisely the kind of decision where owning the logic through Custom Software Development pays for itself in reduced regulatory exposure.
4. Align public claims with documented reality. Audit AI-related language on your website and product marketing against what the underlying systems actually do and can prove.
5. Build the habit, not just the fix. Documentation that gets created once and never updated decays fast in a product that keeps shipping. Bake AI feature documentation into your normal release process so it doesn't become a fire drill every time a rule changes.

None of this needs to happen instantly, but it does need a plan with an owner and a timeline, because "we'll get to it" is a much weaker position in an active enforcement environment than it was a year ago.

It also helps to assign clear ownership internally before you start. A common failure pattern is that AI governance work gets treated as a shared responsibility between legal, product, and engineering, which in practice means no single person is accountable for keeping the inventory current or making sure new features get documented before launch. Naming one owner — even someone who coordinates rather than does all the work themselves — tends to be the difference between a project that gets finished and one that stalls after the first inventory is drafted. That person doesn't need to be a compliance specialist; they need enough technical fluency to translate between what engineering built and what a plain-language explanation of it should say.

Sequencing matters here in a way that's easy to underestimate. Companies that jump straight to rebuilding features before finishing the inventory step often end up rebuilding the wrong things first — usually whichever feature is loudest internally, rather than whichever feature carries the most actual customer or regulatory exposure. The inventory and gap assessment steps are unglamorous, but they're what make the rest of the sequence efficient instead of reactive.

There's also a broader lesson here about how quickly regulatory and operational environments can shift underneath a growing company's international footprint — the same discipline that applies to reading EU enforcement signals early applies to reading manufacturing and supply shifts, like the pattern behind India's rise as a manufacturing alternative to China, where companies that moved early on infrastructure decisions ended up with a real advantage over those who waited for certainty.

Pricing Context: Where This Work Typically Falls

Bringing an AI-touching product into a documented, auditable state is scoped work, and the right tier depends on how much of your system needs rebuilding versus documenting.

Scope of work	Typical tier	What it usually covers
Documentation and audit of existing AI features, minor architecture cleanup	Essential ($1,000)	Feature inventory, gap assessment, targeted fixes to a small number of components
Rebuilding one or more AI-touching features with custom logic for full transparency	Growth ($2,000)	Custom software development on specific decision-making features, structured logging, documentation baked into the build
Full product audit and rebuild across multiple AI-driven workflows, ongoing governance support	Enterprise ($4,000+)	End-to-end architecture review, custom development across the product, sustained documentation processes

These are starting reference points based on Scult's standard service tiers — actual scope depends on how much of your current stack relies on opaque third-party AI components versus systems you already control. Most B2B companies find that the honest answer sits somewhere between the tiers rather than neatly inside one, which is exactly why the inventory and gap-assessment step comes first: it turns a vague sense of "we probably need to do something about AI compliance" into a scoped, priced piece of work with a defined starting point and a clear definition of done.

Key Takeaways

• The EU AI Office has moved from guidance to active enforcement, working alongside national authorities — this is a structural shift, not a headline that will fade.
• B2B companies with any AI-touching feature — scoring, recommendations, automated support — are in scope even if they never built a foundation model themselves.
• Documentation and auditability are engineering problems now, not just legal-team paperwork; systems need to be built so their decisions can be explained.
• Third-party AI vendors and embedded models carry inherited risk — you need to be able to explain what they do, not just that you use them.
• Public claims about "AI-powered" features need to match documented system behavior, including on your own website and marketing pages.
• Custom software development gives you the transparency and control that opaque, licensed AI tools often can't provide when a customer or regulator asks how a decision was made.

Getting ahead of this doesn't require overhauling your entire stack overnight, but it does require an honest inventory and a plan. If you want help figuring out where your AI-touching features stand and what to prioritize first, book a meeting with our team.

Frequently Asked Questions

What is the EU AI Office and what does it actually do?

The EU AI Office is the body responsible for overseeing implementation and enforcement of the EU AI Act at the European level, working in coordination with national market surveillance authorities in individual member states. Its role includes issuing guidance, coordinating enforcement across borders, and handling inquiries related to AI system compliance.

Does "enforcement launch" mean fines are already happening?

Not necessarily — enforcement launch means the office and national authorities are actively positioned to open inquiries and request documentation, not that a specific wave of fines has been announced. The precise volume or timing of penalties isn't publicly detailed in the source material, so it's more accurate to say the operational capacity for enforcement is now live rather than assume punitive action is already widespread.

Does this apply to my company if we're not based in the EU?

If your B2B company sells software, services, or platforms to customers in EU member states, or processes data related to EU users through an AI system, you can fall within scope regardless of where your headquarters sits. Location of incorporation matters less than where your product is deployed and who it affects.

What counts as an "AI system" under this kind of scrutiny?

Broadly, any software component that uses machine learning or similar techniques to make or influence a decision — recommendation engines, scoring models, automated triage, generative content tools, and predictive analytics all typically qualify. A simple rules-based feature without any learned or probabilistic behavior usually would not.

We just use a third-party chatbot plugin — are we exposed?

Yes, potentially. As a deployer of that AI system, you likely carry your own transparency and documentation obligations, even though you didn't build the underlying model. You need to understand and be able to explain what the plugin does with your customers' data and decisions.

What documentation should we actually have ready?

At minimum: a plain-language description of what each AI-touching feature does, where its data comes from, and how a human can review or override its output where relevant. Keeping this current as features change is more important than getting one perfect document written once.

How fast should a B2B company move on this?

There's no single fixed deadline attached to this specific enforcement announcement, but the safer posture is treating it as a near-term priority rather than a future project, given that active enforcement structures tend to accelerate rather than pause. Starting with an inventory this quarter is a reasonable, low-risk first step.

What's the difference between a "provider" and a "deployer" under the AI Act?

A provider builds or substantially modifies an AI system before it goes to market; a deployer uses an AI system built by someone else within their own operations or product. Most B2B companies embedding third-party AI tools fall into the deployer category, which still carries real documentation obligations.

Can our existing privacy policy cover this?

A privacy policy addresses data handling and consent, but it typically doesn't document how an AI system makes decisions, what data trains or feeds it, or how oversight works — which are the things enforcement activity is likely to ask about. Treat them as separate documents serving separate purposes.

What happens if an inquiry is opened and we don't have documentation ready?

The specific procedural consequences aren't detailed in the source material, but generally, an inability to produce requested documentation during a regulatory inquiry is treated as a compliance failure in itself, independent of whether the underlying AI system was actually functioning responsibly. Having the paper trail matters as much as having the good practice behind it.

Should we stop using third-party AI vendors altogether?

Not necessarily — but you should prioritize vendors who can provide their own documentation about model behavior, data sourcing, and update history, since that documentation becomes part of your own compliance trail. Vendors who can't or won't share this information add more risk than convenience.

How does this affect our marketing website specifically?

Any claims about "AI-powered" or "intelligent" features on your public site should be checked against what the underlying system can actually be shown to do, because overstated claims are now a more visible liability than they were before active enforcement began. It's also a good moment to make sure your site's technical claims are backed by clear structured data.

What's the connection between schema markup and AI compliance?

They're not the same thing, but a well-structured, clearly marked-up website makes it easier to represent your actual product capabilities accurately to both search engines and human reviewers, reducing the gap between marketing language and documented reality. Clean structured data is a small but useful part of an overall accuracy posture.

Is this only relevant to companies building generative AI products?

No — the obligations extend to any AI-influenced decision-making, including scoring, classification, ranking, and automated recommendations, which are common in B2B SaaS products well outside the generative AI category. Many companies are in scope without producing anything that looks like a chatbot or content generator.

How do we find every AI-touching feature in our product?

Start with a structured inventory across product, engineering, and customer support teams, since AI features are often added incrementally by different teams without central tracking. Include embedded third-party tools, not just features your own engineers built from scratch.

What role does custom software development play here?

Custom-built decision logic gives you full visibility into how a feature reaches its outcomes, which makes documentation and auditability far more straightforward than trying to explain a licensed black-box tool's internal behavior. It also lets you build oversight and override mechanisms directly into the system rather than working around a vendor's limitations.

Is rebuilding every AI feature from scratch necessary?

Usually not — a mixed approach works for most companies, where high-risk or heavily scrutinized features get custom-built for transparency while lower-risk features are documented and monitored as-is. Prioritizing by risk and customer visibility is more efficient than a blanket rebuild.

How does this affect our sales process with European enterprise customers?

Expect procurement and legal teams to ask more specific AI governance questions earlier in the sales cycle, and expect vague answers to slow deals down more than they used to. Having documentation ready to share can become a competitive advantage rather than just a defensive measure.

What's the risk of doing nothing right now?

The immediate risk is being unprepared if a customer, partner, or regulator asks for documentation you don't have; the longer-term risk is that retrofitting governance under pressure is more expensive and disruptive than building it in gradually. Doing nothing doesn't reduce exposure, it just defers the cost of addressing it.

Does this apply differently to startups versus larger B2B companies?

The underlying obligations don't scale down simply because a company is smaller, though enforcement attention has historically tended to focus first on companies with larger customer bases or more visible market presence. Smaller B2B companies shouldn't assume they're outside the scope, especially if they sell into regulated industries.

How often should AI feature documentation be updated?

Ideally, documentation updates should be part of your normal release process whenever an AI-touching feature changes meaningfully, rather than treated as an annual or one-time exercise. Stale documentation that doesn't reflect the current system is nearly as risky as having none.

What's the relationship between human oversight and compliance here?

Being able to show that a human can review, intervene in, or override an AI system's decision — particularly for anything affecting a customer's rights or outcomes — is a recurring theme across AI governance frameworks generally, and is a practical thing to build into your product architecture regardless of specific enforcement timing. It's also good product design independent of regulation.

Can Scult help with the legal side of AI Act compliance?

Scult focuses on the technical and architectural side — building or restructuring software so that AI-touching features are documented, auditable, and transparent by design. For formal legal compliance opinions, you should work alongside qualified legal counsel familiar with EU AI Act specifics.

What does a typical engagement to fix this look like?

It usually starts with an inventory and gap assessment, then moves into targeted architecture or documentation work on the highest-risk features, scoped according to how much of your system needs rebuilding versus explaining. The pricing table above reflects how that scope typically maps to Scult's service tiers.

How long does a project like this usually take?

Timelines vary significantly with scope — a documentation-focused engagement on a small feature set can move in weeks, while a full architecture rebuild across multiple AI-driven workflows is a longer, phased project. Getting a clear inventory first is what makes an accurate timeline possible.

Does using open-source AI models change our exposure?

Not fundamentally — obligations attach to how the AI system is deployed and what decisions it makes for users, not to the licensing model of the underlying technology. Open-source models still need the same documentation trail around data, decision logic, and oversight.

What if our AI feature only affects internal operations, not customers?

Internal-only AI systems can still carry documentation expectations, particularly where they affect employees' rights or working conditions, though customer-facing systems tend to draw more direct scrutiny given their visibility. It's worth including internal tools in your inventory rather than assuming they're automatically out of scope.

How do we know if our AI feature counts as "high-risk" under the framework?

Risk categorization depends on factors like the sector, the type of decision being made, and who is affected — features touching things like employment, credit, or essential services tend toward higher scrutiny. If you're unsure where a specific feature falls, that uncertainty itself is a signal worth resolving with proper legal guidance alongside your technical audit.

Will this enforcement activity extend beyond the EU eventually?

The source material only confirms EU AI Office and national authority enforcement within the EU framework, so extending that pattern elsewhere is speculative. That said, other jurisdictions have historically referenced EU regulatory frameworks when developing their own, so it's reasonable to expect this space to keep evolving globally.

What's the fastest low-cost step we can take this month?

Run the feature inventory first — it costs internal time rather than a large budget, and it tells you exactly where your real gaps are before you commit to any larger engineering spend. Everything else in a compliance response is easier to scope once that inventory exists.

How does this interact with GDPR obligations we already have?

AI Act obligations and GDPR obligations overlap in places, particularly around data provenance and processing transparency, but they are separate frameworks with separate requirements. Companies that already have strong GDPR documentation practices have a head start, but shouldn't assume GDPR compliance alone satisfies AI-specific obligations.

Are there specific penalties named for AI Act non-compliance?

The source material for this post doesn't specify penalty figures, and it would be inaccurate to state a number without a public source confirming it. What's established is that a functioning enforcement structure is now in place, which is the precondition for penalties to be applied when non-compliance is found.

What should our engineering team change first?

Start by making sure every AI-touching feature has a clear, single owner who can explain what it does and where its data comes from — fragmented ownership is one of the most common reasons documentation gaps exist. From there, prioritize structured logging and decision traceability on the highest-visibility features.

Does this affect how we choose new AI vendors going forward?

Yes — vendor selection should now include a documentation and transparency check as a standard criterion, not an optional nice-to-have. A vendor that can't explain its own model's data sourcing or decision logic passes that risk directly on to you.

How does micro-frontend architecture relate to AI compliance?

If your product is built as several independently deployed micro-frontends, AI-touching features can end up scattered across modules with inconsistent documentation standards unless governance is deliberately coordinated. It's worth weighing that risk against the architectural benefits before committing to a fragmented structure for AI-heavy products.

Should we audit our website copy as part of this?

Yes — any page describing your product's AI capabilities should be checked against documented system behavior, since public claims are now a more visible point of scrutiny than they were before active enforcement began. This is a relatively quick audit compared to backend architecture work.

What's the risk of overstating AI capabilities on our site?

Beyond general reputational risk, overstated claims create a direct mismatch between what you're telling customers and regulators and what your system can actually be shown to do, which is a harder position to defend than simply describing capabilities accurately. Precise language protects you more than impressive-sounding language does.

How do we handle AI features built years ago with no documentation at all?

Treat them the same as new features in your inventory process — retroactively documenting an older feature is more work than documenting one built with governance in mind from the start, but it's still the right first step before deciding whether to rebuild it. Age of the feature doesn't exempt it from current expectations.

Is this a one-time compliance project or an ongoing responsibility?

Ongoing — AI systems and the products they sit inside keep changing, and documentation that isn't maintained becomes inaccurate quickly. Building AI documentation into your regular release and review process is more sustainable than treating this as a single project with an end date.

What if we can't determine exactly which of our features use AI?

That uncertainty is itself worth resolving through a structured technical audit, since "we're not sure" is a weaker position than either a confirmed inventory or a confirmed absence of AI-touching features. A short discovery engagement is often the fastest way to get clarity.

Does this enforcement shift affect how we should structure new products?

Yes — designing new AI-touching features with documentation, data provenance tracking, and human-oversight hooks built in from day one is significantly cheaper than retrofitting them later under regulatory or customer pressure. This is a strong argument for involving compliance-aware architecture decisions early in any new product build.

How does custom software development reduce our long-term risk here?

Owning your decision logic rather than licensing it opaquely means you can produce documentation, adjust for new requirements, and demonstrate oversight without depending on a third-party vendor's roadmap or willingness to cooperate. That control compounds in value as regulatory scrutiny increases over time.

What industries within B2B are likely to see the most scrutiny first?

The source material doesn't specify sector prioritization, so naming particular industries here would be speculative. Historically, sectors with higher consumer impact — finance, healthcare-adjacent tools, employment platforms — tend to draw earlier attention in comparable regulatory rollouts, which is a reasonable pattern to plan around.

What's a practical way to prioritize which AI features to fix first?

A useful method is ranking features by two factors: how customer-visible the feature is, and how much of a decision it actually makes on someone's behalf. Features that are both highly visible and highly decision-driven — like an automated approval or scoring tool — should be addressed before internal, low-impact experiments.

Does this enforcement shift change how much budget companies should set aside for compliance-related engineering work?

There's no official figure tying budget to this specific announcement, so any number here would be a guess rather than a fact. What's reasonable is treating AI governance work as a recurring line item in your engineering roadmap going forward, rather than a one-off cost that gets absorbed and forgotten.

Can we outsource the entire compliance response to a vendor?

You can outsource the technical implementation — documentation, architecture, auditability — to a development partner, but the underlying accountability for compliance stays with your company. Choosing a partner who understands both the technical and governance sides of the work reduces the coordination burden significantly.

What's a reasonable first deliverable to ask for from a partner?

A completed feature inventory and gap assessment is a reasonable, bounded first deliverable that gives you a clear picture of exposure before committing to larger architecture work. It also gives you a concrete basis for prioritizing what gets built or documented next.

How does this news affect companies planning to expand into Europe?

Companies planning European expansion should build AI documentation and governance into their launch plan from the outset rather than treating it as a post-launch concern, since retrofitting it after entering the market is more disruptive. This is analogous to how companies evaluating new manufacturing or operational bases benefit from planning around regulatory and structural realities early rather than reacting to them later.

Where should a B2B company start if this is the first they're hearing of it?

Start with the feature inventory this week, assess documentation gaps honestly, and get a technical partner or legal counsel involved on the specific items that show the largest gaps. Waiting for more clarity from the EU AI Office before acting isn't a safer strategy than starting the inventory now.

How can we get help assessing our specific situation?

The most efficient next step is a direct conversation about your product's specific AI-touching features and where the real gaps sit, rather than trying to interpret general guidance against your particular stack alone. You can book a meeting with our team to walk through that.