Este artículo es la tercera parte de una serie dirigida a CEOs y gerentes generales de empresas medianas que han crecido más rápido que sus sistemas. En la primera parte analizamos por qué una empresa pierde control a medida que crece. En la segunda presentamos la metodología KAIROS 3-6-9+AMA, que prioriza los proyectos de inteligencia artificial por impacto y tiempo de implementación y convierte cada uno en una capacidad permanente de preguntar, monitorizar y actuar.
Esta tercera parte es la más técnica de la serie, pero el criterio sigue siendo empresarial: cada decisión de arquitectura debe justificar qué problema evita, qué coste introduce y qué impacto produce.
La tesis central se puede resumir en una línea: un agente de IA es tan confiable como el sistema que tiene debajo. La diferencia entre una demo que impresiona y una capacidad que la gerencia usa todos los días no está solo en el modelo de lenguaje. Está en la calidad de los datos, en la definición de las métricas, en los permisos y en la trazabilidad. Esta arquitectura es lo que hay debajo de lo que llamamos Agentic BI.
Por qué conectar un chatbot directamente al ERP no funciona
El punto de partida de muchas empresas medianas es previsible: ventas trabaja en el CRM, finanzas en el ERP, operaciones en un desarrollo interno, logística en hojas de cálculo y la gerencia en presentaciones armadas a mano.
Cada herramienta cumple su función. El problema aparece entre ellas.
La telaraña de integraciones
Cuando dos sistemas necesitan hablarse, alguien construye una exportación, una macro o una integración a medida. Con el tiempo, la empresa acumula conexiones con responsables, frecuencias y formatos distintos.
El coste no es solo de mantenimiento. También es de diagnóstico: cuando un número llega mal a un reporte, responder "¿de dónde salió?" implica reconstruir un recorrido que muchas veces nadie documentó. Y cuando se quiere añadir una nueva capacidad, como un agente de IA, no existe un punto único donde conectarla.
Definiciones que no coinciden
Para el ERP, una venta puede existir cuando se factura. Para el CRM, cuando se gana una oportunidad. Para la gerencia, cuando se cobra. Las tres definiciones pueden ser válidas y producir cifras distintas.
Mientras las interpretan personas, la organización compensa con notas al pie y contexto informal. Un agente de IA no dispone de ese contexto. Si existen tres versiones de "ventas del mes", elegirá una, mezclará varias o pedirá aclaraciones constantemente. La confianza se pierde en la primera respuesta incorrecta delante de la dirección.
El atajo del chatbot conectado a la base
Conectar un modelo de lenguaje directamente a la base del ERP suele funcionar bien en una demo porque las preguntas están preparadas. En producción aparecen cuatro problemas:
- El modelo consulta esquemas con cientos de tablas y nombres crípticos.
- No existen definiciones únicas para los conceptos de negocio.
- El control de acceso suele ser demasiado amplio.
- La respuesta no siempre deja una trazabilidad comprensible.
En muchos casos, el principal obstáculo ya no es la capacidad del modelo, sino la calidad y la gobernanza del sistema que tiene debajo.
La arquitectura AMA en una imagen
La arquitectura AMA se organiza en cinco capas: sistemas de origen, datos confiables, orquestación, control y visualización, e inteligencia y acción. Entre los datos y todo lo que los consume se sitúa la capa semántica, donde cada métrica del negocio se define una sola vez. A ello se suman dos ejes transversales: gobernanza y adopción.
Las capas no son un calendario de implementación. Son un orden de dependencias. Cada una hace confiable a la siguiente, pero el sistema se construye por rebanadas verticales: se toma un problema concreto, como cobranza o inventarios críticos, y se implementan solo las piezas necesarias para resolverlo de punta a punta.
Este enfoque evita el clásico proyecto de datos de doce meses y entrega valor visible en semanas. El riesgo es que cada rebanada vuelva a crear un silo. La forma de impedirlo es que todas compartan las mismas definiciones de negocio en la capa semántica.
1. Sistemas de origen: leer sin alterar la operación
La base de la arquitectura son las aplicaciones que la empresa ya utiliza: ERP, CRM, hojas de cálculo, desarrollos propios, plataformas SaaS, bases de datos operativas y, cuando aplica, sensores o sistemas de planta.
Para cada fuente relevante hay que responder cinco preguntas: cómo se accede, con qué frecuencia se actualiza, qué calidad tienen sus datos, quién es su propietario y qué información sensible contiene. También hay que definir qué fuente es autoritativa para cada dato.
Decisión: acceso de solo lectura por defecto. El objetivo es evitar modificaciones accidentales sobre los sistemas que operan el negocio. Este enfoque elimina el riesgo de escritura no autorizada y reduce la superficie de impacto, aunque sigue siendo necesario controlar la carga que las consultas pueden generar sobre los sistemas operativos.
Cuando el sistema necesita actuar, no escribe directamente en la base de datos del ERP o del CRM. Utiliza las APIs oficiales de cada aplicación, con credenciales específicas, permisos mínimos y registro de cada acción.
Impacto empresarial: se puede construir control y analítica sin interrumpir la operación ni obligar a reemplazar los sistemas existentes.
2. Datos confiables: una base analítica separada
¿Consultar las fuentes directamente o construir un almacén?
Consultar directamente una fuente puede ser suficiente para un tablero simple y evita duplicar datos. El problema aparece cuando las consultas son pesadas, se necesitan cruces entre sistemas o hay que conservar historia.
Decisión para el caso general: construir un almacén analítico separado.
- Protege la operación. El ERP está optimizado para transacciones cortas y concurrentes (OLTP); el análisis recorre millones de filas y las agrega (OLAP). Son cargas distintas que no deben competir por la misma base.
- Permite cruzar fuentes. Finanzas, ventas y operaciones pueden analizarse en conjunto.
- Centraliza permisos y auditoría. Existe un único punto de control.
- Conserva historia. Se pueden comparar periodos y detectar tendencias.
El coste aceptado es que los datos pueden ir minutos u horas por detrás de la operación. Para control de gestión suele ser suficiente. Para controlar una máquina en tiempo real, no.
Qué motor, y a qué escala
La decisión no debe basarse en el número de empleados, sino en el volumen de datos, la concurrencia, la latencia necesaria y la complejidad de las consultas. La carga analítica tiene un patrón propio: recorrer muchas filas y agregar unas pocas columnas.
Decisión: un motor analítico columnar (OLAP). DuckDB embebido para el volumen típico de una empresa mediana y ClickHouse cuando el volumen o la concurrencia lo exigen. El formato columnar responde a ese patrón: una agregación sobre tres columnas lee solo esas tres columnas comprimidas, no la tabla entera. DuckDB no añade infraestructura que operar, y el salto a ClickHouse se decide midiendo, no por anticipado.
Lo que descartamos en el rol analítico: una base de filas de propósito general, como PostgreSQL. Funciona a volumen pequeño, pero con el mismo esfuerzo de implantación el motor columnar responde mejor al patrón de consulta y evita una migración posterior. Los warehouses en la nube quedan para cuando la escala o la carga los justifican: adoptarlos antes de medir añade coste y complejidad sin garantizar una mejora real.
La calidad del dato como rutina
Las sincronizaciones deben ser repetibles, registrar cuándo se actualizó cada dato y detectar fallos de origen. Sobre esa base se deduplican clientes, se homologan productos, se unifican identificadores y se validan rangos.
La calidad del dato no es una limpieza inicial con fecha de cierre. Es un proceso continuo con reglas, responsables y alertas.
Impacto empresarial: la dirección deja de depender de reportes manuales y obtiene una base histórica común para analizar el negocio.
3. Capa semántica: definir el negocio una sola vez
La capa semántica es el lugar donde se definen las métricas y dimensiones del negocio: qué es una venta, cómo se calcula el margen, cuándo una factura está vencida o qué significa cliente activo.
Cada definición debe incluir fórmula, fuente, filtros, propietario y frecuencia de actualización.
Decisión: dashboards, alertas y agentes consumen métricas gobernadas por la capa semántica. Los productos de negocio no consultan tablas crudas. El acceso técnico a datos de detalle puede seguir existiendo para analistas e ingenieros, pero bajo permisos y controles específicos.
- Consistencia. El dashboard y el agente usan la misma definición.
- Trazabilidad. Los cambios quedan versionados y revisados.
- Confiabilidad para la IA. El agente elige entre métricas de negocio autorizadas, no entre cientos de tablas.
La capa semántica no tiene por qué ser una única herramienta. Puede combinar modelos de datos, métricas como código, catálogo, políticas de acceso y metadatos, siempre que exista una definición gobernada para cada concepto de negocio.
No elimina todos los errores, pero reduce el espacio de decisión del modelo y hace cada respuesta más detectable y auditable.
Impacto empresarial: disminuyen las reuniones dedicadas a discutir qué número es correcto y aumenta el tiempo disponible para decidir qué hacer.
4. Orquestación: convertir datos en procesos
Si la capa de datos es la memoria del sistema, la orquestación es su sistema nervioso. Cada flujo sigue el mismo patrón: detectar, consultar, decidir, actuar y registrar.
Para integraciones estándar, plataformas visuales como n8n o Make suelen ser suficientes. Reducen tiempo de desarrollo, hacen los flujos más visibles y simplifican el mantenimiento.
Cuando un proceso es crítico, de larga duración o requiere reintentos garantizados, estado durable y compensaciones, conviene utilizar un motor de workflows especializado.
La decisión debe basarse en el riesgo del proceso, no en la preferencia por una herramienta.
Ejemplo: cobranza
Cada mañana, un flujo consulta las facturas que superan los umbrales definidos por finanzas. Para cada cuenta crítica reúne historial de pagos, compromisos previos e interacciones comerciales recientes.
Las cuentas menores generan un recordatorio. Las relevantes producen una alerta con contexto. Las que tienen una oportunidad comercial abierta se derivan a revisión humana. Todo queda registrado: qué se detectó, qué información se utilizó, qué se decidió y qué respuesta hubo.
Este proceso ya produce valor sin IA. La inteligencia artificial mejora el análisis y la preparación de acciones, pero no sustituye una orquestación bien diseñada.
Impacto empresarial: disminuyen las tareas manuales, las omisiones y el tiempo entre detectar un problema y asignar una acción.
5. Control y visualización: una verdad operativa compartida
Los dashboards presentan la información para decidir y se alimentan de la capa semántica, no directamente de los sistemas de origen.
La vista ejecutiva debe mostrar pocas señales de decisión y permitir navegar desde el indicador hasta la causa y la acción. Un dashboard no es el punto final: alguien todavía tiene que ir a mirarlo.
Por eso esta capa se completa con alertas construidas sobre las mismas métricas. La combinación convierte el control de una actividad en un estado: la dirección no necesita revisar continuamente porque el sistema avisa cuando algo relevante cambia.
Impacto empresarial: se reduce el tiempo de reacción y se evita que los desvíos dependan de que alguien recuerde abrir un tablero.
6. Agentes de IA: responder, vigilar y preparar acciones
Con las capas anteriores en funcionamiento, añadir inteligencia artificial deja de ser un salto de fe. Se convierte en una ampliación controlada del sistema.
Qué es un agente
Un agente combina cuatro componentes verificables:
- un modelo de lenguaje;
- contexto de negocio;
- herramientas con permisos acotados;
- memoria del proceso y registro de acciones.
Si no se pueden identificar sus herramientas, permisos y trazabilidad, probablemente se trate de un chatbot con una capa de marketing.
Agente analítico
Responde preguntas como por qué cayó el margen, qué clientes concentran el riesgo o qué cambió respecto al trimestre anterior. Consulta métricas oficiales, compara periodos y explica de dónde sale cada cifra.
Estas mismas métricas gobernadas pueden consultarse desde Claude o ChatGPT a través de MCP (Model Context Protocol). La gobernanza vive en la capa semántica, no en la interfaz: sea cual sea la puerta de entrada, las definiciones y los permisos son los mismos.
Agente proactivo
Vigila indicadores, desviaciones, vencimientos y anomalías. Cuando detecta algo relevante, no se limita a avisar: prepara contexto, identifica causas y propone una acción.
Decisión: la autonomía se gradúa y se gana con precisión medida. El agente puede avanzar desde informar y recomendar hasta preparar, solicitar aprobación y, finalmente, ejecutar acciones acotadas. Cada peldaño requiere evidencia de que el anterior funciona de forma confiable.
Impacto empresarial: se reduce el tiempo entre dato, interpretación y decisión sin eliminar el control humano donde el riesgo lo exige.
Gobernanza y adopción: los dos ejes transversales
Gobernanza, seguridad y trazabilidad
La gobernanza atraviesa toda la arquitectura: solo lectura por defecto, permisos por rol, escrituras mediante APIs oficiales, credenciales específicas y registro de cada acción.
Cada acción de un agente debería poder responder seis preguntas: qué detectó, qué información utilizó, qué recomendó, quién autorizó, qué ejecutó y qué resultado produjo.
Ese registro no es burocracia. Es la base de la confianza, de la auditoría y de cualquier aumento posterior de autonomía. El tratamiento de datos debe cumplir el RGPD y permitir una configuración de residencia adecuada, el mismo criterio que aplicamos a la seguridad de los datos empresariales.
Adopción organizacional
Cada proyecto necesita un propietario del proceso, un usuario principal, responsables para cada alerta y métricas de uso. Consultas realizadas, alertas atendidas, recomendaciones revisadas y acciones aprobadas muestran si el sistema está siendo utilizado de verdad.
Un sistema técnicamente correcto que nadie incorpora a su rutina sigue siendo un proyecto fallido.
Cómo empezar sin un proyecto de doce meses
La primera rebanada suele centrarse en un problema concreto del horizonte 3, como cobranza, inventarios críticos o flujo de caja. Se conectan solo las fuentes necesarias, se definen las métricas de ese dominio, se orquesta el flujo, se publica la vista y se activa el agente en niveles bajos de autonomía.
Con un estado de datos razonable, esa primera capacidad puede estar operativa en tres o cuatro semanas, sujeto a lo que revele el diagnóstico inicial.
El valor acumulativo aparece a partir de la segunda rebanada. Cada proyecto reutiliza conexiones, catálogos, métricas, reglas y flujos de aprobación ya construidos. El coste marginal baja y la velocidad aumenta.
Decisiones de arquitectura e impacto en el negocio
| Decisión | Problema que evita | Impacto |
|---|---|---|
| Acceso de solo lectura | Alterar sistemas operativos | Menor riesgo de implantación |
| Almacén analítico separado | Consultas pesadas y datos fragmentados | Historia y análisis cruzado |
| Capa semántica | Métricas contradictorias | Una definición compartida |
| Orquestación explícita | Tareas manuales y fallos silenciosos | Menor tiempo de reacción |
| Alertas sobre métricas gobernadas | Dependencia de revisar dashboards | Control continuo |
| Autonomía gradual | Acciones prematuras o riesgosas | Más velocidad con supervisión |
Errores frecuentes
Comprar la herramienta antes de definir el problema. La tecnología debe elegirse después de entender qué decisión hay que mejorar.
Intentar ordenar todos los datos antes de entregar valor. La arquitectura debe crecer por rebanadas.
Tratar el dashboard como punto final. Sin alertas ni acciones conectadas, termina convertido en decoración.
Conectar IA a datos inconsistentes. Produce respuestas seguras en el tono e inseguras en el contenido.
Automatizar un proceso roto. La automatización acelera tanto lo bueno como lo malo.
Dar autonomía antes de medir precisión. Una sola acción equivocada puede destruir meses de confianza.
No asignar un propietario del resultado. Todo proyecto necesita un dueño en el negocio, no solo un responsable técnico.
Conclusión: la arquitectura es el medio, el control es el fin
Una empresa mediana no necesita esta arquitectura por amor a la tecnología. La necesita para pasar de perseguir información entre aplicaciones aisladas a preguntar, recibir alertas explicadas y aprobar acciones preparadas.
La secuencia es clara: visibilidad, control, optimización y autonomía supervisada. Construida por rebanadas, con valor visible desde el primer problema y reutilización creciente en los siguientes.
El primer paso no es implantar toda la arquitectura. Es identificar una decisión recurrente que hoy dependa de información dispersa y determinar qué fuentes, métricas y acciones necesita.
En el diagnóstico KAIROS mapeamos ese problema, identificamos la primera rebanada y definimos una arquitectura proporcional a la escala real de la empresa.
Preguntas frecuentes
¿Qué es una capa semántica y por qué importa para la IA?
Es el conjunto de definiciones gobernadas que establece cómo se calculan las métricas del negocio. Permite que dashboards, alertas y agentes utilicen la misma lógica y que cada respuesta pueda auditarse.
¿Necesito un data warehouse para usar agentes de IA?
Necesitas una base analítica separada cuando las preguntas cruzan varias fuentes, requieren historia o pueden afectar al rendimiento de los sistemas operativos. Para el volumen típico de una empresa mediana, un motor columnar embebido como DuckDB es suficiente como punto de partida; ClickHouse toma el relevo cuando el volumen o la concurrencia lo exigen.
¿Tengo que cambiar mi ERP o mi CRM?
No. La arquitectura puede leer los sistemas actuales y utilizar sus APIs oficiales cuando necesita ejecutar una acción.
¿Qué diferencia hay entre un chatbot y un agente de IA?
Un chatbot responde conversaciones. Un agente combina contexto de negocio, herramientas autorizadas, memoria de proceso y trazabilidad para analizar, vigilar y preparar o ejecutar acciones.
¿Cuánto tarda en estar operativa la primera capacidad?
Una primera rebanada acotada puede estar operativa en tres o cuatro semanas, dependiendo de la accesibilidad y calidad de las fuentes.
¿Quién controla lo que puede hacer el agente?
La empresa. Los permisos se definen por rol y proceso, las acciones críticas pueden requerir aprobación humana y todo queda registrado.
Para ampliar contexto: OLAP (Wikipedia) · Qué son los agentes de IA (Google Cloud) · Agente inteligente (Wikipedia).
Relacionado en Kairos: ChatGPT adivina qué significan tus datos · Power BI vs Agentic BI · Qué es Agentic BI · Seguridad de los datos · Cómo trabajamos · Agentes de IA sobre ERP y CRM.
Serie Control empresarial
Este artículo cierra el bloque técnico de la serie. En la primera parte analizamos dónde pierde el control una empresa que crece; en la segunda, cómo priorizar los proyectos de IA con la metodología KAIROS 3-6-9+AMA.
Ver todos los artículos de la serie