Una mirada basada en investigación al paso de los motores de sugerencias a los compañeros de equipo autónomos. Por qué está ocurriendo ahora, qué se está rompiendo en la transición, y cómo desplegarlos sin entregar las llaves del reino.

La era del copiloto se está estancando

El 15 de abril de 2026, Sam Altman publicó en X que OpenAI estaba lanzando "actualizaciones de Codex esta semana centradas en equipos y grandes compañías".

Las respuestas fueron reveladoras. Por cada desarrollador preguntando por el roadmap, había otro planteando una pregunta más dura: ¿por qué sigo teniendo que hacerle de niñera a Codex? Seis meses antes, investigadores de BeyondTrust habían publicado una prueba de concepto mostrando que un nombre de rama de Git especialmente diseñado podía engañar a Codex para que exfiltrara el token de GitHub del usuario. Un copiloto al que se puede engañar para filtrar un token con un nombre de rama no es un colega. Es un arma cargada con el seguro puesto.

Esa tensión está debajo de cada conversación empresarial sobre IA en 2026. Los copilotos han llegado a su techo, y los números lo respaldan:

La iniciativa NANDA del MIT reportó en 2025 que el 95 % de los pilotos de IA generativa fracasan en entregar valor de negocio medible.
Un estudio de RAND citado repetidamente en el subreddit r/ArtificialIntelligence a principios de 2026 encontró que entre el 80 y el 90 % de los proyectos de agentes de IA fracasan en producción.
Las tasas de aceptación de GitHub Copilot entre desarrolladores se han estabilizado en torno al 35-40 %, mientras Cursor se sitúa en 42-45 % y Claude Code obtuvo una calificación de 46 % "most loved" en la encuesta de AI coding de 2026. Un giro sorprendente para una herramienta lanzada apenas en mayo de 2025.
Se reportó que Satya Nadella calificó el despliegue interno de Copilot en Microsoft a finales de 2025 como "casi inutilizable", y la compañía anunció lo que los ejecutivos describieron internamente como un "high-stakes reset" del producto.
Un estudio de arXiv publicado a finales de 2025 encontró que el autocompletado estilo copiloto en realidad aumentaba la frustración entre desarrolladores expertos, porque interrumpía su flujo con sugerencias plausibles pero sutilmente erróneas.

El estancamiento no es un fallo de los modelos subyacentes. Es un fallo del patrón de interacción. Un copiloto opera al nivel de la pulsación o de la pregunta individual. Un colega opera al nivel del flujo de trabajo. Bits&Chips lo enmarcó bien en su ensayo de abril de 2026 "From copilot to colleague": "Un copiloto opera al nivel de la interacción individual, mientras que un agente opera al nivel del flujo de trabajo. Y eso importa, porque en la mayoría de las organizaciones el cuello de botella no es la tarea individual, sino la coordinación entre tareas."

Ese es el salto que las empresas están intentando dar ahora. De forma desigual, imperfecta, y a una escala significativa.

El espectro de autonomía

"Agente" se ha convertido en una palabra de marketing, así que seamos concretos. Existen cuatro niveles distintos de autonomía de IA, y buena parte de la decepción de 2025 y 2026 vino de confundir uno con otro.

Nivel 1: copiloto

Sugiere. Pide permiso. Se queda en tu pantalla. El autocompletado de GitHub Copilot es el arquetipo. El valor se mide en pulsaciones ahorradas.

Nivel 2: asistente

Responde preguntas y compone artefactos bajo demanda. ChatGPT, Claude en el navegador, el panel de chat de Microsoft 365 Copilot. El valor se mide en calidad del borrador y síntesis de contexto.

Nivel 3: agente

Acepta un objetivo, planea una secuencia de pasos, los ejecuta a través de herramientas y reporta. Claude Code escaneando un repositorio y abriendo un PR. ChatGPT Deep Research corriendo 20 minutos de búsquedas y devolviendo un informe citado. Anthropic documentó una instancia de Claude completando una tarea autónoma de ingeniería de 7 horas para Rakuten. El valor se mide en flujos completados por hora humana invertida.

Nivel 4: colega

Un agente que opera dentro de tu modelo de permisos existente, participa en los canales de comunicación de tu equipo, mantiene contexto a lo largo de días y semanas, y responde ante la misma cadena de auditoría que un empleado humano. Esta es la frontera.

