Qué se envía al servidor cuando publicas: flujo de datos y privacidad en un SaaS de Markdown

Si un producto pide al usuario que suba contenido, la pregunta "¿qué pasa con mis documentos?" no puede responderse con vaguedades. La arquitectura debe poder explicarse en una tabla, en un diagrama y en una promesa escrita.

Important

La promesa de privacidad no es copy legal. Es un contrato técnico: qué datos entran, quién los procesa, cuánto tiempo viven y cómo se borran.

La promesa en lenguaje claro

Promesa	Implicación técnica
El contenido se usa sólo para publicar	No se reutiliza para entrenamiento, analytics de texto ni datasets internos
Va cifrado en tránsito y reposo	TLS obligatorio y almacenamiento cifrado
Puedes descargarlo	Export completo en Markdown y assets originales
Puedes borrarlo	Borrado físico de contenido y backups dentro de ventana definida
El servidor no recibe tu workspace entero	El payload se limita al sitio que eliges publicar

Note

Si el producto no puede sostener esta tabla técnicamente, la política de privacidad tampoco debería prometerla.

Flujo de publicación

sequenceDiagram participant U as Usuario participant PS as Servicio de publicación participant Auth as Servicio de identidad participant Lic as Servicio de licencias participant RS as Servicio de render participant Storage as Object storage participant Edge as Hosting estático U->>PS: Publicar sitio (token + contenido seleccionado) PS->>Auth: Verificar identidad y scopes Auth-->>PS: Usuario autorizado PS->>Lic: Validar plan, cuotas y features Lic-->>PS: Entitlement OK PS->>RS: Renderizar Markdown a HTML RS-->>PS: HTML seguro PS->>PS: Aplicar tema y brand tokens PS->>Storage: Subir assets PS->>Edge: Subir bundle estático Edge-->>PS: ID de despliegue + URL PS->>PS: Registrar audit log PS-->>U: URL publicada

Qué viaja al servidor

Dato	Por qué viaja	Quién lo usa	Retención
Markdown del sitio	Convertir páginas a HTML	Servicio de publicación y de render	Versiones según plan
Config del sitio	Dominio, navegación, locales y tema	Servicio de publicación	Mientras exista el sitio
Brand tokens	Logo, colores, fuente y favicon	Servicio de publicación	Mientras exista el sitio
Assets referenciados	Imágenes y archivos públicos del sitio	Object storage / bundle estático	Mientras exista el sitio
Token de identidad	Verificar identidad y scope	Servicio de identidad	No se almacena como contenido
Contexto de licencia	Validar plan y cuotas	Servicio de licencias	Según política de billing/auditoría

Qué no viaja

Fuera del payload

Workspace local completo.
Repos que no forman parte del sitio.
Historial local de edición.
Configuración local del editor.
Archivos personales fuera del repo publicado.

Nunca debería viajar

Claves privadas.
API keys de proveedores.
Credenciales Git locales.
Tokens personales.
Secretos usados por otros proyectos.

Warning

"Publicar un sitio" no puede significar "subir mi máquina". El contrato debe ser explícito: sólo se envía lo seleccionado para ese sitio.

Responsabilidad por servicio

flowchart TD user["Usuario"] --> payload["Payload de publicación"] payload --> publish["Servicio de publicación<br/>orquesta y audita"] publish --> auth["Servicio de identidad"] publish --> license["Servicio de licencias"] publish --> render["Servicio de render"] publish --> storage["Object storage<br/>assets y versiones"] publish --> pages["Hosting estático<br/>sitio publicado"]

Servicio	Debe poder hacer	No debe hacer
Servicio de publicación	Orquestar publish, aplicar tema, auditar	Entrenar modelos con contenido
Servicio de identidad	Verificar identidad y scopes	Leer Markdown
Servicio de licencias	Decidir cuotas y features	Recibir contenido del sitio
Servicio de render	Convertir Markdown a HTML seguro	Guardar contenido indefinidamente
Object storage	Guardar assets y versiones necesarias	Exponer assets privados sin política
Hosting estático	Servir bundle publicado	Conocer secretos del usuario

Por qué no se hace todo en local

Hay una alternativa local y tiene sentido, pero no resuelve el caso SaaS completo.

Necesidad	Local	SaaS
Exportar ZIP estático	Sí	Sí
Publicar con dominio propio gestionado	Manual	Automatizado
Enforce de plan y cuotas	No autoritativo	Autoritativo
Temas premium protegidos	Difícil	Sí
Audit log y rollback	Manual	Centralizado
Deploy sin tokens del usuario	No aplica	Sí

Tip

El modo privado correcto es exportar ZIP y desplegarlo tú. El SaaS existe para automatizar deploy, dominios, cuotas, temas y rollback.

Arquitectura de borrado

El borrado debe ser un flujo, no un flag.

flowchart LR request["Solicitud de borrado"] --> auth["Verificar propietario"] auth --> live["Eliminar sitio publicado"] live --> store["Eliminar assets/versiones en object storage"] store --> audit["Registrar evento de borrado"] audit --> backups["Propagar a backups<br/>ventana máxima 30 días"] backups --> done["Confirmación"]

Checklist mínimo de privacidad operativa

TLS obligatorio en todos los endpoints.
Cifrado en reposo para contenido y assets.
Versiones retenidas según plan, no indefinidamente por defecto.
Borrado físico del object storage al solicitar eliminación.
Ventana documentada para backups.
Audit log de publicaciones, cambios y borrados.
Acceso humano al contenido sólo con autorización explícita de soporte.
Política escrita que coincida con la arquitectura real.

Riesgos y controles

Riesgo	Control
Subir más contenido del necesario	Selector explícito de sitio y preview del payload
Exponer secretos por accidente	Lista de exclusión, validación y avisos antes de publicar
Saltarse cuotas desde cliente	Validación autoritativa en servicio de licencias
Tema premium filtrado al cliente Free	Render y bundle server-side por plan
Retener contenido borrado	Flujo de borrado con evento y ventana de backups
Soporte accediendo a contenido	Acceso temporal, autorizado y auditado

Lo que me hace confiar en el diseño

Minimización

Sólo viaja lo que el sitio necesita para publicarse.

Separación

Identidad y licencias no leen contenido; render no decide cuotas.

Reversibilidad

El usuario puede descargar, exportar ZIP o borrar el sitio.

La regla que me llevo

Un SaaS que recibe contenido del usuario necesita una promesa escrita y una arquitectura que la sostenga. Si una falla, la otra no salva la confianza.

Este artículo forma parte de mis notas sobre datos y privacidad en SaaS. Si te interesa el tema, sigue el blog o escríbeme.