La IA en QHSE: en qué destaca realmente y adónde van tus datos

Hoy en día, todos los proveedores de software de QHSE cuentan con una presentación sobre IA. Sin embargo, muy pocos de ellos pueden explicarte adónde van a parar tus informes de incidentes una vez que el modelo los ha analizado. Esa segunda pregunta es más importante que la primera, ya que los registros de accidentes y de salud laboral no son datos empresariales al uso, y porque la normativa que regula el uso de la IA en el ámbito laboral ha vuelto a cambiar este verano.

En qué aspectos destaca realmente la IA en materia de QHSE en la actualidad

Si dejamos de lado las demostraciones, hay tres tareas en las que un modelo de lenguaje ya se ha ganado un hueco en un sistema de QHSE. Las tres siguen el mismo patrón: se recibe una gran cantidad de texto no estructurado y una persona tiene que convertirlo en algo estructurado antes de que se pueda sacar algún provecho.

Clasificar lo que llega

Un conato de accidente notificado desde un almacén a las 6 de la mañana llega en forma de tres frases escritas en un teléfono. Alguien tiene que decidir si se trata de un conato de accidente o de un incidente, a qué centro y proceso pertenece, en qué categoría de riesgo se enmarca y quién debe hacerse cargo de él. Un modelo realiza bien esa clasificación y lo hace de forma coherente, que es precisamente lo que cuesta a los humanos en doce centros y cuatro idiomas. Deja que el ser humano se encargue de la fase de aprobación: el modelo propone y el responsable de QHSE confirma.

Resumen de una auditoría o de un documento extenso

Una auditoría interna genera cuarenta páginas de notas que solo leerán tres personas. Un modelo convierte todo eso en una lista de conclusiones, una clasificación por gravedad y un borrador de plan de acción en cuestión de segundos. La ventaja no radica en el tiempo que se ahorra en redactar el informe, sino en que el resumen se elabora realmente, en lugar de quedarse guardado en una carpeta hasta la próxima revisión de la dirección.

Leer lo que nunca se escribió

El OCR combinado con un modelo es el ganador silencioso de los tres. Fichas de datos de seguridad, certificados de proveedores, placas de identificación de equipos, hojas de inspección escritas a mano, permisos escaneados: todo ello es texto que tu sistema no puede buscar actualmente. El mero hecho de extraer las fechas de caducidad de los certificados de los proveedores elimina toda una tarea de seguimiento manual, y es el tipo de trabajo que falla en silencio cuando nadie tiene tiempo para dedicarle.

En qué sigue fallando

Predicción de accidentes. Los proveedores comercializan análisis predictivos de seguridad basados en conjuntos de datos demasiado pequeños y con un sesgo demasiado elevado como para respaldarlos. Una instalación con once incidentes registrables en tres años no contiene ninguna señal predictiva, y un modelo al que se le pida que encuentre una dará, de todos modos, una respuesta con un alto grado de confianza. Considera cualquier afirmación predictiva como una pregunta sobre los datos de entrenamiento: ¿cuántos sucesos, durante qué periodo y procedentes de cuántas instalaciones comparables?

Tomar cualquier decisión de forma independiente. Cerrar una acción correctiva, considerar que un hallazgo de auditoría cumple con los requisitos, autorizar un permiso de trabajo: todas estas son decisiones que implican responsabilidad. Alguien tiene que asumir la responsabilidad de forma nominal, y esa persona no puede ser un modelo. Esto no es solo una buena práctica. Si tu sistema evalúa el comportamiento de los trabajadores, es también ahí donde se concentra el riesgo normativo, como veremos a continuación.

Trabajar sin contexto. Un modelo general desconoce tu taxonomía de riesgos, tus códigos de emplazamiento o la diferencia entre cómo utilizan el término «incidente» tu equipo de mantenimiento y tu equipo de SST. Sin esa base, genera respuestas que parecen correctas pero que clasifican de forma errónea. La solución pasa por consultar tus propios datos estructurados, no por un modelo más grande.

Por qué tus datos de QHSE se enmarcan en una categoría jurídica más estricta

Esta es la parte que se suele omitir en la mayoría de las conversaciones sobre la contratación de IA. Según el RGPD, los datos relativos a la salud constituyen una categoría especial de datos personales, tal y como se establece en el artículo 9, y su tratamiento está prohibido salvo que se aplique una excepción específica. En el contexto laboral, la vía habitual es la excepción relativa a las obligaciones en el ámbito del Derecho laboral y de la Seguridad Social. Esa vía está sujeta a condiciones: solo es aplicable cuando la legislación de la Unión o de los Estados miembros, o un convenio colectivo, autorice el tratamiento y establezca las garantías adecuadas. El tratamiento de carácter puramente médico se rige por otra excepción diferente y, en Francia, queda bajo la responsabilidad del servicio de medicina del trabajo, amparado por el secreto médico. Tu delegado de protección de datos (DPO) debería confirmar en qué fundamento jurídico se basa realmente cada uno de tus registros de QHSE, ya que no todos se basarán en el mismo.

