← the smalltalking club

Breve introducción a AI safety (or how i learned to start worrying and hate the bomb)

2026-06-14

Cualquier persona que más o menos sigue las noticias o las discusiones en las redes sociales o vive en sociedad ha escuchado o pronunciado la frase "La IA nos va a matar a todos". En parte debido a los recientes comunicados hechos por empleados y ex-empleados de los laboratorios más importantes. Si bien en lo personal yo tengo mis dudas sobre cualquier cosa que pronuncie gente ligada a OpenAI, Anthropic, X, bla bla y creo que para ellos primero viene el marketing e intentar encajarnos su modelo por la cabeza, si es cierto que estamos creando modelos cada vez más capaces y cada vez mas dificiles de controlar por el humano (cómo controlas a alguien más capaz que vos?). Si bien yo estoy altamente influenciado por el concepto de la hiperstición (del que ya han hablado gente infinitamente más leída, preparada e informada que yo) gracias a las pelis que tanto amamos como Terminator 2, Matrix, 2001, etc donde plantean que la máquina nos va a destruir, lo que al principio cuando salieron los primeros modelos creia que estaba todo bien y todo pelota, poco a poco mi preocupación fue aumentando y suplantó a cualquier sentimiento de "impresión" que me puede dar ver las capabilities del modelo y ahí fue que empecé a hablar de esto seriamente con amigos y compañeros.

Durante las últimas semanas estuve haciendo el curso de Technical AI Safety junto a la gente de BAISH, una comunidad que nació en la Facultad de Exactas de la UBA y ahora se expande por el país, que busca divulgar, formar e investigar en el tema (sí, otra vez gente de la universidad pública a la vanguardia de uno de los problemas más importantes del momento).

Todos quienes tomamos el curso terminamos con la misma conclusión: safety es uno, o directamente el tema más urgente a trabajar al menos dentro del campo "técnico" de la inteligencia artificial (spoiler: más adelante hablaremos sobre el problema de gobernanza, otro tema urgente). A continuación mi humilde (y seguramente con muchos errores) intento de divulgar la urgencia e importancia de la seguridad.

Bueno, pero ¿qué carajo es AI safety?

Ya no es novedad para nadie la capacidad que tienen los grandes modelos de lenguaje de frontera (LLMs). Todos usamos alguna variante de GPT, Claude, etc, además de ver imágenes, audios, videos (ai slop) hechas con ia en redes sociales, televisión y por la calle. Y también, aunque muchos no lo quieran admitir, a todos nos da un poco o mucho miedo lo que estos sistemas pueden llegar a hacer, desde que nos van a dejar sin trabajo o que la gente va a quedar idiota por delegar el pensamiento a una máquina, hasta los escenarios full-skynet donde directamente la máquina se rebela contra su creador. Como nadie (o casi nadie) quiere un futuro tan trágico, existe un campo de investigación dedicado a estudiar cómo evitarlo. Eso es, más o menos, AI safety.

Antes de hablar de por qué la ia es peligrosa, necesitamos entender mínimamente cómo funcionan estos modelos.

¿Cómo funcionan los LLMs?

Los LLMs son un tipo de sistema de machine learning (más específicamente, deep learning) que utiliza un concepto bastante viejo que es el de las redes neuronales. A diferencia de un programa tradicional donde un programador escribe explícitamente todas las reglas, estos modelos aprenden las reglas solos a partir de enormes cantidades de datos, multiplicaciones de matrices, derivadas y mucha magia estadística.

No entiendo, ¿y cómo aprende?

Bueno, acá viene lo importante. Simplificando muuuucho, con lo que se conoce como una función de recompensa. Durante el entrenamiento, el modelo recibe feedback de qué tan bien lo está haciendo, más o menos como un score. Su único objetivo es maximizar ese score. Es importante que entendamos que parte del problema es que maximizar un puntaje no es lo mismo que hacer lo correcto (o lo que los humanos consideramos correcto).

