Prácticas integradas reales para operar IA sin desperdiciar costos

• Para operar LLM y plataformas de IA de forma estable en un entorno de producción, se necesita un enfoque de diseño centrado en la arquitectura que responda al cambio
• Para prepararse ante cambios en modelos y APIs, se deben separar todas las llamadas de IA como servicios y aplicar un patrón de migración basado en ejecución dual
• Al aprovechar el nivel de servicio Flex de OpenAI, es posible reducir costos en un 50% con la misma calidad de modelo y datos
• Si los datos repetidos se colocan al inicio del prompt, se maximiza la eficiencia en el uso de tokens en caché y se paga solo el 10% del costo
• Para evitar costos excesivos, es imprescindible implementar Rate Limiting y Circuit Breaker en el backend

---

Estrategia de integración de IA preparada para el cambio

• Los modelos de IA y las APIs cambian continuamente, y la forma en que algo funciona hoy puede fallar en cualquier momento
• En lugar de seguir herramientas o modelos individuales, la clave es diseñar sistemas capaces de adaptarse al cambio
• El objetivo de usar IA no es perseguir la tecnología más reciente, sino lograr operación estable y control de costos

Patrón de migración (The Migration Pattern)

• Extraer todas las llamadas a APIs de IA en servicios que gestionen internamente la conexión, la composición de prompts y prompts específicos
• Estos servicios deben operar en un estado de migrabilidad permanente (permanent migratability), de modo que siempre puedan usar la versión y el modelo más recientes o una versión utilizada anteriormente
• Se relata una experiencia con problemas al migrar de GPT 4.1 a GPT-5
  • Un prompt perfectamente construido para GPT 4.1 perdió confiabilidad en GPT-5, por ejemplo omitiendo claves JSON
  • GPT-5 tiende a usar esquemas JSON estructurados (structured JSON schemas) en lugar de un formato JSON simple
  • Es necesario explicar un enfoque donde se definen claves y valores posibles y luego se completan desde el prompt
• Implementación de la estrategia de migración
  • Durante un período específico o en entornos de prueba/staging, ejecutar en paralelo el prompt y modelo antiguos junto con el prompt y modelo nuevos
  • También puede abarcar estructuras de datos y llamadas API completamente distintas (OpenAI recomienda pasar de una API estilo chat a una API estilo response)
  • Se registran ambos resultados, y si hay diferencias importantes el sistema las reporta y muestra el diff
  • El servidor de ejecución dual duplica el costo, pero permite entender cómo las diferencias entre modelo viejo y nuevo, así como entre prompts, afectan la calidad, previsibilidad y confiabilidad
• Es especialmente útil para análisis en segundo plano, procesamiento de datos y análisis semántico, más que para conversaciones puras
• Si el nuevo resultado no cumple con lo esperado, siempre es posible hacer rollback a la versión legacy
• Como los sistemas de API tarde o temprano quedan deprecated, es indispensable estar preparado para migrar
• Revisar el diff de datos JSON ayuda a reconstruir prompts
  • Se puede usar Claude Code o OpenAI Codex para ajustar prompts hasta que ambos resultados se parezcan
• Este patrón aplica a todos los servicios que se comunican con modelos de ML externos
• Si un servicio nuevo sufre una degradación repentina, puede volver a la versión anterior con un cambio de switch para recuperar datos confiables como antes

El secreto de los niveles de servicio (The Service Tier Secret)

• Los servicios en la nube ofrecen niveles de servicio con precios distintos según la importancia de las llamadas API
• En el caso de OpenAI
  • Nivel por defecto (default tier): el precio publicado en el sitio web
  • Solicitudes por lotes (batched requests): bastante más baratas, pero no se sabe cuándo se llenará y procesará el lote, así que no sirven para tareas cuasi sincrónicas
  • Nivel Flex: cuesta la mitad del nivel por defecto
    • Puede ser 50% más lento y no estar disponible en ciertos momentos, pero ofrece la misma calidad de modelo y datos
• Casos de uso del nivel Flex
  • Aplicarlo a trabajos de backend (extracción de invitados, análisis de intervenciones, resúmenes, etc.)
  • Con la función de auto-retries del SDK de OpenAI no hace falta lógica adicional
  • Implementar fallback ante errores 429: intentar varias veces con Flex y, si falla, cambiar al nivel estándar y reintentar
• Resultados al aplicarlo a gran escala
  • Reducción inmediata del 50% en costos (el nivel Flex está disponible la mayor parte del tiempo)
  • Cuando hay muchos tokens de entrada y pocos de salida (por ejemplo, muchas transcripciones de podcast → pocos datos JSON resumidos), los tokens en caché también cuestan la mitad
  • Permite duplicar la carga de trabajo de extracción e inferencia, lo que mejora la calidad de la plataforma y aumenta la conversión
