The EU AI Act's Reach Into the UK: A Practical Guide for B2B Companies in UK

Direct answer: Yes, the EU AI Act's transparency obligations that took effect in August 2026 apply to your UK B2B company if you sell software, services, or AI-enabled features to customers based in the EU, regardless of where your company is registered or headquartered. The law follows the market the output reaches, not the postcode on your invoice, so Brexit does not exempt you. If your product uses AI to generate content, make decisions, or interact with users, and any of those users sit in the EU, you now have disclosure and documentation obligations to meet.

The trend grounding this post is specific: as of August 2026, the EU AI Act's transparency provisions have moved from "future compliance item" to active enforcement territory for UK companies that serve EU customers, a shift covered in Deloitte UK Tech Trends' analysis of EU AI Act enforcement this August. This is not a UK law — Britain has taken a lighter-touch, sector-based approach to AI regulation domestically — but the EU AI Act was written with extraterritorial reach by design, similar in structure to how GDPR applied to non-EU companies handling EU personal data. What changed in August 2026 specifically is that transparency duties around AI-generated content, AI-driven interactions, and certain higher-risk AI use cases moved into force, meaning UK B2B companies that had been treating this as a "watch and wait" item now have live obligations if any part of their customer base is in the EU. A precise figure for how many UK B2B firms are currently non-compliant is not publicly available, so this post reasons from the general pattern instead: cross-border regulation historically catches mid-market B2B companies off guard precisely because they assume it is a "big tech" problem, when in practice the obligations attach to anyone shipping AI-touched products into that market, at any size. For a UK software vendor, SaaS provider, or service company with EU clients on the books, this is now a live compliance question, not a theoretical one.

What Actually Changed in August 2026, and Why It Reaches UK Companies

The EU AI Act is structured around risk tiers — unacceptable-risk practices that are banned outright, high-risk systems that require conformity assessments and documentation, and a broader transparency layer that applies more widely to anything that interacts with people using AI or generates synthetic content. It is that transparency layer, not the high-risk tier, that most B2B companies will bump into first, and it is the layer that came into fuller enforcement in August 2026.

In practical terms, the transparency obligations cover things like: telling users clearly when they are interacting with an AI system rather than a human, labelling AI-generated or AI-manipulated content so it is not mistaken for authentic material, and disclosing when an AI system is used to make or materially influence a decision that affects someone. None of this is exotic — it reads like sensible product ethics — but it becomes a compliance obligation, not a nice-to-have, the moment a UK company's product or content reaches an EU-based user.

The Extraterritorial Mechanic, in Plain Terms

The reason UK companies are affected at all, post-Brexit, comes down to how the Act defines its own scope. It does not ask where a company is incorporated or where its servers sit. It asks where the AI system's output is used. If your UK-based SaaS platform has EU customers logging in and using an AI feature, or if your UK software house is under contract to build an AI-enabled tool that an EU client will deploy to EU end users, the Act's obligations travel with that output into EU territory — and by extension, back onto you as the provider or developer. This is the same logic that made GDPR a UK problem long after the exact regulatory relationship between the UK and EU became more complicated. Regulatory reach based on market impact rather than jurisdiction of incorporation is now a repeating pattern in how major economic blocs write tech law, and B2B companies serving international clients should expect more of it, not less.

Why This Matters Specifically for B2B Companies Selling Into the EU From the UK

For a UK B2B company, this trend lands differently than it does for a consumer brand, because B2B relationships run through contracts, procurement processes, and named points of accountability — all of which now have a new item to check.

If you sell software, a platform, or a service to EU-based businesses, your EU customers' own legal and procurement teams are increasingly asking vendors to confirm AI transparency compliance as part of due diligence, the same way data processing agreements became a standard procurement checkbox after GDPR. A UK company that cannot answer those questions clearly risks losing deals not because its product is worse, but because it looks like unmanaged risk to a EU buyer's legal team. That is a commercial cost sitting on top of the regulatory one.

There is also a second-order effect specific to B2B: many UK companies in this position are not consumer-facing at all, so they assumed AI regulation was someone else's problem. But B2B products routinely embed AI in ways that trigger transparency duties without the company necessarily thinking of itself as "an AI company" — a support chatbot on a client portal, an AI-assisted reporting feature, AI-generated first-draft content inside a tool, an automated scoring or triage feature used in a client-facing workflow. Each of those is now a point where disclosure obligations can apply if an EU end user is on the other side of the interaction.

