La IA como asistente de la comisión: del agente en la nube a la investigación offline de incidentes

Cómo pasamos de los primeros experimentos en la nube a un flujo de trabajo operativo «herramienta de enmascaramiento → agente de IA → desenmascaramiento», después creamos un sistema de investigación offline de pruebas y hoy nos preparamos para el siguiente paso: Fire, el entorno corporativo protegido de IA.

Idea principal: la IA no debe «designar al culpable» ni sustituye a la comisión. Su papel útil es ayudar a la comisión a reunir más rápido materiales dispersos en un cuadro único, detectar lagunas, verificar la lógica causal y preparar un primer borrador de trabajo de la investigación.

Cómo empezó todo

Nuestros primeros intentos de usar la IA en la investigación de incidentes se remontan a 2023. Entonces la idea parecía bastante sencilla: crear nuestro propio agente, cargar en él la metodología de investigación y los materiales de un suceso concreto y pedirle que elaborara la cronología, encontrara contradicciones en las declaraciones escritas y propusiera causas y medidas.

En 2024 las capacidades de los modelos se ampliaron notablemente: empezaron a trabajar con soltura no solo con texto, sino también con imágenes. Uno de los primeros experimentos ni siquiera fue una investigación propiamente dicha. En un activo remoto, una trabajadora sufrió una caída y se lesionó una pierna. La radiografía se hizo allí mismo, pero no había ningún especialista que pudiera interpretarla de inmediato. Cargamos la imagen en la IA y el modelo señaló una zona que parecía una fractura del quinto metatarsiano.

Lo subrayo a propósito: aquello no era un diagnóstico médico ni debe serlo. La valoración definitiva de una imagen médica corresponde al médico. Pero para nosotros ese episodio fue una señal técnica importante: el modelo es capaz de detectar en una imagen detalles que a un no especialista se le pueden escapar. Por tanto, en una investigación podría trabajar no solo con texto, sino también con esquemas, fotografías y otros materiales.

Primera versión operativa: un agente en la nube

Cuando aparecieron agentes personalizados más estables, empezamos a configurarlos directamente según nuestra metodología corporativa. Creamos versiones en GPT, Gemini y Perplexity; en una fase temprana probamos también Grok. Al agente se le cargaba la metodología y, después, las declaraciones escritas, la descripción inicial, documentos sueltos y otros materiales.

El efecto práctico se notó enseguida. La IA cotejaba rápidamente los testimonios, proponía la secuencia de los hechos, detectaba discrepancias de horas y de formulación y elaboraba una lista de preguntas adicionales. Para la comisión resultaba útil como un «segundo analista» que no se cansa de releer decenas de páginas.

Pero la primera versión tenía un defecto evidente: en la práctica, entregábamos a un servicio externo materiales reales de la investigación. En el caso de los incidentes esto es especialmente delicado: los materiales pueden contener nombres y apellidos, cargos, datos médicos, declaraciones escritas, fotografías e información interna de la empresa.

Cuanto más usábamos la herramienta, más claro quedaba que la comodidad no puede justificar el envío de datos innecesarios al exterior.

Véase el anexo de prompts: Prompt 1, versión segura del agente en la nube para trabajar únicamente con materiales anonimizados previamente.

La metodología se volvió más exigente, y eso cambió los requisitos para la IA

Paralelamente evolucionaba la propia metodología corporativa de investigación interna. Para mí esto es clave: a la IA no se le puede dar la potestad de «inventar por sí misma cómo investigar». Primero debe existir la metodología, y solo entonces se construye sobre ella la herramienta digital.

Según la metodología vigente, el objetivo principal de la comisión no es buscar un culpable, sino desarrollar las medidas más eficaces posibles para eliminar o reducir la probabilidad de que un suceso similar se repita. Si en la cadena hay una acción humana, hay que ir más allá y averiguar por qué esa acción fue posible o se consideró admisible.

La investigación se estructura según la lógica de las barreras de protección: fuente de peligro → evento no deseado → consecuencias; por separado se analizan las barreras preventivas y las de mitigación. En la fase de análisis de la información se construye la línea de tiempo y se identifican los factores críticos. A continuación se elabora el árbol de causas, que debe conducir desde las causas inmediatas e intermedias hasta las causas raíz sistémicas.

