Radhika Krishnaswamy: “AI Can Detect Hidden Losses, but a Human Must Make the Decision”

“The expensive losses in a dairy plant don’t announce themselves. They hide inside product that’s perfectly in spec. AI earns its keep when it puts a cost on that loss early enough for the shift team to stop it, and when the people on the line can see exactly why it’s asking them to act.”

THEME 1 OF 7: Data and Problem Definition

Q1.1 Which operational challenges at dairy plants can genuinely benefit from artificial intelligence today, and where are conventional automation and statistical process control sufficient?

I'd point to five areas. The first is process losses, the fat, protein and solids that leak away or get given away between stages. The second is unplanned downtime. The third is maintenance on the equipment that wears, like separators, homogenisers, pumps and dryers. The fourth is catching drift early, while it's still small. The fifth is simply keeping each stage in spec as conditions change through the day.

For a single control loop, a safety interlock or a process that depends on one stable variable, conventional automation and SPC are fine and will stay fine. AI should sit on top of that control layer. It shouldn't replace it.

Q1.2 Dairy plants use data from laboratory information systems, ERP, MES, SCADA, equipment sensors, and operator logs. How can these fragmented sources be combined when the data differ in format, frequency, and quality?

The trick is to stop thinking about six systems and start thinking about one process. Every sensor tag, lab result and batch record gets tied to a stage of the line, with a shared time and batch key.

Residence time does most of the work. If you know how long the milk takes to get from the separator to the evaporator, you can line up a sensor reading taken every few seconds with a lab result that comes back three hours later. The data can stay where it already lives. You're mapping it, not moving it.

Q1.3 What is the minimum amount of historical data required before an AI model can begin delivering practical value? Can AI be implemented at a plant where some records are still maintained manually?

One to two years. You need at least one full seasonal milk cycle, otherwise the model will treat spring milk as a fault.

Manual records aren't a reason to wait. Early detection runs mostly on sensor data, and the handwritten logs that really matter can be digitised as you go.

Q1.4 What data problems are most commonly discovered at the beginning of a project: missing values, measurement errors, inconsistent reference data, insufficient data collection frequency, or the absence of links between raw materials, process conditions, and finished products?

The one that comes up most is that some important variables simply aren't measured on line. Fat, protein and total solids at key stages, or moisture after the dryer, are often known only from the lab, hours later, if at all. You can usually estimate them from sensors that move with them. You can also point to the one or two places where adding a measurement would pay for itself quickly.

After that it's the usual list. There's often no link between the raw milk that came in and the product that went out. Clocks disagree between systems, the same tag has three different names, and some sensors haven't been calibrated in a while. None of this is unusual, and most of it gets sorted in the first few weeks.

Q1.5 Who should be responsible for the quality of manufacturing data: the IT department, process technologists, plant management, or a dedicated cross-functional team?

All three, with clear lines between them. Technologists own what the data means. IT owns access and the pipes. Plant management owns accountability.

I'd also name one person per line on the operations side as the data owner. If everyone is responsible for data quality, in practice nobody is.

THEME 2 OF 7: Product Yield and Process Losses

Q2.1 In which areas of dairy processing can AI deliver the most significant economic impact: milk intake and standardization, pasteurization, separation, cheese production, drying, CIP cleaning, energy management, or equipment maintenance?

Dairy rarely loses money in one big event. It loses it in small amounts at almost every stage.

At standardisation, plants give away fat and solids by running blends richer than spec. Pasteurisers over-process, and fouled heat exchangers cost yield and steam. Separators let solids slip into the wrong stream. Cheese lines lose fat and protein to whey. Evaporators and dryers burn the most energy, so a small moisture or steam drift gets repeated on every batch. CIP flushes away product and often runs longer than it needs to. Energy use and unplanned downtime cut across all of these.

You get much more out of treating the line as one system than out of tuning each stage on its own. First you need a live view of every stage, so you can see which one starts to drift. Each deviation then needs a cost attached, and the team needs to know what's actually driving it. Only once the line is steady does it make sense to start moving setpoints.