It also matters that B2B sales cycles for software and services tend to be longer and more scrutinised than consumer purchases, which means a compliance gap surfaces earlier in the relationship rather than after the fact. A consumer might never ask a company whether its chatbot discloses that it is AI. An EU-based procurement lead evaluating a UK software vendor for a multi-year contract increasingly will ask, and increasingly expects a documented answer rather than a verbal assurance. That shifts the cost of getting this wrong from a hypothetical regulatory fine to a very concrete, near-term commercial one: a stalled deal, a delayed renewal, or a security-and-compliance review that drags on longer than it should because nobody on the vendor side could answer the question cleanly the first time it was asked.

The Compliance Gap Is a Contracting Gap

Because most of these obligations surface as things you say to end users — an interface disclosure, a labelling requirement, a documented risk assessment — the fastest place they get missed is in commissioned software work where the specification never asked for them. A UK company that builds internal tools cheaply, or outsources feature builds without an explicit compliance brief, tends to end up with AI functionality that works but was never assessed against this obligation. That is a software delivery problem as much as a legal one, and it is the exact gap that a properly scoped Custom Software Development engagement is built to close, because compliance requirements can be written into the specification and architecture from day one rather than retrofitted after a client's procurement team asks an awkward question.

What Changes in Practice for Your Website, Product, and Customer Interactions

This is where the trend stops being a legal abstraction and starts being a product backlog item. Four areas are worth walking through concretely.

Customer-Facing AI Disclosure

If your product, website, or support flow uses an AI chatbot, AI-generated recommendations, or any automated decisioning that an EU-based user interacts with, you need a clear, accessible statement that they are dealing with an AI system, not a person, and — where relevant — how outputs are generated. This is a UI and content problem before it is a legal one: where does the disclosure live, how prominent is it, does it interrupt the flow, and does it read as compliance theatre or as a normal part of the product. Getting that balance right is genuinely a design problem, and it is worth treating the transition thoughtfully rather than bolting on a jarring banner — the same judgment call this site covers in Motion Design in UI: When Animation Helps and When It Hurts, where the point is that added interface elements should support the user's understanding rather than just satisfy a checklist.

Content Labelling for AI-Generated Material

If any part of your marketing, sales enablement, or product output includes AI-generated or AI-manipulated content — synthetic video, AI-voiced material, AI-generated imagery used in ways that could be mistaken for authentic footage — and that content reaches EU audiences, it now needs appropriate labelling under the transparency rules. This is directly relevant if your marketing function has adopted AI video production, a trend covered in AI Video Ads: How to Create Them (2026 Guide): the production workflow does not change, but the disclosure step around anything AI-generated that an EU audience will see does need to be added deliberately, rather than assumed to be someone else's job.

Vendor and Procurement Documentation

EU-based clients are starting to ask UK vendors to document how AI features work, what data feeds them, and what human oversight exists. If your sales team cannot produce a short, honest answer to "how does your AI feature make decisions and what happens if it's wrong," expect that to slow down or lose EU deals. This is a documentation and product-architecture exercise, not a marketing exercise — it needs an accurate answer, not a polished one.

Internal AI Tooling That Touches EU Client Data or Workflows

It is easy to focus only on customer-facing AI and miss internal tools — an AI agent built to triage support tickets, summarise client calls, or automate parts of account management — that touch EU client data or influence outcomes EU clients experience. Building these properly, with the right guardrails and a clear-eyed view of what they cost to build and maintain responsibly, matters more now that the compliance bar has moved. If your team is weighing whether to build an internal AI agent for this kind of workflow, it is worth reading the honest breakdown in The Real Cost of Building an AI Agent for Your Business before committing, because compliance-aware AI tooling is a different scope and cost than a quick internal script.

Common Mistakes UK B2B Companies Are Making Right Now

A few patterns show up repeatedly when UK companies start actually looking at this, rather than assuming it does not apply to them.

The first is treating "we don't have an EU office" as equivalent to "we're not in scope." Office location is irrelevant; customer location and where the output is used is what matters. The second is assuming a general privacy policy update covers it — AI transparency disclosure is a separate obligation from data protection disclosure, and burying it inside an existing privacy policy that nobody reads does not satisfy a requirement that the disclosure be clear and accessible at the point of interaction. The third is delaying because "enforcement in the UK isn't the same as enforcement in the EU" — true, but irrelevant if your actual exposure is losing EU contracts or facing EU regulatory attention through your EU-based customers and their own compliance obligations, which can flow back to you contractually even without a UK regulator involved. The fourth, and most common among smaller B2B teams, is not knowing which of their own product features actually use AI in a way that triggers this, because the feature was added by a developer solving a practical problem long before anyone thought to flag it as "AI" in a compliance sense.

