Una plataforma low-code reduce la barrera para construir, no las obligaciones que tiene lo construido. Un flujo montado por un departamento en una tarde accede a datos reales, ejecuta acciones sobre sistemas de producción y crea una dependencia operativa exactamente igual que una aplicación desarrollada por el equipo técnico. La diferencia es que nadie ha revisado sus permisos, nadie sabe que existe y nadie lo mantendrá cuando su autor cambie de puesto.
Esto no es un argumento contra el low-code. Es un argumento a favor de tratarlo como lo que es: software en producción.
Obligación | En un desarrollo formal | En un flujo low-code |
|---|---|---|
Permessi | Revisados en diseño | Heredan la cuenta de quien lo creó |
Tracciabilità | Diseñada | Depende de lo que registre la plataforma |
Continuidad | Documentación y relevo | Vive en la cabeza de una persona |
Cumplimiento | Evaluado antes de desplegar | Nadie lo ha evaluado |
La fila de los permisos es la más peligrosa. Un flujo creado por una persona de finanzas se ejecuta habitualmente con sus credenciales. Eso significa dos cosas: que el flujo puede ver todo lo que ve esa persona, y que cuando esa persona cambie de departamento o se marche, el flujo dejará de funcionar o seguirá funcionando con permisos que ya no debería tener. Ambos desenlaces son malos.
La fila de la continuidad es la que produce las urgencias. Un proceso de facturación que depende de un flujo que solo entendía alguien que ya no está es un riesgo operativo real, y aparece siempre en el peor momento.
Conviene reconocer el mérito, porque la respuesta no puede ser prohibir. El low-code prospera porque resuelve un problema auténtico: los departamentos tienen necesidades pequeñas y urgentes, y el canal formal de tecnología tarda semanas o meses en atenderlas.
Mientras esa diferencia de velocidad exista, la gente construirá por su cuenta. Es el mismo mecanismo que produce la shadow AI que entra por la tarjeta corporativa , y se corrige igual: no cerrando la vía informal, sino haciendo la vía formal lo bastante rápida.
La forma práctica de gobernar esto sin frenar a nadie es clasificar por consecuencia, no por herramienta:
Nivel 1 — Personal. Afecta solo a quien lo crea, no toca datos sensibles ni escribe en sistemas compartidos. Libertad total, sin trámite.
Nivel 2 — Departamental. Lo usa un equipo, lee datos compartidos, no ejecuta acciones irreversibles. Requiere registro en un inventario, un propietario nombrado y una revisión anual.
Nivel 3 — Operativo. Toca datos personales, ejecuta acciones sobre clientes o dinero, o algún proceso depende de él. Requiere revisión de permisos, trazabilidad, documentación y plan de relevo. Es software en producción y se trata como tal.
La mayoría de lo que se construye cae en el nivel 1, y decirlo explícitamente es importante: una política que trate todo como nivel 3 será ignorada, y con razón.
Para clasificar cualquier flujo en cinco minutos:
El inventario es el entregable que hace posible todo lo demás, y se consigue mejor con amnistía que con auditoría:
Chiedi senza giudicare. Una comunicación que explique por qué se está haciendo y garantice que nada se apagará sin conversación previa.
Ofrecer algo a cambio. Soporte cuando se rompa, ayuda para conectarlo bien, respaldo si su autor se marcha. La gente registra lo que hizo cuando registrar tiene ventajas.
Revisar solo el nivel 3. Concentrar el esfuerzo donde está el riesgo, y dejar en paz el resto.
Crear una vía rápida. Un canal para pedir ayuda con respuesta en días. La velocidad de ese canal determina cuánto se construye fuera de control.
Hay una pregunta que ordena esto en cualquier comité: ¿cuántos procesos de la empresa dependen hoy de algo que construyó una persona sola y que nadie ha revisado?
Si nadie sabe la respuesta, ese es el proyecto. No prohibir el low-code, que resuelve problemas reales, sino saber qué hay, clasificarlo por consecuencia y proteger lo que importa.
Lo que no se puede es tener en producción software del que la organización no sabe que depende.
Cuatro obligaciones no desaparecen aunque baje la barrera técnica: los permisos, que suelen heredar la cuenta personal de quien creó el flujo; la trazabilidad, que depende de lo que registre la plataforma; la continuidad, si el conocimiento vive en una sola persona; y el cumplimiento normativo, que nadie ha evaluado.
No. Prospera porque resuelve un problema real: los departamentos tienen necesidades pequeñas y urgentes que el canal formal tarda semanas en atender. Mientras exista esa diferencia de velocidad se seguirá construyendo por fuera, así que la solución es hacer la vía formal más rápida, no cerrar la informal.
En tres niveles por consecuencia: personal, si solo afecta a quien lo creó y no toca datos sensibles; departamental, si lo usa un equipo y lee datos compartidos sin ejecutar acciones irreversibles; y operativo, si toca datos personales, mueve dinero o algún proceso depende de él.
Con qué credenciales se ejecuta, qué datos toca, si escribe en algún sistema o solo lee, qué ocurriría si dejara de funcionar mañana y quién lo mantendría si su autor no estuviera disponible.
Con amnistía en lugar de auditoría: comunicar por qué se hace y garantizar que nada se apagará sin conversación previa, ofrecer soporte y ayuda a cambio del registro, revisar en profundidad solo los flujos de nivel operativo y crear un canal de peticiones con respuesta en días.
O el flujo deja de funcionar, porque se ejecutaba con sus credenciales, o sigue funcionando con permisos que ya no deberían estar activos. Ambos desenlaces son problemáticos, y por eso los flujos de nivel operativo necesitan identidad propia, documentación y un plan de relevo.
¿Sabes de qué flujos low-code depende hoy tu operación? Levantamos el inventario, clasificamos por consecuencia y aseguramos permisos y continuidad en los que importan. Parliamone → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
