Una reunión el 28 de julio y una cifra que nadie quería

El 28 de julio, ingenieros senior de Amazon informaron a sus compañeros de lo ocurrido con una serie de proyectos internos de IA. El Financial Times publicó el contenido. Un proyecto había estado usando Claude Sonnet, de Anthropic, para cruzar datos de autores con fichas de comercio electrónico. Gastó 1,8 millones de dólares. Se fue un 860 por ciento por encima del presupuesto. Corrió cinco meses antes de que nadie lo detectara, y nunca llegó a producción. Un equipo describió el patrón como catastróficamente caro.

Vinieron dos casos menores. Una herramienta de auditoría financiera se pasó en unos 541.000 dólares. Un proyecto de logística quedó unos 134.000 dólares por encima del plan. Un empleado senior de Amazon resumió el problema de fondo al FT en una frase: es difícil averiguar cuánto cuesta cualquier cosa relacionada con la IA. Amazon ha respondido que está experimentando, aprendiendo y mejorando cómo usa la tecnología, ha calificado los ejemplos de escogidos a conveniencia, y está introduciendo revisiones obligatorias entre pares y topes de gasto en los proyectos de IA.

Empiece por la aritmética, porque nadie la publicó. Si 1,8 millones de dólares representan un desvío del 860 por ciento, el presupuesto aprobado rondaba los 190.000 dólares. Esa es la cifra que un control debería haber defendido.

Dos meses antes, el mismo error llevaba otro disfraz

El 29 de mayo Amazon cerró KiroRank, un ranking interno en su plataforma de desarrollo Kiro que ordenaba a la plantilla por los tokens de IA consumidos. Se había montado para impulsar la adopción. Lo que impulsó fue una práctica que los empleados llamaron tokenmaxxing: apuntar agentes a trabajo que nadie necesitaba para que la clasificación se moviera. Dave Treadwell, vicepresidente senior, escribió a la plantilla en un memorando que el ranking se había construido con buenas intenciones y pidió que no se usara IA por el mero hecho de usar IA.

Lea los dos episodios como uno. En mayo Amazon premió el consumo y recibió consumo. En julio descubrió consumo que nadie había autorizado y nadie había leído. El ranking y el trabajo desbocado no son fallos de disciplina separados; son la misma brecha, que es que la organización tenía un contador en marcha y ninguna costumbre de mirarlo.

La instrucción está en el reemplazo, no en el cierre. Amazon no se limitó a borrar el ranking. Sustituyó la métrica por despliegues normalizados, que cuentan el código asistido por IA que de verdad llega a producción.

Por qué un fallo tarifado permanece invisible

El software convencional anuncia sus propios fallos. Un bucle defectuoso agota la memoria y el proceso muere, una página agota su tiempo, salta una alerta y alguien recibe un aviso a las tres de la madrugada. Una llamada a modelo mal configurada no hace nada de eso. Tiene éxito. Devuelve una respuesta, cobra los tokens y da otra vuelta. No hay caída que detectar porque, desde el punto de vista de la plataforma, nada salió mal, y esa es exactamente la condición en la que pueden pasar cinco meses.

Tres cosas estiran después la ventana de detección. La facturación es mensual, así que finanzas ve la forma de un problema semanas después del gasto, y la ve agregada. El precio es por token, de modo que el coste escala con el volumen y no con el número de instancias, que es el eje para el que se construyó la mayoría de la alerta de infraestructura. Y los agentes multiplican los tokens, porque un bucle agéntico hace muchas llamadas al modelo donde una interfaz de chat hace una.

Para un operador europeo la consecuencia es la misma sea cual sea la región: el contador corre en la cuenta de nube, la factura llega en ciclo mensual, y nada intermedio le dice que el trabajo dejó de ser útil en marzo.

Los controles existían y no estaban activados

Esta es la parte incómoda de la historia, y es la razón por la que pertenece a una columna de decisiones y no a una de tecnología. Las mitigaciones estuvieron disponibles en la plataforma todo el tiempo. AWS publica inferencia por lotes a la mitad del precio por token de la modalidad bajo demanda para trabajo que no necesita respuesta inmediata, que es exactamente el perfil de un cruce en segundo plano de cinco meses. Ofrece caché de instrucciones para que un contexto repetido no se pague a tarifa completa en cada llamada. Ofrece niveles de modelo más baratos y enrutado entre ellos. Nada de eso es exótico y nada requería negociación.

Un trabajo que corrió cinco meses sin que se necesitara una respuesta con urgencia es la carga por lotes de manual. Ejecutarlo bajo demanda no es un fallo técnico, es una decisión que nadie llegó a plantear, porque la persona que configuró el trabajo no era la persona que veía la factura.

Diseñe contra esa separación. Quien pueda lanzar un trabajo tarifado debería ver su coste acumulado en la misma interfaz donde lo lanza.

Cuatro controles antes de que salga su próximo agente

Fije un techo firme por trabajo, no por cuenta. Una alerta de presupuesto a nivel de cuenta le dice que el total se movió; no le dice qué trabajo lo movió, y para cuando salta un presupuesto de cuenta los cinco meses ya han ocurrido. Segundo, exija una respuesta explícita a una pregunta en la aprobación: esto hay que responderlo ahora? Si la respuesta es no, es una carga por lotes y debe tarificarse como tal.

Tercero, ponga caducidad a todo trabajo de larga duración. Una tarea de cruce que lleva corriendo desde marzo debería haber necesitado que un humano la renovara en abril. Cuarto, mida el resultado. Si la puntuación de un proyecto es el trabajo asistido por IA que llegó a producción, entonces un despliegue que nunca llegó puntúa cero por muchos tokens que haya consumido, y habría aflorado en la primera revisión mensual y no en la quinta.

Leer a continuación: Amazon recorta su AGI pese a 200 mil millones en IA  |  Sus datos revisados por humanos ya eran medio máquina