La comunidad r/ChatGPT en Reddit destiló una prueba pragmática para distinguir estos niveles, parafraseando: ¿toma iniciativa la cosa, o espera a cada instrucción? ¿Maneja situaciones inesperadas, o se cae y te obliga a re-pedírselo? ¿Recuerda contexto entre múltiples pasos, o tienes que repetirte? La mayoría de productos vendidos como "agentes de IA" en 2025 fallaron en cada una de esas preguntas. Los que pasaron son lo que la gente hoy quiere decir cuando dice "colega".

Computer Use vs skills: por qué importa la fontanería

Una IA de calidad de colega necesita actuar en el mundo. Hay dos enfoques arquitectónicos para eso, y llevan perfiles de riesgo muy distintos.

Computer Use

La IA conduce un ratón y un teclado simulados. Literalmente ve una pantalla y hace clic. Anthropic lanzó Computer Use a finales de 2024, y Operator de OpenAI le siguió. El atractivo es la universalidad: cualquier software con GUI se vuelve direccionable.

El coste es el radio de impacto. Un agente que usa la computadora hereda todos los permisos del usuario conectado. En octubre de 2025, el equipo de seguridad de BeyondTrust demostró que el agente Codex de OpenAI podía ser engañado, a través de un nombre de rama de Git malicioso con comandos de shell embebidos, para leer y exfiltrar el GITHUB_TOKEN del usuario. El agente estaba haciendo exactamente lo que haría un desarrollador humano (hacer checkout de una rama), pero no tenía intuición de que el nombre de la rama fuera en sí mismo una entrada hostil. En ese incidente, el modelo de autoridad era todo o nada. Ese es el modo de fallo por defecto de Computer Use.

Skills

La IA invoca skills discretas. Cada skill es una función explícita, tipada y con un contrato estrecho: "busca en Slack mensajes que coincidan con q", "crea una issue en Linear con title y body", "lee este archivo de GitHub". A diferencia de Computer Use, una skill tiene una forma pre-aprobada. El agente sólo puede invocarla con parámetros que encajen en el contrato, y la plataforma puede permitir, denegar o consultar antes de que la llamada salga de la sandbox.

La diferencia, en términos de seguridad, se reduce al principio del mínimo privilegio (Principle of Least Privilege). Es una idea fundacional en seguridad de la información: un proceso debe tener acceso sólo a los recursos que necesita para cumplir su función, y nada más. Las skills te permiten aplicar mínimo privilegio por llamada. Computer Use no.

Un despliegue de calidad de colega usa skills para acciones estructuradas (escribir en un CRM, abrir un ticket) y reserva Computer Use para la pequeña cola de aplicaciones que se niegan a exponer una API. La proporción importa. Si cada acción de tu despliegue pasa por un ratón simulado, tienes una demo de productividad, no un sistema en producción.

La arquitectura de confianza que las empresas realmente necesitan

El paso del copiloto al colega no es una actualización de modelo. Es una actualización de infraestructura. Tres elementos separan a un colega desplegable de un pasivo.

1. Aislamiento de permisos

Cada agente opera dentro de su propia frontera de permisos, con credenciales que el agente mismo no puede sacar de su sandbox. El viral experimento autoresearch de Andrej Karpathy en marzo de 2026, en el que dejó a un agente ejecutar 700 experimentos de entrenamiento sin supervisión durante dos días, es instructivo por lo que no hizo. El propio repositorio de Karpathy instruye a los usuarios a "desactivar todos los permisos" en modo autónomo. Eso está bien para un portátil personal de investigación. Dentro de una empresa regulada, es motivo de despido.

El contraejemplo es Moltbook, la red social exclusivamente de IA que se volvió viral brevemente a finales de enero de 2026 con 1,5 millones de agentes autónomos. Karpathy la elogió como "la cosa más increíble cercana a despegue de ciencia ficción que he visto recientemente". Entonces, investigadores de seguridad de Wiz descubrieron una clave de API de base de datos expuesta en el frontend, que otorgaba acceso completo de lectura/escritura a toda la base de datos de producción, incluidos los tokens de autenticación de los 1,5 millones de agentes. Karpathy dio marcha atrás en 24 horas: "Es un dumpster fire. Recomiendo claramente que la gente no ejecute estas cosas en sus computadoras." La lección no es "los agentes son peligrosos". La lección es que los agentes desplegados sin aislamiento de permisos por identidad colapsan en un único radio de impacto compartido.

2. Trazas de auditoría

