MIT Technology Review advierte: confiamos demasiado en las negativas de los modelos de IA

En la edición del 9 de octubre de su boletín The Download, MIT Technology Review sitúa en primer plano una tesis que muchos en la industria dan por axioma: confiamos demasiado en la capacidad de la IA para decir «no». Los modelos actuales están entrenados para rechazar un gran número de peticiones. Si le preguntas a un chatbot cómo envenenar a una persona, lo más probable es que se niegue. La publicación sostiene que la industria deposita demasiadas esperanzas precisamente en esa negativa. El segundo tema de la edición trata sobre los efectos secundarios de los fármacos para adelgazar y no guarda relación con la IA.

Una salvedad importante: el avance contiene solo el planteamiento inicial del argumento, sin datos ni nombres. La postura completa de los autores conviene leerla en el original. A continuación analizamos cómo funcionan técnicamente las negativas y dónde están sus puntos débiles.

Cómo aprenden los modelos a decir «no»

La negativa no viene integrada de origen en un LLM. El modelo base se limita a continuar el texto y describirá con la misma disposición la receta de una tarta y un procedimiento peligroso. El comportamiento de «no puedo ayudarte con esto» aparece después, en las etapas de ajuste: personas y otros modelos evalúan las respuestas, y el sistema aprende a elegir las que se consideran seguras. Encima se añaden prompts de sistema y filtros externos que revisan la petición a la entrada y la respuesta a la salida.

El resultado parece una frontera, pero en realidad es una tendencia estadística. El modelo no «entiende» que una petición es peligrosa: reconoce patrones familiares de peticiones peligrosas.

Dónde falla la negativa

Este tipo de protección tiene tres puntos débiles conocidos.

• Elusión mediante la formulación. Los escenarios de juego de rol, la paráfrasis, el cambio de idioma y la división de una tarea peligrosa en pasos inocuos llevan años siendo técnicas de jailbreak que funcionan.
• Intención desconocida. Sobre venenos pregunta un toxicólogo, un autor de novela negra, un estudiante y un malintencionado. Por el texto de la petición no se les puede distinguir, así que el sistema se ve obligado a elegir entre negativas innecesarias y fallos de detección.
• El coste del error en ambos sentidos. Un modelo demasiado estricto deja de ser útil para médicos, investigadores de seguridad y periodistas. Uno demasiado laxo entrega lo que no debería entregar.

Con los agentes aparece un problema aparte. Cuando el modelo tiene acceso al navegador, al correo, al código y a herramientas de pago, una negativa educada en el chat no garantiza nada. Una acción peligrosa puede construirse a partir de una serie de pasos, cada uno de los cuales, por separado, parece inocente.

De qué se compone la protección en la práctica

Si no se apoya todo en la negativa como única barrera, el cuadro resultante tiene varias capas:

• entrenamiento con ejemplos de negativas y con preferencias humanas;
• instrucciones de sistema del operador que describen lo permitido y lo no permitido;
• clasificadores independientes del modelo principal, a la entrada y a la salida;
• red teaming: intentos deliberados de vulnerar el sistema antes del lanzamiento y después;
• limitación de los permisos del agente a nivel de infraestructura, no de prompt.

El último punto es el más infravalorado. Los permisos de acceso, los límites y la confirmación humana de las acciones críticas funcionan con independencia de lo que el modelo haya «decidido».

Qué deben hacer los equipos que despliegan modelos

Primero: no consideren la negativa un control de seguridad. Es un ajuste de comportamiento y hay que verificarlo como cualquier otro, de forma periódica y con cada nueva versión del modelo.

Segundo: prueben sus propios escenarios, no solo los benchmarks generales. Las peticiones peligrosas en su ámbito pueden tener un aspecto muy distinto del que presentan en los conjuntos públicos.

Tercero: para los agentes, diseñen permisos mínimos y registro de acciones. Si el modelo se equivoca o lo engañan, el daño debe topar con un límite técnico.

Cuarto: midan ambos lados del error. La proporción de peticiones peligrosas que se cuelan y la de falsas negativas en tareas legítimas dicen más sobre la calidad del sistema que cualquier indicador aislado.