La capa semántica de EDB incorpora las reglas de acceso de los agentes a Postgres

AWS publicó una guía de la capa semántica de EDB que pone a los permisos de la base de datos, en lugar de las instrucciones del prompt, al mando de lo que un agente puede leer. Publicado el 3 de noviembre, el ejemplo conecta EDB Postgres AI con Amazon Bedrock AgentCore, servicios de AWS para alojar y conectar agentes de software. Su propuesta central es concreta: mantener las definiciones empresariales cerca de los datos operativos y aplicar el acceso allí donde se ejecutan las consultas.

Una capa semántica conecta el lenguaje empresarial con las estructuras y los cálculos de una base de datos. En este caso, un agente utiliza Strands Agents, un marco para crear agentes que llaman a herramientas, para responder preguntas sobre la actividad de los clientes. La tensión se sitúa entre la generación flexible de consultas y un control fiable. Un asistente necesita suficiente libertad para interpretar preguntas, mientras que los responsables de la base de datos necesitan límites previsibles para su acceso.

La comparación con Denodo, una plataforma de virtualización de datos que consulta fuentes distribuidas, ayuda a situar el enfoque de EDB. Ambos proporcionan contexto empresarial a los agentes, pero organizan ese contexto en torno a arquitecturas de datos diferentes. Para desarrolladores y compradores empresariales, la pregunta inmediata es dónde deben residir las definiciones y los permisos, y quién debe mantenerlos.

La capa semántica de EDB hace descubrible el significado de la base de datos

El cambio es un patrón de integración que permite que un agente externo use las definiciones existentes de la base de datos.

La guía de la capa semántica agéntica combina la extensión de base de datos AIDB de EDB con un agente que se ejecuta en AWS. Su ejemplo de clientes utiliza cuatro tablas y una vista derivada, una consulta guardada presentada como objeto de base de datos. Las descripciones empresariales proceden de los comentarios de la base de datos, mientras que las claves foráneas, restricciones que conectan registros relacionados, proporcionan las relaciones de unión.

Según AWS, el ejemplo mantiene constantes el prompt y el código del agente mientras cambia la credencial de la base de datos. El rol restringido no puede recuperar una columna protegida de número de la Seguridad Social. Es una distinción útil: la base de datos rechaza el acceso intentado antes de que el asistente redacte su respuesta.

Esto sigue siendo un ejemplo de referencia elaborado por un proveedor. Establece una implementación propuesta e informa de un comportamiento de muestra, en lugar de aportar evidencia independiente de fiabilidad a escala empresarial. Los lectores deben separar esas afirmaciones antes de extraer conclusiones sobre la preparación para el despliegue.

La documentación de EDB explica la base de conocimiento semántico subyacente, un índice consultable de la estructura y las descripciones de la base de datos. Indexa tablas, vistas, columnas y comentarios en lugar de incorporar registros de clientes. Los embeddings, representaciones numéricas utilizadas para la coincidencia por similitud, ayudan a los agentes a localizar objetos relevantes de la base de datos mediante preguntas en lenguaje natural.

Esa distinción importa para la evaluación. Encontrar la estructura correcta no demuestra que un cálculo generado sea correcto. Proporciona al modelo mejor material para construir una consulta. Los equipos aún necesitan comparar las respuestas con resultados empresariales aceptados.

Para quienes buscan una explicación de la capa semántica de EDB, el punto de partida útil es esta separación entre descubrimiento y aplicación. Las descripciones ayudan a un agente a decidir qué significan los datos. Los permisos determinan si su consulta propuesta puede acceder a esos datos.

La ubicación también cambia la propiedad. Un comentario de base de datos pasa a formar parte del contexto operativo del agente, en lugar de ser documentación que los desarrolladores solo consultan ocasionalmente. Una descripción inexacta merece la misma atención que una interfaz de aplicación engañosa.

Consideremos un campo hipotético de compra cuyo nombre no revela si contiene un importe unitario o el total de un pedido. Ambas interpretaciones permiten una aritmética válida. Solo una coincide con la definición empresarial, por lo que una ejecución correcta por sí sola no puede identificar el error.

Eso hace que esta arquitectura sea relevante más allá de su conjunto de datos de muestra. Su valor depende de si los equipos pueden convertir convenciones ambiguas de base de datos en definiciones mantenidas y descubribles. La conexión del agente expone ese trabajo como un requisito previo, en lugar de hacerlo desaparecer.

