AI in QHSE: what it actually does well, and where your data goes

Every QHSE software vendor now has an AI slide. Very few of them can tell you where your incident reports go once the model has read them. That second question matters more than the first, because accident and occupational health records are not ordinary business data, and because the rules governing AI at work moved again this summer.

What AI actually does well in QHSE today

Strip away the demos and there are three jobs where a language model earns its place in a QHSE system right now. All three have the same shape: a lot of unstructured text arrives, and a human has to turn it into something structured before anything useful can happen.

Classifying what comes in

A near miss reported from a warehouse at 6am arrives as three sentences typed on a phone. Someone has to decide whether it is a near miss or an incident, which site and process it belongs to, which risk family it falls under, and who should own it. A model does that triage well, and it does it consistently, which is the part humans struggle with across twelve sites and four languages. Keep the human on the approval step: the model proposes, the QHSE lead confirms.

Summarising an audit or a long document

An internal audit produces forty pages of notes that three people will ever read. A model turns that into a findings list, a severity ranking and a draft action plan in a few seconds. The gain is not the writing time. It is that the summary actually gets produced, instead of sitting in a folder until the next management review.

Reading what was never typed

OCR plus a model is the quiet winner of the three. Safety data sheets, supplier certificates, equipment nameplates, handwritten inspection slips, scanned permits: all of it is text your system cannot currently search. Extracting expiry dates from supplier certificates alone removes an entire manual watch task, and it is the kind of work that fails silently when nobody has time for it.

What it still does badly

Predicting accidents. Vendors sell predictive safety analytics on datasets that are far too small and far too biased to support it. A site with eleven recordable incidents over three years does not contain a predictive signal, and a model asked to find one will produce a confident answer anyway. Treat any predictive claim as a question about the training data: how many events, over what period, from how many comparable sites?

Deciding anything on its own. Closing a corrective action, judging an audit finding compliant, clearing a permit to work: these are accountability decisions. Someone has to own them by name, and that someone cannot be a model. This is not only good practice. If your system evaluates worker behaviour, it is also where the regulatory risk concentrates, as we will see below.

Working without context. A general model does not know your risk taxonomy, your site codes or the difference between how your maintenance team and your HSE team use the word “incident”. Without that grounding it produces answers that look right and classify wrong. The fix is retrieval from your own structured data, not a bigger model.

Why your QHSE data sits in a stricter legal category

This is the part most AI procurement conversations skip. Under the GDPR, data concerning health is a special category of personal data under Article 9, and its processing is prohibited unless a specific exception applies. In an employment context the usual route is the exception covering obligations in the field of employment and social security law. That route is conditional: it is open only where Union or Member State law, or a collective agreement, authorises the processing and provides appropriate safeguards. Purely medical processing sits under a different exception again and, in France, stays with the occupational health service under medical secrecy. Your DPO should confirm which basis each of your QHSE registers actually relies on, because they will not all rely on the same one.

Look at what a QHSE system actually holds. An accident report names an employee, describes an injury, and often records the follow up. An occupational illness file is health data by definition. An exposure register links an identified worker to a carcinogenic or chemical agent over years. A fitness-for-duty restriction is a working restriction recorded against a named individual, derived from a medical opinion your organisation does not itself hold. None of this is ordinary operational data, and none of it should be treated with the same casualness as a project tracker.

Three practical consequences follow, and they apply whether or not you add AI:

• Access has to be genuinely restricted, by role, by site and by department, not by a shared folder convention that everyone has drifted out of.
• Changes have to be traceable. Who modified an injury description, and when, is a question you will be asked eventually, by an inspector, by a works council, or by a lawyer.
• Where the data physically sits becomes a real question, not an IT formality. In France, HDS certification is the reference framework for hosting personal health data, and it is a reasonable bar to hold a QHSE vendor to even where the obligation is arguable.

Add a language model to that picture and you have added a new processor, a new transfer, and a new copy of the most sensitive data you hold. Which brings us to the only question that really matters.

The question to ask every vendor: where does the prompt go?

