AI in food safety: what works in a plant, and what does not

What AI does in a food plant today

Strip out the promises and three uses hold up in a running plant.

Reading documents. Inspection reports, NDT reports (CND), cleaning validations, calibration certificates, supplier files and laboratory results arrive as PDFs, in different layouts, from different providers. Software can read them, pull out the findings and the measurements, and rebuild a history per equipment item. This is where most of the recoverable time sits, because this is where the time is currently lost.

Looking at the line. Vision systems at the packing station or over the conveyor flag defects, foreign bodies, seal faults and label errors, and they do it consistently late in a shift when a human eye no longer does. They work when lighting, camera position and product presentation are stable, and they degrade quietly when they are not.

Sorting what people wrote. Non-conformities, customer complaints, deviation forms and shift handover notes are free text. Language models group them, recognise the same cause described five different ways, and surface the recurring one before the annual management review does.

Most other items on a typical vendor list, hygiene monitoring by camera, outbreak detection from social media, smart pest control, are research programmes, pilots, or sensor products with an AI label on the box. The test is simple: would someone in your plant open it on a Monday morning?

In practice: A quality manager who reviews complaints monthly reads them as a list. Grouped by cause rather than by date, the same closure fault on one filling head shows up across three months of complaints that were each closed individually as isolated.

The real bottleneck is that nobody can find the history

Here is what audit week looks like. The IFS auditor asks for the inspection history of the raw material storage tank. The quality manager opens the shared drive. There is a folder per year, a folder per provider, and reports named after the provider's job number. The most recent thickness campaign is there. The previous one is in an email attachment. Whether the same weld was flagged twice, nobody can answer in the room.

The same scene plays out on the maintenance side before a turnaround (arrêt technique). The planner needs to know which vessels are due, which findings were left open at the last inspection, and which ones the notified body or the insurer will ask about. That information exists. It exists in PDFs that were each read once, by one person, on the day they arrived, and never read together.

No model fixes that. What fixes it is making the history legible: one equipment item, one page, every finding, every measurement, every due date, in order, with the source page behind each value. Once that page exists, AI has something to work on. Before it exists, an AI project in food safety is a demo that survives until the first real question.

In practice: Before an IFS audit, a plant asks its NDT provider to re-send three years of reports because nobody can reconstruct which recommendations were closed. The provider bills for the retrieval, and the reports arrive in two different formats because the provider changed its reporting template in the meantime.

Vision and sensors on the line: what to check before you buy

Line-side AI is the most mature use, and also the one that is easiest to buy badly. Five questions decide whether it survives its first year.

What happens on a format change. Systems that are trained on one product presentation lose accuracy the moment the format, the film, the lighting or the belt speed changes. Ask what retraining costs and who does it.

Who arbitrates a false reject. If the operator has no authority to override, the system gets bypassed within a month. If the operator has full authority with no trace, you have no record.

What record it leaves. A rejection that is not timestamped, attributed and retrievable is invisible in an audit. Ask to see the export before the demo ends.

Whether it talks to anything. A vision system that raises alarms in its own interface, outside the quality system and outside the CMMS (GMAO), creates a second place to look. People stop looking at the second place.

Who maintains the hardware. Cameras drift, lenses get sprayed during washdown, mountings move. This lands on maintenance, so maintenance needs to be in the room before purchase, not after installation.

In practice: A vision system installed on a cooked meat line performs well for four months, then starts over-rejecting after the supplier changes the film supplier. The change is invisible to quality because the rejects are logged only inside the vision software, and the trend is noticed when the yield meeting asks why waste is up.

What AI does not do in food safety

This is the part vendor pages leave out, and it is the part that decides whether your project works.

It does not sign. A CCP decision, a batch release, a recall, the closure of a corrective action: these carry a name and a date. A tool can prepare the file. A person signs it.

It does not create records that were never taken. If the cleaning log was filled in on Friday from memory, nothing recovers the truth of Tuesday.

It does not know your process. A model trained on generic industrial images does not know that your seal defect only appears on the third format change of the day, or that the tank in question is the only one still on the old CIP loop.

It does not replace HACCP. Hazard analysis is a reasoning exercise carried out by people who know the product, the process and the plant. AI can keep the supporting evidence current and flag drift between what the plan says and what the records show. The analysis stays with the team.

It does not turn an unstructured supplier folder into a compliant one. Feeding an assistant a folder of certificates gives you a fluent summary of a folder of certificates.

And it does not lift the burden of proof. In an IFS or BRCGS audit you show the record, the date, the person and the decision. A tool that cannot show where a number came from is a liability in that room.

In practice: An assistant asked to summarise a supplier file reports that allergen management is covered, because the certificate says so. The certificate expired four months earlier, on a page the summary did not weight, and the auditor finds it in under a minute.

Why AI projects stall in food plants

The pattern repeats, and it is rarely technical.

It was scoped by IT rather than by the person who prepares audits. The result answers a question nobody was asking, and the quality team keeps its spreadsheet.

The data was never as clean as the kickoff slide claimed. Equipment names differ between the CMMS (GMAO), the inspection reports and the P&IDs. Until the same tank has one identity, every output is wrong in a way that is hard to see.

Nobody owned it after the pilot. The engineer who ran it moved on. Six months later the tool has no administrator, no updates and no advocate at the management review.

