Susana López Blanco Después de un año construyendo proyectos de IA en la empresa, aparece un modelo que rinde mejor en varias tareas y cuesta menos. Tecnología propone probarlo. Al revisar lo construido aparecen las dependencias: parte de la lógica comercial está dentro de prompts, varias integraciones llaman directamente al proveedor anterior, cada aplicación recupera los datos por su cuenta y algunas decisiones solo se reconstruyen leyendo conversaciones antiguas.
El cambio termina exigiendo varias semanas de trabajo. Hay que rehacer conexiones, revisar instrucciones, reconstruir contexto y volver a probar procesos que ya estaban funcionando.
Una arquitectura de IA empresarial reduce ese trabajo separando los modelos de los recursos que la empresa seguirá necesitando cuando cambie la tecnología: datos, eventos, scorings, memoria, reglas, herramientas, resultados y casos de evaluación. Un modelo nuevo llega a una base que ya contiene la historia y las operaciones del negocio.
Al terminar deberías poder dibujar una arquitectura razonable, decidir qué piezas merece la pena construir primero y detectar proyectos donde la lógica empresarial ha quedado demasiado pegada a una herramienta. Uno o dos procesos reales bastan para empezar a ordenar lo que después utilizarán otras aplicaciones.
Índice de contenidos
Qué conviene conservar entre cambios de modelo
Un cliente lleva tres años con la empresa. Durante ese tiempo ha comprado dos productos, abierto incidencias, rechazado una renovación, negociado condiciones distintas y cambiado de interlocutor. En esos mismos tres años la compañía ha podido utilizar varios modelos de IA, sustituir su herramienta de automatización e incluso cambiar de CRM. La historia del cliente conserva valor a través de todos esos cambios.
Esa historia incluye identidad y relaciones, datos operativos, acontecimientos fechados, decisiones, documentos, reglas comerciales, predicciones y resultados. También incluye operaciones ya resueltas para consultar pedidos, actualizar oportunidades o solicitar aprobaciones.
Si el primer proyecto resuelve bien la identidad del cliente y crea una forma segura de consultar sus pedidos, el segundo empieza con ese trabajo hecho. Si cada aplicación crea sus propias conexiones y guarda conocimiento dentro de prompts o historiales, habrá que reconstruir una parte cuando llegue el siguiente proyecto.
| Componente | Ejemplo | Horizonte habitual | Dependencia deseable |
|---|---|---|---|
| Datos de negocio | Clientes, pedidos, productos, contratos | Largo | Bajo control de la empresa |
| Eventos | Compra, incidencia, renovación, aprobación | Largo | Bajo control de la empresa |
| Scorings | Riesgo, churn, propensión, prioridad | Medio/largo | Versionados y controlados |
| Memoria | Decisiones y antecedentes persistentes | Medio/largo | Accesible fuera del modelo |
| Herramientas | Buscar cliente, crear tarea, consultar pedido | Medio | Interfaces estables |
| Agentes y aplicaciones | Asistente comercial, soporte, reporting | Medio | Evolucionables |
| Modelos | LLM, visión, voz, modelos predictivos | Corto/medio | Sustituibles cuando compense |
| Frameworks | Librerías de agentes y automatización | Corto/medio | Dependencia limitada |
Los horizontes son orientativos. La tabla sirve para revisar dónde queda el trabajo pagado. Una integración común o una identidad bien resuelta se usan desde varios proyectos. Una conexión creada exclusivamente dentro de una aplicación habrá que mantenerla allí.
Una empresa necesita una versión utilizable de sus propios datos
El CRM utiliza un identificador. El ERP utiliza otro. Marketing y Ventas tampoco llaman lead exactamente a lo mismo. Soporte conoce incidencias que afectan a la relación comercial y apenas aparecen fuera de su aplicación.
Un agente conectado directamente a esas fuentes recibe las discrepancias tal como existen. El mismo cliente aparece con dos nombres, varias cifras de facturación o estados incompatibles. Pedir al modelo que reconcilie todo eso en cada ejecución desplaza un problema de datos al proyecto de IA.
Un data mart, entendido aquí como una representación ordenada de una parte del negocio, reúne lo necesario para un uso concreto. En ventas podría relacionar cliente, contactos, productos contratados, oportunidades, facturación, incidencias y métricas. Cada dato conserva procedencia y fecha de actualización.
La capa semántica fija significados compartidos. «Cliente activo», «ingreso recurrente», «oportunidad abierta» o «margen» deberían calcularse igual cuando los consulta un dashboard, una automatización o un agente. Si la definición cambia, guardar desde cuándo se aplica evita comparar cifras construidas con criterios distintos.
La aplicación siguiente que necesite saber quién es el cliente, cuánto factura o qué contratos mantiene consulta una representación ya resuelta. No vuelve a empezar por la reconciliación de CRM, ERP y hojas auxiliares.
En nuestro Máster en Data Science: Big Data e Inteligencia Artificial trabajamos esta relación entre preparación de datos, modelado y explotación posterior. Los errores de identidad, definición o fecha terminan llegando a cualquier modelo que consuma esos datos.
Los eventos explican cómo llegó la empresa hasta aquí
La ficha actual de un cliente describe su situación de hoy. Para reconstruir la relación hace falta el recorrido: compró el 3 de febrero, abrió una incidencia el 18, recibió una propuesta de renovación en mayo, la rechazó, cambió de interlocutor en julio y renovó en septiembre después de otra negociación.
Un registro de eventos conserva esa secuencia mediante acontecimientos fechados. Cada evento incluye la entidad afectada, cuándo ocurrió, de dónde procede y los datos necesarios para interpretarlo. También pueden quedar registradas las acciones generadas por aplicaciones de IA: recomendación, aprobación y resultado.
Con ese histórico se puede calcular cuánto tarda un cliente en renovar después de una incidencia, qué suele ocurrir antes de una baja o qué propuestas terminan aceptándose. Si cambia una métrica, los acontecimientos originales sirven para recalcularla con la nueva definición.
No hacen falta cientos de tipos de evento al principio. Compra, incidencia, propuesta, aceptación, rechazo y resultado cubren bastante terreno en muchos procesos. Ese registro servirá después para analítica, scorings y evaluación.
Los scorings convierten históricos en señales utilizables
Un scoring de churn asigna a un cliente un riesgo del 74 %. La cifra necesita fecha, versión y un periodo razonable de vigencia. En determinados usos también interesa conservar las variables que más influyeron en el cálculo.
El agente comercial consulta ese riesgo junto con tres incidencias recientes y las condiciones del contrato. Prepara una propuesta con esos datos. El modelo predictivo aporta una probabilidad y la aplicación la incorpora al resto del caso.
El 74 % aislado dice poco sobre la utilidad del modelo. Hace falta registrar lo que ocurrió después. Se recomendó llamar, el comercial contactó y el cliente renovó. Otro caso con riesgo parecido terminó en baja. Con suficiente histórico se puede comprobar cómo se comportaban las predicciones y qué acciones funcionaron después de recibirlas.
Guardar la versión evita mezclar scores producidos por modelos diferentes. La fecha evita utilizar una predicción antigua después de una negociación que cambió la situación. La calibración ayuda a interpretar la cifra: un 0,7314 no merece cuatro decimales de confianza por el mero hecho de que el software los haya calculado.
Los umbrales deberían llevar a acciones conocidas: priorizar una cuenta, revisar un caso, pedir más información o dejarlo en espera. El mismo score queda disponible para el dashboard comercial, el agente y una automatización que ordena tareas.
Dato, evento, scoring y memoria responden a preguntas distintas. El dato estructurado describe el estado actual. Los eventos reconstruyen lo ocurrido. El scoring estima un resultado futuro. La memoria guarda antecedentes que habrá que recuperar cuando una aplicación vuelva sobre aquella cuenta.
La memoria guarda antecedentes entre ejecuciones
Algunos antecedentes encajan mal como campo del CRM y tampoco justifican crear un documento. Un cliente rechazó una propuesta por una cláusula concreta. Se aprobó una excepción para una operación. Un equipo tomó una decisión que seguirá afectando al proceso cuando se reabra semanas después.
Esos recuerdos quedan asociados al cliente, proyecto o proceso y se recuperan cuando aportan contexto. El historial completo permanece fuera de la consulta.
RAG recupera documentación relacionada con la tarea. La memoria conserva antecedentes de ejecuciones anteriores. La selección de esos recuerdos, sus fechas, procedencia y actualización requieren un tratamiento propio, que desarrollamos en nuestra guía sobre memoria para agentes de IA.
Una puerta común reduce el trabajo de probar otro modelo
Una aplicación prioriza velocidad y coste. Otra procesa documentos complejos pocas veces al día. Otra necesita visión, voz, herramientas o unas condiciones de privacidad determinadas. Usar el mismo modelo para todas las tareas rara vez será una obligación técnica.
Cuando cada aplicación llama directamente a un proveedor, probar otro exige revisar credenciales, configuración, llamadas y pruebas proyecto por proyecto. Un model gateway concentra ese acceso. Las aplicaciones llaman a un servicio común que registra versiones, gestiona credenciales y dirige tareas según criterios como coste, latencia, calidad observada, privacidad o disponibilidad.
Los proveedores siguen teniendo funciones propias. Si una aplicación depende de una de ellas, mantendrá el adaptador correspondiente. La interfaz común concentra el trabajo repetido sin asumir que todos los modelos funcionan igual.
Un asistente comercial puede probar otra versión y seguir consultando los mismos clientes, scorings, documentos y herramientas. La modificación queda concentrada en menos puntos.
Los modelos necesitan herramientas estables para trabajar sobre la empresa
Para consultar pedidos, modificar una oportunidad o tramitar un reembolso hacen falta operaciones conectadas con CRM, ERP, soporte, facturación y otros servicios internos.
Las herramientas pueden expresarse con nombres que describan una operación concreta:
- buscar_cliente
- consultar_pedidos
- obtener_facturas
- crear_tarea
- actualizar_oportunidad
- solicitar_reembolso
Cada operación define qué recibe, qué devuelve, qué permisos exige y qué efecto produce. «Solicitar_reembolso» puede comprobar el importe y exigir aprobación antes de ordenar la devolución.
Si la empresa cambia de CRM, habrá que adaptar el conector. Las aplicaciones que ya utilizan «buscar_cliente» siguen llamando a la misma operación. El cambio se concentra en la integración con el nuevo CRM.
Las APIs siguen resolviendo buena parte de estas conexiones. MCP, Model Context Protocol, ofrece otra forma de publicar herramientas y recursos a aplicaciones compatibles. Su uso dependerá de los programas existentes, permisos y mantenimiento previsto.
Los agentes de IA en la empresa consumen estas operaciones para consultar información y ejecutar acciones. Si un proceso incorpora varios agentes, compartirán parte de estos recursos con permisos distintos. La coordinación entre ellos corresponde a la pieza específica sobre sistemas multiagente.
En nuestro Máster en Agentes IA y Automatización No-Code trabajamos agentes, workflows e integraciones sobre procesos empresariales.
El resultado de una acción debe volver al histórico
Un histórico alimenta un modelo de churn. El scoring marca riesgo elevado. El agente consulta acontecimientos recientes y prepara una recomendación. El comercial la revisa y llama al cliente.
El cliente acepta una modificación del servicio y renueva. La recomendación, la aprobación, el contacto, la respuesta y la renovación se registran como nuevos acontecimientos.
Con suficientes casos se puede comprobar si el scoring detectaba bien el riesgo y qué acciones obtenían mejores resultados. También aparecerán clientes que habrían renovado igualmente y campañas que apenas modificaron la decisión.
Queda registrada la secuencia completa: qué datos había, qué se predijo, qué se recomendó, qué acción se realizó y cuál fue el resultado.
En soporte pueden registrarse clasificación, respuesta y reapertura de la incidencia. En fraude, alerta, revisión y confirmación. Si una persona rechaza una recomendación y registra el motivo, varias correcciones parecidas señalarán dónde revisar el proceso.
Cómo comprobar si un modelo nuevo funciona mejor
Los benchmarks públicos sirven para conocer determinadas capacidades. La empresa necesita además casos construidos con sus contratos, abreviaturas, reglas, excepciones y tareas habituales.
Una muestra útil incluye casos sencillos, situaciones ambiguas, errores detectados en versiones anteriores y tareas donde equivocarse tiene consecuencias. El candidato se ejecuta sobre esa misma muestra y se compara en calidad, coste, latencia, cumplimiento de instrucciones y uso de herramientas.
En procesos completos interesa medir cuántas tareas terminan correctamente, cuántas requieren revisión y qué resultado obtiene el proceso. Prompt, modelo, configuración, herramientas y datos utilizados deben quedar versionados para poder reconstruir la prueba.
También se puede ejecutar el candidato sobre tráfico real sin darle permiso para realizar acciones. Sus resultados quedan disponibles para comparar con el modelo activo antes de sustituirlo. La misma colección de pruebas servirá cuando aparezca otra alternativa.
El diagnóstico detallado de ejecuciones, llamadas y errores intermedios pertenece al trabajo de observabilidad y merece una pieza propia. Para esta arquitectura hacen falta casos, versiones y resultados comparables.
Cómo empezar sin construir una plataforma para problemas que todavía no existen
Empezaría con uno o dos procesos productivos. Un asistente comercial y una automatización de soporte, por ejemplo. Primero resolvería las entidades que ambos necesitan —cliente, contacto, pedido, incidencia— y sus identificadores.
Después registraría los acontecimientos necesarios para reconstruir lo ocurrido. Los primeros scorings llegarían cuando una decisión concreta pudiera utilizarlos y existiera un resultado posterior con el que comprobarlos.
La documentación se conectaría cuando alguna aplicación necesitara recuperarla. Las herramientas aparecerían al tener que consultar o modificar aplicaciones internas. Una misma operación merece mantenerse cuando varios proyectos hacen exactamente lo mismo.
Los resultados volverían al histórico desde las primeras ejecuciones. La memoria se incorporaría allí donde un proceso necesite recuperar antecedentes entre sesiones. Los errores y casos representativos ampliarían la colección de evaluación. Un acceso común a modelos empieza a tener sentido cuando compararlos o sustituirlos obliga a repetir trabajo entre aplicaciones.
El primer proyecto puede dejar resuelta la identidad de cliente. Otro añade eventos que varias aplicaciones consultan. Un tercero crea una operación común para recuperar pedidos. Los casos donde una predicción acertó o falló quedan disponibles para evaluar la versión siguiente.
Dentro de unos años los modelos serán distintos. La empresa tendrá más clientes, operaciones y resultados registrados. Si esos recursos siguen accesibles desde las aplicaciones nuevas, probar otra tecnología exigirá modificar una parte del conjunto en lugar de reconstruirlo.
Preguntas frecuentes sobre arquitectura de IA empresarial
¿Qué es una arquitectura de IA empresarial?
Es la organización de los datos, eventos, herramientas, memoria, modelos y evaluaciones que utilizan las aplicaciones de IA de una empresa. Define dónde vive cada recurso y cómo lo consultan las aplicaciones. Una estructura común reduce el trabajo que hay que repetir entre proyectos.
¿Qué datos debería controlar una empresa?
Los que describen clientes, operaciones, productos, procesos y resultados deberían conservar identidad, procedencia, permisos y fecha de actualización. Distintas aplicaciones trabajan así sobre las mismas entidades y definiciones.
¿Para qué sirve un data mart en proyectos de IA?
Reúne una parte del negocio en una representación utilizable. En ventas puede relacionar cliente, contratos, oportunidades, facturación, incidencias y métricas. Evita reconstruir esas relaciones cada vez que una aplicación necesita consultar la cuenta.
¿Qué papel tienen los scorings junto a los LLM?
Un scoring resume una predicción, como riesgo de abandono o probabilidad de compra. El agente consulta esa señal junto con datos y documentación del caso. Guardar fecha, versión, acción y resultado posterior ayuda a comprobar después cómo funcionaba la predicción.
¿Cómo se reduce el trabajo al cambiar de modelo?
Los datos, herramientas, memoria y casos de evaluación permanecen fuera del modelo. Si varias aplicaciones acceden además a los modelos desde un punto común, probar otra versión exige modificar menos integraciones.
¿Dónde encajan RAG y memoria?
RAG recupera documentación relacionada con una tarea. La memoria conserva antecedentes útiles entre ejecuciones. Ambos se consultan junto con datos estructurados, eventos y scorings cuando una aplicación necesita ese contexto.
¿Hay que construir toda la arquitectura antes de empezar con agentes?
No. Uno o dos procesos productivos bastan para empezar a ordenar identidades, registrar eventos y crear herramientas comunes. Otras piezas se incorporan cuando aparece una necesidad concreta y existe trabajo suficiente para justificar su mantenimiento.