Política de privacidad
Última actualización: 5 de noviembre de 2026.
Fluyo son dos cosas distintas con dos comportamientos de datos distintos, y esta política las trata por separado porque mezclarlas sería engañoso:
| El editor — fluyo.space | El servidor MCP — mcp.fluyo.space | |
|---|---|---|
| ¿Recibe tus diagramas? | No. No salen del navegador | Sí. Viajan por red hasta el servidor |
| ¿Los guarda? | Solo en tu equipo (localStorage) |
No. Se procesan en memoria y se descartan |
| ¿Cuándo aplica? | Siempre que uses la web | Solo si conectas el servidor remoto a tu asistente de IA |
Si solo usas el editor en fluyo.space y nunca has añadido el conector MCP remoto, la sección B no te aplica en absoluto: el editor no ha enviado tus diagramas a ningún servidor. Lo único que puede sacarlos de tu equipo es lo que tú hagas con un archivo o con un enlace.
Quién es el responsable
Fluyo es un proyecto de software libre mantenido por itsnect (Claudio Jiménez Flores), con domicilio en Chile. No es una empresa constituida, no vende nada, no tiene clientes y no procesa pagos.
Contacto para cualquier asunto de privacidad: hello@fluyo.space. Más vías en la página de soporte.
A. El editor en fluyo.space
El editor es un sitio de archivos estáticos. No hay servidor de aplicación, no hay base de datos y no hay ninguna API propia a la que el navegador llame. Todo —dibujar, animar, calcular el layout y codificar el GIF— ocurre en tu equipo con el procesador de tu equipo.
Tus diagramas
Usando el editor, no salen de tu navegador. No hay backend al que puedan ir. Cuando pulsas Guardar, el navegador descarga un archivo .fluyo.json a tu disco; cuando pulsas Abrir, lo lee desde tu disco. En ninguno de los dos casos hay una petición de red.
Diagramas que llegan por un enlace
Hay un tercer camino: una URL de la forma fluyo.space/#d=… lleva el diagrama dentro del propio enlace, comprimido y codificado. Es lo que devuelve el servidor MCP para que puedas ver el diagrama animado sin guardar ningún archivo.
Ese contenido no viaja en la petición HTTP. Va detrás de la almohadilla, y el navegador no envía el fragmento de una URL: ni en la petición ni en la cabecera Referer. Puedes comprobarlo tú — sirve el proyecto en local, abre uno de estos enlaces y mira el registro de acceso: la línea muestra la ruta y nada del fragmento. Lo que sí llega al servidor es lo anterior a la almohadilla: la ruta y, si la hay, la query, como ?ejemplo= o ?lang=, que no llevan tu documento. El contenido solo llega a un servidor si se lo envías expresamente, por ejemplo al pasarle el enlace o el documento al servidor MCP.
Lo que sí conviene que sepas: el diagrama va codificado, no cifrado. Cualquiera que reciba el enlace puede leerlo. Además queda en el historial de tu navegador —que se sincroniza entre tus dispositivos si tienes esa opción activada— y en cualquier sitio por el que pases el enlace. Compártelo con el mismo criterio con el que compartirías el archivo.
Compartir una copia mediante enlace
La acción Compartir pide confirmación y genera fluyo.space/s/#d=… con una copia completa del diagrama. Cualquiera con el enlace puede verla. La copia viaja en el fragmento #d=, así que tampoco va en la petición HTTP. Fluyo no almacena esta copia en un servidor y no puede revocar el enlace. Los cambios posteriores del editor no modifican la copia. El límite de esta versión es de 64 KiB para la URL final; si se supera, puedes exportar el archivo.
Autoguardado
La sesión en curso se guarda en el localStorage de tu navegador, bajo la clave fluyo.autosave.v1. Es almacenamiento local de tu equipo, no un servidor: nadie más puede leerlo, y se borra al limpiar los datos del sitio en tu navegador.
Telemetría de producto
En el sitio público hay analítica de uso servida por Umami Cloud, sin cookies y sin identificarte por tu nombre o tu cuenta, aunque Umami deriva un identificador de sesión.
Lo que Fluyo envía es esta lista cerrada de eventos; la captura automática está desactivada y no hay pageviews:
| Evento | Significado y propiedades |
|---|---|
editor_opened | Una vez por carga del editor. entry: direct, example (llegó con ?ejemplo=) o link (llegó con #d=), sin la URL. returning: yes si este navegador ya había abierto Fluyo, no si no (ver «Primera visita»). locale: idioma de la interfaz (es, en, fr, ja, zh u other). |
first_edit_completed | Primera modificación real por carga del editor. No incluye selección, pan, zoom, navegación, importación o restauración. Sin propiedades. |
diagram_created | Primera edición que deja nodos en un documento antes vacío, como máximo una vez por carga. Sin propiedades. |
diagram_saved | Descarga explícita generada/iniciada desde Guardar; no autoguardado ni confirmación de escritura a disco. format: fluyo_json. |
diagram_exported | Archivo generado y descarga iniciada. format: gif, png, jpg o svg. No confirma escritura a disco. |
file_imported | Documento válido aplicado. source: file o link; format: fluyo_json. El origen no atribuye autoría MCP. |
present_started | Entrada efectiva al modo presentación, también sin pantalla completa. Sin propiedades. |
example_loaded | Un ejemplo publicado quedó abierto. example: identificador de la lista fija. source: url (?ejemplo=), menu (botón «Ejemplo») o entry (tarjeta de entrada). |
entry_chosen | Solo en la primera visita: qué se hizo con la tarjeta de entrada. choice: explore, blank o dismiss (Escape, tocar el lienzo o abrir otra cosa). |
story_created | Se creó una Historia en el editor. origin: new, variant («Otra forma desde aquí» o «Duplicar como fallo») o copy (duplicar). Ni su nombre ni sus frases. |
story_started | Empezó a reproducirse una Historia. surface: editor o present. trigger: user o entry (la arrancó la tarjeta de entrada). Una vez por reproducción, no por paso. |
story_completed | Esa reproducción llegó al final, viéndola o saltando de momento en momento. surface: editor o present. Una vez por reproducción. |
gif_animation_added | anim: clave de una de las ocho animaciones predefinidas. |
link_failed | reason: decode, schema, too_large o unsupported. |
share_created | Tras confirmar y crear efectivamente un enlace dentro del límite. kind: story o diagram. variants: yes si viajan sus otras formas, no si no. |
share_viewed | Después del primer render exitoso del viewer. story: yes si trae una Historia reproducible. locale: idioma de la interfaz, como arriba. |
viewer_story_started | En el viewer, al pulsar «Reproducir». Sin propiedades. |
viewer_story_completed | En el viewer, esa reproducción llegó al final. Sin propiedades. Una vez por reproducción. |
share_opened_in_editor | Al pulsar explícitamente Abrir en Fluyo en el viewer. Sin propiedades. |
Lo que Umami obtiene de la propia petición. Como cualquier servidor, Umami recibe tu dirección IP y tu User-Agent. A partir de ellos registra país, región y ciudad aproximados, navegador, sistema operativo y tipo de dispositivo, y calcula un identificador de sesión con un hash del sitio, la IP, el User-Agent y una sal que, según Umami, rota cada mes por defecto. También según Umami, la IP se procesa de forma transitoria para esos cálculos y no se guarda como campo en sus registros de analítica, aunque Umami y sus proveedores pueden anotarla en registros operativos y de seguridad, separados de la analítica. Quien administra Fluyo puede ver esos datos derivados y la secuencia de eventos de cada sesión en el panel de Umami, y los consulta para entender cómo se usa Fluyo. Fluyo no envía a Umami ningún identificador de usuario ni de cuenta, y no publica actividad por sesión. El identificador de sesión evita el uso de cookies, pero no es una garantía de anonimato absoluto.
Primera visita
La primera vez que este navegador abre el editor sin traer un documento por el enlace, una tarjeta sobre el lienzo ofrece ver un ejemplo en marcha o empezar en blanco. Para no volver a ofrecerla, el editor guarda en localStorage la clave fluyo.seen con el valor 1: sin fecha, sin identificador, y nunca se envía. Tampoco aparece si ya hay cualquier otra clave fluyo.* (sesión guardada, tema o idioma). Lo único que sale es su consecuencia, returning: yes/no en editor_opened; cuenta navegadores, no personas: en modo privado, tras borrar los datos del sitio o en otro dispositivo, cuenta como nuevo.
El contenido de tus diagramas nunca se envía a analytics. Sólo se admiten los eventos y valores de estas listas cerradas. Los eventos no llevan nombres de archivos o nodos, texto, imágenes, prompts, IDs de documentos ni datos personales. La comparación para detectar la primera edición ocurre sólo en memoria local.
No se envían URLs privadas. La captura automática del proveedor está desactivada con data-auto-track="false". Se excluyen query y fragmento con data-exclude-search y data-exclude-hash; además, el filtro data-before-send reconstruye el payload con ruta fija /, título fijo Fluyo y referrer vacío. No se envían propiedades automáticas adicionales del navegador. La carga asíncrona usa una cola acotada en memoria; bloquear Umami no impide trabajar.
El script de analítica se carga únicamente cuando el dominio es fluyo.space o www.fluyo.space. Si clonas el repositorio, lo abres en local o lo self-hosteas, ese código no llega a ejecutarse y no se hace ninguna llamada de red. Los dominios de preview quedan fuera a propósito. La condición está en js/analytics.js, en un solo bloque, para que puedas verificarlo tú.
Si quieres cero telemetría: usa el proyecto en local o self-hosteado, o bloquea el dominio cloud.umami.is. Fluyo funciona igual — la analítica está escrita para fallar en silencio.
La otra petición externa
Aparte del script de analítica de arriba, el editor hace una única petición a un tercero: carga gif.js —y su gif.worker.js— desde el CDN de cdnjs (Cloudflare), que es la librería que codifica el GIF. Es una descarga de código: no se le envía ningún contenido tuyo. Como en cualquier petición HTTP, Cloudflare ve tu IP y tu user-agent al servir el archivo. El service worker la precachea en la primera visita, así que en visitas posteriores normalmente ni siquiera se pide.
Umami sirve su script en cloud.umami.is y recibe los eventos sanitizados en gateway.umami.is. Son los únicos servicios de terceros a los que el editor llama, y esta lista sí es completa: no hay fuentes, iconos ni hojas de estilo externas. Todo lo demás se sirve desde fluyo.space.
B. El servidor MCP en mcp.fluyo.space
Esto es lo que hay que decir sin rodeos: el servidor MCP sí recibe el contenido de tus diagramas por la red. Es inevitable —no puede editar ni exportar un diagrama que no ha recibido— y es la diferencia sustancial con el editor.
Aplica solo si has añadido https://mcp.fluyo.space/mcp como conector remoto en tu asistente de IA. Si usas el servidor en local por stdio (npx fluyo-mcp), nada sale de tu equipo y esta sección tampoco te aplica.
Qué se recibe
- El documento del diagrama que tu asistente envía: nodos, etiquetas, colores, coordenadas y, si los hay, las imágenes que incrustaste como data URI.
- Los argumentos de la herramienta invocada — por ejemplo el texto de las etiquetas al crear un diagrama.
- Metadatos de red inherentes a cualquier petición HTTP: tu dirección IP (la del cliente que hace la llamada, que normalmente es el servidor de tu asistente, no tu equipo), las cabeceras y la ruta.
Cómo se usa y cuánto dura
Se procesa en memoria y se descarta. Cada petición HTTP construye un servidor nuevo, atiende el mensaje y lo tira. No hay base de datos, no hay disco, no hay caché y no hay sesiones: el servidor es stateless por diseño, no por configuración. El documento existe en la memoria del proceso el tiempo que tarda la petición —milisegundos— y desaparece con ella.
El servidor no lo guarda, no lo reenvía a otros servicios y no lo usa para entrenar nada. Como corre en Cloud Run, el documento pasa por la infraestructura de Google mientras dura la petición.
El enlace que devuelve. Junto al diagrama, las herramientas devuelven una URL fluyo.space/#d=… que lo abre en el editor. Se construye dentro del mismo proceso, con el documento que acaba de recibir: no hay petición nueva a ningún sitio, no se guarda en ninguna parte y no queda registrada. Lo que ese enlace significa para quien lo comparte está explicado arriba, en Diagramas que llegan por un enlace.
Qué se registra
Una línea por petición. Una petición correcta tiene esta forma:
{"ts":"2026-08-03T16:20:11.437Z","route":"/mcp","method":"POST",
"status":200,"outcome":"ok","durationMs":7,
"requestBytes":220,"responseBytes":472,"tools":["create_diagram"]}Cuando algo falla pueden aparecer dos campos más, y ninguno lleva contenido: toolErrors, que es cuántas herramientas devolvieron error —no cuál ni por qué—, y errorType, que es el nombre de la clase del error (TypeError, ZodError…), nunca su mensaje ni su traza. Esos nueve campos más la marca de tiempo son la estructura completa; no hay ningún otro.
Ningún dato del usuario —documento, etiquetas, argumentos de tool, mensajes de error, IP— se escribe al registro. Se anota el nombre de la herramienta invocada, nunca sus argumentos; y si algo falla, se anota que falló y de qué clase era el error, nunca el valor que lo provocó.
Esto no depende de la disciplina de quien edite el código: el tipo que describe una línea de log es una estructura cerrada, sin ningún campo donde quepa texto libre, y hay pruebas automáticas que meten marcadores irrepetibles en las etiquetas de un diagrama y fallan si aparecen en alguna línea de registro. No existe un modo debug que levante estas restricciones.
Direcciones IP y límite de peticiones
El servidor limita el número de peticiones por IP para que un endpoint abierto no se convierta en un problema de abuso o de facturación. Para eso, y solo para eso, mantiene en memoria RAM un registro con la dirección IP y las marcas de tiempo de sus peticiones recientes.
- Se conserva durante la ventana de 60 segundos del límite, y caduca sola.
- Hay un tope de 20.000 direcciones en memoria a la vez; al superarlo se descartan las más antiguas.
- Nunca se escribe a disco. Nunca se escribe al registro. Muere cuando se recicla la instancia.
- La IP se lee de la cabecera
x-forwarded-for, que reescribe la plataforma de alojamiento. - No se usa para nada más: no identifica, no perfila y no decide permisos.
Autenticación
El servidor no pide credenciales, no crea cuentas y no emite tokens. No hay nada tuyo que registrar porque no hay registro.
Dependencias que intervienen
Para el transporte HTTP no se añadió ninguna dependencia: se usa la biblioteca estándar de Node. El árbol de dependencias es el que ya arrastraba el SDK oficial de Model Context Protocol.
De todo ese árbol, los paquetes que se cargan realmente en ejecución son seis: @modelcontextprotocol/sdk, zod, @hono/node-server, ajv, ajv-formats y zod-to-json-schema. Ninguno persiste nada y ninguno hace peticiones de red salientes. Su papel se limita a enrutar el mensaje, validar su forma y convertir entre representaciones de la petición.
Una precisión honesta: @hono/node-server, que es la pieza que adapta la petición HTTP, puede escribir a la consola errores de conexión —ECONNRESET y similares, típicos de un cliente que corta a mitad—. Esos mensajes son errores de socket y no contienen datos del usuario: no llevan el documento, ni las etiquetas, ni los argumentos de ninguna herramienta.
Logs de la plataforma de alojamiento
Los dos dominios tienen proveedores distintos: fluyo.space está alojado en Vercel, y mcp.fluyo.space en Google Cloud, concretamente en Cloud Run. Cloudflare resuelve el DNS de fluyo.space, sin hacer de proxy: las peticiones HTTP a ese dominio no pasan por él.
Vercel atiende las peticiones al sitio, así que recibe tu IP, la ruta solicitada con su query, tu user-agent y otras cabeceras. Sus registros son de varios tipos, y no todos los plazos están confirmados. Según la documentación de Vercel, en el plan Hobby que usa Fluyo los runtime logs se conservan 1 hora. No hemos confirmado un plazo para sus request logs ni para sus CDN requests, ni hemos encontrado uno publicado para sus registros operativos y de seguridad. Usando el editor, el contenido de tus diagramas no le llega, tampoco el fragmento #d= de un enlace.
Como proveedor de alojamiento del servidor MCP, Google Cloud mantiene sus propios registros de plataforma en Cloud Logging, independientes de los del servidor MCP y fuera del control del código de este proyecto. En el caso de Cloud Run, la plataforma escribe un registro por petición automáticamente, antes de que la petición llegue a nuestro código. Esos registros incluyen:
- La dirección IP del cliente.
- La ruta solicitada y el método HTTP.
- El código de estado de la respuesta y su latencia.
- El user-agent y, si la petición lo trae, el
Referer.
Retención en Google Cloud: 7 días. No es el valor por omisión —Google Cloud Logging retiene 30 días por defecto—, sino uno configurado explícitamente en el bucket _Default. El comando exacto que lo fija está publicado en el README del servidor, para que esta cifra sea verificable y no una promesa.
No contienen el cuerpo de las peticiones, así que el contenido de tus diagramas no aparece en ellos.
Conviene no confundir estos registros con el de la aplicación descrito más arriba: son dos cosas distintas. El registro de la aplicación no escribe ningún dato del usuario, ni siquiera la IP, y eso seguirá siendo cierto pase lo que pase con la retención de la plataforma. Los registros de plataforma de Cloud Run sí contienen la IP, y por eso caducan a los 7 días.
Para el tratamiento que Google hace de esos datos como proveedor de infraestructura, consulta su aviso de privacidad de Google Cloud.
Con quién se comparten los datos
Fluyo no vende datos y no los usa para publicidad ni para entrenar modelos. El producto no lee los datos de analítica ni toma con ellos decisiones automatizadas sobre personas. Lo que Umami registra por sesión y quién lo consulta se describe en «Telemetría de producto».
Para funcionar, el sitio necesita proveedores de alojamiento, de distribución de recursos y de analítica. Al atender una petición reciben información que puede ser personal, como tu IP y tu User-Agent, y la tratan para prestar ese servicio y según sus propias condiciones. Esto es lo que recibe cada uno y para qué:
| Proveedor | Qué recibe | Para qué |
|---|---|---|
| Vercel | Las peticiones a fluyo.space: IP, ruta con su query, user-agent y otras cabeceras. Según Vercel, los runtime logs del plan Hobby se conservan 1 hora; el resto de plazos no están confirmados | Alojamiento y distribución de la aplicación web |
| Google Cloud | Las peticiones a mcp.fluyo.space, con el documento que envíes al servidor MCP, que se procesa en memoria. Los logs de plataforma de esas peticiones (IP, ruta, estado, user-agent) se retienen 7 días y no incluyen el cuerpo | Alojamiento y ejecución del servidor MCP |
| Umami Cloud | Los eventos de la lista de arriba (sin pageviews), más IP y User-Agent en la petición, de los que deriva ubicación aproximada, navegador, sistema operativo, dispositivo y un identificador de sesión sin cookies. Retención de los registros de analítica: 6 meses, la que Umami declara para el plan Hobby que usa Fluyo. | Analítica de uso |
| Cloudflare | En cdnjs, la petición de los archivos de gif.js: IP y user-agent. Como DNS de fluyo.space, las consultas de resolución; no las peticiones HTTP | Entrega de la librería de GIF y DNS |
| Cloudflare y Google | Solo si escribes a hello@fluyo.space: tu dirección y tu mensaje. Cloudflare los recibe y los reenvía a la cuenta de Gmail del proyecto, donde se leen y se contestan | Atender tu consulta |
En el uso normal del editor, ninguno de ellos recibe el contenido de tus diagramas. Si envías un documento al servidor MCP, llega a ese servidor en Cloud Run, como explica la sección B. Un enlace con #d= lleva el diagrama dentro: lo recibe quien lo abra y cualquier servicio por el que lo pases.
Menores
Fluyo no está dirigido a menores de 13 años y no recoge conscientemente datos de ellos. Como no hay cuentas ni registro, tampoco hay ninguna cuenta que pudiera pertenecer a un menor.
Tus derechos
La situación práctica es poco habitual y conviene decirla tal cual: no hay ninguna cuenta tuya que consultar, rectificar o borrar, porque Fluyo no te pide nombre, correo ni registro.
- Tus diagramas están en tu equipo. Para borrarlos, borra los archivos y limpia los datos del sitio en tu navegador.
- Los datos que sí existen fuera de tu equipo son los logs de plataforma, con la retención indicada arriba cuando está confirmada; los registros operativos y de seguridad que Vercel, Umami o Cloudflare puedan tener; y los registros de sesión de Umami, descritos en «Telemetría de producto». Como no están vinculados a una cuenta, normalmente no podemos localizar los tuyos.
- Aun así, si quieres ejercer cualquier derecho de acceso, rectificación, supresión, oposición o portabilidad, escribe a hello@fluyo.space y se atiende.
Verificarlo por tu cuenta
Lo que hace el código de Fluyo es comprobable: el código de las dos partes es público y con licencia MIT.
- github.com/itsnect/fluyo — el editor. La telemetría está aislada en
js/analytics.js. - github.com/itsnect/fluyo-mcp — el servidor MCP. Qué se registra y qué no está en
src/http-logging.ts; el límite por IP, ensrc/http-security.ts.
La documentación explica el mismo comportamiento desde el punto de vista de quien usa la herramienta.
Cambios en esta política
Si cambia, se actualiza la fecha del encabezado y queda constancia en el historial público del repositorio, commit a commit. Un cambio que afecte de forma sustancial a qué datos se reciben se anunciará además en el repositorio.