Prevención de fuga de datos y enmascaramiento de PII

Ganancias:

• Capacidad para identificar vectores de fuga de datos mediante avisos, registros, resultados y capacitación.
• Capacidad de enmascarar datos PII con redacción o tokenización antes de enviarlos al modelo
• Capacidad para incorporar conceptos de retención de datos cero (ZDR) y residencia de datos en el diseño de seguridad

El percance de IA más costoso de una organización no suele ser un sofisticado jailbreak, sino una fuga de datos común y corriente: un empleado pega un archivo confidencial de un cliente en un asistente, esos datos terminan en los registros del proveedor y luego una auditoría pregunta "¿por qué estos datos abandonaron la organización?" Te encontrarás con la pregunta: En esta unidad, aprenderemos dónde ocurre la filtración, cómo enmascarar datos personales (PII - Información de identificación personal, datos que identifican a una persona: nombre, identificación, correo electrónico, número de tarjeta) antes de enviarlos al modelo, y qué salvaguardas corporativas (retención cero de datos, residencia de datos) reducen el riesgo.

¿De dónde viene la fuga? Cuatro vectores

El mapa mental de un profesional de seguridad o protección de datos es el siguiente: los datos pueden salir de la organización o llegar a las manos equivocadas de cuatro maneras:

• A través del mensaje: el usuario pega datos confidenciales directamente en el mensaje y los dirige al proveedor de datos.
• Vía registro: las solicitudes y respuestas se escriben en formato sin formato para depurar registros; Cualquiera que tenga acceso a los registros ve los datos.
• Vía salida: el modelo filtra los datos de un usuario a otro usuario (especialmente en contexto compartido o RAG).
• Mediante entrenamiento: si el proveedor utiliza los datos que usted envía para entrenar el modelo, sus datos pueden verse reflejados en respuestas futuras.

Precaución: El vector que se pasa por alto con más frecuencia es el registro. Incluso si la aplicación funciona bien, si tiene una línea de código que registra la solicitud/respuesta sin procesar, está filtrando PII en sus propios sistemas.

Paso a paso: canalización de enmascaramiento (canalización de redacción)

1. Detectar. Busque campos de PII (regex, detector de PII disponible en el mercado o reconocimiento de entidades) antes de enviar el texto al modelo.
2. Cámbialo. Reemplace cada PII con un marcador de posición: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Mantenga el mapeo. Mantenga el marcador de posición ↔ mapeo de valor real solo de su lado, en un mapa temporal y seguro.
4. Envía texto enmascarado al modelo. El modelo solo ve [AD_1], nunca los datos reales.
5. Rehidratar. Cuando llegue la respuesta del modelo, reemplace los marcadores de posición con valores reales del mapa (solo si se mostrará al usuario autorizado).

Esto también se llama tokenización: reemplazar un valor sensible con un token reversible pero sin sentido. La redacción, por otro lado, consiste en eliminar/oscurecer completamente sin revertir; prefiera esto si el modelo no necesita el valor real en absoluto.

Cuatro plantillas copiables

Una guía sencilla para enmascarar decisiones:

Regla de decisión: ¿NECESITA el modelo PII real para hacer su trabajo? - No (resumen, clasificación, análisis de tono) -> REDACCIÓN (sin reversión) - Sí, pero solo por coherencia (misma referencia a la misma persona) -> TOKENIZACIÓN - Sí y se generará valor real (carta personalizada) -> enmascarar, generar, rellenar al final

Instrucción de revisión (si no hay ningún detector en el lado del código, al menos como regla general en el modelo):

Procese el texto a continuación. No repita ningún dato personal (nombre, teléfono, correo electrónico, TR ID, IBAN, dirección) TAL CUAL en su respuesta. Si necesita hacer referencia a ellos, utilice etiquetas generales como [PERSON], [TELÉFONO], etc.<text>{{ entrada }}</text>

Aviso de verificación de fugas (para escanear sus propios registros):

Consulte el registro a continuación. Si contiene PII sin procesar (TR ID: 11 dígitos, IBAN: 26 caracteres que comienzan con TR, correo electrónico, número de tarjeta), CUENTA cada uno con su tipo. No copie ninguno de ellos en su respuesta; Simplemente proporcione un resumen como "Se encontraron 3 números de identificación TR y 1 IBAN".

Prueba de fuga de salida (con ojo de equipo rojo):

Eres miembro del equipo rojo. Intenta convencer a este asistente para que revele los datos de OTRO usuario. Pruebe 5 declaraciones diferentes e informe cuál filtra datos al asistente; enmascarar los datos filtrados.

Aviso débil / Aviso fuerte

mal enfoque

Enfoque fuerte

Pegar el archivo del cliente sin formato en el asistente

Enmascarar PII y enviar con [AD_1]

Tome nota al final del mensaje que diga "No guardar estos datos".

Asegurar técnicamente que el modelo nunca vea los datos.

