Shadow IT como asentamiento informal: primero el mapa

La hoja se llama «precios ajustados FINAL revisado» y llega por correo cada vez que alguien de ventas necesita cotizar un precio que la lista oficial no contempla. En el marco de Urbanización del Mundo Digital (DWU), esa hoja es un asentamiento digital informal, una solución localmente útil creada fuera de la arquitectura, el gobierno, la propiedad o los controles de ciclo de vida compartidos, y así propongo tratar el shadow IT en general. Primero se pone en un mapa; después se decide qué hacer con cada asentamiento.

La hoja pertenece a Northstar Consumer Group, un fabricante y minorista regional ficticio con cinco entidades legales en cinco países, el caso que recorre la serie sobre urbanización digital. Alguien del distrito Comercial (el dominio de negocio que posee ventas y sus métricas) la armó para salir de una tarde difícil, otra persona le agregó una columna, y hoy circulan varias copias con valores distintos entre bandejas de entrada. Funciona lo bastante bien para que las cotizaciones salgan el mismo día. También expone precios negociados por cliente a cualquiera que reciba un reenvío.

Cuatro asentamientos en Northstar

En Northstar la hoja es uno de cuatro asentamientos. Un gerente regional construyó una app low-code para registrar visitas de campo. Corre sobre una plataforma que la empresa licencia y usa la identidad corporativa para iniciar sesión, pero no está registrada, no tiene quién la mantenga si el gerente cambia de puesto y no tiene fecha de revisión. Un script nocturno concilia los pedidos entre el e-commerce y el ERP con svc-integracion, una cuenta de servicio que comparte con otras integraciones. Y varios analistas pegan datos de clientes en un asistente de IA que la empresa no contrató.

Los cuatro resuelven algo que el negocio necesita. Las cotizaciones salen el mismo día, la app consiguió en su región una adopción que nadie tuvo que imponer, sin el script los pedidos divergen y el asistente ayuda a cada analista a analizar y redactar. Tres de ellos cargan además un riesgo alto que nadie administra. La hoja deja precios por cliente en cada reenvío y sus copias ya no coinciden, el script depende de una cuenta compartida sin monitoreo y de la persona que lo escribió, y el asistente saca datos de la empresa sin contrato ni auditoría.

Prohibirlos es la respuesta más rápida. Pero prohibir un asentamiento sin atender la necesidad que lo creó suele desplazarlo. Si Northstar bloquea mañana el asistente, la necesidad de asistencia analítica sigue ahí y reaparece en otro servicio, quizá más difícil de ver.

Qué es un asentamiento y qué señala

DWU trata los cuatro casos con un mismo constructo, el asentamiento informal, y con su décimo principio, el de crecimiento informal visible. La definición une cuatro condiciones con una «o», así que basta con quedar fuera de uno solo de los cuatro controles para ser informal. La app de visitas es informal por propiedad y por ciclo de vida, aunque técnicamente viva en terreno formal.

El término cubre lo que la industria llama shadow IT (hojas de cálculo, bases de datos locales, scripts, apps low-code, dashboards duplicados) y también la IA no sancionada, que entra en la misma categoría. El analista que pega datos de clientes en el asistente construye un asentamiento con la misma lógica que el autor de la hoja. Lo que cambia es la velocidad con que puede sacar datos del territorio, el perímetro legal y de riesgo dentro del cual la empresa tiene autoridad para fijar reglas.

Prefiero «asentamiento» a «shadow IT». «Shadow» sugiere algo escondido a propósito, y la mayoría de los asentamientos que he encontrado nunca se escondieron; nadie había preguntado por ellos. El término urbano describe una posición respecto de la ciudad formal (la arquitectura, las plataformas y los procesos que la empresa gobierna) y deja fuera el juicio sobre quien construyó. Ese juicio, como analicé en desviación organizacional útil, casi siempre lo decide el desenlace: la misma herramienta se llama iniciativa si salió bien e imprudencia si falló. Esa etiqueta no dice nada sobre el riesgo de la herramienta.

DWU propone que la baja habitabilidad alienta los asentamientos informales. La habitabilidad digital es el grado en que el entorno permite a sus habitantes (personas, sistemas y agentes) trabajar de forma segura y efectiva con reglas comprensibles. Cuando la ciudad formal no satisface una necesidad a una velocidad aceptable, alguien construye por su cuenta. Por eso los asentamientos son señales diagnósticas además de incumplimientos, y pueden señalar demanda no satisfecha, infraestructura inaccesible o fricción regulatoria excesiva.

En Northstar aparecen las tres. El script existe porque su autor no tenía a su alcance una ruta gobernada (una API, un evento o una cola con contrato y monitoreo) entre el e-commerce y el ERP. Es infraestructura inaccesible, y el autor usó lo que tenía a mano, la cuenta compartida. El asistente se lee mejor como fricción regulatoria. En mi versión del caso, aprobar una herramienta de IA exige revisiones de seguridad, legales y de datos que ningún analista puede completar antes de su fecha de entrega. La hoja de precios y la app de visitas señalan demanda no satisfecha, capacidades que el negocio necesita y que Comercial todavía no asumió.

El diagrama separa dos relaciones que suelen mezclarse. La primera es recíproca, una tensión que el marco reconoce. La baja habitabilidad puede generar asentamientos, y los asentamientos extendidos pueden reducir todavía más la habitabilidad. En Northstar, cada copia de la hoja que circula resta credibilidad al precio del ERP, y el siguiente vendedor confía más en la hoja, que se vuelve más necesaria. La segunda relación es la proposición P5, en la caja de la derecha, que conecta los asentamientos con formas de deuda urbana y que retomo más abajo. El camino punteado de abajo es el que sigue el resto del post. El asentamiento se lee como señal y el mapa devuelve esa señal para corregir la ciudad formal.

Primero el mapa

El método tiene cuatro pasos en orden: mapear los asentamientos, identificar la capacidad que sirven, evaluar su riesgo y su valor, y elegir una respuesta. El principio 10 lo fija como regla. El crecimiento informal se mapea y se gobierna por etapas, y prohibir es una respuesta posible entre varias.

Rastros y capacidades

La búsqueda empieza por los rastros que los asentamientos dejan en la infraestructura pública, los servicios compartidos de identidad, auditoría, observabilidad y plataformas. En Northstar, la hoja aparece en los registros del correo como un adjunto reenviado una y otra vez. La app de visitas figura en el inventario de la plataforma low-code sin dueño registrado. El script deja sesiones nocturnas de svc-integracion desde un servidor que no figura en ninguna integración registrada, y el asistente se ve en el tráfico de salida hacia servicios de IA externos. Con eso se encuentra el asentamiento, pero la capacidad que sirve solo aparece hablando con quien lo usa.

Con los años aprendí a desconfiar del primer inventario. Sale corto, porque la gente declara lo que cree que no le van a quitar. Para que alguien diga lo que construyó, declararlo tiene que costarle menos que seguir callado.

Identificar la capacidad es el paso que más se salta, y el que cambia la conversación. En el mapa, la hoja queda anotada junto a la capacidad que sirve, aprobar y comunicar precios de excepción por cliente, que pertenece al distrito Comercial. Nombrada así, la pregunta pasa a ser dónde debería vivir esa capacidad en la ciudad formal.

El inventario de Northstar

Cuatro respuestas

DWU nombra cuatro respuestas (reconocimiento, integración, reubicación y retiro) sin definirlas en detalle ni decir cuándo usar cada una. Lo que sigue es mi lectura operativa, y las distingo por lo que cambia en cada caso.

Al reconocer un asentamiento, lo único que cambia es su estatus. Se queda donde está y entra al registro de los edificios de Northstar, es decir, de sus aplicaciones, productos y servicios, con propietario, propósito, usuarios, dependencias, costo, estado de ciclo de vida y decisión de renovación. Al integrarlo, sigue donde está, pero se conecta a la infraestructura pública (identidad, auditoría, observabilidad) y a rutas y datos gobernados. Al reubicarlo, lo que contiene se muda a un edificio formal, con sus datos, sus reglas y sus usuarios, y el asentamiento se desmonta cuando la mudanza termina. Al retirarlo, se apaga y nada de su contenido se hereda. Si la demanda sigue viva, atenderla es una decisión aparte.

Una matriz para elegir

Para elegir uso una matriz de valor contra riesgo. Es una heurística mía, construida en la práctica.

El eje vertical mide el valor que el asentamiento da y que la ciudad formal hoy no ofrece, porque el valor absoluto engaña. La hoja de precios vale muchísimo mientras no exista otra forma de aprobar un precio de excepción, y casi nada el día que exista. El eje horizontal mide el riesgo para la empresa. Para estimarlo pregunto si el asentamiento duplica datos, crea dependencias ocultas, abre brechas de control o genera retrabajo, que son las consecuencias que P5 asocia con los asentamientos.

En el cuadrante de valor alto y riesgo alto hace falta una segunda pregunta, dónde está el riesgo. En el script está en las conexiones (la cuenta compartida, la falta de monitoreo), y eso se corrige conectándolo mejor. En la hoja el riesgo está en el medio mismo. Un adjunto de correo no se puede conectar a nada, así que lo que se mueve es la capacidad.

El asistente de IA cae hoy en la misma zona que la hoja, pero no hay nada que mudar, porque Northstar no controla la herramienta y las conversaciones de los analistas quedan en un servicio externo. Cuando exista un asistente sancionado, con identidad cívica (identidad propia, patrocinador y permisos acotados, como desarrollo en el post sobre gobierno de agentes), el no sancionado deja de ofrecer algo que la ciudad formal no tenga y el punto baja al cuadrante de retiro. Retirarlo antes de que esa alternativa exista reproduce el desplazamiento que describí con el bloqueo.

La entrada en el registro

Así podría verse la entrada del script en el registro. Propietario, distrito y dependencias vienen del registro de edificios que el marco propone para Northstar; capacidad, valor, riesgo y respuesta, de la práctica de mapeo. El formato y los demás campos son míos.

# Registro de asentamientos de Northstar (caso ficticio, formato ilustrativo)
id: conciliacion-pedidos-nocturna
tipo: script programado
capacidad: conciliar pedidos entre e-commerce y ERP
distrito: sin decidir              # Comercial o Cadena de suministro
propietario: sin asignar           # hallazgo del mapa
dependencias: [ERP, e-commerce]
identidad_actual: svc-integracion  # compartida con otras integraciones
señal: falta una ruta gobernada de pedidos
valor: alto
riesgo: alto
respuesta: integración
condiciones:
  - identidad propia con permisos mínimos
  - logs y alerta de fallo en la observabilidad compartida
  - propietario nombrado antes de la próxima revisión
salida_prevista: consumir el evento de pedido confirmado y dejar de leer tablas del ERP

Casi todos los campos son de rutina. distrito: sin decidir muestra que el mapa encontró una capacidad que ningún distrito asumió, un problema de zonificación (qué distrito posee qué capacidad) que el script tapaba. salida_prevista deja escrito que su conexión actual es temporal. Sus lecturas directas a las tablas del ERP son una de las carreteras improvisadas que describí en el post sobre integraciones punto a punto, y el día que exista la ruta gobernada el script deja esas tablas y pasa a consumir el evento.

El caso de Grupo Diveco

El relato con el que arrancó Portal Diveco, la plataforma de Grupo Diveco que presenté al abrir la serie, describe un punto de partida que este post llamaría asentamientos, procesos repartidos en «hojas de Excel compartidas, carpetas de SharePoint sin estructura y correos que nadie puede rastrear».

Desde entonces los asentamientos han aparecido uno por uno. En abril de 2026 quedó documentado un hallazgo de severidad alta. Un tablero regional de BI leía archivos de Excel estáticos guardados en el almacenamiento personal de un analista. El tablero estaba en terreno formal, y lo informal era su fuente. La asignación de cada cliente a su KAM (el ejecutivo responsable de la cuenta) siguió otro camino. Salió de las hojas de cálculo y se mudó a Datos Maestros, que hoy es su fuente de verdad y la publica al data lake corporativo. Es una reubicación en el sentido de este post, porque el contenido cambió de edificio. En la misma línea, los maestros de gastos formalizan tablas que no existen en SAP, y los catálogos dinámicos reemplazan catálogos sueltos.

De las cuatro respuestas se observan tres, reconocimiento, integración y reubicación. Lo que falta es justo el paso con el que empieza el método. No hay un inventario sistemático de asentamientos, y cada uno salió a la luz por un hallazgo o por una migración. Tampoco aparecen en la maqueta 3D de la plataforma, porque sus edificios se copian a mano del registro de herramientas y del monitor de RPA, y ahí solo figura lo que ya es formal. Diveco llegó a sus asentamientos en el orden inverso al que propone este post, primero la respuesta y todavía sin mapa. Sin mapa tampoco hay densidad de asentamientos que contar, y esa es la variable de la que depende P5.

Lo que P5 predice y cómo probarlo