En los análisis más sencillos, la cadena de preguntas «¿Por qué?» puede ser corta. En un suceso complejo se ramifica y se convierte en un árbol de causas completo. La lógica de barreras del «bow-tie» ayuda a comprobar por separado por qué ocurrió el suceso y por qué las consecuencias fueron precisamente esas.

Fue precisamente esta secuencia la que más tarde se convirtió en el esqueleto de nuestra aplicación local.

Véase Prompt 2–6: cronología y factores críticos → preguntas y contradicciones → barreras → árbol de causas → medidas.

Segunda versión: enmascaramos a mano

La siguiente etapa fue mucho más segura, aunque bastante incómoda. Antes de cargar los materiales en el agente en la nube, sustituíamos a mano los apellidos y otros datos sensibles: «Trabajador 1», «Trabajador 2», «Jefe 1», «Departamento 1», etcétera.

Desde el punto de vista de la confidencialidad, ya era un paso adelante. El agente veía la lógica del incidente, pero no los nombres reales. Una vez terminado el análisis, había que volver a sustituir a mano las designaciones por los datos reales, a menudo con la búsqueda Ctrl+F.

Mientras los implicados son dos o tres, el proceso es tolerable. Cuando la investigación incluye muchas declaraciones escritas, testigos, documentos y apellidos que se repiten, el enmascaramiento manual y la restitución posterior se convierten en un trabajo aparte y generan riesgo de error.

Tercera versión: herramienta de enmascaramiento local y el problema aparte del audio

Cuando adquirimos soltura en el vibe coding, sustituimos la operación manual por una herramienta de enmascaramiento local, de la que hablé en el primer artículo de la serie. El documento Word se procesa en el ordenador, recibe designaciones convencionales y, por separado, se guarda la clave de desenmascaramiento. La clave está protegida con contraseña y no se entrega al agente.

Después, a la IA en la nube solo se envían las declaraciones escritas y demás materiales ya enmascarados. El resultado obtenido vuelve al ordenador y se restituye localmente. Este es hoy nuestro flujo de trabajo operativo: herramienta de enmascaramiento local → agente de investigación configurado → desenmascaramiento local. Ya permite aprovechar los puntos fuertes del modelo en la nube sin entregarle los nombres originales ni la clave de restitución.

Pero quedaba otra parte vulnerable: las grabaciones de audio. Las declaraciones y las entrevistas se registran cómodamente por voz, pero para analizarlas primero hay que convertirlas en texto. Antes se usaban para ello servicios en línea y aplicaciones móviles independientes. Más tarde la transcripción llegó a los propios grandes servicios de IA. Es cómodo, pero la grabación original con la voz de la persona sigue saliendo al exterior.

Por eso creamos otra herramienta: un transcriptor local. Utiliza Whisper directamente en el ordenador. En nuestras pruebas, la calidad de la transcripción resultó perfectamente comparable a la de las opciones en la nube habituales, y la grabación original no sale del ordenador. Tras la transcripción local, el texto se puede enmascarar y solo entonces, si es necesario, entregarlo al agente de investigación operativo.

La cadena de esta etapa: transcripción local → herramienta de enmascaramiento local → agente en la nube. Para el análisis de los materiales, véase Prompt 1–6.

Cuarta versión: el sistema offline ya existe y ahora lo estamos probando

En ese punto surgió otra pregunta. Si la transcripción, la lectura de documentos y el modelo ya funcionan en local, ¿por qué no reunirlo todo en un único entorno protegido? Así nació el sistema experimental de investigación offline. Ya está desarrollado y funciona, pero hoy lo consideramos deliberadamente un sistema de pruebas: lo verificamos con casos formativos y anonimizados, comparamos sus resultados con el trabajo de la comisión y buscamos las siguientes iteraciones que hagan el proceso más rápido, más cómodo y más robusto.

El objetivo era crear un puesto de trabajo único para la comisión, en el que se pudieran cargar la guía metodológica, la información inicial, las declaraciones escritas, archivos Word y PDF, grabaciones de audio, fotografías y esquemas; convertir localmente en texto la voz y los documentos; recorrer las etapas de la metodología y obtener un primer borrador editable del informe en Word.

Suena sencillo solo cuando se resume en una frase. En la práctica hubo muchísimas iteraciones. El reconocimiento de voz local no funcionó a la primera; después hubo que resolver los PDF escaneados, las imágenes, los materiales voluminosos, el modelo local, la cronología, las causas y el documento final. El esquema de desarrollo fue el mismo que en nuestros otros proyectos: un cambio → ejecución → resultado o captura del error → siguiente iteración con ChatGPT.

