Diseño del entorno de ejecución y control de agentes: elegir el modelo adecuado

La selección y el enrutamiento de modelos son un problema de control operativo, no una competición de clasificaciones. Los requisitos de privacidad y residencia de datos delimitan primero el conjunto de modelos admisibles; el éxito de las tareas y la calidad de las salidas determinan cuáles funcionan dentro de ese conjunto; solo después deben optimizarse los tokens, la latencia y el costo. Los modelos locales pueden ser eficaces, pero suelen necesitar una descomposición más rigurosa, recuperación de información y verificación determinista.

El entorno de ejecución y control es la unidad productiva

Un agente empresarial no es un modelo con un prompt de sistema largo. Es un entorno de ejecución y control: recepción de solicitudes, preparación del contexto, controles de políticas, ejecución del modelo, acceso a herramientas, estado, verificación, lógica de reintentos, observabilidad y derivación para revisión. El modelo es un componente reemplazable dentro de ese sistema.

Las comparaciones de modelos fuera de este entorno suelen predecir mal los resultados de producción. Un modelo puede destacar en una prueba comparativa y tener dificultades con los formatos, permisos, vocabulario o flujos de trabajo de la organización. Otro puede parecer menos capaz en un chat abierto, pero funcionar de forma fiable cuando se descompone la tarea, se recupera evidencia y se comprueban las salidas contra restricciones deterministas.

Elegir «el mejor modelo» es, por tanto, una abstracción equivocada. Elegimos una ruta de ejecución admisible para una tarea definida. Puede utilizar un modelo, varias llamadas especializadas, un modelo local, uno alojado o ningún modelo. Solo tiene éxito si la tarea alcanza un estado de negocio verificado.

La arquitectura debe hacer explícita esa capacidad de sustitución. Una capa de operaciones de IA basada en hilos separa el contexto del usuario del ejecutor, de modo que el enrutamiento, el estado, la autorización y la verificación se mantienen estables cuando cambia el modelo.

Primer control: privacidad, residencia y admisibilidad contractual

El enrutamiento empieza antes de probar la calidad. La primera pregunta es si un endpoint del modelo puede recibir los datos y realizar la acción.

Creamos un perfil de admisibilidad para cada clase de tarea. Incluye:

clasificación de los datos y presencia de información personal, confidencial, regulada o sujeta a controles de exportación;
regiones exigidas para el procesamiento y el almacenamiento;
condiciones de conservación, registro, uso para entrenamiento y eliminación;
subencargados del tratamiento y restricciones de transferencias transfronterizas;
requisitos de cifrado, identidad y control de acceso;
obligaciones de registro de auditoría y notificación de incidentes;
si las herramientas pueden leer o modificar sistemas de producción;
si los documentos recuperados pueden salir de un entorno controlado.

Son restricciones de enrutamiento, no un párrafo de política añadido después del lanzamiento. Si una tarea contiene datos restringidos, el componente de enrutamiento debe excluir los endpoints que no cumplen el perfil. La supresión de datos sensibles puede producir en ciertos casos una tarea derivada menos restringida, pero debe ser fiable, registrada y probada con los formatos utilizados. Sustituir un nombre y dejar un número de cuenta único o una combinación de hechos comercialmente sensible no anonimiza de forma efectiva.

La residencia también se aplica al entorno de ejecución y control completo. Enviar prompts a un endpoint regional aprobado no resuelve el problema si las trazas, índices vectoriales, registros de errores o colas de revisión humana se almacenan en otra región. Inspeccionamos todo el recorrido de los datos: recepción, archivos temporales, recuperación de información, inferencia, resultados de herramientas, observabilidad, copias de seguridad y acceso de soporte.

Este control produce rutas permitidas, no un ganador. Un modelo local puede ser obligatorio para una tarea, opcional para otra e inadecuado para una tercera. La política reduce las opciones; la evidencia completa la decisión.

Segundo control: éxito de la tarea y después calidad

