Ir al contenido

Arquitectura de Referencia de 7 Capas

Los AI Agents empresariales necesitan más que un LLM. Esta arquitectura separa interfaz de usuario, orquestación, agentes, lógica de decisión, modelos, integración e infraestructura en siete capas independientes. La gobernanza atraviesa todas las capas como componente transversal.

Una selección de más de 5.000 proyectos en 25 años de desarrollo de software

Airbus Volkswagen Shell Renault Evonik Vattenfall Philips KPMG

Por qué siete capas

Un sistema de IA monolítico no es auditable, no es escalable y no se puede mantener. La arquitectura de 7 capas separa responsabilidades: cada capa tiene una función definida y interfaces claras. Un cambio de modelo no altera la lógica de negocio. Un nuevo sistema destino no modifica el agente. Un nuevo requisito de cumplimiento normativo no cambia la infraestructura.

La arquitectura es el resultado de requisitos empresariales: aislamiento de inquilinos, Audit Trail, transparencia para el Comité de Empresa (Art. 64 Estatuto de los Trabajadores), conformidad con el EU AI Act supervisada por la AESIA, cumplimiento del RGPD y la LOPDGDD, y despliegue agnóstico de modelos. Las APIs estándar de LLM no proporcionan nada de esto.

Arquitectura de Referencia: 7 capas con Gobernanza como componente transversal - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure

1. Presentation Layer

La interfaz entre el sistema y el usuario. Sin lógica de negocio, sin decisiones - solo visualización y entrada.

  • Chat UI: Interfaz web para usuarios finales (gestores de RRHH, contables). Compatible con PWA, responsiva.
  • Dashboard: Vista de estado de agentes, workflows activos, escalaciones pendientes. Basado en roles: los gestores ven sus casos, los directores ven indicadores.
  • Auditor Portal: Acceso para auditores al Audit Trail, controles y evidencias. Solo lectura. Para auditores de cuentas, el Comité de Empresa y revisión interna.
  • REST API: Interfaz legible por máquina para integración con sistemas existentes. Versionada, documentada, autenticada.

2. Orchestration Layer

Coordina el flujo de datos entre agentes, sistemas y usuarios. Gestiona workflows, colas y enrutamiento de APIs.

  • Motor de Workflow: Motores open source (Trigger.dev, Camunda) para procesos complejos y multietapa. Workflows visuales, integración de APIs, webhooks.
  • API Gateway: Punto de entrada unificado con Rate Limiting, autenticación, logging y monitoring.
  • Sistema de Colas: Procesamiento asíncrono para procesos batch (cierre mensual, importación masiva).
  • Sistema de Eventos: Reacción en tiempo real a documentos entrantes, cambios de estado y escalaciones.

3. Agent Layer

AI Agents especializados que ejecutan tareas profesionales. Cada agente tiene un ámbito de responsabilidad definido y opera dentro de los límites que establece el Decision Layer.

Document Agents

Leen, comprenden y procesan documentos con verdadera comprensión del lenguaje. Facturas, partes de baja, contratos, certificados, justificantes. Sin reconocimiento de plantillas, sin reglas rígidas - comprensión contextual.

Workflow Agents

Orquestan procesos entre múltiples sistemas. Cuando se necesita leer un documento, tomar una decisión y ejecutar una acción en un sistema destino - el Workflow Agent coordina el flujo completo.

Knowledge Agents

Proporcionan respuestas contextuales basadas en el conocimiento empresarial. Acuerdos de empresa, políticas internas, convenios colectivos, normas de cumplimiento. Cada respuesta incluye la fuente y la versión de la norma aplicada.

4. Decision Layer

Descompone cada proceso de negocio en pasos de decisión individuales y define para cada paso: persona, conjunto de reglas o IA. Cada decisión queda documentada - verificable por auditores de cuentas, el Comité de Empresa y revisión interna.

Rules Engine: Conjuntos de reglas de negocio, versionados y trazables. Convenios colectivos, acuerdos de empresa, lógica contable, normas de cumplimiento. Cada regla tiene una versión, una fecha de vigencia y un ámbito de aplicación.

Confidence Routing: Evaluación automática del nivel de confianza de la decisión. Confianza alta y riesgo bajo: decisión autónoma. Confianza baja o riesgo alto: escalación a persona.

Human-in-the-Loop: Revisión humana arquitectónicamente impuesta para determinados tipos de decisión. Riesgo de sesgo, potencial de discriminación, temas sujetos al derecho de información y consulta del Comité de Empresa (Art. 64 ET).

Audit Trail - el acta de decisión: Documentación completa e inmutable de cada decisión. Por microdecisión, un acta de decisión: input, modelo, evaluación, regla de negocio con su versión, resultado, marca temporal y vía de impugnación. Solo adición - y con ello la respuesta arquitectónica al derecho del afectado a la explicación de la decisión individual conforme al art. 86 del EU AI Act.

Profundizar: Decision Layer en detalle · Tres tipos de decisiones IA · El acta de decisión

5. Model Layer

La capa LLM. Intercambiable, agnóstica respecto a modelos, desacoplada de la lógica de negocio.

Cloud LLMs

Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - a través de regiones UE de los respectivos proveedores cloud.

LLMs Open Source / Open Weight

Llama (Meta), Mistral, DeepSeek, gpt-oss (OpenAI, Apache 2.0) - completamente self-hostable en hardware propio. gpt-oss-120B funciona en una única GPU H100, gpt-oss-20B en 16 GB de hardware de consumo.

Híbrido

LLMs cloud para casos estándar, LLMs self-hosted para datos sensibles. Enrutamiento automático según la clasificación de datos.

La elección del modelo es un equilibrio entre rendimiento, costes, protección de datos y latencia. El Model Layer es intercambiable - un cambio de modelo no altera la lógica de negocio de las capas superiores.

Opciones concretas de hosting, requisitos de hardware y stack tecnológico: AI Infrastructure en detalle

6. Integration Layer

La conexión con los sistemas empresariales existentes. El agente no sustituye sistemas - los amplía.

Categoría de sistema Integración
ERP / FinanzasSAP FI/CO, SAP S/4HANA, DATEV, Oracle Financials
RRHH / NóminasSAP SuccessFactors, Workday, Personio
ColaboraciónSharePoint, Microsoft Teams (via Microsoft Graph)
DMS / ECMSharePoint, d.velop, ELO, nscale
OtrosCualquier sistema con interfaz REST o SOAP

La lógica del agente está desacoplada del sistema destino. La lógica contable está separada de la exportación. Si cambia el sistema destino (por ejemplo, de DATEV a SAP), cambia el Export Layer, no el agente.

7. Infrastructure Layer

El fundamento de despliegue. Toda la arquitectura se ejecuta en la infraestructura del cliente - no en Gosign, no en un tercero.

  • Cloud (UE): Azure, AWS o GCP - exclusivamente regiones UE. Kubernetes gestionado, bases de datos gestionadas, hosting de LLM.
  • Managed UE: Vercel EU + Supabase EU. Opción ligera en la UE sin infraestructura Kubernetes propia.
  • Self-Hosted: Servidores propios, centro de datos propio. Docker/Kubernetes, LLMs open source en GPUs propias. Total independencia del Cloud Act.
  • Híbrido: Combinación según clasificación de datos. Cargas sensibles en self-hosted, cargas estándar en cloud.

Todas las capas por encima de la capa de infraestructura permanecen idénticas, independientemente del modelo de despliegue.

Regiones cloud, dimensionamiento de hardware, stack tecnológico: AI Infrastructure en detalle

Gobernanza como componente transversal

La gobernanza no es una capa individual, sino que atraviesa toda la arquitectura. Cada capa genera datos de gobernanza, cada capa es controlada por reglas de gobernanza.

  • Presentation: Acceso basado en roles, Auditor Portal
  • Orchestration: Logging de workflows, documentación de escalaciones
  • Agent: Las decisiones de agentes generan entradas de Audit Trail
  • Decision Layer: Rules Engine, Confidence Routing, Human-in-the-Loop
  • Model: Seguimiento de versiones de modelo, hashing de entradas, reproducibilidad
  • Integration: Logging de interfaces, documentación de flujos de datos
  • Infrastructure: Cifrado, Row-Level Security, aislamiento de inquilinos

EU AI Act · Cert-Ready by Design · Codeterminación · Data Residency

Runtime y escalabilidad

