Seguridad de IA: el mapa completo, y dónde cae la interpretabilidad

Esta página es el mapa que me hubiera servido cuando entré al campo por una sola puerta. La interpretabilidad es una pieza de algo bastante más grande, y conviene ver el tablero entero antes de elegir en qué trabajar. Cada afirmación va con una referencia que podés ir a chequear.

Seis preguntas distintas, no seis nombres para lo mismo

"Seguridad de IA" se usa para cosas que no se parecen entre sí. Ayuda separarlas por la pregunta que cada una intenta responder:

pilar	la pregunta
Alineamiento	¿El sistema persigue lo que queríamos, o algo que se le parece en el entrenamiento?
Evaluaciones	¿De qué es capaz este modelo, y cómo lo medimos antes de desplegarlo?
Interpretabilidad	¿Qué está haciendo por dentro cuando responde?
Control	Si resultara no estar alineado, ¿el sistema alrededor lo contiene igual?
Gobernanza	¿Quién decide qué se despliega, con qué umbral y quién responde?
Seguridad de sistemas	¿Quién puede robar los pesos, envenenar los datos o usar el modelo como palanca de ataque?

El alineamiento es el problema viejo y el más difícil de enunciar bien: un sistema optimiza lo que medís, no lo que querías, y la brecha entre las dos cosas crece con la capacidad. La formulación que sigue siendo la mejor puerta de entrada tiene diez años y envejeció asombrosamente bien: Concrete Problems in AI Safety.

Las evaluaciones son la pata que más creció, porque es la que las empresas y los reguladores necesitan para decidir. Medir capacidades peligrosas de manera reproducible es un problema técnico en sí mismo — Evaluating Frontier Models for Dangerous Capabilities es el trabajo que fijó buena parte del formato — y hoy tenés herramientas abiertas para hacerlo: Inspect, del instituto británico de seguridad de IA, y el trabajo de METR sobre tareas autónomas largas.

El control parte de una premisa incómoda y muy productiva: suponé que el modelo sí está desalineado y que además lo sabe. ¿Podés diseñar el andamiaje — monitores, permisos, revisión — para que igual no logre hacer daño? Es una agenda distinta de la de alineamiento, porque no depende de resolverlo primero. El paper que la definió es AI Control: Improving Safety Despite Intentional Subversion.

La gobernanza es dónde eso se vuelve obligación: el marco de gestión de riesgos del NIST, el reglamento europeo de IA, y las políticas de escalamiento que los laboratorios se autoimponen y publican, como la de Anthropic. La seguridad de sistemas, en cambio, es el problema clásico de siempre con un objeto nuevo: proteger pesos que cuestan cientos de millones y entender el riesgo cibernético que el propio modelo introduce — el Frontier Model Forum publica sobre esto último.

Lo que un test no te puede decir

Los seis pilares se necesitan, pero entre dos de ellos hay una dependencia que es, en el fondo, lo que justifica que exista este sitio.

Una evaluación mide comportamiento: le das mil situaciones al modelo y contás en cuántas se portó bien. Es indispensable y tiene un techo conocido — un sistema que se porta bien mientras lo mirás no es lo mismo que un sistema seguro, y esa diferencia no se cierra agregando casos de test. El caso mejor documentado hoy es el de los modelos que "razonan en voz alta": hay evidencia de que la cadena de texto no siempre refleja el cómputo que produjo la respuesta. Si el razonamiento visible puede desacoplarse del real, leerlo no alcanza como monitoreo.

La interpretabilidad es el único pilar que promete evidencia sobre el mecanismo. No "pasó el test" sino "sé por qué lo pasa, y sé qué tendría que cambiar adentro para que dejara de pasarlo". Es también el pilar más inmaduro de los seis: hoy explicamos fragmentos, en modelos medianos, y la lista de problemas abiertos es más larga que la de resueltos. Mi página de líneas entra en detalle.

Energía, minería, infraestructura crítica

Vengo de dieciocho años en energía, y creo que ahí esta discusión va a llegar tarde y de golpe. Tres razones, en orden de qué tan comprobable es cada una hoy.

La primera ya está medida. El uso no autorizado de modelos frontera dentro de organizaciones de infraestructura crítica — shadow AI — es un hecho documentado, no una proyección: hay un estudio empírico sobre 27 organizaciones australianas de los sectores de comunicaciones, energía y agua que lo caracteriza como erosión sistemática de los mecanismos de aseguramiento. La gente ya está usando estas herramientas para decisiones que importan, por fuera de los controles.

La segunda es una extrapolación razonable: los agentes van a pasar de asesorar a actuar. Un modelo que hoy sugiere un setpoint y mañana lo escribe cambia la naturaleza del riesgo, porque el error deja de tener a una persona en el medio.

La tercera es la más vieja de todas y no tiene nada de IA: el sesgo de automatización. Un ingeniero que recibe una recomendación confiada y equivocada, en una decisión de alta consecuencia, tiende a deferir. Eso ya pasaba con simuladores.

Lo que no puedo afirmar

Nada de lo que investigo hoy se aplica a una decisión de operación. Mis experimentos separan "Italia" de "capital-de" en el estado interno de un modelo de 1.7B parámetros, en inglés, sobre relaciones factuales de juguete. Entre eso y auditar a un agente con autoridad sobre un ducto hay un salto que no pienso disimular: no tengo evidencia de que la estructura que encontré exista en tareas con consecuencias físicas, ni de que sirva para detectar un error antes de que ocurra.

Lo digo acá porque el error típico en esta intersección es vender el puente antes de construirlo. Prefiero enunciar los escalones.

Los escalones, en orden

Cada uno depende del anterior y ninguno está subido todavía.

1. Diagnóstico causal de errores. Cuando un modelo se equivoca, distinguir si confundió la cosa, eligió la operación equivocada, o falló al ligar una con otra. Mi paper muestra que esas piezas existen y son manipulables por separado en recuperación factual; falta mostrar que el diagnóstico funciona cuando no sabés de antemano cuál era la respuesta correcta.
2. Leer la intención antes del acto. Detectar qué operación está intentando ejecutar el modelo, no cuál ejecutó. Con su contrapunto honesto, que va junto y no aparte: una dirección que podés monitorear es una dirección que alguien más puede manipular. La interpretabilidad tiene un costado ofensivo inevitable.
3. Salir del dominio de juguete. Relaciones factuales sobre países y animales tienen la virtud de que la respuesta correcta es inequívoca. Una tarea de ingeniería no. Ese salto es un proyecto entero, no un corolario.
4. Evaluaciones con anclaje de dominio. Recién acá aparece lo que la industria podría usar: escenarios realistas con criterio de seguro/inseguro, corridos sobre modelos frontera. Es la pata de evaluaciones del mapa de arriba, aplicada a un sector donde los benchmarks genéricos no capturan la semántica del proceso.

Los dos primeros escalones salen directamente de las líneas que abrió mi paper. Los otros dos, por ahora, son una intención.

Por dónde seguir

Si querés entrar al campo, el curso y los recursos son la ruta corta. Si ya estás adentro y buscás problema, las líneas abiertas tienen diez, cada una con una referencia al estado del arte y versiones a escala de una persona con una GPU.