7. Privacy by Design en Sistemas AI

Descripción de la cápsula

Privacy by Design (Cavoukian, 2009) es el framework para integrar privacidad desde el diseño, no como parche post-deployment.

Tiene 7 principios:

1. Proactive not Reactive — anticipar issues, no responder.
2. Privacy as the Default Setting — privado sin configuration.
3. Privacy Embedded into Design — integral, no añadido.
4. Full Functionality — privacy + functionality, no zero-sum.
5. End-to-End Security — protección durante todo el lifecycle.
6. Visibility and Transparency — stakeholders entienden.
7. Respect for User Privacy — usuario al centro.

Esta cápsula cubre cada uno aplicado a sistemas AI específicamente, traduciendo principios a decisiones concretas de arquitectura.

GDPR Art 25 hace Privacy by Design obligación legal. Por eso cubrir estos principios es prerequisito para módulos regulatorios (M5 GDPR).

Principio 1: Proactive not Reactive

El concepto

Anticipar privacy issues antes que ocurran, no responder después.

Aplicación a AI

Reactive (default mode):

• Deploy AI system.
• Privacy issue surface.
• Patch issue.
• Repeat.

Proactive:

• Identify privacy risks during design.
• Apply Ethics Impact Analysis (M1) before code.
• Apply Privacy Assessment before code.
• Build mitigations into architecture.

Concrete actions

## Pre-design checklist

- [ ] Ethics Impact Analysis completed (M1/08)
- [ ] Privacy Assessment completed (M3/08)
- [ ] Threat model includes AI-specific risks (membership inference, model inversion, etc.)
- [ ] Data flow diagram created with privacy annotations
- [ ] Identified all third parties involved (and their privacy practices)
- [ ] Stakeholder review of architecture for privacy implications

Doing this before writing code prevents 80% of privacy issues from existing.

Principio 2: Privacy as the Default

El concepto

Sistema debe ser privado sin que el usuario configure nada. "Opt-in to share" no "opt-out to keep private".

Aplicación a AI

Default behaviors should be privacy-preserving:

• Conversations NOT used for training unless user opts in.
• Logs anonymized by default; raw mode requires explicit enable.
• Personalization off unless user enables it.
• Data shared with third parties: NOT by default.

Concrete pattern

# UI/Settings page

class UserSettings:
    def __init__(self, user_id):
        self.user_id = user_id
        # Privacy-preserving defaults
        self.training_consent = False           # Default OFF
        self.analytics_consent = False           # Default OFF
        self.personalization = False             # Default OFF
        self.share_with_partners = False         # Default OFF
        # Necessary for service: defaults to ON
        self.service_operation = True            # Required for service

User can opt in to additional uses. Service works fully with defaults (privacy-preserving).

Counter-example

# ❌ NOT privacy by default
class UserSettings:
    training_consent = True       # Default ON
    analytics_consent = True       # Default ON
    share_with_partners = True     # Default ON

Common in commercial products. Violates privacy by default.

Principio 3: Privacy Embedded into Design

El concepto

Privacy es architectural concern, no feature añadido al final.

Aplicación a AI

Architectural decisions con privacy implications:

Each architectural decision should explicitly consider privacy.

Concrete: data flow diagram with privacy annotations

[User Input]
    │ encrypted in transit (TLS)
    ▼
[API Gateway]
    │ minimal logging, no PII
    │ rate limited
    ▼
[App Server]
    │ PII fetched only if needed
    │ system prompt sin PII estática
    ▼
[LLM API]   →  Third party (OpenAI)
    │           Contract: no training on data
    │           Logs: 30 days max
    │ response filtered for PII leaks
    ▼
[App Server]
    │ minimal logging
    │ response cached 24h max
    ▼
[Response]
    encrypted in transit (TLS)
    │
    ▼
[User]

Cada arrow has privacy annotation. Architectural review covers each.

Principio 4: Full Functionality

El concepto

Privacy y functionality no son zero-sum. Buen design achieves both.

Aplicación a AI

Common false dichotomy: "if we want personalization, we need to collect everything."

Reality:

• Personalization sin storing PII: usar embeddings/preferences vector, no raw history.
• Recommendations sin tracking: collaborative filtering on hashed user IDs.
• Analytics sin individual tracking: differential privacy aggregates.
• AI improvement sin training en personal data: synthetic data, federated learning.

Pattern: privacy-preserving personalization

# ❌ Privacy-violating
class Personalizer:
    def get_recommendations(self, user_id):
        # Pull entire user history
        history = db.get_full_history(user_id)
        # Pull demographic data
        demographics = db.get_demographics(user_id)
        # Send all to recommender
        return recommend_model.predict(history, demographics)

