Por qué no toda tarea de IA merece el modelo más grande: diseño consciente de los recursos.

Un sistema de fraude, cuatro tareas diferentes

Mire todo lo que tiene que manejar un único sistema de detección de fraudes. Un nombre de dominio puede necesitar ser verificado contra información de inteligencia sobre amenazas conocidas. Una factura puede requerir comparación con los detalles de pago establecidos del proveedor. Un correo electrónico ambiguo necesita ser interpretado en contexto, y audio o video manipulados pueden exigir un modelo analítico mucho más complejo. Todo esto se considera trabajo de seguridad, pero desde el punto de vista computacional no se trata del mismo problema.

Aun así, los sistemas modernos de IA ofrecen un atajo tentador: dirigir todo al modelo de propósito general más grande disponible y dejar que él decida. Ciertamente es sencillo. Pero también puede resultar innecesariamente caro, lento, invasivo para la privacidad, difícil de controlar, o simplemente inadecuado para la tarea. Aquí “más grande” se refiere al modelo de propósito general más potente o complejo disponible, y no solo al que tiene la mayor cantidad de parámetros.

Por lo tanto, la pregunta relevante sobre el diseño cambia. En lugar de preguntarse cuál es el modelo más potente disponible, hay que preguntarse cuál es el mecanismo menos complejo que aún cumpla con los requisitos de calidad y riesgo del trabajo a realizar. A veces se trata de un modelo general robusto; otras, de uno más pequeño y especializado. Y en ocasiones, el modelo adecuado es simplemente ninguno.

Pruebas de rendimiento versus producción

Las pruebas de rendimiento indican qué puede hacer un modelo. La arquitectura de producción debe resolver una cuestión diferente: qué debe utilizar realmente el sistema. La calidad es solo una de las dimensiones a considerar. Los sistemas reales también deben lidiar con objetivos de latencia, presupuestos de inferencia, reglas de privacidad, recursos computacionales limitados, condiciones de red, metas de fiabilidad y costos operativos adicionales.

Un modelo que obtiene las mejores calificaciones en una prueba de rendimiento puede resultar inadecuado para una tarea específica. Cuando una comparación exacta y determinista resuelve la cuestión, contar con mayor capacidad de razonamiento casi no aporta nada. Cuando los datos deben permanecer en las instalaciones locales, enviarlos a un servicio remoto cambia por completo la situación en cuanto a privacidad y seguridad. Y cuando un proceso empresarial debe responder dentro de un límite de tiempo estricto, la elección no puede basarse únicamente en la calidad del modelo.

Una forma de expresarlo es que un mecanismo adecuado combina calidad suficiente, riesgo aceptable y costos operativos razonables. Eso no significa elegir la opción más barata, ya que un mecanismo económico que no cumple con la tarea no es adecuado. Significa que las capacidades adicionales deben justificar su costo extra.

Lo que demuestran las investigaciones sobre enrutamiento

La idea se vuelve cada vez más visible en la investigación sobre enrutamiento de modelos. En lugar de asumir que cada solicitud va a un modelo premium, los investigadores han creado sistemas que eligen un modelo según la solicitud y el rendimiento necesario.

El artículo FrugalGPT de Chen, Zaharia y Zou (2024) evaluó cadenas de procesamiento con una combinación de modelos de lenguaje. Combinarlos cuidadosamente redujo sustancialmente el costo de inferencia manteniendo el rendimiento deseado, y en algunos entornos probados el ahorro reportado alcanzó el 98%. RouteLLM (Ong et al., 2025) fue aún más allá al aprender cuándo una consulta debe dirigirse a un modelo más potente o más débil. En sus pruebas públicas reportó un ahorro de más del doble sin pérdida de calidad en comparación con su configuración de referencia.

Esos números no son garantías de rendimiento en producción. Dependen de los modelos, las pruebas de referencia, las estructuras de precios y los métodos de enrutamiento en cada experimento. Sin embargo, sigue siendo cierto el punto arquitectónico: la capacidad máxima no tiene por qué ser el punto de operación por defecto.

Especialistas, reglas y comparaciones exactas