• Aspectos a verificar según la plataforma
  • El precio Batch tiene el mismo costo de procesamiento que Flex
  • El precio Flex existe para los modelos GPT-5, 5.1, o3 y o4
  • En Codex, Pro, GPT-4o, herramientas de audio en tiempo real y otros, el precio Flex puede no estar fácilmente disponible
• Si existen niveles de precio y no se usan, eso equivale a negligencia financiera (financial negligence)
• Si incluso en momentos de congestión se necesitan resultados rápidos, se puede configurar el nivel Priority (doble precio, resultados más rápidos)
  • Priority también puede no existir para ciertos modelos
• Como hay muchos modelos y formas de uso, se necesita flexibilidad al implementar y optimizar

Front-loading para eficiencia de caché (Front-Loading for Cache Efficiency)

• Cuando hay muchos datos por analizar, conviene poner al inicio las partes repetidas
• Colocar primero el prompt del sistema y, si se analiza el mismo conjunto de datos varias veces, empezar el prompt con esos datos
• Orden del prompt
  1. Prompt del sistema (explicación del rol)
  2. Instrucciones del sistema que siempre son iguales ("extrae los datos en este formato")
  3. Datos que pueden repetirse entre prompts
  4. Instrucciones específicas de cada prompt
• Los datos colocados al frente se procesan como tokens en caché, por lo que se paga solo el 10% del costo de otros tokens
• Caso real de aplicación
  • Insertar primero la transcripción completa y, al final, la instrucción específica de la tarea (buscar cierto invitado, encontrar patrocinadores, procesar preguntas de clientes, etc.)
• Verificación de optimización entre varios prompts
  • Meter los prompts como datos en Claude Code o en una conversación de ChatGPT y pedir un análisis de optimización
  • No aceptar sin más el resultado de la IA; usarlo solo como referencia (la IA solo predice tokens: que diga que algo es más útil no significa que realmente lo sea)
  • Analizar varios prompts al mismo tiempo puede generar insights valiosos

Rate Limiting y Circuit Breakers

• Al usar plataformas externas con costos basados en tokens, Rate Limiting es obligatorio
• Dónde aplicar Rate Limit
  • En acciones de cara al cliente que disparan interacciones con IA
  • En las interacciones con IA que el servidor backend puede enviar
• Es necesario prevenir situaciones donde, por una race condition, el mismo proceso se reinicia repetidamente y vuelve a disparar la misma llamada (incluso usando tokens en caché, eso sigue generando costo)
• Detección de anomalías
  • Si en cierto período se usa 10 veces más tokens de IA de lo normal, se necesita una alerta y una función para detenerlo
• Implementación de Circuit Breaker
  • Un circuit breaker global para todas las funciones de IA de la aplicación o para partes específicas
  • Un feature toggle que pueda activarse/desactivarse desde comandos de Laravel o una interfaz de administración
  • Incluso funciones de auto-onboarding como un botón de "generar configuración genial" deben poder encenderse o apagarse
  • Si alguien automatiza el uso y genera cientos de dólares por hora en costos, el toggle debe permitir bloquearlo de inmediato
• Los feature toggles deben implementarse en el backend, no en el frontend (hay que controlar donde realmente ocurre)
• Uso de escaneo con IA
  • Con herramientas de programación agentic se puede escanear el código para identificar puntos donde las llamadas a IA podrían abusarse y dónde agregar feature toggles
• Todo uso de IA debe pasar por el sistema backend
  • No permitir que el lado cliente use tokens para llamar directamente a la plataforma de IA (además de que ya es una mala práctica)
  • Solo a través del backend se puede encender/apagar funciones y recibir alertas por alto uso
• Capas de seguridad implementadas
  • Rate limits en todas las funciones
  • Rate limits para usuarios del frontend
  • Rate limits del backend
  • Feature toggles
  • Alertas por abuso de funciones (por cuenta, por tipo de suscriptor, por IP)
• Se espera que en el futuro estas capacidades vengan incluidas por defecto en herramientas y frameworks, pero por ahora hay que implementarlas manualmente

Lección clave: construir sistemas preparados para el cambio

• El entorno de la IA cambia sin parar (modelos, APIs, precios), por lo que es imposible seguir todo al mismo tiempo
• La clave de operar IA no es usar el modelo más reciente, sino diseñar sistemas que puedan adaptarse cuando ocurran cambios
• Componentes indispensables:
  • Patrón de migración
  • Optimización de niveles de servicio
  • Caché de prompts
  • Rate limiting
  • Circuit breakers
• No son extras opcionales, sino la base para evitar pérdidas al operar IA en producción
• Desde el momento en que se usa IA en producción, el costo y la estabilidad dejan de ser solo problemas técnicos y pasan a ser un problema de arquitectura

"Build for Change" Construye una base para el cambio