Todas las organizaciones saben que tienen TI en la sombra. La cifra que ilustra el problema es que la mayoría de las organizaciones ejecutan más de 1,000 aplicaciones en la nube, y el departamento de TI suele tener visibilidad de menos del 10 % de ellas. Las grandes empresas utilizan una media de 473 aplicaciones SaaS; el departamento de TI gestiona directamente solo una fracción. El 80 % de los empleados utiliza aplicaciones no autorizadas para realizar su trabajo. Estas cifras se repiten en todos los estudios porque la dinámica que reflejan es siempre la misma: los empleados y las unidades de negocio adoptan herramientas que resuelven problemas inmediatos con mayor rapidez de la que los procesos de gobernanza de TI pueden evaluarlas y aprobarlas.
El debate sobre la TI en la sombra en 2026 está dominado por las herramientas de descubrimiento de SaaS que analizan los registros DNS, los tokens OAuth de SSO, auditan los informes de gastos y detectan el tráfico de red para encontrar aplicaciones en la nube que los empleados utilizan sin autorización. Estas herramientas resuelven la capa SaaS del problema, y lo hacen razonablemente bien. Lo que no resuelven, y que ninguna herramienta de descubrimiento de SaaS aborda, es el otro problema de la TI en la sombra: las aplicaciones personalizadas, los programas por lotes no documentados, las canalizaciones de datos informales y los programas de utilidad fantasma que existen en las carteras de aplicaciones empresariales y que nunca han aparecido en ningún sistema de gestión de activos, registro de cambios o inventario de TI. Estas no son aplicaciones en la nube implementadas por los empleados. Son programas de producción, que se ejecutan en mainframes y sistemas de gama media, y que realizan funciones críticas para el negocio que las organizaciones propietarias no pueden controlar completamente.
Los dos problemas requieren enfoques de detección diferentes. El problema de la TI en la sombra en SaaS requiere visibilidad de la red e integración de identidades. El problema de la TI en la sombra a nivel de código requiere analizar los artefactos de software reales, el código fuente, las bibliotecas de carga y los flujos de trabajos JCL para enumerar qué programas existen y qué hacen. Esta guía abarca ambos, con especial atención a la segunda categoría, que no ha sido abordada por otros autores.
Los dos problemas informáticos en la sombra
Generalmente, la TI en la sombra se define como la tecnología utilizada dentro de una organización sin la aprobación o el conocimiento explícito del departamento de TI. Esta definición abarca dos fenómenos fundamentalmente diferentes que requieren enfoques de detección y respuestas de gobernanza distintos.
Las herramientas SaaS y en la nube no autorizadas son aplicaciones y servicios adoptados por empleados o unidades de negocio sin una contratación formal de TI. Por ejemplo, un equipo de marketing que utiliza una herramienta de escritura con IA no aprobada, un equipo de finanzas que comparte hojas de cálculo a través de una cuenta personal de Dropbox o un desarrollador que utiliza un asistente de codificación con IA no autorizado que envía código fuente propietario a una API externa. Estas aplicaciones existen fuera de la infraestructura de la organización y se pueden detectar mediante señales externas: consultas DNS, autorizaciones OAuth, partidas de informes de gastos y huellas digitales del tráfico de red.
El software de aplicación en la sombra , categoría en la que se centra específicamente este artículo, son programas personalizados y procesos por lotes creados dentro de la propia infraestructura de la organización y que nunca fueron debidamente documentados, inventariados ni gestionados. Un programa COBOL escrito por un desarrollador del departamento de finanzas en 1994 para gestionar un caso límite específico de cálculo de impuestos. Un programa RPG creado por un analista de negocios para generar archivos EDI para un socio comercial específico. Un trabajo JCL que se ejecuta a fin de mes y produce un informe regulatorio del que depende el equipo de cumplimiento, creado por un contratista que dejó la organización en 2009. Una utilidad Java escrita "temporalmente" durante un proyecto de integración de sistemas en 2018 que se convirtió en una dependencia permanente sin que nadie lo decidiera.
Estos programas no aparecen en los registros DNS porque se ejecutan en infraestructura interna. Tampoco figuran en los registros de autorización OAuth porque son anteriores a OAuth. No están incluidos en el inventario oficial de aplicaciones porque nunca se sometieron formalmente a la revisión de gobernanza de TI. Solo se pueden detectar examinando la propia infraestructura, las bibliotecas de carga, los repositorios de código fuente, los planificadores de tareas y los registros de ejecución que revelan qué software se ejecuta realmente en el entorno.
La razón por la que esto importa va más allá de la integridad del inventario: el 74 % de las organizaciones han sufrido incidentes de seguridad debido a activos desconocidos o no gestionados. El software de aplicaciones ocultas representa la categoría de activos desconocidos que ni las herramientas de detección basadas en la red ni las plataformas de visibilidad SaaS pueden encontrar.
¿Por qué se acumula el software de aplicaciones en la sombra?
Comprender por qué proliferan las aplicaciones personalizadas no documentadas en los entornos empresariales explica por qué los procesos de gobernanza estándar no logran prevenirlo y por qué es necesario el descubrimiento retrospectivo.
La necesidad de una solución inmediata. Las unidades de negocio se enfrentan a problemas operativos específicos que requieren soluciones específicas. La aplicación aprobada no contempla el caso límite. La cola de solicitudes de TI está saturada. Un desarrollador, a veces del departamento de TI, a veces integrado en un equipo de negocio, crea una solución que funciona. La solución se ejecuta, resuelve el problema y se integra al flujo de trabajo operativo. El proceso formal de gobernanza nunca se lleva a cabo porque el problema ya está resuelto.
El patrón de lo temporal que se vuelve permanente. La forma más insidiosa de software de aplicación en la sombra comienza como una solución explícitamente temporal. "Solo hasta que el sistema real esté listo". "Una solución rápida para el problema del formato de datos". "Temporal mientras esperamos que el proveedor arregle su API". Las soluciones temporales se vuelven permanentes cuando las dependencias que se acumulan a su alrededor nunca se desmantelan. La corrección del cálculo de fechas de COBOL escrita para la remediación del Y2K que todavía se llama veinticinco años después porque ningún desarrollador posterior sabía por qué existía o si era seguro eliminarla. El script de normalización de base de datos "temporal" que pasó a formar parte del lote nocturno porque la aplicación de destino nunca se construyó realmente.
El fallo en la transferencia de conocimiento. Las aplicaciones fantasma creadas por personas específicas desaparecen del conocimiento documentado de la organización cuando estas personas se marchan. El programa sigue funcionando, está integrado en los procesos de producción que dependen de él, pero no existe documentación, no se le asigna ninguna responsabilidad y nadie conoce su funcionamiento con suficiente detalle como para modificarlo de forma segura. Se convierte en un fantasma en el entorno de producción: visible en sus efectos, invisible en su gestión.
El flujo de datos en la sombra. La integración de datos es un terreno particularmente fértil para el software personalizado no documentado. Cuando la capa ETL oficial no admite una transformación necesaria, o cuando un proceso de negocio requiere que los datos se muevan entre sistemas más rápido de lo que permite el proceso de integración oficial, los desarrolladores crean programas de movimiento de datos no oficiales. Un script de Python que consulta la base de datos de producción y escribe los resultados en una unidad compartida que un proceso posterior recupera. Un programa COBOL que lee de la base de datos DB2 del mainframe y escribe en un archivo plano que una aplicación en la nube ingiere. Estos flujos de datos no oficiales cruzan los límites del sistema, manejan datos potencialmente sensibles y operan completamente fuera del marco de gobernanza de la integración.
Las cuatro categorías de software de aplicaciones paralelas
Categoría 1: Aplicaciones personalizadas de la unidad de negocio
Programas creados por desarrolladores integrados en unidades de negocio, finanzas, compras, operaciones y cumplimiento normativo, que resuelven problemas específicos del dominio. Estos programas suelen:
- Se les da nombres informales (TAXCALC, VENDREPT, ADJBATCH) sin seguir las convenciones de nomenclatura de la empresa.
- Residir en directorios o bibliotecas gestionadas por la unidad de negocio en lugar de por el departamento de TI.
- No tiene ninguna entrada en la base de datos de gestión de la configuración (CMDB).
- No tiene un responsable técnico asignado en el sistema de gestión de servicios de TI.
- Carecen de documentación formal, cobertura de pruebas e historial de control de cambios.
Su importancia suele subestimarse porque la unidad de negocio conoce la función del programa y lo considera propio. El departamento de TI, que desconoce su existencia, no puede evaluar su criticidad. La ausencia del programa en el inventario de aplicaciones de TI implica su ausencia en la planificación de la continuidad del negocio (BCP), la planificación de la recuperación ante desastres, las evaluaciones de seguridad y el alcance del programa de modernización.
Categoría 2: Programas fantasma
Programas que aparecen en la ejecución de producción, pero cuyo origen, propósito y propiedad son desconocidos para la organización actual. Existen en bibliotecas de carga y repositorios de código fuente, son llamados por otros programas o invocados por trabajos JCL, producen resultados de los que dependen los procesos posteriores, pero se ha perdido el recuerdo organizacional de por qué existen y quién es responsable de ellos.
Los programas fantasma son particularmente peligrosos desde la perspectiva de la seguridad y el cumplimiento normativo porque no se pueden revisar según los estándares actuales, no se pueden incluir en programas de análisis de vulnerabilidades que requieren la asignación de la propiedad de la aplicación y no se puede evaluar el cumplimiento normativo porque nadie sabe a qué datos acceden ni qué función empresarial cumplen.
Categoría 3: Canalizaciones de datos en la sombra
Programas no oficiales que transfieren datos entre sistemas fuera de la arquitectura de integración autorizada. Estos programas abarcan desde sofisticadas alternativas ETL hasta simples scripts de transferencia de archivos:
pitón
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")Este programa, representativo de un patrón común en entornos empresariales, utiliza credenciales de base de datos de producción codificadas, escribe datos de facturación confidenciales en una ubicación de red compartida sin cifrado y ha estado funcionando sin supervisión durante años después de que su autor abandonara la organización. No aparecería en ninguna herramienta de detección de SaaS porque se ejecuta en infraestructura interna. Tampoco aparecería en el análisis de tráfico de red porque utiliza protocolos de base de datos estándar que no generan ninguna firma identificable. Solo es visible en el propio código fuente.
Categoría 4: Trabajos por lotes no documentados
Flujos de trabajo JCL y programas programados que se ejecutan en la infraestructura de producción pero que no aparecen en la documentación oficial de la programación de trabajos. Estos se acumulan a través de:
- Trabajos enviados fuera del programador de trabajos estándar mediante envío directo
- Programas llamados dinámicamente desde dentro de otros programas (y por lo tanto no visibles de forma independiente en los inventarios del planificador).
- Trabajos que se realizan con poca frecuencia, a fin de mes, a fin de año o solo cuando se dan condiciones comerciales específicas, y que nunca se han detectado en las auditorías de inventario rutinarias.
- Empleos heredados de sistemas predecesores que fueron “migrados” pero nunca dados de baja formalmente.
Los trabajos por lotes no documentados se convierten en puntos críticos de fallo cuando:
- Una ventana de mantenimiento afecta al sistema en el que se ejecutan, y nadie sabe que debe notificar a la unidad de negocio que depende de su rendimiento.
- Se realiza una evaluación de seguridad y estos trabajos se ejecutan como cuentas de servicio no supervisadas con privilegios elevados.
- Un programa de modernización define el alcance de la migración en función del cronograma de trabajo documentado y llega al entorno de destino sin el procesamiento por lotes crítico.
Métodos de descubrimiento por categoría de software Shadow
Los métodos de detección adecuados para la TI en la sombra de SaaS son en gran medida inaplicables al software de aplicaciones en la sombra. Los métodos necesarios son:
Análisis de la biblioteca de carga. Cada programa compilado e implementado en un sistema central o de gama media se encuentra en una biblioteca de carga, el repositorio de ejecutables. Al comparar los programas de la biblioteca de carga con los del inventario oficial de aplicaciones, se revela la discrepancia: cada módulo de carga presente en la biblioteca pero no en el inventario es un programa oculto. Este análisis no requiere código fuente; opera sobre los ejecutables compilados y sus metadatos.
Recorrido del repositorio de código fuente. Los repositorios de código fuente (archivos PDS de código fuente COBOL, repositorios Git, bibliotecas de código fuente RPG) contienen todos los programas jamás escritos, incluidos aquellos que se escribieron y desplegaron de forma informal y que nunca se registraron en sistemas de gobernanza de TI. Al recorrer el repositorio completo de código fuente comparándolo con la CMDB, se revelan programas que existen en el código fuente pero que no tienen registro de gobernanza.
Conciliación de JCL y planificador. Cada flujo de trabajo JCL que se ejecuta en producción, ya sea enviado a través del planificador oficial, manualmente o invocado por otro trabajo, deja un rastro en el registro de ejecución de trabajos (JESLOG, SYSLOG). La comparación de los programas que aparecen en los registros de ejecución de producción con los programas del inventario oficial permite identificar los programas que se ejecutan en producción sin cobertura de gobernanza.
Análisis de llamadas dinámicas. Los programas que llaman a otros programas de forma dinámica, donde el nombre del programa llamado se determina en tiempo de ejecución en lugar de en tiempo de compilación, crean dependencias invisibles para el análisis estático del planificador. El análisis de llamadas dinámicas rastrea qué programas emiten instrucciones CALL con nombres de programa variables, identifica el rango de programas que podrían ser llamados y señala los programas accesibles mediante despacho dinámico que podrían no aparecer en ningún mapa de dependencias estáticas.
Rastreo del flujo de datos. Las canalizaciones de datos ocultas se pueden detectar mediante el análisis de los patrones de acceso a sistemas de archivos y bases de datos: qué programas leen o escriben en qué conjuntos de datos, archivos o tablas de bases de datos. Un programa que lee de una base de datos de producción y escribe en una ruta de archivo fuera de la jerarquía estándar de gestión de datos es un posible caso de canalización oculta.
La dimensión de la IA en la sombra
La extensión del problema de la TI en la sombra para 2026 es la IA en la sombra, donde empleados y unidades de negocio utilizan herramientas y agentes de IA sin autorización del departamento de TI. Según el informe de IBM sobre el costo de una filtración de datos de 2026, el 43 % de los incidentes de seguridad involucran a trabajadores que utilizan IA en la sombra. Gartner predice que para 2030, más del 40 % de las empresas experimentarán un incidente de seguridad o cumplimiento relacionado con la IA en la sombra no autorizada.
El riesgo específico que introduce la IA en la sombra, directamente relevante para la TI en la sombra a nivel de código, es el código fuente propietario que se incorpora a los asistentes de codificación de IA. Un empleado que utiliza un asistente de codificación de IA no autorizado para ayudar con un programa COBOL heredado ha enviado el código fuente de dicho programa a un proveedor externo de IA. El código fuente puede contener credenciales codificadas, lógica empresarial que constituye secretos comerciales o estructuras de datos cuya exposición infringe los requisitos de residencia de datos. El método de detección de este riesgo específico no es el análisis del tráfico de red, sino la detección de los programas a los que han accedido las herramientas que se comunican con las API de IA externas, lo que requiere una monitorización a nivel de aplicación en lugar de una monitorización a nivel de red.
El problema de la IA oculta y el del software de aplicación oculto comparten una característica importante: ambos son invisibles para las herramientas de detección basadas en la red que dominan el mercado de TI oculta SaaS. Ambos requieren monitorización a nivel de aplicación o análisis de código estructural para salir a la luz.
Creación del inventario completo de aplicaciones
El resultado de un programa de detección de TI en la sombra para software de aplicaciones empresariales es un inventario conciliado que abarca cuatro poblaciones:
Programas conocidos y documentados: Programas que figuran tanto en el inventario oficial como en el entorno de producción real. Estos programas cuentan con cobertura de gobernanza, propietarios asignados, historial de control de cambios y planes de recuperación ante desastres.
Programas conocidos pero no implementados: Programas que aparecen en el inventario oficial pero que no se encuentran en las bibliotecas de carga ni en los registros de ejecución de producción. Estos programas son candidatos para su retirada; es posible que se hayan dado de baja sin la debida formalización de su retirada, o que figuren en la lista de forma incorrecta.
Desconocidos pero implementados (programas en la sombra): Programas que aparecen en los registros de ejecución de producción o en las bibliotecas de carga, pero que no figuran en el inventario oficial. Estos son los principales hallazgos de TI en la sombra; programas que requieren asignación inmediata de propiedad, evaluación de seguridad y registro de gobernanza.
Dependencias no documentadas: Programas que no aparecen ni en el inventario oficial ni en los registros de ejecución de producción principales, pero que se descubren mediante análisis dinámico de llamadas o rastreo de flujo de datos como accesibles desde procesos de producción. Estos son los programas fantasma, los más difíciles de encontrar y los más peligrosos si se dejan sin detectar.
La reconciliación entre estas cuatro poblaciones da como resultado el plan de acción: registrar los programas paralelos, evaluar su nivel de seguridad, asignarles propietarios y determinar su destino, gestionarlos y mantenerlos, modernizarlos o retirarlos.
Cómo SMART TS XL Realiza un descubrimiento de TI en la sombra a nivel de código.
SMART TS XLEl enfoque de [nombre de la empresa] para el descubrimiento de TI en la sombra aborda las categorías a nivel de código a las que no pueden llegar las herramientas basadas en la red.
La capacidad de análisis de código estático comienza con un recorrido completo del repositorio de código fuente: cada programa COBOL, módulo RPG, aplicación PL/I, servicio Java, script Python y flujo de trabajo JCL del entorno se cataloga con su ubicación de origen, lenguaje, tamaño y perfil de complejidad preliminar. Este inventario sirve como base para la conciliación de la CMDB y el registro oficial de aplicaciones; los programas que aparecen en el repositorio de código fuente pero no en el inventario oficial constituyen el principal hallazgo de aplicaciones ocultas.
El mapeo de dependencias de la aplicación resuelve el problema de las llamadas dinámicas: al rastrear cada instrucción CALL en cada programa, incluidas las llamadas dinámicas donde el nombre del programa es una variable, el mapa de dependencias identifica los programas que son accesibles desde procesos de producción, incluso cuando nunca aparecen en los inventarios estáticos del planificador. Un programa fantasma que es llamado dinámicamente por diez programas de producción aparece en el mapa de dependencias aunque no tenga una definición de trabajo JCL independiente.
La capacidad de expansión de JCL rastrea la cadena de ejecución completa de cada flujo de trabajo JCL: resuelve las referencias a PROC, expande los parámetros simbólicos y crea el mapa completo de los programas que invoca cada trabajo. Al comparar este mapa con la documentación oficial de la planificación de trabajos, se identifican automáticamente los trabajos y programas que se ejecutan en producción sin cobertura documental.
La capacidad de análisis de impacto permite que los hallazgos sean prácticos: por cada programa oculto descubierto, se enumeran todos los procesos de producción que dependen de él. Un programa oculto sin dependencias es un candidato a código muerto, que puede eliminarse sin problema. Un programa oculto con veinte dependencias de producción es un activo crítico no documentado que requiere atención inmediata por parte de la gobernanza. El alcance del impacto determina la prioridad de la remediación.
La función de búsqueda empresarial permite consultar el inventario completo: encuentre todos los programas que acceden a un conjunto de datos específico (posibles candidatos para la canalización de datos en la sombra), todos los programas escritos después de una fecha específica que no tienen entrada en la CMDB (aplicaciones en la sombra recientes) y todos los programas que escriben en rutas de archivo externas fuera de la jerarquía de gestión de datos estándar. Esta función de búsqueda respalda tanto el esfuerzo de detección inicial como la monitorización continua que evita que la acumulación de aplicaciones en la sombra se reanude después de la limpieza inicial.
Para las organizaciones que llevan a cabo programas de modernización de sistemas heredados , la detección de aplicaciones no autorizadas es un paso indispensable. Un programa de modernización que define el alcance de la migración basándose en el inventario oficial de aplicaciones y descubre programas no autorizados a mitad de la ejecución es un programa cuyo alcance, cronograma y presupuesto eran erróneos desde el momento de su inicio. El descubrimiento, que debería haberse producido antes de la planificación, ahora se realiza durante la ejecución, cuando su coste es mayor.
La respuesta de la gobernanza: no bloquear, sino dar visibilidad.
Las organizaciones que gestionan eficazmente el uso no autorizado de TI en 2026 han aprendido que la prohibición total no funciona y genera incentivos perversos. La notificación de uso no autorizado de TI fracasa en la mayoría de las organizaciones por una razón: los empleados esperan un castigo. Cuando un miembro del equipo de finanzas utiliza un sistema de seguimiento de gastos no autorizado y lo notifica, un equipo de seguridad que responde con una reprimenda ha condicionado a ese empleado, y a todos con quienes habla, a guardar silencio la próxima vez.
El mismo principio se aplica al software de aplicaciones ocultas. Un desarrollador que creó una utilidad COBOL crítica para el negocio de la que depende la organización no debería ser penalizado por no haber seguido un proceso de gobernanza que tal vez no se comunicó claramente en su momento. La respuesta de gobernanza ante el descubrimiento de aplicaciones ocultas debería ser:
Registro, no eliminación. Los programas ocultos que se descubren en la ruta crítica de los procesos de negocio no son programas ocultos que deban eliminarse, sino aplicaciones de producción no documentadas que requieren gobernanza. Regístrelos, asígneles responsables, evalúe su nivel de seguridad y trátelos con la misma disciplina de gobernanza que cualquier otra aplicación de producción.
Amnistía para la autodenuncia. Un programa de gobernanza que crea canales seguros para que las unidades de negocio revelen las aplicaciones informales que han desarrollado permite descubrir software oculto con mayor rapidez que cualquier método de detección técnica. La garantía de que la divulgación conlleva apoyo de gobernanza, ayuda con la documentación, revisión de seguridad y registro formal, en lugar de medidas disciplinarias, elimina el incentivo para ocultar información.
Prevención mediante procesos. La causa principal de la acumulación de aplicaciones fantasma es la fricción en la gobernanza: el proceso oficial para solicitar el desarrollo de nuevas aplicaciones es más lento de lo que requiere el problema empresarial. Reducir esa fricción, una gobernanza ágil y flexible para el desarrollo, el soporte de gobernanza de TI integrado en las unidades de negocio y la aprobación simplificada de herramientas internas de bajo riesgo, reducen la tasa de creación de nuevas aplicaciones fantasma sin necesidad de un análisis técnico continuo.
El inventario que crees tener no es el inventario que tienes.
La diferencia entre el inventario de aplicaciones que mantiene el departamento de TI y el software que realmente se ejecuta en los entornos empresariales no es una discrepancia menor. En grandes organizaciones con décadas de acumulación de aplicaciones, la brecha entre lo documentado y lo real puede alcanzar casi el treinta por ciento del total de programas. Este treinta por ciento no documentado incluye programas que procesan datos confidenciales, realizan funciones de cumplimiento normativo, se encuentran en la ruta crítica de los procesos de negocio y presentan vulnerabilidades de seguridad que nadie ha revisado porque nadie sabía que debían hacerlo.
Las herramientas de detección de TI en la sombra de SaaS abordan eficazmente la capa de la nube de este problema. El problema de la TI en la sombra a nivel de código, que incluye programas personalizados, utilidades fantasma, flujos de datos informales y trabajos por lotes no documentados que pueblan los entornos heredados de las empresas, requiere un enfoque diferente: el análisis estructural de los artefactos de software reales en lugar de la monitorización del tráfico de red. El inventario resultante de este análisis suele ser sorprendente por su exhaustividad. Las organizaciones que realizan este trabajo descubren sistemáticamente que lo que creían tener en producción y lo que realmente se ejecuta son dos cosas significativamente diferentes. Cerrar esa brecha es la base de todo programa de gobernanza, seguridad, continuidad del negocio y modernización que dependa de conocer el funcionamiento real de la organización.
