Shadow IT y proliferación de SaaS: cómo gobernarlo sin bloquear (catálogo, criticidad y salida)

El crecimiento de SaaS dentro de las empresas ha mejorado la velocidad de adopción de tecnología, pero también ha fragmentado el control. Un equipo puede resolver una necesidad real en muy poco tiempo, contratar una herramienta con presupuesto operativo y empezar a usarla antes de que TI, seguridad, compras o finanzas tengan visibilidad. Eso no solo genera riesgo. También indica que el proceso corporativo no está absorbiendo bien la demanda.

Para negocio, el problema no es “que existan demasiadas herramientas” en abstracto. El problema es que, sin gobierno, el uso de SaaS deriva en tres tensiones concretas. La primera es coste: aparecen licencias duplicadas, renovaciones sin revisión y gasto repartido en partidas pequeñas que nadie consolida. La segunda es riesgo: accesos mal gobernados, datos sin clasificar, integraciones que crecen sin control y dependencias con proveedores que no se han evaluado con suficiente detalle. La tercera es velocidad: cuando el proceso oficial es lento o ambiguo, las áreas aprenden a rodearlo.

Gobernar bien no significa bloquear. Significa crear un sistema donde sea más fácil hacer las cosas dentro del proceso que fuera de él. Eso exige visibilidad, criterios proporcionales y tiempos de respuesta previsibles. Si la organización consigue ese equilibrio, puede reducir duplicidad, contener riesgo y mantener agilidad operativa sin perseguir el imposible de “cero Shadow IT”.

Acciones recomendadas

1. Lanzar un inventario inicial de 30 días combinando finanzas, compras e identidad para detectar qué SaaS se está utilizando realmente y quién responde por cada uno.
2. Definir niveles simples de criticidad según proceso, datos e integración, y asociar controles mínimos obligatorios para cada nivel.
3. Crear un catálogo de herramientas aprobadas con casos de uso, condiciones y responsables, de modo que las altas repetitivas sean rápidas y predecibles.
4. Implantar un circuito de compra con SLA internos para evitar que la lentitud del proceso oficial empuje a negocio a comprar fuera.
5. Asignar un responsable de negocio y un responsable técnico a cada SaaS relevante, con revisión al menos anual de uso, coste, accesos y renovación.
6. Exigir un plan de salida en SaaS críticos que cubra exportación de datos, revocación de accesos, transición e integraciones.
7. Medir regularización, consolidación, tiempo de aprobación y riesgos corregidos para que la gobernanza de SaaS se gestione como capacidad operativa y no como campaña puntual.

El Shadow IT aparece cuando el circuito corporativo es más lento o ambiguo que la compra directa. A menudo no hay voluntad de incumplir, sino una necesidad de negocio no atendida con suficiente velocidad. Un enfoque de “sí, con condiciones” aumenta visibilidad y permite ordenar el ecosistema sin bloquear a las áreas.

Por qué aparece la proliferación de SaaS

Antes de diseñar controles conviene entender el origen del problema. La proliferación de herramientas no suele nacer de una sola causa, sino de la combinación de varias fricciones organizativas.

La urgencia del negocio supera al proceso interno

Cuando un equipo tiene que lanzar una campaña, ordenar un flujo operativo o coordinar trabajo con terceros, no suele evaluar la pureza del modelo de gobierno. Evalúa si puede resolver su necesidad esta semana. Si el circuito corporativo es lento, la compra directa se convierte en la alternativa más probable.

El mercado SaaS reduce la fricción comercial

Muchas herramientas están diseñadas para que la adopción sea inmediata. Ese diseño comercial compite, en la práctica, con los mecanismos internos de control. Si el alta externa tarda minutos y la interna tarda semanas, el incentivo es evidente.

El catálogo corporativo no cubre todos los casos de uso