A fifth pattern worth naming is over-correction: once a company realises this applies to them, the instinct is sometimes to slap a generic AI disclaimer on every page and every email, whether or not AI is actually involved at that touchpoint. That satisfies nobody — it dilutes the disclosures that actually matter, reads as legal cover-your-back copy rather than genuine transparency, and can make a reasonably clean product look more AI-heavy and less trustworthy than it actually is. The better path is the narrower, more accurate one: label precisely where AI is used, skip it everywhere else, and keep the language plain enough that a non-technical EU procurement reviewer can understand it on first read.

What to Do About It: A Practical Compliance Path

Start with an honest inventory rather than a policy document. List every point in your product, website, and internal workflow where AI generates content, makes a recommendation, or interacts with a person, and note whether any EU-based customer or user touches that point. This single exercise resolves most of the uncertainty, because it turns a vague legal question into a short, concrete list.

From that list, prioritise the customer-facing items first — disclosure and labelling changes are usually straightforward once you know where they need to go, and they close the most visible risk quickly. Internal tooling and vendor documentation can follow on a slightly longer timeline, but should not be left indefinitely, since procurement questions from EU clients tend to arrive without much warning.

Where the AI feature itself needs rework — better logging of how a decision was reached, a cleaner interface for disclosure, proper documentation of the model and data behind a feature — this is genuinely a build task, and it belongs in the hands of a team that can treat compliance as a design constraint from the start rather than a patch applied under deadline pressure. That is the practical argument for bringing in Custom Software Development support specifically for this work: a compliance-driven rebuild of an AI feature is a different engineering brief than the original "ship it fast" version, and doing it properly the first time is cheaper than doing it twice.

Finally, put a review cadence in place. The transparency rules that came into force in August 2026 are not the last update to this Act, and UK companies serving EU markets should expect the obligations to be refined and, in places, tightened as enforcement matures. A one-off audit without a review cycle behind it will be out of date within a year.

What This Work Typically Costs: Pricing Context

The scope of AI compliance work varies a lot by how much of your product actually touches AI and how many customer touchpoints need disclosure changes. As a rough guide to where this kind of engagement typically lands against Scult's standard service tiers:

Tier	Typical scope for this work
Essential — $1,000	A focused audit and disclosure fix: inventory AI touchpoints, add clear, correctly worded AI-interaction disclosures to a website or product front end, update customer-facing copy.
Growth — $2,000	Essential scope plus rework of one or two AI-enabled features (chatbot, recommendation engine, automated scoring) to add proper disclosure, logging, and documentation, along with updated vendor-facing compliance documentation for procurement conversations.
Enterprise — $4,000+	Full product-wide AI feature audit and rebuild across multiple customer touchpoints, internal AI tooling review, ongoing documentation and review-cycle support, and closer architectural involvement for companies with several AI-enabled features across a platform.

These are directional, not quotes — the right starting point depends on how many AI touchpoints your product actually has and how many of them reach EU customers today.

Key Takeaways

• The EU AI Act's August 2026 transparency rules apply to UK B2B companies based on where their AI-touched output is used, not where the company is registered, so post-Brexit UK status does not create an exemption.
• Start with an inventory of every AI touchpoint in your product, website, and internal workflows, and flag which ones any EU-based customer or user actually touches.
• Customer-facing AI disclosure and content labelling are the most urgent and usually the fastest to fix — prioritise these before deeper internal tooling reviews.
• EU-based B2B customers are increasingly asking vendors to document AI transparency compliance during procurement, so treat this as a commercial risk, not only a legal one.
• Features that need rework — disclosure UI, decision logging, documentation — are a build task best handled with compliance treated as a design requirement from the start, not bolted on afterward.
• Set a recurring review cadence, since the Act's obligations are expected to keep evolving rather than settle into a single fixed checklist.

Getting a clear, accurate answer to "does this apply to us, and where" usually takes less effort than the uncertainty of not knowing costs in lost EU deals. If you want help auditing your AI touchpoints and scoping the fix properly, book a meeting with our team.

