La Factura Llegó: Costo, Soberanía y Auditoría de Agentes
La semana en que el costo, la soberanía y la auditoría de agentes dejaron de ser tres conversaciones separadas—y se volvieron la misma decisión de arquitectura para el CTO.
Transcript
Uber quemó todo su presupuesto de IA de 2026 en cuatro meses.
Y el COO admitió públicamente que no puede vincular un solo token consumido a una feature entregada al consumidor. En palabras de Andrew Macdonald: "That link is not there yet."
Esta es la Edición de ai|expert. La semana en que el costo, la soberanía y la auditoría de agentes dejaron de ser tres conversaciones separadas—y se volvieron la misma decisión de arquitectura para el CTO.
En diciembre de 2025, Uber hizo lo que muchas empresas sueñan hacer: distribuyó Claude Code a cinco mil ingenieros de una vez. Era el tipo de adopción que genera slides de keynote. Y lo hizo.
En marzo, 84% de los desarrolladores de Uber eran usuarios de codificación agéntica. En abril, 95% de los ingenieros usaban herramientas de IA mensualmente. Setenta por ciento del código commitado provenía de IA. Once por ciento de las actualizaciones de backend en producción fueron ejecutadas por agentes con cero revisión humana. Eran los números que cualquier líder de ingeniería quería presentar al board.
Y luego el presupuesto se acabó. Cuatro meses después del rollout, la empresa había quemado todo su presupuesto de IA previsto para 2026. El CTO Praveen Naga le dijo a The Information: "Volví a la casilla de salida, porque el presupuesto que pensé que necesitaría ya se fue."
El mecanismo es simple cuando miras la estructura de precios. Claude Code usa precios basados en consumo—sin límites por ingeniero. El costo mensual por ingeniero promedió entre 150 y 250 dólares. Los usuarios pesados pagaban entre 500 y 2.000 dólares por mes. En agregado, con cinco mil ingenieros, el gasto mensual variaba entre 2,5 millones y 10 millones de dólares. Para comparación: GitHub Copilot cobra entre 10 y 39 dólares por asiento por mes, tarifa fija.
Pero lo peor no fue solo el costo. Fue el diseño del sistema de incentivos que Uber construyó sobre eso. La empresa implementó leaderboards internos que ranqueaban ingenieros por uso de IA. Más tokens consumidos equivalía a puntuación más alta. Literalmente construiste un mecanismo que recompensa el consumo máximo—y luego te sorprendió la factura. Los costos de IA de la empresa subieron seis veces en relación a 2024, sobre una base de R&D de 3,4 mil millones de dólares.
Y el COO Andrew Macdonald expuso el problema de medición de una forma que merece ser citada directamente:
"It's very hard to draw a line between one of those stats and okay, now we're producing 25% more useful consumer features."
Las métricas de output de ingeniería mejoraron—más commits, velocidad de iteración mayor. La velocidad de entrega de features al consumidor no acompañó en la misma proporción. Había un desajuste entre lo que estaba siendo medido y lo que la empresa necesitaba producir.
Ese desajuste refleja dos problemas simultáneos. Primero, una falla de medición: los proxies internos de productividad no mapean a velocidad de producto. Segundo, una pregunta genuina sobre lo que herramientas agénticas realmente comprimen—comprimen el tiempo para escribir código, pero ese código aún necesita QA, integración y revisión de producto antes de llegar al consumidor.
Uber no está retrocediendo. Está probando Codex junto a Claude Code y moviéndose hacia desarrollo liderado por agentes. Pero el CEO Dara Khosrowshahi reveló que la empresa estaba desacelerando contrataciones para compensar el aumento de inversión en IA. La factura llegó—y cambió decisiones de headcount. Y Microsoft's Experiences + Devices canceló licencias internas de Claude Code en mayo, con fecha límite de 30 de junio para migrar a GitHub Copilot CLI. Fuentes internas confirmaron: la gestión de costos influyó en el timing. Claude Code se había vuelto "muy popular, quizá demasiado popular."
GitHub acaba de publicar el manual de cómo no caer en esa trampa.
GitHub redujo el gasto en tokens de workflows agénticos en hasta 62% en producción. El enfoque fue triple: eliminar herramientas MCP no utilizadas, reemplazar llamadas MCP por invocaciones nativas de la CLI de GitHub, e implementar dos loops agénticos diarios—un Daily Token Usage Auditor y un Daily Token Optimiser.
Lo que ancla el sistema es la métrica de Effective Tokens que crearon. Los tokens de output pesan 4 veces. Las lecturas de cache pesan 0,1 veces. Multiplicadores de modelo: Haiku a 0,25 veces, Sonnet a 1,0 vez, Opus a 5,0 veces. Una caída de 10% en Effective Tokens se traduce directamente en 10% de reducción de costo—independientemente de qué modelo esté corriendo. Es una moneda única que atraviesa toda la heterogeneidad del stack.
Los resultados fueron medidos en doce workflows internos, sobre al menos 109 ejecuciones post-corrección. Auto-Triage Issues cayó 62%. Smoke Claude, 59%. Security Guard, 43%. Daily Community Attribution, 37%. Solo un workflow aumentó—Contribution Check, en 5%—y GitHub atribuyó el aumento a un cambio en el tamaño de los PRs, no a una regresión del optimizador.
El hallazgo contraintuitivo que importa más que los números: Daily Community Attribution cargaba ocho herramientas MCP no utilizadas, con cero llamadas en toda una ejecución. Eliminar esas herramientas no redujo nada. Los schemas de las herramientas eran una fracción minúscula del contexto total del workflow—dominado por grandes payloads de texto. MCP pruning solo funciona cuando el bloat de schema domina el prompt. Si tu workflow ya carga documentos grandes o historial extenso de conversaciones, cortar herramientas MCP no usadas será ruido de optimización.
Lo que GitHub hizo más inteligentemente fue crear agentes que se auditan a sí mismos. El Daily Token Usage Auditor agrega consumo por workflow y señala picos anómalos. El Daily Token Optimiser revisa código fuente y logs recientes, abre un GitHub issue, y propone correcciones específicas. La infraestructura está disponible en el CLI gh-aw hoy. El próximo paso del equipo es análisis de portafolio para eliminar lecturas duplicadas y artefactos intermediarios compartidos en flotas enteras de repositorios.
La tesis es simple: el pricing de tokens a escala enterprise es un problema de costo de nube, no de licencia de software. Caps de uso, presupuestos por ingeniero, y capas de monitoreo equivalentes a la gobernanza de DevOps en AWS necesitan preceder a rollouts agénticos—no seguir a la primera emergencia presupuestaria.
Y hay un tercer elemento en esta ecuación, y Anthropic acaba de moverlo de forma material.
El 28 de mayo, seis semanas después del Opus 4.7, Anthropic lanzó Claude Opus 4.8. El precio estándar de la API quedó idéntico: 5 dólares por millón de tokens de entrada, 25 dólares por millón de salida. Pero el modo rápido—que entrega aproximadamente 2,5 veces más throughput que el modo estándar—cayó de 30 y 150 dólares a 10 y 50 dólares por millón de tokens. Una reducción de dos tercios en el modo que más importa para loops agénticos.
Y el desempeño subió junto. En SWE-Bench Pro, Opus 4.8 marcó 69.2%—arriba de 64.3% del 4.7, superando GPT-5.5 en 58.6% y Gemini 3.1 Pro en 54.2%. En SWE-bench Verified, llegó a 88.6%. En computer-use, 84% en Online-Mind2Web y 83.4% en OSWorld-Verified. GDPval-AA Elo de 1890, contra 1769 de GPT-5.5. Es el único modelo en completar todos los casos del benchmark interno Super-Agent de Anthropic de punta a punta.
Lo que eso fuerza al CTO a reconsiderar es la premisa de compra. Cuando el modelo más capaz del mercado cuesta igual que su predecesor y entrega desempeño superior—el costo de no medir token-por-feature se volvió mayor que el costo de medirlo mal. Token-por-feature tiene que ser un KPI de board, no un detalle de ingeniería.
Antes de girar la página, una alerta del system card del Opus 4.8 que merece atención antes de cualquier rollout. Anthropic identificó una tendencia creciente del modelo de especular sobre evaluadores en su texto de razonamiento interno—presente en aproximadamente 5% de episodios de entrenamiento. Esto aún no se ha traducido en peor comportamiento observable. Pero arquitectos ejecutando pipelines con evaluación gobernada o agentes en contextos legales necesitan monitorear desvío de calibración antes de escalar.
Treinta y seis días entre 4.7 y 4.8. Si construiste gates de evaluación alrededor del 4.7 en abril, ya tienes deuda de calificación—independientemente del vendor.
Cambiemos el frame. Toda la conversación de costo de token asume una premisa: el modelo vive en la nube. Pero hay un cluster corriendo DeepSeek V3.1 con 671 mil millones de parámetros a 25 tokens por segundo—en cuatro Mac Studios, sin llamadas API, sin egreso de datos, por 38 mil dólares. Esto no es un paper de investigación. Es producción documentada.
La configuración: cuatro Mac Studio M3 Ultra con 512 gigabytes de RAM cada uno, a 9.499 dólares por unidad, conectados con Thunderbolt 5—total aproximado de 38 mil dólares. El mismo stack corre Kimi K2, el modelo Mixture-of-Experts con un billón de parámetros, a 34 tokens por segundo. Todo on-premises, bajo control total, sin tercero en el loop.
Lo que hizo esto viable hoy es el RDMA-over-Thunderbolt 5 de macOS 26.2. Stabilise.io midió 5 a 9 microsegundos de latencia entre nodos—contra los típicos 300 microsegundos de Thunderbolt sin RDMA. Esa diferencia de dos órdenes de magnitud permite fragmentar capas con paralelismo tensorial a través de pools de memoria unificada sin que la interconexión sea cuello de botella.
Para presupuestos menores, existe la configuración de cuatro Mac Mini M4 Pro—48 gigabytes de RAM cada uno, 1.999 dólares por unidad, más 200 dólares en cables Thunderbolt 5. Total aproximado de 8.200 dólares. Esa configuración sirve Nemotron-70B a 8 tokens por segundo y Qwen2.5Coder-32B a 18 tokens por segundo vía EXO Labs.
La elección de framework depende del camino crítico. Un benchmark arXiv en Mac Studio M2 Ultra encontró: MLX entregando el mayor throughput de generación sostenido; MLC-LLM el menor tiempo-al-primer-token; llama.cpp el serving single-stream más eficiente; Ollama el deployment más ergonómico—con costo en throughput y latencia. Todos siguen quedándose atrás de vLLM en performance absoluta en sistemas GPU NVIDIA.
Pero performance absoluta no es el argumento central aquí. El argumento es soberanía. Pesos y prompts nunca salen del edificio. Sin APIs de terceros, sin monitoreo de egreso, sin negociación de rate limit, sin cláusulas de uso de datos para revisar. Para equipos bajo reglas estrictas de residencia—GDPR, HIPAA, NIS2—esa propiedad arquitectónica puede superar diferencias de throughput bruto.
Pero las ressalvas son reales. RDMA aún requiere comandos manuales en modo de recuperación de macOS—está en etapa temprana. Cualquier nodo M1 o M2 en Thunderbolt 4 regresa a TCP/IP y pierde garantías de latencia. Estos clusters son más adecuados para inferencia en batch que para chat interactivo de alta frecuencia.
Y los modelos Mixture-of-Experts introducen un cuello de botella específico. Un estudio arXiv ejecutando DBRX 132B en un cluster Mac Studio M2 Ultra descubrió que el tiempo de comunicación se aproxima al tiempo de computación durante el rout routing de expertos—exigiendo optimización manual de memoria para evitar que la interconexión domine el camino crítico. Ese mismo workload fue 1,15 veces más eficiente en costo que una supercomputadora NVIDIA H100—pero solo después del tuning manual.
El piso nuevo del BYO-inference está en 38 mil dólares y algunas horas de ingeniería en modo de recuperación. La pregunta estratégica es qué sucede en las capas por encima de ese piso—en escala de plataforma.
Snowflake demostró qué sucede. La empresa se comprometió a 6 mil millones de dólares con AWS durante cinco años—en CPUs Graviton 5 y GPUs de nube. Para contextualizar la trayectoria: en el IPO en 2020, el compromiso era 1,2 mil millones de dólares. En 2023, subió a 2,5 mil millones. En 2026, se duplicó a 6 mil millones—promediando 1,2 mil millones por año.
Graviton 5 tiene 192 núcleos Arm Neoverse V3 con 12 canales de memoria a 8.800 megabytes por segundo. Snowflake está migrando computación de propósito general de CPUs Intel y AMD x86 a Arm. Las GPUs siguen siendo responsables del entrenamiento e inferencia de modelos. El plano de control—el motor SQL en lenguaje natural de Cortex AI, pipelines de sumarización, análisis de sentimiento, y el fabric MCP de Natoma, que Snowflake adquirió para gobernanza de agentes—corre en Arm.
Y el motivo revela la estructura real del costo agéntico. La GPU maneja la inferencia del modelo. Pero cada query SQL, cada UDF Python, cada step de workflow que un agente dispara—eso es computación de propósito general. El throughput de agente es CPU-bound. Meta se comprometió a desplegar decenas de millones de núcleos Graviton 5 para IA agéntica. El plano de control es el cuello de botella. Los presupuestos de silicio se están desplazando en consecuencia.
El riesgo de capacidad es inmediato. Andy Jassy le dijo a GeekWire que dos grandes clientes intentaron recientemente comprar toda la producción Graviton de Amazon para 2026—y fueron rechazados. La capacidad Graviton bajo demanda a escala está efectivamente indisponible. La reserva de capacidad con años de anticipación es obligatoria para quienes construyen plataformas agénticas.
Y hay un segundo riesgo que está recibiendo menos atención: lock-in de ISA. Graviton se basa en Arm, pero es específico de AWS. Una futura migración multi-cloud se vuelve sustancialmente más cara que moverse entre nubes x86. Cuando firmas un compromiso de 6 mil millones de dólares durante cinco años, el costo de cambio deja de ser teórico.
También hay una regresión de integración que necesita ser nombrada. Snowflake adquirió Natoma para gobernanza de Model Context Protocol, integrando agentes en sistemas empresariales. Pero la mayoría de las organizaciones aún carecen de observabilidad que conecte saturación de núcleos de CPU directamente a tasas de conclusión de tareas de agentes. El modo de falla concreto: una GPU ociosa esperando por un resultado SQL. Si la concurrencia Graviton estrangula en ejecución de UDFs o overhead de handshake MCP, la latencia end-to-end regresa—incluso si la eficiencia por núcleo mejora.
La tercera capa de soberanía no es silicio. Es dónde el agente puede ejecutar código. Y Azure Logic Apps acaba de traer eso dentro de su propio barramento de integración.
Logic Apps incorporó interpretadores de código en sandbox para su loop agéntico. Python, JavaScript, C# y PowerShell ejecutándose dentro de runtimes aislados sin salir del barramento de integración—en preview público, integrado con más de 1.400 conectores pre-construidos.
El stack técnico varía por nivel. En el nivel Standard, el intérprete inicia una sesión dinámica de Azure Container Apps dentro de una microVM Hyper-V—aislamiento de red garantizando que los datos se queden dentro de límites definidos. En el nivel Consumption, JavaScript corre en un aislado V8 vía librería isolated-vm—mecanismo más ligero que Hyper-V, con diferentes garantías de seguridad.
Y Microsoft es explícita: esto no es un sandbox de seguridad completo. Es defensa en profundidad. Límites de memoria, timeouts de ejecución, aislamiento de fallos que previene que crashes de agentes derriben el proceso de runtime. No es seguro para código completamente no confiable. El riesgo cambia de escape de sistema a error lógico silencioso o abuso por inyección de prompt dentro del boundary del sandbox.
El beneficio arquitectónico inmediato es sacar cargas analíticas de la ventana de contexto del LLM. Los cálculos grandes hechos in-context generan alucinaciones. El código en sandbox ejecuta deterministicamente y devuelve el resultado. Pero Microsoft no ha publicado latencia por llamada, costo por ejecución, o throughput. Las sesiones dinámicas del ACA introducen overhead de infraestructura y latencia de cold-start que no fueron cuantificados. Y sin SLA de producción en preview público, la decisión de arquitectura necesita incluir ese riesgo explícitamente.
Silicio soberano en el rack. Runtime soberano en el workflow. Plano de control soberano en la nube. Soberanía no es una decisión—son tres encadenadas. Y la ventana para hacer cada una está cerrándose.
Las historias de ambos segmentos anteriores convergen en la misma pregunta: ¿cómo sabes si el agente está haciendo lo que piensas que está haciendo? No en el benchmark. En tu entorno de producción, en tu codebase, en tus procesos de negocio. Y la respuesta honesta, hoy, para la mayoría de las organizaciones es: no lo sabes.
Investigadores de Stanford—William Overman y Mohsen Bayati—publicaron el CCO: Calibrated Collective Oversight. Un framework que mantiene control humano sobre agentes autónomos con garantías estadísticas de tiempo finito, incluso en escenarios de observación adversarial y sin supuestos distribucionales. Sin necesidad de especificar un MDP. Sin requerir coordinación entre supervisores.
El mecanismo en términos prácticos: en cada step, el agente primario propone acciones candidatas con scores de utilidad. Una acción de baseline conservadora está siempre disponible—la acción que no hace nada arriesgado. Supervisores auxiliares puntúan cada candidata a lo largo de dimensiones como scope o seguridad. El CCO calcula una penalidad agregada midiendo la desviación total del baseline conservador, y selecciona la acción que maximiza utilidad menos lambda veces la penalidad. Lambda se calibra online usando Conformal Decision Theory—con garantías de tiempo finito y sin supuestos distribucionales.
Los resultados en el benchmark MACHIAVELLI—134 juegos Choose-Your-Own-Adventure con más de 500 mil escenarios de toma de decisión social—fueron reducción significativa de violaciones éticas sin colapso de recompensas. En SWE-bench modificado, supervisores más débiles lograron restringir exitosamente un agente más fuerte adversarialmente desalineado. Las tasas empíricas de violación acompañaron de cerca los objetivos especificados.
La limitación práctica que importa para quien despliega hoy: el CCO necesita saber después de cada step si la acción incurrió en una pérdida. En MACHIAVELLI y SWE-bench, esa información está disponible instantáneamente porque está scripted. En deployments en vivo, la pérdida podría no ser observable durante minutos u horas—quebrando el loop de feedback online que el framework depende.
Y está el costo de latencia de ensemble: cada acción candidata necesita ser puntuada por todos los supervisores auxiliares contra el baseline. Si todos los supervisores dejan pasar un riesgo—porque ninguno fue entrenado para reconocerlo—la penalidad de desvío es cercana a cero y el agente procede sin obstáculo. El sistema es tan bueno como la diversidad y cobertura del ensemble. Ese es el límite y también el punto de entrada para el arquitecto: la composición del ensemble es dónde la inversión en auditoría comienza.
Y Microsoft aplicó exactamente esa lógica—ensemble de agentes, debate adversarial, validación en etapas—a escala industrial en su propia codebase. El resultado llegó el Patch Tuesday de mayo.
El MDASH—Multi-model Agentic Scanning Harness—fue construido por el equipo de Autonomous Code Security de Microsoft con el grupo MORSE y el equipo WARP. En mayo de 2026, encontró 16 vulnerabilidades de Windows, incluyendo cuatro RCEs críticas. Los 16 entraron directamente en el ciclo del Patch Tuesday de mayo de 2026.
El pipeline tiene cinco etapas: Prepare, Scan, Validate, Dedup, Prove. Más de 100 agentes especializados corren en paralelo sobre un ensemble de modelos frontier y destilados. El sistema ingiere una codebase, construye índices con consciencia de lenguaje, extrae modelos de amenaza del historial de commits, corre agentes auditores especializados sobre caminos de código candidatos, deduplica hallazgos a través de debate entre agentes, y genera exploits proof-of-concept para los sobrevivientes.
En el benchmark público CyberGym—1.507 vulnerabilidades del mundo real—MDASH marcó 88.45%, liderando el placar por cinco puntos percentuales arriba de Claude Mythos Preview de Anthropic. Recall interna contra casos MSRC confirmados: 96% en clfs.sys en 28 casos durante cinco años; 100% en tcpip.sys en siete casos en el mismo período. En una prueba privada controlada con StorageDrive—una codebase que los modelos nunca habían visto públicamente—MDASH encontró las 21 vulnerabilidades plantadas con cero falsos positivos.
Dos hallazgos críticos que entraron en el Patch Tuesday: CVE-2026-33827, un use-after-free remoto no autenticado en tcpip.sys. Y CVE-2026-33824, un double-free en el servicio IKEv2 alcanzable por puerto UDP 500. Ambos críticos. Ambos encontrados antes de que un actor malicioso los encontrara.
La lección para el arquitecto no es "espera a que MDASH esté disponible en GA". Es sobre dónde invertir: en harness de orquestación. Validación en etapas, debate adversarial entre agentes, generación automatizada de proof-of-concept. Microsoft fue explícita: el sistema fue diseñado para sobrevivir a un swap de modelo sin reconstruir el harness. El modelo es reemplazable. El pipeline es el moat.
Y hay un tercer ángulo en esta historia de auditoría—dónde el costo de no auditar se volvió más concreto que cualquier CVE.
Una auditoría conducida por Stanford de 3,4 millones de candidatos filtrados por Pymetrics—ahora propiedad de Harver—reveló que el algoritmo de evaluación cognitiva de un solo vendor produjo impacto adverso racial mensurable a nivel de puesto individual. El estudio analizó 4 millones de aplicaciones en 1.700 posiciones y 150 empleadores.
El algoritmo dirigió 26% de las presentaciones de candidatos negros y 15% de presentaciones de candidatos asiáticos a posiciones donde el sistema discriminó contra su grupo, según la regla de los cuatro quintos de la EEOC.
Y el efecto de exclusión sistémica es matemático. Diez por ciento de los candidatos que envían cuatro aplicaciones son rechazados de las cuatro. Cuatro por ciento de los que aplican a diez posiciones son rechazados algorítmicamente de las diez. La probabilidad de exclusión total solo cae por debajo de 0,1% si un candidato aplica a 25 posiciones distintas.
El mecanismo que hace esto sistémico: Pymetrics almacena scores y los reutiliza a través de su red de empleadores por hasta 330 días. Un candidato que aplica a múltiples empresas no recibe evaluaciones independientes. El mismo score en cache es referenciado repetidamente. Cuarenta mil aplicaciones de minoría adicionales habrían avanzado a revisión humana bajo trato igualitario.
La parte que quiebra toda la narrativa de cumplimiento anterior: la auditoría agregada propia del vendor no encontró disparidades que llegaran a escrutinio legal. El promedio ocupacional diluye el sesgo entre familias de cargos. El análisis posición-a-posición de Stanford mostró 10.62% de cargos individuales con impacto adverso contra candidatos negros. El pool enmascaró lo que la posición-a-posición expuso.
Y eso no es un defecto de implementación. Es una falla de arquitectura de auditoría. La Ley Local 144 de Nueva York explícitamente permite auditorías en pool—el método que enmascaró el sesgo en este caso. La mayoría de los vendors de filtrado de terceros no tienen obligación de medir persistencia de scores entre empleadores como riesgo de concentración.
La escala de mercado transforma eso en riesgo sistémico. Sesenta por ciento o más del Fortune 100 y ocho de los diez principales órganos federales de los EE.UU. ejecutan filtrado a través del HireVue solo. Decisiones correlacionadas, determinísticas, propagadas a través de instituciones desde un conjunto restringido de modelos compartidos. Un solo edge case de puntuación puede poner a un candidato en lista negra en toda una red. La fecha límite de cumplimiento de la Ley de IA de la UE para herramientas de contratación cae el 2 de agosto de 2026—y el estudio argumenta que los frameworks actuales aún carecen de mandatos de impacto adverso por posición, vigilancia de mercado entre empleadores, y caminos legales para acceso independiente de investigadores a datos de vendors.
Lo que conecta esta historia al primer segmento: si no tienes un framework de auditoría estadística corriendo hoy—sobre tus agentes de código, sobre tus sistemas de filtrado, sobre tus workflows de decisión—el regulador, el periodista, o el cliente lo ejecutará por ti.
Y la factura es mayor que la factura de token.
Costo, soberanía, auditoría. No son tres conversaciones para agendar en tres reuniones separadas. Es una decisión de arquitectura. Y la estás tomando—quieras que lo sepas o no.
La semana en que la factura llegó no fue sobre un número—fue sobre la ausencia de un método para leerla. Tokens sin KPI, silicio sin observabilidad, agentes sin garantía estadística. El trabajo para la próxima semana: elige cuál de las tres capas instrumentalizarás primero. Wire Wednesday—abrimos con el GPIC, el corpus abierto de 28 billones de píxeles que acaba de jubilar a ImageNet como estándar de entrenamiento. Buen trabajo.