Capítulo 13 — Sistemas de datos
Mapa de la lección
Lección 13 publicada. Mapa, ejemplo, EX037.
flowchart TD
N0["Resultados de aprendizaje"]
N1["13.1 Esquemas, linaje y versiones"]
N2["13.2 Integridad de los datos de entrenamiento"]
N3["13.3 Almacenes de recuperación"]
N4["13.4 Protección de datos"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX037"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["13.1 Esquemas, linaje y versiones"]
N2["13.2 Integridad de los datos de entrenamiento"]
N3["13.3 Almacenes de recuperación"]
N4["13.4 Protección de datos"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX037"]
[Resultados de aprendizaje]
|
v
[13.1 Esquemas, linaje y versiones]
|
v
[13.2 Integridad de los datos de entrenamiento]
|
v
[13.3 Almacenes de recuperación]
|
v
[13.4 Protección de datos]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX037]
Resultados de aprendizaje
Usted será capaz de (1) modelar conjuntos de datos con esquemas, linaje y versiones; (2) proteger los datos de entrenamiento y de recuperación frente a la manipulación y la filtración; (3) diseñar almacenes para la generación aumentada por recuperación (RAG) con control de acceso; y (4) aplicar los principios de protección de datos a los datos de IA.
13.1 Esquemas, linaje y versiones
Todo conjunto de datos debería tener un esquema, un registro de la procedencia de cada elemento (linaje o procedencia) y un identificador de versión. Las herramientas de versionado de datos o unos simples hashes del contenido permiten decir exactamente qué datos entrenaron qué modelo, algo esencial al investigar un envenenamiento. Cuando un modelo empieza a comportarse de forma extraña, la primera pregunta de la investigación es de qué aprendió. Sin versiones, el equipo solo puede adivinar si se incluyó un lote sospechoso de etiquetas. Con ellas, puede enumerar todos los elementos añadidos desde el último modelo bueno, averiguar quién suministró cada uno y reentrenar con una versión limpia para confirmar la causa.
13.2 Integridad de los datos de entrenamiento
El envenenamiento requiere acceso de escritura a parte de los datos de entrenamiento. Carlini et al. (arXiv:2302.10149) mostraron que los conjuntos de datos a escala web distribuidos como listas de URL pueden envenenarse comprando dominios caducados; los hashes de integridad del contenido en el momento de la recogida frustran ese ataque concreto. Restrinja quién puede añadir o reetiquetar datos, registre los cambios y revise muestras de las fuentes nuevas. Los hashes protegen lo que se recogió, no si era honesto desde el principio. Un contratista de etiquetado con acceso legítimo puede seguir introduciendo etiquetas erróneas, así que revise muestras por fuente y vigile los cambios en las estadísticas de las etiquetas tras cada entrega.
13.3 Almacenes de recuperación
Los sistemas RAG guardan fragmentos de documentos y sus embeddings en una base de datos vectorial. OWASP LLM 2025 incluye las debilidades de vectores y embeddings (LLM08): la falta de control de acceso permite a un usuario recuperar documentos que no debería ver, y los documentos envenenados pueden inyectar instrucciones. Aplique los permisos por documento en el momento de la recuperación, usando la identidad del usuario final, y etiquete la procedencia y el nivel de confianza de cada fragmento. Comprobar con la identidad del usuario importa porque el propio servicio de recuperación suele tener acceso a todo. Si busca con su propia autoridad, el modelo recibe documentos que el usuario nunca podría abrir, y una pregunta bien elegida los sacará a la luz en una respuesta. Las etiquetas de procedencia permiten que el prompt y la capa de política traten con la debida cautela el texto de contratistas o de fuentes externas.
13.4 Protección de datos
Minimice los datos personales en el entrenamiento y la recuperación; fije límites de conservación; considere la privacidad diferencial para el entrenamiento con datos sensibles (Abadi et al., arXiv:1607.00133). La inferencia de pertenencia (Shokri et al., arXiv:1610.05820) muestra que los modelos pueden revelar si se usó un registro. La minimización es la protección más barata: los datos que nunca se recogieron no pueden filtrarse a través de un modelo. Los límites de conservación eliminan los datos cuando termina su finalidad, lo que también reduce lo que podría exponer una brecha. La privacidad diferencial añade ruido calibrado durante el entrenamiento para que ningún registro individual cambie mucho el modelo, con cierto coste en exactitud. La inferencia de pertenencia concreta el riesgo, ya que incluso las salidas agregadas pueden revelar que se usó el registro de una persona concreta.
13.5 Ejemplo resuelto (caso sintético de NRS)
El almacén vectorial de Wrench contenía en un solo índice los manuales, las notas de los técnicos y los informes de incidentes de seguridad laboral de Recursos Humanos. Cualquier técnico podía recuperar informes de RR. HH. con preguntas hábiles. Sam separó los índices por sensibilidad, añadió listas de control de acceso por documento que se comprueban frente al usuario solicitante en el momento de la consulta y añadió un campo de procedencia (interna/contratista/externa) que la plantilla del prompt usa para marcar el texto no confiable.
Separar los índices no habría bastado por sí solo, ya que un técnico que consulta el índice correcto sigue necesitando una comprobación por documento. El campo de procedencia también facilita las investigaciones: una respuesta que citó texto de un contratista puede rastrearse hasta su documento de origen.
13.6 Errores y límites
- Un solo índice de recuperación para todos los niveles de sensibilidad.
- Comprobar los permisos con la identidad del servicio en lugar de la del usuario.
- Ningún registro de qué datos entrenaron qué modelo.
Un único índice impone un solo modelo de permisos a documentos de sensibilidad muy distinta, de modo que o el acceso es demasiado amplio o el sistema se vuelve inutilizable. Comprobar con la identidad del servicio entrega a cada usuario los derechos del servicio. La falta de registros del entrenamiento convierte las investigaciones de envenenamiento en conjeturas. La revisión de diseño de Sam hace tres preguntas correspondientes: cuántos índices hay y por qué, qué identidad se comprueba en la recuperación y dónde se registra la versión de los datos de entrenamiento de cada modelo.
Ejercicios — capítulo 13
- EX037 — Linaje. ¿Qué tres hechos debe registrar el linaje de un elemento de entrenamiento? Rúbrica: 3 = fuente, momento de recogida/versión, transformaciones (y quién lo añadió); 2 = dos; 1 = uno; 0 = nada.
- EX038 — Acceso en RAG. ¿Por qué debe la recuperación usar la identidad del usuario final? Rúbrica: 3 = de lo contrario, el modelo recupera documentos que el usuario no tiene permitido ver (confused deputy); 2 = parcial; 1 = vago; 0 = incorrecto.
- EX039 — Dominios caducados. ¿Cómo frustran los hashes del contenido el ataque de envenenamiento mediante dominios caducados? Rúbrica: 3 = el contenido descargado que cambió tras la recogida no supera el hash y se rechaza; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
Los datos son la superficie de ataque que entrena e informa a los modelos. El linaje, el control de escritura, los permisos de recuperación por usuario y la minimización de datos los protegen.
Siga estudiando — capítulo 13 de 50
← Capítulo 12 (borrador) · Índice de capítulos del curso · Capítulo 14 (borrador) →