Frequently Asked Questions

What is the EU AI Act, in plain terms?

It is the European Union's risk-based framework for regulating AI systems, banning certain high-risk practices outright, imposing documentation and oversight requirements on higher-risk AI uses, and requiring transparency — like disclosing AI-generated content or AI-driven interactions — more broadly across lower-risk uses. It applies based on where an AI system's output is used, not where the provider is based.

Does the EU AI Act apply to UK companies after Brexit?

Yes, if a UK company's AI-enabled product, service, or content reaches users or customers based in the EU. The Act's scope is defined by market impact rather than the provider's country of incorporation, similar in structure to how GDPR reached non-EU companies handling EU personal data.

What specifically changed in August 2026?

Transparency obligations under the Act — covering disclosure of AI interactions and labelling of AI-generated content, among other provisions — moved into fuller enforcement, according to Deloitte UK Tech Trends' coverage of EU AI Act enforcement this August. For many UK B2B companies, this converted a future compliance item into a current one.

Why does this matter more for B2B companies than it might seem?

B2B relationships run through contracts and procurement, and EU-based business customers are increasingly building AI transparency questions into vendor due diligence. A UK company that cannot answer those questions clearly can lose deals over perceived unmanaged risk, independent of whether a regulator ever gets involved.

My company doesn't have an EU office — am I definitely exempt?

No. Office location is not the relevant factor. What matters is whether your AI-enabled product or content is used by people or businesses based in the EU. A UK-only office with EU customers using the product is still in scope.

What counts as an "AI system" under this framework?

It covers software that uses machine learning, generates content, makes or influences decisions, or interacts with users in ways that could be mistaken for a human, among other technical definitions in the Act itself. In practice, chatbots, recommendation engines, automated scoring tools, and AI content generation features are the most common examples B2B companies actually have.

What is a "transparency obligation" specifically?

It generally means telling users clearly when they are interacting with an AI system rather than a person, labelling AI-generated or AI-manipulated content, and disclosing when AI is used to make or materially shape a decision that affects someone. The obligation is about clear, accessible disclosure at the point of interaction.

Is a chatbot on our website covered by this?

If EU-based users interact with it, yes — a chatbot is a textbook example of a system that needs to disclose it is AI rather than a human agent, if that would not otherwise be obvious to the user.

We use AI internally, not customer-facing — does that matter?

It can, if the internal AI tool influences outcomes that EU-based clients experience, such as automated triage or scoring that affects how their account or case is handled. Purely internal tools with no downstream effect on EU customers carry lower exposure, but should still be documented.

How do we find out which parts of our product actually use AI?

Run an internal inventory: walk through every customer touchpoint and internal workflow and ask whether AI generates content, makes a recommendation, or interacts with a person at that point. This is usually a half-day to few-day exercise for a mid-sized B2B product, not a major project on its own.

What happens if we do nothing?

The realistic risks are commercial before they are regulatory for most UK B2B companies: lost EU deals during procurement review, awkward client conversations when compliance is asked about directly, and a larger, more disruptive fix later once a client or partner flags it. Regulatory enforcement risk depends on the EU market's reach into your specific business and is harder to generalise.

Does this apply to AI features we buy from a third-party vendor and embed in our product?

Generally yes — if your product embeds a third-party AI feature and that product reaches EU users, disclosure obligations still attach to how your product presents that AI interaction to the end user, even if the underlying model or engine is built by someone else.

How is this different from GDPR compliance we already did?

GDPR governs personal data processing; AI transparency obligations govern disclosure about AI systems and AI-generated content, which is a separate concern even where the two overlap (for example, an AI system that also processes personal data). A GDPR-compliant privacy policy does not automatically satisfy AI disclosure requirements.

Can we just add a line to our existing privacy policy?

That is unlikely to be sufficient on its own, because transparency obligations generally require disclosure to be clear and accessible at the point of interaction, not buried inside a document most users never open. A visible in-product disclosure is the safer approach.

What does "labelling AI-generated content" actually look like in practice?

It typically means a clear visual or textual marker on content that is AI-generated or AI-manipulated, positioned so a reasonable person would notice it before treating the content as authentic — for instance on synthetic video, AI-generated images used in marketing, or AI-voiced audio.

Does this affect our AI-generated marketing content, like video ads?

If that content reaches EU-based audiences and is AI-generated or AI-manipulated in a way that could be mistaken for authentic material, yes, it needs appropriate labelling. This is a disclosure step to add to your production workflow, not a reason to stop using AI in content production.