Dentro del conjunto admisible, la primera pregunta de evaluación es si la tarea tuvo éxito. ¿Alcanzó el flujo de trabajo el estado previsto? En investigación, puede ser una respuesta respaldada con citas accesibles. En extracción, un registro válido según el esquema y vinculado a fragmentos de origen. En una acción operativa, un plan válido de simulación sin cambios, una modificación aprobada y una verificación satisfactoria del resultado registrado.

El éxito de la tarea va más allá de la calidad de la respuesta. Una respuesta elocuente que no puede analizarse, cita evidencia inaccesible o llama a una herramienta prohibida es una ejecución fallida. En cambio, una salida breve puede ser exitosa si completa el proceso de forma fiable.

Definimos un conjunto de evaluación a partir de trabajo representativo. Cada caso contiene la entrada, la evidencia permitida, la transición de estado esperada, las condiciones de fallo obligatorio y una rúbrica de puntuación. Debe cubrir:

casos habituales que concentran el volumen;
casos límite cercanos a un umbral normativo o de calidad;
entradas ausentes, desactualizadas, duplicadas o contradictorias;
fallos de herramientas y dependencias;
intentos de inyección de prompts o de uso de contenido no fiable;
casos que exigen abstenerse o derivar para revisión;
variaciones de idioma o formato cuando corresponda.

Evaluamos las restricciones obligatorias antes que las preferencias subjetivas. La validez del esquema, la selección correcta de herramientas, el cumplimiento de autorizaciones, el respaldo de las citas y la abstención exigida se aprueban o rechazan. La integridad semántica, claridad y utilidad pueden puntuarse con una rúbrica. Una prosa más pulida no compensa una menor tasa de tareas completadas y verificadas.

Las skills de agentes específicas de un dominio ayudan a estabilizar esta evaluación porque los procedimientos y las comprobaciones exigidas se representan como artefactos explícitos, en lugar de redescubrirse en cada conversación.

Tercer control: tokens, latencia y costo

Solo optimizamos la eficiencia después de que las rutas cumplan los límites de éxito y calidad. La unidad relevante es el costo por tarea verificada, no el precio por token de entrada.

Un modelo más barato puede resultar más costoso si necesita reintentos, revisión o correcciones posteriores. Una primera respuesta rápida puede tener mala latencia de extremo a extremo si el entorno repara salidas inválidas repetidamente. Una ventana de contexto mayor puede fomentar la carga indiscriminada de datos y aumentar el costo y la superficie de error.

Medimos las siguientes dimensiones:

Dimensión	Medida del entorno de ejecución y control
Éxito	finalizaciones verificadas por intento admisible
Calidad	aceptación en el primer intento, gravedad de los defectos y tasa de errores no detectados por los controles
Tokens	tokens de entrada, entrada en caché, salida y reintentos por tarea completada y verificada
Latencia	tiempo mediano y de los casos más lentos desde el activador hasta el estado verificado
Costo	inferencia, recuperación de información, herramientas, revisión y trabajo que debe repetirse por tarea completada y verificada
Estabilidad	variación del rendimiento en el tiempo, entre formatos y entre clases de demanda

Los índices normalizados hacen legibles las comparaciones internas sin sugerir una precisión falsa. Fije la ruta aprobada actual en Baseline = 100 para el costo ajustado por calidad y la latencia de extremo a extremo. Una alternativa solo es útil si su menor índice de costo no oculta una peor tasa de éxito, más excepciones o más tiempo de revisión. Conservamos los recuentos y definiciones subyacentes para auditoría incluso cuando los informes externos usan valores normalizados.

La optimización se centra entonces en aspectos concretos. Almacenar prompts en caché puede reducir la repetición del contexto de políticas. Recuperar pasajes más cortos puede reducir las distracciones. Las lecturas de herramientas en paralelo pueden mejorar la latencia. Un modelo menor puede encargarse de la clasificación y una ruta más potente, de las síntesis ambiguas. El código determinista puede eliminar por completo una llamada de inferencia.

Enrutar tareas, no usuarios

El enrutamiento fijo por departamento desperdicia capacidad y dinero. Una persona puede solicitar un resumen público, una comparación confidencial, una conciliación y una escritura en producción: clases de tareas con distintos requisitos de admisibilidad, calidad y autoridad.

