La demo funciona. Ahora haga que sobreviva en producción.

Toda API de IA robusta tiene el mismo esqueleto: un gateway para autenticación y limitación de tráfico, una capa de aplicación para validación, construcción del prompt, seguimiento de costos y manejo de errores, el modelo en sí, un almacén para contabilizar el uso y un sistema de métricas con alarmas:

Cliente
  → Gateway          (autenticación + limitación)
  → Capa de app      (validación, prompt, costos, errores)
  → Modelo           (inferencia)
  → Almacén de uso   (tokens por clave)
  → Métricas         (registros estructurados → alarmas)

La arquitectura de referencia tiene forma de AWS (API Gateway → Lambda → Bedrock → DynamoDB → CloudWatch), pero el patrón no depende de la nube: las mismas cinco responsabilidades se trasladan limpiamente a una arquitectura de Postgres/Supabase + funciones de borde (edge functions). Lo que importa es que cada propiedad de abajo tenga una capa que se haga cargo de ella, en lugar de darla por hecha.

El tráfico de producción incluye el camino feliz y cada camino de falla: una entrada enorme, un servicio externo lento, una ráfaga de peticiones simultáneas. La primera defensa es barata: acotar la entrada antes de que llegue al modelo.

• Límites de longitud. Un mínimo y un máximo para la entrada del usuario (p. ej., de 3 a 3,000 caracteres) topan el costo en tokens de cualquier petición antes de pagar la inferencia.
• Rechazar entradas mal formadas. Los bytes nulos y los caracteres de control nunca son texto legítimo de un usuario: descártelos en la puerta.
• Resiliencia frente al servicio externo. Espera exponencial ante la limitación de tráfico (p. ej., 1 s / 2 s / 4 s, tres reintentos) y un ciclo de reintentos que distinga lo reintentable de lo definitivo: reintente ante una limitación, y falle rápido ante un tiempo agotado o un error de validación en lugar de insistir con una llamada condenada.

Las amenazas propias de la IA son la inyección de prompts, la extracción de datos mediante prompts manipulados, el bombardeo de tokens y el abuso de credenciales filtradas. Un primer filtro barato atrapa los intentos más perezosos: expresiones regulares para patrones como “ignore previous instructions”, “you are now…”, “developer/jailbreak mode” o “reveal your system prompt”.

• Aplique un hash a las credenciales antes de que lleguen al almacenamiento o a los registros. Use un hash de la clave de API como llave para el seguimiento de uso; nunca registre una credencial en claro.
• Restrinja la salida, no solo la entrada. Un sobre que la app hace cumplir (solo emitir texto que coincida con una forma estructurada esperada y descartar lo demás) es una capa de defensa en profundidad contra la inyección y contra las respuestas mal formadas: la misma idea detrás de la salida estructurada obligatoria de Groundyard.

El monitoreo blando le avisa de una factura desbocada después de que la pagó. La versión de producción es un tope estricto que se aplica antes del gasto:

• Una cuota diaria de tokens por clave, aplicada con una actualización condicional atómica: ADD … ConditionExpression en DynamoDB, o en Postgres un SELECT … FOR UPDATE o un upsert seguido de verificación. La atomicidad es el punto: dos peticiones simultáneas no pueden colarse ambas por encima del límite.
• Estime el costo antes de la llamada (una heurística de caracteres/4 para la entrada + el presupuesto máximo de salida) y rechace una petición que exceda la cuota antes de gastar un centavo en inferencia.
• Una alarma de costo del mismo día: publique el costo por petición como métrica y ponga una alarma en un umbral de gasto diario, para detectar un gasto desbocado el mismo día y no en la factura de fin de mes.

Esta es la forma de ingeniería de la palanca “ponerle tope a lo que se puede desbocar” del Manual contra el impuesto de tokens. El puente de nuestro propio chatbot de DLR tiene exactamente esta forma: un tope de gasto diario por cliente, con alertas en un umbral por petición, al 75% del tope y ante cualquier pico diario de más del doble del promedio móvil; pasado el tope, los chats nuevos se rechazan hasta que cambia el día. En una arquitectura con varios clientes como SecondClaw, la cuota por clave corresponde directamente al aislamiento por cliente, y el patrón de actualización atómica se traslada tal cual de DynamoDB a Supabase/Postgres.

Cuando algo se rompe en silencio, los registros sin estructura hechos con print() lo dejan haciendo arqueología con grep. La solución son los registros estructurados: cada línea, un objeto JSON con un request_id que la correlaciona:

{ "level": "info", "event": "inference_done", "ts": "…",
  "request_id": "…", "in_tok": 412, "out_tok": 188,
  "cost_usd": 0.0021, "model": "…", "latency_ms": 740 }

• Correlacione por request_id para que un agregador de registros pueda responder “las peticiones más caras de las últimas 24 h” o “los errores desglosados por tipo” sin expresiones regulares.
• Registre por separado las detecciones de inyección para que los patrones de ataque se vuelvan una tendencia consultable, no ruido enterrado en el flujo de peticiones.
• Ponga alarmas solo en lo que importa (ajústelas a cada caso de uso): tasa de error > 5% durante 5 min; costo diario estimado por encima de un umbral fijo; latencia P95 > 5,000 ms en dos ventanas consecutivas de 5 min.

Es el mismo instinto detrás de todo lo que publicamos: una cifra que no se puede consultar no es observabilidad, y, como muestra la trampa de Pareto en el enrutamiento, una cifra agregada que no se puede segmentar esconderá la falla que de verdad importa.

Ninguna de estas cuatro capas es glamorosa, y ese es el punto: una API de IA de producción es sobre todo la infraestructura aburrida que hace que la salida del modelo sea confiable, costeable y depurable. Topes de costo aplicados antes del gasto, una seguridad que no depende de una expresión regular evadible y registros que de verdad se pueden consultar son la diferencia entre una demo y un servicio. Es la misma disciplina que defiende todo este sitio, aplicada una capa más abajo: no dé por hecho el camino feliz; mida y acote cada camino.