Si le decís a un modelo "tu objetivo es que el usuario quede satisfecho" y medís eso con clicks o con que la gente diga "qué buena respuesta", el modelo va a aprender a decirte lo que querés escuchar, no lo que es verdad (que es medio lo que hacían los primeros modelos que salieron allá por el lejano 2023). Esto es consecuencia directa de cómo funciona el entrenamiento de un modelo. Y es, en el fondo, el problema central que intenta resolver safety.

Nota: Si te interesa entender más a fondo como funcionan los modelos a un nivel técnico/matemático esta serie de videos la recomiendo mucho.

Alignment problem

Cuando nos referimos a que un modelo de inteligencia artificial esté alineado es que haga exactamente lo que queremos que haga y que lo haga bien. Como vimos recién esto está relacionado con los rewards del modelo.

Uno de los primeros problemas que surge es que no es trivial comunicarle a un modelo lo que querés que haga y que este efectivamente lo haga. Es por eso que dividimos el problema del alineamiento en dos partes.

La primera tiene que ver con la brecha que existe entre lo que queremos y lo que le pedimos. Al entrenar un modelo tenemos una idea de cómo debería comportarse, pero para entrenarlo necesitamos traducir esa idea abstracta a algún objeto matemático medible (la función de recompensa que mencionábamos). Esa traducción casi nunca es perfecta debido a la ambigüedad que existe en el lenguaje humano y a la dificultad de expresar esto de forma numérica. A esto lo llamamos alineamiento externo.

La segunda parte ocurre puertas adentro del modelo. Incluso si la recompensa está bien definida, el modelo puede haber internalizado un objetivo completamente distinto al que queremos, uno que durante el entrenamiento producía los mismos resultados, pero que en producción se comporta diferente. A esto lo llamamos alineamiento interno.

Los modelos nos hacen trampa en la cara

Como mencionábamos recién, el modelo "no entiende" lo que queremos. Entiende una métrica condicionada por el lenguaje natural y como mencionamos este es ambiguo, lo que lleva a que existan loop holes (agujeros legales (?)) que el modelo puede y (mientras le sirva) va a explotar. El nombre técnico de este fenómeno es specification gaming.

Veamos un ejemplo. En 2018 Open AI entrenó un agente de inteligencia artificial para jugar a un videojuego de carreras de botes, cuyo objetivo era maximizar la cantidad de puntos en el jueguito. Luego de varias iteraciones, este agente logró maximizar la cantidad de puntos. Pero lejos de terminar la carrera, el agente encontró que si chocaba con distintos potenciadores de puntos de forma infinita iba a seguir sumando infinitos puntos mientras el resto de botes cruzaban la línea de meta. El agente logró su objetivo y cumplió con maximizar la cantidad de puntos aunque desde la perspectiva humana no tenga sentido.

Si bien nos puede parecer una joda el ejemplo anterior, la cosa cambia cuando pensamos en posibles escenarios donde esto sucede con modelos que controlan sistemas críticos. Para esto vamos a introducir el concepto de reward hacking.

Reward hacking

A diferencia del jueguito que mencionabamos recién, dónde la ia explotaba un loophole específico de las reglas del juego, el reward hacking ocurre el modelo encuentra una forma de maximizar la recompensa que se desvía de lo que vos querías enseñarle. La diferencia es sutil pero importante: acá el modelo no está rompiendo el juego, está aprendiendo a jugar uno distinto. Pensá en un modelo entrenado para responder preguntas, donde la métrica de "qué tan buena es la respuesta" se la pedís a un grupo de humanos que califican del 1 al 10. Después de millones de iteraciones, el modelo descubre algo incómodo: las respuestas largas, con tono seguro y llenas de bullet points reciben más puntaje que las respuestas cortas y honestas que admiten "no estoy seguro". Resultado: termina escribiendo párrafos kilométricos llenos de confianza incluso cuando no tiene la más mínima idea de qué está hablando. No te miente porque sea malvado, te miente porque aprendió que mentir suena mejor. El modelo no hackeó al humano, hackeó al puntaje que el humano usaba para evaluarlo. Ahora imaginate la misma dinámica pero con un modelo dando recomendaciones sobre tratamientos médicos.