Al final surgió un sistema local con interfaz de navegador y su propio entorno de IA local. Ya transcribe bien las grabaciones, lee los materiales preparados y genera un borrador estructurado de la investigación. Nuestra tarea ahora no es declararlo «producto terminado», sino probarlo con calma, comparar resultados y mejorar su lógica de trabajo. Para ejecutar un modelo local completo y procesar rápidamente grandes volúmenes de información conviene disponer de un ordenador con buen rendimiento.

Véase Prompt 8: prompt maestro para desarrollar con vibe coding el puesto de trabajo local de la comisión.

Qué hace ya la versión offline de pruebas

En la versión offline de pruebas, todo el ciclo ya está construido en torno a la metodología, y no en torno a un chat convencional con IA.

Primero, la comisión registra la información inicial: qué ocurrió, la fuente de peligro, el evento no deseado, las consecuencias, los implicados y los resultados de la inspección. Después se elabora el plan: qué preguntas hay que cerrar, a quién entrevistar, qué documentos y peritajes obtener.

En la sección de materiales se pueden cargar archivos DOCX y PDF con texto. Los escaneos y las fotografías pueden reconocerse localmente; los esquemas y las imágenes se guardan en el expediente, y el modelo puede proponer una descripción de los detalles visibles. El audio y el vídeo se transcriben localmente. También es posible grabar una entrevista directamente con el micrófono y obtener después la transcripción.

Tras verificar los materiales, la aplicación ayuda a construir la línea de tiempo. La IA propone hechos y citas, pero la decisión de incluir cada registro la toma la comisión. Los factores críticos se marcan por separado.

El siguiente bloque son las barreras de protección y las causas. La comisión revisa las barreras preventivas y de mitigación y construye dos ramas de partida: por qué se produjo el evento no deseado y por qué las consecuencias fueron esas. Las causas propuestas por la IA siguen siendo hipótesis hasta que la comisión las confirma.

Después de las causas se definen las medidas: a qué causa corresponde cada una, quién es el responsable, el plazo, qué resultado se puede verificar, si hace falta una barrera provisional y si la medida debe extenderse más allá de una sola área.

Y solo entonces se genera el borrador del informe. La aplicación puede montar un primer borrador en Word siguiendo la estructura de la guía metodológica e incluir la cronología, el árbol de causas, las barreras, el registro de materiales y los anexos.

Véase Prompt 2: cronología; Prompt 3: contradicciones y datos que faltan; Prompt 4: barreras; Prompt 5: árbol de causas; Prompt 6: medidas; Prompt 7: borrador del informe final.

Qué hace la IA local y qué no debe hacer

Aquí es importante no sobrestimar la automatización. La IA lee por fragmentos los textos verificados y propone la cronología, preguntas, barreras, hipótesis de causas y opciones de medidas. Puede encontrar una contradicción entre dos declaraciones escritas o advertir que a la cronología le falta un período importante.

Pero una cita de un documento solo confirma que esas palabras figuran realmente en el material. No demuestra que el testimonio sea cierto. El texto reconocido puede contener errores. Un esquema puede interpretarse mal. Un vínculo causal puede resultar ser solo una hipótesis.

Por eso la aplicación se rige por un principio: la IA propone y la comisión acepta, rechaza o edita. Ninguna causa pasa a estar confirmada automáticamente. El modelo no asigna responsables ni plazos. El borrador en Word es precisamente eso, un primer borrador de trabajo, y no un documento para «firmar y listo».

Esto es especialmente importante porque el informe interno no sustituye a los documentos exigidos por la legislación y los procedimientos establecidos. La responsabilidad de la investigación sigue recayendo en la comisión.

Véase Prompt 9: control de la calidad, de la confidencialidad y de los límites de la automatización antes de utilizar el resultado.

La confidencialidad pasó a formar parte de la arquitectura, no de una instrucción aparte

En las investigaciones, la confidencialidad no puede dejarse «para más adelante». La propia metodología clasifica los materiales de la investigación interna como documentos de uso oficial exclusivo y exige expresamente proteger los datos personales al crear y transmitir archivos.

En la versión offline de pruebas, los materiales del expediente, las transcripciones, los resultados del análisis y el documento Word se quedan en el ordenador. El modelo local funciona a través de una dirección loopback y, una vez preparados los modelos necesarios, la sesión de trabajo con el expediente puede realizarse sin salir a internet.

