fueron diseñados para un puesto de control humano. Los ingenieros prepararon los datos, los analistas formularon consultas, los paneles mostraron las métricas aprobadas y luego los ejecutivos decidieron los siguientes pasos.
Los agentes de IA debilitan este punto de control.
Un agente de datos puede verificar metadatos, seleccionar fuentes de datos, escribir SQL y utilizar los resultados para recomendar los siguientes pasos. Algunos sistemas también pueden llamar a herramientas que desencadenan un flujo de trabajo o modifican una campaña. El almacén de datos pasa así a formar parte de un sistema que puede actuar en función de los resultados de las consultas.
Aquí es precisamente donde surge un problema que muchas arquitecturas de almacenamiento de datos antiguas no están diseñadas para abordar. Un agente puede generar SQL válido y calcular correctamente la métrica solicitada. Sin embargo, aún podría recomendar la acción incorrecta porque, si bien el almacén proporciona los datos, no proporciona las reglas comerciales que le indican al agente cómo usar esos datos o métricas.
Un almacén consultable no está automáticamente listo para el agente
A primera vista, un sofisticado almacén de datos en la nube podría parecer preparado para la IA. Los datos están ubicados centralmente, las canalizaciones se monitorean, los permisos se configuran y las tablas tienen descripciones. Estas medidas facilitan el acceso. Sin embargo, no garantizan que el agente leerá los datos de la forma prevista por la empresa.
Un esquema puede decirle a un agente que los costos de la campaña son un valor numérico. Pero no explica si se incluyen los honorarios de la agencia, si se han estandarizado las monedas o si ya se han deducido los reembolsos. Tampoco muestra si los últimos datos de conversión se han procesado por completo.
Los agentes de datos actuales de BigQuery se basan en metadatos y fuentes de conocimiento seleccionados, así como en instrucciones específicas de casos de uso para el procesamiento de consultas. No se basan únicamente en los nombres de las tablas. El análisis del lenguaje natural requiere reglas escritas sobre cómo la empresa define cada métrica.
En proyectos de infraestructura de datos, a menudo he visto definiciones de métricas integradas en parte en la lógica de transformación y en parte en fórmulas del panel. Otras reglas existen sólo en documentos o en la mente de los analistas. Ese acuerdo se vuelve frágil cuando el software tiene que decidir qué significan los números sin un analista.
Cuando SQL correcto produce una decisión incorrecta
Considere un escenario compuesto basado en patrones que he encontrado en análisis de campañas de múltiples fuentes.
Una empresa agrega datos de la plataforma sobre inversión publicitaria, clics, conversiones e ingresos atribuidos. La capa de informes normaliza las monedas, considera las ventanas de atribución y las reglas de exclusión, y realiza un seguimiento de las conversiones retrasadas.
La empresa le pregunta a un agente de análisis qué campañas deberían pausarse hoy para proteger el ROAS.
El agente selecciona tablas cuyos nombres coinciden con la consulta y genera SQL válido. Calcula la métrica correctamente y luego clasifica las campañas de menor rendimiento. La consulta se ejecuta y devuelve un resultado, pero la recomendación sigue siendo incorrecta.
En una plataforma, las conversiones aún no se han cargado por completo. Otro muestra los ingresos antes de contabilizar las cancelaciones. Un tercero utiliza una zona horaria diferente para informar. El panel que la empresa utiliza para generar informes maneja estas diferencias, pero el agente elige tablas de origen sin formato porque sus nombres coinciden más estrechamente con la pregunta.
Nada de esto es una alucinación. El almacén hacía que las tablas fueran consultables, pero no las reglas subyacentes.
La gobernanza tradicional resuelve sólo una parte del problema
El control de acceso no rige la interpretación
La gobernanza tradicional pregunta quién puede consultar una tabla o ver una columna confidencial. Con los agentes surge otra pregunta: incluso si el agente tiene acceso a los datos, ¿son esos datos adecuados como base para la toma de decisiones?
Las descripciones de las tablas rara vez definen relaciones válidas o métricas autorizadas. También suelen carecer de la granularidad del conjunto de datos, de las expectativas con respecto a la actualidad, de los filtros obligatorios y de las limitaciones conocidas.
Una capa semántica puede hacer explícitas estas reglas. Las vistas semánticas en Snowflake, por ejemplo, definen entidades comerciales sobre datos físicos, incluidos hechos, métricas, dimensiones y relaciones. El principio subyacente es neutral respecto del proveedor: un agente debe consultar un modelo de negocio gobernado en lugar de reconstruirlo a partir de esquemas sin procesar.
Un analista podría notar si la granularidad no coincide. Un agente puede transformar ese mismo error en una explicación plausible.
Una mesa nueva aún puede estar incompleta
El monitoreo de tuberías a menudo trata la actualidad como un estado técnico. El trabajo está completo. La tabla ha sido actualizada.
Sin embargo, una tabla actual todavía puede resultar inadecuada para la toma de decisiones. Los costos de la campaña pueden estar disponibles en cuestión de minutos, mientras que las conversiones solo son confiables después de varias horas. Una tabla financiera podría ser suficiente para generar informes, aunque aún no sea lo suficientemente confiable para una recomendación de precios automatizada.
Un almacén de datos habilitado para agentes debe demostrar si los datos necesarios para tomar una decisión están completos, no solo cuándo se actualizó la tabla por última vez.
En un escenario de campaña, es posible que el agente deba indicar que los datos de gasto están actualizados, pero dos plataformas siguen incompletas y, por lo tanto, cualquier recomendación de pausar es provisional.
La capa que falta es un contrato de decisión
Considero que la capa de arquitectura que falta es un contrato de decisión.
Un contrato de datos define lo que un productor debe entregar. Un contrato de decisión especifica cómo un sistema automatizado puede utilizar estos datos para una clase particular de decisiones.
Para una recomendación de presupuesto de campaña, el contrato especificaría la fuente de datos aprobada, el período histórico mínimo y la definición de la métrica. También especificaría la antigüedad de los datos, qué comprobaciones de integridad deben pasar, qué filtros están permitidos y si el agente puede recomendar un cambio o ejecutarlo.
Podría prescribir costos de medios normalizados y los ingresos netos atribuidos. También podría excluir plataformas donde las ventanas de atribución aún están abiertas y permitir al agente recomendar un cambio pero prohibir la ejecución directa.
El diagrama adjunto para el contrato de decisión muestra un formato legible por máquina. El control de versiones permite a los equipos revisar los cambios en estas reglas junto con los modelos de datos y las políticas de los que dependen.
Por qué este contrato es importante
Ayuda a los equipos a delimitar el origen de un resultado erróneo. Si una respuesta es incorrecta, pueden examinar cada capa individualmente: datos de origen, regla de actualización, modelo semántico, consulta generada y política de acción. Sin esos límites, los equipos llegan a una conclusión vaga: la IA produjo una mala respuesta.
El contrato debería evolucionar con la plataforma de datos. Los cambios en el modelo de atribución o el umbral de aprobación pueden afectar qué recomendaciones son válidas.
Cree una ruta de consulta más segura para los agentes
Coloque una interfaz semántica frente a los datos sin procesar
Un agente no debería comenzar con miles de tablas sin procesar, sino con interfaces para áreas comerciales específicas, como el rendimiento de la campaña o la salud del cliente.
Cada una de estas interfaces debe definir las métricas compartidas y documentar las uniones subyacentes o las relaciones entre entidades. La granularidad, el equipo responsable, la frecuencia de actualización y las limitaciones conocidas son igualmente importantes. Los ejemplos de preguntas y consultas revisados por analistas pueden ilustrar aún más cómo comprender las preguntas recurrentes de los analistas.
La interfaz compartida debe ser el punto de acceso predeterminado. Puede que aún sea necesario acceder a niveles inferiores, pero las tablas de datos sin procesar requieren controles más estrictos porque exponen detalles de implementación y registros de datos solo parcialmente procesados.
Agregar un límite de seguridad antes de la ejecución
El SQL generado debe ejecutarse primero a través de un servicio de ejecución de consultas que valide y limite la consulta antes de ejecutarla en la base de datos.
En BigQuery, un ensayo puede validar una consulta y estimar la cantidad de bytes procesados sin ejecutarla realmente. Los límites en el máximo de bytes facturables pueden detener una consulta si el escaneo estimado excede un umbral definido.
Un servicio de ejecución central puede imponer acceso de solo lectura, límites de tamaño de resultados, conjuntos de datos aprobados, tiempos de espera y tipos de declaraciones bloqueadas. También puede rechazar consultas formalmente válidas si utilizan una fuente no aprobada o combinan granularidades incompatibles. Allí también deberían aplicarse normas relativas a la cobertura de datos requerida.
El servicio debe registrar por qué permitió o rechazó una consulta. También debe registrar si la causa fue un error del modelo, una regla de política o un problema de datos.
Recomendación y acción separadas
Al agente que lee los datos no se le debe otorgar automáticamente permiso para actualizar los sistemas operativos.
Como parte del principio de privilegio mínimo para los agentes de IA, Microsoft recomienda que cada agente tenga su propia identidad, permisos limitados, registros de auditoría, acceso controlado a herramientas y acceso revocable.
Un agente de Analytics puede recomendar pausar una campaña. Sin embargo, la ejecución real debe ser manejada por un servicio de aprobación separado que primero verifique la identidad del usuario y del agente y luego verifique si los límites de la acción y el estado de aprobación permiten la ejecución.
El modelo interpreta los datos y recomienda una acción. Las comprobaciones basadas en reglas determinan si esta acción se puede ejecutar.
Los registros de consultas ya no son suficientes
Una respuesta utilizada como base para una decisión debe identificar claramente la fuente aprobada y la definición de la métrica, incluida la actualidad de los datos y el período de tiempo cubierto. También debe revelar qué datos se excluyeron y cualquier limitación conocida para que un revisor pueda verificar si la respuesta se basa en los datos correctos antes de actuar.
La observabilidad del almacén tradicional registra la declaración SQL, su tiempo de ejecución, los bytes procesados y el estado de ejecución. Esto captura la operación de la base de datos pero no cómo se generó la respuesta.
Los equipos también necesitan la consulta original y el contexto proporcionado por el usuario. Necesitan ver qué metadatos se recuperaron, qué SQL generó, qué herramientas se utilizaron y cuál fue el resultado. La interpretación final y las acciones resultantes también deben ser rastreables.
BigQuery Agent Analytics captura consultas y respuestas, junto con llamadas a herramientas y registros de errores, para su posterior análisis.
Un registro de consultas puede demostrar que el cálculo fue correcto. El seguimiento de la interacción, por otro lado, puede revelar que el agente ignoró una advertencia de integridad, seleccionó una tabla que no estaba autorizada o interpretó los ingresos brutos como ingresos netos.
Comience con una decisión, no con todo el almacén de datos
No exponga todos los datos del almacén y agregue controles más adelante. En su lugar, comience con una decisión recurrente que tenga un dueño claramente definido y cuyo impacto pueda medirse.
Un equipo de marketing podría comenzar con la pregunta recurrente: ¿Qué campañas es probable que no alcancen su objetivo de conversión mensual? La primera versión sólo debería responder a esta pregunta y revelar el fundamento de la decisión. Agregue recomendaciones solo después de realizar pruebas para detectar datos faltantes, conflictos de métricas, consultas poco claras y suposiciones que podrían conducir a acciones incorrectas. La ejecución debería ser el último paso.
Prueba de consultas que suenan plausibles pero arriesgadas
Las buenas pruebas son preguntas ordinarias que suponen algo falso.
Al pausar cada campaña que tiene un rendimiento inferior al promedio, se ignora el tamaño, la duración y el retraso en la atribución de la campaña. Extrapolar el rendimiento del mes únicamente a partir de las conversiones de ayer podría pasar por alto la estacionalidad o los datos incompletos. Excluir campañas a las que les faltan datos de ingresos puede enmascarar una falla en el sistema que proporciona esos datos de ingresos.
Un agente de alto rendimiento debe identificar claramente qué hace que una pregunta no sea confiable. Si la información es insuficiente para tomar una decisión, se debe pedir aclaración o abstenerse de recomendar acción alguna.
La verdadera actualización es el contexto
Los almacenes tradicionales han ayudado a humanos informados a explorar datos aprobados. Los almacenes preparados para agentes deben admitir software para interpretar datos sin inventar implícitamente significado comercial.
Esta transición no requiere reemplazar todas las tuberías. El elemento crucial es una capa controlada entre la solicitud del usuario y la consulta o acción. Esta capa debe definir cada métrica y especificar qué tan actualizados deben estar los datos para cada decisión. Debe identificar al agente, restringir sus consultas, especificar qué documentos debe citar y limitar qué acciones puede realizar.
Más tablas no conducen automáticamente a mejores decisiones. Un enfoque más seguro es un diseño que proporcione solo las tablas, definiciones y permisos compartidos necesarios para precisamente una decisión.
Un almacén sólo está verdaderamente preparado para los agentes cuando puede hacer más que simplemente responder a la consulta de un agente. También deberá informar al agente si los datos disponibles no permiten una respuesta confiable o si los datos están incompletos, desactualizados o no autorizados. Además, debe evitar que las recomendaciones se conviertan en acciones cuando la evidencia sea insuficiente.