Alinear el modelo nunca iba a gobernarlo.

      La mayoría de las hojas de ruta de IA se basan en una apuesta silenciosa: que los laboratorios eventualmente enviarán un modelo lo suficientemente seguro y alineado como para confiar en él en producción. Mejor entrenamiento, mejores barandillas, una versión más, y la cosa se comporta.

      Aquí está el defecto en esa apuesta. Incluso un modelo perfectamente alineado no puede decirte quién lo usó, con qué datos, bajo qué política, o entregarte un registro que puedas mostrar a un auditor. Esos no son hechos sobre cómo se comporta el modelo.

      Son hechos sobre cómo fue desplegado, y viven completamente fuera de los pesos. Un mejor modelo responde a una pregunta diferente de la que realmente están haciendo los reguladores, auditores y equipos de seguridad, y la brecha entre esas dos preguntas es donde ahora reside el verdadero riesgo.

      La ingeniería de seguridad nombró esta trampa hace cincuenta años. Un estudio de la Fuerza Aérea de EE. UU. de 1972 definió el monitor de referencia, el componente que decide si se permite una acción, y estableció tres condiciones para confiar en él: debe ser a prueba de manipulaciones, invocado en cada acceso, y lo suficientemente pequeño como para ser completamente verificado.

      El 💜 de la tecnología de la UE Las últimas novedades de la escena tecnológica de la UE, una historia de nuestro sabio fundador Boris, y un arte de IA cuestionable. Es gratis, cada semana, en tu bandeja de entrada. ¡Inscríbete ahora! Un modelo de frontera moderno no es ninguno de los tres. La alineación intenta hacer que el modelo haga cumplir las reglas destinadas a restringirlo, desde adentro, y un sistema no puede ser la cosa que se gobierna a sí misma. La gobernanza debe estar alrededor del modelo, no dentro de él.

      La seguridad no es lo mismo que la gobernanza

      La confusión se oculta en una palabra. La seguridad y la alineación preguntan si un modelo tiende a comportarse bien. Esa es una disposición, vive en los pesos, y los laboratorios se han vuelto genuinamente buenos en darle forma. La gobernanza pregunta algo diferente: quién usó qué modelo, con qué datos, bajo qué política, y con qué registro auditable.

      Esa es una propiedad de un despliegue específico. El entrenamiento puede dar forma a lo primero. No puede, por construcción, proporcionar lo segundo. Tratar ambos como un solo problema es el error de categoría que subyace en la mayoría de las conversaciones sobre el riesgo de IA.

      El problema es más grande que el modelo, y está creciendo

      Esta no es una preocupación de nicho para los laboratorios. Afecta a todos los que despliegan IA, y está expandiéndose por dos razones.

      Primero, los modelos están ganando agencia. Cuando un modelo solo producía texto, una mala interacción significaba una mala respuesta. Ahora los modelos toman acciones a través de herramientas y protocolos como MCP, y cada llamada a una herramienta es una nueva decisión sobre quién está actuando, con qué datos, bajo qué autoridad. Esas decisiones se multiplican con cada tarea y cada usuario.

      El seguimiento de OWASP para 2026 encuentra que la mayoría de los proyectos agentes que sigue son agentes de codificación, y que la inyección de comandos se relaciona con seis de los diez riesgos en su lista de los diez principales de agentes. La superficie no gobernada crece tan rápido como la adopción.

      En segundo lugar, la responsabilidad ahora es legal. La SB 53 de California y las reglas de la Unión Europea para la IA de propósito general imponen obligaciones a los laboratorios, pero la Ley de IA de la UE también impone deberes separados a los desplegadores, y la ley de protección de datos ya responsabiliza a las organizaciones por cómo se utilizan los datos personales.

      Cuando un regulador pregunta qué hizo tu IA, “usamos un modelo alineado” no es una respuesta, y el informe de seguridad de un proveedor no les dirá quién dentro de tu empresa envió qué datos a qué modelo el martes pasado.

      Los puntos de referencia públicos tampoco ayudan: StrongREJECT, HarmBench y AgentHarm califican el modelo en indicaciones genéricas, no en tus usuarios, tus datos o tu política en un día determinado. Una alta puntuación es una propiedad del modelo, no un rastro de auditoría.

      Así que el alcance es amplio y concreto: cada organización que despliega IA, una superficie que crece con cada nuevo agente, y una responsabilidad que ahora es exigible. Nada de esto es un problema de calidad del modelo.

      Por qué alinear el modelo no puede solucionarlo

      Regresa a la prueba de 1972, porque muestra exactamente dónde no puede vivir la solución.

      Un modelo no es a prueba de manipulaciones. La inyección de comandos, nombrada en 2022, funciona porque las instrucciones y los datos viajan por el mismo canal de texto, por lo que un documento que el modelo lee puede sobrescribir la instrucción que se le dio.

      Cuatro años después, sigue sin resolverse: OWASP dice que no está claro si existe una prevención a prueba de fallos, y un documento de 2026 argumenta que los agentes pueden ser siempre vulnerables. Un control que puedes reescribir con la entrada que está inspeccionando no es un control.

      Un modelo no se invoca de manera confiable como un acceso. Dale herramientas y se convierte en un delegado confundido de texto, un término de 1988 para un programa de confianza que un llamador no confiable engaña para malutilizar su autoridad, porque no puede distinguir una instrucción de los datos que está leyendo.

      Un modelo no es verificable. No puedes inspeccionar miles de millones de parámetros opacos de la manera en que puedes auditar un pequeño núcleo de aplicación.

      Si falla en las tres pruebas, la conclusión no es “alinea más fuerte”. Es que el modelo no puede ser el mecanismo de aplicación, por lo que la aplicación tiene que vivir en otro lugar.

      La solución es una capa alrededor del modelo

      Si el modelo no puede gobernarse a sí mismo, la respuesta no es un mejor modelo, sino una delgada capa de control a su alrededor, una que trate al modelo como un componente no confiable y medie todo lo que intenta hacer.

      Esta no es una nueva arquitectura por inventar. Es el monitor de referencia de 1972 reconstruido para un agente, y aquí está cómo funciona.

      Imagina una solicitud moviéndose a través de él. El modelo lee su entrada y propone una acción: llama a esta API, escribe este archivo, envía este mensaje.

      Esa propuesta nunca se confía por sí sola. Sale del modelo como una solicitud, no como un comando, y pasa a un pequeño motor de políticas fuera del modelo, situado en el camino entre el agente y el recurso que quiere alcanzar, de la manera en que la arquitectura de cero confianza separa el punto que decide si se permite una acción del punto que la lleva a cabo.

      El motor verifica la acción contra dos cosas que los pesos nunca tuvieron: tu política real y el conjunto limitado de capacidades que se le otorgaron a este agente para esta tarea.

      Si la acción supera ambas, un punto de aplicación la realiza; si no, se rechaza. De cualquier manera, quién actuó, a través de qué modelo, con qué datos, bajo qué política, y qué se decidió se escribe en un registro.

      Ese flujo restaura las tres propiedades que el modelo no pudo proporcionar. Es a prueba de manipulaciones, porque la política vive en un pequeño motor externo en lugar de en texto del que el modelo puede ser argumentado. Siempre se invoca, porque nada llega a un recurso real sin pasar por él.

      Y es verificable, porque un punto de aplicación lo suficientemente pequeño como para ser leído es uno en el que realmente puedes confiar, de una manera que miles de millones de pesos opacos nunca pueden ser. Esta es la razón por la que las defensas de investigación más fuertes ya funcionan de esta manera: CaMeL, de Google DeepMind y ETH Zurich, obtiene seguridad demostrable al contener el modelo exactamente así, y se mantiene incluso cuando el modelo subyacente sigue siendo vulnerable. La garantía vive en la arquitectura, no en los pesos.

      Nada de esto hace que el modelo sea seguro, y ese es el punto. Hace que el sistema circundante sea responsable, que es un objetivo más pequeño y mucho más alcanzable, y es el que realmente exige el problema del despliegue.

      La capa correcta

      Este no es un argumento en contra de la alineación. La alineación es necesaria, y está mejorando. Simplemente es la capa incorrecta para la pregunta que realmente están haciendo los reguladores, auditores y usuarios. La respuesta a esa pregunta ha estado en la estantería desde 1972, y la industria sigue redescubriéndola de la manera costosa.

      El próximo modelo será más seguro que este. Aún no sabrá quién lo usó, con qué datos, o bajo qué política. Cerrar esa brecha es el trabajo, y es la historia.