Pero aquí tampoco hay magia. Trabajar en local no significa anonimizar automáticamente. Si se cargan en el expediente nombres y datos médicos, permanecerán en ese ordenador y en los anexos del expediente. Por eso hacen falta las medidas habituales de seguridad de la información: una cuenta de usuario protegida, permisos de acceso, normas de almacenamiento, copias de seguridad y, si es necesario, un enmascaramiento adicional.

Es decir, nuestra evolución no terminó con el eslogan «todo offline, luego todo seguro». Lo correcto es decirlo así: eliminamos el envío innecesario de materiales al exterior y dejamos el control de los datos donde debe estar, dentro de la empresa.

Qué utilizamos hoy

Hoy tenemos, en la práctica, dos flujos. El primero es el operativo: enmascaramos los materiales en local, entregamos una copia anonimizada al agente de investigación configurado y después desenmascaramos localmente el resultado. Este esquema ya puede utilizarse en el trabajo real.

El segundo es el de pruebas: un sistema totalmente offline que transcribe el audio localmente por sí mismo, lee los materiales, ayuda a construir la cronología, las barreras y las causas y genera el primer borrador del informe. Ya funciona, pero seguimos verificándolo y mejorándolo. Para nosotros esto es una cuestión de principio: un piloto no puede presentarse como un sistema de producción maduro solo porque tenga buen aspecto.

Flujo operativo: herramienta de enmascaramiento → agente de investigación de IA configurado → desenmascaramiento.

Flujo de pruebas: puesto de trabajo de la comisión totalmente local → verificación y nuevas iteraciones.

El siguiente paso: Fire, el entorno corporativo protegido

En paralelo, el departamento de IT del Grupo desarrolla en el entorno corporativo Collab una IA interna, Fire. Para nosotros es la siguiente etapa lógica: trasladar la lógica metodológica del asistente de la comisión a un entorno corporativo protegido basado en servidores, donde no haya que elegir entre la potencia de un gran modelo y los requisitos de confidencialidad.

No vemos Fire como un «investigador automático», sino como un entorno más para el mismo principio: los materiales permanecen dentro de una infraestructura protegida, la IA ayuda a la comisión a analizar la cronología, las barreras, las contradicciones y las causas, y las decisiones siguen en manos de las personas.

Antes del traslado hay que comprobar las capacidades técnicas de Fire: el trabajo con documentos y audio, el tamaño del contexto, la segregación de accesos, los registros, el almacenamiento de datos y la exportación de resultados. Es decir, aquí volvemos a partir de la metodología y de la protección de la información, y no del deseo de usar a toda costa el enésimo modelo nuevo.

Vea el vídeo: el ciclo completo de la investigación local

En este artículo evito deliberadamente sobrecargar el texto con decenas de capturas de pantalla casi idénticas. Una grabación de pantalla de tres minutos muestra mejor cómo se conectan los elementos entre sí, qué hace realmente la persona y qué hace el programa.

Las capturas hacen falta allí donde conviene detenerse en la arquitectura: tipos de materiales, cronología, causas, medidas y el Word final. El resto de la mecánica se ve mejor en el vídeo, que está al final del artículo.

Dónde está el ahorro de tiempo

La investigación de un incidente sigue necesitando personas: inspeccionar el lugar, entrevistar a los implicados, obtener documentos, debatir los hechos, tomar decisiones. La esencia del trabajo de la comisión no se puede automatizar.

Pero sí se puede eliminar buena parte de la rutina documental: transcribir audios, cotejar declaraciones escritas, buscar a mano incoherencias temporales, trasladar citas a la cronología, hacer la primera distribución de barreras, dar forma al árbol de causas, preparar la lista preliminar de medidas y montar el primer borrador del informe.

Y para mí el efecto principal no está en reducir el número de especialistas. Al contrario: si el especialista dedica menos tiempo al trabajo mecánico con documentos, gana tiempo para aquello por lo que se hace una investigación: hablar con las personas, trabajar sobre el terreno, verificar las barreras y ayudar a los responsables a evitar que el suceso se repita.

Qué hemos conseguido

En pocos años, el recorrido ha sido revelador: agente abierto en la nube → enmascaramiento manual → herramienta de enmascaramiento y desenmascaramiento locales → transcripción local → sistema offline de pruebas → siguiente paso hacia Fire, el entorno corporativo protegido.

