Privacidad por diseño: una guía práctica para equipos de desarrollo de software

La privacidad por diseño no es una sugerencia, es un requisito legal según el artículo 25 del RGPD. Las organizaciones deben implementar "medidas técnicas y organizativas apropiadas" para garantizar que los principios de protección de datos se integren en el procesamiento en sí. Yet most development teams treat privacy as an afterthought, bolting on consent forms and cookie banners after the architecture is set.

Esta guía traduce los siete principios fundamentales de Privacidad por diseño en prácticas de ingeniería, patrones de diseño e implementaciones a nivel de código procesables.

Conclusiones clave

• Privacidad por diseño significa incorporar la privacidad en las decisiones arquitectónicas, no agregarla como característica más adelante
• La minimización de datos a nivel de esquema evita la recopilación excesiva desde el principio.
• La seudonimización y el cifrado proporcionan una defensa profunda cuando se producen infracciones
• Los análisis que preservan la privacidad pueden brindar información empresarial sin exponer los datos de los usuarios individuales.

---

Los siete principios aplicados al software

1. Proactivo, no reactivo

Cree controles de privacidad antes de recopilar datos, no después de una infracción.

En la práctica:

• Incluir requisitos de privacidad en los criterios de aceptación de historias de usuario.
• Ejecutar un modelo de amenazas a la privacidad durante las revisiones de arquitectura.
• Cree una lista de verificación de privacidad para cada solicitud de extracción que afecte los datos del usuario.

2. Privacidad como configuración predeterminada

Los usuarios no deberían necesitar tomar medidas para proteger su privacidad.

En la práctica:

• Las nuevas cuentas de usuario comparten de forma predeterminada un mínimo de datos.
• El seguimiento analítico es de participación voluntaria, no de exclusión voluntaria.
• La visibilidad del perfil por defecto es privada
• La retención de datos se establece por defecto en el período mínimo requerido.

// Default privacy settings for new users
const DEFAULT_PRIVACY_SETTINGS = {
  profileVisibility: 'private',       // Not 'public'
  analyticsTracking: false,           // Opt-in required
  marketingEmails: false,             // Opt-in required
  dataSharing: false,                 // Opt-in required
  activityLog: true,                  // Security feature, on by default
  twoFactorAuth: true,               // Security feature, on by default
};

3. Privacidad integrada en el diseño

La privacidad es un componente central del sistema, no un complemento.

Diseño de esquema de base de datos:

-- Privacy-aware schema design
CREATE TABLE users (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    -- Separate PII from operational data
    email VARCHAR(255) NOT NULL,          -- PII
    email_hash VARCHAR(64) NOT NULL,      -- For lookups without exposing email
    name_encrypted BYTEA,                 -- Encrypted at rest
    -- Operational fields (non-PII)
    role VARCHAR(50) NOT NULL DEFAULT 'user',
    created_at TIMESTAMP DEFAULT NOW(),
    -- Privacy metadata
    consent_timestamp TIMESTAMP,
    consent_version VARCHAR(20),
    data_retention_until TIMESTAMP,
    deletion_requested_at TIMESTAMP
);

-- Separate sensitive data into its own table with stricter access
CREATE TABLE user_pii (
    user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
    phone_encrypted BYTEA,
    address_encrypted BYTEA,
    date_of_birth_encrypted BYTEA,
    -- Audit trail
    last_accessed_at TIMESTAMP,
    last_accessed_by UUID
);

4. Funcionalidad completa (suma positiva)

La privacidad no debe ir en detrimento de la funcionalidad. Diseñar sistemas que ofrezcan ambas cosas.

Ejemplo: en lugar de elegir entre personalización y privacidad, utilice una personalización que preserve la privacidad:

• Aprendizaje federado: modelos de aprendizaje automático entrenados con datos locales, solo se comparten resultados agregados
• Privacidad diferencial: agregue ruido a los análisis para evitar la identificación individual
• Procesamiento en el dispositivo: recomendaciones calculadas en el dispositivo del usuario, no en el servidor.

