Módulo 3: Privacy and Data Protection Fundamentals

4. Consent en Sistemas AI

Siguiente →

Descripción de la cápsula

Consent es el principio legal y ético central de privacy: las personas deben autorizar el uso de sus datos. Sin consent válido, processing es ilegal en la mayoría de jurisdicciones (GDPR, CCPA, etc.).

Pero consent en AI es más complicado que en software tradicional. Razones:

  1. Los usuarios no entienden cómo AI procesa sus datos. "Tus datos se usarán para mejorar nuestros servicios" → ¿qué significa eso técnicamente?

  2. Los uses son emergentes: cuando recolectaste el dato hace 2 años, no podías anticipar uses que LLMs nuevos hacen posibles.

  3. Datos integrados en modelos: una vez que un sample está en un modelo entrenado, "revoke consent" requires re-training (caro o impossible).

  4. Indirect data collection: data sobre persona X puede venir de persona Y (referrals, mentions, photos).

Esta cápsula cubre cómo diseñar consent significativo en sistemas AI:

  1. Los 4 elementos de valid consent: freely given, specific, informed, unambiguous.
  2. Granularidad: consent separado para distintos uses.
  3. Informed consent en práctica: cómo explicar AI a non-experts.
  4. Revocación: cómo manejar withdrawal cuando data ya está en modelos.
  5. Edge cases: indirect data, public data, derived data.

Los 4 elementos de consent válido

GDPR Art 4(11) define consent. Los 4 elementos requeridos:

1. Freely given

El usuario debe tener opción real de NO consentir, sin penalty.

Violations:

  • "Acepta o no podés usar el servicio" (cuando el dato no es necesario para el servicio).
  • Pre-checked boxes.
  • Bundled consent ("acepto terms y AI training").

Compliant:

  • Boxes unchecked por default.
  • Clear option to refuse without losing core service.
  • Refusal doesn't degrade UX significantly.

2. Specific

Consent para un purpose específico, no blanket.

Violations:

  • "Acepto que mis datos se usen para mejorar nuestros servicios" (qué services? qué specific?)
  • Single checkbox for multiple unrelated purposes.

Compliant:

  • "Acepto que mis conversations se usen para entrenar modelos de generación de texto."
  • Separate boxes for distinct purposes.

3. Informed

El usuario debe entender qué consents.

Violations:

  • 50-page Terms of Service.
  • Technical jargon que normal users no understand.
  • Hiding key information in fine print.

Compliant:

  • Plain-language summary.
  • Concrete examples de cómo se usará el data.
  • FAQ accessible.

4. Unambiguous

Acción clara expressing consent.

Violations:

  • Continued use as consent ("by using this app, you consent...").
  • Inferred consent.
  • Silence.

Compliant:

  • Active checkbox.
  • Click button "I consent".
  • Clear separation entre consent y other actions.

Granularidad: consent separado por purpose

En AI, hay múltiples potential uses de mismo data. Each requires separate consent.

Ejemplo: chatbot de customer support

Datos: conversations entre user y AI.

Possible uses:

  1. Operate the service: handle current query.
  2. Improve the model: fine-tune para better responses.
  3. Research: published research papers.
  4. Marketing: training models para advertising.
  5. Sell to partners: third-party applications.

Compliant approach: consent separado para cada one.

☐ Use my conversations to provide customer support (REQUIRED)
☐ Use my conversations to improve the AI model (OPTIONAL)
☐ Use my (anonymized) conversations for AI safety research (OPTIONAL)
☐ Share my conversations with marketing partners (OPTIONAL)

User puede consent al primero (necessary) y rechazar otros. Service should function regardless de optional consents.

El "primary" purpose vs "secondary" purposes

Primary purpose: para qué el user iniciated la interaction. Consent typically explicit (using the service = consent).

Secondary purposes: anything else. Requires explicit additional consent.

Many AI platforms violate esto by bundling secondary uses con primary.

Informed consent: cómo explicar AI

El reto: most users no understand AI technically. ¿Cómo logras "informed" consent?

Approach 1: layered disclosure

Layer 1 (summary, all users see):

