La seguridad de IA ya no es un tema teórico. En muchas organizaciones, los empleados usan herramientas de IA para automatizar tareas, coordinar flujos de trabajo y encontrar formas de optimizar procesos complejos. Parte de ese uso ocurre dentro de herramientas revisadas y aprobadas por TI. Pero otra parte sucede en espacios difíciles de vigilar: cuentas personales y extensiones del navegador que nadie del equipo de seguridad llegó a analizar.
Durante años, el enfoque clásico para reducir riesgos funcionó bien para el “SaaS sprawl”: descubrir aplicaciones, controlar el acceso y aplicar reglas de protección de datos con CASB y DLP. Sin embargo, la IA introduce un tipo de riesgo diferente. Para gestionarlo, hace falta una capa que no solo mire el acceso, sino que sepa “qué está pasando” dentro de la conversación.
Por qué la seguridad de IA no se comporta como el riesgo de SaaS
En un entorno tradicional, el riesgo suele estar acotado. Puede residir en una aplicación específica, en un archivo o en un campo estructurado. Los controles de seguridad pueden concentrarse en el perímetro: si el usuario accede a una app autorizada y si el contenido cumple políticas, el riesgo baja.
Con IA, el problema aparece de otra manera. Se manifiesta en el prompt que una persona escribe, en la respuesta generada por el modelo y, en escenarios cada vez más comunes, en lo que hacen agentes autónomos cuando un prompt malicioso los induce a actuar.
Esto significa que el riesgo no siempre se alinea con lo que CASB y DLP fueron diseñados para inspeccionar. Los controles tradicionales pueden detectar patrones en datos o eventos dentro de una app, pero la IA agrega una capa semántica: el significado acumulado de la interacción.
Limitaciones de CASB y DLP frente a prompts y contexto
Un punto clave es que CASB suele responder a preguntas del tipo: “¿el usuario puede acceder a esta aplicación?”. En muchos casos, además gobierna qué puede hacer dentro de la herramienta. Pero al tratar la IA, la pregunta relevante no es solo si la app está permitida, sino qué contenido se pide, qué produce y qué acciones se ejecutan.
El control por acceso puede fallar cuando la exposición aparece más tarde. Por ejemplo: el usuario tiene permitido usar el servicio de IA, pero el riesgo emerge cuando escribe un prompt que hace que el modelo procese o reconstruya información sensible. En otras palabras, la conversación es el lugar donde ocurre la exposición.
Además, la IA no siempre expone datos de forma obvia. No siempre se trata de pegar un número de cuenta o una clave de API dentro del chat. A veces la información sensible se comparte de manera indirecta a lo largo de varios mensajes, descrita con términos que el modelo interpreta como suficientes para deducir o reconstruir el contenido real. Aunque no exista una coincidencia directa con una regla típica de DLP, el impacto puede ser real para el negocio.
Ejemplos de riesgo que no encajan en reglas clásicas
- Negociación comercial: se podrían compartir fragmentos sobre un contrato con un proveedor que se cerrará en días, generando riesgo aunque no haya coincidencia con una regla de filtrado.
- Incidentes y resúmenes: redactar un resumen de un incidente puede parecer inofensivo, pero el contexto puede revelar información sensible sobre causa, impacto o resolución.
- Respuestas con lógica propietaria: si un desarrollador pide ayuda con una consulta genérica, el riesgo puede ser bajo; pero si incorpora lógica propietaria o un problema ligado a clientes, el riesgo sube, tanto si la información se comparte como si se genera en la salida.
El dilema para los equipos de seguridad
Cuando la gobernanza se aprieta demasiado, el uso se desplaza. Si CASB restringe con demasiada fuerza, los empleados buscan alternativas: aplicaciones no administradas o extensiones que el equipo de seguridad no puede ver. Resultado: aumenta el “shadow AI”.
Por el lado contrario, si DLP es demasiado permisivo, la organización deja abiertas puertas para filtraciones de datos. La combinación de ambos escenarios puede generar una falsa sensación de control: se permite el acceso, pero se pierde visibilidad sobre el contenido, la intención y las acciones resultantes.
La solución no pasa por elegir uno u otro. Se trata de reconocer que hay capas distintas del problema, y que la capa de interacción es imprescindible para la seguridad de IA.
Inspección de interacción: donde realmente ocurre la exposición
Para gestionar el riesgo con IA, los controles deben operar en el punto donde aparece la amenaza: la conversación entre la persona y el modelo. Eso implica analizar con detalle:
- qué se está pidiendo (intención del prompt),
- qué genera el modelo como respuesta,
- qué herramientas o servicios invoca un agente,
- qué datos recupera o transmite,
- y si la acción final está autorizada por políticas.
En vez de limitarse a decidir “bloquear o permitir” el acceso al servicio de IA, la estrategia debe poder responder preguntas más cercanas a lo que importa: si esa interacción es segura y si las acciones derivadas están permitidas.
Cómo cambia la evaluación en escenarios reales
- Contenido de marketing vs. información no anunciada: usar IA para un esquema de blog suele ser rutinario. Pero usarla para textos de entrada a mercado que referencian un producto aún no divulgado puede introducir riesgo.
- Conocimiento aprobado vs. filtración: un agente que consulta una base de conocimiento aprobada puede ser razonable. El problema surge si, al final, reenvía documentación interna restringida hacia afuera.
- Inyección de prompts: tratar contenido recuperado como “datos” suele ser lo esperado. Sin embargo, cuando instrucciones se incrustan de forma inteligente dentro del material, un agente puede seguirlas sin que el modelo distinga con fiabilidad datos de instrucciones. Esto convierte la inyección de prompts en un riesgo serio.
- Autorización que no es suficiente: autenticar una sesión es una línea base, pero no basta. Un pedido de bajo riesgo puede transformarse en una acción de alto riesgo según el contexto. Aquí es donde la detección de anomalías basada en el comportamiento puede ayudar a decidir qué permitir.
Ampliar la gobernanza, no solo bloquear el acceso
Un enfoque de “deny by default” puede parecer seguro, pero suele quedarse corto a largo plazo. Si se bloquea todo de forma rígida, los plazos laborales empujan el uso hacia cuentas personales o extensiones no gestionadas. Con ello se profundiza el problema de visibilidad: el equipo de seguridad deja de ver el flujo completo.
La buena estrategia para seguridad de IA es “extender la gobernanza” a la interacción, en lugar de depender únicamente del bloqueo del acceso. Esto mantiene el espacio para que los empleados adopten y experimenten con IA, mientras los datos sensibles y el comportamiento de los agentes quedan dentro de límites claros.
En la práctica, la estrategia suele incorporar tres frentes complementarios:
- Gestionar riesgos cotidianos: tratar la inyección de prompts y el mal uso de agentes como riesgos reales, no como casos raros para el futuro.
- Usar CASB y DLP con objetivos claros: descubrir aplicaciones SaaS y de IA en uso, gobernar accesos, detectar patrones conocidos de sensibilidad y apoyar reportes de cumplimiento.
- Agregar una capa de interacción: analizar semántica del prompt, sensibilidad de la respuesta y si la acción del agente está autorizada.
De “¿puede abrir la herramienta?” a “¿es segura esta interacción?”
El punto de partida cambia cuando pensamos en IA. La pregunta tradicional —“¿este usuario puede abrir la herramienta?”— no captura el corazón del riesgo. Con IA, el riesgo puede aparecer en la conversación, en la salida o en la ejecución de acciones por parte de agentes.
La pregunta correcta es otra: ¿el prompt es seguro?, ¿la respuesta es segura?, ¿la acción resultante está autorizada? Si tu estrategia responde a estas tres cuestiones, puedes permitir que los equipos trabajen con IA de forma productiva, sin perder de vista los límites necesarios para proteger datos sensibles, propiedad intelectual y el comportamiento de los agentes.
Conclusión
La seguridad de IA requiere más que controlar el acceso a aplicaciones y aplicar reglas de protección de datos. CASB y DLP siguen siendo útiles para descubrir, gobernar y detectar patrones conocidos, pero no siempre alcanzan para evaluar el significado acumulado de una conversación con IA ni las acciones que un agente puede ejecutar.
La diferencia la marca una capa consciente de interacción: inspecta prompts, respuestas, recuperaciones y transacciones, y verifica autorizaciones en el momento en que el riesgo realmente ocurre. Así, la organización puede reducir exposición sin empujar el uso hacia alternativas no gestionadas.
