Cuando un sistema de inteligencia artificial se despliega, sus reglas y controles se diseñan bajo ciertos supuestos. Pero esos supuestos no son estáticos: el modelo evoluciona, los datos crecen y los usuarios encuentran usos que nadie anticipó. Entender dónde se mueven esos supuestos y cómo responder es la diferencia entre un sistema confiable y uno que genera daño sin que nadie lo note.
La analogía es clara: los límites de velocidad en una autopista se definieron pensando en ciertos autos, frenos y pavimento. Si ahora circulan vehículos autónomos con mejores sensores, la regla no cambió, pero el contexto sí, y eso puede volver la regla insuficiente o incluso peligrosa [0:12]. Con los sistemas de IA pasa exactamente lo mismo.
¿Cuáles son los tres supuestos que se mueven sin aviso?
Existen tres tipos de supuestos que cambian silenciosamente y que todo equipo debería monitorear de forma activa.
¿Cómo afecta 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 puede dar recomendaciones mucho más específicas y convincentes, aunque el diseño original sea el mismo [0:35]. Las señales de alerta incluyen:
- Respuestas que antes eran consistentes y ahora no lo son.
- El modelo rechaza cosas que antes hacía o hace cosas que antes rechazaba.
- Sube la tasa de alucinaciones [0:49].
¿Qué riesgos trae el acceso a nuevos datos?
Cada nueva fuente de datos es una nueva puerta. Un hospital que suma datos de un reloj inteligente ahora tiene frecuencia cardíaca y sueño mezclados con historia clínica. Dos datasets inofensivos por separado se vuelven sensibles juntos [1:03]. Otro ejemplo: una tarjeta de supermercado, datos de farmacia y una aseguradora. El resultado es que se pueden inferir enfermedades y ajustar precios. Cada paso parecía pequeño, pero el efecto combinado no lo fue.
¿Por qué los casos de uso no previstos son tan peligrosos?
Un chatbot de recursos humanos que empieza a redactar documentos legales o un modelo de crédito que se usa para filtrar candidatos laborales son ejemplos de misma herramienta, distinto impacto [1:27]. Y lo más importante: ninguno de estos cambios requiere tocar código.
¿Cómo clasificar dónde está el problema?
Antes de corregir, hay que localizar. La clasificación se divide en tres niveles: riesgo de modelo, riesgo de producto y riesgo de proceso [1:42].
- Si el modelo responde distinto, el problema está en el modelo: auditas versiones.
- Si responde igual pero la decisión cambia, el problema está en el producto: revisas lógica y métricas.
- Si cambian los datos, el problema está en el proceso: auditas el pipeline de datos [1:58].
La herramienta clave es un log de decisiones. Cada output debería registrar versión del modelo, datos usados y decisión final. Sin eso, estás adivinando [2:10].
Para detectar usos no previstos, hay que prestar atención a consultas fuera del diseño original, usuarios fuera del público objetivo, picos raros de uso o quejas inesperadas [2:20]. Al detectar algo nuevo, un checklist rápido ayuda: ¿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, detené su uso [2:40].
¿Cómo construir controles operativos reales?
La plantilla de revisión de escenarios tiene cinco campos: supuesto cambiado, riesgo, daño, control y responsable [2:55]. La brecha de control es la distancia entre el riesgo y lo que realmente se está controlando. Bloquear la palabra "salario" no bloquea "cuánto gana María" [3:08]. Para evaluar esa brecha: define qué puede salir mal, qué hace realmente el control y qué tan lejos está de cubrir el problema. Probalo bajo estrés, eso es red teaming: si podés romper el sistema, la brecha es real [3:22].
El resultado no es un informe, es un backlog. Cada ítem tiene ID, control, brecha, dueño, fecha, dependencias y estado [3:32]. Un control medible tiene número: no es "parece seguro", sino "97 de 100 bloqueos fueron efectivos" [3:52]. Ejemplos de métricas útiles:
- Prompts dañinos detectados.
- Rechazos activos.
- Violaciones de acceso.
- Acciones confirmadas por humanos [4:00].
Sin números no hay auditoría real. Un caso concreto: un asistente de atención al cliente que al principio respondía preguntas simples y ahora recibe solicitudes de recomendaciones financieras, respondiendo sin que nadie haya cambiado el modelo ni el código [4:12]. Las preguntas que surgen son exactamente las de este marco: ¿qué supuesto cambió? ¿Dónde está el riesgo? ¿Qué control implementarías primero?
Dejá tu análisis o un caso real donde te haya pasado algo parecido en los comentarios.
