Del inventario a los escenarios de riesgo

Empieza por el uso concreto

Un mismo sistema puede intervenir en actividades distintas y producir consecuencias diferentes. Por eso conviene partir del identificador de uso, su finalidad y el proceso en el que participa. El nombre comercial de una herramienta no explica por sí solo qué debemos evaluar.

En nuestro inventario didáctico, SYS-001 es el copiloto, con USO-001 para propuestas de código y USO-002 para propuestas de respuesta; SYS-002 es el chatbot, con USO-003 para atención de primer nivel; SYS-003 es el clasificador, con USO-004 para propuestas de criticidad y destino. Son tres sistemas y cuatro usos propuestos para el ejercicio. No estamos afirmando que existan tres proveedores ni que el inventario esté completo.

Comprueba la relación de cada uso con el alcance aprobado. Si el alcance actual comprende únicamente el chatbot, estudiar los otros usos como ejemplos no los incorpora automáticamente al SGIA. Anota “fuera del alcance actual” o “inclusión pendiente”, según corresponda.

Sigue el recorrido de una salida

Describe qué información entra, qué produce el sistema, quién recibe esa salida y cómo llega a influir en una acción. La cadena puede tener varias revisiones, automatismos o decisiones posteriores. Localizar esos pasos ayuda a entender dónde podría aparecer una consecuencia.

En USO-004 sabemos que se proponen criticidad y destino. No sabemos, por ese dato, si la propuesta se aplica automáticamente, si una persona la revisa o qué ocurre cuando discrepa. Esas preguntas siguen abiertas. Una revisión prevista en un procedimiento no prueba que se haya realizado eficazmente en un caso concreto.

Para el ejercicio podemos formular una condición: “si una propuesta de prioridad insuficiente se aplica sin una corrección eficaz…”. Así analizamos una posibilidad sin convertirla en un hecho. Conserva siempre esa condición cuando resumas el escenario.

Construye una frase que pueda contrastarse

Una estructura útil es: en este uso y contexto, debido a una condición posible, podría producirse este suceso; si la salida se utiliza de esta manera, podrían derivarse estas consecuencias para estas personas u organizaciones. Es una ayuda didáctica, no un formato obligatorio de ISO/IEC 42001.

Ejemplo hipotético: en USO-003, si el chatbot utiliza una instrucción de la base de conocimiento que ya no es aplicable y su respuesta se sigue sin detectar el cambio, una persona podría ejecutar una acción inadecuada y prolongar la interrupción de su trabajo. Debemos verificar la versión del contenido, la respuesta, el contexto y las acciones posteriores.

La descripción distingue una condición —contenido no aplicable—, un suceso —respuesta inadecuada— y una consecuencia posible —interrupción prolongada—. No atribuye todavía la causa a un proveedor ni afirma que se haya producido un daño.

Cuatro usos, preguntas diferentes

Para USO-001, una hipótesis es que una propuesta de código contenga un defecto relevante y llegue a incorporarse sin detectarlo. La consecuencia depende de dónde se use ese código, qué pruebas existan y si se despliega. Una sugerencia defectuosa descartada no equivale a un fallo en producción.

Para USO-002, una propuesta de respuesta podría incluir instrucciones inadecuadas o información que no corresponda comunicar al destinatario. Debemos conocer qué datos recibió el copiloto, quién revisó la propuesta y qué se envió finalmente. La existencia de una propuesta no demuestra una comunicación efectiva.

Para USO-003, trabajaremos la respuesta basada en contenido no aplicable. Para USO-004, la propuesta de criticidad o destino inadecuados. Estos ejemplos permiten explorar el inventario; no son incidentes confirmados ni una lista exhaustiva de riesgos.

Evita copiar el mismo escenario cambiando únicamente el nombre de la herramienta. Las personas afectadas, el margen de corrección, la velocidad de propagación y los objetivos del proceso pueden variar mucho.

Decide cuándo separar escenarios

Separa escenarios cuando cambien el suceso, las condiciones de aplicación, los afectados o las evidencias necesarias para evaluarlos. “La IA falla” reúne demasiadas situaciones. En cambio, crear un registro por cada ticket idéntico puede fragmentar innecesariamente el análisis.

Puedes agrupar casos comparables y conservar enlaces a sus evidencias, dejando claro por qué comparten condiciones. Si aparece un grupo con consecuencias diferentes, una configuración nueva o un modo de uso distinto, revisa si sigue siendo razonable la agrupación.

Identifica también resultados favorables esperados, como una orientación inicial más rápida. Trátalos como objetivos o efectos por comprobar. No conviertas un beneficio esperado en una compensación automática de posibles perjuicios.

Busca evidencia que responda a una pregunta

Una evidencia útil permite contrastar una afirmación concreta: qué entrada se recibió, qué salida se generó, qué versión estaba activa, cómo se utilizó y qué ocurrió después. Un registro de actividad puede demostrar que hubo una respuesta sin demostrar que fuera adecuada.

Limita los datos recogidos a lo necesario y protege la información de las personas. Siempre que sea suficiente, trabaja con referencias, resúmenes o ejemplos desidentificados. No copies conversaciones completas ni contenido confidencial en una ficha de formación.

Para cada incertidumbre, anota qué fuente ayudaría a resolverla y qué función puede obtenerla. Si existe una incidencia que requiere atención inmediata, actúa por los procedimientos correspondientes; la elaboración del registro no debe retrasar la respuesta.

Actividad y criterio de revisión

Elige dos usos y redacta un escenario para cada uno. Subraya las condiciones no confirmadas. Comprueba que alguien ajeno al ejercicio podría distinguir qué sabemos, qué suponemos y qué falta comprobar.

Una respuesta suficiente identifica el uso, el suceso, la forma de aplicación y al menos una consecuencia potencial. Una respuesta sólida explica además qué evidencia permitiría revisar el escenario. No asignes aún una categoría de riesgo para llenar una casilla.

Tu ficha de trabajo