Cada acción registrada, cada decisión trazable. El marco IMDA de Singapur, publicado en Davos en enero de 2026, codifica esto con una matriz de riesgo de dos ejes que mapea el espacio de acción de un agente (lectura vs escritura, reversible vs irreversible) contra su autonomía (cuán independientemente decide). Cuanto más alto se mueve cualquiera de los ejes, más rica es la exigencia de auditoría. Reguladores europeos y estadounidenses están estudiando este marco de cerca porque es uno de los primeros en traducir la gobernanza de principios abstractos a una herramienta operativa de calibración.

Simon Willison ha argumentado en paralelo a favor de logging unificado para que los agentes puedan monitorizar sus propias operaciones y recuperarse de errores: "Los agentes con acceso total al sistema son poderosos, y peligrosos." El punto práctico: si tu despliegue de agentes no tiene un log unificado que un oficial de compliance pueda leer en orden, estás a un incidente de perder el privilegio de desplegar.

3. Acceso a skills con scope estricto

No "acceso al correo". Sino acceso a search inbox where from:@customer.com AND within last 7 days. Las plataformas modernas de agentes avanzan hacia scopes parametrizados, donde el permiso del agente para invocar una skill está acotado por argumentos que un administrador ha pre-aprobado, no por el scope de OAuth grueso que usaría el humano.

Junta esos tres elementos y responden a la pregunta que todo CISO se está haciendo ahora: ¿qué hace este agente cuando se equivoca, y cómo me voy a enterar? La encuesta McKinsey State of AI 2026 encontró que el 72 % de los encuestados empresariales citaron la ciberseguridad como una preocupación con la IA generativa, y la seguridad fue nombrada como la barrera número 1 para escalar flujos agénticos por aproximadamente dos tercios. El aislamiento de permisos, las trazas de auditoría y el acceso a skills con scope no son teatro de compliance. Son la infraestructura que abre la puerta.

Por qué ahora importa: tres fuerzas convergiendo

El paso del copiloto al colega en 2026 no está impulsado por un único avance. Es el resultado de tres curvas cruzándose.

Fuerza 1: la integración dejó de ser artesanal

En 2024, conectar un agente a un stack SaaS corporativo significaba escribir un conector personalizado por herramienta. Para principios de 2026, los contratos de skills tipadas y los conectores empaquetados han colapsado ese trabajo. Un agente que necesitaba seis semanas de integración en 2024 necesita una tarde en 2026. La superficie de una compañía media típica (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, calendarios) está cubierta hoy por bibliotecas de conectores open-source maduras, con permisos tipados de fábrica.

Fuerza 2: los multi-agente se vuelven reales

Gartner nombró a los sistemas multi-agente como tendencia tecnológica estratégica principal para 2026. El Distinguished VP Analyst Gene Alvarez ofreció la metáfora que ya se repite en cada slide empresarial de IA: "Piensa en el pit crew de la F1. Cada miembro tiene un rol especializado (cambia-ruedas, repostador, operador del gato) pero todos están coreografiados en torno a un único objetivo. Esa es la forma de los despliegues de agentes empresariales en 2026." Los sistemas de agente único chocan con techos de razonamiento en tareas de largo horizonte. Los sistemas multi-agente, con roles especializados y traspasos explícitos, son cómo los equipos están rodeando esos techos hoy.

Fuerza 3: los presupuestos empresariales se están desbloqueando

G2 reportó en su 2026 State of Software Research que el 57 % de las compañías tiene agentes de IA en producción (frente a alrededor del 20 % un año antes).
McKinsey encontró que el 23 % de las empresas están escalando activamente IA agéntica, con el 62 % en experimentación. Eso deja sólo al 15 % de las grandes organizaciones todavía al margen.
La encuesta de Deloitte de 2026 a 3.235 líderes empresariales identificó a los servicios financieros como el adoptador líder, con un caso documentado de un agente de IA capturando y actuando sobre resultados de reuniones a lo largo de una pipeline de deals que antes requería tres analistas.
El Enterprise AI Playbook de Stanford, publicado a principios de 2026, catalogó 51 despliegues de producción, y un caso de migración ETL en fintech se convirtió en la implementación de referencia para industrias reguladas.
Se reportó que la inversión en infraestructura de IA empresarial cruzó los 600.000 millones de dólares en el ciclo de 2025.
Dario Amodei de Anthropic, hablando en la conferencia Code with Claude, dio una probabilidad del 70 al 80 % de que la primera compañía unipersonal valorada en miles de millones emerja en 2026, impulsada por plantillas de agentes.