Los responsables de la base de datos heredan parte de la carga de trabajo del agente

Trasladar el significado a Postgres otorga a los equipos de base de datos un papel directo en la calidad de las respuestas.

La presión inmediata recae en las personas responsables de los esquemas, las definiciones de informes y las políticas de acceso. Un equipo de aplicaciones puede mejorar las instrucciones de un asistente, pero no puede resolver una definición empresarial no consensuada únicamente mediante la redacción.

Supongamos que ventas y finanzas usan definiciones diferentes de cliente activo. Uno cuenta las compras recientes; el otro exige una cuenta en buen estado. Un agente que elige cualquiera de las interpretaciones sin aclaración produce una respuesta que parece más consensuada de lo que realmente está la organización subyacente.

Mantener una definición cerca de los datos crea un lugar para resolver ese desacuerdo. No decide qué departamento tiene razón. Alguien aún necesita autoridad para aprobar la definición, explicar su alcance y gestionar los cambios.

Por eso la carga operativa merece atención junto con la arquitectura. Un equipo que adopte este patrón debe esperar un trabajo editorial continuo sobre el significado de la base de datos. Revisar las descripciones pasa a formar parte del mantenimiento de una interfaz que consumen los agentes de software.

Lo mismo se aplica a las relaciones entre tablas. Una conexión técnicamente válida no expresa automáticamente la relación empresarial que exige una pregunta. Los compradores deberían preguntarse si su estructura de base de datos existente refleja necesidades de elaboración de informes o si simplemente respalda transacciones de aplicaciones.

Esa diferencia se hace visible cuando un cliente tiene múltiples direcciones, propietarios de cuenta o clasificaciones históricas. Una pregunta sobre el territorio actual requiere una interpretación distinta de una pregunta sobre el territorio cuando se realizó un pedido. Ninguna respuesta debería depender de una suposición no documentada.

Estos son escenarios de evaluación, no fallos reportados de la implementación de EDB. Muestran dónde un descubrimiento de esquemas más sólido sigue necesitando criterio empresarial. Un piloto útil debería incluir deliberadamente preguntas cuyas respuestas cambien cuando cambien esas suposiciones.

La implicación para la dotación de personal es directa. Los equipos de agentes necesitan acceso a las personas que ya resuelven disputas sobre informes. De lo contrario, los desarrolladores de aplicaciones corren el riesgo de convertirse en propietarios no oficiales de métricas que no tienen autoridad para definir.

Por tanto, los compradores empresariales deberían evaluar el proceso de mantenimiento junto con la demostración del agente. ¿Quién aprueba una definición modificada? ¿Qué aplicaciones dependen de ella? ¿Cómo descubre la organización que un asistente está usando una interpretación obsoleta?

Para los equipos de ingeniería, una base de conocimiento consultable puede conservar el razonamiento detrás de esas decisiones. Las definiciones de base de datos y la documentación de respaldo cumplen propósitos relacionados, incluso cuando residen en sistemas diferentes.

La presión a corto plazo consiste en preparar un piloto fiable. La presión a largo plazo es organizativa: mantener definiciones empresariales coherentes a medida que cambian las aplicaciones, los requisitos de informes y el personal. La arquitectura hace más visible esa responsabilidad, lo que solo resulta útil si alguien la asume.

Las consultas revisadas proporcionan a los agentes flexibles una referencia estable

Las preguntas empresariales recurrentes merecen lógica de consulta reutilizable, incluso cuando los usuarios las formulan con palabras distintas.

EDB documenta los alias semánticos, consultas con nombre emparejadas con descripciones consultables en lenguaje natural y parámetros definidos. Un alias debe contener un único SELECT de solo lectura, una consulta que recupera resultados. EDB afirma que valida esa restricción cuando se crea y ejecuta el alias.

La implicación arquitectónica es un camino intermedio entre interfaces de informes fijas y generación de consultas sin restricciones. Los usuarios pueden expresar una solicitud conocida de forma conversacional, mientras el sistema dispone de una consulta existente como referencia.

Para un informe hipotético de ventas regionales, la lógica revisada podría especificar ya el período de elaboración de informes, la clasificación de clientes y el tratamiento de pedidos cancelados. Esas decisiones deberían sobrevivir a cambios en cómo un usuario formula la solicitud.

