ERBAS: preguntarle a tu ERP como se lo preguntarías a un empleado

Imaginemos que un gerente llega por la mañana y pregunta:

¿Qué está pasando realmente en mi negocio?

No debería necesitar saber en qué aplicación está cada dato, qué módulo gestiona los pedidos o dónde consultar facturación, cobros, incidencias o inventario. Debería poder preguntar de una forma mucho más natural:

• ¿cómo vamos este mes?;
• ¿qué clientes deberían preocuparme?;
• ¿por qué ha bajado el margen?;
• ¿qué pedidos importantes están bloqueados?;
• ¿qué problemas requieren mi atención hoy?;
• ¿qué ha cambiado desde ayer?

Como se lo preguntaría a una persona que conoce la empresa.

Ésa es una de las ideas que está guiando ERBAS: no construir un chatbot encima de un ERP, sino una arquitectura en la que una IA pueda utilizar, de forma controlada, las capacidades y la información real de la empresa para responder preguntas sobre el negocio.

El usuario pregunta sobre su negocio, no sobre sus sistemas.

La dificultad no está en formular la pregunta

Un modelo de lenguaje ya puede entender una pregunta como:

¿Qué está pasando con el cliente ACME?

La dificultad empieza después. Para responder correctamente quizá haya que relacionar pedidos, facturas, cobros, incidencias, actividad comercial, inventario, proyectos o documentación corporativa, y esos datos pueden estar repartidos entre diferentes módulos o sistemas.

El gerente no debería tener que saberlo; la arquitectura sí. Responder sobre una empresa real implica resolver, al menos, cuatro problemas distintos:

1. quién está preguntando;
2. qué información puede conocer;
3. qué capacidades puede utilizar;
4. quién conserva finalmente la autoridad sobre la operación.

Seguridad en el centro

En ERBAS la seguridad no debería ser otro módulo situado al final del diseño. Debe estar en el centro, porque la misma pregunta puede producir respuestas diferentes dependiendo de quién la realiza.

Un director general puede tener acceso a información financiera y operativa que un técnico no necesita conocer. Un responsable comercial puede necesitar pedidos, actividad comercial y situación del cliente, pero no necesariamente toda la información financiera de la organización.

La IA no debería disponer de un permiso especial por el hecho de ser IA.

La IA nunca debería tener más permisos que la persona en cuyo nombre está actuando.

La identidad y los permisos del usuario forman parte del contexto de ejecución. No son información decorativa que se añade al prompt: son límites efectivos.

Estos tres ejes orbitan alrededor de la seguridad y permiten formular una regla que considero central para ERBAS:

El modelo interpreta. El software conserva la autoridad.

Primero arquitectura. Después IA.

Es fácil comenzar un proyecto de IA empresarial preguntando:

“Tenemos un LLM. ¿A qué datos lo conectamos?”

ERBAS intenta invertir la pregunta. Primero hay que decidir qué capacidades expone la empresa, mediante qué contratos, con qué permisos y bajo qué autoridad. Después podemos decidir cómo puede utilizar esas capacidades una IA.

Ese orden importa. Si conectamos primero el modelo y diseñamos después los límites, podemos terminar con una arquitectura difícil de asegurar, auditar y evolucionar.

La IA es un consumidor especialmente potente.

Pero sigue siendo un consumidor.

El agente conoce capacidades, no implementaciones

Supongamos que ERBAS necesita conocer la situación de un cliente. Conceptualmente debería poder utilizar una capacidad como:

getCustomerSituation(customerId)

Esa capacidad podría resolverse mañana mediante un módulo propio, PostgreSQL, SAP, un servicio externo, un data warehouse, otro ERP o una combinación de varios sistemas. El agente no necesita saberlo; necesita un contrato estable.

La arquitectura podría verse conceptualmente así:

Usuario
  │
  ▼
Identidad + permisos
  │
  ▼
