The Visibility Gap, Part 1

What product safety reporting systems were designed to do and why that matters now

The Visibility Gap is a four-part investigation into how product safety signals are detected, interpreted, escalated and made visible before harm occurs. New parts will be published weekly throughout August.

The product that exists six months after release may no longer be the product that was originally assessed.

Software updates, AI-enabled functionality and connected digital ecosystems increasingly allow products to change after they enter the market.

That creates an important question:

Are today’s product safety reporting systems evolving quickly enough to keep pace?

That is the question this investigation explores.

Not from the perspective of blame, but from the perspective of visibility.

Most people notice product safety systems only after something has already gone wrong: a recall notice, a public warning, a dangerous product removed from sale, or a Safety Gate alert issued after an issue has escalated far enough.

What most people never see is the machinery behind those moments.

Across Europe and the United Kingdom, product safety reporting systems were built to perform a critically important function: identify and escalate signals of emerging harm early enough to protect consumers.

That sounds straightforward. But products are changing quickly, and the systems responsible for monitoring them are increasingly being asked to interpret risks that are dynamic, interconnected and difficult to isolate.

What most people never see

Across the European Union, information about dangerous non-food consumer products is exchanged through the Safety Gate rapid alert system.

Formerly known as RAPEX, Safety Gate enables national authorities to circulate information about dangerous products, the risks identified and the corrective measures taken across the Single Market.

The General Product Safety Regulation, Regulation (EU) 2023/988, has applied since December 2024. It strengthened the European framework for product safety, market surveillance, traceability, accident reporting and corrective action.

Where a manufacturer considers or has reason to believe that a product it placed on the market is dangerous, it must take corrective action and inform consumers and the relevant national authorities through the Safety Business Gateway. Manufacturers must also notify accidents caused by their products through the Gateway without undue delay after becoming aware of them.

In Great Britain, the product safety landscape includes the Office for Product Safety and Standards and the relevant mechanisms through which businesses notify authorities about unsafe or noncompliant products. Northern Ireland introduces another layer of complexity because the EU General Product Safety Regulation continues to apply there under the post-Brexit framework.

For consumers, these systems are mostly invisible.

For businesses, they are anything but.

Behind every notification sits a chain of decisions:

• Was the issue recognised and classified correctly?
• Did it meet the applicable reporting threshold?
• Which jurisdiction and legal framework applied?
• Who decided whether escalation was necessary?
• How quickly was that decision made?
• What evidence supported it?

Those questions are becoming more important, not less.

What these systems were originally designed for

Historically, many product safety frameworks evolved around relatively stable physical products.

The logic was broadly familiar:

• identify the defect;
• assess the hazard and its severity;
• determine whether the reporting threshold has been met;
• notify the relevant authority; and
• implement and communicate corrective action.

In many traditional cases, the problem itself was physically observable: an overheating component, an electrical fault, a choking hazard, a mechanical failure or a harmful chemical exposure.

But products are no longer staying still.

A product today may receive remote updates, depend on cloud services, interact with third-party APIs and change its behaviour through AI-enabled functionality.

That changes the visibility challenge completely.

Imagine a connected product that has operated safely for several months.

A cloud-side update changes how it behaves under certain conditions. Customer Support begins receiving isolated complaints. Engineering sees a software anomaly. Quality cannot yet confirm a product defect. Regulatory is asked whether the issue has reached the threshold for notification.

No one is necessarily making the wrong decision.

The challenge is determining whether those separate pieces of information form a reportable product safety event.

The visibility challenge

At first glance, the answer may seem simple:

If there is a serious issue, businesses report it.

In reality, an organisation may have to interpret incomplete and fragmented information before it can determine whether a reportable event exists.

There is often a gap between detecting a signal internally and concluding that the signal has crossed an external reporting threshold.

That distinction matters because product safety visibility depends not only on whether information exists. It depends on whether the organisation can connect information held across Customer Support, Engineering, Quality, Cybersecurity, Regulatory, Operations and Legal early enough to act.

The more fragmented the information, the harder it becomes to establish:

• whether the emerging pattern represents a safety risk;
• how the product has changed since its original assessment;
• which markets and users may be affected;
• whether the issue requires immediate corrective action; and
• whether notification obligations have been triggered.

This is not simply a reporting problem.

It is a problem of organisational visibility.

Why software changes the equation

Software introduces a different kind of complexity.

Physical defects are often visible and bounded. Software-related risks may be intermittent, update-dependent, configuration-specific, data-driven or influenced by third-party services and integrations.

An issue may emerge only after an operating-system update, under particular environmental conditions, following a cloud-side change or through interaction with an external platform.

Unlike many traditional manufacturing defects, these problems may continue to evolve after the product has entered the market.

That matters for two reasons.

First, Directive (EU) 2024/2853 expressly brings software within the revised product liability framework and recognises the significance of related services, updates and changes occurring after a product has been placed on the market.

Second, the EU Artificial Intelligence Act introduces lifecycle obligations relating to areas including monitoring, documentation, risk management, governance and human oversight for systems within its scope.

Together, these developments point in the same direction:

Post-market visibility is becoming central to both product safety and product liability.

The question beneath the question

This series is not arguing that companies deliberately fail to report product safety issues.

Nor is it claiming that existing reporting systems are ineffective. In many respects, the regulatory framework has become more sophisticated, and the GPSR has modernised important elements of product safety reporting and market surveillance.

The harder question is whether the organisation surrounding the reporting system can interpret modern product signals quickly enough.

If products are becoming more software-driven, interconnected and continuously changeable, reporting and surveillance mechanisms must be supported by governance capable of seeing across the product lifecycle.

That means connecting weak signals before they become obvious patterns. It means knowing who owns the initial assessment, who can trigger escalation and what evidence must be preserved. It also means maintaining visibility when a product’s behaviour depends on software, data, cloud infrastructure or third parties that may sit outside the traditional Quality system.

The issue is therefore not simply whether a reporting channel exists.

It is whether the organisation can convert incomplete information into a timely, evidence-based and defensible decision.

Every product safety system ultimately depends on visibility into emerging risk, changing product behaviour and weak signals before they become major events.

As products continue to evolve after entering the market, the question is no longer simply whether reporting systems exist.

It is whether they can still see clearly enough.

That does not mean the systems are failing. But it may mean that organisations are entering a level of complexity their traditional reporting structures were never designed to manage.

That is where this investigation begins.

Next in the series

In Part 2, I examine how product safety reporting works across the European Union, Great Britain and Northern Ireland, and where the first layers of operational and jurisdictional complexity begin to appear.

Sources and references

European Commission, Safety Gate rapid alert system

Regulation (EU) 2023/988, General Product Safety Regulation

European Commission, Safety Business Gateway guidance

UK Government, Business notifications of unsafe and noncompliant products

UK Government, Product safety and noncompliance notification guidance for authorities

Directive (EU) 2024/2853, revised Product Liability Directive

Regulation (EU) 2024/1689, Artificial Intelligence Act