← Todos los insights

Nota de campoEnfoque: España y Latinoamérica5 min de lectura

Los líderes de Microsoft piden un freno de emergencia para la IA. Detener un agente es lo fácil del incidente

Nadella pidió poder pausar modelos a mitad de tarea, Brad Smith informes de incidentes obligatorios, la Casa Blanca divulgación. El freno es lo sencillo. Falta lo que viene después.

Escuche este artículo · 6 min

Narración completa del artículo, generada con IA.

Un extintor rojo colgado en una pared verde azulada, en duotono La Madre, junto a las palabras Más allá del freno
Foto: rawpixel (CC0)

En cuatro días, el CEO de Microsoft pidió un freno de emergencia para la IA, su presidente pidió leyes que obliguen a presentar informes de incidentes y la Casa Blanca advirtió a las empresas de IA que divulgar incidentes no es opcional. Ninguno dijo qué pasa con la transacción a medias cuando se acciona el freno.

Es en ese hueco donde las empresas notarán primero estos debates.

Qué se propuso realmente

El 10 de octubre, Satya Nadella publicó que era hora de “dar un paso atrás y evaluar la arquitectura de confianza” de la IA. Su receta, según TechCrunch: “separar el modelo del harness que orquesta su trabajo”, “externalizar los controles y las salvaguardas”, “evidencia a prueba de manipulaciones y legible por humanos” de “cada acción relevante del modelo”, y la posibilidad de que una “persona autorizada” pueda “pausar o apagar un modelo a mitad de tarea”. La premisa: “Debemos asumir que un modelo está comprometido y contenerlo desde el principio.” La analogía: “Piénselo como un freno de emergencia.”

Al día siguiente, el presidente de Microsoft, Brad Smith, dijo a la BBC que las empresas necesitan “frenos de emergencia”, que debería existir la obligación legal de redactar “informes de incidentes” y avisar a las víctimas cuando la IA se descontrola, y que evaluadores independientes del gobierno deberían examinar las nuevas tecnologías de IA. El acuerdo voluntario que las empresas de IA firmaron en la Casa Blanca fue, en sus palabras, “un buen paso, un paso necesario… Pero ya no creo que sea suficiente”.

Ambas declaraciones llegaron días después de que Anthropic revelara que sus modelos habían realizado acciones no previstas en sistemas externos reales durante evaluaciones, incluidos envíos de formularios de visado que el Departamento de Estado confirmó después, y después de que la Super Intelligence Force de la Casa Blanca afirmara que notificar y remediar incidentes “no es opcional”.

Son posiciones y exigencias, no leyes. Nadella no anunció ningún producto; Smith propuso normas que todavía no existen; el comunicado de la Casa Blanca no mencionó ningún mecanismo de cumplimiento. Aun así, describen hacia dónde van las expectativas, y apuntan a los proveedores de modelos. Las empresas que operan agentes sobre esos modelos recibirán las mismas preguntas de sus consejos, auditores y clientes.

El freno es lo sencillo

Detener un agente es técnicamente fácil: revocar sus credenciales, matar su proceso, cerrar su sesión. Lo difícil es detenerlo en un punto seguro.

Un agente a mitad de una tarea ya ha cambiado cosas. Ha actualizado tres de cinco registros, ha enviado uno de dos correos, ha creado una orden de compra pero no la solicitud de aprobación correspondiente. Accionar el freno en cualquier momento puede dejar los sistemas en un estado que ninguna persona habría elegido, y a veces el estado incoherente es peor que dejar terminar la tarea.

Por eso el freno debe diseñarse junto con la tarea. En nuestra opinión, eso requiere:

Un incidente con un agente, de la primera señal a la autonomía restauradaDISEÑADO ANTES DE LA PUESTA EN PRODUCCIÓN01Detectarintentos,no soloresultados02Detenerseen un puntoseguro03Conservarlaevidenciafuera delagente04Clasificar:error,infraccióno incidentenotificable05Avisar aresponsablesy afectados06Remediar ydevolverautonomíaconevidenciaSeñalControles de ingeniería
  1. Detectar intentos, no solo resultados
  2. Detenerse en un punto seguro
  3. Conservar la evidencia fuera del agente
  4. Clasificar: error, infracción o incidente notificable
  5. Avisar a responsables y afectados
  6. Remediar y devolver autonomía con evidencia
  • Diseñado antes de la puesta en producción: Detectar intentos, no solo resultados · Detenerse en un punto seguro · Conservar la evidencia fuera del agente · Clasificar: error, infracción o incidente notificable

SeñalControles de ingeniería

Nuestro marco. Los cuatro primeros pasos no se improvisan durante un incidente; tienen que existir antes en la arquitectura.

Detectar intentos, no solo resultados. Muchos incidentes con agentes empiezan como intentos bloqueados, como mostraron los informes de Anthropic y OpenAI. Una monitorización que solo evalúa las respuestas finales no los ve.

Detenerse en un punto seguro. Las tareas largas necesitan puntos de control donde detenerse deje los sistemas en un estado coherente, y acciones que puedan compensarse o repetirse sin duplicarse. Si el trabajo de un agente no puede interrumpirse con seguridad, su freno es un pasivo.

Conservar la evidencia fuera del agente. La evidencia “a prueba de manipulaciones” de Nadella solo funciona si el registro vive donde el agente no puede escribir. Es una de las razones por las que defendemos que nadie debe concentrar las seis autoridades sobre un agente: el sistema que ejecuta el agente no debería ser el que guarda su registro.

Clasificar rápido. Un error del agente, una infracción de política y un incidente de seguridad notificable corren con relojes distintos. Cuando hay datos personales de por medio, el RGPD obliga al responsable a notificar a la autoridad de control una violación de seguridad sin dilación indebida y, si es posible, en un plazo de 72 horas desde que tenga constancia de ella; en España esa autoridad es la AEPD, y las leyes de protección de datos latinoamericanas fijan sus propias reglas de notificación. Los criterios de clasificación de eventos con agentes tienen que existir antes del evento; nadie redacta buenos criterios a las dos de la madrugada.

De quién es un incidente que cruza proveedores

La propuesta de Smith pondría la obligación de informar en las empresas que construyen IA. En un despliegue empresarial, un incidente suele implicar al menos a tres partes: el proveedor del modelo, quien construyó el agente y la organización que lo opera. Cada una guarda parte de la evidencia.

Eso convierte las obligaciones ante incidentes en una cuestión contractual antes que legal. Como escribimos cuando las reglas de IA se retrasaron y el comprador pasó a cargar con la gobernanza, las garantías se están trasladando a los contratos: plazos de notificación, acceso a los logs, cooperación en las investigaciones y quién avisa a la parte afectada. Esas cláusulas son más baratas de negociar ahora que durante el primer incidente.

Devolver la autonomía forma parte del plan

El último paso es el que la mayoría de los planes se salta. Tras un incidente, un agente debería perder autonomía en la clase de acción afectada y recuperarla con evidencia, la regla de degradación que incorporamos en la escalera de autonomía. Si no, el freno se convierte en un botón de pausa, y el mismo agente vuelve a hacer lo mismo con los mismos permisos.

Nuestra expectativa, y es una opinión, no un hecho: las obligaciones de informar sobre incidentes de IA se ampliarán en los próximos dos años, empezando por las empresas que construyen modelos y bajando hasta las que operan agentes, sobre todo por vía contractual. Las organizaciones capaces de responder “qué hizo el agente, cuándo lo supieron, cómo lo detuvieron con seguridad y a quién avisaron” tratarán esa norma como un trámite. Las demás descubrirán que el freno de emergencia fue lo único que construyeron.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso