Evaluar latencia, coste, privacidad y dependencia

El modelo que obtiene mejor puntuación en una prueba aislada no es necesariamente la mejor opción para una aplicación empresarial. La arquitectura debe cumplir requisitos de tiempo, coste, datos, disponibilidad, seguridad y operación.

Esta lección no pretende declarar un proveedor ganador. Construye una matriz para decidir con datos y volver a evaluar cuando cambien modelos, precios o condiciones.

Empieza por calidad de tarea

Antes de hablar de coste, define una prueba representativa. Compara modelos o configuraciones sobre las mismas entradas, criterios y referencias.

Mide lo que importa al caso:

• exactitud o calidad esperada;
• cumplimiento de esquema;
• groundedness si usa fuentes;
• uso correcto de herramientas;
• abstención;
• errores críticos;
• estabilidad entre casos similares.

Un modelo barato que obliga a duplicar revisión humana puede resultar más caro en el sistema completo.

Mide latencia de extremo a extremo

La latencia observable incluye más que la inferencia:

autenticación → preparación → recuperación → modelo → herramientas → validación → persistencia → respuesta

Mide percentiles cuando dispongas de suficiente tráfico. El promedio puede ocultar colas o casos lentos.

Distingue:

• tiempo hasta primer contenido cuando hay streaming;
• tiempo hasta respuesta completa;
• tiempo hasta resultado empresarial utilizable.

El streaming puede mejorar percepción, pero no elimina el tiempo necesario para completar una validación o una acción posterior.

La documentación actual de OpenAI sobre optimización de latencia recomienda, entre otras palancas, reducir tokens generados, reducir solicitudes y paralelizar operaciones cuando sea seguro. Son recomendaciones de proveedor; debes verificar si aplican a tu arquitectura.

Calcula el coste total

No limites el análisis al precio de entrada y salida del modelo.

Incluye:

• tokens de entrada;
• tokens de salida;
• embeddings o búsqueda cuando existan;
• herramientas de terceros;
• almacenamiento;
• reintentos;
• evaluaciones;
• observabilidad;
• revisión humana;
• infraestructura;
• soporte y operación.

Modela al menos tres escenarios: volumen normal, pico y crecimiento.

Los precios son volátiles. Guarda fuente, fecha y supuestos. No incrustes cifras en una arquitectura como si fueran permanentes.

Coste marginal y coste fijo

Una API suele introducir coste variable por uso. Una alternativa local o reservada puede introducir más coste fijo de infraestructura y operación. No concluyas que una es más barata sin volumen, hardware, utilización y personal.

La comparación debe considerar el coste de capacidad ociosa, mantenimiento, actualizaciones y disponibilidad.

Privacidad: empieza por el flujo de datos

Antes de elegir proveedor, documenta exactamente qué sale de tu sistema:

• datos personales;
• secretos comerciales;
• documentos internos;
• identificadores;
• contenido generado;
• logs;
• resultados de herramientas.

Después verifica para el servicio y endpoint concretos:

• finalidad del tratamiento;
• retención;
• controles disponibles;
• región o residencia de datos cuando aplique;
• subprocesadores;
• cifrado y acceso;
• borrado;
• uso para mejora o entrenamiento cuando corresponda.

Las condiciones no deben inferirse por la marca. La documentación actual de OpenAI, por ejemplo, diferencia controles y retención según servicios y configuraciones de la plataforma. Otros proveedores tienen sus propios contratos y políticas. Verifica siempre la oferta concreta.

Minimiza antes de enviar

La pregunta no es solo «¿puede este proveedor recibir estos datos?». También: «¿necesita la tarea esos datos?».

Puedes reducir exposición mediante:

• selección de campos;
• pseudonimización cuando tenga sentido;
• recuperación mínima;
• separación de secretos;
• procesamiento previo;
• controles de acceso;
• rutas que no usan LLM para datos innecesarios.

No presentes «modelo local» como sinónimo automático de privacidad. La seguridad depende también de infraestructura, permisos, logs, copias, operación y actualizaciones.

Disponibilidad y límites

Una aplicación empresarial necesita conocer:

• rate limits;
• cuotas;
• regiones;
• ventanas de mantenimiento si existen;
• políticas de deprecación;
• disponibilidad del modelo;
• comportamiento ante saturación;
• soporte.

Diseña fallback solo si aporta valor. Mantener dos proveedores puede reducir una dependencia y duplicar esfuerzo de pruebas, seguridad y operación.

Dependencia de proveedor

Evalúa qué elementos son portables:

• prompts;
• esquemas;
• herramientas;
• embeddings;
• ficheros;
• estado;
• evaluaciones;
• observabilidad;
• identificadores internos.

Una capa de abstracción puede reducir acoplamiento superficial y también ocultar capacidades específicas o multiplicar complejidad. Añádela cuando exista un requisito real de portabilidad.

La mejor protección suele ser conservar contratos propios, datasets de evaluación, datos en formatos exportables y fronteras claras entre lógica empresarial y API de modelo.

Ejemplo de matriz de decisión

Compara dos alternativas sobre el mismo caso:

No asignes un ganador hasta definir pesos y umbrales del caso.

Separa calidad de modelo y calidad de sistema

Una comparación de proveedores debe fijar el resto de variables siempre que sea posible. Si A recibe mejores instrucciones y B menos contexto, no estás comparando modelos de forma limpia.

Mantén un baseline reproducible y registra cambios. Después evalúa la arquitectura completa, porque el modelo que gana en una prueba aislada puede perder cuando incorporas retrieval, herramientas o restricciones de latencia.

Capacidad y picos

No basta con coste medio. Modela concurrencia y picos. Una tarea mensual de 10.000 documentos puede tolerar batch; una interacción de atención al cliente necesita respuesta inmediata.

Considera colas, límites de proveedor y degradación. El sistema debe definir qué sucede si la capacidad disponible es menor que la demanda: esperar, priorizar, usar otra configuración o pasar a manual.

Riesgo de cambios externos

Modelos, APIs y precios cambian. Mantén una lista de dependencias volátiles con propietario y fecha de revisión. Cuando un proveedor depreca una versión, la actualización necesita pasar por evaluación antes de producción.

Esto convierte vendor lock-in en un riesgo gestionable, no en una etiqueta abstracta.

Ejercicio: comparación reproducible

Selecciona dos configuraciones y prepara:

1. dataset de prueba;
2. versión de modelos;
3. fecha;
4. parámetros relevantes;
5. calidad;
6. latencia;
7. coste total estimado;
8. controles de datos;
9. disponibilidad;
10. portabilidad;
11. trabajo de operación;
12. incertidumbres.

Documenta qué cambio en los requisitos podría invertir la decisión.

Decisión resultante

La decisión debe quedar respaldada por una matriz de arquitectura, no con un ranking de modelos. Sabes qué alternativa cumple calidad, tiempo, coste y datos para tu caso y qué supuestos debes revisar periódicamente. La última lección integrará estas decisiones en un brief técnico que C04 podrá convertir en una implementación real.