Hay algo que muchas empresas todavía no han entendido: implementar automatizaciones con Make, Zapier o n8n no es solo una decisión de productividad, también es una decisión de riesgo. Estas plataformas permiten mover información entre CRM, ERPs, hojas de cálculo, correos, formularios, bases de datos y herramientas internas a gran velocidad. Y precisamente por eso, cuando se usan sin reglas claras, pueden multiplicar copias de datos, abrir accesos innecesarios, dejar trazas completas en historiales técnicos y exponer información sensible fuera del perímetro de control de la compañía. El problema no es automatizar. El problema es automatizar sin gobernanza.

La propia arquitectura de estas herramientas ya nos da una pista del riesgo. Make organiza escenarios, conexiones, webhooks, data stores y otros activos dentro de organizaciones y equipos; Zapier permite compartir Zaps, carpetas y cuentas conectadas en entornos Team y Enterprise; y n8n agrupa workflows y credenciales mediante proyectos y roles. Traducido al lenguaje de negocio: cuando automatizas no solo mueves datos, también repartes permisos, visibilidad y capacidad de actuación sobre sistemas críticos. Si eso no está definido desde el diseño, la automatización deja de ser una ventaja y se convierte en superficie de exposición.

El primer gran peligro: la proliferación silenciosa de datos

Un dato que antes existía en un único sistema pasa a viajar por varios a la vez. Sale del formulario, entra en el CRM, aterriza en una hoja de cálculo, se envía por email, se publica en un canal interno y además queda reflejado en el historial de ejecución. Make permite inspeccionar salidas de módulos y buscar texto dentro de los outputs del historial; Zapier registra el historial de ejecuciones y permite exportarlo; y n8n permite configurar qué datos de ejecución se guardan, lo que demuestra que esa persistencia existe y debe gobernarse explícitamente. Cuando una empresa no limita qué campos circulan por cada flujo, la automatización se convierte en una maquinaria de replicación de datos sensibles. Eso choca de frente con los principios de minimización, limitación de finalidad y limitación del plazo de conservación.

El segundo gran peligro: permisos excesivos y acceso lateral

Aquí está una de las amenazas más graves. En Make, la documentación indica que todos los usuarios del equipo pueden usar y gestionar cualquier conexión creada en ese equipo, y además los roles de team admin y team member tienen acceso completo a todos los datos del equipo. En Zapier, incluso cuando una app está restringida, los miembros todavía pueden conectar cuentas y utilizar triggers y acciones para cargar o crear registros de prueba; la limitación afecta a publicar y ejecutar, no a toda la fase de preparación. En n8n, el acceso a workflows y credenciales depende de proyectos y roles, pero ese modelo no está disponible igual en todas las ediciones. El resultado es obvio: una sola conexión mal planteada, una cuenta OAuth sobredimensionada o una credencial compartida puede abrir acceso lateral a correo, calendarios, almacenamiento, CRM y bases de datos completas.

El tercer gran peligro: pensar que los logs “no cuentan”

Sí cuentan. Y mucho. Un flujo de RRHH puede dejar en un historial nombres, teléfonos, CV, salario esperado o documentos adjuntos. Un flujo comercial puede exponer importes, notas del vendedor, emails y estado de negociación en una ejecución fallida. Una exportación de historial transforma esa traza técnica en un archivo reutilizable fuera de la plataforma. Make permite exportar historial y buscar texto completo en outputs; Zapier mantiene histórico de ejecuciones y también permite exportarlo; n8n incluso dispone de funciones para guardar metadata de ejecuciones y recuperarla después. Lo que muchas empresas tratan como simple “troubleshooting” puede acabar funcionando como una base de datos paralela de información sensible. Ese es un peligro real, directo y muy infravalorado.

Un ejemplo muy común, y muy peligroso

Imaginemos un flujo aparentemente inocente: formulario web → CRM → Google Sheets → Slack → email de bienvenida. Para “ir rápidos”, el equipo envía todos los campos del formulario: nombre, móvil, empresa, cargo, presupuesto, notas internas y documentos adjuntos. En ese momento, el dato ya no está en un único sitio: circula por varios sistemas, varias credenciales, varios historiales y potencialmente varias cuentas compartidas. Después llega la pregunta incómoda: ¿dónde está exactamente ese dato?, ¿quién lo ha visto?, ¿cuánto tiempo lleva almacenado?, ¿cómo se borra de todos los puntos de paso? Cuando una empresa no puede responder a eso, no tiene automatización madura; tiene descontrol automatizado.