Vamos a usar tus conversations para responder mejor a tus preguntas. Si lo permites, también las usaremos para entrenar nuestros modelos AI.

Layer 2 (more detail, click to expand):

"Entrenar modelos AI" significa que tus conversations se incluyen en datasets que enseñan a nuestros modelos a generar mejores respuestas. Los modelos aprenden patterns generales, no memorize details específicas.

Layer 3 (technical, for those who want):

Conversations se anonimizan eliminando emails, phones, names, addresses. Se almacenan encrypted. Después de fine-tuning, el dato se purga del raw store. El modelo entrenado puede contener traces estadísticas pero no individual records.

User puede choose nivel de detalle según interés. Most users read layer 1, some layer 2, few layer 3 — pero la información está disponible.

Approach 2: concrete examples

En lugar de abstract:

❌ "Tus datos se usarán para improve services."

✅ "Si preguntas '¿cómo cambio mi password?', entrenaremos el modelo para responder mejor a preguntas similares de otros usuarios."

Examples concretos comunican what abstract doesn't.

Approach 3: visual / interactive

Demo interactive:

"Veamos qué pasaría con tus datos:

  1. Vos enviás message: 'Hola, soy María, tengo problema con mi orden'
  2. Sistema anonimiza: 'Hola, soy [NAME], tengo problema con mi orden'
  3. Anonymized version se incluye en training dataset
  4. Future users con preguntas similares obtendrán mejor respuesta"

Demuestra el flow real.

Revocación: el problema con modelos entrenados

El reto

Imagina:

  1. María consent a que su data se use para training (1 year ago).
  2. Modelo se entrenó con su data (incluido en 1M samples).
  3. Modelo está deployed y serving 100K queries/day.
  4. María revokes consent.

¿Qué hacés?

Opciones

Opción 1: Re-train sin María's data

  • Costo: weeks de compute, $100K+.
  • Practical: rara vez factible.

Opción 2: "Machine unlearning"

Active research area. Techniques que aproximadamente "remove" un sample's influence sin full re-train.

  • Ejemplo: SISA (Sharded, Isolated, Sliced, Aggregated training).
  • Limitations: works mejor para some architectures, not others.
  • No silver bullet aún.

Opción 3: Remove from RAG / retrieval store, accept model contains traces

  • Si el sistema usa RAG (retrieval), remove desde el store.
  • El base model puede contener traces, pero outputs ya no incluyen María's data directly.
  • Often legally acceptable bajo GDPR si "reasonable" effort hecho.

Opción 4: Block future use sin training

  • Document que María opted out.
  • Future training rounds excluden su data.
  • Existing model continues but no further use.

Realistic approach: combination — remove desde retrieval stores, opt-out future training, document si full unlearning is impossible.

Lo que NO podés hacer

  • Ignorar la request: GDPR Right to Erasure (Art 17) es enforceable.
  • Cobrar fee por revocation.
  • Demorar indefinidamente.

Tenés que respond, hacer best effort, document lo que hiciste y por qué not más.

Indirect data collection

Casos donde collected data sobre persona X via persona Y:

Caso 1: photos con multiple personas

User uploads selfie con friend → tu sistema procesa el friend's face también.

Solution:

  • Notify users que photos con others requires their consent.
  • Face detection + blurring para non-consenting individuals.
  • Limit retention de derivative data.

Caso 2: mentions en conversations

User message: "My girlfriend Sarah said she wanted X."

Tu sistema processes this con Sarah's name. Sarah no consent.

Solution:

  • PII redaction: detect names, replace con placeholders.
  • Don't persist mentions of third parties.
  • Educate users about not sharing third-party PII.

Caso 3: communication apps

User forwards email from Bob to your AI for summarization.

Solution:

  • Process inline, don't persist.
  • Document que outgoing emails aren't stored.
  • Bob's data is processed only en context de specific request.

Lecciones generales

Indirect data is harder problema. Mitigations:

  1. Inform users about responsibility para third-party data they share.
  2. Detect and limit persistence of third-party PII.
  3. Process locally when possible (no cloud round-trip with PII).
  4. Audit periodically for unexpected third-party data accumulation.

Public data: ¿hay consent?

Common belief: "data is public, can be used freely".

