AIBlog del CAIO
← Todos los artículos

IA / Análisis

Shadow AI en octubre de 2026: cómo descubrirla, gobernarla y controlar sus riesgos

Guía práctica de Shadow AI: agentes, conectores, inventario, controles verificables, ISO/IEC 42001 y 27090, contexto chileno y un plan de 90 días.

EDICIÓN AMPLIADA · OCTUBRE 2026

La unidad que debemos gobernar ya no es una aplicación: es una combinación de persona o agente, propósito, datos, permisos y destino. Aprobar un chatbot no autoriza automáticamente sus conectores, su memoria ni las acciones que puede ejecutar.

DescubrirUsos, cuentas y conexiones reales.
DelimitarDatos permitidos y capacidad de actuar.
DemostrarEvidencia de control y de revocación.

Revisión de fuentes: 26 de octubre de 2026. Esta edición amplía la publicación original de abril. Las cifras indican su año y población; los escenarios y el plan operativo son propuestas de aplicación, no resultados de una auditoría de TTPSEC.

1. Shadow AI: una brecha entre el trabajo real y el trabajo autorizado

Shadow AI es el uso de capacidades de inteligencia artificial fuera de la visibilidad, evaluación o autorización que requiere la organización. Incluye una cuenta personal, pero también una función nueva dentro de un SaaS aprobado, un modelo local no inventariado o un agente conectado a información corporativa con permisos que nadie revisó.

La palabra shadow describe una falta de gobierno; no demuestra intención maliciosa. Una persona puede intentar resolver una tarea legítima y, aun así, crear un tratamiento de datos o una delegación de autoridad que la empresa desconoce. Confundir ambas cosas dificulta que los usuarios declaren lo que ya utilizan.

Un servicio aprobado también puede convertirse en un uso no autorizado: resumir documentación pública y evaluar candidatos con antecedentes personales son actividades distintas, aunque ocurran en la misma interfaz. La autorización necesita un propósito, un alcance y condiciones de uso. Comprar licencias no resuelve esa definición.

En mayo de 2026, el Work Trend Index de Microsoft sitúa a los agentes y la reorganización del trabajo en el centro de la adopción. Es investigación de un proveedor, útil para entender prácticas y percepciones; no mide por sí sola la prevalencia mundial de Shadow AI. La consecuencia operativa que extraemos es revisar también quién delega tareas y hasta dónde llega esa delegación. [3]

2. Evidencia: distinguir años, países y denominadores

No conviene justificar una inversión repitiendo porcentajes sin su población. Estas fuentes muestran el problema desde ángulos diferentes; no forman una serie estadística comparable.

Datos publicados y límites de interpretación
FuenteHallazgoQué permite concluir
Microsoft / Censuswide, Reino Unido, octubre de 2025 [1]71% declaró haber usado herramientas de IA de consumo no aprobadas en el trabajo; 51% lo hacía semanalmente.Describe a los empleados encuestados en Reino Unido. No equivale a 71% de empresas chilenas ni a 71% de incidentes.
IBM / Ponemon, informe 2025 [2]En 600 organizaciones que sufrieron brechas entre marzo de 2024 y febrero de 2025, el uso elevado de Shadow AI se asoció con un costo medio de brecha USD 670.000 superior al de uso bajo o inexistente.Es una asociación en organizaciones afectadas. No prueba causalidad ni permite calcular automáticamente el costo esperado de una empresa particular.
IBM, resultados para India, agosto de 2026 [4]El informe identifica Shadow AI como uno de los factores que aumentan costos; reporta INR 17,9 millones adicionales en India cuando está presente.Es evidencia reciente y específica de ese país. No debe convertirse en una tarifa de riesgo para Chile ni compararse directamente con la cifra global de 2025.

La pregunta útil para el directorio es qué datos propios faltan: cuántos usos existen, cuáles tratan información restringida, quién puede revocar sus accesos y qué procesos dependen de ellos. Los estudios externos ayudan a priorizar una investigación; no sustituyen ese diagnóstico.