El funcionamiento en producción no es un trabajo posterior, sino un componente arquitectónico. La arquitectura de 7 capas está diseñada para operar bajo carga.

  • Orquestación de contenedores: Despliegue basado en Kubernetes. Cada capa funciona en sus propios contenedores, escalables de forma independiente.
  • Escalabilidad horizontal: El Agent Layer y el Model Layer escalan horizontalmente según la carga. Un nuevo agente significa más pods, no más arquitectura.
  • Health Checks y Self-Healing: Liveness y Readiness Probes en todos los contenedores. Reinicio automático en caso de fallo, redirección automática en caso de sobrecarga.
  • Monitoring y Alerting: Métricas Prometheus en todas las capas. Dashboards Grafana para latencia, throughput, tasas de error y profundidad de colas. Alertas al superar umbrales.
  • CI/CD: Despliegues basados en GitOps. Infrastructure as Code (Terraform/Pulumi). Tests automatizados, Blue-Green o Canary Deployments.

Arquitectura de datos

Los datos fluyen a través de las siete capas. La arquitectura define dónde se generan los datos, cómo se almacenan y quién tiene acceso.

  • Flujo de datos: Input (documento, consulta) - Agent (análisis) - Decision Layer (decisión) - Integration (exportación al sistema destino). Cada paso genera una entrada de Audit Trail.
  • Vector Store: PostgreSQL con pgvector para búsqueda semántica (RAG). El conocimiento empresarial se almacena como embeddings, sin enviarse a servicios externos.
  • Aislamiento de inquilinos: Row-Level Security (RLS) a nivel de base de datos. Impuesto arquitectónicamente, no mediante lógica de aplicación. Cada inquilino está completamente aislado.
  • Cifrado: En reposo (AES-256) y en tránsito (TLS 1.3). Gestión de claves a través del proveedor de identidad del cliente o módulos de seguridad de hardware (HSM).
  • Retención de datos: Configurable según requisitos. La obligación de conservación fiscal y el derecho de supresión del RGPD Art. 17 se resuelven mediante anonimización en lugar de eliminación.
  • Backup y Recovery: Copias de seguridad automatizadas, Point-in-Time Recovery. Recovery Point Objective (RPO) y Recovery Time Objective (RTO) se configuran por inquilino.

Arquitectura de interfaces

La arquitectura se comunica a través de interfaces definidas - internamente entre capas y externamente con sistemas de origen y destino.

  • REST API: APIs versionadas (v1, v2) con documentación OpenAPI. Cambios incompatibles solo en versiones nuevas; las versiones anteriores se mantienen en paralelo.
  • Event-Driven: Procesamiento de eventos basado en webhooks para reacción en tiempo real. Documento entrante - evento - agente procesa. Sin polling, sin retardo batch.
  • MCP (Model Context Protocol): Protocolo estandarizado para integración de herramientas en agentes LLM. Los agentes acceden a herramientas externas a través de MCP - tipadas, documentadas, auditables.
  • Procesamiento batch: Para operaciones masivas (cierre mensual, liquidación anual, importación masiva). Basado en colas con seguimiento de progreso y gestión de errores.
  • API Gateway: Punto de entrada central. Autenticación (SSO/OIDC), Rate Limiting, logging de peticiones, monitoring. Desacopla la arquitectura interna de los consumidores externos.

Principios de diseño

Agnóstico de modelos: Sin vendor lock-in con un único LLM. Los modelos son intercambiables. Hoy Claude, mañana gpt-oss, pasado mañana un modelo que hoy aún no existe.

Agnóstico de infraestructura: La misma arquitectura en Azure, AWS, GCP, self-hosted o híbrido. La elección de infraestructura es una decisión del cliente, no de la arquitectura.

Agnóstico de sistemas: La lógica del agente está desacoplada del sistema destino. Lógica contable separada de exportación. Un cambio de sistema modifica el Integration Layer, no el agente.

Governance by Design: Audit Trail, RBAC, Decision Layer y Human-in-the-Loop son componentes arquitectónicos - no funcionalidades opcionales que se añaden después.

Cert-Ready by Design: Los controles son objetos de datos de primera clase con generación automática de evidencias. ISO 27001, PS 951, SOC 2 - la arquitectura genera las pruebas.

Acceso al código: Acceso completo al código fuente, todos los prompts y conjuntos de reglas. Las configuraciones y conjuntos de reglas permanecen con el cliente. Stack open source donde sea posible. Tras 12-18 meses, el cliente opera los agentes de forma independiente.

