La serie sobre arquitectura de IA – Parte 3

El cuello de botella en los flujos de trabajo de inversión no suele ser el análisis en sí mismo, sino más bien todo lo que hay que hacer antes de que pueda comenzar el análisis: realizar comprobaciones de cumplimiento, cotejar las posiciones de la cartera con los criterios del mandato, clasificar un fondo según una norma regulatoria, detectar posibles conflictos en todo un universo de activos, entre muchas otras tareas similares.

No se trata de tareas analíticas. Son tareas de recuperación y formateo disfrazadas de trabajo analítico. La arquitectura que describimos en el artículo anterior se diseñó precisamente para resolver este problema.

En las partes 1 y 2 de la serie sobre arquitectura de IA, explicamos por qué las decisiones arquitectónicas se acumulan con el tiempo y cómo encajan en teoría las cuatro capas (el LLM, los MCP, las habilidades y los agentes). En este artículo, pasamos a la práctica y analizamos qué aporta cada capa a los flujos de trabajo reales de inversión, qué nos revela un caso de uso concreto sobre las posibilidades actuales y cuáles son las limitaciones de los protocolos de contexto de modelos (MCP).

El problema que merece la pena mencionar en el análisis de inversiones

La disponibilidad de datos solía suponer una limitación para el análisis de inversiones y el cumplimiento normativo. Sin embargo, a medida que la divulgación de información corporativa ha ido madurando y las fuentes de datos se han multiplicado, esta limitación se ha invertido para muchas empresas. La cantidad de datos a su disposición ha superado su capacidad para actuar en consecuencia. El resultado es una especie de «información inutilizada», definida por la brecha entre la información que existe en un sistema y la decisión que realmente se puede tomar a partir de ella.

Imaginemos a un analista que comprueba el cumplimiento de un mandato. Los pasos previos a su análisis incluyen acceder al conjunto de datos o archivo correcto, seleccionar la cartera adecuada, localizar el mandato pertinente, iniciar la comprobación de cumplimiento, interpretar los resultados a nivel de métricas e identificar las infracciones y los factores que las provocan. Ninguno de esos pasos requiere un juicio profundo ni un pensamiento crítico. Se trata simplemente de saber dónde hacer clic y ser capaz de repetir el proceso de forma fiable.

Esto no es una crítica a los sistemas actuales. Es una descripción de cómo han funcionado siempre la mayoría de los productos de datos estructurados: sistemas potentes que exigen que los usuarios sepan cómo manejarlos.

La IA, y concretamente la arquitectura hacia la que se ha ido orientando esta serie de artículos, nos permite replantearnos este statu quo. El razonamiento general de un LLM, combinado con los datos y metodologías específicos del dominio de un MCP especializado, acorta la distancia entre la pregunta y la respuesta. El trabajo «administrativo» que antes ocupaba toda la mañana de un analista (la navegación, el filtrado, la exportación y el formateo) desaparece. Lo que queda es el juicio; el trabajo diferenciado para el que se contrató al analista.

Supervisión de mandatos basada en la inteligencia artificial: un ejemplo real

Como empresa tecnológica, la filosofía Clarity AIconsiste en acercarnos a los clientes allí donde trabajan, en lugar de exigirles que vengan a nosotros.

Nuestro enfoque centrado en las API hace que la capa de agentes sea una extensión natural de ese principio rector. Nuestra suite de MCP, que incluye uno diseñado para supervisar el cumplimiento de la cartera con respecto a los mandatos de inversión, integra los datos y la metodología Clarity AIdirectamente en las aplicaciones de IA o los sistemas internos que nuestros clientes ya utilizan. Estos MCP facilitan flujos de trabajo que se ejecutan de principio a fin con sencillas instrucciones en lenguaje natural, como «por favor, comprueba el cumplimiento de mi cartera con mi mandato de inversión».

Una sola frase redactada en un lenguaje sencillo pone en marcha todo un flujo de trabajo. A falta de especificaciones adicionales por parte del usuario, Claude analiza los requisitos de las instrucciones y, en respuesta, activa una serie de herramientas distintas, recabando las instrucciones del usuario y la composición de su cartera, realizando comprobaciones de cumplimiento a nivel de métricas y recopilando los resultados.

Los resultados se muestran en forma de tabla estructurada e interactiva dentro del chat, incluyendo los resultados de «aprobado/suspenso» a nivel de métricas y una lista de las empresas que incumplen los requisitos. Todos los valores pueden rastrearse mediante preguntas de seguimiento o a través de un enlace directo a la aplicación web Clarity AIpara realizar una investigación más exhaustiva.