Mezclar modelos no se trata solo de elegir entre dos LLM de uso general. Cuando una tarea está estrictamente delimitada, la especialización a veces puede sustituir a la mera magnitud. Pecher, Srba y Bielikova (2025) compararon modelos especializados pequeños con modelos generales grandes en ocho tareas de clasificación de texto, y con una cantidad bastante reducida de datos etiquetados del dominio, los modelos pequeños igualaron o superaron a los grandes en algunos problemas específicos.

No obstante, existe un límite. Un clasificador compacto entrenado para un propósito específico no puede sustituir a un modelo general potente cuando el trabajo requiere razonamiento amplio, situaciones desconocidas, interpretación entre modalidades o conocimientos que van más allá de sus datos de entrenamiento. Sin embargo, los problemas estrechos y repetitivos cambian las cosas: si un sistema realiza una operación bien definida una y otra vez, es posible que no necesite contar con capacidades generales a las que nunca recurre. La investigación en enrutamiento también se dirige en esa dirección. BEST-Route (Ding et al., 2025) no solo pregunta qué modelo debe manejar una consulta, sino también cuánto cálculo en tiempo de prueba merece dicha consulta.

La idea central es sencilla. Diferentes cargas de trabajo se encuentran en regiones de capacidad distintas, y la arquitectura resulta útil cuando puede distinguirlas.

Considérense aún operaciones más simples:

• decidir si dos identificadores de cuenta normalizados coinciden
• verificar si una transacción supera un umbral especificado
• probar si un dominio puede pertenecer a un conjunto en caché
• descubrir si falta un campo requerido en un registro estructurado

Ninguno de estos procedimientos es inherentemente semántico. Realizar una comparación exacta mediante un modelo de lenguaje convierte una tarea determinística en una probabilística, añade carga adicional por inferencia y genera otra posibilidad de fallo. Esa es una de las razones por las cuales los diseños que combinan mecanismos determinísticos y aprendidos parecen más convincentes que aquellos que integran inteligencia artificial en cada componente. El trabajo neurosimbólico en ciberseguridad apunta en la misma dirección, donde las partes aprendidas contribuyen al reconocimiento de patrones, mientras que las partes simbólicas o basadas en reglas aportan razonamiento y control explícitos (Bizzarri et al., 2025).

Por supuesto, las reglas no son necesariamente mejores en todos los casos. Se vuelven frágiles cuando el lenguaje es ambiguo, cuando el comportamiento cambia, cuando los atacantes utilizan paráfrasis inesperadas, o cuando el sistema debe generalizar más allá de lo que sus diseñadores previeron. La verdadera distinción no radica en reglas contra la IA, sino en si la tarea realmente requiere inferencia. Cuando una condición puede expresarse con exactitud, la lógica determinista constituye una excelente solución técnica. Donde importan el significado, la incertidumbre o la generalización, los modelos aprendidos ganan su lugar. Una arquitectura madura puede manejar ambas situaciones.

La misma disciplina para los sistemas multiagente

Los sistemas multiagente merecen el mismo escrutinio. Una vez que un equipo acepta que un modelo grande no debería manejarlo todo, es fácil sobrecorregir y dividir todo en agentes porque eso parece más sofisticado. La cantidad de agentes no es una justificación. Un diseño multiagente tiene sentido cuando las responsabilidades están realmente separadas: diferentes especializaciones, herramientas, permisos o fuentes de datos, o tareas que realmente pueden ejecutarse en paralelo. Shen y colaboradores (2024) exploraron un diseño multi-LLM para el uso de herramientas en el que la planificación, la llamada a herramientas y la resumen estaban separadas, y la ventaja provino de esa división funcional.

Los agentes adicionales también generan costos de coordinación. Wang y colaboradores (2024) estudiaron las discusiones entre múltiples agentes en tareas de razonamiento y descubrieron que no siempre superaban a las bases de referencia de un solo agente más potentes, lo cual socava la idea de que añadir conversaciones entre modelos mejora automáticamente el razonamiento. La topología también es importante. Li y colaboradores (2024) demostraron que la forma en que los agentes se comunican afecta tanto el rendimiento como el costo computacional.

La regla de diseño que sigue es que los agentes deben especializarse porque el volumen de trabajo lo exige. Si varios agentes leen esencialmente el mismo contexto, utilizan las mismas herramientas y ejecutan variaciones secuenciales del mismo razonamiento, la arquitectura probablemente solo esté multiplicando los costos adicionales. Un único agente con herramientas bien diseñadas puede ser la solución más eficiente.

Dónde se ejecuta el cálculo

Elegir un mecanismo es solo la mitad del problema, ya que también debe ejecutarse en algún lugar. Los dispositivos locales, la infraestructura periférica y las plataformas en la nube tienen cada una sus fortalezas y limitaciones, y la investigación en inferencia colaborativa ha explorado la posibilidad de distribuir el cálculo entre ellos en lugar de asumir que una carga de trabajo pertenece exclusivamente a un único lugar (Zhou et al., 2019; Ren et al., 2023).

Nada de lo que existe aquí funciona en todos los casos. Ejecutarlo localmente no es necesariamente más rápido, ya que el hardware del endpoint podría ser débil, mientras que un servicio en la nube optimizado realiza la tarea con mayor rapidez. Tampoco ejecutarlo en la nube es automáticamente mejor, ya que la latencia de red, el ancho de banda, la sensibilidad de los datos o las necesidades de tiempo de actividad pueden alterar ese equilibrio. La privacidad es un tema más complejo que la idea de que “lo local significa privado”. Mantener la información bruta en el dispositivo reduce la cantidad de datos brutos que se transfieren, pero las representaciones intermedias generadas por inferencias divididas o colaborativas aún pueden exponer detalles sensibles. Higgins y colaboradores (2025) analizan los riesgos de reconstrucción e inferencia en entornos de aprendizaje dividido.

Por lo tanto, la ubicación es una decisión de tipo sistémico y no una preferencia tecnológica. La cuestión no es si se utiliza el edge o la nube, sino qué entorno satisface adecuadamente los requisitos de la carga de trabajo.

Un estudio de caso en protección contra fraudes

La cuestión adquirió concreción durante el diseño de una arquitectura de ciberseguridad orientada a explorar formas de protección contra el fraude para empresas pequeñas y medianas. Preguntar qué modelo de IA debería detectar el fraude nunca fue el enfoque adecuado. El concepto incluía tareas muy diferentes: verificaciones técnicas rápidas, comparaciones estructuradas de registros financieros, interpretación semántica, análisis de anomalías y, potencialmente, análisis forense de medios mucho más complejo. Tratarlas como un único problema computacional no habría tenido mucho sentido.

El resultado fue una propuesta de arquitectura híbrida de múltiples agentes en tres niveles, organizada según un grado creciente de profundidad analítica. Aquí es importante hacer una distinción: el diseño en tres niveles es una arquitectura objetivo, mientras que la prueba de concepto más limitada desarrollada para un proyecto final solo valida una parte de ella. No demuestra que cada componente propuesto para su implementación real exista o haya sido probado.

Capa 0: filtrado y triaje

La primera capa es la parte económica y rápida. Las tareas propuestas incluyen la normalización, verificaciones de remitente y dominio, señales de autenticación, pruebas de pertenencia con filtro Bloom en caché, un análisis de los metadatos de los archivos adjuntos y indicadores deterministas sobre riesgo financiero. Gran parte de estas tareas no utiliza inteligencia artificial, por diseño. Un filtro Bloom es una estructura probabilística rápida para determinar pertenencias, no un clasificador de fraudes; un resultado positivo solo indica que un elemento podría formar parte del conjunto, por lo que aún se necesita confirmación. Los demás indicadores deterministas también sirven como evidencia para escalar el caso, pero no constituyen un juicio final. Esta capa existe para evitar gastar análisis costosos en situaciones en las que pruebas más simples pueden resolver o elevar el nivel de un caso.

Capa 1: orquestación y explicación