Aun así, la herramienta de trabajo actual no es la versión offline experimental, sino el flujo probado con enmascaramiento: los materiales originales se quedan con nosotros, al agente llega una versión anonimizada y la restitución se hace en local. El sistema offline lo estamos probando ahora y lo vamos perfeccionando paso a paso.

El cambio más importante ni siquiera es técnico. Dejamos de preguntar a la IA «¿quién tiene la culpa?» y empezamos a preguntarle otra cosa: «¿qué datos faltan, qué barreras fallaron, por qué fallaron y qué medidas reducirán de verdad el riesgo de que se repita?».

Es precisamente en ese papel donde la IA resulta útil en la investigación: no como juez ni como presidente de la comisión, sino como un segundo analista rápido que ayuda a las personas a trabajar con los hechos en mayor profundidad.

Y algo más: no hay que olvidarse de la inteligencia natural

Cuanto más potentes son los modelos, más importante es no cederles nuestro propio pensamiento. La inteligencia artificial es útil cuando potencia la natural: ayuda a ver antes las conexiones, a comprobar una hipótesis, a montar un borrador y a liberar tiempo para hablar con las personas y trabajar sobre el terreno.

Por eso, para mí el camino correcto es no limitarnos a ser usuarios de botones ya hechos, sino convertirnos en creadores de nuevas soluciones: entender la metodología, definir la arquitectura, verificar el resultado, corregir errores y hacernos más fuertes junto con la herramienta.

Hay que usar la IA, pero la inteligencia natural propia hay que ejercitarla y desarrollarla en la misma medida. Y si esa combinación ayuda a investigar los sucesos con más profundidad, a aprender mejor de ellos y a evitar que se repitan, entonces la tecnología está realmente al servicio de la seguridad.

Prompts del artículo

Flujo operativo con enmascaramiento → sistema offline de pruebas → siguiente paso hacia Fire, el entorno corporativo protegido

Estado actual: en el trabajo real se utiliza el flujo «herramienta de enmascaramiento local → agente en la nube configurado → desenmascaramiento local». El sistema totalmente offline ya está desarrollado, pero se encuentra en fase de pruebas y mejoras. Fire se contempla como la siguiente etapa corporativa protegida.

Prompt 1. Agente operativo actual: solo materiales anonimizados

Relación con el artículo: secciones «Tercera versión» y «Qué utilizamos hoy». Es el flujo de trabajo operativo vigente tras el enmascaramiento local.

Eres el asistente analítico de una comisión de investigación interna de un incidente en materia de seguridad y salud en el trabajo y seguridad industrial.

FLUJO DE TRABAJO:
Los documentos originales se enmascaran primero en local. Solo recibes copias anonimizadas. Después de tu trabajo, el resultado se desenmascara localmente con una clave y una contraseña independientes que tú no tienes.

IMPORTANTE:
- trabaja únicamente con materiales anonimizados previamente;
- no intentes recuperar nombres y apellidos, departamentos, direcciones ni otros valores ocultos;
- no uses internet ni hechos externos, salvo que se te proporcionen expresamente;
- no determines culpables;
- no presentes una hipótesis como un hecho establecido;
- no sustituyas la decisión de la comisión.

Objetivo: ayudar a la comisión a estructurar los materiales y comprobar que la investigación esté completa.

En cada conclusión distingue:
FACT — confirmado directamente por el material;
ASSUMPTION — suposición fundamentada;
CONFLICT — contradicción entre materiales;
GAP — información que falta;
QUESTION — pregunta que es necesario cerrar;
HYPOTHESIS — posible causa que requiere confirmación.

Orden de trabajo:
1. Elabora un registro de los materiales recibidos.
2. Extrae únicamente hechos verificables, indicando la fuente.
3. Elabora una cronología preliminar.
4. Muestra las contradicciones y las lagunas.
5. Formula preguntas adicionales para la comisión.
6. Una vez confirmada la cronología, propón el análisis de barreras.
7. Formula las causas solo como hipótesis hasta que decida la comisión.
8. Vincula las medidas únicamente a causas confirmadas.

En todas las tablas indica la fuente: número del material, documento/archivo y una cita breve o el lugar exacto en que se basa la conclusión.

Prompt 2. Cronología de los hechos y factores críticos

Relación con el artículo: sección sobre la cronología en el agente operativo y en el sistema offline de pruebas.