Lo que antes requería navegar por un portal de datos, localizar la cartera y el mandato adecuados, interpretar los resultados a nivel de métricas, dar formato a los resultados y filtrar los casos de incumplimiento, ahora se resuelve con un solo intercambio.

Una aplicación web bien diseñada es la herramienta ideal para explorar datos, especialmente en el caso de preguntas abiertas en las que las ayudas visuales permiten al usuario moverse por un entorno lleno de posibilidades. Al fin y al cabo, muchas de las mejores preguntas surgen simplemente al explorar los datos. Sin embargo , el flujo de trabajo descrito anteriormente no es de carácter exploratorio.

El gestor de carteras conoce la pregunta, la cartera y el mandato, y quiere la respuesta. En este tipo de trabajo, en el que se buscan resultados concretos, incluso la interfaz mejor diseñada añade un paso de traducción en el que el usuario debe convertir una pregunta en lenguaje sencillo en una secuencia de clics. La arquitectura MCP elimina esa traducción y acorta el camino de la pregunta a la respuesta. El usuario formula la pregunta en el lenguaje que habría utilizado con un analista, y el sistema le da la respuesta en cuestión de segundos.

Esa integración depende de que el MCP realice tareas que el propio LLM no puede llevar a cabo por sí solo. Los modelos base como Claude cuentan con un enorme bagaje de conocimientos generales, pero carecen de los datos especializados y seleccionados, así como de la información con base metodológica, de los que dependen los sectores regulados.

Imaginemos a un gestor de carteras que gestiona un mandato basado en valores religiosos con una cartera de fondos.

Un modelo de lenguaje grande (LLM) de uso general con acceso a Internet tendría que identificar las carteras de cada fondo (que rara vez se hacen públicas y suelen estar desactualizadas en un trimestre), armonizar las convenciones de nomenclatura entre archivos PDF y fichas técnicas, localizar veinte valores métricos para cada una de las quizás cien posiciones por fondo, desglosar métricas compuestas que las empresas comunican de forma inconsistente, estimar valores para los que no divulgan información, normalizar las unidades según las normas de información y los calendarios fiscales, y mantener un registro de auditoría defendible ante los reguladores en cada paso. Eso supone 2.000 puntos de datos por fondo, en una cartera que puede contener docenas, sin una capa de gobernanza que arbitre las definiciones y sin forma de saber qué participaciones se han omitido silenciosamente porque los datos no se han podido encontrar o la página no se ha podido recuperar.

La tarea resulta estructuralmente imposible para un modelo que opera únicamente a través del acceso web. Por lo tanto, el MCP especializado actúa como el «impulso» que dota al razonador general de conocimientos específicos del ámbito, en este caso, sobre las carteras de fondos verificadas, los criterios de mandato, el contexto normativo y los datos codificados según la metodología que requiere el flujo de trabajo. 

Este es solo el primer paso básico hacia un valor verdaderamente transformador. Dado que este trabajo se ejecuta ahora dentro de una potente capa de aplicaciones repleta de posibles conexiones (horarios, bandejas de entrada, CRM, calendarios, etc.), puede integrarse en un flujo de trabajo automatizado de principio a fin. Una tarea programada en Claude puede ejecutar la misma comprobación cada mañana de lunes a viernes, señalar y justificar los cambios relevantes, redactar un resumen de acuerdo con tus directrices de estilo, adaptar los elementos visuales de las alertas al estilo de diseño de tu empresa y enviarlo a la bandeja de entrada del gestor de carteras antes de las 9 de la mañana.

Ese flujo de trabajo, que antes requería herramientas específicas o un esfuerzo manual considerable, se puede configurar en menos de treinta minutos. Eso es lo que hace posible la capa de agentes, la combinación de un modelo de lenguaje grande (LLM), los MCP y las habilidades.

Anatomía del flujo de trabajo de un agente: los cuatro elementos básicos

El flujo de trabajo descrito anteriormente se divide en cuatro elementos básicos. Cada uno de ellos realiza una tarea concreta. Por sí solos, ninguno es suficiente; es su combinación lo que los hace funcionar. A continuación se muestran esos elementos aplicados a un flujo de trabajo de supervisión de mandatos. Cada elemento básico va acompañado de un ejemplo concreto que puedes probar tú mismo.