3. Dónde buscar: seis superficies distintas

  • IA de consumo y cuentas personales. Conversaciones, archivos, memoria y espacios compartidos que quedan fuera de la administración corporativa.
  • IA integrada en SaaS. Asistentes de reuniones, CRM, correo o diseño que añaden funciones después de aprobarse el contrato original.
  • Extensiones, IDE y herramientas de desarrollo. Acceso al repositorio, terminal, secretos de entorno, dependencias y publicación de aplicaciones.
  • Agentes, automatizaciones y conectores. Identidades no humanas que consultan, transforman, envían o modifican información.
  • Modelos locales y repositorios RAG. Pesos, índices vectoriales, documentos recuperados, copias de seguridad y cuentas del servidor.
  • IA utilizada por proveedores. Un tercero puede procesar datos recibidos para prestar un servicio mediante herramientas que el cliente no evaluó.

Un modelo local reduce ciertas transferencias a terceros, pero no elimina permisos excesivos, registros inseguros o decisiones incorrectas. Una suscripción empresarial puede ofrecer mejores controles, pero tampoco autoriza todos los casos de uso. La evaluación debe seguir el recorrido real de los datos y las acciones.

4. El salto de 2026: de compartir datos a delegar acciones

La fuga de un documento sigue siendo relevante. Con agentes aparece una segunda dimensión: una salida del modelo puede activar herramientas. Una respuesta incorrecta deja de ser solamente texto cuando cambia una cuenta, envía un archivo o altera un registro.

01 · EntradaCorreo, archivo o instrucción externa
02 · ContextoModelo, memoria y datos recuperados
03 · AutoridadIdentidad, permisos y herramientas
04 · EfectoLectura, envío o modificación
Modelo conceptual propuesto: comprobar los límites de confianza en cada paso. No representa un incidente medido.

OWASP distingue la agencia excesiva: herramientas con funciones innecesarias, privilegios demasiado amplios o autonomía sin verificación suficiente pueden convertir una salida inesperada en daño. Una inyección de instrucciones contenida en un documento es una posible causa; no es la única. [5]

Escenario ilustrativo: un asistente autorizado para resumir propuestas obtiene además permiso para enviar correo. Lee un documento externo que contiene instrucciones engañosas y prepara una salida a un destinatario ajeno. La defensa no debería depender exclusivamente de que el modelo detecte el engaño: el servicio puede negar el envío, limitar destinatarios o exigir que una persona revise el contenido y la dirección exacta.

Conviene separar cuatro afirmaciones que suelen confundirse: el proveedor no usa datos para entrenamiento; conserva datos durante cierto período; permite conexiones con otros servicios; y autoriza determinadas acciones. Una condición favorable en una de ellas no resuelve las otras. La revisión contractual y técnica debe registrar las cuatro por producto, plan y configuración.

5. Inventariar usos, no solamente marcas

El registro mínimo propuesto contiene: responsable de negocio, finalidad, herramienta y plan, cuenta o tenant, usuarios o agentes, clasificación de datos, repositorios conectados, permisos efectivos, proveedores y destinos, retención, decisión de aprobación, fecha de revisión y mecanismo de revocación.

La descripción «usamos IA para ventas» no permite evaluar nada. Una ficha operativa diría: «el equipo comercial resume contratos desde un repositorio concreto; el agente solo lee; el borrador se revisa antes de enviarse; las credenciales pertenecen a la empresa; el dueño del proceso revisa el acceso cada trimestre». Son condiciones propuestas que deben contrastarse con la configuración real.

Para descubrir usos, combine declaraciones de los equipos, catálogo de compras, consentimientos OAuth, aplicaciones empresariales, extensiones administradas, registros del proxy o pasarela y facturación de APIs. Compare señales: una visita a un dominio no demuestra envío de datos; la ausencia de tráfico observado no descarta uso desde un dispositivo o una red no gestionados.

El monitoreo también trata información. Defina propósito, proporcionalidad, acceso y retención; prefiera metadatos cuando basten. Guardar cada conversación de todos los empleados puede crear un repositorio sensible adicional sin resolver el problema original.

