Shadow IT: cómo mapear las apps que ya construyó su empresa

Cuatro áreas, cuatro aplicaciones, y ninguna pasó por sistemas. No es un caso aislado: es lo que pasa cuando pedirle algo al área de sistemas tarda meses y hacerlo con una herramienta de inteligencia artificial tarda una tarde. El caso que originó esta guía lo resume así, y no es una excepción entre las empresas que atendemos.

No es rebeldía ni indisciplina. Es una consecuencia directa de que cualquier persona con acceso a una herramienta de IA puede armar hoy lo que antes había que encargar. El costo de esa velocidad aparece después, cuando esa aplicación ya tiene datos de la empresa adentro y una sola persona sabe cómo funciona.

Qué es shadow IT y por qué aparece primero en pymes con áreas ágiles

Shadow IT es toda aplicación, automatización o flujo de trabajo que una empresa usa sin que el área de sistemas lo sepa, lo apruebe o lo administre. El término no es nuevo: existía antes de la IA generativa, con planillas de Excel con macros, formularios externos o cuentas de software contratadas directamente por un área sin pasar por compras ni por sistemas.

Lo que cambió es la velocidad y el alcance. Antes, construir una herramienta propia requería saber programar o contratar a alguien que supiera. Hoy, con una herramienta de inteligencia artificial, cualquier persona sin formación técnica puede describir lo que necesita en lenguaje natural y obtener una aplicación funcional en horas.

Esto aparece primero en empresas medianas con áreas ágiles: equipos de ventas, marketing, finanzas u operaciones que sienten el costo de esperar semanas o meses a que sistemas atienda su pedido. Cuando la alternativa de hacerlo solo tarda una tarde, la decisión racional de un gerente de área es resolverlo él mismo, aunque eso implique que la aplicación termine viviendo fuera del radar de sistemas.

El problema no es la iniciativa. El problema es que esa aplicación, construida rápido y por necesidad, casi nunca queda documentada, casi nunca pasa por una revisión de seguridad y casi siempre depende de una sola persona para seguir funcionando.

El riesgo de conocimiento concentrado en una sola persona

La mayoría de las aplicaciones de shadow IT comparten un mismo defecto de diseño: las construyó una persona, para resolver un problema puntual de su área, sin pensar en qué pasa si esa persona deja de estar disponible.

Esto crea lo que en gestión de riesgo se conoce como un punto único de falla concentrado en una persona. Mientras esa persona siga en la empresa, la aplicación funciona, se actualiza cuando hace falta y nadie nota el riesgo. El problema se manifiesta el día que esa persona renuncia, cambia de área o simplemente se toma una licencia larga: la aplicación sigue corriendo, pero nadie sabe cómo modificarla, a qué otros sistemas está conectada ni qué hacer si falla.

El riesgo se agrava cuando esa aplicación ya toca datos sensibles: información de clientes, cifras financieras, datos de empleados. Una herramienta que nació como una solución rápida para ahorrar tiempo puede convertirse, sin que nadie lo haya decidido así, en el lugar donde vive información crítica de la empresa sin ningún control formal sobre quién accede a ella ni cómo se respalda.

Es la misma lógica de dependencia que describimos en Automatizar si nadie lo construye: cuando la capacidad de sostener algo depende de una sola persona en vez de un proceso documentado, la empresa no tiene una solución, tiene una promesa frágil.

Cómo relevar las apps y los datos que ya están corriendo antes de prohibir

El primer paso no es prohibir el uso de herramientas de IA ni bloquear el acceso a ellas. El primer paso es saber qué hay: qué aplicaciones se están usando, quién las hizo, qué datos tocan y qué pasa si mañana esa persona no está disponible.

Este relevamiento sigue el mismo método que usamos para entender cualquier proceso antes de automatizarlo, lo que llamamos Process Discovery: en vez de partir del organigrama o del manual de políticas de IT, se parte de cómo el equipo trabaja en la práctica hoy. Eso significa conversar con cada área, preguntar qué herramientas usan para resolver su trabajo diario y documentar, sin juzgar, lo que aparezca.

En la práctica, ese relevamiento responde cuatro preguntas concretas por cada aplicación que se encuentra: qué problema resuelve, quién la construyó y la mantiene, qué datos de la empresa lee o almacena, y qué pasa con la operación del área si esa aplicación deja de funcionar mañana. Con esas cuatro respuestas, una empresa puede priorizar: qué aplicaciones son de bajo riesgo y pueden seguir como están, cuáles necesitan pasar a un entorno controlado por sistemas, y cuáles conviene reemplazar por una solución con dueño claro y respaldo real.

El detalle metodológico completo de cómo se ejecuta un relevamiento de este tipo está en Process Discovery: entender el proceso antes de automatizarlo, donde se explica cómo aplicar el mismo enfoque a cualquier proceso de la operación, no solo a shadow IT.

La diferencia entre gobernar shadow IT y frenar la iniciativa de los equipos

Gobernar shadow IT no es lo mismo que eliminarlo. Un equipo de ventas que armó su propio asistente para calificar leads, o un área de finanzas que automatizó la carga de gastos con una herramienta de IA, resolvió un problema real que sistemas no había atendido a tiempo. Cortar esa herramienta sin ofrecer una alternativa equivalente no resuelve el riesgo: solo devuelve a esa área al problema original, con menos confianza en que pedirle algo a sistemas sirva de algo.

Gobernar significa poner reglas mínimas sobre lo que ya existe: qué datos puede tocar una aplicación construida por un área, dónde se guarda esa información, quién más además del creador original entiende cómo funciona, y qué pasa si necesita escalar o integrarse con otro sistema. No implica migrar todo a una plataforma centralizada de un día para el otro, ni exige que cada área deje de resolver sus propios problemas con IA.

La diferencia práctica es esta: sin gobernanza, cada aplicación de shadow IT es una apuesta individual que depende de que a nadie se le ocurra irse, cambiar de rol o cometer un error con los datos que maneja. Con gobernanza mínima, esa misma aplicación sigue existiendo, pero la empresa sabe que existe, sabe qué toca y tiene un plan si algo falla.

El rol de Process Discovery como primer paso de gobernanza de IA

Process Discovery nació como el paso previo a cualquier proyecto de automatización: entender el proceso real antes de tocar tecnología. La misma lógica aplica, casi sin cambios, al problema de shadow IT: antes de decidir qué automatizar con gobierno, con presupuesto y con un dueño formal dentro de sistemas, hay que saber qué automatización ya existe, aunque nadie la haya autorizado.

Tratar el mapeo del shadow IT como un ejercicio de Process Discovery, en vez de como una auditoría de cumplimiento, cambia el resultado. Un auditor busca a quién sancionar. Un relevamiento de procesos busca entender por qué cada área resolvió su problema de la forma en que lo hizo, y qué necesitaría esa área para seguir resolviendo problemas así, pero con datos protegidos y con continuidad garantizada más allá de una sola persona.

Una vez completado ese mapeo, el trabajo que sigue es el mismo que aplicamos después de cualquier Process Discovery: priorizar qué automatizar primero con un enfoque formal. Ese criterio de priorización está desarrollado en cómo elegir el primer caso de uso de IA en su empresa.

Si en su empresa sospecha que ya existen aplicaciones como estas, y quiere saber qué hay antes de decidir qué hacer con ellas, puede escribir la palabra MAPA en los comentarios del anuncio original o contactarnos directamente: relevamos, sin costo inicial, lo que ya está corriendo en su operación antes de recomendar cualquier cambio.