Why do deployers still carry AI Act risk when a third-party model provider marks the output?

Why the deployer remains on the hook

The marking service does not transfer the deployer’s duties. The AI Act assigns obligations by legal role, so the deployer still has to make sure the human-facing notice appears, is understandable in the deployment context, and is delivered at the point people first encounter the output. If the model provider only supplies machine-readable marking, that is useful evidence, not full compliance.

That role split matters because deployment is where the output is actually published, embedded, or shown to end users. A provider can support the control, but the deployer controls the channel, the user experience, and often the decision to expose the output in a public or regulated setting. In practice, the deployer must treat provider marking as one input to its own disclosure process, not as a substitute for it. See the EU AI Act Compliance Guide for the role split and transparency duties, and the EU AI Act regulatory framework for the Commission’s current framing of provider and deployer obligations.

For deployers, the practical question is not whether the model was marked upstream, but whether the notice survived the full delivery chain. If your product strips metadata, rewrites model output, translates it, screenshots it, or republishes it through a different interface, the original marking can be lost or rendered invisible. That is why the compliance burden stays with the party that controls presentation to the user. The Third-Party AI Risk Guide is a useful navigation point for understanding why vendor controls and deployer controls need to be tested separately.

Where the compliance gap usually appears

The gap is usually between machine-readable provenance and user-visible disclosure. A provider can tag the output, but the deployer still has to decide whether the interface shows a notice, how prominent it is, and whether the notice still makes sense after downstream formatting or moderation. That is especially important for deepfake-related outputs and public-interest content, where the user must see the warning at first exposure, not after a click-through or buried in terms of use.

Another common gap is evidence. If regulators or auditors ask how the notice was delivered, the deployer needs to show logs, screenshots, configuration records, or workflow evidence that the disclosure was actually presented to users. That is a different control from the provider’s marking function. The deployment team needs proof of delivery, not just proof that the provider generated a mark. For teams scoping that assurance work, the AI Risk Assessment Guide helps frame the control as an end-to-end risk and evidence problem rather than a vendor checkbox.

Where third-party model providers are involved, the deployer should also verify whether the vendor’s marking survives any post-processing steps in the application. Output filters, content rewriters, caching layers, mobile rendering, and downstream integrations can all alter what the user ultimately sees. If the visible notice is lost in those layers, the deployer owns the failure even if the provider did its part correctly.

How deployers should operationalise the duty split

Deployer controls should be designed around the actual user journey. The right test is whether a person encountering the output for the first time would reasonably see the required disclosure in context, without having to infer it from backend metadata or legal boilerplate. That means aligning product design, legal review, and content operations so the notice is present where the output is consumed.

What to verify: confirm that the provider’s marking is mapped to a deployer-side display rule, that the interface renders the disclosure consistently across channels, and that the notice is still visible after translation, truncation, export, or republishing. If any of those steps can remove the notice, treat the control as incomplete until that failure mode is closed.

Decision rule: if the provider only supplies machine-readable marking, assume the deployer still needs a separate visible-disclosure control and an audit trail. If the output can reach the public, or is presented as a deepfake or public-interest text, the bar is higher: do not rely on the vendor’s tag alone, because the deployer is the party that can prove first-exposure notice at the point of delivery.

Agentic AI Compliance Guide is the most relevant internal starting point when the same deployment stack also involves agentic workflows, because the role split, evidence trail, and disclosure mechanics often cross into automated content generation and orchestration.

Practitioner takeaway: treat provider marking as upstream support, not as compliance completion; the deployer owns the user-visible notice, the delivery context, and the proof that disclosure happened when the output was first seen.

Related resources from NHI Mgmt Group

• Guide: Agentic AI Compliance Guide
• Why does model genealogy matter when organisations assess the risk of third-party AI models?
• What are the signs that an AI-enabled third-party risk program is still operating like a manual process?
• Why do third-party AI models still create regulatory risk for insurers?
• Why is single-provider AI agent governance not enough for enterprise security?