# Informe de preparación de datos y anonimización

## Resumen

Se analizaron **4 documentos**
(4 páginas). De ellos,
**1** contiene datos personales sin anonimizar.

Todo el procesamiento se ha ejecutado en local. Ningún documento ha salido del equipo.

## Documentos que no se pudieron leer

Todos los documentos aportados se pudieron leer.

Un documento ilegible —un PDF corrupto, un `.docx` que no abre— no llega a las cifras de arriba, así que se declara aquí aunque no haya ninguno.

## Cobertura de extracción

**75,0 %** de las páginas contienen texto extraíble, entendiendo por tal
al menos **100 caracteres** por página. El porcentaje se calcula sobre los
documentos que sí se pudieron abrir: los documentos ilegibles de la sección anterior no
entran ni en el numerador ni en el denominador.

La 1 página sin texto extraíble se
reparte así:

| Tipo de fichero | Páginas sin texto |
|---|---|
| `.txt` | 1 |

La causa depende del tipo de fichero, y por eso no se cuentan juntas. En un PDF, una página
sin texto suele ser un **escaneo sin OCR**: el contenido está ahí, pero como imagen, y un
asistente de IA no puede leerlo. En un `.txt` o un `.docx` no hay escaneo posible: significa
simplemente que el documento es **muy corto**.

## Exposición de datos personales

### Identificadores con formato verificable

| Tipo | Detectados |
|---|---|
| DNI / NIF | 2 |
| Teléfono | 1 |

Estas filas se han reconocido por su formato —letra de control del DNI y del NIE, mod-97
del IBAN, y patrón con palabra de contexto cerca para el NSS y la tarjeta—, no por
parecido, y ahí el formato basta para afirmar el dato. **El teléfono es la excepción**: se
reconoce solo por su forma, sin exigir contexto, así que un expediente o un número de
factura de nueve cifras puede aparecer en esa fila. Está explicado en la Metodología, y es
la fila que conviene contrastar con el documento antes de darla por buena.

### Menciones propuestas por el modelo de lenguaje

| Tipo | Menciones |
|---|---|
| Personas | 3 |
| Lugares | 2 |
| Organizaciones | 2 |

Estas las propone el reconocedor de entidades por parecido con nombres, lugares y
organizaciones, sin ningún formato que verificar, y **requieren revisión manual**. En
documentos jurídicos es habitual que aquí aparezcan encabezados y fórmulas del propio
escrito: en las pruebas de este producto se han medido casos como "la Ley" clasificado como
lugar o "Líquido" —de "Líquido a percibir", en una nómina— como persona. Cuentan como señal
de dónde mirar, no como recuento de datos personales.

## Fragmentación

3 fragmentos generados ·
0 demasiado cortos ·
0 duplicados exactos.

Medido con ventana deslizante de **1000 caracteres** y **100 de
solape**, contando como "demasiado corto" todo fragmento por debajo de
**200 caracteres**. Son parámetros de esta auditoría, no verdades del
dominio: se declaran para que la cifra se pueda comparar con la del sistema que el
despacho tenga o vaya a montar, que casi seguro usa otros.

## Metodología

Extracción con `pypdf` y `python-docx`; detección de datos personales con Microsoft Presidio
y spaCy, con reconocedores de DNI y NIE incluidos en Presidio para español, más
reconocedores propios para teléfono español y para el Número de la Seguridad Social (NSS).
Del catálogo estándar de Presidio se usan además los de **correo electrónico**, **cuenta
bancaria (IBAN)** —validada con mod-97— y **tarjeta de crédito** —validada con Luhn—: por
eso pueden aparecer en la tabla de arriba filas que no son ninguno de los cuatro
identificadores españoles.
El reconocedor de NSS detecta por formato (12 dígitos en grupos 2-8-2) y exige una palabra
de contexto cercana ("nss", "afiliación", "afiliacion", "seguridad", "s.s."); **no valida el dígito de control**
del NSS, así que un NSS con formato correcto pero dígitos de control inválidos también se
marca.
El reconocedor de teléfono detecta por formato (nueve cifras que empiezan por 6, 7, 8 o 9,
con o sin prefijo internacional) y **no exige palabra de contexto**: un número de expediente,
una referencia o un número de factura con esa misma forma se marca como teléfono. Es una
decisión deliberada y medida: exigir contexto elimina esos casos, pero deja fuera teléfonos
reales que en un documento van solos en su línea —el del pie de firma, el del membrete—, y en
una auditoría de datos personales un teléfono que no se declara es peor que uno de más. Si en
la tabla de arriba hay una fila de teléfonos, **conviene revisarla** contra el documento.
Troceado por ventana deslizante. El recuento de tokens usa un **tokenizador propio y
aproximado** (`dhc-aprox-1`), implementado en este paquete y sin ningún dato de
terceros: por cada racha de letras cuenta 1 token cada 4, por cada racha de dígitos 1
cada 3, y 1 por cada signo de
puntuación o símbolo, redondeando hacia arriba. **No reproduce el tokenizador de OpenAI ni
el de ningún otro proveedor**, así que sus cifras no predicen el coste de ninguna API
concreta; sirven para comparar el mismo texto antes y después de una transformación, que es
para lo único que se usan aquí. El recuento de
fragmentos "demasiado cortos" excluye el último fragmento de cada documento cuando ese
documento tiene más de un fragmento, porque con la ventana deslizante ese último fragmento
mide un resto aritmético del troceado, no una señal real de fragmentación; cuando un
documento produce un único fragmento, ese fragmento sí se cuenta si es corto, porque en ese
caso es el documento entero. Ejecución 100% local, sin llamadas de red.

## Alcance

Este informe mide el estado de los documentos aportados. No estima con qué frecuencia el
asistente de IA del cliente inventa contenido o responde de forma incorrecta: esa medición
exige un conjunto de preguntas de referencia y no puede deducirse del corpus.

## Anexo — variación del recuento de tokens al anonimizar

| | Tokens |
|---|---|
| Antes de anonimizar | 298 |
| Después de anonimizar | 302 |
| **Variación medida** | **-1,3 %** |

**Esta cifra no es un ahorro de coste.** Va en anexo, y no entre los hallazgos, porque no
dice nada sobre los documentos del cliente: entre los dos recuentos ocurre una única
transformación, la sustitución de cada dato personal por su etiqueta (`[ES_NIF]`,
`[ES_TELEFONO]`). Esas etiquetas son casi siempre más largas que el dato que ocultan —un
NIF o un teléfono español ocupan muy poco—, así que **la variación puede ser negativa**, es
decir, más tokens después que antes, sin que eso indique ningún problema. Se publica como
constancia de que la anonimización se aplicó y de cuánto texto movió, no como estimación de
facturación de ninguna API. El signo positivo significa menos tokens tras anonimizar.