Where the biggest prize sits depends on what you make. For powder plants it's usually the dryer, for cheese it's whey losses, and for liquid milk it's standardisation giveaway.

Q2.2 How can AI account for the natural variability of raw milk, including seasonal changes, protein and fat content, acidity, bacterial load, and heat stability, when recommending process parameters?

You treat the milk as an input. The intake lab results for fat, protein, acidity, bacterial count and heat stability become part of the context. What counts as normal at each stage is then learned against the milk that's actually arriving.

If the model has two years of history, it has already seen how spring milk behaves differently from autumn milk. So it can judge a separator or standardisation setting against today's milk instead of an annual average.

This is also why I'd always stabilise before optimising. Get every stage holding spec on the current milk first. Then recommend setpoint changes, each with an expected impact that someone can test in a simulation before acting on it.

Q2.3 Can an AI system identify process deviations before they result in an off-specification product but already pose a risk of reducing product yield? Which signals and combinations of parameters does it analyze?

Yes, and frankly this is where most of the money is. A product can be perfectly in spec while the line making it is quietly losing solids or burning extra steam.

Watching at both sensor and subsystem level against learned behaviour, as well as hard limits, picks up drift well before a spec limit is reached. It also catches it long before it shows up in the shift report.

What you look at is how signals move together. On a separator, that's flow, differential pressure and skim fat. On an evaporator, it's steam pressure, vacuum and concentrate solids. On a dryer, it's inlet and outlet temperature, exhaust humidity and powder moisture. On a butter line, it's cream temperature, churning time and fat in the buttermilk.

Each finding should come with a confidence level and a plain description of what's happening. It should also say what it's likely to do downstream and roughly what it's costing per hour.

Q2.4 Could you provide a specific example in which an AI model identified a hidden cause of production losses that conventional methods had failed to detect? Which performance indicators changed after the solution was implemented?

Take a whey protein line, where an ultrafiltration membrane concentrates whey to WPC-80. The membrane starts to foul. Permeate flux drops a little below where it normally sits, and pressure creeps up to compensate. No alarm goes off, and from the control room the skid looks like it's holding rate.

Multivariate monitoring catches the membrane behaving differently from its history. When you connect that to what's happening downstream, the real picture appears. Protein is going out with the permeate, yield is falling and purity is sliding towards the 80% floor, with a possible downgrade at the end of it.

A conventional alarm system, if it noticed at all, would have seen four separate problems: flux, pressure, yield and purity. In reality there's one, a fouling membrane. The fix is to adjust cross-flow and feed temperature, and to schedule a CIP if flux doesn't recover. The operator accepts the change, and the case is tracked until it's closed.

What moves afterwards is protein yield and the share of product made in grade. The time between the first sign of trouble and someone acting on it drops from a shift or more to minutes.

Q2.5 Which metrics should be used to evaluate the results of an AI project: increased finished-product yield, reduced fat and protein losses, lower reject rates, reduced water and energy consumption, shorter downtime, or lower unit production costs?

They're all valid, but I'd pick one or two as the headline. Agree them in writing before any work starts, put them in money terms, and measure them against the plant's own baseline, not a vendor's benchmark.

For most lines, that means product recovery and unplanned downtime. Product recovery is finished product per kilo of milk solids received. Everything else on your list supports those two.

I'd also track two adoption numbers: how many recommendations operators accept, and how long it takes from detection to a decision. If those don't move, the financial results won't either.

Q2.6 How can a company distinguish the actual effect of AI implementation from the impact of seasonality, changes in raw-milk quality, equipment upgrades, or improvements introduced by plant technologists?

You have to build measurement in from day one. Set the baseline from the plant's own history, corrected for milk composition and season, so you're comparing like with like. Log equipment upgrades, new procedures and the technologists' own improvements on the same timeline, so you can separate their effect out.

Most importantly, count value one event at a time. Every recommendation gets logged with the decision, the expected impact and what actually happened. Then savings trace back to specific, dated decisions instead of being read off a monthly yield number.

If the plant has two similar lines, running one with the system and one without for a while gives you a proper control. You want a result you can show, not one you have to argue for.

THEME 3 OF 7: Early Detection of Process Deviations