Falso bajo GDPR. Public data sigue siendo personal data. Processing requires lawful basis (consent or legitimate interest, etc.).

Casos

Web scraping:

  • Scraping public LinkedIn profiles → potencialmente violación.
  • Scraping public tweets → grey area, depends on use.
  • Scraping public government data → typically OK.

Foundation model training:

  • GPT, Claude, etc. trained on internet data → ongoing legal challenges.
  • New York Times v OpenAI (2023): claim OpenAI used NYT articles without consent.
  • Outcome will affect industry standards.

Best practices conservadoras

  1. Use only data with clear lawful basis (consent, legitimate interest documented).
  2. Respect robots.txt and similar signals.
  3. Don't bypass paywalls / authentication.
  4. Document data provenance carefully.
  5. Be prepared to remove data if requested.

Implementación: consent management

Tabla de consents

CREATE TABLE user_consents (
    user_id INT,
    consent_type VARCHAR(50),  -- 'training', 'research', 'marketing', etc.
    granted_at TIMESTAMP,
    revoked_at TIMESTAMP NULL,
    consent_text TEXT,  -- exact text user agreed to
    consent_version VARCHAR(20),
    PRIMARY KEY (user_id, consent_type)
);

API for consent management

class ConsentManager:
    def grant_consent(self, user_id, consent_type, version):
        """User grants consent."""
        self.db.execute("""
            INSERT INTO user_consents 
            (user_id, consent_type, granted_at, consent_version)
            VALUES (?, ?, NOW(), ?)
            ON DUPLICATE KEY UPDATE granted_at = NOW(), revoked_at = NULL
        """, (user_id, consent_type, version))
    
    def revoke_consent(self, user_id, consent_type):
        """User revokes consent."""
        self.db.execute("""
            UPDATE user_consents
            SET revoked_at = NOW()
            WHERE user_id = ? AND consent_type = ?
        """, (user_id, consent_type))
        
        # Trigger downstream actions
        self._handle_revocation_actions(user_id, consent_type)
    
    def has_active_consent(self, user_id, consent_type):
        """Check before processing."""
        result = self.db.fetchone("""
            SELECT 1 FROM user_consents
            WHERE user_id = ? AND consent_type = ?
            AND granted_at IS NOT NULL AND revoked_at IS NULL
        """, (user_id, consent_type))
        return result is not None
    
    def _handle_revocation_actions(self, user_id, consent_type):
        """Trigger removal/blocking based on consent type."""
        if consent_type == 'training':
            # Mark user data to exclude from future training
            self.exclude_from_future_training(user_id)
        if consent_type == 'retention':
            # Schedule data deletion
            self.schedule_deletion(user_id)

Integration: check consent before processing

async def process_for_training(user_id, conversation):
    if not consent_manager.has_active_consent(user_id, 'training'):
        return  # Skip, no consent
    
    anonymized = anonymize(conversation)
    add_to_training_set(anonymized)

Consent check is first thing in any processing pipeline. Default deny.

Trampas comunes

1. Bundled consent

"Accept all terms" combining 5 distinct purposes. Violates "specific" requirement. Each purpose needs separate checkbox.

2. "Continued use = consent"

Banner: "By continuing to use this site, you agree to AI training". Not valid. Active consent action required.

3. Granting consent without UI to revoke

Easy to grant, hard to revoke = violates spirit. Revocation must be similarly accessible.

4. Consent collected once, never refreshed

Consent given 5 years ago for "service improvements" doesn't cover new use cases (LLM training) que didn't exist then. Re-consent for material new uses.

5. Default opt-in for AI

Pre-checked boxes are GDPR violation. AI training participation should be opt-in, default unchecked.

Auto-verificación

1. ¿Cuáles son los 4 elementos de consent válido?

  1. Freely given: usuario tiene opción real de NO consentir sin penalty.

  2. Specific: para purpose específico declarado, no blanket.

  3. Informed: usuario entiende qué consent.

  4. Unambiguous: clear active action expressing consent (no inferences, no continued use).

Si uno falla, el consent es inválido. Implication: processing basado en consent inválido es ilegal bajo GDPR (sin lawful basis).

