What should organisations do when AI systems are embedded in products but not yet high-risk?

What “not yet high-risk” still means in practice

Product-embedded ai systems are not exempt from governance just because they have not crossed a high-risk threshold. Organisations still need to know where the system is used, who owns it, what data it touches, and which transparency or disclosure duties already apply. In practice, the governance question starts at deployment and customer exposure, not at the eventual high-risk classification.

That matters because embedded systems often sit inside existing products, procurement chains, and customer journeys, which makes them easy to overlook. A low-risk label today can become misleading once the system reaches EU users, influences customer-facing interactions, or is repurposed in a way that changes its legal and operational profile.

What organisations should put in place now

At a minimum, organisations should maintain an inventory of embedded AI systems, assign a responsible owner, and document the data flows and lineage feeding each system. That gives teams a defensible basis for later classification, audit preparation, and incident response. It also prevents “shadow AI” inside products from escaping ordinary governance simply because the risk assessment is still evolving.

Where the system affects users, outputs, or customer interactions, transparency controls should be treated as immediate work rather than future cleanup. This includes deciding what the user needs to know, what the product should disclose, and where the organisation needs evidence that the disclosure is accurate. NHIMG’s Agentic AI Compliance Guide is useful here because it ties AI governance to compliance evidence, transparency obligations, and control ownership.

Product teams should also preserve lineage for training, prompts, retrieval inputs, and downstream outputs where those elements affect the system’s behaviour or claims. The important practical point is not only whether the model is powerful, but whether the product can explain what data and processing steps shaped the result. That is what allows compliance, legal, and security teams to distinguish a manageable embedded feature from one that needs a more formal control path.

How to decide whether to escalate the control posture

The right trigger is exposure, not internal comfort. If the system touches EU users, influences customer decisions, or is embedded in a product that can be repurposed into a regulated use case, organisations should escalate ownership and review even before the system is formally classified as high-risk. NHIMG’s Agentic AI Identity Risk Board Briefing is a good fit for translating that escalation into board-level questions, metrics, and decision ownership.

That escalation should be proportionate. It does not mean treating every embedded AI feature as a fully regulated high-risk system from day one. It means avoiding a false sense of exemption and making sure the organisation can prove its inventory, accountability, and transparency decisions if the system later moves into a higher-risk category.

For teams that need a deeper control lens, NHIMG’s Top 10 Agentic AI Identity Issues helps identify where ownership, access, and overreach problems tend to emerge once AI is embedded into products and operational workflows. That is especially helpful when product, platform, and governance teams need a shared view of where accountability can break down.

Risk and Threat Considerations

Embedded AI systems often create governance risk before they create obvious technical risk. The main failure mode is premature de-scoping: teams assume a feature is “low risk” and delay inventory, ownership, lineage, and disclosure work until the system is already deployed in front of users or customers.

Failure mechanism: The organisation loses traceability over where the system runs, what data it uses, and which user-facing outputs it affects, so later classification, transparency, and incident handling become harder to prove and harder to defend.

Impact: Missed disclosure obligations, weak accountability, and slower remediation if the product is later reclassified, repurposed, or scrutinised by regulators or customers.

A separate threat is scope creep. A system that starts as a low-risk embedded feature can become materially different once it is exposed to more users, more data, or more decision influence. The control problem is not the initial label, it is the organisation’s ability to notice when the operating context has changed.

Practitioner Guidance

What to prioritise: Establish ownership and inventory first, then confirm which embedded systems touch EU users or customer-facing interactions. That is the point where transparency, lineage, and escalation decisions become operationally meaningful.

What to verify: Teams should be able to show where each embedded system lives, which product it supports, what data sources feed it, and which disclosures or notices are already in place. If any of that is unclear, the system is already under-governed, even if it is not yet high-risk.

Decision rule: If the system can affect external users, customer communications, or regulated workflows, treat it as a governance item now rather than waiting for the final risk classification. If it never leaves internal experimentation, keep the control set lighter but still maintain traceability.

Practitioner takeaway: The goal is not to over-regulate every embedded model, but to prevent “low-risk” from becoming a delay tactic that leaves no audit trail when the product’s real exposure changes.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• How should organisations implement continuous AI risk management for high-risk systems?
• Why does the EU AI Act force organisations to prioritise high-risk AI systems first?
• How should organisations align AI governance with the EU AI Act before deploying high-risk systems?