Q3.1 How does AI-based prediction of process deviations differ from a conventional alarm system based on threshold values for temperature, pressure, acidity, and other parameters?

A threshold alarm watches one number and fires when it crosses a line. By then, the loss has usually already happened.

AI-based monitoring learns how each part of the line normally behaves, from the plant's own data. It watches individual sensors and whole subsystems, and it pays attention to patterns, persistence and context as well as limits. That means it can spot a problem forming while every single reading is still inside its alarm band, which gives you time to stabilise the stage before it goes out of spec.

The other difference is what lands in front of the operator. SCADA can throw dozens of alarms for one underlying problem. A good system rolls those up into a single event. It says what changed, why it probably happened, what it affects upstream and downstream, what it's likely to cost and what to do next.

Hard limits and safety interlocks stay exactly where they are.

Q3.2 How far in advance can an AI system warn an operator about a potential process disruption? Does this provide enough time to take corrective action?

It depends on the kind of problem. Gradual ones show up hours, sometimes days, before they touch the product. That includes membrane or heat-exchanger fouling, build-up in evaporators and dryers, separator wear and slow sensor drift. That's plenty of time to act.

Sudden failures, like a valve sticking or a power trip, give you little or no warning, and nobody should pretend otherwise.

Luckily for dairy, most yield and energy loss is the gradual kind. Catching it at the start of a shift, with a suggested fix, beats reading about it in tomorrow's report.

Q3.3 How is the balance between model sensitivity and the number of false alerts managed? What happens if operators begin ignoring warnings because they occur too frequently?

You design for it from the start. Don't send operators every sensor deviation. Group them, so one problem means one notification. Give each one a confidence level and an estimated cost. Show operators only what needs action, and keep the detail for engineers. If something has no real business impact, don't raise it at all.

Sensitivity is best tuned with the operators themselves, during a stretch of parallel running before go-live.

If operators start ignoring warnings, that tells you the system needs retuning. It isn't a discipline problem. If every recommendation has to be formally accepted or rejected, you'll see the acceptance rate fall straight away, and that should trigger a review.

Q3.4 Can the model distinguish between deviations caused by raw-material quality, operator error, equipment wear, and failure to follow the required process parameters?

Mostly, yes, because each cause looks different in the data. Poor raw milk shows up in the intake lab results and affects several stages at once. Wear shows up as a slow drift in one subsystem, usually with pressure, flow or temperature moving with it. Not following the recipe shows up as a gap between standard and actual setpoints. Operator actions are visible if every change is recorded with what, when and who. A faulty sensor usually gives itself away because it stops agreeing with its neighbours.

When several deviations come from one upstream cause, the diagnosis should say so and show the evidence, instead of handing over a list of separate faults. When the data really can't tell two causes apart, the system should say that too and leave the call to the technologist.

Q3.5 What happens when a plant changes a recipe, raw-material supplier, piece of equipment, or production line? Does the model need to be retrained?

It depends on the size of the change. A new milk supplier is mostly absorbed, because milk composition is already an input. A new recipe is a new operating mode, so its normal range is learned from its first runs. New equipment means that stage has to be re-learned and checked again. A new line needs its own setup, though much of the integration work can be reused.

The system should also tell you when it's out of date. You'll see deviations popping up across a stage with no real impact behind them. When that happens, retrain deliberately and validate it with the technologists. It should never happen quietly in the background.

THEME 4 OF 7: Explainability and Human Control

Q4.1 What information should an operator receive together with an AI-generated warning: the presumed cause of the deviation, the model's confidence level, the contributing parameters, the expected consequences, or a recommended action?

All of it, but in layers. At first glance, the operator needs to know three things: what's drifting, how sure the system is, and what it suggests doing.

One click down, they should see what changed, the likely cause, the evidence, the knock-on effect upstream and downstream, and the expected cost. They should also see a trend of the signal against its normal behaviour.

Engineers and managers should be able to open the full diagnosis and the history of the case, including who owns it and where it stands. An operator should be able to act in seconds, and a technologist should still be able to check every step.

Q4.2 How detailed should the AI system's explanation be to allow a dairy technologist to assess and verify its recommendation using professional judgment?

