Las etiquetas de sensibilidad no son solo un mecanismo de compliance para documentos, informes o datasets. En escenarios de IA agentiva, pueden convertirse en una señal semántica muy valiosa para decidir qué datos debe usar un agente, con qué prioridad y bajo qué restricciones organizativas. Esa es la idea central detrás del uso de sensitivity labels para mejorar la precisión de agentes de IA: no basta con que el agente tenga acceso técnico a muchas fuentes; necesita entender qué fuentes son apropiadas para cada pregunta.
El problema aparece cuando una organización empieza a desplegar agentes sobre un patrimonio de datos amplio. Un agente puede tener acceso a lakehouses, semantic models, reports, notebooks, documentos o bases de conocimiento. Sin una capa de orientación, el sistema puede recuperar información técnicamente disponible pero contextualmente equivocada. Puede mezclar métricas financieras auditadas con datos preliminares, usar información interna para una respuesta destinada a clientes, o ignorar activos aprobados porque el ranking de recuperación favoreció otra fuente con texto más parecido a la consulta.
Las etiquetas de sensibilidad ofrecen una forma pragmática de añadir intención organizativa al proceso. En lugar de depender únicamente de similitud vectorial, nombres de tablas o permisos de acceso, el agente puede usar señales ya conocidas por la organización: confidencialidad, clasificación, ámbito de uso, criticidad y alineación con políticas internas.
El problema real: los agentes recuperan datos, pero no siempre contexto
En un sistema RAG clásico, la calidad de la respuesta depende en gran medida de la recuperación. Si el sistema trae fragmentos relevantes, el modelo tiene más probabilidades de responder bien. Si trae fragmentos ruidosos, contradictorios o incompletos, el modelo puede producir una respuesta aparentemente coherente pero mal alineada con el contexto corporativo.
Este problema se amplifica en agentes. Un agente no solo responde con un conjunto fijo de documentos; puede planificar, llamar herramientas, consultar fuentes diferentes y encadenar pasos. Esa capacidad hace que el sistema sea más útil, pero también aumenta la superficie de decisión. ¿Debe consultar un informe certificado o una tabla de trabajo? ¿Debe usar datos de ventas globales o solo datos de una región? ¿Debe responder con información interna o limitarse a contenido público?
Las arquitecturas modernas de conocimiento para agentes, como las descritas al hablar de Foundry IQ como capa de conocimiento ubicua para agentes, intentan resolver precisamente esta tensión: hacer que el conocimiento empresarial sea accesible, reutilizable y gobernado. Las etiquetas de sensibilidad encajan en esa visión porque aportan una señal de gobierno que puede viajar con el dato y ser interpretada por los sistemas de IA.
La clave está en entender que los permisos responden a la pregunta “¿puede este usuario o agente acceder a este dato?”, mientras que las etiquetas ayudan a responder otra pregunta distinta: “¿es este dato adecuado para este propósito?”.
Qué aportan las etiquetas de sensibilidad a un agente
Una etiqueta de sensibilidad suele indicar el nivel de protección o clasificación de un activo. En entornos Microsoft, estas etiquetas forman parte de Microsoft Purview Information Protection y pueden aplicarse a distintos tipos de contenido. En Microsoft Fabric, el concepto es especialmente interesante porque Fabric concentra datos, analítica, modelos semánticos e informes en un entorno común.
Cuando un agente consulta datos en Fabric, las etiquetas pueden actuar como metadatos de decisión. No sustituyen a los permisos, ni deberían hacerlo, pero añaden contexto. Un agente puede aprender que un semantic model etiquetado como “Confidential - Finance” es más apropiado para responder preguntas internas de planificación financiera que un extracto provisional sin certificación. Del mismo modo, una fuente etiquetada como “Public” puede ser preferible si la respuesta se va a incorporar a un asistente orientado a clientes.
Esta distinción es importante porque la precisión de un agente no depende únicamente de acertar hechos. También depende de responder desde la fuente correcta. En organizaciones grandes, puede haber varias versiones de una misma métrica: ventas brutas, ventas netas, forecast, pipeline, ingresos reconocidos o estimaciones operativas. Todas pueden ser “correctas” en su contexto, pero no son intercambiables. Una etiqueta bien diseñada ayuda al agente a discriminar entre ellas.
Note: Una etiqueta de sensibilidad no convierte automáticamente una fuente en “confiable” ni valida la calidad de los datos. Su valor está en representar una decisión organizativa sobre clasificación, protección o uso previsto. La calidad del dato sigue requiriendo procesos de gobierno, linaje, certificación y ownership.
Precisión no significa solo similitud semántica
En muchos diseños RAG, la recuperación se basa principalmente en similitud semántica. El usuario pregunta “¿cuál fue el crecimiento de ingresos en Europa?” y el sistema busca fragmentos cercanos a esos términos. Esto funciona bien cuando el corpus es acotado y homogéneo. Pero en una organización real, la similitud textual puede traer fuentes con diferentes niveles de madurez o sensibilidad.
Imaginemos tres activos de Fabric:
| Activo | Contenido | Etiqueta | Uso esperado |
|---|---|---|---|
Revenue Forecast FY26 |
Previsión interna de ingresos | Highly Confidential | Planificación ejecutiva |
Quarterly Revenue Report |
Informe financiero aprobado | Confidential | Reporting interno |
Public Earnings Summary |
Resumen publicado externamente | Public | Comunicación externa |
Los tres pueden responder a preguntas sobre ingresos. Sin embargo, no deberían usarse igual. Para un analista financiero autenticado que pregunta por escenarios de forecast, la primera fuente puede ser adecuada. Para un manager que necesita cifras consolidadas, el informe trimestral puede ser mejor. Para un agente que redacta una respuesta para clientes o partners, el resumen público debe tener prioridad.
Aquí es donde las etiquetas de sensibilidad añaden precisión organizativa. El agente no solo pregunta “qué documento se parece más a la consulta”, sino también “qué documento se alinea mejor con el propósito, audiencia y permisos de esta interacción”.
La evolución de la recuperación agentiva en servicios como Azure AI Search también va en esta dirección: mejorar la selección de conocimiento mediante consultas más ricas, planificación y grounding más controlado. Si te interesa la parte de recuperación y orquestación, el análisis de las actualizaciones en recuperación agentiva de Azure AI Search ofrece un buen complemento técnico a esta conversación.
Un patrón práctico: usar etiquetas como señales de ranking y filtrado
Hay dos formas principales de usar etiquetas de sensibilidad en un agente: como filtro duro o como señal de ranking. Ambas tienen sentido, pero resuelven problemas distintos.
Un filtro duro excluye fuentes que no deben participar en una respuesta. Si el usuario está en un canal externo, el agente puede descartar todo lo que no esté etiquetado como público o aprobado para comunicación externa. Este enfoque reduce riesgos, pero puede ser demasiado rígido si se aplica sin considerar el contexto.
Una señal de ranking, en cambio, no elimina necesariamente una fuente, sino que modifica su prioridad. Por ejemplo, un agente interno puede preferir activos etiquetados como “Confidential - Certified” frente a fuentes sin etiqueta, siempre que el usuario tenga permisos. Esto mejora la probabilidad de que el contexto final sea el más alineado sin bloquear por completo información potencialmente útil.
El siguiente ejemplo muestra una forma simplificada de representar esa lógica en una capa de recuperación. No asume una API concreta de Fabric; ilustra cómo una aplicación podría combinar permisos, etiquetas y propósito de la consulta antes de construir el contexto para el modelo.
from dataclasses import dataclass
from typing import list
@dataclass
class DataAsset:
id: str
title: str
sensitivity_label: str
certified: bool
semantic_score: float
allowed_for_user: bool
LABEL_WEIGHTS = {
"Public": 0.10,
"General": 0.05,
"Confidential": 0.15,
"Highly Confidential": -0.20,
}
def rank_assets_for_agent(
assets: list[DataAsset],
interaction_scope: str,
max_results: int = 5
) -> list[DataAsset]:
"""
Ordena activos de datos para un agente combinando:
- permisos efectivos del usuario,
- etiqueta de sensibilidad,
- certificación del activo,
- similitud semántica calculada previamente.
"""
candidates: list[tuple[float, DataAsset]] = []
for asset in assets:
if not asset.allowed_for_user:
continue
if interaction_scope == "external" and asset.sensitivity_label != "Public":
continue
label_weight = LABEL_WEIGHTS.get(asset.sensitivity_label, 0.0)
certification_weight = 0.20 if asset.certified else 0.0
final_score = asset.semantic_score + label_weight + certification_weight
candidates.append((final_score, asset))
candidates.sort(key=lambda item: item[0], reverse=True)
return [asset for _, asset in candidates[:max_results]]
Lo importante del ejemplo no es el peso exacto asignado a cada etiqueta, sino el patrón. La etiqueta no reemplaza a la similitud semántica; la complementa. Tampoco reemplaza a la autorización; se evalúa después de comprobar que el usuario puede acceder al activo. En sistemas reales, esta lógica debería estar alineada con políticas de seguridad, auditoría y gobierno de datos, no embebida como constantes arbitrarias en una aplicación.
Warning: No conviene usar etiquetas de sensibilidad como único mecanismo de control de acceso. Un agente debe respetar siempre permisos efectivos, roles, políticas de seguridad y límites de datos. Las etiquetas ayudan a decidir qué es apropiado, pero no deberían ser la única barrera de protección.
Diseño de etiquetas pensando en agentes
Muchas organizaciones ya tienen taxonomías de sensibilidad, pero no todas están diseñadas para ser útiles en IA. Una clasificación pensada únicamente para cifrado o DLP puede quedarse corta cuando se usa como señal de recuperación. Para que un agente pueda aprovechar las etiquetas, estas deben ser consistentes, comprensibles y aplicables a activos de datos relevantes.
Una taxonomía demasiado genérica, como “Public”, “Internal” y “Confidential”, puede ser suficiente para controles básicos, pero quizá no ayude a distinguir entre un dato financiero auditado, un dato operativo preliminar o un dataset de experimentación. Por otro lado, una taxonomía excesivamente granular puede ser difícil de mantener y generar etiquetas inconsistentes.
El punto de equilibrio suele estar en combinar sensibilidad con propósito. Por ejemplo, una organización podría mantener niveles de confidencialidad generales y añadir metadatos complementarios para dominio, certificación o audiencia. La etiqueta de sensibilidad indica protección; otros atributos indican calidad y uso recomendado. Para un agente, la combinación de estas señales es más útil que una etiqueta aislada.
Una forma práctica de empezar es revisar las preguntas que los agentes deben responder y mapearlas contra fuentes oficiales. Si el agente responderá preguntas de ventas, ¿cuáles son los semantic models aprobados? Si responderá consultas de soporte, ¿qué base de conocimiento es pública y cuál es interna? Si asistirá a equipos financieros, ¿qué informes están certificados y qué datasets son solo de trabajo?
Esta reflexión también obliga a separar claramente tres conceptos que a menudo se mezclan:
| Concepto | Pregunta que responde | Ejemplo |
|---|---|---|
| Permiso | ¿Quién puede acceder? | Un analista de finanzas puede leer el modelo financiero |
| Sensibilidad | ¿Qué nivel de protección requiere? | El modelo contiene información confidencial |
| Adecuación | ¿Debe usarse para esta respuesta? | Es la fuente aprobada para reporting trimestral |
Los agentes necesitan los tres. Si falta el permiso, el acceso debe denegarse. Si falta la sensibilidad, el sistema pierde contexto de riesgo. Si falta la adecuación, la respuesta puede ser técnicamente correcta pero organizativamente incorrecta.
Integración con arquitecturas RAG y agentes
En una arquitectura RAG con agentes, las etiquetas pueden participar en varias fases del flujo. Durante la indexación, se pueden capturar como metadatos asociados a documentos, tablas, informes o modelos semánticos. Durante la recuperación, se usan para filtrar o ponderar resultados. Durante la generación, pueden incluirse como contexto de sistema para que el modelo conozca el origen y restricciones de la información. Durante la auditoría, permiten explicar por qué se usaron unas fuentes y no otras.
Este último punto es crítico. La gobernanza de IA no termina en impedir accesos indebidos; también requiere trazabilidad. Si una respuesta de un agente se basa en datos confidenciales, la organización necesita poder reconstruir qué fuente se consultó, con qué identidad, bajo qué política y para qué usuario. En estrategias de seguridad integral para IA agentiva, esta trazabilidad es tan importante como el propio control de acceso.
Un flujo de alto nivel podría seguir esta secuencia:
- El usuario realiza una pregunta al agente desde un canal determinado.
- El orquestador identifica intención, audiencia y ámbito de la interacción.
- La capa de recuperación busca activos candidatos en Fabric u otras fuentes.
- Los resultados se filtran por permisos efectivos del usuario o identidad delegada.
- Las etiquetas de sensibilidad y metadatos de gobierno ajustan ranking o exclusión.
- El agente genera la respuesta usando solo el contexto seleccionado.
- El sistema registra fuentes, etiquetas, identidad, decisión y resultado.
Este patrón evita tratar la IA como una caja negra. El agente sigue siendo probabilístico en la generación, pero el proceso de selección de conocimiento se vuelve más controlable y explicable.
Ejemplo conceptual con metadatos en un índice
En muchos proyectos, la forma más directa de hacer que un agente aproveche etiquetas es incorporarlas al índice de búsqueda o al catálogo de conocimiento. El índice no debería almacenar únicamente texto y embeddings, sino también metadatos como dominio, owner, certificación, fecha de actualización y etiqueta de sensibilidad.
El siguiente ejemplo muestra un documento JSON que podría representar un activo indexado para recuperación. De nuevo, el objetivo no es documentar una API específica, sino mostrar qué tipo de señales conviene preservar cuando se prepara conocimiento para agentes.
{
"id": "finance-quarterly-revenue-report",
"title": "Quarterly Revenue Report",
"content": "Resumen consolidado de ingresos trimestrales aprobado por el equipo financiero.",
"source_type": "fabric_semantic_model",
"business_domain": "finance",
"sensitivity_label": "Confidential",
"certified": true,
"intended_audience": ["internal"],
"owner": "finance-data-office",
"last_reviewed": "2026-06-30"
}
La parte más relevante es que sensitivity_label aparece junto a otros metadatos de gobierno. Un agente rara vez debería decidir solo por una señal. Una fuente confidencial puede ser correcta para un usuario interno, pero no para una respuesta externa. Una fuente pública puede ser segura, pero no necesariamente suficiente para análisis interno. Una fuente certificada puede tener más peso que una fuente experimental aunque ambas contengan términos similares.
Si el agente tiene una capa de planificación, estos metadatos también pueden guiar la elección de herramientas. Por ejemplo, ante una pregunta regulatoria, puede preferir fuentes certificadas y revisadas recientemente. Ante una pregunta de comunicación externa, puede limitarse a contenido público o aprobado. Ante una pregunta exploratoria de un equipo interno, puede ampliar el rango de fuentes, pero marcando claramente el nivel de confianza de la respuesta.
Alineación organizativa: la parte que suele olvidarse
El título de la actualización original no habla solo de precisión, sino también de alineación organizativa. Esa segunda parte es fundamental. Un agente preciso desde el punto de vista lingüístico puede seguir siendo problemático si no respeta cómo la organización define sus datos, sus audiencias y sus procesos de aprobación.
La alineación aparece cuando el agente responde de acuerdo con las reglas explícitas e implícitas de la empresa. Por ejemplo, si el área financiera ha declarado un modelo semántico como fuente oficial para ingresos, el agente debería favorecer esa fuente frente a una exportación local. Si legal ha aprobado una versión pública de una política, el agente no debería sintetizar una respuesta externa desde documentos internos más detallados. Si un informe está etiquetado como altamente confidencial, su uso debe quedar limitado a escenarios donde exista justificación, permisos y trazabilidad.
Este enfoque también reduce fricción entre equipos. Los responsables de datos pueden usar etiquetas y metadatos para expresar intención sin tener que reescribir cada agente. Los equipos de IA pueden construir políticas de recuperación reutilizables. Seguridad puede auditar decisiones. Y los usuarios reciben respuestas más coherentes con la forma en que la organización entiende sus datos.
En este punto, conviene conectar la discusión con un principio más amplio: los agentes no deberían improvisar la gobernanza en tiempo de ejecución. La gobernanza debe estar modelada en las fuentes, los metadatos, las identidades, las políticas y la observabilidad. Las etiquetas de sensibilidad son una pieza de ese sistema, no una solución aislada.
Riesgos y límites del enfoque
Aunque el patrón es potente, tiene límites claros. El primero es la calidad de etiquetado. Si los activos no están etiquetados, o lo están de forma inconsistente, el agente recibirá señales pobres. En ese caso, la etiqueta puede generar falsa confianza. Es preferible empezar con un conjunto reducido de activos críticos bien gobernados que intentar etiquetar todo sin criterios claros.
El segundo riesgo es sobrerrestringir la recuperación. Si las reglas son demasiado estrictas, el agente puede quedarse sin contexto suficiente y responder de forma vaga. Esto se mitiga diseñando comportamientos explícitos para ausencia de datos: pedir aclaración, declarar limitaciones o escalar a una fuente autorizada.
El tercer riesgo es confundir sensibilidad con veracidad. Una fuente altamente confidencial no es necesariamente más correcta que una pública. Puede contener borradores, hipótesis o datos operativos no reconciliados. Por eso las etiquetas deben convivir con señales de certificación, linaje y calidad.
El cuarto riesgo es no auditar. Si una organización permite que los agentes usen datos etiquetados, necesita logs que registren qué etiquetas participaron en cada respuesta. Sin esa evidencia, será difícil demostrar cumplimiento o investigar incidentes.
Recomendaciones para empezar
La forma más efectiva de adoptar este enfoque no es crear una gran taxonomía desde el primer día, sino seleccionar un caso de uso agentivo con riesgo y valor claros. Por ejemplo, un asistente interno para analistas financieros, un agente de soporte que combina documentación pública e interna, o un copiloto de ventas que accede a materiales aprobados y datos de cliente.
A partir de ahí, conviene identificar las fuentes de datos que el agente debería usar, revisar sus etiquetas actuales y definir una política simple de recuperación. Esa política debe indicar qué etiquetas se permiten para cada audiencia, cuáles se priorizan, cuáles requieren advertencias y cuáles quedan excluidas. Después, la implementación puede llevar esas reglas al índice, al orquestador o a la capa de herramientas.
Un punto práctico es mantener las reglas fuera del prompt siempre que sea posible. El prompt puede explicar al modelo cómo comportarse, pero los filtros de acceso y selección deberían ejecutarse en código o en servicios de recuperación. Esto evita depender de que el modelo “recuerde” respetar una política y facilita auditoría.
También es importante probar con preguntas adversariales o ambiguas. Un usuario puede pedir “dame el forecast más reciente para compartir con un cliente” o “resume los riesgos internos de este producto en lenguaje público”. Estas preguntas mezclan intención, audiencia y sensibilidad. Son excelentes pruebas para validar si las etiquetas están ayudando realmente al agente a elegir bien.
Una pieza fundacional para agentes empresariales
El uso de etiquetas de sensibilidad para mejorar agentes de IA representa un cambio de enfoque: pasar de agentes que simplemente encuentran información a agentes que seleccionan conocimiento de forma gobernada. En entornos empresariales, esa diferencia es decisiva. La respuesta correcta no es solo la que coincide con la pregunta, sino la que usa la fuente adecuada, respeta la audiencia y deja trazabilidad.
Microsoft Fabric aporta un terreno especialmente relevante para este patrón porque concentra datos analíticos, modelos semánticos e informes donde las etiquetas pueden tener impacto directo. Combinadas con permisos, certificación, linaje y recuperación agentiva, las etiquetas de sensibilidad pueden reducir ruido, evitar mezclas de contexto y mejorar la confianza en las respuestas.
La arquitectura resultante no elimina la necesidad de buen diseño RAG, evaluación o seguridad. Al contrario, las refuerza. Un agente empresarial fiable necesita una capa de conocimiento bien estructurada, una recuperación controlada y una política clara sobre qué datos son apropiados para cada escenario. Las etiquetas de sensibilidad son una señal sencilla de entender, pero poderosa cuando se integra en todo el ciclo: indexación, recuperación, generación y auditoría.