AI in Production -- Parte 5

Gobernanza y Compliance: Lo que Legal te va a preguntar antes de que tu IA salga a producción

#ai #architecture #gdpr #compliance #security

El Problema

Alguien de Legal se acerca a tu mesa. Han oído lo de la funcionalidad con IA. Traen una lista de preguntas.

¿Qué datos estás enviando al modelo? ¿Hay datos personales? ¿Dónde los almacena el proveedor? ¿Durante cuánto tiempo? ¿Los usuarios saben que su input lo procesa una IA de un tercero? ¿Pueden rechazarlo? ¿Qué pasa si un usuario pide borrar sus datos — eso incluye lo que ya enviaste a la IA?

Si no puedes responder a estas preguntas, la funcionalidad no sale a producción. No porque Legal sea difícil. Porque en la UE, estas preguntas tienen respuestas legales, y equivocarse tiene consecuencias reales.

Esto no es un caso raro. Cualquier funcionalidad de IA que procese input de usuario en la UE toca el GDPR casi por definición. Cuando un usuario escribe un mensaje, pega un documento o envía un formulario que se manda a un modelo de IA, estás procesando datos personales en su nombre. El proveedor de IA es un procesador de datos bajo tu control. Tú eres el responsable del tratamiento. Las obligaciones son tuyas.

Además del GDPR, la EU AI Act añade otra capa. La mayoría de funcionalidades de IA empresariales caen en las categorías de “riesgo limitado” o “propósito general” — no requieren una evaluación de conformidad — pero sí requieren obligaciones de transparencia: los usuarios deben saber que están interactuando con IA.

La buena noticia es que la mayor parte se puede resolver con diseño. Constrúyelo bien desde el principio y la revisión de compliance es rápida. Si te lo saltas, estarás haciendo cirugía de emergencia en código de producción.

A person in business formal walks purposefully toward a developer at their desk, holding a clipboard with a long checklist. The developer has a frozen "oh no" expression, coffee mug halfway to mouth.

Las Cinco Preguntas que Necesitas Responder

Antes de escribir código de compliance, responde a estas con claridad. El código sale de las respuestas.

1. ¿Qué datos personales van a la IA? Mapea cada campo. ¿Nombres de usuario? ¿Direcciones de email? ¿Texto libre que podría contener cualquier cosa? ¿Documentos que suben los usuarios? Registra esto de forma explícita — “input de usuario (texto libre, puede contener PII)” es una respuesta honesta. “Nada sensible” suele ser incorrecto.

2. ¿Qué hace el proveedor con los datos? Lee los términos de procesamiento de datos del proveedor. La mayoría de proveedores grandes ofrecen un Data Processing Agreement (DPA) y opciones de residencia de datos. Averigua si tus datos se usan para entrenar el modelo (opta por no participar si es posible), dónde se almacenan y cuánto tiempo se retienen. Esto va en tu Records of Processing Activities (RoPA).

3. ¿Lo saben los usuarios? Tu política de privacidad debe mencionar el procesamiento con IA. Si los usuarios interactúan directamente con una funcionalidad de IA, necesitan saberlo — la EU AI Act lo exige. Una etiqueta pequeña de “Powered by AI” y un enlace a la política de privacidad suele ser suficiente para sistemas de riesgo limitado.

4. ¿Pueden los usuarios rechazarlo o pedir el borrado? Si un usuario ejerce su derecho al olvido bajo GDPR, ¿qué pasa con los datos que ya enviaste a la IA? No puedes “des-enviarlos”, pero puedes documentar qué se envió, cuándo y bajo qué base legal. También puedes dejar de enviar los datos de ese usuario en adelante.

5. ¿Cuál es tu base legal para el procesamiento? Normalmente interés legítimo o necesidad contractual para B2B, consentimiento para productos de consumo. Esto determina tus obligaciones. Elige una y documéntala — “no estamos seguros” no es una base legal.

Ejecución

Limpia PII antes de que salga de tu sistema