Detailed enough to check against the plant. It should show which deviations it grouped, what cause they share and the evidence for that. Every claim should trace back to actual sensor values and trends, and the suggested fix should be testable in a simulation first.

Then a technologist can confirm it, for example by seeing that membrane pressure rose before flux fell. Or they can throw it out because they know that sensor was being serviced that morning. If you can't check a recommendation this way, don't act on it.

Q4.3 Who is responsible for a decision made on the basis of an algorithmic recommendation, particularly when that decision may affect food safety or compliance with mandatory processing requirements?

The plant. The system recommends and the plant decides. Responsibility stays with whoever holds it under the food safety plan and HACCP, the same as if the advice had come from a consultant or a senior colleague.

Critical control points like pasteurisation time and temperature stay under validated control. They should never be handed to an algorithm.

What the system does add is a clean record. You get every recommendation, the reasoning, the decision, who made it and what happened next. That helps your quality and compliance processes. It doesn't replace them.

Q4.4 Should an AI system only inform plant personnel, or can it be permitted to change process parameters autonomously? Where should the boundary of acceptable autonomy be drawn?

For now, it should advise. It proposes a setpoint change with its reasoning and expected impact, and the operator says yes or no.

Further down the road, I can see closed-loop control making sense for a few narrow, well-understood, non-safety settings. Energy-related setpoints within tight bounds are one example. Even then, you'd need a long track record, hard limits enforced by the control system and an instant manual override.

It should never extend to critical control points, product release, allergen management or anything else that touches food safety or compliance.

Q4.5 How are cases recorded when an operator rejects an AI recommendation? Is this feedback used to improve the model?

Every decision gets recorded, yes or no, with what changed, when and by whom, next to the event and the suggested action.

Rejections are some of the most useful data you'll get. Sometimes the operator knew something the model didn't, like a sensor under maintenance or a planned changeover, and that makes the next diagnosis better. Sometimes the model was right, and the case becomes something the team learns from.

Either way, rejections should be reviewed regularly and fed into model updates.

Q4.6 Could excessive automation result in plant personnel losing essential technological expertise? How can companies ensure that operators remain capable of assessing the process independently and responding to abnormal situations?

It's a real risk, and it's the best argument for keeping people in the loop. If the system shows its reasoning and the operator has to approve each change, people learn the process instead of losing touch with it.

Over time, the log of problems and fixes becomes something you can search. It holds knowledge that used to live only in the heads of your most experienced shift staff, and it stays when they retire.

Plants should still train for manual running and abnormal situations, run drills and review cases across shifts. You want operators who understand the line better because of the system, not operators who can't run it without one.

THEME 5 OF 7: Implementation and Economics

Q5.1 What does a typical pilot project involve? How is the production line or process selected, how long does data preparation take, and which criteria are used to decide whether the solution should be scaled up?

Keep it to one line. First, get access to the data, agree the yield and downtime metrics in writing, and set the baseline from one to two years of the plant's own history. Next, model the line's stages, sensors and spec ranges, and let the system learn what normal looks like. Then go live in parallel with operators, engineers and management trained on it. After that, measure against the baseline.

Choose the line where you suspect margin is leaking, where the data is there and where the team actually wants to try it. Scale up only when three things are true. The agreed metric has moved, operators are acting on the recommendations, and the data has held up.

Q5.2 What investments are required beyond the AI platform itself, including additional sensors, system integration, data preparation, employee training, and ongoing model maintenance?

Most plants don't need new sensors to get started. The system connects to what's already there: PLC, SCADA and DCS, historians, LIMS and QMS, ERP and MES, and BI tools.

The main cost on the plant's side is people's time. That means some IT effort for data access, and operations time for training and getting the floor comfortable with it.

On top of the software, budget for hosting, either on-premises as capex or cloud as opex. Add usage charges if root-cause reasoning relies on an external large language model, and ongoing model upkeep.

Sometimes a pilot shows that one extra measurement would be worth adding. That's a call to make on the evidence, not a condition of starting.

Q5.3 How can the expected economic impact be calculated before implementation if the company does not yet know the actual scale of its hidden process losses?