Eso es diferente de pedir al modelo que reconstruya cada decisión cada vez. Reconstruir una lógica conocida introduce otra oportunidad para la variación. La reutilización proporciona a los revisores un objeto más pequeño y concreto que inspeccionar.

Sin embargo, una consulta guardada no resuelve la interpretación por sí sola. El agente aún debe identificar la consulta adecuada y proporcionar parámetros apropiados. Una solicitud de actividad trimestral no debería convertirse silenciosamente en una solicitud del último trimestre natural.

Esto crea preguntas de evaluación distintas. ¿Reconoció el sistema la pregunta empresarial prevista? ¿Seleccionó el período y el alcance correctos? ¿La explicación devuelta describió con precisión lo que midió la consulta?

Un resultado favorable de la base de datos aborda solo una parte de esa cadena. Un asistente puede recuperar los registros correctos y resumirlos incorrectamente. A la inversa, una explicación fluida puede ocultar una consulta que respondió a una pregunta cercana.

La respuesta práctica es mantener respuestas de referencia para solicitudes recurrentes. Los equipos pueden comparar las respuestas generadas con esas referencias mientras varían la redacción, las fechas y los permisos de usuario. Eso prueba el comportamiento que los usuarios realmente encontrarán.

La lógica revisada también crea un proceso de cambio más claro. Si la empresa cambia su definición, los responsables pueden identificar la consulta pertinente y evaluar los resultados afectados. Sin una referencia compartida, las definiciones equivalentes pueden desviarse entre aplicaciones de agentes.

Existe un límite para este beneficio. Las preguntas altamente exploratorias seguirán exigiendo interpretación más allá de un catálogo existente de consultas. Los compradores deberían evaluar cómo se comporta el sistema cuando no existe una coincidencia cercana, incluido si pide aclaraciones.

El comportamiento importante del producto es la incertidumbre honesta. Una herramienta que identifica una solicitud ambigua ofrece a los usuarios la oportunidad de corregir su rumbo. Una herramienta que selecciona con seguridad una definición inadecuada oculta la decisión.

Por tanto, el enfoque de EDB se evalúa mejor como una forma de organizar significado reutilizable y lógica de consultas. Su utilidad depende de que la calidad de recuperación, el manejo de parámetros y las prácticas de revisión funcionen conjuntamente. Ninguno debe inferirse de una demostración exitosa de otro.

Denodo pone de relieve el límite del significado local de la base de datos

La comparación entre EDB y Denodo gira en torno a la ubicación de los datos y la responsabilidad operativa.

La anterior arquitectura de virtualización de datos de AWS utiliza Denodo para conectar información de clientes entre Amazon Aurora, Amazon Redshift y una base de datos PostgreSQL local. La virtualización de datos presenta fuentes distribuidas mediante una capa de consulta compartida. Esa guía sitúa las vistas empresariales y las políticas de acceso en Denodo.

El ejemplo de EDB, en cambio, centra el significado dentro de su base de datos operativa Postgres. Esta comparación no establece un ganador en rendimiento. Muestra condiciones iniciales diferentes para decidir dónde pertenece una definición empresarial.

Para un equipo cuyos datos relevantes ya residen juntos, merece la pena considerar definiciones locales de la base de datos. El atractivo organizativo es sencillo: los responsables actuales de la base de datos cuentan con un lugar conocido para inspeccionar los objetos que dan forma a las respuestas.

Para un equipo cuya información de clientes abarca sistemas independientes, el problema central es más amplio. Debe reconciliar identificadores, significados y permisos entre esos sistemas. Añadir una interfaz de agente no elimina esas decisiones de integración.

Por tanto, la pregunta útil sobre EDB frente a Denodo se refiere al límite de la pregunta de negocio. ¿Puede la organización responderla desde la base de datos gobernada que ya opera? ¿O la respuesta requiere coordinación entre varias fuentes?

Consideremos a un hipotético gestor de cuentas que pregunta qué clientes requieren atención para la renovación. El historial de compras por sí solo podría ser insuficiente. El estado del contrato, los casos de soporte sin resolver y la titularidad de la cuenta podrían afectar a la respuesta.

