Las organizaciones que desarrollan aplicaciones impulsadas por inteligencia artificial (AI) enfrentan un desafío recurrente: brindar a los agentes de modelo de lenguaje grande (LLM) acceso a lagos de datos empresariales sin duplicar la lógica de integración en cada agente y aplicación. La mayoría de los equipos comienzan conectando directamente a los agentes con bases de datos y API, sin una puerta de enlace compartida como un servidor de Protocolo de Contexto de Modelo (MCP). Cada nuevo conjunto de datos requiere código personalizado, y cada agente reimplementa su propio control de acceso. A medida que crece el número de conjuntos de datos o agentes, la aplicación de permisos se vuelve impredecible, y la incorporación de una nueva fuente de datos se convierte en un esfuerzo de ingeniería de varios días.

Nuestro equipo apoya la red del Centro de Clasificación de Norteamérica (NASC) de Amazon, donde los equipos de planificación dependen de datos operativos para gestionar la capacidad, la mano de obra y el flujo de paquetes. Para brindar a esos equipos acceso conversacional a esos datos, creamos un servidor Model Context Protocol (MCP) sin servidor en Amazon Elastic Container Service (Amazon ECS) con AWS Fargate para abordar este problema para los equipos de planificación en NASC. El servidor actúa como una puerta de enlace centralizada y agnóstica de agentes entre los agentes de AI y nuestro lago de datos empresariales. Exponer un nuevo conjunto de datos requiere solo un archivo de metadatos JSON que el servidor descubre automáticamente en la próxima sincronización de la pipeline.

En esta publicación, describimos la arquitectura, mostramos cómo un enfoque dirigido por metadatos elimina la necesidad de código de integración por conjunto de datos y explicamos cómo la infraestructura sin servidor admite múltiples agentes y aplicaciones en un entorno multi-tenant.

Declaración del problema y objetivos de diseño

Dos desafíos interrelacionados dieron forma a cómo diseñamos este sistema: patrones de acceso a datos fragmentados y un modelo de incorporación insostenible.

Desafío de integración a escala

Nuestro lago de datos contiene miles de conjuntos de datos que abarcan métricas operativas, análisis comerciales y datos específicos del dominio. Múltiples equipos querían asistentes de AI que pudieran consultar estos datos de manera conversacional, pero cada uno construyó su propia integración desde cero. Cada agente incorporó su propia lógica de generación de SQL, conocimiento de esquema y control de conexión, por lo que un cambio de esquema significaba parchear cada agente individualmente. El control de acceso estaba fragmentado, sin un solo punto de auditoría para las decisiones de acceso a datos. La incorporación de un nuevo conjunto de datos requería código de herramienta personalizado, validación de consultas y redepliegue, típicamente un esfuerzo de varios días por tabla.

Objetivos de diseño

Establecimos cuatro requisitos:

• Acceso al lago de datos basado en configuración. Agregar un conjunto de datos solo requiere un archivo de metadatos, no código.
• Interfaces de herramientas agnósticas al agente. Cualquier cliente compatible con MCP puede invocar las mismas herramientas.
• Aplicación de permisos centralizada. El control de acceso se aplica en la capa del servidor MCP.
• Infraestructura elástica. El sistema se escala con patrones de carga de trabajo de IA variables.

Visión general de la solución

La arquitectura separa las preocupaciones en cuatro capas (cliente, servidor MCP, herramientas y actualización de la base de conocimientos), cada una escalable y desplegable de forma independiente. Un catálogo de metadatos subyace a la capa de herramientas, almacenando descripciones de esquemas, semántica a nivel de columna y relaciones de tablas que el agente de IA referencia al generar SQL. Debido a que el agente deriva el conocimiento del esquema del catálogo en el momento de la consulta, no es necesario codificar estructuras de tablas de forma rígida ni volver a implementar cuando los esquemas cambian. La capa de actualización de la base de conocimientos mantiene actualizado ese catálogo, indexando nuevos metadatos de conjuntos de datos a medida que llegan. Las siguientes secciones describen cada capa en detalle.

Recorrido por la arquitectura

El siguiente diagrama muestra el flujo de solicitudes desde la consulta del usuario hasta la capa de datos a través de las cuatro capas. Un usuario envía una consulta desde una aplicación cliente (chat web, Slack, un complemento de IDE o un agente externo). La solicitud se resuelve a través de Amazon Route 53 para DNS y llega a un Application Load Balancer en una subred pública, configurado con HTTPS y AWS WAF. El equilibrador de carga enruta a Amazon Cognito, que autentica al usuario y enriquece la solicitud. El tráfico autenticado entra entonces en la subred privada, donde la capa del cliente se ejecuta en Amazon ECS Fargate. Esta capa maneja el estado de la sesión en Amazon DynamoDB y envía solicitudes a través de un Application Load Balancer interno a la capa del servidor MCP, también en Amazon ECS Fargate. En la capa del servidor MCP, un agente de IA impulsado por Amazon Bedrock orquesta herramientas construidas con FastMCP (un framework de Python para construir servidores MCP). Amazon Bedrock Guardrails se aplica a cada interacción de modelo. A la derecha, la capa de datos contiene las partes traseras de las herramientas. Amazon Athena y Amazon Redshift ejecutan consultas SQL contra el lago de datos, y Amazon Bedrock Knowledge Bases, la capacidad de generación aumentada de recuperación (RAG) completamente administrada, maneja la búsqueda semántica. La ingesta de datos en Amazon Simple Storage Service (Amazon S3) y las bases de conocimientos se maneja mediante AWS Lambda. Cada capa se describe en detalle en las secciones que siguen.

Figura 1: Flujo de solicitudes a través del servidor MCP sin servidor, desde aplicaciones cliente hasta la capa de datos

Capa de cliente MCP: Autenticación y administración de sesiones

Una solicitud fluye desde la aplicación cliente a través de Amazon Route 53 para la resolución de DNS hasta un Application Load Balancer configurado con HTTPS y AWS WAF. El equilibrador de carga envía el tráfico al servicio de cliente Amazon ECS Fargate, que se integra con Amazon Cognito para la autenticación de token web JSON (JWT) y Amazon DynamoDB para el almacenamiento de sesiones.

Una configuración de asignación de contexto impulsa esta enriquecimiento, limitando cada consulta solo a las tablas relevantes. En nuestras pruebas, esta limitación mantiene la latencia de interacción de extremo a extremo en el rango de 15 a 20 segundos. El siguiente ejemplo muestra una configuración de asignación de contexto:

{
  "package_data": {
    "description": "Package tracking and delivery information",
    "tables": ["analytics_db.regional_order_summary", "operations_gold.load_summary"],
    "sources": {"wiki": [], "quip": []}
  },
  "labor_planning": {
    "description": "Workforce management and capacity planning",
    "tables": ["workforce.capacity_details"],
    "sources": {"wiki": [], "quip": []}
  }
}

Cuando un contexto especifica tablas, el servidor MCP reduce su búsqueda del catálogo de metadatos a esas tablas, reduciendo el ruido y mejorando la precisión de la generación de SQL. Agregar un nuevo dominio empresarial requiere solo agregar una entrada a esta asignación.

Capa de servidor MCP: Ejecución sin estado con estado de conversación

El servidor MCP se ejecuta en su propio clúster ECS Fargate, aislado de la capa de cliente. Las solicitudes llegan a él a través de Amazon Route 53 y un Application Load Balancer interno en una subred privada. El servidor maneja la orquestación completa, incluido el análisis de consultas, la selección de herramientas, la ejecución y la generación de respuestas. A través del punto de conexión del protocolo MCP (/mcp), una interfaz JSON-RPC con FastMCP, los clientes compatibles con MCP externos, como Amazon Q Developer o extensiones de IDE, pueden descubrir e invocar herramientas directamente.

Las tareas de Fargate son sin estado, con el estado de conversación persistente en DynamoDB, por lo que las tareas se pueden reemplazar o escalar sin pérdida de datos. Cuando llega una solicitud, el agente recupera el historial de sesión, analiza la intención del usuario utilizando Amazon Bedrock, descubre e invoca las herramientas adecuadas y transmite los resultados de regreso al usuario.

Capa de herramientas y acceso al lago de datos impulsado por metadatos

Cada herramienta se registra con FastMCP y es descubrible en tiempo de ejecución:

Las herramientas de consulta de Athena son la interfaz principal con el lago de datos. El agente primero consulta el catálogo de metadatos para entender los esquemas disponibles, genera una consulta SQL optimizada a través de Amazon Bedrock, valida y corrige automáticamente el SQL para la compatibilidad con Athena, y luego la ejecuta. Los resultados fluyen de regreso al agente orquestador para la síntesis de lenguaje natural.

Controles de IA responsables

Amazon Bedrock Guardrails se aplica a todas las interacciones de LLM y está diseñado para filtrar contenido dañino, hacer cumplir las verificaciones de base y ayudar a bloquear intentos de inyección de solicitudes. Estos guardrails operan como controles de producción en la capa del servidor MCP, por lo que cada agente conectado se beneficia de las mismas políticas de seguridad de contenido, independientemente de cómo se conecte. Las herramientas de consulta de Athena aplican consultas SELECT-solo, rechazando operaciones de escritura a nivel de herramienta antes de que lleguen al lago de datos.

Capa de actualización de base de conocimientos: Incorporación de conjuntos de datos con un solo archivo JSON