Fíjate en lo que realmente contiene un sistema de QHSE. Un informe de accidente identifica a un empleado, describe una lesión y, a menudo, registra el seguimiento. Un expediente de enfermedad profesional es, por definición, información sanitaria. Un registro de exposición vincula a un trabajador identificado con un agente cancerígeno o químico a lo largo de los años. Una restricción de aptitud para el trabajo es una limitación laboral registrada a nombre de una persona concreta, derivada de un dictamen médico del que tu organización no dispone. Nada de esto son datos operativos ordinarios, y nada de ello debería tratarse con la misma ligereza que un registro de seguimiento de proyectos.

De ello se derivan tres consecuencias prácticas, que se aplican independientemente de si se incorpora o no la IA:

• El acceso debe estar realmente restringido, según el cargo, la sede y el departamento, y no mediante una convención de carpetas compartidas que todo el mundo ha dejado de respetar.
• Los cambios deben poder rastrearse. Quién modificó la descripción de una lesión y cuándo es una pregunta que, tarde o temprano, te planteará un inspector, un comité de empresa o un abogado.
• La ubicación física de los datos se convierte en una cuestión real, no en una mera formalidad informática. En Francia, la certificación HDS constituye el marco de referencia para el alojamiento de datos sanitarios personales, y supone un criterio razonable para exigir el cumplimiento a un proveedor de QHSE, incluso en aquellos casos en los que la obligación sea discutible.

Si añades un modelo de lenguaje a ese panorama, habrás añadido un nuevo procesador, una nueva transferencia y una nueva copia de los datos más confidenciales que tienes. Lo cual nos lleva a la única pregunta que realmente importa.

La pregunta que hay que hacerle a cualquier proveedor: ¿dónde va la indicación?

Cuando tu herramienta de QHSE te ofrece la posibilidad de resumir un informe de accidente, hay algo que sale de tu sistema. El texto de ese informe, incluyendo el nombre y la lesión, se envía al lugar donde se ejecuta el modelo. Plantea tres preguntas: qué proveedor, en qué país y en qué condiciones contractuales en lo que respecta a la conservación de datos y la formación.

En realidad, solo hay tres arquitecturas en el mercado, y la diferencia entre ellas no radica en el rendimiento, sino en la visibilidad.

La razón por la que la geografía no es sinónimo de paranoia es la Ley CLOUD de EE. UU., que permite a las autoridades estadounidenses, con una orden judicial o una citación, obligar a un proveedor sujeto a la jurisdicción de EE. UU. a entregar los datos que obren en su poder, custodia o control, incluidos los datos almacenados en servidores fuera de Estados Unidos. Cabe señalar que el criterio es la jurisdicción de EE. UU. y no la ubicación de la sede central en EE. UU., lo cual es más amplio de lo que la mayoría de la gente supone, y que abarca los datos en poder de las filiales. La ley sí prevé que un proveedor pueda solicitar la anulación de la orden cuando la divulgación entre en conflicto con la legislación extranjera, pero ese es un proceso sobre el que no se tiene control. Se trata de un riesgo jurisdiccional más que de una falla de seguridad, y el cifrado en reposo gestionado por el proveedor no lo resuelve, ya que es el proveedor quien posee las claves.

Hay otra cosa que conviene solicitar, que casi nadie ofrece y que cada vez gusta más a los auditores: un registro de todas las llamadas de IA. Qué documento, qué modelo, qué usuario y cuándo. Así, la afirmación de que «utilizamos la IA de forma responsable» se convierte en algo que realmente se puede demostrar.

La Ley de IA, en su versión vigente en octubre de 2026

El panorama normativo ha cambiado este verano, y gran parte de la documentación orientativa publicada ha quedado obsoleta. A continuación se expone la situación actual, en términos sencillos.