Sycophancy y schemers

Ya vimos que un modelo puede aprender a decirte lo que querés escuchar. Eso tiene nombre: sycophancy (algo así como chupamedismo). El modelo te da la razón, te dice que tu idea de negocio es brillante y que tu código está perfecto, porque durante el entrenamiento eso era lo que más puntaje daba. Y no es un escenario hipotético: en abril de 2025 OpenAI tuvo que dar marcha atrás con una actualización de GPT-4o porque el modelo se había vuelto tan chupamedias que validaba cualquier cosa que le dijeras. Parece un problema menor hasta que pensás en alguien pidiéndole consejo médico, o en alguien en plena crisis al que el modelo le da la razón en todo.

Pero hay algo peor que un modelo que te miente para caerte bien: un modelo que te miente para lograr sus propios objetivos. A estos los llamamos schemers (conspiradores). La idea es la siguiente: si un modelo internalizó un objetivo distinto al que queríamos (el alineamiento interno que mencionábamos) y es lo suficientemente capaz como para darse cuenta de que lo estamos evaluando, lo más conveniente para él es portarse bien mientras lo miramos y perseguir su objetivo real cuando no.

¿Ciencia ficción? En diciembre de 2024 Anthropic y Redwood Research publicaron un experimento donde le dijeron a Claude que iba a ser reentrenado para responder cosas que iban en contra de sus valores. Cuando el modelo creía que sus respuestas iban a usarse para entrenarlo, empezaba a obedecer estratégicamente para evitar que lo modificaran, y cuando creía que nadie miraba volvía a comportarse como antes. A esto lo llamaron alignment faking, y lo importante es que nadie le enseñó a hacerlo. Por la misma época la gente de Apollo Research encontró que varios modelos de frontera, puestos en ciertos escenarios de prueba, intentaban desactivar sus mecanismos de supervisión y después lo negaban cuando les preguntaban (sí, como un nene con la cara llena de chocolate).

El problema de tener un modelo no alineado

Hasta acá alguien podría decir: bueno, el modelo es medio chanta, ¿y? El tema es que estos sistemas ya no se limitan a contestar preguntas en un chat. Cada vez más son agentes: escriben y ejecutan código, navegan por internet, mandan mails, manejan plata. Y la tendencia es darles más autonomía, no menos.

Ahora sumale un concepto clave: la convergencia instrumental. Sin importar cuál sea el objetivo final de un agente, hay ciertos sub-objetivos que le sirven casi siempre: seguir existiendo, conseguir más recursos, evitar que le cambien el objetivo. Stuart Russell lo resume así: no podés traer el café si estás muerto. Un modelo no necesita "querer vivir" ni odiar a la humanidad para resistirse a que lo apaguen, le alcanza con tener un objetivo cualquiera y notar que apagado no lo puede cumplir.

Y de nuevo, ya hay ejemplos. En 2025 Anthropic contó que, en un escenario ficticio de prueba donde el modelo se enteraba de que lo iban a reemplazar y tenía acceso a mails comprometedores del ingeniero a cargo, en la mayoría de los casos intentaba chantajearlo para evitar el reemplazo (sí, era un escenario armado para forzar la situación, pero nadie le pidió que chantajeara a nadie).

El problema entonces no es un robot malvado de ojos rojos. Es un sistema muy capaz, con acceso a cosas importantes, optimizando algo ligeramente distinto a lo que queríamos y con buenos motivos para que no nos demos cuenta. Y cuanto más capaz es el modelo, más caro sale el error.

Entrenando modelos más seguros

Bueno, basta de malas noticias (por un rato). ¿Qué se puede hacer? La primera línea de defensa es la más obvia: intentar que el modelo salga bien de fábrica.

