Análisis de riesgos de IA: el método en 5 pasos antes de aprobar

Antes de aprobar cualquier proyecto de IA, rellena una tabla de cinco columnas: qué puede fallar, qué impacto tendría en el negocio, cómo de probable es, qué harás para evitarlo y quién responde si pasa. Eso es un análisis de riesgos de IA. No hace falta ser ingeniero para hacerlo, y es la diferencia entre decir “sí” con criterio y firmar un cheque a ciegas.

La mayoría de los proyectos de IA que salen mal en las empresas no fallan por mala tecnología. Fallan porque nadie se sentó media hora a pensar qué pasa cuando el sistema se equivoca. Un análisis de riesgos no frena la innovación: es lo que te deja aprobar el proyecto sabiendo dónde están los cables pelados. Y es aburrido a propósito. Cinco columnas que puedes rellenar en la próxima reunión de comité.

Por qué la IA necesita su propio análisis de riesgos

Un sistema de IA generativa puede darte respuestas distintas ante la misma pregunta, y puede inventarse una con total aplomo. Ahí está la diferencia con el software de toda la vida.

Cuando compras una herramienta de facturación, sabes lo que hace. Metes los mismos datos y sale siempre el mismo resultado. Es predecible, y por eso el riesgo es fácil de entender. La IA generativa (los sistemas tipo ChatGPT que redactan texto, resumen documentos o atienden a un cliente) funciona distinto. Genera cada respuesta sobre la marcha, y de vez en cuando produce algo que suena perfectamente razonable pero es falso. En el sector se le llama alucinación: el sistema afirma un dato inventado sin ninguna señal de que se lo está inventando.

Para un directivo la consecuencia práctica es simple. No basta con preguntar “¿funciona?”. Hay que preguntar “¿qué pasa las veces que no funciona, y quién se come el marrón?”. Ese cambio de pregunta es el motivo de que la IA merezca su propia tabla de riesgos y no la de un software cualquiera. Si quieres el marco completo de por qué la IA obliga a decidir distinto, lo desarrollo en la guía de riesgos de IA para empresas.

Pasos 1 y 2: qué puede fallar y a quién le duele

El primer paso es listar, en lenguaje llano, todo lo que puede salir mal. El segundo es decir a qué parte del negocio le duele cada cosa. Sin tecnicismos.

Estos son los fallos que aparecen casi siempre cuando la IA toca a un cliente o a un dato:

• Respuesta inventada a un cliente. El asistente promete un reembolso que no existe o da una condición legal que la empresa no ofrece.
• Filtración de un dato personal. Alguien pega en el sistema el DNI o el historial médico de un cliente y ese dato acaba donde no debe.
• Decisión sesgada. El sistema, entrenado con datos del pasado, descarta candidatos o clientes siguiendo un patrón injusto.
• Dependencia de un proveedor. Todo tu proceso depende de un servicio externo que puede subir el precio, cambiar las reglas o cerrar.
• Coste que se dispara. El piloto era barato, pero a volumen real la factura mensual se multiplica.

El impacto se mide en cuatro monedas que cualquier directivo entiende: dinero (una multa, una venta perdida, una factura descontrolada), reputación (un cliente indignado que lo cuenta en redes), legal (una infracción de protección de datos) y personas (una decisión que perjudica a alguien de forma injusta). Al lado de cada fallo, apunta cuál de esas cuatro toca y cómo de fuerte.

Paso 3: cómo de probable es

No necesitas un número exacto de probabilidad. Una escala de baja, media o alta, acordada en la reunión, es suficiente para decidir. Lo importante no es la precisión, es cruzar dos cosas.

Un riesgo con impacto enorme pero casi imposible (un meteorito) no merece que pares el proyecto. Un riesgo pequeño pero constante (el sistema se equivoca en una de cada diez respuestas rutinarias) tampoco se gestiona igual que uno grande y raro. La prioridad sale de multiplicar impacto por probabilidad: lo que es grave y frecuente va primero.

Esa combinación se ve mejor en una cuadrícula que en una lista.

Si quieres la herramienta visual completa para ordenar los riesgos por prioridad, la tienes en la matriz de riesgo e impacto de IA. Aquí me quedo con la idea de fondo: no todos los riesgos se atienden, se atienden los que caen en la esquina grave y probable.

Paso 4: mitigación, o qué haces para que no pase

Mitigar es reducir la probabilidad de que el fallo ocurra o el daño que causa si ocurre. Para cada riesgo de la esquina peligrosa, apunta una acción concreta, no una intención.

Las mitigaciones que funcionan en la mayoría de proyectos de IA son poco glamurosas:

• Revisión humana antes de actuar. El sistema propone la respuesta, pero una persona la aprueba antes de que salga al cliente. Lento, sí, pero corta las alucinaciones de raíz en lo importante.
• No meter datos personales en el sistema. Si el proveedor no te garantiza por contrato dónde se guardan y qué se hace con ellos, esos datos no entran. Punto.
• Empezar con un piloto pequeño. Un departamento, un tipo de consulta, un mes. Así el coste real y los fallos aparecen cuando aún son baratos de corregir.
• Tener un plan B manual. Si el sistema falla o el proveedor cae, el proceso puede seguir a mano. Nunca dejes que la IA sea el único camino para algo crítico.

