Cloudflare llevaba meses construyendo algo en silencio. Una plataforma interna donde sus empleados, incluidos quienes no son desarrolladores, describen flujos de trabajo en lenguaje natural y un agente de IA los convierte en aplicaciones funcionales. La llamaron Cloudflare OS. Hace unos días la hicieron de código abierto.
La pregunta que muchas empresas se hacen es: ¿cómo dejo que mi equipo construya sus propias herramientas sin que alguien del equipo de seguridad termine con insomnio?
Qué resuelve una plataforma así
La fricción habitual es conocida. Tu equipo de operaciones necesita un tablero que cruce datos de tres sistemas. Piden el ticket. Pasa por priorización, desarrollo, QA, despliegue. Tres semanas después tienen algo que ya no encaja del todo con lo que necesitaban.
Cloudflare OS aborda esto desde otro ángulo. Un empleado describe lo que necesita. El agente genera una aplicación que corre en un sandbox aislado. Cada documento, cada tablero, cada flujo es una instancia separada con sus propios permisos. No hay contenedores tradicionales. Usan isolates de V8 que arrancan en milisegundos y consumen megabytes, no gigas.
El resultado: miles de empleados de Cloudflare usan la plataforma a diario para crear documentos, automatizar tareas repetitivas y construir pequeñas apps que visualizan datos. Sin pasar por el embudo de desarrollo tradicional.
El problema de seguridad que bloquea a muchas empresas
Dejar que personas no técnicas generen código con IA suena bien en teoría. En la práctica, el equipo de seguridad ve pesadillas: un prompt mal formulado que expone datos sensibles, una app que se conecta a una API de producción sin control, un agente que escribe en una base de datos que no debería tocar.
Cloudflare resolvió esto con un modelo de permisos explícito. Los agentes empiezan sin acceso a nada. Cada recurso que necesitan (archivos, APIs, bases de datos) debe ser concedido por la plataforma. El código del servidor corre con acceso a red deshabilitado por defecto. El código del cliente corre en un frame aislado.
Kenton Varda, ingeniero principal de Cloudflare, lo resumió así: el sandbox es tan seguro que puedes dejar que la IA haga lo que quiera sin introducir vulnerabilidades serias. El equipo de seguridad puede dar permiso a usuarios no técnicos para hacer vibe-coding y dormir tranquilo.
Qué cambia para tu empresa
No necesitas usar Cloudflare OS para aplicar la lección. El principio es transferible:
Separa el entorno de experimentación del de producción. Tu equipo puede construir prototipos en sandboxes aislados donde el coste de equivocarse es bajo. Cuando algo funciona, lo promueves a un entorno controlado.
Define permisos antes que casos de uso. Antes de pedirle a un agente que construya algo, decide a qué sistemas puede acceder y qué puede modificar. El perímetro de seguridad se define al principio, no después del primer incidente.
Mide el uso real, no la adopción teórica. Cloudflare dice que miles de empleados usan la plataforma a diario. No es un experimento de laboratorio. Si tu equipo no lo usa después de dos semanas, el problema no es la tecnología.
Empieza con lectura, no escritura. Un agente que resume datos de tres sistemas en un tablero es un primer proyecto seguro. Cuando tu equipo confía en el resultado, amplías a agentes que modifiquen datos.
En Luxion ayudamos a empresas a construir este tipo de plataformas internas: entornos donde tu equipo puede experimentar con IA sin que el equipo de seguridad pierda el control. Empezamos con un caso concreto, montamos el sandbox, definimos los permisos. Tu equipo construye, tú duermes tranquilo.