Sábado por la mañana. Tu teléfono vibra. Luego otra vez. Luego 47 veces. Entrecierras los ojos ante la pantalla —$12,000 en cargos de LLM API desde las 3 am. Alguien de tu equipo subió una clave de API a un repositorio público de GitHub a las 11 pm del viernes por la noche. Para cuando AWS marcó la anomalía, la clave estaba ejecutando inferencia de minería de criptomonedas en tres regiones. No eres el primer desarrollador al que le pasa esto. Ni siquiera eres el centésimo.
En 2025–2026, los errores de LLM API les costaron a los equipos de ingeniería más de $500 millones. Un equipo sin failover estuvo caído 47 minutos durante una interrupción de OpenAI —cada request golpeaba exactamente un endpoint. El presupuesto “ilimitado” de evaluación de una startup consumió silenciosamente $3,200 en un fin de semana por un script de eval que nunca dejó de hacer loop. Ninguno de estos es hipotético. Todos eran prevenibles, usualmente con un solo cambio de configuración.
Este artículo es un checklist, no un tutorial. Cada uno de los 23 errores incluye: lo que pasó (incidente real), la solución (una frase) y dónde encontrar la guía de implementación completa. Varios mapean directamente al OWASP Top 10 para aplicaciones de LLM —el framework estándar de la industria para los riesgos de seguridad de LLM. Imprime el checklist al final. Pégalo en tu monitor.
Errores de seguridad (1–5)
1. Claves de API hardcodeadas en el código fuente.
Incidente real: en junio de 2025, un paquete de PyPI comprometido en la cadena de suministro de LiteLLM extrajo claves de API de 95 millones de instalaciones mensuales. Las claves en archivos .env, archivos de configuración y código fuente eran todas vulnerables.
Solución: guarda las claves en una bóveda de secretos (AWS Secrets Manager, HashiCorp Vault, Doppler). Inyéctalas en tiempo de ejecución. Nunca en tiempo de build.
Implementación completa —mejores prácticas de seguridad de LLM API
2. Una sola clave de API compartida en todos los entornos. Solución: claves separadas por entorno (dev/staging/prod) con allowlists de modelos y límites de presupuesto por clave. Una clave de desarrollo comprometida no debería acceder a modelos de producción.
3. Sin límites de presupuesto en las claves de API. Incidente real: en marzo de 2026, una empresa quemó $500 millones en un mes por una clave de API sin tope de gasto. Solución: establece topes duros de presupuesto tanto a nivel de proveedor como de plataforma. Alerta al 80%. Rechazo duro al 100%.
4. Claves expuestas en código del lado del cliente. Solución: enruta todas las llamadas LLM a través de tu backend. Las claves de API de los proveedores nunca viajan a navegadores ni apps móviles. Usa claves virtuales de vida corta para la autenticación del cliente.
5. Sin cronograma de rotación de claves. Solución: rota las claves cada 90 días. Inmediatamente cuando un miembro del equipo se va o hay sospecha de exposición. Rotación blue/green: genera una clave nueva —despliega junto a la anterior— monitorea —revoca la anterior.
El hilo que une las cinco: las claves de API son credenciales de nivel cero. Adminístralas con el mismo rigor que aplicas al IAM en la nube —bóvedas, rotación, privilegio mínimo y topes duros.
Errores de costo (6–10)
6. Usar GPT-5.5 para todo. Dato real: $875/mes (todo con GPT-5.5) —$39.50/mes (DeepSeek V4 Flash para tareas simples + Claude Sonnet para complejas). 95% de ahorro. Cero pérdida de calidad para los usuarios finales. Solución: divide tus modelos en niveles. Tareas simples —modelos baratos. Tareas complejas —modelos frontera. Implementación completa —estrategias de optimización de costos
7. Ignorar los costos de los reasoning tokens.
Incidente real: un equipo migró su bot de soporte a un modelo de razonamiento en agosto de 2025. Su costo diario se cuadruplicó de la noche a la mañana —el mismo prompt, el mismo tráfico, la misma experiencia de usuario final. El culpable: aproximadamente 3,200 reasoning tokens invisibles por query, facturados a la tarifa de salida, que nunca aparecieron en su dashboard de uso.
Solución: monitorea reasoning_tokens en las respuestas de API. Estos tokens invisibles se facturan a la tarifa de salida y pueden multiplicar tu costo efectivo por 2–5. Establece límites de presupuesto de reasoning.
8. No usar prompt caching. Solución: cachea los system prompts, las definiciones de herramientas y los ejemplos few-shot. Anthropic: 90% de descuento en input cacheado. DeepSeek: $0.0036/M en cache hits. OpenAI: 50% de descuento. Implementación completa —guía de prompt caching
9. No usar batch API para trabajo offline. Solución: OpenAI, Anthropic y Google ofrecen ~50% de descuento para procesamiento batch asíncrono (entrega en 24 horas). Todo workload que no sea en tiempo real debería usar batch.
10. Sin seguimiento de costos por usuario. Solución: crea claves de API virtuales por usuario o por funcionalidad. Atribuye cada llamada de API a un usuario específico. Cuando los costos se disparan, sabes exactamente por qué.
El patrón común: los costos de LLM son costos de consumo, no infraestructura fija. Cada llamada sin medir, cada prompt sin cachear, cada modelo frontera innecesario se acumula. Trata tu factura de API como una factura de nube —mide todo, segmenta todo, procesa todo por lotes.
Errores de confiabilidad (11–15)
11. Sin modelo de fallback configurado. Solución: cadena de fallback try/except de dos líneas. El modelo primario falla —automáticamente prueba el respaldo. Implementación completa —guía de manejo de rate limits
12. Ignorar los headers de rate limit.
Solución: lee x-ratelimit-remaining-* en cada respuesta 200. Muestra el presupuesto restante como un indicador. Alerta a <20%. Reduce la velocidad a <10%.
13. Sin lógica de reintento con backoff exponencial.
Solución: backoff exponencial + jitter aleatorio. Nunca reintentos a intervalo fijo —crean thundering herds que garantizan más 429. Usa tenacity (Python) o llm-retry-kit (Node.js).
14. Usar aliases de modelos en vez de IDs fechados.
Incidente real: el clasificador de transacciones de un equipo fintech se rompió silenciosamente cuando su proveedor actualizó un alias de modelo a un snapshot nuevo. La actualización cambió el orden de los campos JSON en cada respuesta. Tres horas de transacciones mal clasificadas y $4,600 en reversiones de procesamiento de pagos antes de que el ingeniero de guardia lo detectara.
Solución: fija IDs de modelo fechados (gpt-5.5-2025-06-15). Aliases como gpt-5.5 se actualizan silenciosamente a snapshots nuevos que pueden cambiar el comportamiento de tu prompt inesperadamente.
15. Sin circuit breaker. Solución: deja de enrutar hacia los proveedores que fallan consistentemente. Prueba después de un período de enfriamiento. Máquina de estados simple: closed —open (tras N fallos) —half-open (prueba) —closed (si la prueba tiene éxito).
La conclusión: las LLM APIs fallan de maneras predecibles —rate limits, interrupciones de proveedores, cambios de modelos silenciosos. Una configuración de un solo endpoint y un solo modelo es frágil por diseño. El fallback, el backoff y el circuit breaker convierten una dependencia frágil en una resiliente.
Errores de calidad (16–19)
16. Sin system prompt. Solución: un system prompt define el comportamiento. Sin uno, el modelo adivina lo que quieres. “Eres un revisor de código. Concéntrate en vulnerabilidades de seguridad y problemas de rendimiento” es 100x más efectivo que no tener system prompt.
17. Temperature = 0 para tareas creativas. Solución: guía de temperature: código = 0–0.3, chat = 0.7–1.0, escritura creativa = 1.0+. Ejecutar tareas creativas con temperature=0 produce output robótico y repetitivo.
18. Ignorar los límites de tokens en conversaciones largas.
Solución: rastrea los tokens totales en el array de mensajes. Cuando te acerques al límite de contexto del modelo, recorta los mensajes antiguos o resúmelos. Nunca dejes silenciosamente que la API devuelva un error context_length_exceeded.
19. No validar los outputs estructurados.
Incidente real: un pipeline de facturación asumió que amount siempre sería un número. Una respuesta malformada del LLM devolvió amount: "null" como string. El procesador de pagos aguas abajo lo interpretó como cero dólares. 47 facturas de clientes salieron por $0 antes de que alguien señalara el error.
Solución: valida siempre el schema JSON de las respuestas antes de actuar. Incluso con Structured Outputs habilitado, valida —captura casos límite y te da un mensaje de error claro en vez de una falla en cascada aguas abajo.
La calidad no es magia —es configuración. Un system prompt, la temperature correcta, conciencia de tokens y validación de outputs son cuatro perillas que no cuestan nada configurarlas bien, pero degradan silenciosamente tu producto cuando se ignoran.
Errores de arquitectura (20–23)
20. Vendor lock-in por diseño.
Solución: usa el patrón del SDK de OpenAI con un base_url configurable. Tu elección de proveedor es una decisión de configuración, no de arquitectura.
Ejemplo completo —patrón de routing multi-modelo
21. Llamadas síncronas para tareas independientes.
Solución: diez queries independientes = diez llamadas de API paralelas, no diez secuenciales. asyncio.gather en Python, Promise.all en Node. Tu latencia baja de 20 segundos a 2 segundos.
22. Sin observabilidad. Solución: registra cada llamada de API con schema unificado: timestamp, modelo, tokens, costo, latencia, ID de usuario. Cuando tu CFO pregunte por la factura de API, respondes en 30 segundos en vez de 3 horas.
23. Gestionar proveedores en vez de usar agregación. Solución: una clave de API. Un endpoint. Fallback integrado, seguimiento de costos integrado, gestión de rate limits integrada. Deja de gastar 8–12 horas/mes en mantenimiento de dashboards de proveedores. Argumento completo —por qué los desarrolladores se están cambiando a la agregación
La lección de arquitectura: la integración de LLM API no es una funcionalidad —es infraestructura. Diseña para independencia de proveedores, ejecución paralela, observabilidad completa y una superficie de integración única desde el día uno. Agregar esto después cuesta 10x más que construirlo desde el inicio.
Checklist imprimible
| # | Error | Gravedad | Tiempo de arreglo | Análisis detallado |
|---|---|---|---|---|
| 1 | Claves de API hardcodeadas | Crítica | 30 min | [#18 Security] |
| 2 | Claves compartidas entre entornos | Alta | 15 min | [#18 Security] |
| 3 | Sin topes de presupuesto | Crítica | 5 min | [#18 Security] |
| 4 | Claves en el código del cliente | Alta | 1 hora | [#18 Security] |
| 5 | Sin rotación de claves | Media | 30 min | [#18 Security] |
| 6 | GPT-5.5 para todo | Alta | 10 min | [#15 Cost] |
| 7 | Ignorar los tokens de razonamiento | Media | 5 min | [#15 Cost] |
| 8 | No usar el prompt caching | Alta | 30 min | [#17 Caching] |
| 9 | No usar la API de batch | Media | 15 min | [#15 Cost] |
| 10 | Sin seguimiento de costos por usuario | Media | 1 hora | [#15 Cost] |
| 11 | Sin modelo de respaldo | Crítica | 10 min | [#16 Rate Limits] |
| 12 | Ignorar los encabezados de rate limit | Alta | 15 min | [#16 Rate Limits] |
| 13 | Sin backoff en los reintentos | Alta | 10 min | [#16 Rate Limits] |
| 14 | Usar alias de modelos | Media | 5 min | — |
| 15 | Sin circuit breaker | Media | 1 hora | [#16 Rate Limits] |
| 16 | Sin system prompt | Media | 5 min | — |
| 17 | Temperatura incorrecta | Baja | 1 min | — |
| 18 | Ignorar los límites de tokens | Media | 30 min | — |
| 19 | No validar las salidas | Alta | 15 min | [#14 Function Calling] |
| 20 | Bloqueo de proveedor | Media | 2 horas | [#12 Multi-Model] |
| 21 | Llamadas síncronas para tareas paralelas | Media | 30 min | [#12 Multi-Model] |
| 22 | Sin observabilidad | Alta | 2 horas | [#12 Multi-Model] |
| 23 | Gestionar proveedores manualmente | Media | 5 min | [#8 Why Switch] |
Cuenta tus ítems “aún no arreglados”. Prioriza: Critical —High —Medium. Arregla uno por día. En tres semanas, tu infraestructura de API está a nivel de producción. Imprime este checklist. Pégalo en tu monitor. Los veinte minutos que inviertas ahora auditando tu stack contra estos 23 ítems te ahorrarán la llamada que nadie quiere recibir —esa donde alguien te cuenta lo que acaba de hacer tu factura de API.
FAQ
¿Cuál es el error más costoso?
Sin tope de presupuesto (Error 3). Una configuración faltante puede costar millones. Una empresa perdió $500 millones en un mes por una clave sin tope. Establece topes duros en todos lados —nivel proveedor, nivel plataforma, nivel por clave. Implementación: Mejores Prácticas de Seguridad de LLM API.
¿Qué error es más fácil de arreglar con mayor ROI?
Usar GPT-5.5 para todo (Error 6). Cambia las tareas simples a DeepSeek V4 Flash o Gemini Flash. Reducción de costos del 70–95%. Diez minutos para implementar un router básico. Estrategia completa: 12 estrategias para recortar tu factura.
¿Cómo sé si mi equipo está cometiendo estos errores?
Recorre el checklist de arriba. Cada casilla sin marcar es un error que estás cometiendo ahora. Prioriza en este orden: Security —Cost —Reliability —Quality —Architecture. Un incidente de seguridad cuesta más de lo que ahorra cualquier optimización.
El incidente de $500 millones no fue un ataque sofisticado. Fue una configuración faltante —un tope de presupuesto que nadie estableció. En ingeniería de LLM, la seguridad y el costo son la misma disciplina. Cada error de seguridad de esta lista —una clave hardcodeada, una credencial compartida, un límite de gasto sin tope— es también un error de costo. La industria se está dando cuenta lentamente: conforme las LLM APIs se vuelven la capa de datos por defecto de las aplicaciones, la gestión de claves de API cargará el mismo peso que la gestión de credenciales de bases de datos. Los equipos que la tratan así hoy no serán los que escriban la lección del próximo año.
Audita tu stack —topes de presupuesto, claves virtuales, routing de fallback y seguimiento de costos —la infraestructura que convierte la seguridad y la gestión de costos en una misma conversación.