Semáforo operativo propuesto — adaptar al contexto y a las obligaciones aplicables
NivelEjemploCondición antes de usar
VerdeReescribir un texto público sin acceso a sistemas internos.Herramienta admitida, revisión humana y ausencia de datos restringidos.
ÁmbarConsultar documentación interna o redactar respuestas con datos de clientes.Evaluar datos y contrato, autenticar al usuario, limitar acceso y registrar la aprobación del caso.
RojoSecretos, credenciales, datos especialmente protegidos o acciones autónomas de alto impacto.Suspender el uso no evaluado y escalar. Una excepción requiere decisión expresa, controles verificables y límites definidos.

Este semáforo es una ayuda de triaje, no una clasificación jurídica del AI Act ni un cálculo cuantitativo del riesgo.

6. Controles con evidencia: del documento al funcionamiento

Aprobar una combinación concreta de herramienta, datos y finalidad

Publique un catálogo comprensible: qué se permite, con qué cuenta, para qué tareas y dónde solicitar una excepción. La alternativa aprobada necesita servir para el trabajo real. Si la evaluación demora, asigne un responsable y un plazo de respuesta; una prohibición sin vía operativa puede desplazar el uso fuera de la visibilidad.

Reevaluar cuando cambie el alcance

Un nuevo conector, una ampliación de permisos, otro tipo de dato o la habilitación de acciones autónomas deben disparar una revisión. La aprobación de ayer no cubre automáticamente la capacidad de hoy. Registre tanto el beneficio esperado como las consecuencias de una salida incorrecta y la posibilidad de recuperarse.

Controles técnicos y cómo probarlos

Matriz propuesta de controles y evidencia de aceptación
ControlPrueba útilLímite que debe conocerse
Identidad corporativa y mínimo privilegioUna cuenta de prueba no puede recuperar un documento al que no tiene acceso; revocar la concesión impide la siguiente operación.Autenticarse con SSO no implica que los permisos del conector sean mínimos.
Clasificación y prevención de fugaUn dato sintético marcado como restringido activa el control previsto y genera una alerta revisable.La detección puede fallar ante formatos, idiomas o canales no cubiertos.
Autorización de herramientas en el servidorUn intento de ejecutar una función no permitida recibe una denegación aunque el modelo lo solicite.Una instrucción en el prompt no sustituye una comprobación de acceso.
Revisión de acciones sensiblesLa persona ve destinatario, contenido y efecto antes de confirmar un envío o modificación.Un botón genérico de «aceptar todo» no demuestra una revisión informada.
Límites y paradaSe prueban cuotas, vencimiento de credenciales y suspensión de un agente sin interrumpir procesos ajenos.Revocar acceso no recupera automáticamente los datos ya transferidos.
Trazabilidad protegidaUna operación puede asociarse con responsable, versión, herramienta y decisión de autorización.Los logs deben minimizar secretos y contar con controles de acceso y retención.

Para integraciones MCP, revise la autenticación y la audiencia de los tokens, además de las funciones expuestas. La guía oficial prohíbe el token passthrough y explica los riesgos de aceptar o reenviar tokens que no fueron emitidos para el servicio correspondiente. Usar MCP no significa que un conector sea seguro por defecto. [6]

Capacitar sobre decisiones, no sobre eslóganes

La formación debería usar tareas del equipo: qué quitar de un archivo antes de compartirlo, cómo reconocer una instrucción externa, cuándo no confiar en una referencia generada, cómo revisar un permiso y cómo reportar un uso que necesita regularización. Evalúe la capacidad de aplicar esas decisiones, no solo la asistencia al curso.

7. ISO/IEC 42001, NIST y el contexto de octubre de 2026

ISO/IEC 42001:2023 establece requisitos para un sistema de gestión de IA. Ayuda a organizar responsabilidades y mejora continua; no equivale a una lista de herramientas aprobadas ni garantiza que cada integración carezca de vulnerabilidades. Su utilidad práctica depende de conectar las decisiones del sistema de gestión con inventarios y pruebas. [7]

NIST AI RMF y su perfil de IA generativa proporcionan una base para gobernar, contextualizar, medir y gestionar riesgos. Son instrumentos voluntarios que permiten estructurar el análisis; no sustituyen las obligaciones legales ni certifican el cumplimiento de una implementación. [8]