Enrutamos según un conjunto de propiedades de la tarea:

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

El componente de enrutamiento debe ser lo más determinista posible. La clase de datos, la residencia y la autoridad son decisiones de política. No deben depender de que un modelo adivine si la solicitud «parece sensible». Un clasificador puede ayudar en la recepción, pero la incertidumbre debe llevar a la ruta más segura o a solicitar una aclaración específica.

El modelo se elige dentro de la rama permitida. La ruta se registra junto con las versiones de política, modelo, prompt o skill, los identificadores de evidencia recuperada, las llamadas a herramientas, los resultados de verificadores y el estado final. Este registro permite diagnosticar fallos y reproducir comparaciones.

Por qué los modelos locales necesitan otro entorno de ejecución y control

A menudo se habla de inferencia local como si bastara trasladar el mismo prompt de un endpoint alojado a hardware local. Rara vez basta. Los modelos locales pueden ofrecer un control sólido de privacidad, un costo marginal predecible, funcionamiento sin conexión y baja latencia en tareas acotadas. También pueden seguir peor las instrucciones, seleccionar peor las herramientas y tener menor fiabilidad con contexto largo o menor consistencia multilingüe que las alternativas alojadas más potentes disponibles en cada momento.

La respuesta adecuada no es ocultar estas diferencias, sino cambiar el entorno de ejecución y control.

Descomponer más

Asigne al modelo una transformación acotada cada vez. Separe la selección de documentos, la extracción, la clasificación, la redacción y la verificación. Cada etapa debe tener un contrato limitado de entrada y salida. Descomponer reduce las instrucciones simultáneas y crea puntos de comprobación donde los controles deterministas pueden detener la propagación de errores.

Una ruta local puede identificar primero las secciones relevantes, extraer después afirmaciones a un esquema, vincular cada afirmación a un fragmento de origen y redactar solo con las afirmaciones aceptadas. Requiere más coordinación que un único prompt grande, pero es más fácil de evaluar y reparar.

Recuperar menos y mejor

Volcar un repositorio o una colección de documentos entera al contexto no es recuperación de información. Transfiere al modelo el problema de selección. Las rutas locales se benefician de índices estructurados, filtros de metadatos, restricciones de actualidad y paquetes breves de evidencia. La recuperación debe devolver identificadores y fragmentos de origen para que las comprobaciones posteriores confirmen el respaldo de la respuesta.

Los patrones prácticos de construcción de un asistente local de IA con recuperación de información y búsqueda web muestran por qué la inferencia local depende de una capa de herramientas y evidencia, no solo de la memoria del modelo.

Verificar de forma determinista

Utilice esquemas, analizadores, listas de elementos permitidos, restricciones de base de datos, cálculos, motores de políticas y verificaciones del resultado registrado siempre que sea posible. Un modelo puede proponer un cambio; el código debe confirmar que existen los campos exigidos, se resuelven los identificadores, cuadran los totales, los permisos permiten la acción y el estado posterior coincide con el plan aprobado.

Para comprobaciones semánticas no deterministas, utilice una rúbrica y una revisión independiente. No pida a una misma llamada que genere, puntúe y apruebe su propia salida. Si se utiliza un evaluador basado en un modelo, calíbrelo frente a juicios humanos y manténgalo fuera del límite de autoridad final.

Cascadas, alternativas de respaldo y abstención

Un componente de enrutamiento útil no envía cada tarea admisible al modelo más potente. Puede usar una cascada: empezar con la ruta menos costosa que ya haya superado el control de aceptación de esa clase de tarea y derivar a otra ruta ante fallos observables.

Las señales para derivar deben ser concretas: esquema inválido después de repararlo, evidencia ausente, fuentes contradictorias, confianza calibrada baja, herramienta no disponible, límite de política o fallo del verificador. El número de tokens por sí solo no indica calidad. Tampoco la declaración verbal de incertidumbre del modelo, salvo que se haya calibrado para la tarea.

Las alternativas de respaldo deben mantener la consistencia semántica. Si la ruta principal falla porque no puede cumplir los requisitos de residencia, la alternativa no puede ignorarlos. Si no está disponible una llamada a herramienta, una ruta solo de chat no debe fingir que ejecutó la acción. Si la evidencia está desactualizada, un modelo más potente no puede actualizarla.