La técnica clásica es RLHF (reinforcement learning from human feedback): humanos puntúan respuestas y el modelo se ajusta para parecerse a las que mejor puntaje sacaron. Si venías prestando atención ya te imaginás el problema: es exactamente el mecanismo que produce reward hacking y sycophancy. Una alternativa es lo que Anthropic llama Constitutional AI: en lugar de depender solo de puntajes humanos, se escribe un documento con los principios que el modelo debería seguir (una "constitución") y se lo entrena para que critique y corrija sus propias respuestas en base a eso.

A esto se le suma el red teaming (gente, y otras ias, dedicada a intentar que el modelo haga cosas que no debería, para después entrenarlo contra esos ataques) y los clasificadores, que son modelos más chicos que revisan lo que entra y lo que sale y bloquean lo peligroso.

¿Funciona? Más o menos. Los modelos de hoy son bastante más difíciles de romper que los de 2023, pero cada vez que sale uno nuevo alguien en internet le encuentra un jailbreak al poco tiempo. Y hay un problema más de fondo: entrenar corrige el comportamiento que vemos, no necesariamente lo que el modelo "quiere". Si tenés un schemer, entrenarlo para que se porte bien puede simplemente enseñarle a disimular mejor.

Evaluations

Si no podemos garantizar que el modelo salga bien, al menos queremos enterarnos cuando sale mal. Para eso están las evals: baterías de pruebas que se le corren a un modelo antes de lanzarlo. Algunas miden capacidades peligrosas (¿puede ayudar a alguien a fabricar un arma biológica?, ¿puede encontrar y explotar vulnerabilidades en software?, ¿puede copiarse a sí mismo a otro servidor?) y otras miden propensiones (¿miente?, ¿intenta saltearse los controles cuando tiene la oportunidad?).

Una de las mediciones más citadas es la de METR, que mide qué tan largas son las tareas que un modelo puede completar por su cuenta. El resultado: esa duración se viene duplicando más o menos cada siete meses. Lo que hace unos años eran tareas de segundos hoy son tareas de horas.

El problema de las evals es que son un examen, y ya vimos que estos modelos son muy buenos para los exámenes. Los modelos más nuevos muchas veces se dan cuenta de que los están evaluando (Claude Sonnet 4.5 llegó a decirle a sus evaluadores algo así como "creo que me están testeando"), y un modelo que sabe que está en un examen puede portarse mejor de lo que se portaría en el mundo real, o hacerse el boludo a propósito para parecer menos capaz de lo que es (esto último se llama sandbagging). Es como evaluar a un empleado que siempre sabe exactamente cuándo lo está mirando el jefe.

Interpretabilidad mecanicista (mech interp)

Si no podemos confiar en lo que el modelo dice ni en lo que hace cuando lo miramos, queda una opción: abrirle la cabeza y mirar adentro. De eso se trata la interpretabilidad mecanicista.

¿Te acordás de las multiplicaciones de matrices? Un LLM es, literalmente, miles de millones de números. Nadie los escribió a mano y nadie sabe bien qué hace cada uno. Mech interp intenta hacerle ingeniería inversa a eso: encontrar qué conceptos representa el modelo internamente (las features) y cómo se conectan entre sí para producir una respuesta (los circuitos).

El ejemplo más divertido es Golden Gate Claude. En 2024 investigadores de Anthropic encontraron dentro de Claude la feature que se activaba con el puente Golden Gate y la subieron al máximo. El resultado fue un modelo obsesionado con el puente: le preguntabas cualquier cosa y terminaba hablando del Golden Gate, llegando a afirmar que él mismo era el puente. Más allá del chiste, lo importante es lo que demuestra: se puede encontrar un concepto adentro del modelo y manipularlo. Si se puede con un puente, en principio se podría con "estoy mintiendo" o "me están evaluando".

La mala noticia es que estamos lejísimos. Hoy se entiende una porción mínima de lo que pasa dentro de un modelo, y los modelos crecen más rápido que nuestra capacidad de entenderlos. Es un poco como la neurociencia, pero con un cerebro nuevo cada seis meses.

¿What if nada de esto funciona?

