Vaughn Gruneberg wants a safety management system that tells him where to look tomorrow as well as what happened yesterday. An unstable approach, a recurring defect or a fatigue report may each warrant attention, and examining the circumstances around them, along with the relationships across information held in different systems, can give safety teams earlier warning of a developing problem.
At AAD 2026, Solenta’s Manager, Flight Safety & OHSE set out how artificial intelligence can support that work. His examples ranged from flight data monitoring and engineering trends to the hundreds or thousands of narrative reports an organisation accumulates. Throughout, responsibility stays with the people who interpret the information and decide what to do about it.
“AI doesn’t make the safety decision. It helps us see the decision sooner.”
For many years, Gruneberg explained, aviation safety was predominantly reactive. An occurrence prompted an investigation, the cause was identified and corrective action followed so that it would not happen again, and legislation and regulation reflected those experiences. Safety management systems (SMS) moved the discipline upstream by asking what hazards were already present in an operation, even where they had not yet produced an occurrence.
Technology now allows a further step, from proactive to predictive, looking for precursors and changes in exposure and eventually working towards an adaptive process in which information already being received helps an operator adjust its controls. In his view AI extends the reach of SMS rather than replacing it, taking the discipline from learning what happened to understanding what is happening and asking what might happen next.
Gruneberg reduces AI’s contribution to four functions: detect, connect, forecast and translate.
Detection finds weak signals or something unusual among thousands of events. Connection identifies relationships between information that appears unrelated, forecasting shows where exposure is increasing before a threshold is crossed, and translation turns large amounts of complicated or unstructured information into something people can actually see.
What Happens Before an Unstable Approach?
Flight data monitoring already gives operators a much better understanding of their normal operations. Gruneberg proposes changing the familiar question of which approaches were unstable to what tends to happen before instability develops. That means looking at energy state changes, weather, airports, pilot duty periods and aircraft variation, together with clusters of events that have not exceeded current thresholds. The aim is to identify a system condition that is becoming more likely to produce an unsafe outcome, rather than an unsafe pilot, so that quiet signals are seen before they become loud ones.
He gave a hypothetical example of three unstable approaches, none particularly dramatic, at the same airfield, in similar weather and at a similar point in the duty period. None of those factors would trigger an alarm individually, but together they give the safety team a reason to look closer. In an adaptive SMS, the operator applies targeted controls and then monitors whether they work, using the result to inform the next decision. The human remains accountable, and the management loop becomes faster and better informed.
Engineering follows the same principle. A small vibration change, a temperature trend, oil pressure or oil temperature, consumption and a recurring minor defect each say little on their own, but connected they tell a different story. Technology can identify that deterioration earlier and bring it to the engineer’s attention before a traditional threshold is reached. The engineer still makes the technical decision, now with information that arrives earlier and may prevent escalation, repeated defects and operational disruption.
Safety reports are another large source of weak signals. Drawing on Solenta Aviation’s own volume of data, Gruneberg points out how difficult it is for one person to identify every connection once an organisation holds hundreds or thousands of narrative reports. AI can suggest classifications, identify common themes, find similar reports and propose questions investigators might ask, which allows safety professionals to read more without asking personnel to write more. He draws a line at just culture outcomes and the closing of safety reports, both of which stay with people because context still matters, particularly where the data relates to individuals.
Fatigue, Reporting and Trust
Combining duties, roster times, time of day and workload information shows where fatigue exposure is increasing, which Gruneberg notes as incredibly valuable. He also identifies a fine line between understanding system exposure and creating individual surveillance.
“I don’t want technology to secretly decide that a particular person is a high-risk employee.”
His interest is in where the system creates greater exposure and how people can be helped. If personnel believe fatigue information or safety reports will be used against them, they stop trusting the safety system, and the quality of the safety information goes with that trust.
“Trust itself is a safety control.”
Predictive systems depend on the quality of the information people choose to report, so preserving confidence in the reporting process is part of making the information useful.
Gruneberg also separates compliance, which tells an operator whether it can operate, from risk management, which asks whether it should. Answering the second question properly means looking beyond individual data sources. Operators already produce or receive flight data, safety reports and maintenance defects, along with weather, terrain, wildlife, fatigue, workload, air traffic control, airport and security information. None of this is new, he notes, but it often sits in different systems managed by different departments. An unstable approach trend can then be read alongside late duty periods, weather and particular airports, and a technical trend alongside the environment, utilisation and operating conditions. Risk, as the Swiss cheese model illustrates, usually builds from several small factors beginning to align.
The same logic extends beyond a single organisation. In his example, one operator sees an increase in bird activity or bird strikes, another records go-arounds and the airport receives wildlife incursion reports. Each holds a piece of the picture, and connecting them changes the assessment of the risk. Operators, airports, regulators, OEMs and maintenance organisations may each be seeing part of the same risk picture, which leads Gruneberg to describe collaboration, and not AI alone, as one of the major evolutions in safety. He adds that none of it works without trust.
Bringing AI into the Safety System
Gruneberg is equally direct that AI creates hazards of its own. Bad data produces bad outputs, and he stresses that an operator can only evolve with clean data. Historical data can contain bias, and AI-generated answers can sound extremely convincing and still be wrong. Automation bias is a further concern: the better technology becomes, the easier it is to stop challenging it, so someone still has to ask why, whether the answer makes sense and what the context is. Connecting more information also increases cyber, privacy and data protection exposure.
From an SMS perspective, he says, the answer is familiar: treat AI like any other hazard source by identifying the hazards, assessing the risks, putting controls around it and monitoring whether those controls work. Accountability cannot be outsourced. AI can advise, and the human decides.
Before AI touches operational safety decisions, he proposes five questions:
- What safety problem is the operator trying to solve?
- Is the information complete, lawful, protected and representative?
- How is the output validated as good enough, and who reviews and challenges it?
- Who ultimately owns the decision?
- And how will the operator know when the model starts drifting, getting things wrong or producing unintended consequences?
These are safety management questions rather than AI questions, and an operator unable to answer one of them is probably not ready to put the tool into operational safety use.
To describe the relationship between people and technology, Gruneberg uses Formula 1. Procedures, training, reporting systems, flight data monitoring, risk assessments, engineering data and technology make up the car, and people drive it. He likens his own role to the pit wall, where he watches the bigger picture, listens to the driver and studies information from the car to find where the system can improve. He does not steer. AI is just another engineer on that pit wall, able to process enormous amounts of information and say that something is worth a look, but never the driver. Unlike in Formula 1, the objective is not to cross the line first but to have a safer system tomorrow than today, with the machine finding the pattern and the human working out what it means.
For operators across Africa with multiple bases, he acknowledges the practical conditions: mixed fleets, remote locations, different systems and sometimes variable connectivity. His advice is to start small rather than with an enormous AI programme, beginning with clean data, an agreed taxonomy and defined ownership. Operators can then automate routine work such as classification, summaries, trend packs and anomaly screening, and begin connecting higher-value information from flight data monitoring, defects, fatigue and airport hazards.
Larger predictive models and external data sharing come after that, and he sees no need to wait for a perfect system before starting. One of the first returns may simply be time: if AI saves a safety professional five hours of administration, those hours go to analysing hazards, speaking to crews and managing risk.
The longer-term aim is a safety management system that does more than store safety history, one that directs attention to changing exposure while controls are adjusted and their effectiveness reviewed as new information arrives. Gruneberg’s three take-aways are that AI should move safety earlier, that trust is part of the safety architecture, and that AI should be governed like any other safety-critical change, with a defined purpose, validation, risk controls and monitoring. The measure of success, in his words, is what an operator does with what it finds.
“Success isn’t being able to say, we used AI. Success is being able to say, we identified a risk earlier and we did something about it.”