We outsource development — whose responsibility is compliance?

Contractually this depends on your agreement with the vendor, but practically, the company selling the product into the EU market carries the exposure regardless of who built it. This is why compliance requirements should be written explicitly into any development specification rather than assumed to be handled by default.

How long does it typically take to become compliant on the transparency side?

For a company with a handful of AI touchpoints, a focused audit and disclosure fix can often be completed in a few weeks. Companies with AI features embedded across multiple products or workflows should expect a longer timeline, particularly if features need rework rather than just added disclosure.

What is the first concrete step we should take this month?

Complete the AI touchpoint inventory described above, and flag which touchpoints any EU-based customer or user interacts with. That single list turns an abstract compliance question into a scoped, prioritised task list.

Should our sales team be trained to talk about this?

Yes — if EU-based prospects or clients are raising AI transparency questions during procurement, sales and account teams should have a clear, accurate, pre-agreed answer rather than improvising, since an inconsistent answer looks worse than a plain, honest one.

Does company size matter for whether this applies to us?

The Act's scope provisions are generally not size-gated in the way GDPR has some SME accommodations; a small UK B2B company selling to EU customers can still be in scope for transparency obligations. Company size may affect how enforcement is prioritised in practice, but should not be relied on as a reason to skip the assessment.

What is the difference between "high-risk" AI systems and the transparency rules?

High-risk systems (used in areas like employment decisions, credit scoring, or critical infrastructure) face a heavier set of obligations including conformity assessments and risk management documentation. The transparency rules apply more broadly to a wider range of AI uses, including many that would not be classified as high-risk, which is why most B2B companies will meet the transparency layer first.

Can we get sued directly by an EU customer over this?

That would depend on contractual terms and the specific facts, and is a legal question outside general guidance. The more immediate and common exposure for UK B2B companies is commercial — lost deals or damaged trust — rather than direct litigation.

What are the penalties for non-compliance?

The Act sets out tiered financial penalties for non-compliance, with the most serious violations (like banned practices) carrying the highest exposure and transparency-layer breaches generally sitting lower. A precise, current penalty figure is not something to rely on secondhand for a specific situation, so treat this as a directional risk category rather than a number to plan around, and focus instead on closing the practical gaps described in this guide.

Is UK domestic law going to mirror the EU AI Act?

The UK has taken a different, more sector-based regulatory approach domestically rather than adopting a single comprehensive AI Act. That does not reduce a UK company's exposure to the EU AI Act itself when serving EU customers — the two regulatory tracks operate independently.

How do we document AI decision-making for procurement questionnaires?

At minimum, be able to describe in plain language what the AI feature does, what data feeds it, what human oversight exists, and what happens when it produces an incorrect or unexpected result. This does not need to be a lengthy technical paper — clarity matters more than length.

What if our AI feature was built years ago and nobody documented how it works?

This is common, and it is exactly the kind of gap a structured audit uncovers. Expect to need some reverse-engineering of the feature's actual behaviour before you can write accurate documentation or disclosure copy for it.

Does this apply to AI used in recruitment or HR tools for EU-based staff or candidates?

AI used in employment-related decisions is treated more strictly under the Act's higher-risk categories, so if your company uses AI in hiring or performance-related decisions affecting EU-based candidates or staff, that deserves a closer, more careful review than general transparency compliance.

How often should we re-review our AI compliance position?

At least annually, and immediately after adding any new AI-enabled feature or expanding into a new EU market segment. The regulatory landscape here is still maturing, so a static, one-time audit will age quickly.

Will this slow down our product roadmap?

It adds a step — assessing AI features for disclosure and documentation needs before or alongside shipping them — but it does not need to be a roadblock if it is built into the development process rather than treated as a separate, late-stage compliance gate.

What's the risk of over-disclosing or being too cautious?

Excessive, poorly designed disclosure can hurt user experience and make a product feel bureaucratic without making it meaningfully more compliant. The goal is clear, accurate, well-placed disclosure, not maximum volume of legal language.

Does this affect API-based products sold to EU developers?

If your API's output is used by EU-based businesses or reaches EU end users through their applications, yes — the same scope logic applies, and your documentation should clarify what disclosure obligations pass through to your customers who build on top of your API.

Should smaller UK B2B companies worry as much as larger ones?

