IA en la sombra, explicada.

«Shadow IT» describía un patrón familiar mucho antes de que la IA entrara en escena: empleados adoptando en silencio aplicaciones en la nube, herramientas para compartir archivos o software que TI nunca aprobó, revisó ni siquiera supo que existía, porque la opción autorizada era más lenta o peor. La IA en la sombra es ese mismo patrón, aplicado a la ola actual de productos de IA –y se está extendiendo más rápido de lo que nunca lo hizo el shadow IT, porque la barrera de entrada es una cuenta gratuita y una pestaña del navegador, no un ticket de TI ni un ciclo de compras.

La distinción importa porque el riesgo no es solo «hay una aplicación sin monitorizar corriendo en algún sitio». Con la IA en la sombra, lo que suele quedar expuesto son los propios datos –pegados directamente en un cuadro de texto, enviados a los servidores de un tercero y, en algunos casos, usados como entrada de entrenamiento o de registro, sin contrato, sin rastro de auditoría y sin forma de recuperarlos una vez que se han ido.

Qué aspecto tiene realmente la IA en la sombra

Rara vez se anuncia a sí misma como un incidente de seguridad. En la práctica, la IA en la sombra suele ser uno de un pequeño número de hábitos cotidianos:

• Una cuenta personal gratuita en un chatbot de consumo usada para resumir el contrato de un cliente, reescribir un correo interno o redactar una propuesta que contiene detalles sensibles del negocio.
• Extensiones de navegador que prometen «superpoderes de IA» –resume esta página, reescribe este texto, transcribe esta reunión– instaladas sin revisión, a menudo solicitando permisos amplios para leer todo lo que ve el navegador.
• Asistentes de código con IA y plugins de IDE sin gestionar, apuntados a una base de código real, que leen y a veces transmiten archivos fuente, configuración e historial de commits a un servicio de terceros que el equipo de seguridad nunca evaluó.
• Herramientas SaaS que añadieron funciones de IA en silencio a un producto ya aprobado, a veces enrutando los datos hacia un proveedor de modelo distinto en el backend del que cubría la evaluación original del proveedor.

Ninguno de estos casos requiere intención maliciosa. Casi todos son alguien intentando hacer su trabajo más rápido, con una herramienta que resulta funcionar bien. Eso es exactamente lo que también hizo difícil erradicar el shadow IT, y es la misma dinámica que impulsa la adopción aquí.

Por qué ocurre, incluso en empresas concienciadas con la seguridad

La IA en la sombra prospera específicamente donde hay un hueco entre lo que necesitan los empleados y lo que está disponible oficialmente. Un ciclo de compras y revisión de seguridad para una nueva herramienta de IA empresarial puede tardar meses; la demo del producto de un competidor, la recomendación de un compañero o una publicación viral sobre un nuevo asistente se puede probar en treinta segundos. Si la opción autorizada es tosca, restringida o simplemente todavía no existe para un caso de uso concreto, la gente no deja de intentar usar IA: solo deja de pedir permiso primero.

También hay un hueco de percepción que empeora esto: una pestaña del navegador y una pantalla de inicio de sesión se ven idénticas, ya sea que la herramienta detrás sea un producto empresarial totalmente auditado o la beta gratuita de una startup de dos personas. Nada en la interfaz indica «esta registra y entrena con tu entrada» frente a «esta, contractualmente, no lo hace». Los empleados no están siendo temerarios tanto como están haciendo un juicio de valor sin información visible en la que basarse, que es exactamente el tipo de hueco que una política por escrito y una lista corta de herramientas aprobadas están pensadas para cerrar.

Los mecanismos de riesgo reales

Vale la pena ser específico sobre cómo la IA en la sombra causa daño realmente, en lugar de tratarla como una vaga preocupación de gobernanza:

Esa última fila es fácil de infravalorar hasta que una auditoría o un regulador la pide directamente. Marcos como el RGPD, la HIPAA y SOC 2 exigen todos que una organización sepa a dónde fueron los datos regulados y quién tuvo acceso a ellos. «Es posible que un empleado pegara los datos personales de un cliente en un chatbot de consumo en algún momento, pero no tenemos registro de ello» no es una afirmación respondible en ese tipo de revisión: es un hallazgo. La IA en la sombra no solo crea un riesgo técnico de fuga; crea un hueco precisamente en el tipo de registro que los programas de cumplimiento están construidos para exigir.

El uso autorizado de IA tiene una estructura distinta