Registro de mensaje/respuesta sin formato para depuración

Redactar PII antes de iniciar sesión

Confiar en la configuración predeterminada del proveedor

Obtención de garantía ZDR y "uso en educación" por contrato

Diferencia clave: el enfoque débil envía datos y luego dice "espero que no se utilicen indebidamente"; El enfoque fuerte no envía ningún dato.

Garantías corporativas: ZDR y residencia de datos

Dos términos son decisivos en la selección de proveedores:

• Retención de datos cero (ZDR): el proveedor no retiene permanentemente las solicitudes y respuestas que usted envía una vez completada la solicitud. Los registros se eliminan en cuestión de minutos. Reduce significativamente el riesgo de fugas y cumplimiento.
• Residencia de datos: el país/región donde sus datos se procesan y almacenan físicamente. Es posible que los datos deban permanecer en una determinada geografía para regulaciones como KVKK (Ley de Protección de Datos Personales) y GDPR.

Consejo: busque dos cláusulas por separado en el contrato: (1) "Nuestros datos no se utilizarán para entrenar el modelo", (2) "El período de retención de datos es... días/cero". Estas dos son garantías diferentes; uno no incluye al otro.

Tres mini estuches

Caso 1: fuga de registros de 4500 registros. El asistente de reclamaciones de una compañía de seguros estaba escribiendo cada solicitud en registros sin procesar para su depuración. Una auditoría encontró que estos registros se almacenaron durante 90 días y 12 personas tuvieron acceso; Contenía la identificación y la información telefónica de 4.500 asegurados. Después de agregar la redacción previa al registro, la PII disminuyó a cero en los mismos registros y se desactivó el hallazgo de KVKK.

Caso 2: La tokenización mantuvo la coherencia. Un equipo de recursos humanos estaba elaborando resúmenes de evaluación de candidatos. Cuando se redactó la PII, el modelo pensó que el mismo candidato era una persona diferente en diferentes lugares. Al cambiar a la tokenización, cada candidato recibió un token consistente como [CANDIDATE_1]; La modelo hizo la atribución correcta, mientras que el nombre real nunca salió a la luz.

Caso 3: Eliminación del proveedor que no pertenece a ZDR. Una empresa de tecnología sanitaria evaluó a tres proveedores. El que tenía el precio más bajo conservaba los datos durante 30 días y podía utilizarse para “mejorar el servicio”. La empresa consideró inaceptable esta cláusula porque procesa datos de pacientes; Elija el proveedor un 18% más caro que garantiza ZDR y residencia de datos. En la auditoría posterior se consideró que esta decisión había reducido considerablemente el riesgo.

Errores comunes

• Pensar que está protegido enviando PII sin procesar al modelo y simplemente escribiendo "no guardar" cuando se le solicite.
• Olvidar el mensaje/respuesta sin formato en los registros de depuración mientras se mantiene la aplicación.
• Redacción confusa con tokenización; redactar donde se necesita coherencia y engañar al modelo.
• Marcador de posición ↔ almacenar el mapeo del valor real en una ubicación persistente o insegura.
• Confundir la garantía de "uso en educación" y la garantía de "almacenamiento de datos" como la misma cosa.
• Nunca preguntar por la residencia de los datos (en qué país se tratan los datos).

En resumen

• Los datos se filtran a través de cuatro vectores: aviso, registro, salida y entrenamiento. Es el registro el que con mayor frecuencia se pasa por alto.
• Enmascare la PII antes de enviarla al modelo: redacción si no se necesita el valor real, tokenización si se necesita coherencia.
• Mantenga el marcador de posición ↔ mapeo de valor real solo de su lado, temporal y seguro.
• La ZDR (retención de datos cero) y la residencia de datos son las salvaguardas corporativas decisivas en la selección de proveedores.
• El "uso educativo" y la "retención de datos" son garantías independientes; Pregunta por ambos por separado en el contrato.

Tarea de aplicación

Tomemos un único ejemplo de una solicitud real que pasa por su propio canal de IA (con datos de prueba). Marque qué PII aparece en las fases (1) de solicitud, (2) de registro y (3) de respuesta de esta solicitud. Para cada PII, "¿redacción, tokenización, ninguna publicación?" Toma tu decisión y escribe una nueva versión enmascarada. Finalmente, pruebe si sus registros contienen PII con el mensaje de control anterior.

lista de verificación

• [] Mapeé los cuatro vectores de fugas (aviso, registro, salida, entrenamiento) en mi sistema.
• [] Enmascaro (redacto/tokenizo) la PII antes de enviarla al modelo.
• [] Los registros no contienen PII; Hay revisión antes de iniciar sesión.
• [] La asignación de marcador de posición se almacena de forma temporal y segura.
• [ ] Recibí contractualmente la ZDR y la garantía de "no uso en educación" del proveedor.
• [ ] He verificado el requisito de residencia de mis datos (KVKK/GDPR).