No todas las funciones de negocio necesitan lo mismo. Marketing, ventas, soporte, operaciones o equipos de proyecto suelen demandar soluciones específicas. Cuando el catálogo corporativo es limitado o está desactualizado, buscar fuera deja de verse como excepción y pasa a ser rutina.

El proceso de aprobación no es predecible

Un proceso complejo puede ser asumible si es claro. Lo que más empuja al atajo no siempre es la exigencia, sino la opacidad: nadie sabe qué hay que entregar, quién decide ni cuándo habrá respuesta. Esa incertidumbre erosiona la credibilidad del modelo oficial.

La conclusión práctica es simple: la organización no reduce Shadow IT solo endureciendo normas. Lo reduce cuando crea un camino más útil que la improvisación.

Qué debe perseguir un modelo de gobierno

El objetivo realista no es eliminar por completo el uso no centralizado de software. El objetivo es lograr tres cosas: visibilidad, control proporcional y capacidad de salida.

Visibilidad significa saber qué herramientas existen, quién las usa, para qué proceso sirven y qué datos tocan. Control proporcional significa no tratar igual una utilidad menor y una plataforma conectada a procesos críticos. Capacidad de salida significa evitar que una herramienta relevante quede incrustada en la operación sin plan de exportación, sustitución o transición.

Ese enfoque cambia el tono del gobierno. Ya no se trata de impedir cada decisión local, sino de incorporar esas decisiones a un marco donde la empresa pueda entender, priorizar y gobernar su riesgo sin paralizar a las áreas.

Inventario inicial: descubrir sin convertirlo en vigilancia

El primer paso es construir un inventario suficiente para actuar (no perfecto). Para reducir resistencia, conviene apoyarse en fuentes sencillas y complementarias:

• Finanzas: facturas, tarjetas y suscripciones para detectar herramientas y renovaciones.
• Compras: contratos y fechas de renovación para priorizar revisiones.
• Identidad: aplicaciones usadas con credenciales corporativas para visibilidad de accesos.
• Señales técnicas (si aplica): inventario de aplicaciones/extensiones, con criterios de privacidad y coordinación con legal/privacidad/RR. HH. cuando corresponda.
• Entrevistas: conversación con las áreas para entender necesidad y fricción del proceso.

No hace falta esperar a tener una foto cerrada para empezar a clasificar, regularizar o consolidar.

Clasificar para decidir, no para burocratizar

Una vez que la empresa ve parte de su ecosistema, necesita decidir qué hacer con cada herramienta. Ahí es donde entra la clasificación. El objetivo de clasificar no es producir taxonomías complejas, sino determinar con rapidez qué controles son necesarios y qué nivel de revisión corresponde.

Un modelo sencillo puede apoyarse en tres variables:

• criticidad del proceso que la herramienta soporta,
• tipo de dato que almacena o procesa,
• exposición operativa derivada de usuarios, automatizaciones o integraciones.

Nivel 1: uso acotado y bajo impacto

Aquí suelen entrar herramientas auxiliares, con datos limitados y escasa dependencia operativa. Su indisponibilidad genera molestia o pérdida de comodidad, pero no interrumpe procesos relevantes.

Nivel 2: impacto medio o departamental

En este nivel ya aparece información interna relevante, uso compartido por varios miembros de un equipo o dependencia de un proceso departamental. La revisión debe ser más estructurada, especialmente en permisos, renovaciones e integraciones.

Nivel 3: alto o crítico

Son herramientas que tocan procesos clave, datos sensibles, automatizaciones relevantes o relaciones con clientes y operación principal. Aquí el estándar de gobierno debe ser más exigente desde el principio.

La clasificación funciona si desencadena decisiones claras: qué revisión se pide, quién aprueba, qué controles son obligatorios y qué excepciones requieren elevación.

Controles mínimos por criticidad

No todos los SaaS necesitan el mismo tratamiento. De hecho, intentar aplicar el mismo paquete de control a todo suele producir el efecto contrario al buscado: ralentiza la respuesta y empuja compras fuera del proceso.

