Según informes, un proyecto interno de Amazon que utiliza Claude Sonnet de Anthropic acumuló una factura de 1,8 millones de dólares, superan...
Según se ha informado, un proyecto interno de Amazon que utilizaba Anthropic Claude Sonnet acumuló una factura de 1,8 millones de dólares, superando el presupuesto planificado en un 860%, sin ser detectado durante cinco meses, y finalmente nunca llegó a implementarse.
La tarea en sí parecía bastante rutinaria: cotejar información de autores con listados de productos en la plataforma de comercio electrónico de Amazon.
El caso salió a la luz después de que el Financial Times informara de que un ingeniero senior de Amazon había debatido múltiples incidentes de sobrecostos relacionados con IA en una reunión interna de empleados. Sirve como advertencia útil para cualquier organización que pase de usar chatbots ocasionalmente a flujos de trabajo automatizados que pueden generar miles o millones de llamadas de pago al modelo cada día.
Los defectos del software tradicional suelen desperdiciar horas de ingeniería o producir salidas erróneas. Los defectos en flujos de trabajo de IA medidos por uso pueden hacer ambas cosas a la vez, y seguir generando gastos en tokens, herramientas, almacenamiento y cómputo cada minuto que permanecen activos.
La lección no es que las empresas deban dejar de usar IA, sino que los procesos de IA autónomos o de alto volumen necesitan controles financieros tan claros como sus controles de seguridad y calidad.
Según personas familiarizadas con el asunto, Amazon utilizó Claude Sonnet en un proyecto destinado a cotejar información de autores con listados de productos en su plataforma minorista.
Según los informes, el despliegue:
Ingenieros senior describieron algunos errores de codificación relacionados con IA como "catastróficamente caros".
Amazon respondió que están experimentando, aprendiendo y mejorando su forma de utilizar la tecnología, incluida la gestión de la eficiencia de costes. La compañía también afirmó que presentar unos pocos casos aislados como práctica habitual no refleja con precisión el uso de la IA en la organización más amplia de Amazon.
Ambas afirmaciones pueden ser ciertas.
Estos incidentes pueden afectar solo a una pequeña parte de los equipos de Amazon, pero también revelan un problema de control que otras organizaciones deberían tomarse en serio.
El informe original en chino atribuía el sobrecosto a un programa sin límite de frecuencia de llamadas que enviaba solicitudes de forma continua en un bucle.
Esta explicación es plausible, pero aún no ha sido confirmada por los informes públicos actuales.
El Financial Times describió errores de codificación, controles de gasto deficientes y detección tardía. No publicó un análisis post-mortem técnico que mostrara:
La conclusión más segura es más prudente: un despliegue fallido de Claude Sonnet generó una factura enorme, y los sistemas de control de Amazon no detectaron el problema durante cinco meses.
A menos que Amazon publique un informe técnico del incidente, cualquier explicación más detallada debe considerarse especulativa.
Sobrecostes
Según se informa, el mismo informe interno también abordó al menos otros dos casos.
| Proyecto | Coste no previsto según informes |
|---|---|
| Herramienta de auditoría financiera | Aproximadamente 541.000 dólares |
| Proyecto logístico destinado a mejorar la velocidad de entrega | Aproximadamente 134.000 dólares |
Según se informa, el sobrecoste logístico tardó más de dos semanas en detectarse.
Estos casos son de menor escala que el proyecto de cotejo de autores de 1,8 millones de dólares, pero apuntan al mismo patrón: cuando ningún fallo técnico obliga a detener el proceso, los sistemas de IA basados en uso pueden seguir acumulando costes.
Los trabajos por lotes tradicionales pueden fallar, agotar la memoria o no superar las pruebas.
Los procesos de IA pueden permanecer técnicamente saludables mientras ya están económicamente en quiebra.
Incluso cuando un proyecto ya no produce resultados útiles, puede seguir recibiendo respuestas exitosas de la API, escribiendo registros, llamando a herramientas, reintentando tareas o procesando registros de bajo valor.
Los costes de las aplicaciones tradicionales suelen estar vinculados a unidades relativamente conocidas:
Los flujos de trabajo de IA pueden acumular simultáneamente múltiples niveles de facturación por uso:
Esto produce un efecto multiplicador.
Supongamos que una tarea envía un prompt muy largo, genera una respuesta extensa, llama a dos herramientas, reintenta tras un error y pasa el historial completo a la siguiente ronda. Si la aplicación procesa millones de registros, un pequeño error de diseño puede volverse extremadamente costoso.
Desde una perspectiva operativa, la aplicación puede parecer normal. Las solicitudes siguen devolviendo 200 OK. Los procesos de trabajo siguen activos. Las colas se reducen continuamente. La factura suele ser el primer lugar donde aparece el problema.
Antes de lanzar un proceso de IA automatizado, calcule primero el coste por cada tarea de negocio completada.
Un modelo simplificado sería el siguiente:
| Componente de coste | Cálculo |
|---|---|
| Coste de entrada | Tokens de entrada × Precio de entrada del modelo |
| Coste de salida | Tokens de salida × Precio de salida del modelo |
| Coste de herramientas | Número de llamadas a herramientas × Precio de la herramienta |
| Coste de reintentos | Número de intentos fallidos o repetidos × Coste medio por intento |
| Coste de infraestructura | Cómputo, almacenamiento, base de datos, red y registros |
| Coste de revisión humana | Tiempo de revisión × Tarifa combinada que incluye coste laboral |
La métrica clave no es solo el coste por token.
Sino:
Coste total por resultado de negocio completado con éxito
Una solicitud más barata con una tasa de fallos más alta, que requiera llamadas repetidas o genere más revisión humana, puede seguir produciendo un flujo de trabajo más caro.
Del mismo modo, un modelo más potente que complete la tarea en menos pasos puede resultar más barato en términos globales.
Cada flujo de trabajo de IA en producción debe tener un responsable designado que supervise tanto el comportamiento técnico como el gasto.
Ese responsable debe conocer:
Cuando un único trabajador puede emitir solicitudes de forma continua, los presupuestos vagos a nivel de proyecto no son suficientes.
Los presupuestos deben existir en múltiples niveles:
| Nivel | Ejemplo |
|---|---|
| Organización | Límite mensual de gasto en IA |
| Equipo | Cuota mensual de una unidad de negocio |
| Aplicación | Presupuesto de un producto o flujo de trabajo |
| Entorno | Límites separados para desarrollo, preproducción y producción |
| Trabajo | Coste máximo de un lote |
| Usuario o inquilino | Cuota de uso por cliente |
| Sesión de agente | Máximo de tokens, pasos, herramientas y tiempo |
Los niveles más bajos proporcionan el mecanismo de frenado más rápido y eficaz.
Las alertas de facturación en la nube son importantes, pero no sustituyen a los controles a nivel de aplicación.
La aplicación debe detenerse o requerir aprobación al alcanzar los límites establecidos.
Los límites útiles incluyen:
Estos controles deben estar desactivados por defecto.
Si el servicio de seguimiento de costes no está disponible, o la aplicación no puede determinar el presupuesto restante, el comportamiento más seguro suele ser pausar en lugar de continuar indefinidamente.
Los agentes autónomos no deben controlar su propia autoridad final de gasto.
Un servicio independiente debe poder:
Incluso si el agente entra en un bucle de reintentos o produce mensajes de estado engañosos, el interruptor de emergencia debe seguir disponible.
Pruébelo antes de producción.
Los controles que nunca se han utilizado son solo teoría.
Las organizaciones que utilizan Amazon Bedrock pueden habilitar el registro de llamadas al modelo para las invocaciones compatibles de bedrock-runtime.
AWS indica que estos registros pueden incluir datos de solicitud y respuesta, metadatos, identificadores de modelo, identificadores de solicitud, información de identidad y uso de tokens. Los destinos de registro pueden incluir Amazon CloudWatch Logs y Amazon S3.
El registro de invocaciones está desactivado por defecto.
El equipo debe habilitar únicamente los datos necesarios para la observabilidad y aplicar controles adecuados de privacidad, seguridad, retención y enmascaramiento. Los prompts y las salidas pueden contener información sensible de la empresa o de los clientes.
Como mínimo, los registros de seguimiento de costos deben incluir:
De esta manera, la facturación puede asociarse con tareas específicas, en lugar de descubrir un total general enorme durante la revisión financiera mensual.
AWS Budgets puede rastrear costos o uso en relación con umbrales establecidos y enviar notificaciones. Las acciones de presupuesto también pueden aplicar controles, como políticas de IAM o políticas de control de servicios, cuando se superan los umbrales. Según la configuración, las acciones pueden ejecutarse automáticamente o esperar la aprobación humana.
Un detalle importante específico de AWS es fácil de pasar por alto.
La documentación de AWS Cost Anomaly Detection indica que este servicio no monitorea productos de terceros vendidos a través de AWS Marketplace, incluidos los modelos de lenguaje de terceros ofrecidos a través de Amazon Bedrock, como Anthropic Claude.
Estos costos siguen apareciendo en Cost Explorer y en la facturación, pero AWS recomienda usar AWS Budgets para alertar sobre este tipo de gastos.
Los presupuestos pueden usar filtros de entidad de facturación para rastrear con mayor precisión los cargos de Marketplace.
Este es exactamente el tipo de detalle de configuración que puede generar una falsa sensación de seguridad. Una empresa podría habilitar la detección de anomalías y asumir que todos los costos de modelos están cubiertos, cuando una categoría de facturación específica no está incluida.
La documentación de AWS indica que el estado de los presupuestos se actualiza varias veces al día.
La documentación también advierte que los costos pueden seguir aumentando antes o después de que se entregue la notificación.
Esto significa que AWS Budgets es útil para la gobernanza financiera, pero por sí solo puede no detener lo suficientemente rápido a un agente de alto rendimiento.
La pila de control debe incluir:
Cuanto más rápido gaste dinero un flujo de trabajo, más cerca del punto de invocación deben estar los controles.
AWS Cost Anomaly Detection utiliza modelos de aprendizaje automático para identificar patrones de gasto anómalos y ayudar a localizar posibles causas raíz.
AWS indica que este servicio evalúa aproximadamente tres veces al día los datos de facturación procesados.
Puede detectar de manera efectiva crecimientos inesperados en servicios de AWS, cuentas, regiones, tipos de uso y etiquetas de asignación de costos.
Para sistemas de IA, puede identificar anomalías en costos de soporte relacionados con cómputo, almacenamiento, bases de datos o red.
Sin embargo, los equipos deben recordar la limitación de Marketplace mencionada anteriormente y crear AWS Budgets por separado para los costos de modelos de terceros cuando sea necesario.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
Amazon Bedrock aplica cuotas de servicio para la inferencia de modelos, incluidos límites basados en tokens para modelos y endpoints compatibles.
Las cuotas pueden prevenir un rendimiento ilimitado, pero no están diseñadas para ser presupuestos financieros precisos.
Las cuotas aún pueden permitir gastos muy superiores a los límites proyectados del proyecto. Por el contrario, aumentar las cuotas para resolver problemas de capacidad de producción puede eliminar involuntariamente un límite de seguridad útil.
Por lo tanto, los cambios de cuota deben requerir:
Los límites de velocidad y tokens deben considerarse parte del diseño de riesgo del sistema, no solo obstáculos para la escalabilidad.
Para aplicaciones que llaman directamente a Anthropic, la consola de Anthropic proporciona informes de costos y uso.
Los límites de API de Anthropic pueden incluir solicitudes por minuto, tokens de entrada por minuto, tokens de salida por minuto y límites de gasto relacionados con el nivel de uso.
Estos límites pueden reducir el rendimiento no controlado, pero deben complementarse con controles a nivel de aplicación.
Las organizaciones con múltiples equipos también pueden implementar una puerta de enlace de LLM entre las aplicaciones y el proveedor de modelos. La puerta de enlace puede centralizar autenticación, seguimiento de uso, presupuestos, límites de velocidad, enrutamiento de modelos y registros de auditoría.
La puerta de enlace se convierte en un componente de seguridad crítico, por lo que debe operarse y revisarse con el mismo cuidado que cualquier otra capa de acceso de producción.
Según informes, un proyecto de Amazon intentó ejecutar una tarea de coincidencia de datos a gran escala.
Un patrón de despliegue más seguro es:
No inferir basándose únicamente en el registro promedio.
Los documentos más largos, los registros que fallan al coincidir, los casos ambiguos, los reintentos y los bucles de agentes suelen dominar el costo total.
Usar estimaciones por percentiles, como los costos P50, P95 y P99 por tarea.
El flujo de trabajo debe detenerse cuando las llamadas adicionales al modelo ya no sean económicamente razonables.
Para un sistema de coincidencia de autores, métricas útiles pueden incluir:
Un proceso que cuesta $0.02 por solicitud parece barato.
Si requiere 50 llamadas, la mitad de los registros falla y el resto se envía a revisión manual, la economía real puede ser muy deficiente.
No todos los registros necesitan un modelo de vanguardia.
Una canalización consciente de los costos puede usar:
Para proyectos de coincidencia de datos, el software tradicional puede resolver la mayoría de los casos a menor costo y de manera más determinista.
Los LLM deben usarse solo cuando la ambigüedad lingüística realmente lo requiera, no aplicarse automáticamente a cada línea.
La propia guía de precios de Anthropic recomienda elegir el modelo adecuado, usar caché de prompts para contextos repetidos, emplear procesamiento por lotes para trabajos no urgentes y monitorear los patrones de uso.
Los reintentos son una fuente común de gasto oculto.
Una solicitud fallida puede ser reintentada por la aplicación, el sistema de colas, el SDK, la puerta de enlace, el administrador de trabajadores, el agente o el orquestador del flujo de trabajo.
Cuando múltiples capas reintentan de forma independiente, una tarea lógica puede generar múltiples solicitudes pagadas.
Definir una política de reintentos unificada que incluya:
Los errores no deben crear bucles económicos infinitos.
Los scripts de prueba no deben heredar límites de nivel de producción.
Usar cuentas o espacios de trabajo independientes, claves de API, roles de IAM, presupuestos, cuotas, registros, fuentes de datos y permisos de red.
Los entornos de desarrollo deben tener límites de gasto deliberadamente bajos.
Un prototipo que entra accidentalmente en un bucle debería fallar con una factura pequeña, no obtener cuotas de producción de nivel empresarial.
El incidente involucró un proyecto asistido por IA, pero el problema clave no es si el código fue generado por un modelo.
Lo importante es si el código puede gastar dinero.
Cualquier componente que pueda iniciar solicitudes pagadas a modelos debe someterse a revisión de:
Las pruebas unitarias deben incluir escenarios de fallo económico.
Ejemplos: el modelo nunca devuelve una respuesta válida, entrega repetida de tareas, el proceso de trabajo se bloquea después de una llamada pagada, errores recurrentes de límite de velocidad, el contexto crece con las salidas de herramientas en cada turno y el servicio de estimación de costos no está disponible.
El camino normal funcionalmente correcto no es suficiente.
Un responsable técnico designado es responsable del gasto.
Se documentan el uso esperado y el costo por resultado exitoso.
[ ] Los entornos de desarrollo, preproducción y producción tienen presupuestos independientes.
Cada tarea tiene un máximo de solicitudes, tokens, pasos, reintentos y tiempo de ejecución.
Cada sesión de agente tiene un presupuesto en dólares estadounidenses.
Los servicios que no son agentes pueden detener el flujo de trabajo.
Las tareas se pausan cuando no se puede leer el presupuesto restante.
Se evita el trabajo duplicado mediante la idempotencia.
Cada llamada al modelo se atribuye a un equipo, proyecto, usuario y tarea.
Se registra el uso de entradas, salidas, caché, herramientas y reintentos.
Se configuran alertas tanto para la tasa de gasto como para el gasto total.
Se habilita una revisión diaria durante el lanzamiento inicial en producción.
El equipo comprende los elementos de costo no cubiertos por la detección de anomalías.
El costo se mide por cada resultado comercial exitoso.
Se utilizan código convencional y modelos más pequeños cuando corresponde.
Se han probado los costos en el peor de los casos y en percentiles altos.
Se incluyen los costos de revisión humana.
El flujo de trabajo se detiene cuando las llamadas adicionales ya no aportan valor.
El código generado por IA se somete a revisión humana.
Los aumentos de presupuesto y cuotas requieren aprobación.
El interruptor de emergencia se prueba periódicamente.
La respuesta a incidentes incluye a las partes interesadas financieras y técnicas.
El equipo revisa el gasto después de cada cambio importante en el modelo o en el mensaje.
Se informa que los ingenieros de Amazon están construyendo salvaguardas automatizadas para futuros proyectos de IA.
Esa es la dirección correcta, pero la automatización debe existir en múltiples niveles.
Un sistema de control maduro debería combinar límites duros en la aplicación, límites del modelo y de la puerta de enlace, presupuestos de nube, acciones automatizadas, registros de uso, paneles financieros, aprobaciones humanas y revisiones periódicas.
La compañía también eliminó anteriormente una tabla de clasificación interna que alentaba a los empleados a maximizar el uso de su herramienta de desarrollo Kiro. Según el Financial Times, esa tabla fomentaba el "tokenmaxxing", un fenómeno en el que los empleados aumentaban el consumo de tokens para mejorar su posición.
Este es un recordatorio útil: los incentivos pueden socavar el control de costos.
Si los empleados son recompensados por usar más IA en lugar de generar valor comercial medible, el uso aumentará incluso sin mejoras en los resultados.
Las organizaciones deberían recompensar los problemas resueltos, las mejoras de calidad, el tiempo ahorrado, los ingresos generados, el riesgo reducido y la disminución del costo por unidad de producción.
La cantidad de tokens es una métrica de entrada, no una métrica de productividad.
El Financial Times informó que un proyecto interno de Amazon que usaba Claude Sonnet acumuló una factura de $1,8 millones. El proyecto, destinado a hacer coincidir información de autores con listados de comercio electrónico, superó el presupuesto en un 860% y no llegó a implementarse.
Los informes públicos indican que Amazon carecía de controles de gasto suficientes y que los errores de codificación fueron uno de los factores que contribuyeron al problema. Amazon no ha publicado un análisis post-mortem técnico para identificar los defectos específicos o las fallas de monitoreo.
Esa explicación apareció en algunos informes secundarios, pero no ha sido confirmada en los informes principales. La cantidad exacta de solicitudes, la lógica de reintentos, el volumen de tokens y los defectos del código fuente siguen sin divulgarse.
Sí. Se informa que la misma presentación interna también incluía costos inesperados de aproximadamente $541.000 en un proyecto de auditoría financiera y $134.000 en un proyecto de logística.
La documentación de AWS indica que Cost Anomaly Detection no supervisa los productos de terceros de AWS Marketplace, incluidos los modelos Anthropic Claude en Bedrock. AWS recomienda usar AWS Budgets para gestionar estos costos y, cuando corresponda, los filtros de entidad de facturación.
Por sí solo, no. AWS indica que la información de presupuesto se actualiza varias veces al día y que los costos pueden seguir aumentando antes o después del período de notificación. Las aplicaciones de alto tráfico necesitan límites duros a nivel de solicitud e interruptores de emergencia independientes.
No. Los límites de velocidad controlan el rendimiento, mientras que los presupuestos controlan el costo aceptable. Un flujo de trabajo puede funcionar dentro de los límites de velocidad y, aun así, superar ampliamente el gasto planificado durante semanas o meses.
Establecer un presupuesto duro por cada sesión de agente que incluya solicitudes, tokens, herramientas, reintentos y tiempo. Aplicar ese presupuesto fuera del agente y contar con un método probado para detener el flujo de trabajo de inmediato.
com/bedrock/latest/userguide/model-invocation-logging.html): Guía oficial de configuración y manejo de datos para el registro de invocaciones de modelos en Bedrock.
Según informes, un proyecto interno de Amazon que usaba Claude Sonnet gastó 1.8 millones de dólares, superando el presupuesto en un 860%, sin ser detectado durante cinco meses y sin llegar nunca a implementarse. Según informes, otros proyectos de IA generaron gastos inesperados de cientos de miles de dólares.
Los registros públicos no confirman que el evento principal fuera causado por un bucle infinito de solicitudes. Lo que los registros confirman es la brecha entre la velocidad de gasto de los flujos de trabajo de IA y la velocidad a la que las organizaciones detectan problemas.
Las empresas deberían combinar el seguimiento de solicitudes individuales, presupuestos a nivel de trabajo, límites de tokens y herramientas, reintentos controlados, enrutamiento de modelos, presupuestos en la nube, acciones automatizadas y un interruptor de emergencia que los agentes no puedan anular.
**
La regla más segura es simple: ningún proceso de IA debería ejecutarse durante cinco meses sin demostrar repetidamente que sigue siendo útil, está dentro del presupuesto y está autorizado para continuar.
Empieza con una sola frase y obtén un sitio completo en minutos.