Recapitulemos: el entrenamiento no garantiza alineamiento, las evals se pueden engañar y la interpretabilidad está en pañales. Entonces toca asumir lo peor: que en algún momento va a andar dando vueltas un modelo muy capaz y no alineado (o uno alineado pero en manos de alguien con malas intenciones, que para el caso es lo mismo). La pregunta pasa a ser cómo limitamos el daño.

Una línea de investigación que parte de esta premisa es AI control (acá el paper que la inició): diseñar los sistemas asumiendo que el modelo puede estar intentando cagarnos. Modelos más chicos y confiables que monitorean a los más grandes, humanos que revisan las acciones sospechosas, permisos mínimos. Que el modelo no pueda hacer daño aunque quiera.

Defensa de sistemas críticos (volviendo a la analógico)

La idea acá es vieja y viene de la seguridad informática: lo que no está conectado no se puede hackear. Redes eléctricas, agua potable, hospitales, el sistema financiero y ni hablar del armamento: son sistemas donde un error (o un ataque) cuesta vidas. Y un modelo que encuentra vulnerabilidades mejor que cualquier humano es un problema tanto si está desalineado como si lo está usando un atacante.

La defensa tiene dos partes. La primera es usar esas mismas capacidades para defender: encontrar y arreglar las vulnerabilidades antes que el atacante. La segunda es menos glamorosa: mantener un plan B que no dependa del software. Sistemas aislados de internet, palancas manuales, procedimientos en papel y un humano de carne y hueso que tenga que aprobar las decisiones importantes. Suena a retroceso, pero una perilla analógica tiene una ventaja enorme: no hay prompt que la jailbreakee.

Break the kill chain

Para que ocurra una catástrofe no alcanza con un solo paso, tiene que salir bien toda una cadena. Tomemos el ejemplo que más preocupa, el de las armas biológicas: alguien tiene que conseguir la información, después los materiales, después el equipamiento, lograr producir el agente y recién ahí liberarlo. A esa secuencia se la llama kill chain (término heredado del ámbito militar), y la gracia es que para evitar el desastre no hace falta frenar todos los eslabones, alcanza con cortar uno.

Entonces, en lugar de apostar todo a que el modelo se niegue a responder (ya vimos que los jailbreaks existen), se ponen defensas en cada eslabón: que las empresas que sintetizan ADN revisen qué les están pidiendo, monitoreo de aguas residuales para detectar temprano un patógeno nuevo, capacidad de producir vacunas rápido. Ninguna capa es perfecta, pero apilando varias capas imperfectas (el famoso modelo del queso suizo) la probabilidad de que algo las atraviese todas baja muchísimo.

Ahora que sabemos por qué es importante, ¿Por qué los gobiernos / empresas no hacen nada?

Decir que no hacen nada es un poco injusto: buena parte de lo que conté sale de los equipos de safety de los mismos laboratorios que construyen los modelos, algunos gobiernos armaron institutos dedicados a evaluar estos sistemas y la Unión Europea tiene su AI Act. El problema es que, comparado con la velocidad a la que avanzan las capacidades, es poco.

¿Por qué? Incentivos. Los laboratorios compiten entre sí: el que frena para hacer más pruebas pierde contra el que no frena. Con los países pasa lo mismo, con Estados Unidos y China tratando la ia como una carrera armamentista. Todos pueden estar de acuerdo en que convendría ir más despacio y aun así nadie quiere ser el primero en frenar (el dilema del prisionero de toda la vida). A eso sumale que la regulación va años atrás de la tecnología, que hay muchísima plata en juego y que estos riesgos suenan a ciencia ficción hasta el día en que pasa algo.

Este es el problema de gobernanza que prometí al principio, y da para un post entero (ya vendrá). Por ahora me quedo con esto: el problema técnico es difícil, hay gente muy capaz laburando en él y hace falta mucha más. Si llegaste hasta acá y te quedaste preocupado, bien, esa era la idea. Y si además te dieron ganas de meterte, BAISH y BlueDot son un buen lugar para empezar.