Low-code governance: Un framework para empresas de 500-2.000 empleados

El uso de plataformas low-code se ha expandido rápidamente en empresas medianas y grandes durante los últimos años. En 2024, aproximadamente el 67% de las empresas europeas con más de 500 empleados tenía algún proyecto de desarrollo low-code en marcha.[1]

Sin embargo, cerca del 58% de esas organizaciones no contaba con un marco claro de governance para gestionarlos. Según previsiones de Gartner, el 70% de las nuevas aplicaciones empresariales se desarrollarán con tecnologías low-code para 2025, y el 75% de las grandes empresas utilizará al menos cuatro herramientas low-code.[2]

Cuando esta adopción ocurre sin una estructura mínima de control, empiezan a aparecer situaciones relativamente conocidas para los equipos de IT: distintos departamentos desarrollan herramientas propias sin validación de seguridad, sin procesos de backup definidos, sin documentación suficiente o sin un responsable claro del proceso.

En algunos casos, estas herramientas dependen completamente de la persona que las construyó. Cuando esa persona cambia de rol o deja la organización, mantener o evolucionar el sistema se vuelve mucho más difícil.

Este artículo propone un framework de governance específicamente pensado para empresas de entre 500 y 2.000 empleados, que buscan aprovechar el potencial del low-code sin generar deuda técnica ni comprometer la seguridad de sus datos.

Por qué el governance low-code es diferente del IT governance tradicional

Los modelos tradicionales de IT governance se diseñaron para un entorno en el que el desarrollo de herramientas estaba concentrado en equipos técnicos especializados. En ese contexto, centralizar decisiones y establecer procesos formales de aprobación resultaba razonable: el número de proyectos era limitado y los equipos responsables estaban claramente definidos.

Las plataformas low-code cambian parcialmente este escenario. Hoy es relativamente habitual que analistas de negocio o responsables de operaciones puedan construir herramientas funcionales tras un periodo breve de formación. Según Gartner, el 41% de los empleados en unidades de negocio son actualmente «business technologists» que construyen o personalizan soluciones tecnológicas fuera del departamento de IT.[3]

Esto introduce una dinámica distinta: el número potencial de herramientas aumenta y el desarrollo se distribuye entre más áreas de la organización. Cuando se intenta aplicar sin adaptación el governance IT tradicional —comités de aprobación largos, procesos de change management muy formales o requisitos documentales extensos— suele producirse un efecto no deseado: los equipos buscan alternativas para avanzar por su cuenta.

En esos casos aparece precisamente aquello que el governance pretendía evitar: shadow IT sin visibilidad ni control. Según Gartner, el shadow IT representa ya entre el 30% y el 40% del gasto total en IT de las grandes empresas.[4]

Por esta razón, el objetivo del governance en entornos low-code suele ser diferente. Más que limitar qué herramientas pueden construirse, el foco pasa a ser asegurar que las herramientas que se desarrollan cumplen estándares mínimos de seguridad, mantenibilidad y documentación. Esto implica un cambio conceptual importante: pasar de un modelo centrado en el control a otro orientado a habilitar el desarrollo de forma responsable.

Principio de diseño

Un framework de governance low-code efectivo suele compartir una característica clave:

debe ser más rápido y útil que no tenerlo.

Si los equipos perciben que saltarse el proceso es más sencillo que seguirlo, lo más probable es que lo hagan.

Por el contrario, cuando el framework aporta beneficios claros —seguridad, soporte técnico, integración con sistemas corporativos o visibilidad sobre los proyectos— los equipos tienden a adoptarlo de forma natural.

Los cuatro pilares de un framework de governance low-code

Pilar 1 — Clasificación de herramientas por nivel de criticidad

No todas las herramientas low-code requieren el mismo nivel de control.

Por ejemplo, una pequeña herramienta utilizada por un único equipo para automatizar cálculos o reportes tiene un perfil de riesgo muy distinto al de una aplicación que gestiona contratos o que se integra con el ERP corporativo.

Por esta razón, muchos frameworks utilizan un sistema de clasificación por niveles de criticidad (habitualmente Tier 1, Tier 2 y Tier 3).

Este modelo permite aplicar el nivel adecuado de governance según el impacto potencial de cada herramienta y evita dos problemas frecuentes:

• introducir burocracia innecesaria en herramientas simples
• subestimar los riesgos asociados a aplicaciones críticas

De esta forma, el governance se ajusta al nivel de riesgo real de cada proyecto en lugar de aplicar el mismo proceso a todos los casos.

‍

‍

La clasificación determina automáticamente el proceso de aprobación requerido, los estándares mínimos de documentación, los requisitos de backup y los criterios de revisión periódica.

Las herramientas Tier 3 pueden construirse y desplegarse sin aprobación formal, aunque deben notificarse al IT Manager del área.
Las herramientas Tier 2 requieren una revisión técnica rápida (habitualmente en menos de 48 horas).
Las herramientas Tier 1 siguen el proceso completo de revisión.

Pilar 2 — Proceso de aprobación ágil con tiempos garantizados

El proceso de aprobación debe tener una regla clara:
tiempos máximos de respuesta definidos.

Una práctica habitual es establecer:

• 48 horas para solicitudes Tier 2
• 5 días laborables para solicitudes Tier 1

Si IT no responde en ese plazo, la aprobación se considera concedida bajo condiciones estándar.

Esta regla suele ser clave para que el proceso tenga credibilidad dentro de la organización.

‍

‍

