Why AI makes it easier to connect public alerts, but does not automatically make their information comparable or useful for prevention.
Imagine that you are responsible for food safety in a company buying ingredients from different countries. You want to understand whether recent incidents involving undeclared allergens should prompt a closer look at your own products or suppliers.
You start with official information. The US Food and Drug Administration (FDA), the European Commission and the UK Food Standards Agency (FSA) all publish valuable information about food recalls, alerts and risks. Much of it is accessible online, and some is available through structured databases and APIs that software can process.
But there is a problem. Just because the information is public does not mean it speaks the same language.
This is a question I was exploring in August 2020, when I published One food safety data standard to rule them all? I argued that the answer was not necessarily to force every authority to adopt one format. Instead, we should find better ways to make independently developed systems understandable to one another.
Six years later, with AI making it easier to extract and combine information, I think the question deserves another look. Perhaps some of the technical work is becoming easier. But have we solved the underlying problem?
Three authorities, three different purposes
The FDA’s openFDA Food Enforcement Reports API provides structured information derived from its Recall Enterprise System, including the recalling firm, product description, reason for recall and relevant dates. The FDA also classifies recalls according to their level of health hazard. Importantly, the agency cautions that this particular dataset should not be used to issue public alerts or track the full lifecycle of a recall.
In Europe, the Rapid Alert System for Food and Feed (RASFF) helps authorities exchange information about risks and coordinate their response. Its public RASFF Window makes notification summaries searchable, including information about products and hazards. It covers more than recalls, and deliberately excludes certain commercial information, including business operators and brands, from its public summaries.
The UK’s FSA Food Alerts API supports allergy alerts, product recall notices and food alerts for action. Its data model includes product details, allergen codes, consumer advice and reporting-business information where applicable. Some fields are optional.
That does not make one system better than another. These systems serve different purposes, under different regulatory and disclosure requirements. Before we combine their information, we need to understand what each record actually represents.
Here is a simplified comparison, based on the public documentation of the three systems rather than on three records of the same incident.
| Information | US FDA | EU RASFF Window | UK FSA |
|---|---|---|---|
| Type of record | Recall enforcement report | Risk notification, including alerts and border rejections | Allergy alert, recall notice or alert for action |
| Business | Recalling firm identified | Brands and operators excluded from public summaries | Reporting business where applicable |
| Product | Description; broad product type | Product information and category | Product name; optional category and batch details |
| Hazard | Reason in narrative text; separate severity classification | Hazard and risk information | Structured allergens; risk description |
| Dates | Recall initiation and report dates | Notification date | Alert creation and modification dates |
Sources: FDA field documentation, European Commission’s RASFF overview, and FSA API reference. Individual records may omit optional fields, and public summaries do not necessarily contain everything known to an authority.
One allergen, different descriptions
Consider an undeclared milk allergen. It is a straightforward food safety concern to recognize, but real public notices illustrate how differently the information can be presented:
- In the United States, an FDA announcement about dark chocolate products, published in 2017, explicitly identifies milk as an undeclared allergen and includes product, brand and company information. In the openFDA enforcement-data model, the reason for recall is a narrative field, while the separate recall classification describes the level of health hazard.
- In Europe, a RASFF notification identified as 2026.7541, dated 26 August 2026, concerns undeclared milk on the Spanish label of Asian-style noodles. The notification can be searched by its reference number; the public RASFF model does not provide the same commercial identifiers as the FDA announcement. The Spanish food safety authority has also published consumer-facing information about milk-allergen labelling in Asian-style noodles, illustrating how a national consumer notice may provide a different level of product detail.
- In the United Kingdom, a June 2026 FSA allergy alert about a chocolate bar identifies milk, the product, its batch code and the advice given to consumers. The FSA’s underlying alert model can also represent allergens through controlled terms.
These are three separate examples, not three authorities reporting one international incident. The comparison concerns how a similar food safety issue is represented, not whether the underlying incidents are equivalent.
What makes the information difficult to combine is not just the names of the fields. Their meaning may differ too. A hazard description is not the same as a recall severity classification. A recall initiation date is not necessarily comparable to a notification or publication date. A business name withheld from a public summary is not the same as one missing because a record was incomplete.
And the level of product detail may vary considerably. Before counting, grouping or comparing incidents, we need to know which differences can be reconciled and which must remain visible. Public, structured and machine-readable are not the same as comparable.
Does AI change the answer?
It certainly changes what is technically possible. AI can help identify allergens in narrative descriptions, translate terminology, suggest product classifications and propose relationships between records. Some of the work that once required extensive manual mapping may become faster and less costly.
But recognizing similar words is not the same as establishing equivalent meaning. If AI finds undeclared milk in several records, are these separate incidents or different notices concerning one event? If two systems use different risk classifications, can those values legitimately be compared? If a field is absent, is the information unknown, unavailable in this public view, or deliberately restricted?
AI may help investigate such questions when evidence exists. It cannot turn undisclosed information into verified fact. This is why I still think metadata, shared vocabularies and documented mappings matter. One approach would be for authorities and other information systems to use a common metadata schema directly. Another, perhaps more realistic, would allow them to retain their own schemas while mapping their fields and values to a shared reference model.
For example, we could agree on how to represent the type of event, product, allergen, date and its meaning, action, and source of information. Just as importantly, we would need mappings between local vocabularies and the common reference terms. Some mappings would establish equivalence; others would need to express only partial similarity or no reliable correspondence at all.
AI could then operate against these specifications rather than inventing its own interpretation of each source. It could extract information using documented field definitions, reference vocabularies and existing mappings as guidance, retain links to the original announcements and flag uncertain or unsupported mappings for review.
This would not eliminate the differences between authorities, nor should it. The objective is to make those differences explicit enough that systems can exchange safety-critical information and combine it in meaningful ways.
From collecting information to preventing harm
For a food safety manager, the objective is not to build a bigger database of recalls. It is to recognize relevant patterns and decide whether further investigation or preventive action is justified. An increase in recorded allergen incidents might be worth investigating. But it could also reflect changes in reporting coverage, classifications or the way records have been combined. A convincing chart is not, by itself, proof that the underlying risk has increased.
In my 2020 article, I suggested approaching interoperability more like benchmarking: different systems could retain their own structures while agreeing on how their information should be compared. I still find this a useful direction.
But a harmonized record should not mean a record in which every empty field has been filled or every classification has been forced into one category. We also need to preserve provenance, permitted use, disclosure restrictions, uncertainty and the original meanings of the information. Where no reliable mapping exists, that limitation should travel with the record.
With those foundations, I believe we could reduce duplicated work and help different systems share information more reliably. But the final step still belongs to the people and organizations responsible for evaluating what the information means in their own context and acting upon it.
I suspect AI makes this shared groundwork more important, not less. When machines can combine information faster, they can also spread mistaken equivalences faster.
The goal should not simply be to give AI access to more food safety data. It should be to enable systems to exchange safety-critical information, combine it meaningfully and support better decisions that help prevent harm.
These are personal reflections and do not represent the views or positions of SGS or FoodNexus.