ISO/IEC 27090:2026 figura publicada en octubre de 2026 en el catálogo oficial de ISO. Se centra en amenazas y compromisos de seguridad de sistemas de IA. Complementa la conversación de gobierno: conviene evaluar tanto quién responde por el uso como qué puede fallar técnicamente durante su ciclo de vida. No debe presentarse como una certificación automática de seguridad del chatbot. [9]

Chile: al corte de esta edición, la Ley 21.719 tiene vigencia diferida al 1 de diciembre de 2026, según la Biblioteca del Congreso Nacional. Preparar el inventario de tratamientos y proveedores de IA es una tarea inmediata, sin presentar esa fecha futura como una obligación ya plenamente vigente ni olvidar el marco actualmente aplicable. La licitud y las condiciones de cada tratamiento requieren revisión específica. [10]

Unión Europea: la documentación vigente de la Comisión contempla medidas para desarrollar la alfabetización en IA de quienes operan sistemas, y sitúa la aplicación de determinadas reglas de transparencia en el 2 de agosto de 2026. Las obligaciones dependen del rol, sistema y ámbito territorial: no todo uso de IA en una empresa chilena queda automáticamente dentro del mismo régimen. Este artículo no reemplaza esa evaluación. [11]

8. Si ya se compartió información: contener sin destruir evidencia

  1. Detener la exposición activa. Suspender el flujo, desactivar el conector o revocar la concesión comprometida según el caso. Si hubo credenciales expuestas, rotarlas mediante el procedimiento correspondiente.
  2. Delimitar qué ocurrió. Identificar herramienta, cuenta, archivos, datos afectados, permisos, destinatarios y momento. Distinguir lo confirmado de lo inferido.
  3. Preservar evidencia proporcional. Retener identificadores de operaciones y registros necesarios con acceso limitado. No reenviar el documento sensible a otro asistente para investigarlo.
  4. Coordinar la respuesta. Involucrar al responsable de negocio, seguridad, privacidad y al proveedor. Evaluar obligaciones de notificación con el contexto jurídico real; no asumir que todo evento tiene el mismo plazo.
  5. Verificar la remediación. Comprobar revocación, borrado solicitado y alcance de retención. Documentar qué asegura el proveedor y qué permanece desconocido.
  6. Corregir el proceso. Revisar por qué se eligió esa herramienta, qué alternativa faltaba y qué control falló. Evitar cerrar el caso únicamente con una circular.

Una solicitud de eliminación no prueba por sí sola que los datos hayan desaparecido de todos los registros, respaldos o destinatarios. La respuesta debe describir su alcance, sus evidencias y las limitaciones que persisten.

9. Plan de 90 días para pasar de la declaración al control

La siguiente secuencia es una propuesta adaptable. No exige esperar tres meses para contener un riesgo grave ni promete una certificación al finalizar.

Hoja de ruta propuesta
PeríodoTrabajo prioritarioSalida verificable
Días 1–15Nombrar responsables, habilitar declaración de usos, identificar conexiones y contener exposiciones críticas.Inventario inicial, canal de consulta y lista priorizada de riesgos con dueño.
Días 16–30Clasificar usos, revisar datos y contratos, definir alternativas aprobadas y excepciones temporales.Catálogo por finalidad y datos; decisiones documentadas con vencimiento.
Días 31–60Aplicar permisos, detección y controles de acción; probar flujos representativos con datos sintéticos.Evidencias de denegación, alertas, aprobación humana y revocación.
Días 61–90Ejecutar un ejercicio de incidente, revisar métricas, ajustar formación y extender el control a proveedores.Informe de brechas pendientes, acciones con fecha y aceptación explícita del riesgo residual.

10. Qué medir y quién responde