El formulario de solicitud también debe ser breve y claro. Los campos mínimos suelen incluir:

• nombre y descripción de la herramienta
• caso de uso y equipos afectados
• datos que se almacenarán o procesarán
• integraciones necesarias con sistemas existentes
• nombre del process owner (responsable de la herramienta en el negocio)

Con esta información, una gran parte de las clasificaciones puede realizarse automáticamente.

Pilar 3 — Stack aprobado de herramientas (Approved Stack)

El tercer pilar consiste en mantener un catálogo de herramientas low-code aprobadas por IT, con niveles de soporte definidos y criterios claros de inclusión.

El objetivo no es limitar artificialmente las opciones disponibles, sino evitar la proliferación de herramientas sin soporte técnico, sin formación interna o sin capacidad de integración con la infraestructura existente.

Un Approved Stack típico en una empresa de 500–2.000 empleados suele incluir entre 20 y 30 herramientas organizadas en categorías como:

• plataformas de construcción (WeWeb, Bubble, Softr)
• bases de datos y backend (Supabase, Airtable, Notion para casos simples)
• herramientas de automatización (n8n, Make, Zapier)
• formularios y encuestas
• herramientas de integración
• dashboards y visualización de datos

Para cada herramienta incluida en el stack aprobado, IT suele mantener:

• documentación de integración con sistemas internos
• templates de arquitectura para casos de uso comunes
• acceso a licencias corporativas
• al menos una persona del equipo con experiencia práctica en la herramienta

Este último punto suele ser determinante: el Approved Stack solo funciona si IT puede ofrecer soporte real a las herramientas que aprueba.

Criterios de inclusión en el Approved Stack

Normalmente se consideran aspectos como:

• modelo de negocio estable del proveedor
• cumplimiento de GDPR y residencia de datos en Europa
• API documentada para integración con sistemas internos
• posibilidad de exportar datos sin restricciones
• al menos tres años de presencia en el mercado

Pilar 4 — Training y soporte continuo (Office Hours)

El cuarto pilar cambia el papel del departamento de IT:
de guardián del sistema a habilitador del desarrollo interno.

En lugar de limitarse a revisar solicitudes de forma reactiva, IT organiza sesiones periódicas de Office Hours donde cualquier persona de la empresa puede:

• resolver dudas sobre herramientas low-code
• pedir ayuda con automatizaciones
• validar la viabilidad de una idea antes de construirla

Este formato suele generar varios beneficios:

• reduce el número de proyectos que aparecen como shadow IT
• mejora la calidad técnica de las herramientas construidas por negocio
• crea un canal informal de colaboración entre IT y otros departamentos

El formato habitual suele ser una sesión semanal de una hora, con al menos un IT Manager o arquitecto técnico disponible.

Estas sesiones se centran en resolver problemas concretos.
La formación estructurada suele ofrecerse aparte, en workshops específicos organizados cada trimestre.

Plan de implementación en 12 semanas

‍

‍

Métricas de éxito del framework

Un framework de governance low-code efectivo suele evaluarse en cuatro dimensiones:

1. Velocidad: El tiempo medio de aprobación se reduce o se mantiene bajo control.

2. Adopción: El porcentaje de herramientas registradas en el catálogo central supera el 85 % en los primeros meses.

3. Seguridad: No aparecen incidentes de seguridad asociados a herramientas low-code no gobernadas.

4. Satisfacción: Los equipos de negocio perciben el governance como un facilitador, no como una barrera.

Resultados típicos

Benchmark observado en organizaciones donde se ha aplicado este modelo indican que:

• el tiempo medio de aprobación se sitúa entre 48 y 72 horas para la mayoría de solicitudes
• entre el 60 % y el 80 % del shadow IT existente suele identificarse y regularizarse en los primeros seis meses

Impacto esperado

La implementación de un framework de governance low-code suele poder realizarse en aproximadamente 12 semanas, normalmente en paralelo con la operación habitual del departamento de IT.

El retorno de esta iniciativa se materializa principalmente en dos áreas:

• reducción del riesgo de seguridad asociado al shadow IT
• mayor velocidad en el desarrollo de herramientas internas por parte de los equipos de negocio

Notas

[1]  Nota metodológica: Las cifras del 67% y el 58% son estimaciones aproximadas sintetizadas a partir de encuestas del sector de los años 2023–2024 (Gartner, Forrester, KPMG). No proceden de un único estudio primario con esa segmentación específica para empresas europeas de más de 500 empleados; se presentan como referencia orientativa del orden de magnitud del problema.

[2]  Gartner. (2022). Gartner Forecasts Worldwide Low-Code Development Technologies Market to Grow 20% in 2023. https://www.gartner.com/en/newsroom/press-releases/2022-12-13-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023

[3]  Gartner. (2021). Gartner Says the Majority of Technology Products and Services Will Be Built by Professionals Outside of IT by 2024. Referenced in multiple Gartner publications: 41% of employees in business units are 'business technologists' who build or customize technology solutions.

[4]  Gartner. (2023). How to Manage Shadow IT Risk While Enabling Business Innovation. Gartner Research. https://www.gartner.com/en/information-technology/insights/shadow-it

[5]  Nota metodológica: Los rangos de resultados típicos del framework (48–72 horas de aprobación media; 60–80% del shadow IT regularizado en seis meses) se basan en la experiencia acumulada de Yellow Glasses en proyectos de governance low-code en empresas medianas. No proceden de un estudio externo único; se presentan como referencia orientativa derivada de la observación de proyectos comparables.

‍