Cuando los departamentos de negocio crean aplicaciones con IA sin pasar por TI
La IA ha cambiado la forma en que surge el shadow IT. Antes, un departamento compraba un SaaS sin informar a TI. Hoy, pueden construir una pequeña aplicación, un flujo de trabajo, un panel de control o una herramienta interna en pocos días, conectarla a hojas de cálculo, CRM, correos electrónicos, tickets, documentos o bases de datos, y empezar a usarla como si fuera un sistema corporativo oficial.
El problema no es que el negocio quiera resolver sus propios problemas: es que una solución útil puede volverse invisible. Sin inventario, sin propietario técnico, accesos no gobernados, datos cargados fuera del perímetro, claves API personales, enlaces públicos, ausencia de retención y sin plan de contingencia si algo falla.
Para CIOs, CISOs, gerentes de TI y responsables de negocio, la pregunta concreta es: ¿qué aplicaciones creadas con IA existen ya, qué datos manejan y cuáles deben regularizarse antes de que se vuelvan críticas?
Por qué la IA acelera la proliferación del shadow IT
Los constructores de aplicaciones de IA y las herramientas de “vibe coding” reducen significativamente el umbral técnico. Un equipo de marketing puede crear una herramienta para segmentar clientes potenciales, Finanzas puede automatizar conciliaciones, RR.HH. puede construir un formulario con flujo de aprobación y Operaciones puede conectar hojas de cálculo, correos y tickets en pocos días. Muchas de estas iniciativas nacen por motivos legítimos: backlog de TI extenso, urgencia operativa, presupuesto limitado, necesidad de prototipar rápidamente.
El punto crítico es que, en cuanto la aplicación maneja datos reales, usuarios, integraciones o decisiones operativas, ya no es solo un experimento. A diferencia del shadow IT tradicional, la aplicación está hecha a medida y no comprada como un producto terminado: esto la hace más difícil de censar y hace que sea aún más importante entender cómo está construida (código, configuraciones, almacenamiento, flujos de trabajo, API, credenciales, dominios, registros y datos incluidos).
El primer control: ¿existe la aplicación en el inventario?
El primer paso es saber que la aplicación existe. Si TI no la ve, no puede aplicar SSO, copias de seguridad, registro de eventos (logging), gestión de vulnerabilidades, políticas de datos, respuesta a incidentes o baja del servicio. Un inventario útil debe incluir al menos estos elementos:
- Nombre de la aplicación y departamento propietario
- Propósito operativo
- Herramienta utilizada para crearla
- Usuarios internos o externos
- Datos tratados
- Integraciones y API
- URL, dominios, vistas previas y entornos
- Credenciales y cuentas utilizadas
- Criticidad para el proceso empresarial
No hace falta empezar con un censo perfecto. Se necesita un proceso repetible: encuestas a los departamentos, descubrimiento de dominios y SaaS, revisión de aplicaciones OAuth, control de repositorios, análisis de costes en la nube y un canal sencillo para declarar las aplicaciones existentes sin el temor a un bloqueo inmediato.
Clasificar los datos y evaluar el impacto
No todas las aplicaciones de shadow IT presentan el mismo nivel de riesgo. Una herramienta que reformatea textos públicos es muy diferente a un panel de control con datos de clientes, facturas, tickets, datos de RR.HH. o información sanitaria. La clasificación debe responder a unas pocas preguntas esenciales:
- ¿Trata datos personales o datos de clientes?
- ¿Contiene datos confidenciales, comerciales, financieros, de RR.HH. o contractuales?
- ¿Lee o escribe en sistemas corporativos?
- ¿Envía datos a proveedores externos o modelos de IA?
- ¿Produce decisiones operativas o solo informes?
- ¿Es utilizada por varias personas, departamentos o sujetos externos?
- ¿Qué sucede si se detiene, pierde datos o expone información?
Las respuestas determinan el camino a seguir: tolerar con controles mínimos, regularizar, probar, migrar a una plataforma aprobada o dar de baja.
Accesos: enlaces compartidos, cuentas personales y falta de roles
Muchas aplicaciones nacidas en los departamentos de negocio comienzan con accesos simples: enlace compartido, contraseña común, cuenta personal, lista de correo manual, permisos de “editor” para todos. Mientras el uso es restringido parece funcionar, pero cuando entra un nuevo equipo, un consultor o un usuario externo, el modelo falla. Los controles mínimos que se deben aplicar son:
- Cuentas nominativas
- SSO y MFA donde sea posible
- Eliminación de cuentas compartidas
- Revocación de accesos cuando una persona cambia de rol o deja la empresa
- Roles coherentes con lectura, modificación, exportación y administración
- Registros (logs) de accesos y acciones críticas
Para las aplicaciones con datos de clientes o multi-departamento, es útil probar también el acceso directo: ¿puede un usuario cambiar el ID, URL, filtro, espacio de trabajo o parámetro y ver datos que no le pertenecen?
Integraciones y claves API: el riesgo oculto
Para ser útil, una aplicación de shadow IT a menudo se conecta a algo: Google Workspace, Microsoft 365, CRM, ticketing, correo electrónico, almacenamiento, ERP, bases de datos, Slack, webhooks o servicios de pago. La conexión se realiza típicamente con tokens personales, claves API copiadas, aplicaciones OAuth no aprobadas o cuentas de servicio con permisos excesivos. Este es uno de los puntos más críticos: una aplicación pequeña puede tener acceso amplio a datos corporativos y, si se ve comprometida, el daño no queda confinado a la aplicación en sí.
Los controles prácticos a aplicar incluyen:
- Inventario de tokens, aplicaciones OAuth, cuentas de servicio y webhooks
- Alcances (scopes) mínimos para cada integración
- Credenciales corporativas, no personales
- Rotación periódica de claves
- Segregación por entorno
- Registros de auditoría en las llamadas más sensibles
- Revocación de integraciones que ya no se utilizan
Exposición pública, vistas previas y dominios temporales
Los constructores de aplicaciones facilitan la publicación de una vista previa o un dominio temporal. El departamento de negocio puede compartirlo con colegas, socios o clientes sin percibirlo como una exposición en Internet. Los elementos a controlar son:
- URL públicas y vistas previas aún activas
- Dominios personalizados y subdominios temporales
- Indexación por parte de los motores de búsqueda
- Webhooks alcanzables sin autenticación
- Endpoints de administración o depuración
- Almacenamiento público
- CORS y devoluciones de llamada (callbacks) demasiado amplias
Cuando la aplicación es accesible en línea y gestiona inicios de sesión, API, datos reales o roles, el inventario no es suficiente: se necesita una prueba técnica. En estos casos, el Web Application Penetration Testing verifica el comportamiento real de la aplicación, no solo la configuración declarada.
Registros, exportaciones, retención y eliminación
Las aplicaciones creadas por el negocio a menudo giran en torno a exportaciones y hojas de cálculo: CSV del CRM, informes financieros, listas de clientes, tickets, archivos adjuntos, archivos cargados. El riesgo no es solo el acceso abusivo, sino la acumulación no gobernada de datos sensibles. Es necesario saber dónde se guardan los registros y resultados, quién puede exportar datos, cuánto tiempo permanecen los archivos y transcripciones, si existen copias de seguridad, cómo se elimina un dato y qué sucede cuando el proyecto se abandona.
Una aplicación que ya no se usa pero que sigue conectada a datos corporativos es un riesgo silencioso: sigue teniendo credenciales, enlaces y almacenamiento activos, pero ya no recibe atención operativa.
Regularizar sin bloquear el valor
Si TI llega solo para prohibir, el shadow IT se esconde. Un camino eficaz debe clasificar y regularizar, produciendo una decisión clara para cada aplicación: mantener, corregir, migrar, probar o apagar. No basta con “arreglarlo tarde o temprano”.
| Clase | Ejemplo | Acción |
|---|---|---|
| Bajo riesgo | Herramienta sin datos reales, uso individual | Registrar propietario y fecha de caducidad |
| Medio riesgo | Panel interno con datos no críticos | SSO, accesos, retención, copias de seguridad |
| Alto riesgo | App con datos de clientes, API o flujo operativo | Evaluación de riesgos, revisión técnica, pruebas |
| Crítico | App pública, multiusuario, datos sensibles | WAPT/VA, remediación antes del uso extensivo |
| Inaceptable | Credenciales compartidas, datos prohibidos, proveedor no aprobado | Baja o migración |
Lista de verificación para aplicaciones shadow IT creadas con IA
- ¿Está la aplicación censada en un inventario de TI/seguridad?
- ¿Existe un propietario de negocio y un propietario técnico?
- ¿Qué datos trata y de qué sistemas provienen?
- ¿Utiliza datos personales, de clientes, RR.HH., financieros o contractuales?
- ¿Es accesible desde Internet, por socios o solo desde la red interna?
- ¿Utiliza SSO/MFA o cuentas compartidas?
- ¿Qué claves API, aplicaciones OAuth, webhooks o integraciones utiliza?
- ¿Qué roles existen y quién puede exportar datos?
- ¿Dónde terminan los registros, archivos, exportaciones, copias de seguridad y transcripciones?
- ¿Existen vistas previas, dominios temporales o versiones antiguas aún activas?
- ¿Se ha realizado al menos una prueba de acceso con diferentes usuarios?
- ¿Está claro qué hacer si la aplicación se ve comprometida o debe darse de baja?
Cuándo involucrar a ISGroup
El punto de partida puede ser una evaluación ligera: inventario, datos, exposición, propietario, integraciones y riesgo. El control posterior depende de lo que surja.
| Escenario | Riesgo principal | Control recomendado |
|---|---|---|
| Muchas apps no censadas creadas por departamentos | Gobernanza débil y falta de propiedad | Virtual CISO |
| Necesidad de clasificar datos, impactos y prioridades | Riesgo no comprendido o no priorizado | Risk Assessment |
| Apps, hosts, dominios, vistas previas o servicios expuestos | Vulnerabilidades conocidas y configuraciones abiertas | Vulnerability Assessment |
| Web app o API con login, datos, roles o usuarios reales | Abuso de la aplicación desde el exterior | Web Application Penetration Testing |
La elección no es “hacer seguridad sobre todo”. Es decidir qué aplicaciones son tolerables, cuáles deben regularizarse, cuáles requieren una prueba técnica y cuáles deben apagarse, antes de que se conviertan en un problema operativo o normativo.
Evidencias útiles para una verificación
Para iniciar una verificación estructurada es útil recopilar: lista de aplicaciones, propietarios, URL, herramienta utilizada para crearlas, datos tratados, usuarios, roles, integraciones, claves API, aplicaciones OAuth, proveedores involucrados, registros, exportaciones, copias de seguridad, dominios, vistas previas, entornos y criticidad del proceso. También son útiles ejemplos concretos como capturas de pantalla, exportaciones, flujos de trabajo, esquema de datos, configuración de accesos, lista de conectores, lista de usuarios y descripción de qué sucede si la aplicación no está disponible.
Preguntas frecuentes
- ¿El shadow IT generado por la IA debe bloquearse siempre?
- No. Debe descubrirse y clasificarse. Algunas aplicaciones pueden permanecer operativas con controles mínimos, otras deben regularizarse, probarse, migrarse o darse de baja según el riesgo que presenten.
- ¿Cuál es el primer control que se debe hacer?
- El inventario. Sin saber qué aplicaciones existen, qué datos tratan y quién las usa, cualquier control técnico llega tarde y sin contexto.
- ¿Cuándo se necesita un Web Application Penetration Test?
- Cuando la aplicación es accesible en línea, expone API, gestiona inicios de sesión, datos reales, roles, cargas de archivos, pagos o flujos de trabajo utilizados por varios usuarios.
- ¿Cuándo es suficiente un Risk Assessment?
- Cuando el problema principal es decidir prioridades, propietarios, datos tratados, impacto en el negocio y camino de regularización antes de iniciar pruebas técnicas.
- ¿Quién debe ser responsable de la aplicación?
- Se necesita al menos un propietario de negocio para el proceso y los datos, y un propietario de TI/seguridad para accesos, controles, integraciones y camino de regularización.
[Callforaction-RA-Footer]