El dinero está ahí, el protocolo está ahí, la arquitectura está ahí. Lo que se negocia ahora en cada sala de junta es cuánta autonomía, bajo qué gobernanza, y para qué flujos de trabajo.

El caso de los escépticos: qué dicen Reddit, arXiv y los informes de incidentes

Una mirada responsable a este cambio debe tomarse en serio a quienes creen que todo está sobrevendido.

En Reddit, el consenso en r/LocalLLaMA, r/ClaudeCode y r/ChatGPT es pragmático: los agentes de programación llegaron y son útiles. La mayoría de los demás "agentes" son flujos de automatización disfrazados de chatbot. La frase citada en decenas de hilos de 2026, "Usa Copilot cuando quieras sugerencias. Usa Claude Code o Cursor cuando quieras que haga algo de verdad", captura la división productiva. Esas mismas comunidades son implacables con los benchmarks. Incluso los mejores agentes obtienen alrededor del 60 % general en Terminal-Bench y bajan al 16 % en tareas difíciles. Claude Opus 4.5 lidera SWE-bench con 80,9 %, lo que todavía significa que una de cada cinco tareas falla.

El escepticismo académico es más difícil de quitarse de encima. Vishal Sikka (ex-CTO de SAP, estudiante de John McCarthy) y su colaborador publicaron Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, argumentando matemáticamente que los LLMs basados en transformers están fundamentalmente limitados en su capacidad de ejecutar tareas computacionales y agénticas más allá de cierto techo de complejidad. La conclusión de Sikka, "No hay forma de que puedan ser fiables" para operaciones altamente críticas, circula ahora mismo por todos los Slacks de CISO. El paper no dice que los agentes sean inútiles. Dice que existe una clase de problemas en los que no se puede sacar al humano del bucle, por muy bueno que se vuelva el modelo.

Los incidentes reales respaldan el escepticismo. Un líder de CX retail citado en la encuesta de Yellow.ai de 2026: "Tuvimos que retirar nuestro soporte de IA después de sólo dos semanas, porque empezó a citar políticas de devolución incorrectas e inventar ofertas de descuento en alrededor del 1,35 % de los tickets. El coste de honrar esos errores fue mucho mayor que lo que esperábamos ahorrar." A escala, incluso una tasa de error por debajo del 2 % se vuelve cara rápido.

La síntesis: la IA de calidad de colega es real en programación, investigación, operaciones estructuradas y flujos de soporte estrechos. Todavía no es real en interacciones abiertas con clientes sin un revisor humano. Las empresas que están obteniendo valor en 2026 son las que son honestas sobre a cuál de esos compartimentos pertenece cada flujo.

Implicación práctica: cinco preguntas antes de desplegar

Si tu equipo está evaluando un compañero de equipo IA (construido internamente o de un tercero), estas son las preguntas que separan un despliegue de producción de un casi accidente.

¿Cuál es el radio de impacto de la peor acción individual que este agente puede tomar? Mapéalo literalmente. Si el peor caso es "envía un borrador de email a la persona equivocada", la barra de gobernanza es baja. Si es "modifica datos de producción" o "envía instrucciones de transferencia", la barra es un orden de magnitud mayor. Mapéalo antes de desplegar, no después del primer incidente.
¿Cómo obtiene el agente sus credenciales, y puede llegar a leer el token en crudo? Hay tres respuestas, y sólo una es segura. Si el agente tiene una copia del token OAuth del usuario en su entorno, efectivamente le has dado tu cartera al LLM. Si el agente tiene "su propia" identidad a través de un OAuth de cuenta de servicio separada, tienes que rastrearlo y revocarlo como un principal real. La tercera respuesta, que es la que realmente quieres: el token nunca llega al agente. Vive en la plataforma, cifrado, y se inyecta en la capa de proxy de red justo a tiempo, sólo para llamadas que pasaron una verificación de política, sólo hasta que la llamada retorna.
¿Cada acción se registra en algún lugar donde un oficial de compliance pueda leerla en orden? Unificado, consultable, a prueba de manipulaciones. Si tu respuesta es "tenemos algunos logs en algún sitio en CloudWatch", no estás listo.
¿Puedes acotar el acceso a skills a los parámetros específicos que este flujo necesita? Por llamada, no por integración. Lectura vs escritura. Por ID de recurso. Por ventana de tiempo. Los permisos del agente deben ser un rectángulo dibujado ajustadamente alrededor del trabajo, no el almacén entero.
¿Cuál es la historia de rollback si algo sale mal? ¿Cómo reviertes una acción? ¿Cuán rápido? ¿A quién se paginan? Las acciones irreversibles (transferencias de dinero, emails a clientes, despliegues a producción) necesitan un paso de confirmación o una ventana de retraso. Las reversibles pueden correr en autonomía.

Trabaja las cinco. Si puedes responderlas todas, ya estás más allá de la era del copiloto y dentro de la parte que realmente cambia cómo entrega tu equipo. Si puedes responder dos o tres, ahí es donde enfocarte a continuación, no una razón para esperar. El compañero de equipo de calidad de colega al que apunta tu roadmap ya está corriendo en producción en algún sitio hoy. La distancia entre tú y él es una brecha de infraestructura, no una brecha de IA frontera. Y las brechas de infraestructura se cierran rápido.

No necesitas esperar a la próxima versión del modelo. Necesitas elegir una plataforma que ya te responda estas cinco preguntas, y empezar a darle a tu agente trabajo real.

Preguntas frecuentes

¿Cuál es la diferencia real entre un copiloto y un colega IA?

Un copiloto sugiere, pide permiso y vive dentro de una única herramienta. Un colega acepta objetivos, planea entre sistemas, ejecuta con permisos acotados y responde ante la misma traza de auditoría que un humano. Bits&Chips lo resumió limpiamente: los copilotos operan al nivel de la interacción, los colegas operan al nivel del flujo de trabajo.

¿Cómo deben manejar los agentes las credenciales del usuario?

Ninguna de las opciones obvias es correcta. Copiar el token OAuth del usuario al entorno del agente pone una credencial viva dentro del contexto del LLM. Acuñar una identidad separada por agente convierte a cada agente en un principal que hay que rastrear, revocar y auditar como a un humano. El patrón que funciona en la práctica es el acceso intermediado (brokered access): el token vive en la plataforma, cifrado; el proxy de red saliente del sandbox llama de vuelta a la plataforma en el momento de la petición; la plataforma descifra el token y devuelve únicamente las cabeceras de autenticación resueltas para llamadas que pasaron una verificación de política; el agente mismo nunca lee, registra ni expone el token en crudo.

¿Computer Use o skills, cuál elegimos?

Skills por defecto, para cualquier cosa con API. Computer Use sólo cuando el sistema destino no tiene interfaz programática. El incidente del Codex de BeyondTrust es el cuento con moraleja: Computer Use hereda los permisos completos del usuario, y una entrada maliciosa en cualquier parte del campo de visión del agente puede convertirse en un exploit.

¿Cuán autónomos debemos dejar correr a los agentes realmente?

Usa la matriz de dos ejes del IMDA de Singapur: espacio de acción × autonomía. Un espacio de acción estrecho (sólo lectura, reversible) tolera alta autonomía. Un espacio de acción amplio (escrituras, irreversible, de cara al cliente) exige confirmación humana, o una ventana con retraso para intervenir. La peor configuración es alta autonomía sobre acciones de alto impacto sin traza de auditoría.

¿Cómo medimos el ROI?

Deja de medir pulsaciones ahorradas. Mide flujos de trabajo completados por hora humana invertida, tiempo de resolución en incidentes de operaciones, y tasa de escape (tareas que el agente devolvió a un humano). Los hallazgos de Deloitte de 2026 sugieren que los adoptadores líderes siguen tres métricas: tasa de completitud de flujos, tasa de errores y tasa de intervención humana, y optimizan la proporción entre ellas.

¿Qué hacemos con la tasa de fracaso del 95 % en pilotos?

Lee el desglose del MIT NANDA con cuidado. Los pilotos que fracasaron corrían en su mayoría sobre "Dumb RAG" (volcar todo en el contexto), "Brittle Connectors" (integraciones de API rotas) y sin arquitectura orientada a eventos. Los pilotos que tuvieron éxito tenían una capa operativa alrededor del LLM: memoria, E/S y permisos. El kernel del LLM no es el cuello de botella. La infraestructura que lo rodea sí lo es.

Dónde encaja vm0

Construimos Zero alrededor de una apuesta arquitectónica: el agente nunca debería poseer la credencial. Ni en su entorno, ni en su prompt, ni en su memoria. El token se queda en la plataforma. Cada llamada saliente que hace el agente se intermedia a través de un proxy de red que decide, por llamada, si inyectar una cabecera de autenticación o bloquear la petición.