5. Seguridad de extremo a extremo

Proteger los datos durante todo su ciclo de vida.

6. Visibilidad y Transparencia

Los usuarios deben comprender qué sucede con sus datos.

Implementación:

// Privacy dashboard API endpoint
@Controller('privacy')
export class PrivacyController {
  @Get('my-data')
  @ApiOperation({ summary: 'Get all personal data (GDPR Art. 15)' })
  async getMyData(@Req() req: AuthenticatedRequest) {
    return {
      profile: await this.userService.getProfile(req.user.sub),
      orders: await this.orderService.getUserOrders(req.user.sub),
      supportTickets: await this.supportService.getUserTickets(req.user.sub),
      loginHistory: await this.authService.getLoginHistory(req.user.sub),
      consentRecords: await this.consentService.getUserConsents(req.user.sub),
      dataProcessors: this.getDataProcessorList(),
    };
  }

  @Post('export')
  @ApiOperation({ summary: 'Export personal data (GDPR Art. 20)' })
  async exportMyData(@Req() req: AuthenticatedRequest) {
    // Generate machine-readable export (JSON)
    return this.privacyService.generateDataExport(req.user.sub);
  }

  @Post('delete')
  @ApiOperation({ summary: 'Request data deletion (GDPR Art. 17)' })
  async requestDeletion(@Req() req: AuthenticatedRequest) {
    return this.privacyService.initiateDataDeletion(req.user.sub);
  }
}

7. Respeto a la Privacidad del Usuario

Mantenga al usuario en el centro de cada decisión de diseño.

---

Patrones arquitectónicos que preservan la privacidad

Patrón 1: Separación de datos

Separe la información de identificación personal de los datos operativos:

[Frontend] --> [API Gateway] --> [Application Service]
                                       |
                      +----------------+----------------+
                      |                                 |
              [Operational DB]                    [PII Vault]
              (Orders, products,                  (Names, emails,
               analytics - by ID)                  addresses - encrypted)

Patrón 2: Procesamiento basado en el consentimiento

// Consent middleware
async function requireConsent(purpose: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const consent = await consentService.check(req.user.id, purpose);
    if (!consent.granted) {
      throw new ForbiddenException(
        `Processing for "${purpose}" requires user consent`
      );
    }
    next();
  };
}

// Usage
@Get('recommendations')
@UseGuards(requireConsent('personalization'))
async getRecommendations(@Req() req: AuthenticatedRequest) {
  return this.recommendationService.getForUser(req.user.sub);
}

Patrón 3: Caducidad automática de datos

// TTL-based data retention
const RETENTION_POLICIES = {
  supportTickets: { days: 1095, action: 'anonymize' },    // 3 years
  recruitmentData: { days: 730, action: 'delete' },        // 2 years
  analyticsEvents: { days: 365, action: 'aggregate' },     // 1 year
  sessionLogs: { days: 90, action: 'delete' },             // 90 days
  tempUploads: { days: 7, action: 'delete' },              // 7 days
};

---

Privacidad en integraciones de terceros

Cada integración de terceros es un riesgo potencial para la privacidad. Cuando su aplicación envía datos de usuario a un servicio externo, usted se hace responsable de cómo ese servicio los maneja.

Evaluación de privacidad de integración

Antes de integrar cualquier servicio de terceros que procese datos de usuarios:

Riesgos comunes de privacidad de integración

Análisis: Google Analytics, Mixpanel y servicios similares reciben datos del comportamiento del usuario. Utilice análisis del lado del servidor o alternativas sin cookies (Plausible, Fathom) para minimizar la exposición de los datos.

Procesamiento de pagos: Stripe, PayPal y servicios similares procesan datos financieros. Utilice sus formularios de pago alojados (Stripe Elements) para evitar la expansión del alcance de PCI-DSS. Nunca registre números completos de tarjetas de crédito.