Practical: implement consent flows que claramente address cada elemento. Document que cumplís cada uno. Audit periodically.

2. ¿Por qué granularidad de consent matters?

Porque AI tiene múltiples possible uses de mismo data:

  • Operate the service.
  • Improve the model.
  • Research.
  • Marketing.
  • Sell to partners.

Bundling estos en single consent violates "specific" requirement de GDPR. Each requires explicit separate consent.

Granular consent allows users to:

  • Enable core service (necessary).
  • Opt out of secondary uses they don't agree to.
  • Maintain control over their data participation.

Implementation: separate checkboxes, separately revocable. Default off for non-essential uses.

Beneficio adicional: users que confían en tu manejo grantan more consents. Granularidad = trust = más data overall (vs bundled where users may refuse all).

3. ¿Cómo manejás revocation cuando data ya está en un modelo entrenado?

Realistic approach es combinations:

  1. Remove from retrieval/RAG stores immediately: future queries no use the data.

  2. Mark for exclusion en future training rounds: next time el modelo se re-train, María's data is excluded.

  3. Machine unlearning si feasible: emerging techniques que approximate removal del modelo. Not full re-train pero best effort.

  4. Document lo done y lo not done: paper trail showing reasonable effort. GDPR accepts "reasonable" effort cuando full removal is impossible.

  5. Communicate honestly al user: "We've removed your data desde retrieval stores y our future training will exclude it. Existing models may contain statistical traces que are not individually identifiable, but cannot be fully removed without full re-train."

Lo que NO podés:

  • Ignore the request.
  • Pretend that "anonymized" data after model training is no longer her data.
  • Charge for processing the request.
  • Wait indefinitely.

Bottom line: best effort + transparency + paper trail. Most regulators accept esto cuando alternative es technically impossible.

4. ¿Por qué public data sigue siendo personal data bajo GDPR?

GDPR define personal data como "any information relating to an identified or identifiable natural person". No mention of public/private.

Si el data identifies a person, es personal data, regardless of dónde se obtuvo.

Implication: scraping public LinkedIn, Twitter, etc. for AI training requires lawful basis:

  • Consent (explicit consent del individuo).
  • Legitimate interest (documented, balanced against rights).
  • Contract necessity.
  • Legal obligation.
  • Vital interest.
  • Public task.

For most foundation model training, "consent" is not feasible at scale (you can't get consent from every individual mentioned online). Companies typically claim "legitimate interest" — but this requires:

  • Documented assessment.
  • Balancing test (your interest vs individual's rights).
  • User option to object.

Ongoing legal challenges (NYT v OpenAI) test these claims. Outcome will set industry standards.

Practical recommendation:

  • Document data provenance carefully.
  • Have a process for removing specific individuals upon request.
  • Use data with clear lawful basis when possible.
  • Be prepared for legal scrutiny as regulations evolve.

Resumen y siguiente paso

  • Valid consent requires 4 elements: freely given, specific, informed, unambiguous.
  • Granularity matters: separate consent for each distinct purpose.
  • Informed consent en AI requires plain-language explanations, layered disclosure, concrete examples.
  • Revocation es challenging with trained models. Best effort + transparency + documentation.
  • Indirect data collection (third parties mentioned, photos with others) requires special handling.
  • Public data sigue siendo personal data bajo GDPR. Lawful basis required.

Checkpoint: deberías poder evaluar un consent flow y identify violations de cada uno de los 4 elements.

Puente a la siguiente cápsula: la cápsula 05 cubre retention y data lifecycle: cuánto tiempo conservar data, políticas de purga automática, manejo de "right to deletion" requests. Crítico porque datos persisten más de lo planeado por default.

Recursos

  1. GDPR Art 4(11), 6, 7 — definitions y conditions for consent.
  2. Article 29 Working Party — Consent Guidelines — interpretive guidance.
  3. California Consumer Privacy Act (CCPA) — US comparison.
  4. Machine Unlearning research — emerging techniques.

Siguiente: 05-retention-lifecycle.md — Retention, purge, y right to erasure.

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

← Anterior3. Anonymization vs PseudonymizationSiguiente →5. Retention y Data Lifecycle