Presentado por EDB
A medida que las empresas dan más autonomía a los agentes de IA (la capacidad de planificar, decidir y actuar en todos los sistemas sin que un humano apruebe cada paso), surge una pregunta difícil en el centro de cada revisión de arquitectura: cuando un agente intenta realizar una acción para la que nunca fue autorizado, ¿qué es lo que realmente lo detiene?
Son sus agentes, que se ejecutan en sus modelos, los que tocan sus datos en su infraestructura, y la responsabilidad de lo que hacen es suya. Esta responsabilidad no puede ser asumida a posteriori ni por un conjunto de políticas abstractas que existen en el papel pero no en la práctica. Los agentes necesitan reglas adaptadas al contexto actual, porque no ejercen un juicio preponderante sobre sus propias acciones.
Considere una regla simple: nunca abra la puerta del automóvil. Siguiéndolo literalmente, un oficial nunca podría entrar ni salir del auto. Pero si cambias el contexto (el auto acaba de chocar, hay un incendio, alguien está herido y necesita salir), entonces la regla que realmente quieres es la opuesta. El contexto del momento lo es todo. Les pedimos a los agentes que hagan cosas inteligentes; esto requiere reglas inteligentes.
El instinto es agregar barreras de seguridad alrededor del agente: instrucciones, políticas y monitoreo superpuestos al modelo. Estos mecanismos son importantes, pero comparten una limitación estructural: la regla de la puerta del automóvil es plausible hasta el punto en que realmente hay que decidir si abrir o no la puerta. Los controles a nivel de agente sólo son confiables en la medida en que el resultado del agente sea predecible, y la autonomía es precisamente la propiedad que hace que ese resultado sea difícil de predecir. La gobernanza que depende de considerar una acción antes de que suceda no puede seguir el ritmo de un sistema que actúa en milisegundos, en múltiples sistemas a la vez.
La gobernanza debe convertirse ejecutabley se aplica donde los agentes realmente hacen su trabajo: en la capa de datos operativos, en contexto y exactamente cuando sucede.
La capa de datos es el punto de aplicación.
Los agentes crean valor tocando datos. Lo cuestionan, lo recuperan, lo transforman y actúan cada vez más en consecuencia. Una política que establece que un agente no debe acceder a una determinada clase de datos sólo tiene sentido si el sistema puede negar ese acceso en el momento en que el agente lo solicita. Además, el principio de que la IA debe ser auditable sólo tiene sentido si la organización puede reconstruir qué hizo el agente, qué datos tocó, para qué usuario actuó y qué resultó. Cuando la gobernanza reside en la capa de datos, es válida independientemente de cómo se construyó el agente o cómo se comporta, porque el control es una propiedad de la base de datos en sí, no una promesa hecha por el agente.
El comportamiento de los agentes puede ser probabilístico. La gobernanza no puede ser
La empresa no debe confiar en que un modelo opte por seguir una política. La política debe ser aplicada por el sistema. Es la diferencia entre esperar que un actor se mantenga dentro de los límites y construir límites que no puede cruzar en primer lugar.
Los controles que hacen que esto sea real son los que muchas organizaciones ya ejecutan en la capa de datos: acceso basado en roles y atributos, seguridad a nivel de filas y columnas, clasificación y enmascaramiento, políticas como código y pistas de auditoría integrales.
Lo que los agentes cambian no es el mecanismo, sino a quién debe reconocer el mecanismo. La gestión de la identidad debe tratar al agente como un principal por derecho propio, con su propia identidad y un propósito declarado al inicio de la sesión.
Una vez que el objetivo está vinculado a la identidad, el motor de políticas puede evaluarlo de la misma manera que evalúa una función o servicio hoy, y el registro de lo que sucedió puede capturar no sólo quién actuó y qué afectó, sino también para qué dijeron que estaban allí.
En la práctica, esto se resuelve en nueve controles, agrupados en tres imperativos:
Aplicarlo
-
Control de acceso basado en roles y atributos aplicado en el momento de la solicitud, tanto para agentes como para usuarios
-
Ocultación dinámica de columnas impulsada por la misma ruta de política
-
Identidad del agente como principal de primera clase, con un propósito declarado vinculado al inicio de la sesión y el usuario actuante preservado.
Véalo y pruébelo
-
Clasificación y marcado que determina la política.
-
Registro de auditoría a nivel de sesión que registra qué agente actuó, para qué usuario y con qué propósito declarado.
-
Trazabilidad entre canales, de modo que un resultado pueda rastrearse hasta la solicitud que lo produjo.
Unificar y endurecer
-
Gestión de políticas centralizada y portátil
-
Cifrado en reposo y en tránsito
-
Aplicación coherente en entornos locales, en la nube y soberanos o aislados
«El objetivo declarado es lo que marca la diferencia. Se convierte en un atributo que la capa de acceso ya comprende, evaluado en la misma ruta política que la seguridad a nivel de rol y de fila. El mecanismo de aplicación no cambia. Lo que cambia es que el objetivo del agente se convierte en parte de lo que evalúa y de lo que el registro demuestra posteriormente», dice Priyanka Jain, vicepresidenta de gestión de productos, gobierno de datos e IA en EDB.
No importa en qué etapa de su proceso de adopción de la IA se encuentre, es la aplicación en la capa de datos la que le permite avanzar más rápido en lugar de hacerlo más lento. Los controles ya están en la base de datos. La diferencia es que los agentes ahora tienen que pasar por ellos.
Una correa digital, no una puerta cerrada
El objetivo no es impedir que los agentes realicen un trabajo útil. Se trata de definir hasta dónde puede llegar un agente, qué puede tocar, qué puede cambiar, qué requiere escalada y cómo la organización puede reconstruir los eventos si algo sale mal. Gobernados de esta manera, los agentes son identificados, delimitados, monitoreados y auditables. La empresa puede adoptarlos. más rápidoporque los equipos de seguridad, riesgos y gestión confían en el modelo operativo subyacente.
Abierto, soberano y exigible en origen
Construida sobre Postgres de código abierto, esta base abierta permite a las empresas controlar dónde residen sus datos, quién puede acceder a ellos y según qué políticas, sin ceder la gobernanza a una capa que no les pertenece o que no pueden inspeccionar. Para las industrias reguladas, esta combinación de soberanía de datos y aplicación de la ley a nivel de fuente no es una solución atractiva; este es el requisito previo para poner los agentes en producción.
Los sistemas de agentes seguirán volviéndose más eficientes y autónomos. Esta es una razón para pensar dónde está el control, no para frenar. Las empresas que aplican la gobernanza en la capa de datos pueden adoptar un enfoque agresivo hacia la IA porque proteger sus datos es más que una simple ilusión.
EDB Postgres AI es una plataforma de inteligencia artificial y datos soberana, abierta y de nivel empresarial que unifica cargas de trabajo transaccionales, analíticas y de inteligencia artificial, con gobernanza aplicada donde residen los datos. Para conocer el marco completo, consulte el documento técnico de EDB. Gobernar la IA agente a la velocidad de los negocios.
Max Romanenko es director de tecnología de EDB.
Los artículos patrocinados son contenidos producidos por una empresa que paga por la publicación o tiene una relación comercial con VentureBeat y siempre están claramente marcados. Para más información, póngase en contacto ventas@venturebeat.com.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.











































