Un modelo útil se puede organizar en cuatro bloques.

Identidad

La pregunta básica es quién accede, cómo accede y cómo se revoca ese acceso. En herramientas relevantes conviene priorizar:

• federación o SSO cuando sea viable,
• MFA en accesos sensibles o administrativos,
• perfiles mínimos por rol,
• alta y baja coordinadas,
• revisión periódica de cuentas activas.

En niveles altos, depender de usuarios locales sin control centralizado debería tratarse como excepción.

Datos

Aquí importa qué información entra en la herramienta, quién puede verla y cuánto tiempo permanece:

• clasificación del dato permitido,
• reglas de acceso y compartición,
• criterios de retención y borrado,
• límites para exportación cuando aplique,
• revisión de espacios compartidos o públicos.

Contrato y proveedor

La revisión contractual no debería centrarse solo en precio. También conviene revisar:

• renovaciones y condiciones de cancelación,
• soporte y escalado,
• subprocesadores o cambios relevantes,
• términos de servicio según criticidad,
• capacidad de exportación de datos,
• condiciones de salida.

Operación

En SaaS más relevantes, la empresa necesita algo más que una compra aprobada:

• responsable de negocio,
• responsable técnico,
• revisión periódica,
• trazabilidad cuando sea necesaria,
• continuidad básica,
• plan de transición en caso de sustitución o incidencia prolongada.

La lógica es de proporcionalidad. Cuanto mayor sea el impacto, más explícito debe ser el control.

Catálogo de aprobados y circuito con SLA internos

Uno de los elementos más eficaces para reducir Shadow IT no es un comité más grande, sino un catálogo útil acompañado de tiempos de respuesta claros. Si una herramienta ya está evaluada para un caso de uso concreto, el alta debería ser rápida. Si no lo está, la organización necesita una ruta de evaluación con pasos y plazos conocidos.

Qué debe resolver el catálogo

El catálogo no tiene que ser enciclopédico. Debe responder a preguntas prácticas:

• qué herramienta está aprobada,
• para qué caso de uso,
• con qué nivel de criticidad,
• con qué condiciones de uso,
• quién es el responsable,
• cuándo toca revisar de nuevo.

Por qué importan los SLA internos

Cuando la organización exige aprobaciones pero no compromete tiempos, el mensaje real para negocio es incierto. El área solicitante no sabe si tendrá respuesta en pocos días o en varias semanas. Esa falta de previsibilidad incentiva el atajo.

Por eso conviene definir SLA internos por tipo de solicitud. No hace falta fijar una norma universal en el artículo, pero sí una lógica:

• alta sobre herramienta ya aprobada: respuesta rápida,
• nivel bajo: revisión simplificada,
• nivel medio: validación estándar,
• nivel alto o crítico: revisión ampliada.

El punto central no es el número exacto de días, sino que la empresa los defina, los publique y los cumpla.

Lista de verificación de alta

Para no convertir el proceso en una barrera documental, la entrada debería ser breve y operativa:

• necesidad de negocio,
• área solicitante,
• datos implicados,
• usuarios previstos,
• integraciones esperadas,
• criticidad estimada,
• responsable de negocio,
• responsable técnico.

Esa información suele bastar para enrutar la solicitud y decidir el nivel de revisión sin frenar innecesariamente.

El plan de salida: la parte que suele llegar demasiado tarde

Muchas organizaciones revisan la entrada de una herramienta y olvidan la salida. Sin embargo, buena parte del riesgo aparece al final del ciclo: datos difíciles de recuperar, integraciones que nadie documentó, cuentas abiertas tras una baja o renovaciones que continúan por inercia.

En SaaS críticos, conviene tratar la salida como parte del alta. Eso no significa anticipar una ruptura inminente, sino reducir dependencia futura.

Un plan de salida razonable debería cubrir:

• cómo se exportan los datos y en qué formato,
• quién valida integridad y utilidad de esa exportación,
• qué accesos se revocan y en qué secuencia,
• qué integraciones deben desactivarse,
• cómo se comunica la transición a usuarios,
• qué alternativa existe si el servicio deja de ser viable.

Este punto es especialmente importante cuando una herramienta empieza siendo táctica y acaba conectada a procesos principales. El lock-in rara vez aparece de golpe; se construye poco a poco cuando el uso crece sin una estrategia de salida.

Consolidar sin romper la operación

Un inventario de SaaS no sirve solo para aprobar mejor. También sirve para retirar. En casi cualquier organización aparecerán herramientas solapadas, soluciones poco utilizadas o aplicaciones que cumplieron una función temporal y se quedaron activas por inercia.

La consolidación debe hacerse con criterio de negocio, no solo de ahorro. A veces conviene mantener una solución algo más costosa si ofrece mejor integración, menor fricción de soporte o una gobernanza de accesos más robusta. En otros casos, dos herramientas similares pueden convivir un tiempo mientras se ordena la transición.

La retirada responsable incluye:

• comunicación a usuarios,
• conservación o exportación de información necesaria,
• cierre de accesos,
• revocación de integraciones,
• cancelación contractual y financiera,
• seguimiento para evitar reaparición informal de una alternativa no aprobada.

Eliminar una herramienta sin dar sustituto suele recrear el problema que se intentaba corregir.

Métricas que sí ayudan a gobernar

Para que este modelo no se quede en intención, conviene medir pocas cosas, pero útiles. Algunas métricas ayudan a mantener la conversación en términos de capacidad operativa:

• número de herramientas identificadas,
• porcentaje regularizado,
• porcentaje con responsables asignados,
• porcentaje con revisión anual completada,
• herramientas consolidadas o retiradas,
• renovaciones revisadas antes de vencimiento,
• tiempo medio de aprobación por nivel,
• porcentaje con control centralizado de acceso cuando aplique,
• riesgos corregidos detectados en revisiones.

Estas métricas no buscan exhibir perfección. Buscan mostrar si la organización gana visibilidad, decide más rápido y reduce dependencia desordenada.

Errores comunes que conviene evitar

Hay varios fallos recurrentes en programas de gobierno de SaaS.

Prohibir sin alternativa. Si la necesidad sigue existiendo, la compra solo se desplazará fuera del radar. Aprobar sin responsable. Sin una persona que responda por uso, coste y renovación, la herramienta queda en tierra de nadie. Tratar todo igual. La falta de proporcionalidad destruye velocidad y credibilidad. Pensar que el contrato resuelve el riesgo. Sin identidad, permisos y proceso de baja, el control sigue siendo débil. No revisar integraciones. Una herramienta menor puede ganar criticidad por lo que conecta, no por lo que parece. Dejar la salida para el final. Cuando se piensa tarde, ya suele haber dependencia.

Un enfoque práctico: sí, con condiciones

La mejor política frente al Shadow IT no es una promesa de erradicación. Es un modelo operativo donde las áreas perciben que pedir aprobación merece la pena porque obtienen respuesta, criterio y apoyo. En ese entorno, el gobierno deja de verse como freno y pasa a ser un mecanismo para usar software con menos incertidumbre.

La combinación más útil suele ser simple: inventario suficiente, clasificación por criticidad, catálogo de aprobados, controles mínimos por nivel, SLA internos de decisión y plan de salida para herramientas críticas. Con eso, la empresa no evita toda dispersión, pero sí gana la capacidad de verla antes, corregirla con más orden y reducir dependencia innecesaria.

En el fondo, gobernar SaaS bien no consiste en cerrar puertas, sino en diseñar un proceso donde la opción correcta sea también la más practicable. Ahí es donde el control deja de competir con la velocidad y empieza a sostenerla.