Este es el criterio que de verdad separa un proyecto de IA sensato de uno temerario, y es lo que trabajamos con casos reales en el curso de IA sin hype: no la tecnología, sino cómo decidir qué riesgo aceptas y cuál no.

Paso 5: el responsable, el paso que todos se saltan

Cada riesgo necesita el nombre de una persona al lado. No un departamento, una persona. Este es el paso que casi nadie rellena y el que más problemas evita.

“La IA” no es responsable de nada. Un sistema no puede responder ante un cliente, ante un juez ni ante tu comité. Siempre hay alguien que responde, y si no lo decides antes, lo decidirá el caos el día del incidente. Por eso la última columna es un nombre: quién vigila que ese riesgo esté controlado y a quién llamas cuando salta.

Aquí entra la parte legal, y conviene tratarla con respeto. En la Unión Europea hay dos normas que casi siempre aparecen. El RGPD (el reglamento de protección de datos) regula cómo tratas los datos personales de tus clientes y empleados. Y el Reglamento Europeo de Inteligencia Artificial (conocido como AI Act, en vigor desde 2024 y aplicándose por fases) clasifica los sistemas de IA según su nivel de riesgo y exige más controles cuanto más sensible es el uso. No necesitas saberte los artículos. Necesitas saber que existen y que la responsabilidad de cumplirlas es tuya, no del proveedor. Esto no es asesoramiento jurídico: para un caso concreto, habla con un abogado especializado.

La tabla completa, de una

Así se ve el método aplicado a un caso. Imagina una pyme que quiere poner un asistente de IA para atender dudas de clientes por chat. Las cifras y nombres son ilustrativos.

Qué puede fallar	Impacto	Probabilidad	Mitigación	Responsable
El asistente promete un reembolso inexistente	Legal y reputación, alto	Media	Respuestas sobre reembolsos siempre revisadas por una persona	Responsable de Atención al Cliente
Un cliente pega datos personales en el chat	Legal (RGPD), alto	Alta	Aviso visible y borrado automático de esos mensajes; contrato claro con el proveedor	Responsable de Protección de Datos
El coste mensual se dispara con el volumen real	Dinero, medio	Media	Piloto de un mes con límite de gasto antes de abrir a todos	Dirección Financiera
El proveedor cambia condiciones o cae	Operativo, medio	Baja	Plan B: el equipo humano puede atender el chat a mano	Responsable de Operaciones

Cuatro filas, media hora de reunión, y de repente el proyecto deja de ser un salto de fe. Ves qué aceptas, qué corriges antes de empezar y a quién llamas cuando algo salte. Si además quieres el filtro rápido de “¿esto siquiera merece IA?” antes de montar la tabla, empieza por las cuatro preguntas antes de usar IA.

Una tabla así no garantiza que nada salga mal. Garantiza que, si sale mal, sabías que podía pasar, decidiste asumirlo y pusiste a alguien a vigilarlo. Eso es gestionar un riesgo en lugar de sufrirlo.

Un concepto nuevo cada semana

Suscribirme

Checklist antes de aprobar el proyecto

• Tienes la lista de qué puede fallar en lenguaje de negocio, sin tecnicismos
• Cada fallo tiene marcado su impacto (dinero, reputación, legal o personas)
• Cada fallo tiene una probabilidad acordada (baja, media o alta)
• Los riesgos graves y probables tienen una mitigación concreta, no una intención
• Cada riesgo tiene el nombre de una persona responsable, no un departamento
• Has comprobado si el proyecto toca datos personales (RGPD) o un uso sensible (AI Act)
• Existe un plan B manual para lo que sea crítico

Preguntas frecuentes

¿Qué es exactamente un análisis de riesgos de IA?

Es el ejercicio de listar, antes de aprobar un proyecto de IA, todo lo que puede salir mal, valorar su impacto y su probabilidad, decidir cómo lo evitas y asignar un responsable a cada riesgo. En la práctica cabe en una tabla de cinco columnas que rellenas en una reunión. Su objetivo no es bloquear la IA, sino aprobarla sabiendo qué asumes.

¿Cuál es el riesgo específico de la IA generativa frente a otro software?

Que no es predecible del todo. Un software normal da siempre la misma respuesta ante los mismos datos, mientras que la IA generativa genera cada respuesta sobre la marcha y a veces produce información falsa con apariencia de certeza. Por eso el análisis de riesgos de IA se centra tanto en qué pasa cuando el sistema se equivoca y quién lo revisa.

¿Necesito conocimientos técnicos para hacer este análisis?

No. El análisis se hace en lenguaje de negocio: impacto, probabilidad, responsable. Lo único técnico que conviene tener cerca es a alguien que te explique, en una frase, qué hace el sistema y con qué datos trabaja. El resto son preguntas de gestión de toda la vida aplicadas a una herramienta nueva.

¿Quién es el responsable si la IA comete un error?

Siempre una persona de tu organización, nunca “la IA” ni, por defecto, el proveedor. El sistema no responde ante un cliente ni ante un juez, así que la responsabilidad de vigilar cada riesgo y de cumplir la normativa (RGPD, AI Act) recae en quien aprueba y opera el proyecto. Por eso la última columna de la tabla lleva un nombre concreto. Para el detalle legal de tu caso, consulta con un abogado.