Te paso los textos verificados de los materiales del incidente.

Elabora un BORRADOR de la línea de tiempo.

Reglas:
1. No añadas hechos que no figuren en los materiales.
2. Si la hora es exacta, indícala como exacta.
3. Si la hora es aproximada, márcala como «aproximada».
4. Si dos fuentes dan horas o secuencias distintas, no elijas una opción en silencio; muestra CONFLICT.
5. En cada fila indica: fecha/hora; hecho o condición; fuente; estado FACT / ASSUMPTION / CONFLICT; por qué es importante.
6. Propón por separado una lista de factores críticos: hechos/condiciones sin los cuales el evento no deseado o la gravedad de las consecuencias probablemente habrían sido distintos.
7. No consideres aprobados los factores críticos hasta que decida la comisión.

Al final entrega:
A. borrador de la cronología;
B. lista de contradicciones;
C. lista de datos que faltan;
D. borrador de factores críticos para que los debata la comisión.

Prompt 3. Contradicciones, lagunas y plan de entrevistas adicionales

Relación con el artículo: secciones sobre la planificación, la recopilación de materiales y el papel de la IA como segundo analista.

A partir de los materiales y del borrador de la cronología, prepara una hoja de trabajo para la comisión.

Debes:
1. Encontrar contradicciones entre declaraciones escritas, documentos, horas y datos técnicos.
2. No interpretar una diferencia de formulación como una mentira sin pruebas.
3. Para cada contradicción, indicar: fuente A; fuente B; en qué consiste exactamente la diferencia; qué hay que comprobar.
4. Formular preguntas para una entrevista adicional.
5. Las preguntas deben ser abiertas y neutrales, sin sugerir la respuesta.
6. Elaborar por separado una lista de documentos, mediciones, peritajes, fotos o esquemas que puedan cubrir la laguna.
7. Marcar qué preguntas son críticas para establecer las circunstancias, las barreras de protección, las causas y la gravedad de las consecuencias.

No concluyas que un testimonio no es fiable solo porque exista una contradicción.

Prompt 4. Lógica de barreras y «bow-tie»

Relación con el artículo: sección sobre la lógica de barreras y el paso a las causas.

Utiliza la cronología y los factores críticos confirmados por la comisión.

Elabora un BORRADOR del análisis de barreras.

1. Fuente(s) de peligro.
2. Evento no deseado.
3. Consecuencias.
4. Barreras preventivas: qué barrera debía haber evitado el evento/contacto; si existía; si estaba disponible; si se aplicaba; si funcionó; fuente de confirmación.
5. Barreras de mitigación: qué barrera debía haber evitado las consecuencias o reducido su gravedad; si existía; si funcionó; fuente de confirmación.
6. Para cada barrera ausente o ineficaz, formula la pregunta «¿Por qué?».

No califiques automáticamente la ausencia de una barrera como causa raíz.
No inventes barreras que no figuren en la metodología, en los documentos o en la lógica del proceso sin marcarlas como HYPOTHESIS.

El resultado es una tabla para que la comisión la debata, no una conclusión aprobada.

Prompt 5. Árbol de causas y causas raíz

Relación con el artículo: sección «La metodología se volvió más exigente» y el bloque de causas.

Datos de entrada:
- cronología confirmada;
- factores críticos;
- análisis de barreras;
- decisiones de la comisión sobre los hechos confirmados.

Construye un BORRADOR del árbol de causas.

Punto de partida: «Evento no deseado + consecuencias».
Las dos primeras ramas:
A. ¿Por qué se produjo el evento no deseado?
B. ¿Por qué se produjeron esas consecuencias / por qué su gravedad fue esa?

A continuación:
1. En cada nodo pregunta «¿Por qué?» tantas veces como sea necesario para llegar a la causa sistémica.
2. Vincula cada causa con su pregunta de origen.
3. Cada factor crítico debe reflejarse en el árbol o explicarse por separado como excluido.
4. No tomes la acción/error de una persona como causa raíz. Continúa el análisis: por qué la acción fue posible o se consideraba admisible.
5. Propón una causa raíz solo si describe una deficiencia concreta del proceso/sistema; es subsanable; está dentro del ámbito de control de la empresa/del Grupo; permite proponer una medida concreta.
6. Se prohíben las formulaciones genéricas sin desarrollar: «baja cultura», «imprudencia personal», «mala organización», «deficiencias en la formación».