La protección más simple: no envíes lo que no necesitas. Antes de pasar el input del usuario a la IA, elimina o enmascara los campos que son identificables pero irrelevantes para la tarea de la IA.

public static class PiiScrubber
{
    // These patterns cover common EU PII formats.
    // Extend based on what your actual data looks like.
    private static readonly Regex EmailPattern =
        new(@"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b",
            RegexOptions.IgnoreCase | RegexOptions.Compiled);

    private static readonly Regex IbanPattern =
        new(@"\b[A-Z]{2}\d{2}[A-Z0-9]{4,30}\b",
            RegexOptions.Compiled);

    private static readonly Regex PhonePattern =
        new(@"\b(\+\d{1,3}[\s.-])?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}\b",
            RegexOptions.Compiled);

    public static string Scrub(string text)
    {
        text = EmailPattern.Replace(text, "[EMAIL]");
        text = IbanPattern.Replace(text, "[IBAN]");
        text = PhonePattern.Replace(text, "[PHONE]");
        return text;
    }
}

Úsalo en tu servicio de IA antes de cada llamada:

public async Task<string?> SummarizeAsync(
    string text,
    CancellationToken cancellationToken = default)
{
    // Scrub before it leaves your boundary
    var sanitized = PiiScrubber.Scrub(text);

    // ... proceed with sanitized input
}

Esto no va a pillar todo — el texto libre es impredecible. Pero elimina los patrones de PII estructurado más comunes y demuestra intención: diseñaste el sistema para minimizar la exposición de datos.

A conveyor belt where documents enter a machine labeled "PII SCRUBBER". Email addresses and phone numbers are being replaced with [EMAIL] and [PHONE] tags. A small robot operates the machine with a satisfied expression.

Audita cada llamada a la IA

Necesitas poder responder “¿qué enviamos a la IA, y cuándo?” para cualquier usuario. Esto significa un log de auditoría duradero — no solo logs de aplicación que rotan y desaparecen.

public record AiAuditEntry
{
    public Guid Id { get; init; } = Guid.NewGuid();
    public string UserId { get; init; } = default!;
    public string Feature { get; init; } = default!;       // e.g. "document-summary"
    public string InputHash { get; init; } = default!;     // SHA-256 of input, not the input itself
    public int EstimatedTokens { get; init; }
    public string Model { get; init; } = default!;
    public string LegalBasis { get; init; } = default!;    // e.g. "legitimate_interest"
    public DateTimeOffset Timestamp { get; init; } = DateTimeOffset.UtcNow;
}

Almacena el hash del input, no el input en sí. Esto te permite demostrar que un input específico se envió (hasheando el original otra vez) sin almacenar una segunda copia de datos personales. Menos datos almacenados, menos exposición.

public class AiAuditService
{
    private readonly IRepository<AiAuditEntry> _repository;

    public async Task LogAsync(
        string userId,
        string feature,
        string originalInput,
        int estimatedTokens,
        string model,
        string legalBasis,
        CancellationToken ct = default)
    {
        var hash = Convert.ToHexString(
            SHA256.HashData(Encoding.UTF8.GetBytes(originalInput)));

        await _repository.InsertAsync(new AiAuditEntry
        {
            UserId = userId,
            Feature = feature,
            InputHash = hash,
            EstimatedTokens = estimatedTokens,
            Model = model,
            LegalBasis = legalBasis
        }, ct);
    }
}

Middleware de consentimiento

Para productos de consumo donde el consentimiento es tu base legal, compruébalo antes de cada llamada a la IA. No asumas que el consentimiento persiste — los usuarios pueden retirarlo.

public class AiConsentMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IConsentStore _consent;

    public AiConsentMiddleware(RequestDelegate next, IConsentStore consent)
    {
        _next = next;
        _consent = consent;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Only applies to AI endpoints
        if (!context.Request.Path.StartsWithSegments("/api/ai"))
        {
            await _next(context);
            return;
        }

        var userId = context.User.FindFirst("sub")?.Value;
        if (userId is null)
        {
            context.Response.StatusCode = 401;
            return;
        }

        var hasConsent = await _consent.HasAiConsentAsync(userId);
        if (!hasConsent)
        {
            context.Response.StatusCode = 403;
            await context.Response.WriteAsJsonAsync(new
            {
                error = "ai_consent_required",
                message = "Enable AI features in your privacy settings to use this."
            });
            return;
        }

        await _next(context);
    }
}

La etiqueta de transparencia

La EU AI Act requiere que los usuarios sepan que están interactuando con IA. En la práctica, esto es una etiqueta en la UI — pero inclúyela también en las respuestas de tu API para que cualquier superficie de cliente pueda mostrarla:

public record AiSummarizeResponse(
    string? Summary,
    bool AiAvailable,
    // Clients must display this when AiGenerated is true
    bool AiGenerated = true,
    string AiDisclosure = "This summary was generated by an AI system."
);

El checklist del DPA

Antes de conectarte a cualquier proveedor de IA, verifica esto:

  • DPA firmado — tienes un Data Processing Agreement con el proveedor
  • Residencia de datos confirmada — los datos se quedan en la UE (o tienes garantías adecuadas para transferencias)
  • Opt-out de entrenamiento — tus datos no se usan para entrenar los modelos del proveedor (la mayoría de tiers enterprise lo ofrecen)
  • Periodo de retención documentado — sabes cuánto tiempo guarda el proveedor los datos de las peticiones
  • Notificación de incidentes — el proveedor te notificará de brechas en 72 horas (necesario para notificar a tus usuarios)
  • Lista de sub-procesadores — sabes con quién comparte datos el proveedor

Esta lista va en tu documentación de privacidad. Si el proveedor no puede responder a estas preguntas, elige otro proveedor.

A developer stands in front of a compliance officer at a desk. The officer holds a checklist with every item checked in green, stamping a document "APPROVED". The developer looks relieved, giving a thumbs up.

EU AI Act: la versión rápida

La mayoría de funcionalidades de IA empresariales son de riesgo limitado bajo la EU AI Act. Esto significa:

  • Debes informar a los usuarios de que están interactuando con IA (obligación de transparencia)
  • No se requiere evaluación de conformidad
  • No se requiere marcado CE
  • No se requiere registro en la base de datos de la UE

Alto riesgo aplicaría si usas IA para decisiones de empleo, scoring crediticio, infraestructura crítica o fuerzas de seguridad. Si ese es tu caso, los requisitos son bastante más pesados y quedan fuera del alcance de este artículo.

Si estás en el ámbito de aplicación, enlaza al texto de la EU AI Act y documenta tu decisión de clasificación. “Evaluamos esto como riesgo limitado porque X” es lo que un auditor necesita ver.

Checklist

  • ¿Sabes exactamente qué datos personales van al modelo de IA?
  • ¿Has firmado un DPA con tu proveedor de IA?
  • ¿Está confirmada la residencia de datos en la UE?
  • ¿Saben los usuarios que su input lo procesa una IA? (transparencia EU AI Act)
  • ¿Tienes un log de auditoría de llamadas a la IA por usuario?
  • ¿Hay forma de que los usuarios rechacen o retiren el consentimiento?
  • ¿Está documentada tu base legal para el procesamiento con IA?
  • ¿Has clasificado tu sistema bajo la EU AI Act?

Si Legal te hace estas preguntas la semana que viene, ¿puedes responder a todas?

Antes del Siguiente Artículo

Compliance resuelto. Ahora la pregunta práctica: ¿cómo añades una funcionalidad de IA a un sistema que ya existe? No un proyecto desde cero — tu API de producción actual, con su base de datos existente, su capa de autenticación y su pipeline de despliegue.

Eso es el artículo 6. Patrones de integración para IA en sistemas existentes.


Si esta serie te resulta útil, puedes invitarme a un café.

Este es el artículo 5 de la serie AI in Production. Siguiente: Integración de IA en Sistemas Existentes — patrones para añadir IA sin romper lo que ya funciona.

Comments

Loading comments...