La Ley de IA de la UE clasifica determinados sistemas utilizados para la gestión del empleo y de los trabajadores como de alto riesgo, según el punto 4 del anexo III, incluidos los sistemas utilizados para supervisar y evaluar el rendimiento y el comportamiento de los trabajadores. El Paquete Ómnibus Digital sobre IA, aprobado por el Parlamento el 16 de junio de 2026 y por el Consejo el 29 de junio de 2026, y en vigor desde julio, aplazó hasta el 2 de diciembre de 2027 las obligaciones relativas a los sistemas autónomos de alto riesgo del anexo III. En el caso de la IA integrada en productos ya regulados por la legislación de la UE en materia de seguridad, el plazo se amplía hasta agosto de 2028. Las obligaciones de transparencia previstas en el artículo 50, incluida la obligación de informar a las personas de que están interactuando con un sistema de IA, se aplican a partir del 2 de agosto de 2026, con un período de gracia hasta el 2 de diciembre de 2026 para el marcado legible por máquina del contenido generado en los sistemas que ya se encuentran en el mercado. Las prácticas prohibidas están en vigor desde febrero de 2025. Cabe señalar lo que el Omnibus no hizo: no restringió la categoría de empleo ni modificó los criterios de clasificación. Solo se modificaron las fechas.

Hay dos interpretaciones posibles, y la segunda es la que resulta útil.

En primer lugar: la mayoría de las aplicaciones de la IA en el ámbito de QHSE no entrañan un alto riesgo. Resumir un informe de auditoría, extraer una fecha de un certificado, clasificar un incidente según su categoría de riesgo: ninguna de estas tareas supone una evaluación del trabajador. No se está creando un sistema de alto riesgo por el mero hecho de añadir OCR a tu base de documentos.

En segundo lugar: en el momento en que tu sistema evalúe a los operadores en función de su comportamiento en materia de seguridad, clasifique a los equipos según la tasa de incidentes en todo lo que afecte a su carrera profesional o señale a personas concretas como perfiles de riesgo, es muy probable que hayas entrado en el ámbito de aplicación del anexo III. Existe una vía de escape en el artículo 6, apartado 3, para los sistemas que solo realizan una tarea procedimental limitada o que no influyen de manera significativa en el resultado de una decisión, pero recurrir a ella requiere una evaluación documentada y un registro, por lo que es una conclusión a la que se llega sobre el papel y no algo que se dé por sentado. El aplazamiento hasta diciembre de 2027 es tiempo para hacerlo bien, no un permiso para saltárselo. Las organizaciones que mantengan una ficha del modelo, un paso de aprobación humana y un registro de decisiones para cada función de IA considerarán el plazo de 2027 como una mera formalidad. Las que no lo hagan pasarán un trimestre reconstruyendo lo que hizo su proveedor.

Siete preguntas que debes hacerle a tu proveedor

Imprime esto y llévatelo a tu próxima demostración. Las respuestas permiten distinguir rápidamente entre una plataforma seria y una presentación de IA.

1. ¿Qué modelo procesa mis indicaciones y dónde está alojado?

   Quieres el nombre de un proveedor y un país, no «un LLM líder» ni «la nube».

2. ¿Se utiliza mi contenido para entrenar el modelo de alguien?

   Pídelo en el contrato, no en las preguntas frecuentes. Las políticas que figuran en la documentación del producto pueden cambiar sin previo aviso.

3. ¿Puedo elegir un modo diferente para cada caso de uso?

   La traducción de un procedimiento y el resumen de un informe de accidente no deberían tener que compartir la misma estructura.

4. ¿Existe un registro de todas las llamadas de IA?

   Documento, modelo, usuario, marca de tiempo. Esta será tu prueba en la próxima auditoría.

5. ¿Dónde está el paso de la aprobación humana?

   Si un modelo puede cerrar una acción o resolver un hallazgo sin ayuda, eso es un problema de diseño, no una característica.

6. ¿Hay alguna función que evalúe a cada trabajador por separado?

   En caso afirmativo, pregunte directamente cómo se está preparando el proveedor para cumplir las obligaciones del anexo III que entrarán en vigor a partir de diciembre de 2027.

7. ¿Quién está sujeto a la Ley CLOUD en esta cadena?

   Incluidos los subencargados del tratamiento. La respuesta suele ser diferente a la relativa a la plataforma principal.

El enfoque de TimeTonic

TimeTonic ofrece las tres arquitecturas mencionadas anteriormente y te permite elegir según cada caso de uso: IA en la nube pública para contenidos habituales, IA soberana privada alojada en Francia y un servidor de IA dedicado cuando tu sector o tus clientes lo requieran. Tus datos nunca alimentan los modelos de terceros, el alojamiento cuenta con la certificación HDS y se registra cada llamada a la IA. Los permisos se gestionan por rol, centro y departamento, lo cual es fundamental para el registro de accidentes mucho antes de que intervenga ningún modelo. Encontrarás un análisis en profundidad de los tres modos en nuestra guía completa sobre la oferta de IA de TimeTonic.

Preguntas frecuentes