Vercel eve: sandboxing y aprobaciones para agentes de IA

Vercel presentó eve como framework open-source para construir agentes de IA que ejecutan acciones reales sobre sistemas reales: escribir código, llamar APIs, modificar bases de datos, desplegar servicios. La pieza que lo diferencia de un SDK de agentes genérico es que resuelve de fábrica dos problemas que casi ningún equipo interno resuelve bien por su cuenta: dónde corre el agente cuando ejecuta algo (sandboxing) y quién decide si una acción se ejecuta de verdad (aprobaciones). La mayoría de automatizaciones con IA que hemos auditado en pymes españolas no tienen ninguna de las dos cosas: el agente corre con las mismas credenciales que un desarrollador senior y ejecuta lo que decide sin que nadie lo revise antes. Eso funciona bien el 95% del tiempo, hasta que el agente interpreta mal una instrucción ambigua y borra una tabla, envía cientos de emails de prueba a clientes reales o hace push directo a producción. No hace falta adoptar eve literalmente para que esto sirva de algo: lo que hay que copiar es el patrón, no la herramienta.

El sandboxing aísla el entorno de ejecución del agente —normalmente un contenedor o microVM efímera que se destruye al terminar la tarea— para que un error de código, un bucle infinito o un intento de escalada de privilegios no toquen el sistema host ni otros procesos. Es la misma lógica que llevamos años aplicando en pentest con entornos desechables: si algo sale mal, se tira el entorno y no ha pasado nada grave. El problema es que ese aislamiento no protege nada fuera del propio proceso: si el agente tiene una API key de un CRM, un token de Slack o acceso a una pasarela de pago, puede causar daño real y completamente legítimo desde dentro de la sandbox. El contenedor puede estar perfectamente aislado y aun así el agente cobrar de más a un cliente, borrar un canal entero de Slack o lanzar una campaña de email a toda la base de datos. Ahí es donde entra la segunda pieza —la aprobación—, que no protege el sistema operativo sino las consecuencias del lado del negocio.

Qué es realmente una aprobación en estos frameworks

Una aprobación bien diseñada no es un pop-up genérico de '¿estás seguro?': es un punto de interrupción síncrono que pausa la ejecución del agente justo antes de una acción clasificada como irreversible o de alto impacto, muestra el payload exacto que se va a ejecutar y espera una confirmación humana explícita antes de continuar. La clave técnica es que la clasificación de qué acciones requieren aprobación no la decide el agente en tiempo real —eso sería dejar al zorro decidir si entra al gallinero—, sino una política fija definida por quien despliega el sistema. Leer datos, generar un borrador o consultar una API no necesita aprobación; borrar registros, enviar comunicaciones externas o modificar configuración de producción sí. Ese registro de decisiones, además, queda auditado: quién aprobó qué acción, cuándo y con qué justificación, algo que en más de una auditoría RGPD nos ha ayudado a demostrar control humano efectivo sobre el tratamiento automatizado de datos.

En los 12 proyectos de automatización con agentes de IA que hemos desplegado para pymes catalanas en el primer semestre de 2026, en 9 el cliente no tenía definida ninguna lista de qué acciones requerían aprobación humana antes de que empezáramos a trabajar juntos —simplemente no se lo habían planteado porque el agente 'de momento solo hacía cosas pequeñas'—. El patrón se repite: se empieza con un agente que redacta borradores o clasifica tickets, funciona bien, se le van dando más permisos sin revisar los anteriores, y en cuestión de meses tiene acceso de escritura a sistemas que nadie recuerda haber autorizado formalmente. No hace falta el framework de Vercel para arreglar esto. Hace falta, como mínimo, separar las credenciales del agente de las credenciales humanas con permisos acotados por rol, definir por escrito qué tipo de acción exige un OK humano antes de ejecutarse, y registrar esa aprobación en un sitio que no sea el chat de Slack que se pierde en el scroll a las dos semanas.

• Auditar qué credenciales usa cada agente activo y si tienen permisos superiores a los necesarios
• Clasificar por escrito las acciones del agente en 'automáticas', 'requieren aprobación' y 'prohibidas'
• Ejecutar el agente en un entorno aislado (contenedor, sandbox o cuenta de servicio separada) del resto de la infraestructura
• Registrar cada aprobación humana con quién, cuándo y por qué — no en un chat efímero
• Revisar trimestralmente si los permisos concedidos siguen siendo necesarios

Dónde no compensa montar esta infraestructura

Aquí viene la parte que no todos los proveedores de servicios de IA dicen en voz alta: si tu automatización interna son tres flujos que leen datos y generan un informe en PDF, montar sandboxing dedicado y un sistema de aprobaciones con auditoría es sobreingeniería que cuesta más mantenimiento del que ahorra. La gobernanza de agentes tiene sentido cuando el agente puede escribir, borrar o comunicar hacia fuera —no cuando solo lee y resume—. Nosotros mismos, en varios proyectos, hemos recomendado al cliente NO añadir esa capa todavía y esperar a que el agente pase de 'lee y sugiere' a 'ejecuta directamente', porque construir la infraestructura de control antes de necesitarla suele quedar obsoleta o mal calibrada cuando por fin hace falta. La pregunta correcta no es '¿tenemos sandboxing y aprobaciones?' sino '¿qué puede hacer nuestro agente hoy que un humano no podría deshacer en cinco minutos?'.

La mayoría de incidentes con agentes de IA que hemos visto no vienen de que la IA 'se volviera loca' — vienen de permisos que nadie revisó desde el día que se los dieron.

• El agente tiene credenciales con permisos de escritura en producción, no solo de lectura
• El agente puede comunicarse con clientes o terceros sin revisión previa (email, WhatsApp, tickets)
• El agente maneja datos personales o financieros sujetos a RGPD
• Nadie en el equipo puede decir, sin mirar el código, qué acciones puede ejecutar el agente sin supervisión