La segunda capa proporciona el flujo de trabajo controlado. En el diseño objetivo, LangGraph gestiona el estado, los nodos, el enrutamiento condicional y el flujo de evidencias. Un modelo de lenguaje pequeño podría ayudar opcionalmente con la interpretación semántica limitada o con la redacción de textos para los usuarios, pero no está diseñado para decidir sobre el enrutamiento, la gravedad ni las acciones de alto impacto.

Eso es importante porque utilizar un modelo de lenguaje dentro de un sistema no implica darle control sobre dicho sistema. La capa de orquestación puede limitar dónde operan los modelos, qué evidencias ven y qué acciones posteriores están a su disposición. También puede separar el análisis de la explicación: primero establecer evidencias estructuradas y luego convertir los hallazgos respaldados en un lenguaje legible.

Capa 2: agentes analíticos especializados

La tercera capa contiene el análisis más profundo. El diseño objetivo separa el análisis de texto y facturas, la detección de anomalías y el análisis audiovisual que requiere muchos cálculos. Estas funciones no necesariamente requieren el mismo modelo, acceso a datos ni entorno de ejecución. Ahí es donde la idea de múltiples agentes resulta útil, no como una afirmación de que más agentes significan más inteligencia, sino como una forma de representar responsabilidades analíticas verdaderamente diferentes.

Lo interesante no es tanto el número de tres capas como la idea que estas representan: la capacidad computacional debe ser proporcional al problema que se resuelve.

Lo que mostró la prueba de concepto

La prueba de concepto implementada fue deliberadamente más limitada. Utilizó escenarios de compromiso de correos electrónicos de proveedores sintéticos y desvío de facturas, junto con un LangGraph StateGraph determinista. El flujo de trabajo mantuvo un estado centralizado, siguió rutas de enrutamiento explícitas, extrajo indicadores de riesgo estructurados del texto y las facturas, determinó la gravedad de manera determinista y generó advertencias basadas en pruebas concretas. Cubrió un escenario sospechoso, un escenario de referencia seguro y una ruta de error controlada, con pruebas automatizadas y ejecución local.

Se dejaron de lado varios aspectos: el flujo de trabajo completo de producción de Capa 0, la integración en tiempo real con Microsoft 365 o Google Workspace, el OCR en producción, el aprendizaje federado, la detección local de anomalías basada en VAE, la inferencia de cómputo confidencial en medios, y la detección de deepfake de audio o video. El alcance es importante. La prueba de concepto demuestra que el flujo de trabajo es factible. No prueba nada sobre la precisión en producción, la escalabilidad ni la superioridad del diseño completo de tres capas.

Se reforzó una lección más específica. En este flujo de trabajo, ningún modelo de lenguaje tuvo que dirigir cada decisión. Primero llegaban las pruebas en formato estructurado, luego se evaluaba la lógica explícita, y solo después se redactaba como una advertencia comprensible para las personas. Separar la capacidad de razonamiento de la autoridad en el flujo de trabajo fue una de las conclusiones arquitectónicas más útiles.

La complejidad tiene un precio

La arquitectura heterogénea no es gratuita:

• Cualquier enrutador puede elegir la ruta incorrecta.
• Una cascada puede añadir latencia antes de pasar al modelo costoso que se necesitaba desde el principio.
• Varios modelos implican más evaluaciones, alojamiento y gestión de versiones.
• Los diseños multiagente generan costos relacionados con la comunicación y la coordinación.
• Los componentes que operan cerca del usuario deben ser enviados, actualizados y monitoreados en una variedad de puntos finales.
• Distribuir los datos amplía las posibilidades de brechas de seguridad, puntos ciegos y fallos.

Existe un argumento en contra muy importante: a veces un único modelo potente es el diseño más simple y adecuado. Si cumple con los requisitos de calidad, latencia, privacidad, fiabilidad y costos necesarios, agregar routers, modelos especializados o agentes adicionales puede generar más complejidad operativa de la que realmente vale la pena. Eso no contradice el principio de consideración de los recursos; de hecho, forma parte de él, ya que la complejidad también debe justificarse.

