Un equipo de ventas recupera 10.000 horas al mes

En mayo de 2026, Cloudflare permitió discretamente que personas ajenas a su organización de ingeniería empezaran a construir software. No a probarlo, no a solicitarlo mediante un ticket, sino a construirlo ellos mismos. Comerciales, personal de soporte y otros empleados sin perfil técnico recibieron acceso a Cloudflare OS, una plataforma interna que les permite ensamblar agentes y apps de IA basados en los datos propios de la empresa y conectados a sus sistemas internos.

La primera cifra en salir a la luz fue contundente. El propio equipo de ventas de Cloudflare afirmó ahorrar más de 10.000 horas al mes desde que su personal empezó a construir herramientas en la plataforma en lugar de esperar a ingeniería. Eso es tiempo recuperado, no una previsión sobre productividad futura.

4.000 apps, construidas por quienes no programan

Cloudflare reveló las cifras más amplias el 5 de agosto de 2026, al publicar dos artículos en su propio blog, "Cloudflare OS" y un texto complementario titulado "How We Use AI with Cloudflare OS", y al liberar el código de la plataforma para su uso fuera de la empresa. En los primeros 30 días tras conceder acceso a personal sin perfil técnico, los empleados construyeron más de 4.000 apps propias.

Para avanzar a ese ritmo, Cloudflare reclutó a 1.111 becarios específicamente para ayudar a implantar la plataforma en toda la empresa, mostrando a los equipos qué podía hacer por su propio flujo de trabajo un agente basado en el contexto de la empresa, en lugar de esperar a que la demanda surgiera por sí sola.

La misma plataforma revisa su propio código

Cloudflare OS no solo se usó para construir apps; también se puso a trabajar revisándolas. En cuatro meses, la revisión de código con IA de la plataforma marcó aproximadamente 250.000 problemas y bloqueó 16.000 solicitudes de fusión antes de que llegaran a producción.

Para el despliegue externo, Cloudflare lanza la plataforma con dos socios de lanzamiento, Presidio y Happy Cog, junto con un artículo complementario, "The Agent Access Model", que expone el diseño de seguridad detrás de todo ello.

El verdadero producto es el modelo de acceso, no las apps

Las 4.000 apps no son en realidad la noticia. Lo que permitió a personal sin perfil técnico construirlas con seguridad fue el modelo de acceso subyacente: Cloudflare lo estructuró en torno a la intermediación de identidad, de modo que un agente de IA recibe permiso limitado y basado en identidad para tocar un sistema interno concreto. Eso no es otra función de IA añadida sobre el acceso ya existente: es un punto de partida distinto, en el que un agente se autentica como sí mismo, limitado a una tarea, en lugar de heredar el acceso que ya tiene su operador humano.

Las cifras de revisión de código ilustran la misma idea desde otro ángulo. 250.000 problemas marcados y 16.000 solicitudes de fusión bloqueadas no son un equipo de seguridad que detecta errores después de publicar el código; son el modelo de acceso aplicado a los propios cambios de código, decidiendo justo en el momento de la solicitud de fusión qué puede avanzar un agente, o una persona que trabaja a través de él. La gobernanza reside en la capa de acceso, no en una cola de revisión añadida después.

Qué debería tomar un operador de la UE o el Reino Unido del 5 de agosto

Cualquier empresa de la UE o el Reino Unido que evalúe un despliegue interno de IA después del 5 de agosto de 2026 se verá empujada hacia la pregunta que Cloudflare respondió primero: ¿recibe un agente de IA acceso amplio de red porque resulta más cómodo de configurar, o recibe acceso limitado y basado en identidad exactamente a los sistemas que su tarea requiere? La segunda opción exige más trabajo previo, y es la que Cloudflare está liberando y recomendando ahora.

En la práctica, un operador de la UE o el Reino Unido que pilote un despliegue similar debería tratar la intermediación de identidad, no otra interfaz de chat, como la partida presupuestaria y la decisión de gobernanza. Las propias cifras de Cloudflare, 4.000 apps en 30 días y 16.000 solicitudes de fusión bloqueadas en cuatro meses, muestran cómo es el acceso limitado cuando funciona a gran escala, y son un punto de referencia razonable para pedir a un proveedor o a un equipo interno que explique por qué su propio despliegue no se acerca ni de lejos.

Leer a continuación: Microsoft abarata diez veces el entrenamiento de agentes  |  El modelo cambió, el nombre de la API no