# ✅ Privacy-preserving
class Personalizer:
    def __init__(self):
        self.user_vectors = load_user_vectors()  # Pre-computed embeddings
    
    def get_recommendations(self, user_id):
        # Use only the user's preference vector (anonymous embedding)
        user_vector = self.user_vectors.get(user_id)
        # Recommend based on vector similarity
        return self.recommend_by_similarity(user_vector)
    
    def update_vector(self, user_id, action):
        # Update vector incrementally based on action
        # No need to store the action itself long-term
        self.user_vectors[user_id] = update(
            self.user_vectors[user_id],
            action
        )
        # Optionally, action discarded after vector update

Achieves personalization with much less PII surface.

Principio 5: End-to-End Security

El concepto

Protección durante todo el lifecycle: collection, processing, storage, transmission, deletion.

Aplicación a AI

Data lifecycle stages with security:

1. Collection
   ├ TLS for transmission
   ├ Input validation
   └ Minimization at collection
   
2. Processing
   ├ Authorization checks
   ├ PII redaction in logs
   └ Audit trails
   
3. Training
   ├ Encryption at rest
   ├ Access controls
   ├ Differential privacy (where applicable)
   └ Audit who accessed
   
4. Inference (production)
   ├ TLS to model API
   ├ Output filtering
   ├ Rate limiting
   └ Monitoring abnormal queries
   
5. Storage
   ├ Encryption at rest (always)
   ├ Backups encrypted
   └ Access logged
   
6. Deletion
   ├ Secure deletion (overwrite, not just unlink)
   ├ Cascade across systems
   └ Document

Each stage has security measures. Single failure → exposure. Defense in depth.

Concrete: encryption everywhere

# At rest
db.execute("CREATE TABLE conversations (... ) WITH (encryption='AES256')")

# In transit
app.config['SSL_REQUIRED'] = True
app.config['MIN_TLS_VERSION'] = 'TLSv1.2'

# In API calls to third parties
openai_client = OpenAI(
    api_key=settings.openai_key,
    # Always TLS
)

# In backups
backup_config = {
    'encryption': True,
    'kms_key': settings.kms_backup_key,
}

Principio 6: Visibility and Transparency

El concepto

Stakeholders (users, regulators, internal) deben entender cómo el sistema maneja privacy.

Aplicación a AI

Transparency artifacts:

1. Privacy policy (user-facing): plain language, comprehensive, current.

2. Model card: technical documentation of model behavior, limitations, biases, data sources.

3. Data flow diagram: how data moves through system.

4. Privacy impact assessment (Privacy Assessment from M3/08): formal evaluation.

5. Audit trails: what data was processed when by whom.

Concrete: model card example

# Model Card: Customer Support Chatbot

## Model Details
- **Type**: Fine-tuned LLM (Llama 3 base)
- **Version**: v2.1
- **Date**: 2026-04
- **Fine-tuning data**: 50K anonymized customer support conversations

## Intended Use
- **Primary**: respond to customer support queries
- **Out of scope**: medical, legal, financial advice

## Training Data
- **Source**: internal customer support tickets
- **Anonymization**: PII redacted (names, emails, phones, addresses)
- **Consent**: customers consented at ticket submission with opt-out option
- **Time period**: 2020-2025

## Performance
- **Accuracy**: 87% (on test set)
- **By language**: English 89%, Spanish 85%, French 80%
- **Limitations**: known issues with technical jargon

## Privacy Considerations
- **No PII in system prompt**: customer-specific data fetched on-demand
- **Conversations not used for training without explicit consent**
- **Logs anonymized within 30 days**
- **Output filtering for PII leaks**

## Bias Considerations
- **Tested**: equal performance across age groups, languages
- **Known limitation**: lower accuracy in non-Western names

## Maintenance
- **Re-evaluation**: every 6 months
- **Contact**: ai-team@acme.com

Open documentation builds trust + supports compliance.

Principio 7: Respect for User Privacy

El concepto

User al centro. Their interests primary consideration, no afterthought.

Aplicación a AI

Concrete behaviors:

1. Privacy-preserving defaults (Principio 2).
2. Easy access to user's own data (Right to Access).
3. Easy deletion of user's data (Right to Erasure).
4. Easy export of user's data (Right to Portability).
5. Easy withdrawal of consent.
6. Clear notification when data practices change.
7. Genuine accountability when issues occur.

Concrete: user-facing privacy controls

[User Settings - Privacy]

Data & Privacy:

┌─────────────────────────────────────────────────────────┐
│  📊  See your data                                      │
│      What we know about you                          [→]│
├─────────────────────────────────────────────────────────┤
│  📥  Download your data                                 │
│      Get a copy in JSON format                       [→]│
├─────────────────────────────────────────────────────────┤
│  🗑️  Delete your account                                │
│      Permanently remove your data                    [→]│
├─────────────────────────────────────────────────────────┤
│  ⚙️  Privacy settings                                    │
│      Control how your data is used                   [→]│
├─────────────────────────────────────────────────────────┤
│  📝  Privacy policy                                     │
│      How we handle data                              [→]│
└─────────────────────────────────────────────────────────┘

All accessible. Self-service. No support tickets required.

Aplicación integrada: AI system con Privacy by Design

Ejemplo: customer support chatbot con todos los principios:

# 1. Proactive: completed Privacy Assessment before code
# 2. Privacy default: training consent OFF until explicitly granted
# 3. Embedded: data flow diagram + architectural review

class ChatbotService:
    def __init__(self):
        self.consent_manager = ConsentManager()
        self.audit_logger = AuditLogger()
    
    async def handle_query(self, user_id, query):
        # Audit log (Principio 5: end-to-end security)
        self.audit_logger.log({
            'user_id': hash(user_id),  # Hashed in logs
            'query_hash': hash(query),
            'timestamp': now(),
        })
        
        # Fetch only what's needed (Principio 4: full functionality, minimum data)
        user_context = self.fetch_minimal_context(user_id)
        
        # Generate response without PII in prompt (Principio 3: embedded)
        response = await self.generate_response(query, user_context)
        
        # Filter response (defense in depth)
        safe_response = self.filter_pii_from_response(response)
        
        # Optionally, save conversation (only if user consented)
        if self.consent_manager.has_consent(user_id, 'training'):
            await self.save_for_training(query, response, user_id)
        
        return safe_response
    
    def fetch_minimal_context(self, user_id):
        """Fetch only fields needed for context."""
        return self.db.fetch_fields(user_id, fields=['subscription_tier', 'language'])
        # NOT: full user profile, payment info, etc.

# Architectural decisions documented

architecture:
  data_storage:
    primary: PostgreSQL with encryption at rest
    cache: Redis with 24h TTL
    backups: encrypted, 90-day rotation
  
  api_security:
    transport: TLS 1.3
    auth: JWT with 1h expiry
    rate_limiting: 100/hour/user
  
  llm_provider:
    vendor: OpenAI
    contract: enterprise (no training on data)
    region: US (data residency)
  
  logging:
    level: minimal
    pii_redaction: automatic
    retention: 30 days
  
  monitoring:
    privacy_metrics:
      - failed_consent_checks
      - pii_in_logs (alert if non-zero)
      - data_purge_completion

# Public artifacts (Principio 6)

- /privacy: full privacy policy
- /privacy/data: how data is handled
- /privacy/your-data: user's own data
- /privacy/preferences: privacy settings
- /privacy/contact: data protection contact

- Model card: github.com/.../model-card.md
- Data flow diagram: in privacy policy
- Privacy assessment: available on request to regulators

Esta es una system con Privacy by Design fully implementado.

Trampas comunes

1. "Privacy is legal team's problem"

Privacy is architectural. Legal team can advise, but engineers implement. By Design means engineers own it.

2. Adding privacy "later"

When it's easier (shipping fast), privacy is deferred. Then becomes "we'll fix it next release". Never gets done. Build it in from start or never.

3. Privacy theater

UI shows "your privacy matters" while sharing data with 50 partners. Users notice. Eventually regulators notice. Be authentic or don't claim.

4. Not auditing the architecture

Privacy by Design works only if verified periodically. Re-review architecture every 6 months. New features can break privacy posture.

5. Treating Privacy by Design as checklist

It's a mindset + framework, not just checkboxes. Engineers should think privacy when they think anything.

Auto-verificación

architecture:
  user_db:
    location: EU (Frankfurt)
    encryption: AES-256 at rest
    backups: encrypted, 30-day retention
    access_logs: enabled, 1-year retention
  
  api:
    minimum_response_fields: true
    rate_limiting: enabled
    audit_logging: enabled
    pii_in_logs: filtered
  
  third_parties:
    - openai: enterprise contract, no training, US region
    - cloudflare: TLS termination only, no PII access

Resumen y siguiente paso

• Privacy by Design = 7 principles (Cavoukian, 2009): proactive, default, embedded, full functionality, end-to-end, visibility, respect.
• GDPR Art 25 makes it legal obligation.
• Aplicación a AI requires translating each principle to specific architectural decisions.
• Privacy as default is the shift: from opt-out to opt-in for non-essential.
• End-to-end security + transparency = defense in depth.
• Full functionality is achievable with privacy — false dichotomy.

Checkpoint: deberías poder evaluar un sistema AI contra los 7 principios y identify gaps.

Puente a la siguiente cápsula: la cápsula 08 es el mini-proyecto: el Privacy Assessment para un sistema real. Vas a aplicar todo lo aprendido — minimization, anonymization, consent, retention, AI-specific risks, Privacy by Design — en un evaluation comprehensivo. Documento de 4-6 páginas, defendible, reusable.

Recursos

1. Privacy by Design — Cavoukian (2009) — paper foundational.
2. GDPR Art 25 — Data protection by design and by default — referencia legal.
3. NIST Privacy Framework — US framework.
4. Federated Learning (McMahan et al., 2017) — privacy-preserving training.
5. Differential Privacy 101 — accessible introduction.

Siguiente: 08-mini-proyecto-privacy-assessment.md — Privacy Assessment para tu sistema.

Cápsula 07 de 08 — Módulo 3 — AI Ethics & Compliance Guide