Smaller companies often have fewer AI touchpoints, which makes the audit and fix faster and cheaper, but the underlying obligation does not scale down with company size. Treat it as proportionate effort, not something to skip.

How does this interact with data residency or hosting location?

Where your servers are hosted is a separate question from AI transparency obligations, which focus on user-facing disclosure and AI system documentation rather than data location. Both can matter for an EU-facing product, but they are addressed differently.

What's a realistic budget for a first pass at this?

For most mid-sized UK B2B companies with a handful of AI touchpoints, a focused audit and disclosure fix falls in the Essential-to-Growth range described above; companies with AI embedded across multiple products should expect Enterprise-level scope.

Can this work be done alongside a broader software project, rather than separately?

Yes, and it is often more efficient that way — if you already have development work planned for an AI-enabled feature, building the disclosure, logging, and documentation requirements into that same project avoids a second round of rework later.

What happens if an EU client asks us a compliance question we can't answer yet?

Be honest that you are actively auditing your AI touchpoints and give a realistic timeline for a full answer, rather than guessing. Most procurement teams respond better to an accurate "we're addressing this, here's our timeline" than to a vague reassurance that turns out to be wrong.

Does using a well-known third-party AI model (rather than building our own) reduce our obligations?

It can reduce certain technical documentation burdens since the underlying model provider carries some obligations themselves, but it does not remove your disclosure obligations around how your product presents the AI interaction to end users.

Are there any exemptions for research, internal tools, or non-commercial use?

The Act includes some narrower exemptions for specific contexts, but a commercial B2B product or service used by EU customers is very unlikely to fall under a research or purely internal exemption. Do not assume an exemption applies without checking the specific use case carefully.

What's the single biggest mistake companies make when addressing this?

Assuming it does not apply to them because they are UK-based, small, or not "an AI company" in their own self-description, and therefore never running the touchpoint inventory that would show them otherwise.

How does this affect AI-generated proposals, reports, or client deliverables?

If AI-generated content is delivered to EU-based clients in a form that could be mistaken for entirely human-authored work, labelling it as AI-assisted is the safer, compliant approach, particularly for anything resembling analysis, imagery, or synthetic media.

Should this be a legal project or a product/engineering project?

Both, but the execution — inventorying touchpoints, redesigning disclosure UI, adding documentation and logging — is primarily a product and engineering exercise informed by legal requirements, which is why it fits naturally into a software development engagement rather than sitting purely with external counsel.

What if our product doesn't use AI at all right now?

Then your exposure is currently low, but worth revisiting before adding any AI feature aimed at or reachable by EU customers, so the disclosure and documentation requirements are built in from the first version rather than retrofitted.

Is this likely to get stricter over time?

Based on the general pattern of how the Act has been phased in — moving from bans, to GPAI obligations, to broader transparency and high-risk requirements — it is reasonable to expect continued tightening and clarification rather than a rollback, though a precise future timeline is not something to speculate on beyond that general pattern.

Do our website's cookie or consent banners already cover this?

No — cookie consent addresses data collection preferences, while AI transparency disclosure addresses whether users understand they are interacting with an AI system or viewing AI-generated content. They are separate mechanisms serving separate obligations.

How do we handle AI features used by a mix of UK-only and EU customers?

The safest and most maintainable approach is usually to apply the disclosure and documentation standard consistently across the whole product rather than maintaining two different versions by region, since segmenting by user location adds ongoing engineering overhead for a compliance requirement that is reasonable to meet everywhere.

What role does an AI agent play in all this, if we're considering building one?

If you're evaluating building an AI agent for a customer-facing or client-affecting workflow, this is the right moment to scope disclosure and documentation requirements into the build from the start rather than after launch — understanding the realistic cost of that kind of build up front avoids surprises later.

Who inside our company should own this going forward?

Ownership works best when it sits with whoever owns the product roadmap, working alongside legal or compliance input rather than treating it as purely a legal filing exercise, since most of the actual fixes are product and engineering changes.

Can Scult help us specifically with this, or only with general software work?

Scult's Custom Software Development work is well suited to exactly this kind of engagement — auditing AI touchpoints, redesigning disclosure and documentation into a product, and rebuilding features so compliance is part of the architecture rather than a late patch.

What's a good next step if we're not sure how exposed we are?

Start with the touchpoint inventory internally, and bring in outside help to review the results and scope a fix once you have a concrete list — that conversation is far more productive than starting from "does this apply to us at all."