El objetivo no es reducir los modelos, maximizar la cantidad de agentes ni trasladar los cálculos al edge solo porque la computación en el edge resulte interesante. El objetivo es evitar pagar, ya sea en dinero, latencia, exposición de la privacidad o esfuerzo de ingeniería, por capacidades que la carga de trabajo no necesita.

Comience con la carga de trabajo

Antes de elegir un modelo, es mejor plantearse una serie de preguntas más simples:

• ¿Podría una regla exacta, una comparación o una búsqueda resolver la tarea? Si es así, es posible que no sea necesario realizar inferencias en absoluto.
• ¿Es la tarea lo suficientemente específica y recurrente como para justificar la necesidad de un especialista?
• ¿Realmente se necesita razonamiento semántico o generalización amplia?
• ¿Dónde se pueden procesar los datos sin superar los límites de latencia, seguridad o privacidad?
• ¿Qué ocurre cuando el mecanismo elegido es incorrecto, y ¿se puede escalar el flujo de trabajo de manera segura?
• Si se consideran varios agentes, ¿tienen responsabilidades, herramientas o datos distintos, o se está dividiendo una sola tarea porque eso parece más avanzado?

Solo una vez respondidas estas preguntas cobra sentido elegir un modelo. Esto invierte una costumbre común, donde primero se elige el modelo más impresionante y luego se buscan tareas para él. Comience con la carga de trabajo y deje que sus limitaciones determinen el mecanismo a utilizar.

Los modelos grandes de uso general siguen siendo herramientas extraordinarias, y un diseño consciente de los recursos no es un llamado a evitarlos. Es un llamado a utilizar sus capacidades donde realmente sean útiles. Las operaciones deterministas deben seguir siéndolo siempre que eso sea suficiente. Los modelos especializados deben poder especializarse. El modelo general más potente debe encargarse de los problemas que realmente requieren su capacidad de razonamiento. Y un sistema multiagente solo debería existir cuando la verdadera especialización lo exija. En una frase: utilice el mecanismo más simple que satisfaga adecuadamente los requisitos de calidad y riesgo de la carga de trabajo.

Una vez que el modelo más potente deje de ser el destino predeterminado, surge una pregunta inevitable: ¿cómo debe decidir el sistema a dónde ir cada carga de trabajo? Esa cuestión de enrutamiento, la asignación de recursos de cómputo según la carga de trabajo, es el siguiente problema natural.

Investigación mencionada

• Chen, Zaharia y Zou (2024): FrugalGPT, modelos de lenguaje en cascada para reducir costos
• Ong et al. (2025): RouteLLM, aprendizaje para enrutar entre modelos a partir de datos de preferencias
• Ding et al. (2025): BEST-Route, enrutamiento adaptativo con cálculos en tiempo de prueba
• Pecher, Srba y Bielikova (2025): modelos especializados pequeños versus modelos generales grandes para la clasificación de texto
• Bizzarri et al. (2025): una revisión de la IA neurosimbólica para la detección de intrusiones en redes
• Shen et al. (2024): un agente multi-LLM para el aprendizaje de herramientas
• Wang et al. (2024): si las discusiones entre múltiples agentes mejoran el razonamiento de los LLM
• Li et al. (2024): topología de comunicación dispersa en debates entre múltiples agentes
• Zhou et al. (2019) y Ren et al. (2023): revisiones sobre inteligencia periférica e inferencia colaborativa de redes neuronales

Higgins et al. (2025): aprendizaje dividido que preserva la privacidad frente a inferencias adversarias

Lección relacionada

• Notas prácticas: 21 patrones de diseño agente explicados simplemente — Guía paso a paso de las Notas prácticas: 21 patrones de diseño agente explicados simplemente: contratos, verificaciones y espacios de código listos para usar para los equipos que implementan este patrón.
• La memoria del agente AI no es una base de datos: qué guardar, recuperar y olvidar — Por qué la memoria del agente es un problema de relevancia: cómo difieren el contexto, la memoria, el estado y RAG, qué almacenar, cómo delimitar su alcance, controlar su antigüedad y auditarla, y por qué olvidar es una característica positiva.