Servicios de correo electrónico: SendGrid, Mailgun y servicios similares procesan direcciones de correo electrónico y contenido de mensajes. Asegúrese de que el proveedor de servicios de correo electrónico tenga un DPA firmado y no utilice los datos de su destinatario para publicidad.

Atención al cliente: Zendesk, Intercom y servicios similares almacenan conversaciones de clientes que pueden contener PII. Configure la retención de datos en la plataforma de soporte y asegúrese de que el DPA cubra todos los tipos de datos.

---

Lista de verificación del desarrollador

Para cada función que afecta a los datos del usuario

• ¿Qué datos personales recopila esta función? (Documéntelo)
• ¿Cuál es la base legal para el cobro? (Consentimiento, contrato, interés legítimo)
• ¿Son estos los datos mínimos necesarios? (Minimización de datos)
• ¿Cuánto tiempo lo conservaremos? (Política de retención)
• ¿Quién tiene acceso? (Mínimo privilegio)
• [] ¿Está cifrado en reposo y en tránsito? (Seguridad)
• ¿Puede el usuario acceder, exportar y eliminar sus datos? (Derechos)
• ¿Se registra con fines de auditoría? (Responsabilidad)
• ¿Traspasa fronteras? (Mecanismos de transferencia)
• ¿Se ha realizado una EIPD si el riesgo es alto? (Evaluación)

---

Preguntas frecuentes

¿La privacidad por diseño es solo para el RGPD?

No. Si bien el RGPD lo convierte en un requisito legal (Artículo 25), la Privacidad por diseño es una mejor práctica reconocida a nivel mundial. La CPRA de California, la LGPD de Brasil y el DPDP de la India incluyen requisitos similares para incorporar la privacidad en el diseño del sistema. La implementación de Privacidad por diseño para el cumplimiento del RGPD satisface automáticamente los requisitos de la mayoría de las demás jurisdicciones.

¿Cómo adaptamos la privacidad a una aplicación existente?

Priorice: (1) Audite qué datos personales tiene y dónde se encuentran, (2) Implemente flujos de trabajo de solicitud de datos (acceso, eliminación, exportación), (3) Agregue cifrado para datos confidenciales en reposo, (4) Implemente políticas de retención y eliminación automática, (5) Agregue administración de consentimiento cuando falte. Esto no es ideal, pero aborda primero las brechas de mayor riesgo.

Does Privacy by Design mean we cannot use analytics?

No. Significa utilizar la analítica de forma responsable. Datos agregados en lugar de seguimiento individual. Utilice análisis sin cookies (Plausible, Fathom) para las métricas del sitio web. Para análisis de productos, recopile eventos sin PII ni seudonimice identificadores. Para las pruebas A/B, utilice la asignación del lado del servidor sin cookies de seguimiento del lado del cliente. La privacidad y el análisis son compatibles con un diseño bien pensado.

¿Cómo implementamos la Privacidad por Diseño en Odoo?

Odoo proporciona varias funciones de privacidad integradas: grupos de acceso de usuarios (control de acceso por módulo), registro de auditoría (charla en registros) y archivo de datos. Mejórelos con: campos personalizados cifrados para datos confidenciales, reglas de retención automatizadas mediante acciones programadas, funcionalidad de exportación de datos GDPR mediante informes personalizados y seguimiento de consentimiento en registros de contactos. Los servicios de personalización de Odoo de ECOSIRE incluyen la implementación de privacidad por diseño.

---

¿Qué viene después?

La privacidad por diseño es la disciplina de la ingeniería. Combínelo con políticas de retención de datos para la gestión del ciclo de vida, implementación del consentimiento de cookies para propiedades web y privacidad de datos de los empleados para sistemas internos.

Comuníquese con ECOSIRE para obtener consultoría sobre privacidad por diseño y revisión de la arquitectura de software.

---

Publicado por ECOSIRE: ayuda a las empresas a incorporar privacidad en cada línea de código.