Un tablero de gestión debe evitar la ilusión de precisión. «Porcentaje de Shadow AI eliminado» no es defendible si se desconoce el universo. Es mejor medir cobertura sobre el universo descubierto y explicitar los puntos ciegos.

  • Usos con responsable y decisión vigente / usos descubiertos. Acompañar el porcentaje con el número absoluto y el alcance observado.
  • Conectores privilegiados revisados / conectores privilegiados identificados. Separar lectura de escritura y envío.
  • Tiempo mediano y percentil 90 de evaluación. Ver si el proceso facilita una alternativa antes de que el equipo la busque por su cuenta.
  • Pruebas de revocación exitosas / pruebas ejecutadas. Registrar además el tiempo hasta que el acceso deja de funcionar.
  • Excepciones vencidas, fallos de control y reincidencias. Asignar responsable y plazo, en lugar de ocultarlos en un promedio.
  • Beneficio observado del uso autorizado. Comparar calidad, retrabajo y tiempo sobre una tarea definida; no convertir una estimación del usuario en ahorro financiero comprobado.

El dueño del proceso responde por la finalidad y el resultado; TI por la configuración y el ciclo de vida; seguridad por los escenarios y controles; privacidad y asesoría jurídica por las condiciones aplicables; y la dirección por las decisiones de riesgo que exceden el mandato operativo. Una organización pequeña puede combinar funciones, pero debe dejar clara la responsabilidad de cada decisión.

11. La prueba real de gobierno

Una política útil se reconoce cuando alguien puede descubrir una herramienta, declarar su necesidad y obtener una respuesta viable; cuando el acceso aprobado coincide con el necesario; y cuando se puede demostrar qué ocurrió si el sistema falla. La prohibición puede ser necesaria para determinados usos, pero necesita alcance, alternativas y revisión.

La gobernanza de Shadow AI se vuelve operativa cuando permite responder con evidencia a cinco preguntas: quién la usa, para qué, con qué datos, qué puede hacer y cómo se detiene. Si la respuesta depende de preguntarle informalmente a una sola persona, el proceso todavía es frágil.

Preguntas para la próxima reunión de dirección

  • ¿Qué usos críticos dependen de una cuenta o credencial personal?
  • ¿Qué función nueva de IA apareció dentro de un proveedor ya contratado?
  • ¿Podemos revocar hoy un conector y demostrar que dejó de operar?
  • ¿Qué acciones requieren revisión humana, y qué ve exactamente quien aprueba?
  • ¿Qué alternativa útil ofrecemos a quien declara una necesidad no cubierta?

Fuentes primarias y alcance de esta revisión

Fuentes consultadas el 26 de octubre de 2026. Las recomendaciones operativas, matrices y escenarios de este artículo son una síntesis editorial; no se presentan como requisitos textuales de una norma ni como investigación empírica propia.

  1. Microsoft (13 octubre 2025). Rise in ‘Shadow AI’ tools raising security concerns for UK organisations. Encuesta encargada a Censuswide.
  2. IBM (30 julio 2025). Cost of a Data Breach Report 2025: resultados de seguridad y gobierno de IA.
  3. Microsoft (5 mayo 2026). Work Trend Index 2026: Agents, human agency, and the opportunity for every organization.
  4. IBM India (3 agosto 2026). Cost of a Data Breach Report 2026: resultados para India. El estudio global incluye 602 organizaciones con brechas entre marzo de 2025 y febrero de 2026.
  5. OWASP. LLM06:2025 — Excessive Agency.
  6. Model Context Protocol. Security Best Practices, edición de especificación 2025-11-25.
  7. ISO. ISO/IEC 42001:2023 — Artificial intelligence management system.
  8. NIST. AI Risk Management Framework y Generative Artificial Intelligence Profile (NIST AI 600-1).
  9. ISO. ISO/IEC 27090:2026 — Addressing security threats and compromises to AI systems. Catálogo oficial, edición 2026-10.
  10. Biblioteca del Congreso Nacional de Chile. Ley 21.719, texto con vigencia diferida al 1 diciembre 2026.
  11. Comisión Europea, AI Act Service Desk. Recursos oficiales de alfabetización y transparencia en IA, actualizaciones de julio y octubre de 2026.

Publicado originalmente en el blog CISO de TTPSEC en abril de 2026. Edición ampliada y revisada el 26 de octubre de 2026; se conserva la fecha original de publicación.