Start with a mass balance from data you already have. Compare milk solids received with solids in finished product, and both with what you could theoretically recover. Add standardisation giveaway from lab results against spec, energy and water per tonne by stage, and downtime from production logs.

Even a fraction of a percent of unrecovered solids, multiplied by a year's intake and product value, usually justifies a pilot.

The pilot then replaces your estimate with real numbers. Once each deviation carries a cost, sorted into quality, yield and throughput, or utilities, you quickly see where the margin is going. That becomes the business case for the next line.

Q5.4 What payback period can realistically be expected? Could you provide examples that include baseline indicators and independently verifiable results?

Payback depends on line volume, product value and where the losses actually sit, so I'd be wary of anyone who quotes one number. It comes fastest when there's no new hardware to buy, when deployment takes weeks rather than quarters, and when integration work carries over to the next line.

What matters more than a headline figure is whether the result can be checked. If the baseline was agreed in writing before work began, and every accepted recommendation is logged with its expected and actual impact, anyone can verify the value event by event. Any partner you work with should be comfortable being measured that way.

Q5.5 Are these solutions economically viable for small and medium-sized dairy processors, or are they mainly suitable for large plants with continuous production?

Yes, they're viable for mid-sized processors, as long as you start sensibly. Begin with your most important line, use the sensors you already have, and consider cloud hosting so it sits in opex. Batch and semi-continuous processes work as well as continuous ones.

The one real requirement is that the line already produces digital data through a historian, SCADA or something similar. Because value grows with volume, a very small plant might do better starting with a conversational tool over its ERP, MES and lab data, before going to real-time process monitoring.

Q5.6 What most frequently prevents successful implementation: insufficient data, outdated equipment, integration difficulties, employee resistance, a shortage of qualified specialists, or the absence of a clearly defined business objective?

The absence of a clear business objective with a named owner. Without an agreed metric, the project turns into a technology exercise that nobody is accountable for. Agree the metric and baseline in writing before anything gets built.

After that come data gaps, especially variables that aren't measured on line, and operators who don't trust the recommendations. Trust comes when operators only see what needs action and every suggestion comes with its reasoning.

Old equipment is rarely the real problem. If it produces data, it can usually be connected.

THEME 6 OF 7: Reliability and Security

Q6.1 How is a model's accuracy validated before it is used in live manufacturing? Is it initially tested in parallel without being allowed to interfere with the production process?

Yes, in two steps. First, test it on history. Would it have caught the incidents the plant already knows about, and how many false alarms would it have raised? Then run it in parallel with live production, with technologists reviewing what it flags without acting on it, until it meets criteria everyone agreed beforehand.

Even after go-live, it stays advisory. Nothing changes on the line without an operator saying yes.

Q6.2 How is deterioration in model performance monitored over time? Who should retrain and validate the model, and how often should this be done?

The system's own records tell you. Watch how many events lead to action, how often recommendations are accepted or rejected, and how far actual results land from what was expected. Watch the input signals too, so you know when the process has moved away from what the model learned.

Retraining should be shared. Data scientists do the technical work, and the plant's technologists check the result against what they know about the process. A quarterly review works well, plus a retrain after a seasonal shift, a recipe change or new equipment.

Q6.3 How are a dairy manufacturer's operational data protected? Where are the data stored, and can the system operate entirely within the customer's own IT environment?

The manufacturer should own its process data, full stop, and the contract should say so. A technology partner licenses software, not the plant's know-how.

The system can run entirely on-premises inside the plant's own IT environment, or in the cloud if that's company policy. Either way, access should depend on role, with separate views for operators, engineers and management, and every action should be logged.

One thing to raise early: if root-cause reasoning uses an external large language model, that piece needs an outside connection. Plants with strict data-residency or air-gap rules should settle how that's handled at the start, not halfway through.

Q6.4 Can a model developed for one dairy plant be transferred to another, or does each facility require individual configuration based on its equipment, raw materials, and process specifications?

Both. The same core can run on butter, milk powder, whey protein, cheese and MPC lines. Diagnostic patterns carry across similar processes well, and integration work can be reused.

