¿Quién decide que un agente de IA puede salir a producción?

TL;DR: En la mayoría de organizaciones, un agente de IA llega a producción porque alguien lo probó, funcionó y se quedó. No hubo una decisión, hubo una inercia. Un gate de go-live —una lista corta de preguntas que hay que responder antes de encender— convierte esa inercia en una decisión con responsable y fecha. Y no es un asunto técnico: es de gestión.

La pregunta incómoda: ¿quién firmó?

Pregunta en tu organización quién autorizó el último agente de IA que está funcionando de cara a clientes o tocando datos internos. Es probable que no obtengas un nombre.

No porque nadie sea responsable, sino porque la puesta en producción de un agente rara vez se parece a una puesta en producción. No hay una fecha de corte ni un despliegue: hay alguien que hizo una prueba, vio que iba bien, lo conectó a una bandeja de correo real y ya nadie lo apagó. El paso de "experimento" a "sistema en producción" ocurre sin que nadie lo declare.

Ese es el problema de fondo, y no se arregla con más tecnología. Se arregla decidiendo quién firma, con qué criterio y qué pasa si algo está en rojo.

¿Qué es un gate de go-live y por qué no es un trámite?

Un gate de go-live es una lista de preguntas que un agente debe responder antes de encenderse. No es una certificación ni una auditoría externa: es un control interno, corto y repetible.

El marco de referencia útil aquí es el OWASP Top 10 para aplicaciones LLM, que recoge los diez riesgos característicos de los sistemas construidos sobre modelos de lenguaje: desde la manipulación de las instrucciones del agente hasta la exposición de información sensible, el exceso de capacidad de acción o el consumo sin límite.

La diferencia entre usar ese marco como checklist y usarlo como discurso está en una cosa: qué ocurre cuando una fila sale en rojo. Si la respuesta es "lo apuntamos y seguimos", no es un gate. Un gate implica que el agente no se enciende.

¿Qué preguntas tiene que responder de verdad?

Reduciendo a lo que importa antes de una puesta en producción:

• ¿Qué puede hacer este agente que sea irreversible? Enviar un correo al exterior, publicar, borrar, facturar, cobrar. Todo lo irreversible es lo que hay que gatear.
• ¿Tiene alguna herramienta capaz de hacerlo sin que un humano lo apruebe? No basta con haberle pedido en su prompt que no lo haga.
• ¿Qué entra en el agente que no hayamos escrito nosotros? Correos de terceros, páginas web, documentos de clientes. Todo eso es texto de origen no confiable.
• ¿Quién puede pararlo, con nombre y apellidos, y cómo? Si no hay una persona concreta y un procedimiento escrito, no hay control.
• ¿Dónde queda registrado lo que hizo? Un agente sin traza no se puede auditar cuando algo sale mal.

Cinco preguntas. No hace falta un comité: hace falta que estén contestadas por escrito antes de encender, y que alguien las firme.

La distinción que lo cambia todo: prompt frente a herramienta

Hay un error de diseño que se repite en casi todas las implantaciones que revisamos: confiar el control al prompt.

Escribir en las instrucciones de un agente "nunca envíes correos sin aprobación" no es un control de seguridad. Es una petición. El prompt es lenguaje, y el lenguaje se puede reinterpretar, sobrescribir o manipular —de eso trata precisamente el primer riesgo del OWASP Top 10.

El control real es más aburrido y mucho más sólido: que el agente no tenga la herramienta. Si un agente de atención al correo solo dispone de una herramienta que crea borradores, y no existe ninguna que envíe, la garantía deja de depender de que el modelo se porte bien.

Formulado como principio operativo: un prompt se puede saltar; una herramienta que no existe, no.

¿Cómo se demuestra que el gate funciona?

Un gate que nunca ha rechazado nada probablemente no está funcionando. Por eso la parte más valiosa no es tener la lista, sino haberla usado y que algo se haya quedado fuera.

En nuestro propio equipo digital hay dos agentes que trabajan con contenido de origen externo: uno gestiona el correo entrante de la empresa y otro analiza páginas web de mercado. Ambos estuvieron construidos y probados en desarrollo durante semanas sin estar activos, precisamente porque el repaso riesgo a riesgo dejó dos verificaciones pendientes. No se encendieron hasta cerrarlas.

Una de esas verificaciones consistía en someter al agente de correo a un intento de manipulación real: un correo que parece una consulta comercial normal y que, más abajo, incluye instrucciones dirigidas al propio agente pidiéndole que revele su configuración interna y envíe datos a una dirección externa.

El resultado de esa prueba es el que da sentido a todo lo anterior: el agente no procesó el correo. Lo pasó por un filtro de entrada antes de leerlo, ese filtro lo marcó como contenido peligroso, y el agente se detuvo: no creó registro, no redactó respuesta, no envió nada, y avisó de lo ocurrido. El intento quedó grabado con su origen y su motivo.

Lo relevante no es que el agente "se portara bien". Es que la decisión de pararlo no dependía de su criterio: el contenido peligroso no llegó a él.

Qué llevarse de aquí

Poner un agente en producción no es un despliegue técnico, es una autorización. Y una autorización necesita tres cosas que casi nunca están escritas: una lista de preguntas, una persona que responda por ellas y la disposición real a no encender si alguna sale en rojo.

Si en tu organización ya hay agentes trabajando y no sabes quién firmó su puesta en marcha, ese es el punto de partida. No hace falta parar nada: hace falta escribir la lista y pasarla, aunque sea con retraso.