← Todos los insights

Análisis de noticiaEnfoque: España y Latinoamérica4 min de lectura

¿A quién alcanza ya el rol que le dará a su agente de IA? Snowflake ya puede decirlo

Snowflake puso en GA dos informes de Trust Center: quién puede acceder a tablas sensibles y quién las consultó. Para revisar el acceso de agentes, la brecha entre ambos es el hallazgo.

Escuche este artículo · 5 min

Narración completa del artículo, generada con IA.

Una puerta de madera entreabierta hacia un pasillo, en duotono La Madre, junto a las palabras Quién entró
Foto: Palm Beach Police Department (Wikimedia Commons, Public domain)

Cuando un equipo pide un rol de data warehouse para su nuevo agente de analítica, la solicitud suele sonar así: «el mismo acceso que los analistas». ¿Qué significa eso en tablas? ¿Cuáles de esas tablas contienen salarios, datos de salud o identificadores de clientes? Y de todas las personas que hoy tienen ese rol, ¿cuántas han tocado realmente esas tablas?

En la mayoría de las empresas nadie puede responder a la última pregunta sin abrir un proyecto. La versión que Snowflake publicó el 20 de octubre lo convierte en un informe.

Dos informes, dos hechos distintos

Snowflake puso en disponibilidad general (GA) dos informes del Trust Center, para Enterprise Edition y superiores:

  • Sensitive Data Entitlement muestra las rutas de acceso a las tablas que contienen datos sensibles: los usuarios, los roles y los privilegios que conceden acceso a ellas.
  • Sensitive Data Access muestra quién consultó realmente esas tablas, dentro de una ventana de retrospectiva que usted configura.

Ambos trabajan sobre tablas identificadas como portadoras de datos sensibles, así que son tan completos como la clasificación de la organización. Las tablas que nunca se clasificaron no aparecen, por sensibles que sean.

Tres preguntas sobre el acceso, y cuál responde cada herramienta

Puede acceder

  • Usuarios, roles, privilegios
  • Concesiones heredadas

Informe de derechos de acceso

Accedió

  • Quién consultó
  • Dentro de una ventana de retrospectiva

Informe de accesos

Si esta solicitud debería permitirse ahora

  • Por consulta, por tarea
  • Propósito y contexto

Autorización en runtime, no un informe

La brecha entre las dos primeras columnas es privilegio excesivo. La tercera columna es donde los agentes necesitan controles que los informes no pueden dar.

Por qué esto importa más cuando llegan los agentes

Los agentes heredan roles a escala. Una persona con un rol demasiado amplio rara vez explora tablas que no tiene motivo para abrir. Un agente que responde preguntas abiertas consultará lo que su rol le permita cuando una pregunta lo lleve hasta ahí. El privilegio excesivo que estaba dormido para las personas se vuelve activo para los agentes. El informe de derechos de acceso muestra esa exposición antes de que el agente exista.

«Accedió» es la línea base del privilegio mínimo. La diferencia entre quién puede llegar a una tabla sensible y quién la ha usado en los últimos 90 días es el hallazgo de privilegio mínimo más práctico que puede producir un equipo de gobernanza. En España y en la UE ese principio tiene forma legal: la minimización de datos del artículo 5.1.c del RGPD y el régimen reforzado de las categorías especiales de datos del artículo 9 son, en la práctica, la versión jurídica de esa misma línea base. Para un agente, eso da el alcance de partida: conceda lo que los usuarios humanos de ese flujo de trabajo usaron de verdad, no todo lo que su rol permite técnicamente.

El informe de accesos se convierte en un monitor del agente. Después del go-live, el mismo informe muestra si la identidad del agente está leyendo tablas sensibles que no se esperaba. Eso solo funciona si cada agente tiene su propia identidad en el data warehouse. Un agente que corre bajo un usuario de servicio compartido, o bajo la identidad del propio usuario sin una marca que lo distinga, desaparece en el tráfico humano.

Lo que los informes no hacen

Son evidencia, no un mecanismo de aplicación. Un informe que muestra el acceso de ayer no detiene la consulta de hoy; decidir si una solicitud concreta debería permitirse, para un propósito concreto, es trabajo de las políticas de fila y columna y de la capa de autorización de la plataforma de agentes.

También ven una sola plataforma. Si un agente combina datos de Snowflake con documentos de SharePoint o registros de un CRM, su exposición real es la unión, y cada fuente aplica sus propias reglas. Por eso importan tanto los patrones en los que el sistema de origen decide por usuario, o en los que el agente lleva la identidad del usuario a cada herramienta, como cualquier informe por separado.

Un uso práctico este trimestre

Haga de los dos informes parte de la solicitud de cualquier rol nuevo para un agente:

  1. Ejecute el informe de derechos de acceso sobre el rol que recibiría el agente. Enumere las tablas sensibles a las que llega.
  2. Ejecute el informe de accesos para las personas que hoy hacen ese trabajo. Enumere las tablas sensibles que usaron de verdad.
  3. Conceda al agente la segunda lista, con su propia identidad, y deje registrada la decisión.
  4. Revise cada mes el informe de accesos del propio agente y trate cualquier tabla sensible nueva como un cambio que requiere aprobación.

Nada de esto necesita tecnología nueva más allá de lo que Snowflake acaba de lanzar. Necesita que alguien decida que la revisión de acceso de los agentes parte de la evidencia y no de «el mismo acceso que los analistas».

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso