Privacidad y Seguridad en IA

La privacidad y la seguridad en IA son dos preocupaciones distintas que conviene no confundir. La privacidad atañe a los datos: proteger la información personal que entrena y alimenta a los modelos frente a filtraciones y usos indebidos. La seguridad atañe al sistema: proteger al modelo y a su comportamiento frente a la manipulación de un atacante. Un sistema puede ser robusto y aun así indiscreto, o cuidadoso con los datos y aun así fácil de engañar.

La distinción importa porque las defensas también difieren, y porque el auge de los grandes modelos de lenguaje (LLM) y los agentes ha ampliado la superficie de ataque mucho más allá de lo que cubrían los enfoques clásicos.

Explicar no es asegurar

La IA explicable (XAI) reúne métodos para hacer inspeccionable una decisión del modelo. Uno de ellos es Layer-Wise Relevance Propagation (LRP): parte de la salida y redistribuye una puntuación de relevancia hacia las capas anteriores hasta atribuir contribuciones a las variables de entrada. El artículo que introduce LRP para clasificadores no lineales formula esa propagación como una conservación de relevancia entre capas y visualiza las contribuciones. La explicación ayuda a auditar una predicción concreta; no demuestra que el modelo sea seguro, causal ni correcto fuera de los casos evaluados.

Riesgos de privacidad

Los modelos memorizan más de lo que aparentan. Shokri y sus colaboradores describieron en 2017 los ataques de inferencia de pertenencia (membership inference): con solo acceso a las predicciones de un modelo, un atacante puede determinar si un registro concreto —una historia clínica, por ejemplo— formó parte de los datos de entrenamiento. En los LLM el problema se agudiza: Carlini y su equipo demostraron la extracción de datos de entrenamiento, recuperando literalmente secuencias memorizadas por GPT-2, incluidos nombres, teléfonos y direcciones de correo. La memorización no es una anécdota, es un vector de fuga.

Riesgos de seguridad: del ejemplo adversario al agente

Goodfellow, Shlens y Szegedy mostraron en 2015 los ejemplos adversarios: perturbaciones mínimas, casi imperceptibles, que hacen a una red clasificar de forma errónea con alta confianza. A ello se suma el envenenamiento de datos (data poisoning), que corrompe el modelo desde su entrenamiento. Con los LLM y los agentes aparecen riesgos propios que cataloga el OWASP Top 10 for LLM Applications: la inyección de prompts —directa o indirecta, cuando el modelo obedece instrucciones ocultas en una web o un documento— encabeza la lista; le siguen la fuga de información sensible, el exceso de agencia (un agente con demasiados permisos que actúa sobre herramientas conectadas y filtra datos a través de ellas), el robo de modelos y las fugas del prompt de sistema. Los jailbreaks, que sortean las salvaguardas, completan el cuadro.

Dos defensas históricas muestran por qué siempre hay que declarar el modelo de amenaza. El adversarial training incorpora al entrenamiento ejemplos generados para atacar al modelo; el trabajo original de Goodfellow, Shlens y Szegedy lo usó para reducir el error frente a ese tipo de perturbación. La defensive distillation se propuso después para suavizar la respuesta de la red, pero Carlini y Wagner mostraron que no resistía ataques dirigidos adaptados. Nombrar una defensa no basta: hay que especificar qué atacante conoce, qué puede modificar y contra qué ataque se midió.

Defensas y su límite: el caso del aprendizaje federado

La privacidad diferencial, formalizada por Dwork y otros en 2006, es hoy la referencia con garantías cuantificables: añade ruido calibrado para acotar cuánto revela una salida sobre un individuo concreto. El cifrado homomórfico y el cómputo seguro multiparte permiten operar sobre datos cifrados. Y el aprendizaje federado mantiene los datos en el dispositivo del usuario, entrenando un modelo común sin centralizarlos. Aquí conviene un matiz que suele omitirse: mantener los datos locales no garantiza la privacidad por sí solo. Los ataques de reconstrucción por gradientes (gradient leakage) pueden recuperar muestras privadas a partir de las actualizaciones compartidas, y la inferencia de pertenencia sigue siendo posible. Por eso el federado suele combinarse con privacidad diferencial y agregación segura; en solitario no basta.

Otras dos familias actúan sobre los datos antes de compartirlos. k-anonymity busca que cada combinación publicada de cuasi-identificadores no distinga a una persona de al menos otras k−1; la perturbación modifica valores, por ejemplo mediante generalización, intercambio o ruido, para reducir el vínculo con el registro original. NIST SP 800-188 las encuadra como técnicas de desidentificación y exige medir el riesgo de reidentificación. Ocultar nombres o alcanzar k-anonymity no prueba anonimato: variables auxiliares y combinaciones raras todavía pueden volver a identificar.

Gobernanza y regulación

La respuesta institucional ya es tangible. El NIST AI Risk Management Framework (2023) ofrece un marco voluntario articulado en cuatro funciones —gobernar, mapear, medir y gestionar—. El Reglamento de IA de la Unión Europea (EU AI Act), en vigor desde agosto de 2024, impone obligaciones escalonadas: prácticas prohibidas desde febrero de 2025 y deberes para los modelos de propósito general desde agosto de 2025. Queda sin resolver lo esencial: no existe defensa completa contra la inyección de prompts, y las garantías de privacidad casi siempre exigen ceder algo de utilidad. La seguridad en IA es un equilibrio en movimiento, no un estado que se alcanza.