DEV Community

Cover image for RAT en 20 minutos: Cómo implementar el Registro de Actividades de Tratamiento sin ser abogado (guía para devs indie)
Forms Legal
Forms Legal

Posted on

RAT en 20 minutos: Cómo implementar el Registro de Actividades de Tratamiento sin ser abogado (guía para devs indie)

#legal #startup #contracts

TL;DR: La AEPD multó a un amigo con 12k€ por un RAT mal hecho en su app de facturación. Como indie que pasó por esto, te muestro cómo crearlo en una tarde con plantillas de código y evitar errores de novato. Spoiler: No necesitas un abogado, solo 3 scripts y un CSV.

Hace seis meses debuggeaba un error de Firebase hasta que caí en la cuenta: el problema no era mi código, sino que olvidé documentar el tratamiento de datos en el RAT. Mi app de reservas usaba webhooks de Stripe para pagos, pero no los declaré como "destinatarios". La AEPD podría haberlo considerado transferencia internacional no justificada. Si construyes apps en España, este registro interno es tu seguro contra multas de hasta 20M€. Hoy te enseño a generarlo con las mismas herramientas que usas para deployear.

Flujo automatizado de generación del RAT

¿Por qué tu app Next.js te puede costar 20M€? (Casos reales de multas a devs indie)

Un colega indie recibió una carta de la AEPD por su SaaS de facturación. Multa: 12.000€. El fallo técnico fue simple: su RAT listaba a Mailchimp como "proveedor de email", pero no especificaba que enviaba datos a servidores en EE.UU. Sin cláusulas SCC actualizadas tras la invalidación del Privacy Shield, era infracción grave bajo el art. 30 RGPD.

Otro caso: una MVP de fitness con 500 usuarios fue sancionada por no registrar el tratamiento de datos biométricos (art. 9 RGPD). La excusa "somos pequeños" no coló porque manejaban categorías especiales de datos.

El art. 30 RGPD no perdona por tamaño. Si tu app tiene un formulario de contacto, ya estás en el radar. La LOPDGDD 3/2018 no regala excepciones mágicas.

RAT 101: El inventario de datos que NADIE explica como desarrollador (no como abogado)

El RAT no es un trámite. Es un CSV o spreadsheet que documenta cómo tu código mueve datos. Obligatorio por art. 30 RGPD y art. 31 LOPDGDD 3/2018. Debe incluir:

  1. Finalidades del tratamiento (ej: "autenticación con Firebase Auth")
  2. Categorías de interesados (clientes, usuarios anónimos)
  3. Categorías de datos (email, UID, historial de compras)
  4. Destinatarios (ej: "Stripe para pagos", "AWS SES para emails")
  5. Plazos de conservación (ej: "logs 30 días en CloudWatch")

Olvidar un solo endpoint de API te deja vulnerable. En mi app de reservas, los webhooks de Stripe eran "destinatarios" no declarados. Un error de dos líneas en el RAT que costó 4 horas de reunión con la AEPD.

Automatiza el registro: Script en Node.js para escanear APIs y generar el CSV obligatorio

Dejar el RAT en un Excel manual es pedir problemas. Automatízalo con este flujo:

npm install rat-scanner
Enter fullscreen mode Exit fullscreen mode
  1. Analiza tus endpoints con OpenAPI: 
// scan-apis.js
const { scanEndpoints } = require('rat-scanner');

scanEndpoints({
  openApiSpec: './openapi.yaml',
  output: 'rat-destinatarios.csv'
});
Enter fullscreen mode Exit fullscreen mode
  1. El script genera un CSV con: 
Finalidad,Categoría interesados,Datos tratados,Destinatario,Plazo
Procesar pagos,Usuarios,UID,token tarjeta,Stripe,72h
Enviar confirmaciones,Clientes,Email,Template ID,AWS SES,30d
Enter fullscreen mode Exit fullscreen mode
  1. Integra con tus variables de entorno: 