The output landed outside the tools people already use. If a finding does not become a work order in the CMMS or a line in the non-conformity register, it becomes a screenshot in a meeting.

The legal and confidentiality question came last. Somebody asks where the inspection reports are processed, the answer is a service outside the plant's control, and the project pauses. That question is cheaper to answer at the start.

None of these are reasons to avoid AI. They are the specification.

In practice: A pilot on complaint classification is dropped after eight months because the same production line appears under four different names across the complaint register, the CMMS and the quality system, and nobody was given the time to reconcile them.

Where AI fits in HACCP, IFS and BRCGS

Mapping it to the way the standards are actually audited is more useful than a use-case list.

Hazard analysis and its supporting evidence. The plan itself stays human. What ages badly is the evidence behind it: validation studies, supplier data, monitoring records. Software that keeps that evidence current, and that shows when a record contradicts the plan, does real work here.

Monitoring and verification. Monitoring at a CCP is a defined measurement with a defined limit and a named person. AI is not the monitor. It is useful in verification, where you review whether monitoring actually happened as described, across months of records, rather than sampling a few.

Corrective actions and non-conformities. Grouping and trending free-text records is where language models pay for themselves, because it exposes the recurring root cause that individual closure reports never show.

Traceability and supplier approval. Reading and structuring supplier documents, expiry dates, scope of certification, tested parameters, is document work at scale.

Equipment maintenance and calibration. Auditors ask whether product-contact equipment is inspected, maintained and fit for purpose. This is where inspection report history matters, and where most plants are weakest.

In every one of these, what the auditor wants is the record and its provenance. Design for that, not for the dashboard.

In practice: A BRCGS auditor asks how the plant verifies that its metal detector checks were performed on every shift over the last quarter. The team has the paper records, in three binders, and spends the afternoon proving it manually.

Food safety and equipment integrity are the same question

This is the part that gets separated by the organisation chart and never by the product.

A heat exchanger tube that is thinning is a maintenance topic until it perforates, and then it is a contamination event: utility fluid, glycol or steam condensate on the product side. A tank whose internal surface is pitting is an integrity finding and a hygiene finding at the same time, because a pitted surface does not clean. A weld on a process line that an NDT report (CND) flagged two campaigns ago sits in a maintenance folder, while the same equipment appears in the HACCP plan under a different name.

Pressure equipment (ESP in France) adds a second calendar on top of the food safety one: periodic inspections, requalification deadlines, and a file that must hold together in front of a different inspector. Quality rarely sees that calendar. Maintenance rarely sees the HACCP plan.

This is where AI is genuinely useful and almost never applied, because the two document sets sit in two different places, owned by two different people, in two different vocabularies. Bringing them onto one equipment history is unglamorous and it is the single change that most plants would feel within a quarter.

In practice: During a turnaround, a plate heat exchanger is opened for a planned gasket change. The last NDT report, filed under the maintenance provider's job number, had recommended a follow-up inspection of two plates. Nobody in the shutdown meeting had read it, and the follow-up is scheduled for the next shutdown, a year later.

How Lucens Integrity handles the report problem

Lucens Integrity is software that reads inspection report PDFs on the plant's own machines and rebuilds the integrity history of each piece of equipment: the findings, how the measurements evolve from one campaign to the next, the due dates, and the file you need when someone asks for proof.

Two design choices are worth stating plainly.

It runs locally. Reports stay on the site's machines. There is no upload of inspection data to an outside service, which removes the confidentiality conversation that stalls so many projects and keeps the answer simple when an auditor asks where the data lives.

It is faithful to the source, by construction. What the report says is what appears. Values are traceable back to the page they came from. Nothing is inferred to fill a gap, and a field the report does not contain stays empty rather than being guessed. That is a deliberate limit: an integrity history that quietly invents a value is worse than no history.

The annual fee is set by the number of equipment items covered. Users and sites are unlimited, because the people who need the history are in quality, in maintenance and at group level, and charging per head guarantees nobody looks.

In practice: A site loads three years of thickness inspection reports from two different NDT providers. Each equipment item ends up with one page showing the measurement points, how each reading has moved campaign after campaign, the open recommendations and the next due date, which is the page the auditor asks for and the page the shutdown meeting never had.

A way to start that does not need a programme

You do not need a strategy, a data lake or a steering committee. You need one visible result.

Pick one equipment family. The one that generates the most questions: storage tanks, process piping, heat exchangers, whichever comes up every audit.

Gather twelve months of documents for it. Inspection reports, NDT reports, maintenance interventions, cleaning validations. Do not clean them first. The mess is the point, and the exercise is worthless on tidied inputs.

Rebuild the history. One page per equipment item, findings in order, measurements over time, open recommendations, next due date, with the source behind each value.

Take it to a real meeting. The next audit preparation, or the next shutdown planning session. See whether it answers questions faster than the shared drive did. That is the only benchmark that matters, and you get it in weeks, not quarters.

Then decide. If it changed the meeting, extend it to the next equipment family. If it did not, you spent a small amount of time and learned something specific about your own records, which is more than most AI pilots deliver.

In practice: A plant runs the exercise on its storage tanks before an IFS audit. Two open recommendations from a previous campaign, both closed verbally and never documented, surface during the preparation rather than during the audit.