El cuarto gran peligro: el shadow IT elegante

Estas plataformas son tan fáciles de implantar que muchas automatizaciones nacen fuera del radar de TI, seguridad o legal. Make permite que cualquier usuario cree su propia organización y elija la región del centro de datos, y además esa localización no puede cambiarse después de crearla. Zapier concentra distintos controles de privacidad y gobierno en planes Team y Enterprise, como roles, restricciones de apps y retención configurable. n8n permite más control fino mediante proyectos y RBAC, pero no todas las capacidades están presentes en Community. Esto provoca una situación muy delicada: dos departamentos pueden estar automatizando el mismo tipo de dato con reglas distintas, permisos distintos, ubicaciones distintas y periodos de conservación distintos, sin una política corporativa común. Eso no es agilidad. Eso es fragmentación del control.

El quinto gran peligro: la falsa sensación de seguridad contractual

Que un proveedor hable de GDPR, SOC 2, cifrado, DPA o cláusulas contractuales tipo no resuelve por sí solo tu problema. Make publica documentación sobre GDPR, DPA y SCC; Zapier ofrece Trust Center, SOC 2 Type II y documentación de seguridad; n8n explica sus medidas de privacidad y seguridad e incorpora DPA para cloud. Todo eso es importante, sí. Pero nada de eso decide por ti qué datos deben circular, con qué cuentas, con qué permisos, durante cuánto tiempo y quién puede revisarlos. La gobernanza no la hace el logo del proveedor ni su página de compliance. La gobernanza la hace tu organización con criterios, límites y controles internos.

Con n8n aparece además un riesgo muy particular

Mucha gente piensa: “si lo autoalojamos, ya está resuelto”. Y no. La propia documentación de n8n para self-hosted deja claro que el cliente debe encargarse del TLS en tránsito, del cifrado en reposo, de ejecutar auditorías de seguridad, de vigilar los riesgos de los community nodes y de limitar ciertas capacidades del Code node. También indica que las credenciales se cifran con una clave que debe gestionarse correctamente, y que en determinados despliegues esa clave debe estar presente en todos los workers. La conclusión es evidente: al pasar a self-hosted, una parte del riesgo sale del SaaS, pero entra de lleno en tu equipo de infraestructura y seguridad. Si no tienes madurez técnica, puedes quedar más expuesto, no menos.

Pensemos en otro caso. Una empresa decide usar n8n para procesos financieros porque “así los datos no salen de casa”. Pero nadie configura bien TLS, nadie revisa qué ejecuciones guardan payloads sensibles, nadie corre el security audit y nadie restringe nodos o capacidades peligrosas. El riesgo ya no está en el proveedor externo; está dentro de la propia operación. Y ese riesgo es más difícil de detectar, porque se confunde con autonomía técnica.

Hay un detalle más incómodo todavía

En la práctica, parte de la gobernanza depende del plan contratado y de cómo se configure la plataforma. En Make, por debajo de Teams solo hay un equipo y no se pueden gestionar roles dentro de ese único equipo. En n8n, RBAC no está disponible en Community. En Zapier, varias capacidades de control y privacidad viven en Team y Enterprise. Eso significa que muchas empresas pretenden controlar datos críticos con configuraciones pensadas para empezar rápido, no para gobernar fino. Y ahí es donde el riesgo crece de verdad: cuando la complejidad del dato es empresarial, pero el modelo de control sigue siendo casi artesanal.

La conclusión que muchas empresas no quieren escuchar

Adoptar Make, Zapier o n8n sin gobernanza de datos expone a la empresa a cinco peligros muy serios: logs e historiales con información sensible, permisos excesivos mediante conexiones y cuentas compartidas, replicación incontrolada de datos entre sistemas, problemas de residencia, retención y finalidad, y shadow IT que saca la automatización del control corporativo. No son riesgos teóricos. Son riesgos cotidianos, silenciosos y acumulativos. Y cuanto mejor funciona la automatización, más invisibles se vuelven.

Automatizar sin gobernanza no es innovar; es amplificar el desorden a velocidad de máquina. Make, Zapier y n8n pueden aportar un enorme valor, pero solo cuando se implantan con inventario de flujos, clasificación de datos, cuentas de servicio separadas, mínimo privilegio, políticas de retención, revisión de logs, control de cambios y supervisión real de quién automatiza qué. Todo lo demás es jugar con información crítica de la empresa y con datos personales de clientes, empleados y proveedores como si fueran piezas sin consecuencias.

Toni Domenech