Decision Layer - Flujo de decisión

+-----------+    +--------------+    +----------------+
|  Input    |--->|  AI Agent    |--->| Decision Layer |
|(documento |    |  analiza,    |    |                |
| consulta) |    |  comprende,  |    |  Verificar     |
+-----------+    |  evalua      |    |  reglas        |
+--------------+    |                |
|  Evaluar       |
|  confianza     |
|                |
|  Decidir       |
|  enrutamiento  |
+-------+--------+
|
+-------------+--------------+
|                            |
+--------v--------+        +----------v----------+
| Autonomo        |        | Human-in-the-Loop   |
|                 |        |                     |
| Alta confianza  |        | Riesgo de sesgo     |
| Bajo riesgo     |        | Baja confianza      |
| Sin restriccion |        | Restriccion activa  |
| normativa       |        | Consulta al Comite  |
+--------+--------+        +----------+----------+
|                            |
|         +--------------+   |
|         |  Persona     |   |
|         |  decide      |<--+
|         +------+-------+
|                |
+--------v----------------v--------+
|         Audit Trail              |
|  Input - Modelo - Regla -        |
|  Evaluacion - Resultado -        |
|  Marca temporal                  |
+----------------------------------+
|
+--------v--------+
|  Sistema        |
|  destino        |
|  (ERP, RRHH,    |
|   Nominas)      |
+-----------------+
Flujo esquemático de decisión a través del Decision Layer. En el entorno de producción, cada paso se documenta como entrada de Audit Trail.

Para profundizar

Implementación

AI Infrastructure

Tecnologías concretas, regiones cloud, dimensionamiento de hardware, tabla de stack tecnológico.

Infraestructura en detalle →

Recurso de conocimiento

Blueprint 2026

Once artículos sobre las decisiones de infraestructura que importan en 2026.

A la serie de artículos →

Agentes

AI Agents

Document Agents, Workflow Agents, Knowledge Agents - tres tipos de agentes para procesos empresariales.

Explorar AI Agents →

Governance

Marco de Governance

EU AI Act, Cert-Ready, Codeterminación, Data Residency - todos los temas de governance en un vistazo.

Vista general Governance →

Preguntas frecuentes sobre la Arquitectura de Referencia

¿Por qué una arquitectura propia en lugar de APIs estándar de LLM?

Las APIs estándar de LLM proporcionan comprensión del lenguaje, pero no gobernanza, ni Audit Trail, ni aislamiento de inquilinos, ni modelo de roles. La arquitectura de 7 capas es la capa entre el LLM y el sistema empresarial que proporciona exactamente eso. Sin esta capa, cualquier LLM sigue siendo un experimento.

¿La arquitectura es agnóstica respecto a modelos?

Sí. El Model Layer es intercambiable. Actualmente soportados: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. Se integran nuevos modelos sin modificar las capas superiores. Sin vendor lock-in con ningún LLM individual.

¿Cómo escala la arquitectura bajo carga creciente?

Cada capa escala de forma independiente. El Agent Layer y el Model Layer pueden escalar horizontalmente sin modificar el Decision Layer ni la integración. El despliegue basado en Kubernetes permite auto-scaling según la carga.

¿Cómo se garantiza el aislamiento de inquilinos?

A nivel de base de datos mediante Row-Level Security (RLS). Cada inquilino ve exclusivamente sus propios datos, reglas y Audit Trails. La separación es arquitectónicamente impuesta, no solo mediante lógica de aplicación.

¿Se puede introducir la arquitectura de forma gradual?

Sí. Las capas están desacopladas. Un punto de entrada típico: un agente (por ejemplo, Document Agent) con Decision Layer, conectado a un sistema existente. Agentes adicionales, integraciones y funciones de gobernanza se añaden gradualmente.

¿Qué diferencia esta página de la página de infraestructura?

Esta página describe el patrón arquitectónico - qué capas existen y por qué. La página de infraestructura describe la implementación concreta - qué tecnologías, qué regiones cloud, qué hardware. La arquitectura es el qué, la infraestructura es el cómo.

Assessment de arquitectura para su empresa

Analizamos su panorama de sistemas existente y le mostramos cómo la arquitectura de 7 capas encaja en su infraestructura.

Agendar reunión