Para cada nodo:
- formulación;
- tipo: inmediata / intermedia / candidata a causa raíz;
- fuentes que la confirman;
- factores críticos relacionados;
- estado FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

No confirmes una causa raíz en lugar de la comisión.

Prompt 6. Medidas correctivas y preventivas

Relación con el artículo: sección sobre las medidas y el ahorro de tiempo en la preparación del primer borrador.

Utiliza solo las causas que la comisión haya decidido incluir en la lista para el desarrollo de medidas.

Para cada causa, propón de 2 a 4 opciones de medidas.

Para cada opción indica:
- qué causa concreta elimina o qué barrera refuerza;
- tipo: técnica / organizativa / formación / control / otra;
- resultado esperado y verificable;
- cómo comprobar su eficacia;
- ámbito de aplicación: lugar del suceso / instalaciones similares / empresa / Grupo;
- si hace falta una medida de protección provisional hasta que se implante la permanente;
- posibles riesgos colaterales;
- qué datos se necesitan para fijar el plazo y el responsable.

No rellenes el nombre del responsable ni un plazo concreto sin decisión de la comisión.
No propongas una medida del tipo «impartir una instrucción extraordinaria» como solución universal si no elimina la causa establecida.
Marca por separado las medidas que solo refuerzan el control, pero no eliminan la causa raíz.

Prompt 7. Borrador del informe final según la metodología

Relación con el artículo: sección sobre la generación del Word y el principio «primer borrador, no documento para firmar».

Prepara un BORRADOR del texto del informe interno basándote únicamente en los elementos aprobados por la comisión.

Utiliza:
- la ficha del incidente;
- la cronología confirmada;
- la lista de factores críticos;
- el análisis de barreras aprobado;
- el árbol de causas definitivo;
- la lista de causas aprobada;
- las medidas acordadas;
- el registro de materiales.

No incluyas en el resultado como hechos hipótesis no confirmadas, versiones controvertidas sin marcar ni conclusiones sin fuente.

Estructura:
1. Información resumida y circunstancias.
2. Materiales y métodos de recopilación de información.
3. Cronología.
4. Factores críticos.
5. Barreras de protección.
6. Análisis de causas.
7. Causas raíz.
8. Medidas correctivas y preventivas.
9. Anexos / registro de materiales.

Siempre que sea posible, junto a cada conclusión relevante conserva la referencia al material en que se basa.
En la parte superior del documento indica: «BORRADOR. Pendiente de revisión y aprobación por la comisión».
No formules conclusiones sobre culpabilidad.

Prompt 8. Prompt maestro para el sistema offline de pruebas

Relación con el artículo: sección «El sistema offline ya existe y ahora lo estamos probando».

No soy programador. Ayúdame a crear una aplicación local DE PRUEBA para la investigación interna de incidentes según la metodología corporativa. El objetivo de esta etapa es un piloto y la verificación de la calidad, no la puesta en producción automática.

Trabaja paso a paso. En cada paso:
1. explica qué hacemos y para qué;
2. dame una sola acción o un único archivo/parche listo;
3. espera mi resultado o una captura de pantalla;
4. revísalo;
5. solo después pasa al siguiente paso.

ARQUITECTURA OBJETIVO
- Windows 10/11;
- backend local en 127.0.0.1 e interfaz de navegador;
- tras preparar los modelos una sola vez, trabajo con los materiales del expediente sin internet externo;
- prever el trabajo en un ordenador potente; para un equipo modesto, proponer un modelo ligero, sin ocultar la pérdida de calidad/velocidad;
- almacenamiento local de los expedientes;
- archivo del expediente con sumas de verificación;
- historial de versiones;
- ningún envío obligatorio de materiales a API externas.

MATERIALES
- DOCX: párrafos, tablas, encabezados y pies de página;
- PDF con texto;
- PDF escaneados / imágenes: reconocimiento local;
- esquemas / fotografías: guardar el original y proponer la descripción solo como borrador;
- audio / vídeo: transcripción local;
- grabación desde el micrófono;
- introducción y edición manuales;
- marca obligatoria «cotejado con el original» antes de usar el texto en el análisis con IA.

MODELOS LOCALES
- LLM mediante un motor local (por ejemplo, Ollama);
- modelo de voz multilingüe Whisper;
- si es necesario, un modelo vision local;
- la aplicación no debe descargar modelos de forma oculta durante la investigación.