Si esos registros se encuentran en otros lugares, un piloto centrado en la base de datos debería hacer visible esa limitación. De lo contrario, una respuesta satisfactoria sobre los registros disponibles puede confundirse con una evaluación completa de la cuenta. La fuente ausente se convierte en un riesgo de negocio disfrazado de éxito técnico.

Un enfoque distribuido afronta su propia carga de evaluación. Conectar fuentes no establece automáticamente que sus definiciones coincidan. Los compradores aún deben examinar cómo el sistema reconcilia identificadores y periodos de reporte conflictivos.

La tensión central sigue siendo la misma en ambos enfoques: los agentes flexibles necesitan significados mantenidos y acceso aplicable. La elección arquitectónica determina dónde se concentran esas responsabilidades, en lugar de eliminarlas.

Por eso también el número de conectores es un criterio de compra incompleto. Un conector establece una ruta hacia la información. No establece que una pregunta concreta tenga un significado acordado en todas las fuentes conectadas.

Los equipos deberían comparar arquitecturas usando una solicitud de negocio representativa y todas sus dependencias. Incluyan a los propietarios de las fuentes, el cálculo aprobado, las restricciones de acceso y la explicación esperada. Eso revela más que una discusión general sobre las capacidades de los agentes.

Para EDB, la oportunidad consiste en convertir la estructura existente de la base de datos en una base fiable para los agentes. El límite es igual de claro: una organización debe establecer hasta dónde cubre esa base las preguntas que realmente hacen sus usuarios.

Los permisos siguen dependiendo de que la identidad llegue a Postgres

Una regla de acceso a la base de datos protege al usuario previsto solo cuando la consulta se ejecuta bajo un rol adecuado.

El servidor MCP de EDB utiliza el Model Context Protocol, una interfaz estándar mediante la cual los agentes llaman a herramientas externas. Su documentación indica que las llamadas a herramientas se ejecutan como el rol autenticado de Postgres. Los privilegios de la base de datos determinan entonces qué puede ejecutar ese rol.

Esto crea un punto concreto de revisión para los equipos de producción. Autenticar a una persona en el límite de una aplicación y seleccionar una identidad de base de datos posterior son responsabilidades distintas. Los revisores deberían rastrear ambas antes de aceptar una afirmación sobre acceso específico por usuario.

Una cuenta compartida hipotética para informes ilustra el problema. Si cada solicitud llega a la base de datos bajo esa cuenta, las reglas de la base de datos evalúan los permisos de esa cuenta. Una interfaz de aplicación personalizada no establece por sí misma una aplicación personalizada de las reglas de la base de datos.

Eso no hace que las cuentas compartidas sean universalmente inapropiadas. Significa que su autoridad debe corresponder al límite de servicio previsto. Un asistente de informes con un alcance limitado tiene requisitos distintos de un asistente que atiende a usuarios con derechos de acceso diferentes.

Las políticas de seguridad por filas de PostgreSQL restringen los registros a los que puede acceder un rol. Cuando se habilitan sin una política aplicable, la seguridad por filas deniega el acceso de forma predeterminada. Sin embargo, los superusuarios y los roles con BYPASSRLS eluden esas restricciones, mientras que los propietarios de tablas normalmente también las eluden, salvo que se les obligue a cumplirlas.

Esas excepciones documentadas importan al probar una conexión de agente. Una demostración que utiliza una cuenta administrativa no puede establecer el aislamiento de usuarios ordinarios. Los evaluadores deben verificar el rol efectivo y sus privilegios para la ruta de solicitud real.

Las restricciones de columnas y las restricciones de filas también responden a preguntas diferentes. Ocultar un campo sensible no establece que el registro de otro cliente sea inaccesible. Una evaluación convincente debería probar las dimensiones de acceso que promete la aplicación.

Esa evaluación debería incluir intentos de acceso mediante preguntas alternativas. Pedir directamente un campo sensible es útil, pero las solicitudes de negocio pueden combinar atributos permitidos de formas inesperadas. Los revisores deberían examinar qué devuelve la aplicación y cómo explica las restricciones.

La aplicación de permisos tampoco establece la exactitud de las respuestas. Un rol puede estar autorizado para leer registros que el agente combina de forma incorrecta. La evaluación de seguridad y la evaluación analítica deben mantenerse diferenciadas, con evidencia para cada una.