ERBAS
  │
  ├──► capacidades del Core
  ├──► capacidades de módulos
  ├──► conocimiento autorizado
  └──► herramientas / plugins
              │
              ▼
       sistemas empresariales

El desacoplamiento permite que cada módulo evolucione sin obligar a reconstruir el agente. También permite sustituir tecnologías: si mañana cambia el sistema de facturación, el agente no debería tener que aprender de nuevo cómo funciona toda la empresa. Si el contrato permanece estable, ERBAS sigue sabiendo qué capacidad puede utilizar.

El agente conoce qué puede hacer. No necesita conocer cómo está implementado.

La misma pregunta no debería dar la misma respuesta a todos

Volvamos al ejemplo:

¿Qué está pasando con ACME?

La respuesta correcta depende de la identidad.

La diferencia no debería depender de que el modelo “recuerde” ocultar determinadas cosas. Debe depender de permisos reales. Por eso, para ERBAS, seguridad y contexto son parte de la arquitectura de la respuesta.

La información tampoco es una única bolsa de documentos

Cuando llegue el momento de incorporar conocimiento mediante RAG, tampoco quiero tratar toda la información de la empresa como un único repositorio indiscriminado.

Conceptualmente existen distintos ámbitos:

Conocimiento público
        │
Conocimiento corporativo
        │
Conocimiento por área / rol
        │
Conocimiento por usuario

El contexto disponible para una ejecución debería construirse a partir de aquello que el usuario puede conocer. Y además conviene separar dos tipos de información.

El conocimiento puede recuperarse. El estado del negocio debe consultarse.

Herramientas antes que acceso directo

Otra decisión importante es cómo llega la IA a los datos. No quiero un agente generando SQL contra las tablas del ERP ni accediendo directamente a la base de datos porque el modelo haya decidido que necesita una respuesta.

La frontera debe ser otra:

IA
 │
 ▼
tool / capability
 │
 ▼
Core
 │
 ├── autorización
 ├── validación
 ├── política
 ├── módulo
 └── auditoría
 │
 ▼
datos / servicio

La herramienta puede exponer una capacidad como:

wms.uoms.list

El agente puede decidir que necesita utilizarla, pero la ejecución real continúa pasando por el Core. En cada llamada vuelven a evaluarse permisos, disponibilidad del módulo y condiciones de ejecución.

La IA no recibe una puerta trasera.

Recibe capacidades controladas.

Esto ya ha dejado de ser únicamente una idea

Una parte importante de esta arquitectura ya se ha validado en la implementación .NET de ERBAS.

Actualmente existe un agente empresarial síncrono, agnóstico del proveedor, que trabaja únicamente con capacidades de lectura. El flujo implementado permite:

• descubrir las capacidades READ efectivas disponibles para el usuario;
• exponer esas capacidades como herramientas al modelo;
• dejar que el modelo seleccione una herramienta cuando la necesita;
• invocar la capacidad a través del Core;
• reevaluar permisos y disponibilidad del módulo en cada llamada;
• auditar tanto la interacción de IA como la ejecución de la capacidad.

La cadena completa ya se ha probado de extremo a extremo:

Angular
   │
   ▼
ERBAS .NET
   │
   ▼
modelo de IA
   │
   ▼
Core
   │
   ▼
capacidad WMS

En esa validación, el modelo pudo utilizar una capacidad real de lectura del WMS sin acceder directamente al módulo ni a su persistencia. Eso es más importante que la capacidad concreta utilizada en la prueba: lo relevante es haber validado la frontera arquitectónica.

Lo que todavía no está implementado

También es importante separar la visión de lo que existe hoy. En el estado actual, el agente es deliberadamente limitado y todavía no incorpora:

• RAG;
• conocimiento corporativo segmentado;
• plugins externos;
• memoria empresarial persistente;
• operaciones WRITE;
• flujos de aprobación para acciones sensibles.

Eso forma parte de la evolución prevista. No quiero añadir esas capacidades antes de disponer de una base suficientemente clara para controlarlas.

El objetivo no es conseguir cuanto antes un agente que haga muchas cosas.