Abstenerse es un resultado satisfactorio cuando el contrato de la tarea exige derivar para revisión. Incluimos «rechazo o derivación correctos» en las métricas de éxito. De lo contrario, la presión del enrutamiento recompensa intentos que exceden la evidencia o la autoridad.

Estado, versiones y reproducibilidad

Los modelos y endpoints cambian. Aunque el nombre del modelo permanezca, su comportamiento puede cambiar por una nueva versión, configuración de servicio, prompt de sistema, índice de recuperación, definición de herramienta o política. El entorno debe mantener versiones de todo el contrato de ejecución.

Como mínimo, registramos:

versiones de tarea y política;
proveedor del modelo, región del endpoint y versión del modelo;
versiones de prompt, skill y esquema de herramientas;
consulta de recuperación, ID de fuentes y marcas de tiempo de actualización;
parámetros de muestreo y tiempos de espera máximos;
versiones y resultados de verificadores;
eventos de reintento, alternativas de respaldo y revisión humana;
acción final y evidencia de verificación del resultado registrado.

La reproducibilidad operativa procede de entradas, configuración, acciones externas y evidencia de verificación, no de una cadena de razonamiento sin restricciones. Las trazas sensibles siguen las reglas empresariales de minimización y conservación.

La disciplina de los procedimientos descrita en ajustar un agente específico de un proyecto es relevante: los espacios de trabajo persistentes y los procedimientos reutilizables solo son útiles si los cambios, la concurrencia y las formas de fallo son observables.

Un proceso práctico de selección

Utilizamos un proceso de selección por etapas:

Definir clases de tareas. Separar extracción, síntesis, planificación, acción y verificación; no promediarlas en una puntuación.
Aplicar controles de admisibilidad. Eliminar rutas que incumplan requisitos de privacidad, residencia, contrato o autoridad.
Crear el conjunto de evaluación. Incluir casos representativos, límite, adversos y de derivación obligatoria con evidencia fijada.
Probar las rutas en el entorno real. Incluir recuperación de información, herramientas, tiempos de espera máximos, reintentos y verificadores.
Comprobar fallos obligatorios. Rechazar rutas que incumplan los requisitos de esquema, evidencia, autorización o abstención.
Puntuar éxito y calidad. Revisar el rendimiento promedio y los casos extremos de defectos graves.
Medir eficiencia total. Comparar tokens, latencia, costo de inferencia, tiempo de revisión, reintentos y trabajo que debe repetirse por tarea completada y verificada.
Hacer un piloto en modo de evaluación en paralelo o simulación sin cambios. Observar las variaciones de la demanda real sin permitir escrituras no verificadas.
Aprobar por clase de tarea. Registrar la ruta, los límites, la alternativa de respaldo y la fecha de caducidad de la decisión.
Reevaluar continuamente. Activar una revisión ante cambios del modelo, desviaciones, nuevas clases de datos, excepciones repetidas o cambios importantes de precios.

El resultado del proceso es una política de enrutamiento con versiones, no una clasificación permanente.

La regla de decisión

El orden de las decisiones es esencial para un enrutamiento responsable de modelos. Los controles de privacidad, residencia y requisitos contractuales determinan qué está permitido. El éxito verificado y la calidad determinan qué es capaz. Los tokens, la latencia y el costo total determinan qué es eficiente entre las rutas restantes.

Invertir el orden causa fallos previsibles. Priorizar el costo envía trabajo sensible a endpoints inadmisibles o trabajo de baja calidad a ciclos de revisión costosos. Priorizar el modelo adapta los procesos a un proveedor preferido. Priorizar las pruebas comparativas optimiza tareas que quizá la empresa nunca realice.

Diseñamos el entorno para cambiar modelos sin perder políticas, estado ni evidencia. Los modelos alojados, los locales y los servicios deterministas tienen su función. La elección correcta es el sistema admisible más pequeño que completa la tarea definida, se mantiene dentro del límite de calidad y demuestra el resultado.