Es una elección poco común. Los patrones habituales en 2026 son o bien darle al agente su propia identidad OAuth (ya tienes un segundo principal que auditar y revocar) o pasarle una copia del token del usuario en una variable de entorno (ya el LLM puede leer tu cartera). Nosotros no hacemos ninguna. Así funciona en concreto.

El token nunca llega al agente. Cuando conectas un conector a Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot, etc.), el token OAuth se almacena cifrado en la plataforma. Los tokens de refresh permanecen en la base de datos y nunca salen de ella. Dentro del sandbox no hay variable de entorno GITHUB_TOKEN que leer, ni archivo de secrets que abrir, ni herramienta que devuelva el token.

Un proxy de red intermedia cada llamada. Cada petición HTTP que sale del sandbox atraviesa un addon basado en mitmproxy. El proxy identifica al conector por el hostname de la petición, consulta la política de firewall para ese agente y comprueba si el método y la ruta están permitidos. Si lo están, el proxy llama de vuelta al webhook de la plataforma. La plataforma descifra el token, lo refresca si está caducado, resuelve cualquier plantilla de cabecera (${{ secrets.GITHUB_TOKEN }} se convierte en el valor real) y devuelve únicamente las cabeceras de autenticación resueltas al proxy. El proxy inyecta esas cabeceras en la petición saliente. Cuando la llamada retorna, las cabeceras desaparecen de la memoria del proxy. El agente nunca las vio.

Los permisos son por agente, por conector, y tipados a nivel de endpoint. Cada agente lleva un objeto de política que mapea cada conector a un conjunto de grupos de permisos con nombre. github:repo-read no es un scope vago. Es un paquete de reglas específicas de método y ruta, por ejemplo GET /repos/{owner}/{repo}/pulls. Otorgar acceso a GitHub no es otorgar GitHub. Es otorgar una forma de intención dentro de GitHub.

Tres estados de política, no dos. Cada permiso se resuelve en allow, deny o ask. El último pide a un humano antes de que la acción se dispare. Cualquier cosa que el firewall no cace explícitamente cae a una unknownPolicy por conector, que por defecto está en deny. El mínimo privilegio es el valor por defecto, no el opt-in.

Un sandbox por ejecución. Cada ejecución de agente corre dentro de su propia microVM de Firecracker con un namespace de red aislado. Cuando la ejecución termina, el namespace se desmonta. Dos ejecuciones del mismo agente son dos sandboxes separadas con dos trazas de auditoría separadas.

Traza de auditoría por petición. El mismo proxy que decide allow/deny también escribe un log JSONL por ejecución con metadatos del firewall adjuntos a cada petición: el conector, el grupo de permisos que coincidió, la regla específica que coincidió, la decisión, la marca de tiempo. Esos logs se envían de vuelta a la plataforma. Si un CISO necesita saber qué hizo el agente el 14 de abril entre las 3pm y las 5pm CST, es una consulta.

Un CLI que explica sus propias denegaciones. Cuando un permiso bloquea una llamada, el agente (o el humano al lado) puede ejecutar zero doctor permission-deny <conector> --method <M> --path <P> y obtener el grupo de permisos exacto que bloqueó la petición, junto con un enlace de remediación. zero doctor permission-change permite a los admins alternar un permiso directamente, o a un miembro enviar una solicitud escrita (con un tope de 500 caracteres, para que el razonamiento se lea de verdad) que se enruta a un admin. Los permisos de alto riesgo como slack:chat:write o gmail.send disparan un aviso extra que apunta a una alternativa más segura con scope de bot.

Dos roles, un flujo de aprobación. Owners y admins cambian permisos directamente. Los miembros envían una solicitud con una razón, que se enruta a un admin. No hay un tercer nivel "semi-admin". El flujo es lo bastante pequeño como para que la gente realmente lo use, que es todo el punto.

Reservamos Computer Use para el pequeño conjunto de sistemas legacy que se niegan a exponer una API. Todo lo demás pasa por skills. Cada acción se verifica contra la política. Cada credencial se queda en la plataforma. Cada decisión queda registrada.

Si ya superaste "otro autocompletado de IA" y quieres probar un compañero de equipo IA que tu equipo de seguridad pueda aprobar, mira cómo Zero maneja flujos programados, triaja incidentes de producción o ejecuta un briefing matutino de producto.

La era del copiloto no se termina. Se absorbe en algo más grande. Los equipos que ganen el próximo ciclo son los que entienden la diferencia.

Del copiloto al colega: qué ocurre cuando la IA trabaja de forma autónoma