Source: https://aiprimetech.io/es/docs/guides/best-practices/

[Inicio](/es/) / [Documentación](/es/docs/) / Buenas prácticas para producción 

# Buenas prácticas para producción 

Qué debes configurar correctamente antes de que una integración gestione tráfico real. 

 Copiar página [ Ver como Markdown](/es/docs/guides/best-practices.md) [ Preguntar a ChatGPT](https://chatgpt.com/?q=Read%20https%3A//aiprimetech.io/docs/guides/best-practices.md%20and%20answer%20questions%20about%20it.%20Start%20with%20a%20short%20summary.) [ Preguntar en Claude](https://claude.ai/new?q=Read%20https%3A//aiprimetech.io/docs/guides/best-practices.md%20and%20answer%20questions%20about%20it.%20Start%20with%20a%20short%20summary.)   

## Fiabilidad 
- Reintenta los códigos adecuados. 429, 500, 502, 503, 529 con espera exponencial y variación aleatoria. Nunca reintentes a ciegas 400, 401, 402 o 403.
- Establece tiempos de espera. Una generación larga puede tardar varios minutos sin que haya ningún problema; un socket bloqueado no debería bloquear también tu proceso de trabajo. 120 s es un límite razonable para las llamadas sin streaming.
- Limita la concurrencia con un semáforo en lugar de lanzar todas las solicitudes y reintentar las rechazadas.
- Ten un modelo de respaldo. Si tu modelo principal está sobrecargado, recurrir a uno más pequeño es mejor que devolver un error. 

## Coste 
- Configura max_tokens en cada llamada. Es un límite de gasto, no una sugerencia.
- Selecciona el modelo según la tarea; consulta [Control de costes](/es/docs/guides/cost-control/).
- Activa [el almacenamiento en caché de prompts](/es/docs/guides/prompt-caching/) para obtener prefijos estables.
- Registra usage por solicitud con una etiqueta de tarea para poder atribuir el gasto más adelante. 

## Seguridad 
- Las claves deben estar en variables de entorno o en un gestor de secretos: nunca en el repositorio ni en un paquete de código del cliente.
- Una clave por servicio, para que la revocación sea precisa.
- Nunca construyas prompts concatenando entradas de usuario no fiables con instrucciones; mantén el contenido del usuario en un mensaje user y las instrucciones en system.
- Trata la salida del modelo como contenido no fiable. No eval ese contenido ni ejecutes SQL generado con un rol que tenga permisos de escritura. 

## Observabilidad 
- Registra el modelo, la latencia, usage, stop_reason y tu propio tipo de tarea en cada llamada.
- Configura una alerta para la tasa de stop_reason: max_tokens : un aumento significa que las respuestas se están truncando.
- Haz un seguimiento del coste por tipo de tarea, no solo del total. Los totales ocultan qué carga de trabajo ha empeorado. 

La alerta más útil es la de truncamiento, no la de errores. Una respuesta truncada devuelve HTTP 200 y parece correcta para tu sistema de monitorización, aunque sea incorrecta para el usuario. 

[ErroresSemántica de reintentos](/es/docs/api-reference/errors/)[Límites de solicitudesConcurrencia](/es/docs/api-reference/rate-limits/)[Control de costesGestión del gasto](/es/docs/guides/cost-control/) 

[AnteriorMigración desde la API de OpenAI](/es/docs/guides/migration-from-openai/)[SiguienteResolución de problemas](/es/docs/guides/troubleshooting/)