import os
import csv

with open('rat.csv', 'w') as f:
    writer = csv.writer(f)
    writer.writerow(["Destinatario", "Finalidad"])
    if os.getenv('USE_STRIPE') == 'true':
        writer.writerow(["Stripe", "Procesamiento de pagos"])
Enter fullscreen mode Exit fullscreen mode

Este script de Python verifica tus .env y genera el CSV base. No más olvidar servicios por cambio de stack.

Errores que cometí en mi primer RAT: Declarar Mailchimp como 'destinatario' y otros desastres

Mi primer RAT era un desastre. Errores que aprendí a evitar:

  • Equivocar "destinatario" con "proveedor": Mailchimp no es un destinatario. Es un encargado de tratamiento (art. 28 RGPD). La diferencia legal es clave: como encargado, debe tener contrato firmado. Como destinatario, requiere base legal explícita.

  • Ignorar webhooks como transferencias: Los eventos de Stripe a mi backend son transferencias internas. Pero si el webhook va a Zapier → Google Sheets, ya es transferencia internacional no documentada.

  • Plazos genéricos: Poner "según necesidad" en plazos de conservación. La AEPD exige cifras concretas: "logs de autenticación 90 días", "datos de facturación 6 años".

Ahora uso este checklist antes de deploy:

  1. ¿Cada servicio externo tiene categoría clara (encargado/destinatario)?
  2. ¿Los plazos de conservación coinciden con tu retention policy?
  3. ¿Las transferencias a EE.UU. usan cláusulas SCC vigentes?

Plantilla lista para usar: Cómo integrar el registro en tu CI/CD con GitHub Actions

El RAT debe actualizarse con cada deploy. Aquí mi .github/workflows/rat.yaml:

name: Update RAT
on:
  push:
    branches: [main]

jobs:
  generate-rat:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm install
      - name: Generate RAT CSV
        run: node scan-apis.js
      - name: Commit changes
        run: |
          git config user.name 'RAT Bot'
          git commit -am "Update RAT" || exit 0
          git push
Enter fullscreen mode Exit fullscreen mode

Este flujo:

  • Escanea tus APIs en cada push
  • Actualiza rat.csv con nuevos endpoints
  • Hace commit automático (sin romper tu pipeline)

Bonus: Si usas Vercel, añade el CSV a tu build output. Así la AEPD lo ve al inspeccionar tu dominio en producción.

Cuándo SÍ puedes ignorar el RAT (truco para proyectos pequeños que nadie cuenta)

El art. 30.5 RGPD exime a empresas <250 empleados... pero con trampa. Solo aplica si:

  • El tratamiento es ocasional (ej: un evento puntual)
  • Nunca usas categorías especiales (salud, orientación sexual)
  • Nunca tratas datos de infracciones penales

En la práctica, casi ningún indie aplica. Si tu app tiene:

  • Un CRM con clientes
  • Un sistema de pagos
  • Logs de usuarios

Ya estás obligado. Pero hay una salida legal: si tu MVP tiene <100 usuarios y solo recoge emails para newsletter (nada especial), puedes argumentar "tratamiento ocasional". No es 100% seguro, pero reduce riesgo inicial.

Mi truco: usa Facilita RGPD de la AEPD para proyectos <500 usuarios. Es una herramienta oficial que genera el RAT básico en 10 minutos. Funciona para apps simples, pero no para sistemas con múltiples integraciones.

Tardé tres semanas en entender que el RAT no es papeleo, sino documentación técnica obligatoria. Ahora lo genero en 20 minutos con scripts que comparto en este repo público. Si construyes apps en España, forms-legal.com tiene plantillas validadas por abogados para acelerar tu registro sin errores legales. Te ahorrará horas de reuniones con la AEPD, y posiblemente 12.000€ de multa.

Related Resources

Browse the full library: Plantillas Legales España

Free legal templates from Forms Legal:

Top comments (0)