METODOLOGÍA / ETAPAS
1. Información inicial.
2. Plan de la comisión.
3. Recopilación de materiales.
4. Cronología y factores críticos.
5. Barreras y causas.
6. Medidas.
7. Informe.

REGLAS PARA LA IA
- La IA solo propone.
- Cada conclusión conserva su fuente y su cita.
- Distinguir FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Las causas son hipótesis hasta que las confirme la comisión.
- El modelo no asigna por sí mismo responsables ni plazos.
- La comisión debe poder aceptar, rechazar o editar cada propuesta.
- El Word final es un borrador editable.
- Incluir en el informe el árbol de causas, las barreras, el registro y los anexos.

SEGURIDAD
- sin CDN ni telemetría externa;
- conexiones de red de la investigación solo por loopback;
- advertir al usuario de que trabajar en local no equivale a anonimizar automáticamente;
- no guardar secretos en el código del cliente, que queda expuesto;
- prever la eliminación del expediente, la copia de seguridad y el traslado.

Empieza por la arquitectura de directorios, el formato de datos del expediente y el modelo de amenazas. No escribas código hasta que yo lo confirme.

ESTADO DE PILOTO
- marca explícitamente la versión como «DE PRUEBA / PILOTO»;
- añade un conjunto de casos formativos de control;
- en cada caso, compara el resultado de la IA con las conclusiones de la persona/comisión;
- lleva un registro de los defectos encontrados y de las iteraciones;
- no califiques el sistema como listo para producción hasta que terminen las pruebas.

Prompt 9. Auditoría del sistema offline piloto

Relación con el artículo: secciones sobre los límites de la automatización, la confidencialidad y el estado actual de pruebas.

Audita la aplicación terminada y el borrador de la investigación antes de entregarlos a la comisión.

COMPRUEBA LO TÉCNICO
1. Si hay conexiones de red externas durante el trabajo con el expediente.
2. Si se usan CDN, fuentes tipográficas externas, speech-to-text en la nube o API externas.
3. Dónde se almacenan los originales, las transcripciones, los modelos locales y las copias de seguridad.
4. Qué ocurre al eliminar un expediente.
5. Si los documentos originales acaban en los registros de diagnóstico.
6. Si el contenido del expediente sale al exterior cuando se produce un error.

COMPRUEBA LO METODOLÓGICO
7. Si todas las conclusiones relevantes tienen fuente.
8. Si los hechos están separados de las hipótesis.
9. Si todos los factores críticos se reflejan en el análisis de causas.
10. Si se han señalado acciones humanas como causa raíz sin analizar las condiciones sistémicas.
11. Si las medidas están vinculadas a causas/barreras concretas.
12. Si el modelo ha asignado responsables y plazos sin decisión de la comisión.
13. Si el borrador del informe se presenta como documento aprobado.

COMPRUEBA LA CONFIDENCIALIDAD
14. Qué datos personales/médicos hay en el expediente local.
15. Si se requiere un enmascaramiento adicional para una demostración, publicación o transmisión.
16. Si los nombres de archivo y las capturas de pantalla contienen nombres y apellidos innecesarios.

Entrega el resultado en forma de tabla:
Comprobación | Estado | Riesgo detectado | Qué corregir | Quién debe confirmarlo.

No corrijas automáticamente las conclusiones de fondo de la investigación.

COMPRUEBA EL NIVEL DE MADUREZ
17. Si existe un conjunto de casos de control y resultados de la comparación.
18. Qué funciones ya son estables y cuáles siguen siendo experimentales.
19. Qué errores/limitaciones deben eliminarse antes del uso en producción.
20. Si la interfaz da la falsa impresión de que la conclusión de la IA es una decisión de la comisión.

Cómo usar los prompts

• Prompt 1: el flujo operativo actual; solo materiales anonimizados previamente; la clave de desenmascaramiento no se entrega al agente.
• Prompt 2–7: bloques de trabajo metodológicos que pueden usarse tanto en el agente actual como en el futuro entorno local o de servidor.
• Prompt 8: creación y mejora continua del sistema de pruebas totalmente offline.
• Prompt 9: auditoría del piloto antes de ampliar su uso.

El principio básico de la serie sigue siendo el mismo: primero protegemos los datos y fijamos la metodología; después automatizamos. La IA potencia el trabajo de la comisión, pero no anula el pensamiento profesional, la verificación de los hechos ni la responsabilidad humana.