Un agente en producción no es un prompt con permisos. Es un sistema distribuido con identidad, herramientas, estado, políticas, costes y modos de fallo.
La lista publicada por Google Cloud en julio sobre la “empresa agéntica” resulta valiosa menos como anuncio de producto que como prueba de cuánto ha cambiado la pregunta de ingeniería. La conversación ya no es simplemente ¿qué modelo usamos? Ahora es: ¿quién puede crear agentes, a qué pueden acceder, cómo conservan el contexto, cómo se evalúan sus acciones y quién responde cuando un paso automatizado falla?
Por qué importa
Un modelo puede dar una respuesta espectacular en una demo. Un agente en producción debe sobrevivir a la ambigüedad, caídas parciales, datos desactualizados, cambios de política, entradas maliciosas, picos de coste y usuarios que cambian de criterio a mitad de una tarea.
Esa diferencia convierte una función de IA en un problema de sistema operativo. El agente necesita identidad. Sus herramientas necesitan permisos limitados. El trabajo prolongado necesita estado duradero. Cada acción relevante necesita una política, una evidencia y una ruta definida hacia revisión humana.
Las preguntas que hay detrás de las preguntas
La lista de Google recorre construcción, escala, optimización y gobierno. Cuatro temas merecen especial atención.
1. Diseñar para un perímetro operativo concreto
Conviene empezar con un agente y un mandato estrecho. “Ayudar en compras” no es una especificación de producción. “Recopilar la documentación para dar de alta a un proveedor, validar campos obligatorios, señalar excepciones del control de sanciones y preparar el expediente para aprobación” ya se acerca mucho más.
Un mandato acotado hace comprensibles las herramientas, evaluaciones, permisos y responsabilidades. La arquitectura multiagente debe aparecer porque el proceso exige especialización, no porque seis círculos queden más sofisticados en un diagrama.
2. Tratar la conectividad como capacidad gobernada
MCP, las APIs y los conectores ponen sistemas empresariales al alcance de los modelos. Que algo esté disponible no significa que esté autorizado. Una buena arquitectura distingue entre descubrir, leer, proponer y ejecutar. Un mismo agente puede consultar una factura, preparar una corrección y solicitar aprobación, pero tener prohibido contabilizar el cambio.
También importa la identidad. Actuar como el usuario, mediante autoridad delegada o con una identidad de servicio genera implicaciones diferentes en auditoría, revocación y segregación de funciones.
3. Hacer explícitos el tiempo y el estado
Muchos procesos valiosos no caben en un turno de chat. Una reclamación puede esperar dos días por un documento. El alta de un proveedor puede detenerse para revisión jurídica. Un flujo de mantenimiento puede reanudarse tras recibir un evento del ERP.
Por eso son esenciales el estado duradero, las llamadas idempotentes, los checkpoints, la reanudación y las reglas de caducidad. La memoria no debería convertirse en un cajón de historial conversacional. Debe separarse entre estado de la tarea, conocimiento corporativo aprobado, preferencias del usuario y datos que nunca deben persistir.
4. Gobernar el bucle de ejecución, no solo la respuesta
Los filtros de salida no bastan cuando el agente puede actuar. El control debe abarcar la intención, la selección de herramientas, los argumentos, los sistemas de destino, la verificación del resultado y el escalado.
Aquí el software determinista vuelve al centro. Políticas, esquemas, presupuestos, límites de frecuencia, aprobaciones y reversión deben quedar fuera del razonamiento probabilístico siempre que sea posible. Las evaluaciones deben comprobar la traza completa: si el sistema llegó al resultado correcto, usó las herramientas adecuadas, respetó las políticas y se detuvo en el límite previsto.
Una puerta práctica hacia producción
Antes de permitir que un piloto toque un sistema real, la dirección debería poder responder:
- ¿Qué resultado empresarial y qué umbral de aceptación definen el éxito?
- ¿Qué identidad usa el agente y quién puede revocarla?
- ¿Qué herramientas puede descubrir, consultar y modificar?
- ¿Qué datos se conservan, dónde y durante cuánto tiempo?
- ¿Qué acciones requieren aprobación humana?
- ¿Cómo se contienen la inyección de prompts, la exfiltración de datos y la ejecución insegura de código?
- ¿Cómo se monitorizan calidad, latencia, coste y comportamiento anómalo?
- ¿Qué ocurre si falla el modelo, un conector o el sistema de destino?
- ¿Quién es propietario del agente después del lanzamiento?
- ¿Puede la organización cambiar de modelo o proveedor sin reconstruir el proceso?
No poder responder todavía no obliga a cancelar el proyecto. Significa que sigue siendo un prototipo.
La visión de Lexdatum
La unidad duradera de la IA empresarial no es el prompt. Es la traza de ejecución controlada: objetivo, contexto, herramientas, permisos, acciones, evidencias, controles y responsabilidad.
Las organizaciones que estandaricen pronto esos elementos podrán construir muchos agentes sin crear otros tantos modelos de riesgo incompatibles. Las que optimicen únicamente la velocidad de la demo terminarán dedicando más tiempo a reconciliar identidades, conectores y controles que a automatizar trabajo útil.
La ruta responsable más rápida hacia producción suele ser más estrecha de lo esperado: un proceso relevante, un responsable claro, un resultado medible y una arquitectura que pueda ampliarse una vez haya ganado confianza.
Fuentes
- Google Cloud — 20 questions for the Agentic Enterprise (and how Agent Platform can help) (2026-07-07)
Nota de investigación: este análisis se basa en información pública disponible a 31 de agosto de 2026. Las capacidades, los precios y las interpretaciones regulatorias pueden cambiar. Las métricas comunicadas por proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad o inversión.