Cómo proteger tus datos ante el uso de IA en entornos corporativos: riesgos reales, Purview, proxies y alternativas del mercado

La adopción de IA generativa en entornos corporativos ha dejado de ser un experimento aislado. Hoy conviven ChatGPT Enterprise, Microsoft 365 Copilot, Gemini, Claude, herramientas embebidas en suites SaaS y una larga cola de servicios que los empleados prueban por su cuenta. El problema es que, en demasiadas empresas, la conversación va mucho más rápido que el gobierno del dato. Se despliega IA para ganar productividad, pero no siempre se define qué información puede salir, qué datos pueden usarse en prompts, qué aplicaciones están aprobadas, cómo se auditan las interacciones o qué ocurre cuando el usuario mezcla un documento sensible con un copiloto público.

El verdadero riesgo no es solamente “usar IA”. El riesgo es usarla sin controles equivalentes a los que ya exigimos para el correo, el almacenamiento en la nube, el acceso remoto o la navegación web. Una organización que protege con mimo su ERP, su CRM y sus repositorios documentales puede perder ese esfuerzo en segundos si un empleado pega en un prompt un contrato, un listado de clientes, un informe financiero o código fuente con secretos de negocio. Microsoft explica en su documentación de Purview para IA generativa que la IA amplifica el problema de la sobreexposición y de la fuga de datos precisamente por la velocidad con la que puede descubrir, resumir o redistribuir contenido sensible.

En este artículo vamos a analizar en profundidad cómo se debe abordar la protección de datos frente al uso corporativo de IA, qué papel juegan los proxies y los secure web gateways con whitelisting y blacklisting, cómo encaja Microsoft Purview con el etiquetado y la clasificación, qué aportan plataformas como Defender for Cloud Apps, Netskope o Zscaler, y por qué el enfoque correcto no es prohibir de forma ciega, sino construir una arquitectura de control por capas.

El problema real: la IA convierte la fuga casual en una fuga sistemática

Antes de la explosión de la IA generativa, una fuga de información solía requerir más fricción: adjuntar un fichero, subirlo a un servicio, enviarlo a un tercero o copiarlo fuera del entorno corporativo. La IA cambia esa dinámica porque transforma el propio acto de pedir ayuda en una posible exfiltración. El usuario cree que “solo está preguntando”, cuando en realidad puede estar cediendo contexto crítico: un correo de cliente, un procedimiento interno, una incidencia de seguridad, una transcripción de reunión o una hoja de cálculo con datos personales.

Ese cambio es especialmente delicado por cinco razones:

Los prompts parecen inocuos: un usuario no siempre percibe que un párrafo pegado en una IA equivale a compartir datos.
La IA incentiva el copiado masivo: cuanto más contexto se pega, mejor suele ser la respuesta.
Existen cientos de aplicaciones: no se trata de controlar dos o tres herramientas, sino un ecosistema enorme y muy dinámico.
Hay IA embebida en SaaS aprobados: el riesgo no viene solo de servicios externos no autorizados, sino también de funciones nuevas en herramientas corporativas.
La superficie es híbrida: navegador, aplicaciones de escritorio, extensiones, APIs, agentes, plugins, móviles y RAG corporativo.

La documentación de Microsoft sobre descubrimiento de IA insiste en que la primera tarea de seguridad no es bloquear por defecto, sino ganar visibilidad sobre qué aplicaciones se usan, qué datos tocan y qué riesgos generan. Sin esa fase de descubrimiento, la organización solo opera a ciegas.

Qué datos debes proteger de forma prioritaria

No todos los datos tienen el mismo impacto si acaban en una IA no controlada. Por eso, antes de hablar de herramientas, conviene ordenar la información en categorías operativas:

Datos personales: clientes, empleados, candidatos, historiales, identificadores, datos de salud, nóminas.
Información financiera: previsiones, resultados, márgenes, precios, presupuestos, M&A.
Propiedad intelectual: código fuente, diseños, algoritmos, procedimientos, documentación técnica.
Información contractual y legal: borradores, acuerdos, litigios, due diligence, informes de compliance.
Credenciales y secretos: claves API, tokens, certificados, configuraciones, secretos incrustados en scripts.
Información estratégica: roadmap, decisiones internas, posicionamiento comercial, análisis de competencia.

La consecuencia práctica es evidente: si no sabes identificar automáticamente este tipo de información, tampoco podrás impedir que salga por un prompt, por un fichero adjunto o por una integración API. Ahí entra la primera gran pata del problema: clasificación y etiquetado.

Microsoft Purview: clasificar, etiquetar y aplicar DLP antes de hablar de IA

Muchas organizaciones buscan “una solución para la IA” cuando en realidad lo primero que les falta es una solución madura de gobierno del dato. Microsoft Purview tiene sentido precisamente por eso: no empieza en la IA, sino en la protección del contenido. Sus controles para IA generativa se apoyan en capacidades ya conocidas como sensitivity labels, DLP, auditoría, eDiscovery y DSPM para IA.

En la práctica, Purview aporta varias capas muy útiles:

Etiquetas de sensibilidad para marcar contenido como público, interno, confidencial o altamente confidencial.
Clasificación automática mediante tipos de información sensible, patrones, clasificadores entrenables y reglas.
Data Loss Prevention para detectar y bloquear salidas no autorizadas en Edge, endpoints y flujos compatibles.
Auditoría y trazabilidad sobre actividades relacionadas con IA y acceso al contenido.
DSPM para IA para entender exposición, sobrecompartición y recomendaciones de endurecimiento.

Este punto es clave: si un documento tiene una etiqueta bien diseñada y esa etiqueta impone restricciones de acceso o cifrado, la IA integrada en el ecosistema Microsoft debería respetar esos límites. Es decir, el control no se hace “solo sobre la aplicación de IA”, sino sobre la propia naturaleza y sensibilidad del dato. Esa es una diferencia profunda frente a enfoques más superficiales basados únicamente en listas de dominios.

Whitelisting y blacklisting mediante proxy o Secure Web Gateway

La segunda gran capa es el control del canal de salida. Aquí entran los proxies tradicionales, los secure web gateways modernos y las plataformas SSE/SASE. La idea es sencilla: si los empleados van a interactuar con servicios de IA desde el navegador, la organización debe decidir qué aplicaciones están permitidas, cuáles se bloquean y cuáles se monitorizan.

Hay varias estrategias posibles:

Blacklist: bloquear dominios y servicios explícitamente no autorizados.
Whitelist: permitir solo un conjunto aprobado de servicios de IA corporativos.
Modelo mixto: permitir navegación general, pero bloquear acciones de subida, pegado o descarga en apps de riesgo.
Políticas por usuario, grupo o dispositivo: distintos niveles para IT, legal, desarrollo, RRHH o dirección.

El enfoque basado en solo blacklist suele quedarse corto porque el catálogo de herramientas cambia cada semana. Aun así, sigue siendo útil para cortar de raíz el acceso a servicios expresamente prohibidos. La documentación de Microsoft Defender for Cloud Apps explica cómo marcar aplicaciones como unsanctioned y cómo integrarlas con mecanismos de bloqueo posteriores, ya sea con Microsoft Defender for Endpoint o con plataformas terceras compatibles.

La whitelist, por otro lado, es mucho más robusta cuando el caso de uso está claro: “solo se puede usar Copilot corporativo y ChatGPT Enterprise desde cuentas aprobadas”. El problema es operativo: requiere tener alternativas reales para el negocio, o de lo contrario disparará el shadow IT y las evasiones.

Por qué el proxy por sí solo no basta

Bloquear dominios ayuda, pero no resuelve todo. Una empresa puede permitir un único servicio de IA y aun así sufrir fuga si un usuario pega datos sensibles en ese servicio sin controles adicionales. Además, muchas aplicaciones de IA ya vienen integradas en suites SaaS aprobadas, con lo que no basta con bloquear “chat.openai.com” o “gemini.google.com”.

Por eso, el proxy moderno debe hacer algo más que permitir o denegar acceso:

inspeccionar tráfico web y acciones del usuario,
detectar subidas de archivos y envíos de formularios,
aplicar DLP inline,
distinguir entre instancia personal y corporativa,
bloquear copy/paste o subida de datos según sensibilidad,
registrar eventos para auditoría.

Ahí es donde plataformas como Netskope One y la AI Security Suite de Zscaler intentan diferenciarse: no solo descubren apps de IA, sino que aplican políticas más granulares con contexto de usuario, acción, contenido y riesgo.

Netskope, Zscaler y el modelo SSE: visibilidad, control y contexto

El valor de un SSE moderno para IA está en combinar visibilidad y enforcement. Netskope destaca en su documentación que puede clasificar cientos de aplicaciones GenAI, vigilar el uso de instancias personales frente a corporativas, y aplicar DLP inline con controles sobre subir, descargar, copiar o imprimir. Zscaler, por su parte, está empujando un discurso de Zero Trust para IA centrado en visibilidad, clasificación de prompts, inspección inline y gobernanza del uso empresarial.

Traducido a decisiones prácticas, esto permite escenarios como:

permitir ChatGPT Enterprise, pero bloquear ChatGPT personal,
permitir lectura de respuestas, pero no subida de documentos confidenciales,
permitir prompts sobre información pública, pero no sobre datos marcados con DLP,
permitir acceso desde equipos gestionados y bloquearlo desde BYOD o redes no confiables.

Ese matiz es fundamental porque la empresa no necesita una política binaria. Necesita controles adaptativos. Hay departamentos que requerirán IA intensiva y otros en los que el riesgo no compensa. Hay datos que pueden usarse para resumir y otros que jamás deberían salir del tenant. Y hay herramientas con garantías contractuales aceptables frente a otras que son puro shadow AI.

Defender for Cloud Apps y el descubrimiento de Shadow AI

Uno de los errores más comunes es pensar que la organización ya controla la IA porque “solo ha aprobado una herramienta”. En realidad, lo crítico es descubrir qué se usa de verdad. Defender for Cloud Apps aporta valor justo ahí: catálogo de aplicaciones, puntuación de riesgo, clasificación como Generative AI y flujos de sanción o bloqueo. Microsoft insiste en que descubrir, monitorizar y bloquear aplicaciones generativas no es un lujo, sino un paso esencial para evitar fuga de datos y mantener el gobierno.

La parte interesante de esta aproximación es que te permite pasar de una conversación teórica a una operativa:

qué apps se están usando,
qué usuarios las usan,
desde qué dispositivos,
con qué volumen,
y si deben sancionarse o bloquearse.

Esto es especialmente útil cuando quieres implantar una estrategia de allowlist realista. Primero observas, después mides, luego defines alternativas aprobadas y finalmente aplicas bloqueo progresivo a lo no sancionado. Intentar hacerlo al revés suele producir más resistencia y menos seguridad.

El endpoint también importa: navegador, clipboard y DLP local

La protección no termina en la red. Si el usuario puede copiar un informe sensible desde su escritorio, pegarlo en una IA y hacer la petición desde cualquier navegador, necesitas controles en el endpoint. Microsoft, de hecho, vincula buena parte de sus capacidades de control de IA a dispositivos correctamente incorporados al ecosistema de protección, con Edge protegido, navegadores alternativos controlados y políticas DLP activas.

En este punto, las capacidades más valiosas suelen ser:

bloqueo o advertencia al pegar datos sensibles en apps de IA,
bloqueo de subida de archivos etiquetados,
políticas distintas según usuario o grupo,
registro forense de intentos de exfiltración,
integración con UEBA, insider risk y CASB.

Si el control de red no puede inspeccionar cierto canal, el endpoint sigue siendo la última barrera. Y si el endpoint no está bien gobernado, el proxy se queda corto. Otra vez aparece la idea central: defensa en profundidad.

El caso especial de Microsoft 365 Copilot, RAG y los modelos privados

No toda la IA se consume como un servicio web público. En muchas organizaciones, el principal riesgo estará en copilotos empresariales que acceden al contenido del tenant, o en soluciones RAG internas conectadas a SharePoint, OneDrive, bases documentales o data lakes. Aquí el peligro no es tanto “sacar datos fuera”, sino sobreexponer información a quien no debería verla.

Eso obliga a revisar tres cosas:

Permisos heredados: si el dato ya está sobrecompartido, la IA lo hará más visible.
Etiquetas y clasificación: el motor debe respetar sensibilidad, cifrado y acceso.
Gobierno del índice y de las fuentes: no todo repositorio debe ser indexable por copilotos o agentes.

De hecho, una de las lecciones más repetidas en proyectos de Copilot es que no se puede desplegar bien sin antes hacer limpieza de permisos, enlaces abiertos y comparticiones heredadas. La IA no crea el desorden, pero lo explota con brutal eficiencia.

Otras soluciones y enfoques del mercado

Además de Microsoft, Netskope o Zscaler, el mercado se está llenando de controles para IA con distintos enfoques. Algunos se centran en navegación segura, otros en API security, otros en DSPM y otros en runtime guardrails para aplicaciones construidas por la propia empresa. No todas las organizaciones necesitan comprar todas las piezas, pero sí entender las familias de soluciones disponibles:

SSE/SWG/CASB: control de acceso, visibilidad y DLP inline para apps generativas.
Data Security / DSPM: descubrimiento de datos sensibles, clasificación, posture management y priorización.
Endpoint DLP: control local de copy/paste, subida, impresión y transferencia.
Identity & Zero Trust: condicionar uso de IA por identidad, dispositivo, sesión, ubicación y riesgo.
AI gateways y policy engines: interponer una capa entre el usuario y el modelo para registrar prompts, filtrar datos, tokenizar y aplicar redacción.
RAG security / model security: proteger índices, conectores, embeddings, secretos y runtime de agentes y aplicaciones propias.

La clave es evitar comprar soluciones aisladas sin arquitectura. Si ya tienes Purview y Defender, probablemente debas exprimir ese stack antes de duplicarlo. Si tu organización ya vive en un SSE maduro, quizá te interese complementar con DSPM fuerte. Lo que rara vez funciona es una “herramienta mágica de IA” sin clasificación del dato, sin control del navegador y sin gobierno de identidades.

Una estrategia realista para limitar el uso de la IA sin frenar el negocio

La mejor estrategia no suele ser “prohibir toda IA” ni “permitir todo y ya veremos”. Una hoja de ruta sensata suele tener estas fases:

Descubrir: inventariar qué apps de IA se están usando realmente.
Clasificar: etiquetar y priorizar el dato sensible que nunca debe salir.
Sancionar: definir herramientas aprobadas por caso de uso.
Bloquear: cortar accesos no autorizados con blacklist o unsanctioning.
Permitir con guardrails: usar allowlists, DLP inline y políticas por grupo.
Auditar: registrar eventos, prompts, incidentes y excepciones.
Revisar permisos: especialmente si usas copilotos conectados al contenido interno.
Formar: enseñar a los usuarios qué no deben pegar nunca, aunque la app esté autorizada.

La formación, por cierto, es crítica. La mejor plataforma del mundo no compensa una cultura en la que los usuarios creen que “si la empresa lo permite, puedo pegar lo que sea”. La norma debería ser clara: el hecho de que una IA sea corporativa no convierte cualquier dato en apto para ser usado en un prompt.

Conclusión: proteger datos frente a la IA es un problema de arquitectura, no de moda

La empresa que quiera aprovechar la IA sin exponer su información necesita abandonar los enfoques simplistas. No basta con bloquear un dominio, ni con comprar un copiloto, ni con poner una política genérica de DLP. Hace falta una arquitectura completa que combine clasificación del dato, etiquetado, visibilidad de uso, sanción de aplicaciones, proxy o secure web gateway, DLP en red y endpoint, gobierno de permisos y auditoría.

Microsoft Purview aporta una base sólida allí donde el ecosistema Microsoft ya es central. Defender for Cloud Apps ayuda a descubrir, sancionar y bloquear Shadow AI. Netskope y Zscaler ofrecen control inline, SSE y visibilidad contextual sobre el uso de aplicaciones generativas. Y por encima de todo ello sigue vigente un principio clásico: el dato debe viajar con su política de protección. Si tu organización consigue eso, la IA se convierte en una herramienta poderosa. Si no, se convierte en una fuga de información con interfaz conversacional.

Preguntas frecuentes

Q: ¿Es mejor bloquear toda la IA pública en la empresa?

A: No siempre. En muchos casos es más eficaz descubrir qué herramientas se usan, aprobar unas pocas alternativas corporativas y bloquear el resto con controles de red, endpoint y DLP.

Q: ¿Qué aporta Microsoft Purview en un proyecto de IA corporativa?

A: Aporta clasificación, etiquetas de sensibilidad, DLP, auditoría, eDiscovery y capacidades de postura de seguridad para IA, lo que ayuda a proteger el dato antes y durante su uso en copilotos y aplicaciones generativas.

Q: ¿Para qué sirven el whitelisting y el blacklisting en este contexto?

A: Sirven para decidir qué aplicaciones de IA se permiten y cuáles se bloquean. El blacklisting corta servicios no autorizados y el whitelisting limita el uso a herramientas aprobadas por la organización.

Q: ¿Por qué no basta solo con un proxy o secure web gateway?

A: Porque el riesgo no está solo en acceder a una app de IA, sino en qué datos se copian, se suben o se exponen. Por eso hacen falta además clasificación, DLP, control de endpoint, permisos y auditoría.