Nada de esto es un argumento en contra de usar herramientas de IA en el trabajo: es un argumento a favor de la diferencia entre usarlas gobernadas y usarlas invisibles a la gobernanza. Un programa de IA correctamente autorizado se construye en torno a unos pocos elementos concretos y verificables, en lugar de una instrucción general de «ten cuidado»:

• Condiciones de API empresariales que excluyen explícitamente el entrenamiento con la entrada. Los acuerdos empresariales serios con los principales proveedores de IA se comprometen contractualmente a que los datos enviados no se usarán para entrenar modelos, un arreglo materialmente distinto de las condiciones por defecto de un nivel de consumo gratuito.
• Acceso vinculado a la identidad. La integración con SSO y las consolas de administración significan que el uso está vinculado a una identidad real de empleado, se puede aprovisionar y desaprovisionar como cualquier otro sistema de la empresa, y produce logs que la organización realmente controla.
• Herramientas de DLP orientadas al tráfico de IA. Sistemas de prevención de pérdida de datos que pueden inspeccionar, marcar o bloquear datos sensibles –credenciales, datos personales regulados, código fuente– antes de que lleguen siquiera a un endpoint de IA, autorizado o no.
• Una política interna de uso de IA por escrito. Un documento concreto y específico que indique qué herramientas están aprobadas, qué clasificaciones de datos pueden o no introducirse en ellas, y cuál es la vía de escalado para una nueva herramienta que alguien quiera adoptar –no un vago memorando de «usa la IA de forma responsable».

El último punto es el que hace más trabajo práctico. Una política que solo dice que no, sin una vía rápida para que una nueva herramienta genuinamente útil sea evaluada y aprobada, garantiza más IA en la sombra, no menos: los empleados rodean las puertas lentas en lugar de esperar por ellas.

Construyendo hacia un uso gobernado de la IA

Reducir la IA en la sombra no es principalmente un problema tecnológico: es un problema de inventario e incentivos, y tiende a seguir una secuencia predecible:

• Averigua qué ya está en uso. Una encuesta corta y no punitiva, junto con datos de descubrimiento de red y de SaaS, normalmente revela mucha más adopción de IA en la sombra de la que esperan los equipos de seguridad: no puedes gobernar lo que no has inventariado.
• Levanta una alternativa autorizada que sea realmente competitiva. Si la herramienta aprobada es notablemente peor que la opción de consumo gratuita que a la gente ya le gusta, la adopción de la versión autorizada se mantiene baja sin importar la política.
• Escribe la política con especificidad, no con generalidades. Nombra las herramientas aprobadas, nombra las clasificaciones de datos que nunca pueden salir del perímetro, y da un punto de contacto real para solicitar la evaluación de una nueva herramienta.
• Pon controles técnicos detrás de la política. Las reglas de DLP y la visibilidad a nivel de red capturan lo que se les escapa a la formación y a las buenas intenciones, y lo hacen de forma consistente en lugar de depender de que todos recuerden las reglas.
• Forma para los modos de fallo específicos, no para la IA en abstracto. «No pegues contratos de clientes en un chatbot gratuito» y «no le des a una extensión de navegador acceso a tu pestaña de correo» son reglas concretas y memorables; «usa la IA de forma responsable» no lo es.

Esta es también la razón por la que la IA en la sombra pertenece junto a los temas de seguridad de IA más centrados en el ataque que cubrimos en otros artículos, en lugar de quedar a un lado como un problema puramente de cumplimiento. El red teaming de IA trata de encontrar debilidades en los sistemas de IA que has elegido construir o desplegar. La inyección de prompts trata de cómo se atacan esos sistemas una vez que están en producción. La IA en la sombra es la pregunta de gobernanza que subyace a ambas: ninguna de esas pruebas o defensas significa mucho si los datos también están saliendo a través de herramientas de IA que nadie en el equipo de seguridad sabe siquiera que están en uso.

La IA en la sombra no es un riesgo futuro hipotético: es la consecuencia directa y predecible de que las herramientas de IA se volvieran gratuitas, rápidas y genuinamente útiles más rápido de lo que la mayoría de las organizaciones pudieron construir un programa de gobernanza a su alrededor. La solución no es intentar prohibir el uso de IA, algo que rara vez funciona durante mucho tiempo contra una herramienta que la gente encuentra genuinamente útil. Es hacer que la vía autorizada sea lo bastante rápida, y la política lo bastante específica, para que rodearla deje de ser la opción más fácil.

Preguntas frecuentes