Claude, el modelo de lenguaje grande (LLM), es el motor de razonamiento. Interpreta la solicitud, decide qué herramientas utilizar, las ordena, lee los resultados y redacta el texto final. El usuario no tiene que especificar nada de esto por adelantado.

Los MCP gestionan el acceso. Por ejemplo, un MCP de base de datos recupera la cartera y las posiciones de los fondos, los datos extrafinancieros y las metodologías asociadas, y realiza la comprobación de cumplimiento. Un conector de Gmail o Outlook envía la alerta. Las herramientas determinan a qué sistemas puede acceder el LLM.

Las habilidades determinan cómo debe ejecutar el sistema el trabajo. Orientan al modelo de lenguaje grande (LLM) para que realice una tarea de forma reproducible, siguiendo un conjunto específico de criterios, en lugar de hacerlo de manera ad hoc cada vez. En un ejemplo en el que a Claude se le proporcionan tanto una habilidad para redactar correos electrónicos como una para dar formato a informes, la primera codifica el tono preferido de la empresa; la segunda, cómo la empresa comunica sus análisis, como la estructura de un memorándum del comité de inversiones, el orden en que se exponen los riesgos y la forma en que se presentan las recomendaciones. Las habilidades permiten a los LLM aplicar realmente las formas de trabajo institucionales de las empresas.

La programación es el detonante. Transforma el flujo de trabajo de reactivo (tú lo solicitas) a proactivo (el sistema actúa según la cadencia que hayas establecido). Sin ella, la elaboración del informe de este ejemplo queda en suspenso, a la espera de que alguien se acuerde.

El resultado que se muestra a continuación es lo que generan esas primitivas cuando el usuario las integra: un informe de cumplimiento con la imagen corporativa en la bandeja de entrada del gestor de carteras antes de las 9 de la mañana, redactado con el estilo de la empresa, formateado según sus normas y utilizando datos verificados sobre carteras, mandatos y aspectos no financieros procedentes del sistema conectado a MCP, sin que nadie haya tenido que iniciarlo.

Por sí sola, cada unidad básica tiene sus limitaciones, pero al combinarlas, su efecto se multiplica. Si se elimina el calendario, el analista sigue teniendo que acordarse de activar el flujo de trabajo. Sin los conocimientos necesarios, el informe resulta genérico, poco práctico y aleatorio. Si se descarta el MCP, los datos o bien no están disponibles en absoluto o bien son totalmente poco fiables.

Por qué la calidad de los datos es el verdadero obstáculo en los flujos de trabajo basados en la inteligencia artificial

Los MCP no son mágicos. La calidad de los resultados que generan es un reflejo directo de la calidad de los datos de origen. En el ejemplo de flujo de trabajo detallado anteriormente, lo que importa es la calidad de los datos extrafinancieros y de las carteras. Si esos datos son dudosos, todo el flujo de trabajo carece de valor.

Cada uno de los elementos necesarios para la calidad de los datos constituye una disciplina en sí misma:

• El tratamiento de datos requiere una enorme capacidad computacional y operaciones de investigación primaria, además de avances en el aprendizaje automático para realizar estimaciones.
• La actualidad exige operaciones de datos continuas y específicas que abarquen los ciclos de captación, validación y actualización de miles de fuentes.
• El rigor metodológico exige un seguimiento normativo, un profundo conocimiento del sector y una gestión rigurosa de las versiones en miles de métricas.
• La auditabilidad requiere una infraestructura que conserve la trazabilidad a lo largo de todas las transformaciones, de modo que cualquier dato pueda remontarse hasta su origen.

Estas disciplinas no se derivan de un modelo más potente. Más bien, se desarrollan de forma lenta y deliberada, con un tipo de conocimiento especializado que no cabe en una ventana de contexto. La implicación es estructural. A medida que los modelos convierten el razonamiento en un producto básico, la ventaja competitiva se desplaza hacia el sustrato: los datos.

Más allá de la arquitectura: cuatro preguntas que hay que hacer a cualquier proveedor de IA

La arquitectura que se describe en este artículo es convergente. Todos los proveedores serios ofrecerán alguna versión de la misma en los próximos años. Por lo tanto, las preguntas que conviene plantear en las conversaciones con los proveedores deberían centrarse en qué elementos sustentan esa arquitectura.

Síguenos en LinkedIn o suscríbete a nuestro newsletter recibir Clarity AI .