Cómo detectar riesgos ocultos en sistemas de IA

Los supuestos ocultos en sistemas de IA cambian sin que muevas una sola línea de código, y ahí nace el riesgo real. Si trabajas con modelos de inteligencia artificial en producción, entender cómo detectar y auditar estos cambios te protege de daños que parecen pequeños hasta que se combinan.

Piensa en los límites de velocidad de una autopista. Se definieron pensando en autos, frenos, pavimento y comportamiento humano. Ahora metes autos autónomos, mejores sensores y mejores frenos. La regla no cambió, pero el contexto sí. Y esa regla puede volverse insuficiente o incluso peligrosa. Con los sistemas de IA pasa exactamente lo mismo: el contexto se mueve mientras la regla se queda quieta [00:14].

Qué supuestos se mueven en un sistema de IA sin avisar

Hay tres tipos de supuestos que cambian sin que te des cuenta, y ninguno requiere tocar código [02:39].

El primero es el comportamiento del modelo. Un sistema que en 2025 respondía preguntas básicas de salud tenía límites claros. Un modelo más capaz hoy puede dar recomendaciones mucho más específicas y convincentes, aunque el diseño original sea el mismo. Eso cambia el impacto [00:44]. Las señales de alerta son claras: respuestas que antes eran consistentes ahora no lo son, el modelo rechaza cosas que antes hacía, hace cosas que antes rechazaba o incluso sube la tasa de alucinaciones [01:15].

El segundo es el acceso a datos. Cada nueva fuente es una nueva puerta. Un hospital suma datos de un reloj inteligente y de repente mezcla frecuencia cardíaca y sueño con historia clínica. Dos datos inofensivos por separado se vuelven sensibles juntos [01:35]. Piensa en una tarjeta de supermercado, luego datos de farmacia, luego aseguradora: se pueden inferir enfermedades y ajustar precios. Cada paso parecía chico, pero el efecto combinado no lo fue [01:55].

¿Por qué dos datos inofensivos se vuelven peligrosos juntos? Porque su combinación permite inferir información sensible que ninguno revelaba por separado. Frecuencia cardíaca más historia clínica, o farmacia más aseguradora, permiten deducir enfermedades y ajustar precios.

El tercero son los casos de uso. Un chatbot de recursos humanos empieza a redactar documentos legales. Un modelo de crédito se usa para filtrar candidatos laborales. Misma herramienta, distinto impacto [02:14].

Cómo saber si el problema es del modelo, del producto o del proceso

Antes de salir a arreglar algo, necesitas saber dónde está el problema [02:44]. Aquí distingues tres tipos de riesgo.

• Si el modelo responde distinto, es un problema en el modelo.
• Si responde igual pero la decisión cambia, es un problema en el producto.
• Si cambian los datos, es un problema en el proceso.

Esto importa porque la solución cambia según el origen. Si es el modelo, auditas versiones. Si es el producto, revisas lógica y métricas. Si es el proceso, auditas el pipeline de datos [03:14].

¿Qué es un log de decisiones en IA? Es un registro donde cada output guarda la versión del modelo, los datos usados y la decisión final. Sin él, estás adivinando el origen de cualquier problema.

El log de decisiones es la herramienta clave. Cada output debería registrar versión del modelo, datos usados y decisión final [03:26].

Cómo detectar usos no previstos y aplicar el checklist de riesgo

Para detectar usos que nadie planeó, presta atención a consultas fuera del diseño original, usuarios fuera del público objetivo, picos raros de uso o quejas inesperadas [03:45]. Agrupa las consultas y revísalas mensualmente.

Cuando detectes algo nuevo, corre este checklist [04:04]:

• ¿Quién es afectado?
• ¿Qué decisión impacta?
• ¿Hay un humano en el loop?
• ¿Hay datos sensibles?
• ¿Puede discriminar?

Si más de dos preguntas no tienen respuesta clara, detén su uso. Esa es la regla dura para no seguir operando a ciegas [04:14].

Cómo estructurar la revisión con plantillas y controles medibles

Para que esto sea repetible, necesitas una estructura fija. La plantilla de revisión de escenarios tiene cinco campos: supuesto cambiado, riesgo, daño, control y responsable [04:23].

Aquí aparece la brecha de control, que es la distancia entre el riesgo y lo que realmente estás controlando. Bloquear la palabra salario no bloquea cuanto gana Maria [04:40]. Para medir esa brecha, sigue tres pasos: que puede salir mal, que hace realmente el control y que tan lejos esta de cubrir el problema. Luego pruébalo bajo estrés, eso es red teaming, y si puedes romper el sistema, la brecha es real [05:00].

El resultado de todo esto no es un informe, es un backlog. Cada ítem tiene ID, control, brecha, dueño, fecha, dependencias y estado [05:16]. Ana, en Colombia, trabaja en un modelo de contratación y detecta posible sesgo por código postal. El ítem se define como auditoría de equidad, el dueño es el equipo de datos, con fecha definida y una limpieza previa como dependencia [05:24].

¿Qué hace que un control de IA sea auditable? Que tenga números. No basta con "parece seguro": necesitas datos como "97 de 100 bloqueos fueron efectivos". Sin números no hay auditoría real.

Un control medible tiene número. Ejemplos concretos: prompts dañinos detectados, rechazos activos, violaciones de acceso y acciones confirmadas por humanos [05:47].

Cómo aplicar todo esto a un caso real de atención al cliente

Sofía, en El Salvador, trabaja con un asistente de atención al cliente. Al principio respondía preguntas simples, pero ahora los usuarios le piden recomendaciones financieras y el sistema responde. Nadie cambió el modelo, nadie cambió el código [06:03].

Las preguntas para practicar son directas: que supuesto cambio, donde esta el riesgo entre modelo, producto o proceso, y que control implementarias primero [06:23]. Este es justo el tipo de escenario donde el caso de uso se mueve sin tocar nada del sistema.

¿Te ha pasado algo parecido con un modelo que empezó a usarse para algo que no estaba previsto? Déjame tu análisis o tu caso real en los comentarios.