El sistema completo está construido alrededor de la extensibilidad impulsada por la configuración. Agregar un nuevo conjunto de datos requiere un archivo JSON de metadatos que describe la tabla y una entrada de mapeo de contexto opcional. El archivo captura el esquema de la tabla, el contexto empresarial y la semántica a nivel de columna. Sirve como la única fuente de verdad que el agente de IA utiliza para entender y consultar el conjunto de datos:

{
  "database_service_name": "athena",
  "database_name": "analytics_db",
  "table_name": "regional_order_summary",
  "business_description_for_the_table": "Regional order history with shipping status and delivery performance. Contains completed orders with delivery data. Refreshes daily. In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.",
  "column_details": {
    "order_id [varchar]": {
      "description": "Unique order identifier assigned at checkout.",
      "sample_values": ["ORD-20250115-001234", "ORD-20250116-005678"]
    },
    "order_date [timestamp(3)]": {
      "description": "Date and time the order was placed. Use this column for time-range filtering.",
      "sample_values": ["2025-01-15 08:00:00.000", "2025-01-16 12:30:00.000"]
    },
    "warehouse_id [varchar]": {
      "description": "Fulfillment center that processed the order.",
      "sample_values": ["FC-EAST-07", "FC-WEST-03", "FC-SOUTH-12"]
    }
  },
  "load_type": "Incremental (refreshes last 7 days)",
  "refresh_frequency": "Daily at 6:00 AM UTC",
  "table_size": "~2.1B rows",
  "creation_time": "2024-03-15",
  "last_refresh_time": "2025-05-20T06:00:00Z"
}

El campo business_description_for_the_table lleva pistas de consulta específicas del motor, como "siempre use date() para envolver literales de cadena", que reducen los fallos de validación de SQL. El campo column_details empareja cada column_name [type] con una descripción en lenguaje natural y valores de ejemplo, lo que da al agente tanto conciencia del esquema como semántica empresarial. El campo sample_values es importante para la generación precisa de la cláusula WHERE porque el agente aprende patrones de datos reales, por ejemplo, que warehouse_id contiene códigos como FC-EAST-07 en lugar de nombres escritos como "instalación de la región este".

La pipeline recoge archivos de metadatos, genera incrustaciones de vector con Amazon Titan Text Embeddings y los indexa en Amazon Bedrock Knowledge Bases. Una vez indexados, la tabla es accesible para todos los agentes conectados sin reindexación manual o reinicios del servidor.

Para mejorar la precisión para aplicaciones específicas, un ingeniero puede asociar opcionalmente el conjunto de datos con un contexto empresarial. Esto reduce el alcance de la búsqueda, por lo que el agente prioriza las tablas correctas. El siguiente ejemplo muestra una entrada de asignación de contexto:

{
  "delivery_metrics": {
    "description": "Delivery accuracy and defect attribution data",
    "tables": ["analytics_db.customer_orders_summary"],
    "sources": {"wiki": [], "quip": []}
  }
}

Si no se especifica contexto, el agente busca en todas las tablas indexadas. La asignación de contexto reduce la latencia y mejora la precisión de SQL al limitar el espacio de búsqueda. Esta delimitación es opcional y se puede agregar en cualquier momento sin modificar los archivos de metadatos en sí.

Poniéndolo todo junto: Una consulta en acción

Cuando un usuario pregunta, "¿Cuáles fueron nuestros 10 pedidos de mayor valor del mes pasado?", el cliente enriquece la solicitud con contexto empresarial para reducir el alcance. El agente convierte la pregunta en una incrustación de vector, busca en el catálogo de metadatos esquemas coincidentes y selecciona la tabla más relevante a través de una llamada LLM ligera.

Usando el esquema seleccionado, las descripciones de columna y las pistas de consulta específicas del motor, el agente genera una instrucción SQL como:

SELECT order_id, customer_id, total_amount, order_date
FROM analytics_db.regional_order_summary
WHERE order_date >= date_add('month', -1, current_date)
ORDER BY total_amount DESC
LIMIT 10

El SQL se valida y corrige automáticamente para la compatibilidad del motor, y luego se ejecuta contra Amazon Athena. El agente da formato a los resultados en una respuesta en lenguaje natural y los transmite de regreso al usuario. En nuestras pruebas, este flujo de extremo a extremo se completa dentro de 15-20 segundos.

La misma orquestación se extiende más allá del puro SQL. Debido a que la búsqueda de documentos está registrada como otra herramienta en el mismo servidor, el agente puede responder preguntas que abarcan fuentes estructuradas y no estructuradas en un solo turno, como "¿Cuál fue nuestra tasa de devolución para el Q4, y qué dice el análisis del equipo de productos sobre las causas raíz?". Para esa solicitud, el agente ejecuta una consulta de Athena para la cifra de tasa de devolución y una búsqueda de documentos de Knowledge Bases para el análisis, y luego combina ambos en una sola respuesta.