El acceso de solo lectura merece una precisión similar. Impedir escrituras limita lo que un agente puede cambiar mediante esa ruta. No determina si un resultado autorizado contiene información que la aplicación debería mostrar en un contexto concreto.

Estas salvedades definen el alcance de la afirmación, en lugar de descartarla. La aplicación de reglas por la base de datos ofrece a los revisores algo concreto que inspeccionar. Pueden examinar roles, privilegios, políticas y consultas ejecutadas en vez de depender únicamente de las intenciones declaradas del asistente.

El trabajo restante consiste en verificar que la aplicación llegue sistemáticamente a ese punto de aplicación bajo la identidad prevista. Esa es una responsabilidad de despliegue y debería ser visible en la evidencia de aceptación.

Observe el aislamiento de identidad, los cambios de definición y las respuestas repetibles

La próxima evidencia útil mostrará si la gobernanza resiste cambios en usuarios, definiciones y volumen de solicitudes.

Durante los próximos meses, los compradores deberían buscar evaluaciones que conecten esas dimensiones. Demostraciones adicionales de preguntas conocidas aportan menos información que pruebas diseñadas en torno a los límites de la arquitectura.

La primera señal es el aislamiento de identidad a lo largo de la ruta de solicitud desplegada. Busque evidencia de que los usuarios con permisos distintos reciben resultados adecuadamente diferentes. La evidencia debería identificar el rol efectivo de la base de datos, en vez de limitarse a mostrar nombres diferentes en una interfaz.

Una prueba de aislamiento debería incluir un intento de acción fuera de la autoridad del usuario y el comportamiento resultante de la base de datos. Una aplicación coherente reforzaría el argumento a favor de la arquitectura. La compartición de credenciales sin explicación debilitaría las afirmaciones sobre gobernanza específica por usuario.

La segunda señal es cómo los cambios de definición afectan a las respuestas. Una métrica de negocio rara vez permanece intacta durante toda la vida de una aplicación. Los equipos deberían buscar demostraciones que actualicen una definición y luego verifiquen la interpretación posterior del asistente.

La evidencia significativa incluye la transición en sí. ¿Utiliza el asistente el significado revisado? ¿Pueden los revisores identificar qué definición respaldó una respuesta anterior? ¿Se actualizan las respuestas de referencia afectadas mediante un proceso explícito?

Una gestión satisfactoria de cambios reforzaría el argumento de mantener el significado cerca de los objetos de base de datos mantenidos. Una propiedad poco clara o interpretaciones obsoletas mostrarían que la ubicación conjunta por sí sola no garantiza consistencia.

La tercera señal es una exactitud repetible bajo un uso representativo. Las evaluaciones deberían variar la redacción de las preguntas, la autoridad del usuario y el volumen de actividad simultánea. Los compradores necesitan comprobar si el sistema sigue siendo útil cuando las condiciones difieren de la demostración original.

Eso no exige tratar cada pregunta de negocio como una competición de benchmarks. Exige un conjunto declarado de comportamientos esperados. Los cálculos correctos, las negativas apropiadas, las limitaciones comprensibles y los tiempos de respuesta aceptables deberían contar cada uno con evidencia.

Para los equipos que buscan una explicación operativa de la capa semántica de EDB, esas señales proporcionan un marco práctico de decisión. Convierten una propuesta arquitectónica en preguntas que un piloto puede responder.

También evitan una previsión sin respaldo sobre qué plataforma gana. La implementación más sólida dependerá de la ubicación de los datos, los requisitos de identidad y la capacidad de la organización para mantener definiciones. Un enfoque centrado en la base de datos debe juzgarse frente a esas condiciones.

Empiece con una pregunta de negocio que su equipo ya responda de forma fiable y, a continuación, documente su definición, resultado esperado y límites de acceso. Proporcione a los revisores información suficiente para reproducir el resultado sin confiar en la explicación del asistente. Ejecute la misma solicitud con identidades adecuadamente restringidas e inspeccione el comportamiento de la base de datos junto con la respuesta. Después, cambie una definición relevante y verifique que la respuesta siga el cambio aprobado. Utilice la capa semántica de EDB para probar una propuesta operativa específica: su organización puede mantener un significado compartido mientras aplica el acceso en el momento de la consulta. Antes de ampliar el piloto, pregunte si puede explicar cada respuesta importante y cada denegación importante.