La proposición P5 sostiene que la densidad de asentamientos informales se asociará positivamente con datos duplicados, dependencias ocultas, brechas de control y retrabajo operativo. Son formas de deuda urbana, las restricciones acumuladas que frenan el cambio y aumentan el riesgo operativo. Como todo el marco, P5 es una hipótesis sin medir, y viene con la indicación de qué evidencia serviría para probarla.

Si P5 es correcta, en una empresa como Northstar esperaría ver que los distritos con más asentamientos por capacidad acumulan más conciliaciones manuales, más copias de los mismos datos y más excepciones de control abiertas. Comercial, con la hoja y la app, sería el primer lugar donde mirar.

Mi matriz tiene aquí una trampa. Si puntúo el riesgo con las mismas consecuencias que P5 predice, el mapa ya no sirve para probar P5, porque la asociación viene incluida en la medición. Esas consecuencias tendrían que contarse aparte, en los registros de operación y de auditoría.

La objeción más directa al constructo la plantea el mismo marco, y es una prueba discriminante. La densidad de asentamientos tiene que separarse empíricamente de los inventarios convencionales de deuda técnica, y si contarlos resulta ser lo mismo con otro nombre, el constructo sobra.

Aunque la asociación aparezca, P5 no establece dirección causal. Podría ser la deuda urbana la que empuja a la gente a construir por fuera, o una causa común, como un área de plataforma sin financiamiento que produce a la vez asentamientos y deuda (el financiamiento de plataforma figura entre las explicaciones rivales). En ambos casos, reducir asentamientos no tendría por qué reducir la deuda. Las explicaciones rivales de ese tipo, y cómo controlarlas en un estudio, están en cómo sabría que esta teoría está equivocada.

Formalizar a destiempo

Formalizar asentamientos mejora el gobierno y puede suprimir la experimentación local. Es el trade-off que acompaña a P5.

La app de visitas existe porque un gerente regional pudo construirla sin pedir permiso a nadie. Si el registro fuera un requisito previo, con revisión de arquitectura y aprobación del distrito, probablemente la app no existiría. La adopción que consiguió sola, porque resolvía un problema que su autor vivía a diario, es lo que en ingeniería de adopción tuve que diseñar a propósito, con límites de intentos y plazos que hacía cumplir el servidor. El costo de formalizar demasiado pronto no aparece en ningún inventario, porque consiste en herramientas que nunca llegaron a construirse.

Hay un segundo costo. Un registro exigente es fricción, y la fricción puede producir los asentamientos que el registro pretende gobernar, esta vez mejor escondidos.

Para contener ambos, el reconocimiento llega después de que el asentamiento demuestra valor, nunca como condición para construirlo. El tratamiento pesado lo reservo para los asentamientos que tocan datos de clientes o sacan información del territorio; el resto se registra con lo mínimo. Quien lo construyó participa en la decisión, porque suele conocer mejor que nadie la capacidad que sirve.

Tampoco el mapa es gratis. Hay que mantenerlo, envejece rápido y alguien tiene que ser su dueño. Un inventario de asentamientos hecho una vez, en una hoja de cálculo, sin propietario ni fecha de revisión, cumple la definición de asentamiento informal.

Lo que el mapa dice de la ciudad formal

Leído en negativo, el mapa de Northstar describe su ciudad formal, y los huecos que muestra no son del mismo tipo. Dos son capacidades de Comercial que la ciudad formal no atendía, la aprobación de precios de excepción y el registro de visitas. Otro es una ruta de pedidos que nunca se construyó, sobre una capacidad que ningún distrito reclama. El último es un trámite de aprobación de IA que nadie puede completar a tiempo. Un inventario de aplicaciones no habría mostrado ninguno, porque lista lo que la ciudad construyó, y este mapa lista lo que la gente necesitó mientras tanto.

Queda una condición que ningún diagrama resuelve. Si el mapa lo hace un equipo que después no tiene autoridad para cambiar la ciudad formal, la gente aprende que declarar un asentamiento solo sirve para perderlo, y el siguiente inventario sale más corto que el primero.

Este artículo es parte de la serie Urbanización digital, basada en el preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), un marco conceptual cuyas ideas apliqué y refiné en la plataforma corporativa de Grupo Diveco, aunque sus seis proposiciones todavía no tienen validación empírica. Anterior: Gobernar el subsuelo de datos que nadie ve. Siguiente: Habitabilidad digital: lo que la arquitectura no mide.