Es conseguir una arquitectura en la que podamos ampliar lo que hace sin perder seguridad ni gobierno.

Del READ a una IA realmente operativa

La progresión natural puede ser gradual.

Primero:

pregunta
  ↓
consulta autorizada
  ↓
respuesta

Después pueden incorporarse nuevas capas:

conocimiento contextual
RAG
más capacidades READ
módulos adicionales
plugins

Y sólo cuando el modelo de autorización y gobierno sea suficientemente sólido:

acciones WRITE
  ↓
validación
  ↓
políticas
  ↓
aprobación cuando corresponda
  ↓
ejecución
  ↓
auditoría

Un gerente podría pasar de preguntar:

¿Qué pedidos importantes están bloqueados?

a solicitar:

Prepárame las acciones que deberíamos realizar para desbloquearlos.

Y, eventualmente, bajo políticas explícitas:

Ejecuta las que estén dentro de mis competencias y déjame para aprobación las demás.

La diferencia entre esas fases no es sólo funcional. Es una diferencia de riesgo y autoridad.

El objetivo no es tener una única base de datos

Para que un gerente pueda preguntar por toda la empresa, no es necesario meter toda la empresa dentro de una única base de datos. Eso crearía otro tipo de acoplamiento.

Lo que necesitamos es que las capacidades relevantes puedan descubrirse y utilizarse mediante contratos. La información puede seguir perteneciendo al sistema que tiene autoridad sobre ella; ERBAS proporciona una forma común de consultarla.

Por eso la experiencia ideal para el usuario puede ser unificada aunque la arquitectura interna siga estando desacoplada.

Una única conversación no requiere un único sistema.

Lo que debería ver un gerente

Toda esta arquitectura tiene sentido únicamente si termina simplificando el trabajo de la persona.

El gerente no debería ver:

• módulo WMS;
• servicio de facturación;
• repositorio documental;
• API de proyectos;
• base de datos comercial;
• motor RAG;
• plugins.

Debería poder decir:

Dime qué requiere mi atención hoy.

Y obtener una respuesta construida con la información que puede consultar legítimamente. Después podría preguntar por qué, profundizar en los clientes implicados o pedir acciones propuestas sin cambiar continuamente de sistema y sin conceder a la IA permisos que el usuario no posee.

ERBAS no pretende que la IA sustituya la arquitectura

Pretende exactamente lo contrario: que una buena arquitectura haga posible utilizar IA sin romper los límites del sistema.

Por eso los pilares terminan siendo poco exóticos:

• seguridad;
• información y contexto;
• desacoplamiento;
• gobierno y autoridad.

La IA se apoya sobre ellos.

No los sustituye.

Y quizá ésa sea la idea que mejor resume el proyecto:

Un gerente debería poder preguntarle a ERBAS por su empresa como se lo preguntaría a un empleado que conoce el negocio.

Pero con una diferencia fundamental: ese empleado digital puede consultar distintas capacidades de la organización en segundos, relacionar la información y explicar el resultado, siempre dentro de los límites de identidad, permisos y autoridad definidos por la empresa.

Primero arquitectura. Después IA.

Los modelos cambiarán. Los proveedores cambiarán. Las técnicas de RAG cambiarán. Aparecerán nuevos protocolos, herramientas y formas de construir agentes.

Pero la empresa seguirá necesitando responder las mismas preguntas:

• ¿quién está preguntando?;
• ¿qué puede conocer?;
• ¿qué puede hacer?;
• ¿qué sistema tiene autoridad?;
• ¿qué ocurrió exactamente?;
• ¿podemos auditarlo?

Si ERBAS consigue responder correctamente a esas preguntas desde la arquitectura, podremos cambiar muchas de las piezas que hay encima sin perder el control.

Ése es el objetivo: no construir una IA que conozca todos nuestros sistemas, sino una arquitectura en la que la empresa pueda hablar con su propia información sin tener que conocer dónde vive cada dato.