La señal más confiable no es una alerta de TI, es el silencio: casi ninguna app hecha con IA aparece en soporte oficial. En Progresus, de más de 4.600 tickets entre 2020 y 2026, solo 15 mencionan IA, Breeze o Copilot: su uso no pasa por los canales donde se detectaría un problema.
Shadow IT es cualquier herramienta que alguien del equipo construye o adopta sin pasar por TI ni por un proceso formal de aprobación. Con IA, construir esa herramienta se volvió mucho más fácil, así que el fenómeno crece más rápido de lo que crecen los controles.
Antes, montar una herramienta interna requería saber programar o pedirle tiempo a alguien que sí sabía. Hoy, describir en lenguaje natural lo que se necesita puede bastar para tener una primera versión funcionando en una tarde. Esa facilidad es la razón por la que este fenómeno merece atención nueva, aunque el problema de fondo no sea nuevo.
Lo que cambia no es la intención de quien construye. Es la velocidad con la que un experimento personal se convierte en una herramienta que otras tres personas del equipo ya están usando para algo importante.
Un ticket de soporte se abre cuando algo falla de forma visible: un sistema se cae, un reporte no carga, un flujo se detiene. Una app hecha con IA para resolver un problema puntual rara vez falla así, al menos al principio. Simplemente funciona, y funciona en silencio.
En Progresus, de más de 4.600 tickets de soporte entre 2020 y 2026, solo 15 mencionan IA, Breeze o Copilot. Esto explica por qué el dato es tan bajo. No es que la IA no se use, es que su uso no genera el tipo de fricción que normalmente termina en un ticket. La ausencia de reportes no es evidencia de que no exista el problema, es evidencia de que el canal habitual no lo está capturando.
En Progresus, de más de 4.600 tickets de soporte entre 2020 y 2026, solo 15 mencionan IA, Breeze o Copilot.
Hay una segunda razón, más incómoda. Muchas veces la persona que construyó la herramienta sabe que no pasó por ningún proceso formal, y no tiene incentivo para reportarlo. Reportarlo podría significar que le pidan documentarlo, justificarlo, o dejar de usarlo. El silencio, en ese caso, es una elección, no un accidente.
Como los canales directos no funcionan, hay que buscar señales indirectas. La primera es un proceso que se volvió notablemente más rápido sin que nadie haya pedido presupuesto para una herramienta nueva. Si algo que tomaba un día ahora toma una hora, y nadie sabe explicar del todo por qué, vale la pena preguntar.
La segunda señal es una persona que se volvió el punto de contacto que resuelve algo puntual, con un método que nadie más en el equipo entiende del todo. Esto se parece al riesgo de depender de una sola persona en un proceso manual, solo que ahora esa dependencia está encapsulada en una herramienta que tampoco está documentada.
La tercera señal, más sutil, es un archivo o una integración que aparece mencionada en una reunión de forma casual, como si todos ya la conocieran, cuando en realidad nadie del área de tecnología sabe que existe.
El riesgo principal no es que la herramienta funcione mal. Muchas funcionan bien, al menos para el caso que resolvieron originalmente. El riesgo real es de visibilidad: nadie revisó qué datos toca esa app, quién tiene acceso a ella, ni qué pasa si la persona que la construyó deja el equipo.
Una herramienta construida rápido para resolver un problema puntual rara vez se diseñó pensando en seguridad de datos, en control de acceso, o en qué pasa si crece más allá de su propósito original. Eso no la hace automáticamente peligrosa, pero sí la hace una incógnita que nadie decidió aceptar de forma consciente.
El riesgo se agrava cuando esa app toca información sensible sin que nadie lo haya evaluado antes de que empezara a usarse. Para eso vale la pena revisar qué preguntas hacerse antes de darle acceso a datos reales a cualquier herramienta de este tipo, sea nueva o ya en uso.
Lo primero no es apagarla. Antes de tomar esa decisión, entiende qué proceso resuelve y para quién. Si varias personas dependen de ella para su trabajo diario, apagarla sin un reemplazo genera un problema nuevo, distinto pero igual de real que el que ya existía.
El segundo paso es evaluar qué datos toca y con qué nivel de exposición. Una herramienta que solo organiza tareas internas no representa el mismo riesgo que una que procesa información de clientes. Esa evaluación decide si la herramienta se integra formalmente, se ajusta, o se reemplaza por algo con el control que le faltaba.
El paso final, y el que suele evitar que esto vuelva a pasar, es preguntarse por qué esa persona construyó la herramienta en vez de pedirla. Casi siempre la respuesta es que el camino oficial era más lento que hacerlo por su cuenta. La mayoría de shadow IT no nace de mala intención, nace de que el camino oficial era más lento que construir algo por su cuenta. Dar a los equipos un canal rápido y oficial para pedir una herramienta nueva reduce la razón de fondo que hace que esto siga pasando.
La mayoría de shadow IT no nace de mala intención, nace de que el camino oficial era más lento que construir algo por su cuenta.
Busca señales indirectas: una hoja de cálculo que de repente automatiza algo que antes era manual, un proceso que se volvió más rápido sin que nadie pidiera presupuesto para una herramienta nueva, o una persona que resuelve algo puntual con un flujo que nadie más entiende.
¿Qué riesgos trae que cualquiera construya una app con IA?
El riesgo principal no es técnico, es de visibilidad. Nadie revisó qué datos toca esa app, quién tiene acceso a ella, ni qué pasa si la persona que la construyó se va.
¿Por qué esto no aparece en los tickets de soporte?
Porque una app hecha con IA suele resolver un problema puntual sin pasar por TI. Solo se abre un ticket cuando algo falla de forma visible, y estas apps rara vez fallan de forma visible antes de convertirse en un problema mayor.
¿Cuántas apps hechas con IA existen normalmente sin que nadie lo sepa?
No hay una cifra universal, pero el patrón de Progresus es una referencia útil: de más de 4.600 tickets de soporte en seis años, solo 15 mencionan IA, Breeze o Copilot. Eso sugiere que el uso real de IA suele estar muy por delante de lo que los canales oficiales registran.
¿Qué hago si encuentro una de estas apps en mi empresa?
No la apagues de inmediato. Primero entiende qué proceso resuelve y para quién, porque probablemente existe porque algo oficial no cubría esa necesidad. Luego evalúa qué datos toca antes de decidir si se integra formalmente o se reemplaza.
¿Cómo evito que esto vuelva a pasar?
Dando a los equipos un canal rápido y oficial para pedir una herramienta nueva. La mayoría de shadow IT no nace de mala intención, nace de que el camino oficial era más lento que construir algo por su cuenta.
Si ya confirmaste que existe una de estas apps, antes de darle acceso a datos reales, empieza por saber qué revisar antes de darle datos reales a una app hecha con IA. También puedes revisar señales de que tu equipo construyó apps con ia sin control, dentro de la guía completa que Progresus Apps armó sobre qué hacer cuando ya construyeron apps con IA sin método.