Seguridad y acceso multi-tenant

Esta orquestación de un solo turno funciona solo porque cada llamada a la herramienta pasa por la misma puerta de enlace controlada. La arquitectura utiliza seguridad en capas en lugar de un solo punto de aplicación. El servidor MCP se ejecuta en subredes privadas detrás de un Application Load Balancer interno y no es accesible desde Internet. Solo la capa del cliente, que se encuentra detrás de un Application Load Balancer con AWS WAF, puede enrutar solicitudes a él. Amazon Cognito valida la identidad del usuario en la capa del cliente, y solo las solicitudes autenticadas y con token se envían hacia abajo. A nivel de herramienta, las herramientas de consulta de Athena aplican consultas SELECT-only, rechazando operaciones de escritura antes de que lleguen al lago de datos. Todas las invocaciones de herramientas se registran en Amazon CloudWatch con JSON estructurado, lo que da a los equipos de seguridad un solo punto de auditoría para el acceso a datos en cada agente y aplicación. Esta arquitectura está disponible en las regiones de AWS donde están disponibles Amazon Bedrock y Amazon Bedrock Knowledge Bases.

Diseño centralizado es también lo que hace que el servidor sea multi-tenant. Debido a que el punto de conexión estandarizado /mcp acepta cualquier cliente compatible con MCP, independientemente del LLM o framework de orquestación que utilice, múltiples agentes comparten las mismas herramientas y los mismos controles de acceso. Agregar un nuevo agente requiere solo apuntar a él al punto de conexión del servidor, por lo que la incorporación de otro equipo extiende el sistema sin debilitar o duplicar el modelo de seguridad.

Infraestructura y escalado sin servidor

Cada capa se escala a través de un mecanismo adecuado para su patrón de carga de trabajo:

Amazon ECS Fargate proporciona cómputo sin servidor sin instancias de EC2 que administrar. Los servicios downstream (Athena, Bedrock) se escalan automáticamente, por lo que el sistema maneja una sola consulta o cientos de consultas concurrentes sin cambios de configuración.

Casos de uso y extensiones

Esta arquitectura admite varios patrones más allá de la respuesta básica a preguntas. Los asistentes de conocimiento empresarial pueden combinar consultas de data lake con búsqueda de documentos para responder preguntas complejas que abarcan datos estructurados y conocimiento no estructurado, como "¿Cuál es nuestra tasa de devolución para el Q4, y qué dice el análisis del equipo de productos sobre las causas raíz?". Los copilotos de análisis internos permiten a los usuarios empresariales consultar el data lake de manera conversacional sin escribir SQL, confiando en las descripciones de metadatos y las sugerencias de consulta para guiar al agente hacia patrones de consulta precisos y performantes.

El punto de conexión estandarizado /mcp también admite flujos de trabajo multiagente. Múltiples agentes especializados para análisis de datos, recuperación de documentos y alertas operativas pueden compartir el mismo servidor MCP, cada uno accediendo a la suite de herramientas completa a través de un protocolo común. La incorporación de los datos de un nuevo equipo sigue el mismo patrón de configuración. Agregan un archivo JSON de metadatos, y dentro de un ciclo de sincronización de pipeline, su conjunto de datos es descubrible por cada agente y aplicación conectado.

Conclusión

Un servidor MCP centralizado en Amazon ECS Fargate proporciona una puerta de enlace escalable y segura entre agentes de IA y data lakes empresariales. El enfoque basado en metadatos elimina la necesidad de código de integración por conjunto de datos, y el estándar de Protocolo de Contexto de Modelo significa que cualquier cliente compatible con MCP puede conectarse sin adaptadores personalizados.

La decisión arquitectónica clave es separar la capa de herramientas de la capa de agente. Los agentes evolucionan rápidamente, pero los patrones de acceso a datos deben sobrevivir a cualquier implementación de agente individual. Tratar la extensibilidad como un problema de configuración en lugar de un problema de código acelera la incorporación.

Para obtener más información, consulte Amazon ECS en AWS Fargate, Amazon Bedrock, la guía del usuario de las bases de conocimiento de Amazon Bedrock, Amazon Athena y la especificación del Protocolo de Contexto de Modelo.

Próximos pasos

Estamos extendiendo esta arquitectura en dos direcciones. Primero, un control de acceso más granular donde los propietarios de tablas pueden marcar columnas sensibles como restringidas por grupo de permisos, y el agente excluye automáticamente esas columnas del SQL generado sin cambios a nivel de prompt.

Segundo, cerrar el bucle de retroalimentación para que cuando las consultas fallen o produzcan resultados de baja confianza, el sistema capture el patrón de falla y presente sugerencias dirigidas para mejorar las descripciones de columnas, agregar sugerencias de consulta.

Acerca de los autores