Dependencia directa del proveedor
Una integración directa entre el backend y un proveedor de LLM aumentaría el acoplamiento y dificultaría cambiar de proveedor o modelo en el futuro.
CASO DE ESTUDIO / 03
Integración de LLM. IA · APIs · Arquitectura.
Una empresa de servicios de alimentos cuenta con una plataforma que concentra información sobre ventas, clientes y comportamiento de consumo. Ante el crecimiento del volumen de datos, busca incorporar capacidades de inteligencia artificial generativa para facilitar su análisis y obtener nuevas formas de aprovechar la información del negocio.
DESCUBRIMIENTO
Problema descrito por el cliente.
El equipo de marketing busca identificar patrones de consumo a partir del historial de ventas y comprender con mayor facilidad qué productos, servicios y comportamientos tienen mayor relevancia para el negocio. Actualmente, gran parte de esta información se encuentra distribuida entre un volumen elevado de datos, lo que dificulta detectar relaciones y tendencias que podrían ser útiles para la toma de decisiones.
ARQUITECTURA ACTUAL
Arquitectura actual del sistema
La plataforma está construida sobre una arquitectura centralizada. Un único backend desarrollado con Spring Boot concentra las operaciones de clientes, ventas, facturación, inventario e integraciones externas, utilizando una misma base de datos PostgreSQL para almacenar y consultar la información del sistema. La arquitectura actual no contempla una capa específica para integrar capacidades de inteligencia artificial ni mecanismos orientados a controlar el acceso de estos servicios a la información del negocio.
CLIENT
Frontend
Interfaz de usuarios
APPLICATION
Spring Boot
Clientes · Ventas · Facturación · Inventario · Integraciones Externas
DATABASE
PostgreSQL
Datos transaccionales y reporting
ANÁLISIS
Hallazgos de la investigación
El análisis de la arquitectura actual permitió identificar distintos desafíos para incorporar capacidades de inteligencia artificial. La información del negocio se encuentra concentrada en la aplicación y en la base de datos, por lo que una integración directa con un modelo podría generar problemas de seguridad, acoplamiento, costos y control sobre el uso de los datos.
Contexto y datos
El modelo necesita información relevante para responder, pero no debería tener acceso indiscriminado a la información almacenada en la base de datos.
Costos y consumo
Cada interacción con el modelo puede implicar costos, latencia y límites de consumo que deben ser considerados dentro de la arquitectura.
Seguridad
La información enviada al modelo debe estar sujeta a controles que permitan definir qué datos pueden utilizarse y bajo qué condiciones.
Fallos externos
El LLM es un servicio externo que puede presentar timeouts, errores, indisponibilidad o respuestas inesperadas, por lo que estas situaciones deben contemplarse dentro de la arquitectura.
EXPLICACIÓN TÉCNICA
¿Cómo integramos el LLM?
El análisis combinó la revisión del funcionamiento del sistema con el estudio de su estructura interna. A partir de los hallazgos se definieron los puntos de integración, los datos necesarios y los controles requeridos para incorporar capacidades de inteligencia artificial sin comprometer la evolución del sistema existente.
Revisión del sistema existente
Se revisó cómo se organiza el sistema y cómo interactúan sus componentes para identificar dónde se encuentra la información necesaria para los primeros casos de uso de inteligencia artificial.
Puntos de integración
Se analizaron los puntos de interacción existentes para determinar dónde incorporar una capa capaz de coordinar las solicitudes hacia los servicios de inteligencia artificial sin acoplarlos directamente al núcleo de la aplicación.
Datos y casos de uso
Se trabajó con el equipo de marketing para definir los objetivos de la primera interacción con la IA y determinar qué información del negocio era realmente necesaria para alcanzarlos.
Proveedor y modelo
Una vez definidos los casos de uso y sus requisitos, se evaluaron los modelos y proveedores disponibles considerando capacidades, latencia, límites de consumo y costos.
Seguridad y control de datos
Se definieron controles para determinar qué información puede utilizarse como contexto y qué datos deben permanecer fuera de las solicitudes enviadas al modelo.
Observabilidad
Se consideraron mecanismos para registrar y monitorear las interacciones con el servicio de IA, permitiendo detectar errores, tiempos de respuesta, consumo y comportamientos inesperados.
Costos y resiliencia
Finalmente, se evaluaron los costos y los posibles fallos del servicio externo, definiendo límites y comportamientos alternativos para que la aplicación pueda continuar operando ante errores o indisponibilidad del modelo.
ARQUITECTURA PROPUESTA
Una capa de IA desacoplada del sistema principal.
La propuesta incorpora un servicio específico para gestionar la interacción con modelos de inteligencia artificial. El AI Service actúa como una capa intermedia entre el sistema principal y los servicios necesarios para procesar cada solicitud, permitiendo controlar el contexto, las políticas de acceso, el uso de información previa y la comunicación con el proveedor de LLM.
CLIENT
Frontend
Interfaz de usuarios
API
API / CORE
Entrada y distribución de solicitudes
AI SERVICE
AI Service
Coordinación de solicitudes hacia la IA
CONTEXT
Contexto
Datos relevantes · Prompt
POLICIES
Políticas
Reglas y control de datos
CACHE
Cache
Información de consultas previas
LLM
Proveedor de LLM
Servicio externo de inteligencia artificial
El AI Service concentra la coordinación de las solicitudes y conecta el sistema principal con los distintos componentes necesarios para procesar una interacción con el modelo.
DECISIONES ARQUITECTÓNICAS.
¿Por qué tomamos esas decisiones?
El LLM queda aislado detrás de un servicio propio. El sistema principal no depende directamente del proveedor. El acceso a información se controla desde la aplicación. Las llamadas al modelo tienen límites y políticas. La integración puede evolucionar independientemente. El proveedor de LLM puede cambiar sin modificar todo el sistema.
PROPUESTA
Roadmap de implementación
La implementación se plantea de forma incremental, comenzando por definir los límites de la integración y construyendo sobre ellos el servicio de IA. De esta manera, el primer caso de uso puede validarse antes de ampliar las capacidades del sistema.
01
FASE 1
Preparar integración
Definir los primeros casos de uso, identificar los datos necesarios y establecer los límites de información que podrán utilizarse como contexto.
02
FASE 2
Crear AI Service
Implementar la capa responsable de coordinar las solicitudes, gestionar el contexto y comunicarse con el proveedor de LLM sin acoplarlo directamente al sistema principal.
03
FASE 3
Incorporar primer caso de uso
Implementar un caso de uso concreto definido junto al equipo de marketing y utilizarlo para validar el funcionamiento de la integración antes de ampliar sus capacidades.
04
FASE 4
Agregar seguridad y observabilidad
Incorporar controles sobre los datos utilizados, registrar las interacciones con el servicio y monitorear errores, tiempos de respuesta y consumo.
05
FASE 5
Optimizar costos y rendimiento
Evaluar el consumo real de la solución y optimizar modelos, contexto, cache y frecuencia de llamadas para alcanzar un equilibrio entre costo, rendimiento y calidad.
06
FASE 6
Expandir capacidades
Incorporar nuevos casos de uso sobre la misma arquitectura, aprovechando la infraestructura existente sin duplicar la integración con el proveedor de IA.
CIERRE
Integrar IA también es una decisión arquitectónica.
Incorporar un LLM no consiste simplemente en enviar un prompt a un modelo. Requiere definir cómo se integra con el sistema, qué información puede utilizar, cómo se controlan sus interacciones y cómo se prepara la solución para evolucionar junto con las necesidades del negocio.