Política de privacidad

Última actualización: 26 de agosto 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.spaceEl 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: ningún diagrama tuyo ha salido nunca de tu navegador.

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: nectdnb@gmail.com. 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

No se envían a ninguna parte. 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 tampoco llega a ningún servidor. 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 dice GET /index.html y nada más.

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. 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 agregada, servida por Umami Cloud. Sin cookies y sin fingerprinting, y sin identificar usuarios.

Lo que se registra es esta lista cerrada de eventos; la captura automática está desactivada:

EventoSignificado y propiedades
editor_openedUna vez por carga del editor. Sin propiedades.
first_edit_completedPrimera modificación real por carga del editor. No incluye selección, pan, zoom, navegación, importación o restauración. Sin propiedades.
diagram_createdPrimera edición que deja nodos en un documento antes vacío, como máximo una vez por carga. Sin propiedades.
diagram_savedDescarga explícita generada/iniciada desde Guardar; no autoguardado ni confirmación de escritura a disco. format: fluyo_json.
diagram_exportedArchivo generado y descarga iniciada. format: gif, png, jpg o svg. No confirma escritura a disco.
file_importedDocumento válido aplicado. source: file o link; format: fluyo_json. El origen no atribuye autoría MCP.
present_startedEntrada efectiva al modo presentación, también sin pantalla completa. Sin propiedades. No se mide presentación completada.
example_loadedexample: identificador de un ejemplo de la lista fija.
gif_animation_addedanim: clave de una de las ocho animaciones predefinidas.
link_failedreason: decode, schema, too_large o unsupported.
share_createdTras confirmar y crear efectivamente un enlace dentro del límite. Sin propiedades.
share_viewedDespués del primer render exitoso del viewer. Sin propiedades.
share_opened_in_editorAl pulsar explícitamente Abrir en Fluyo en el viewer. Sin propiedades.

El contenido de tus diagramas nunca se envía a analytics. Sólo se admiten los eventos y valores de estas listas cerradas. No se envían 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 nada 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

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.

Nada se persiste. Nada se comparte. Nada se usa para entrenar nada.

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.

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 —fluyo.space y mcp.fluyo.space— están alojados en Google Cloud, en servicios separados de la misma cuenta. El servidor MCP corre concretamente en Cloud Run.

Como cualquier proveedor de alojamiento, 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:

Retención: 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 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

Con nadie. No se venden, no se ceden, no se usan para publicidad y no se usan para entrenar modelos. No hay perfilado ni decisiones automatizadas sobre personas.

Los únicos terceros que intervienen son proveedores de infraestructura, cada uno con su propio papel acotado:

ProveedorQué vePor qué
Google CloudLogs de plataforma de los dos dominios (IP, ruta, estado, user-agent), retenidos 7 díasAlojamiento
Umami CloudPageviews y los eventos de la lista de arriba, sin cookies ni identificadoresAnalítica del editor
Cloudflare (cdnjs)La petición del archivo gif.js: IP y user-agentEntrega de la librería de GIF

Ninguno de los tres recibe el contenido de tus diagramas.

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 ningún perfil 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, ningún perfil y ningún registro tuyo que consultar, rectificar o borrar, porque no se guarda nada que te identifique.

Verificarlo por tu cuenta

Todo lo anterior es comprobable: el código de las dos partes es público y con licencia MIT.

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.