When your QHSE tool offers to summarise an accident report, something leaves your system. The text of that report, including the name and the injury, travels to wherever the model runs. Ask three things: which provider, in which country, and under what contractual terms regarding retention and training.

There are really only three architectures on the market, and the difference between them is not performance. It is exposure.

The reason geography is not paranoia is the US CLOUD Act, which allows US authorities, with a warrant or subpoena, to compel a provider subject to US jurisdiction to produce data in its possession, custody or control, including data stored on servers outside the United States. Note that the test is US jurisdiction rather than a US head office, which is broader than most people assume, and that it reaches data held by subsidiaries. The Act does provide for a provider to move to quash where disclosure would conflict with foreign law, but that is a process you do not control. This is a jurisdictional exposure rather than a security flaw, and provider-managed encryption at rest does not address it, because the provider holds the keys.

One more thing to ask for, which almost nobody offers and which auditors increasingly like: a log of every AI call. Which document, which model, which user, when. It turns “we use AI responsibly” into something you can actually show.

The AI Act, as it stands in October 2026

The regulatory picture changed this summer, and a lot of published guidance is now out of date. Here is the current state, in plain terms.

The EU AI Act classifies certain systems used for employment and worker management as high risk under Annex III point 4, including systems used to monitor and evaluate the performance and behaviour of workers. The Digital Omnibus on AI, adopted by Parliament on 16 June 2026 and by Council on 29 June 2026 and in force since July, deferred the obligations for standalone Annex III high-risk systems to 2 December 2027. AI embedded in products already covered by EU safety legislation moves to August 2028. Transparency obligations under Article 50, including telling people they are interacting with an AI system, apply from 2 August 2026, with a grace period to 2 December 2026 for machine-readable marking of generated content on systems already on the market. The prohibited practices have been in force since February 2025. Note what the Omnibus did not do: it did not narrow the employment category or change the classification criteria. Only the dates moved.

Two readings of that, and the second one is the useful one.

The first: most QHSE uses of AI are not high risk. Summarising an audit report, extracting a date from a certificate, classifying an incoming event by risk family: none of that evaluates a worker. You are not building a high-risk system by adding OCR to your document base.

The second: the moment your system scores operators on safety behaviour, ranks teams by incident rate for anything touching their career, or flags individuals as risk profiles, you have very likely walked into Annex III. There is an escape route in Article 6(3) for systems that only perform a narrow procedural task or do not materially influence the outcome of a decision, but relying on it requires a documented assessment and registration, so it is a conclusion you reach on paper rather than one you assume. The deferral to December 2027 is time to get that right, not permission to skip it. Organisations that keep a model card, a human approval step and a decision log for each AI feature will treat the 2027 deadline as a formality. Organisations that do not will spend a quarter reconstructing what their vendor did.

Seven questions to put to your vendor

Print this and take it to your next demo. The answers separate a serious platform from an AI slide very quickly.

1. Which model runs my prompts, and where is it hosted?

   You want a provider name and a country, not “a leading LLM” or “the cloud”.

2. Is my content used to train anyone's model?

   Ask for it in the contract, not in the FAQ. Policies in product documentation change without notice.

3. Can I choose a different mode per use case?

   Translating a procedure and summarising an accident report should not have to share an architecture.

4. Is there a log of every AI call?

   Document, model, user, timestamp. This is your evidence at the next audit.

5. Where is the human approval step?

   If a model can close an action or clear a finding unaided, that is a design problem, not a feature.

6. Does any feature evaluate individual workers?

   If yes, ask directly how the vendor is preparing for the Annex III obligations applying from December 2027.

7. Who is subject to the CLOUD Act in this chain?

   Including subprocessors. The answer is often different from the one about the main platform.

How TimeTonic approaches it

TimeTonic offers the three architectures above and lets you pick per use case: public cloud AI for ordinary content, private sovereign AI hosted in France, and a dedicated AI server where your sector or your clients require it. Your data never feeds a third party's models, hosting is HDS certified, and every AI call is logged. Permissions work by role, site and department, which is the part that matters for accident records long before any model is involved. The deep dive on the three modes is in our complete guide to the TimeTonic AI offer.

Frequently asked questions