What doesn't carry over is what's normal for each plant. Every line needs its stages, sensors and spec ranges set up and its own behaviour learned from its own data. No two plants have the same equipment, the same milk or the same way of running.

Q6.5 Which technological limitations should customers understand before beginning a project? In which situations should AI recommendations never be accepted without additional human verification?

AI can't see what isn't measured. It can't fully correct for a sensor giving bad readings, although it can flag one it suspects. It's weakest on things that have never happened before. A root-cause diagnosis is a likely explanation backed by evidence, not proof, and language models do make mistakes, which is why the evidence should always be on screen.

Never accept a recommendation without a person checking it when it touches food safety, critical control points, allergens, product release or regulatory compliance. The same applies when it's outside the validated operating range, when confidence is low, or soon after a big change to a recipe, piece of equipment or line. If the system is advisory, that check happens by default.

THEME 7 OF 7: Experience from Other Industries and Future Development

Q7.1 Which methods already used in the chemical, pharmaceutical, oil and gas, or pulp and paper industries could be transferred to dairy manufacturing?

Quite a few. Multivariate process monitoring from chemicals and refining is how you learn normal behaviour across many signals at once. Golden-batch analysis and continuous process verification from pharma let you judge a run against your own best runs. Mass-balance reconciliation from sugar and pulp and paper is how you put a cost on each deviation. Predictive maintenance from heavy industry fits separators, homogenisers, membranes and pumps well.

A lot of the AI that works in dairy is these established methods, adjusted for the biology and hygiene demands of milk.

Q7.2 Which characteristics of the dairy industry make the direct transfer of such solutions difficult: the biological variability of raw milk, short product shelf life, hygiene requirements, or the difficulty of measuring product quality in real time?

All four, and they make each other harder.

Milk changes with season, herd and region, so a model built for a fixed feedstock breaks quickly. It has to learn in the context of what's coming in, which is why two years of history matters. Short shelf life means little room for rework, so you have to catch problems early. Hygienic design limits where you can put inline sensors, and frequent CIP cycles chop up the data. And a lot of quality is still measured in the lab, hours after the fact.

On top of that, dairy plants run lots of products on shared lines with frequent changeovers. So methods from other industries have to be rebuilt around stages, residence times and milk composition. You can't just copy them across.

Q7.3 What do you see as the next stage in the use of AI at dairy plants: finished-product quality prediction, autonomous process optimization, digital twins, predictive maintenance, or end-to-end management of the entire production chain?

I see these as steps in order, not options to pick from. A live digital twin comes first, because you can't optimise what you can't see. Next is stabilisation and real-time quality prediction, so each stage holds spec without waiting for the lab. Setpoint optimisation follows once the line is steady. It starts advisory and later moves to closed loop for a few non-safety settings.

The longer-term step is connecting the whole chain. That means linking milk quality at the farm, plant performance and demand, so collection, processing and product mix are planned together. Each step depends on the one before it being properly in place.

Q7.4 Which applications of AI in dairy manufacturing have already been proven in full-scale industrial operation, and which capabilities remain experimental?

Proven at industrial scale are anomaly detection on process data, predictive maintenance on rotating equipment, energy and utility monitoring, demand forecasting, multivariate process monitoring and live digital twins for visualisation.

In use but still maturing are generative-AI reasoning that pulls many deviations into one root-cause diagnosis, and conversational access to plant and business data.

Still mostly experimental are fully autonomous closed-loop optimisation, real-time prediction of complex quality outcomes like cheese ripening, and optimising the whole chain from farm to customer.

Q7.5 If a dairy manufacturer wanted to begin working with AI today, which single production challenge would you recommend addressing first, and why?

Product recovery on your highest-volume line. Find out where milk solids are being lost or given away through standardisation, separation, concentration and drying. It's measured in money, and the data is already in your historians and lab systems. It doesn't touch food-safety controls, and you see results in weeks rather than years.

Most plants know their annual yield figure, but they can't tell you which twenty events last month caused it. So they can't stop the twenty-first. Answering that question against your own baseline builds the business case, and the trust on the floor, for everything that comes after.