grahama1970/anonymize-data

Anonimizar datos

Opera el proyecto canónico oai-trial. No dupliques su motor de coincidencia, adaptadores de formato, verificador, esquemas o manejo de errores en esta habilidad. La CLI argparse existente del proyecto se conserva intencionalmente; este envoltorio no añade una CLI de Python ni un servicio.

Configuración y operación principal

ANONYMIZE_DATA_ROOT anula el checkout primario predeterminado anterior. La configuración necesita uv e instala las dependencias de desarrollo/descubrimiento declaradas del proyecto. Las operaciones en tiempo de ejecución no necesitan Memoria, credenciales de proveedor, LLM, red ni servicio de base de datos.

./run.sh setup
./run.sh --input /data/exports --policy /data/policy.json --output /data/release
./run.sh anonymize --input /data/export.sqlite --policy /data/policy.json --output /data/release

La entrada es un archivo .csv, .json, .txt o .sqlite, o un directorio de esos archivos. La política debe ser un archivo regular separado. Utiliza un directorio de salida vacío dedicado, fuera de los directorios de entrada. Los originales se copian en una instantánea temporal privada; la salida exitosa contiene solo corpus/ y report.json.

La interfaz de paquete (bundle) existente permanece disponible:

./run.sh run --input /data/bundle --output /data/release
./run.sh verify --input /data/bundle --output /data/release
./run.sh inspect /data/release

Un paquete contiene policy.json y corpus/. La política, la identidad canónica, las reglas de valores protegidos, los fallos tipificados y el esquema del informe son propiedad del proyecto. Lee su README.md, docs/ANONYMIZATION_SEMANTICS.md y schemas/report.schema.json al interpretarlos. No declares el éxito solo por un código de salida: lee el informe real, valida sus campos de estado de preparación e inspecciona la salida para el formato solicitado. Los informes corruptos o faltantes no están LISTOS (READY).

Descubrimiento opcional con RapidFuzz: nunca reemplazo automático

./run.sh discover --input /data/exports --policy /data/policy.json --output /data/work/review.json
./run.sh approve-discovery --input /data/exports --policy /data/policy.json \
  --review /data/work/review.json --approve CANDIDATE_ID --output /data/work/approved-policy.json
./run.sh --input /data/exports --policy /data/work/approved-policy.json --output /data/release

El descubrimiento compara valores completos de cadenas estructuradas y líneas de texto completas contra las entradas de política de tipo name. No es una extracción de tramos NLP ni un escáner general de PII. Valores predeterminados: umbral de similitud 90, margen de separación 5; configurables con --threshold y --margin. No se proponen empates, casi empates, valores protegidos, valores que contienen dígitos o puntuación de identificadores como @, /, _, y literales ya conocidos. Se permiten apóstrofes, guiones y puntos en texto con forma de nombre; la similitud nunca es prueba de que dos personas sean la misma.

Pide al operador que apruebe IDs de candidatos específicos. Nunca apruebes solo por la puntuación de similitud. La aprobación vuelve a derivar las propuestas contra la política/el corpus actual, rechaza revisiones obsoletas/editadas y compila una política de coincidencia exacta. Las propuestas no aprobadas nunca afectan la anonimización. release_ready: false es obligatorio en los recibos de descubrimiento/aprobación.

Los archivos de revisión y política aprobada contienen nombres sin procesar: mantenlos fuera de los lanzamientos, registros e informes compartidos. Se crean con modo 0600 y nunca sobrescriben un archivo existente. Las instantáneas temporales se ubican por defecto en la unidad de artefactos; anula con ANONYMIZE_DATA_WORK_DIR cuando sea necesario.

Docker sigue siendo la interfaz independiente

Desde el checkout del proyecto:

docker build -t anonymization-trial .
docker run --rm anonymization-trial
# Imagen opcional con descubrimiento habilitado; la imagen por defecto mantiene la dependencia del motor exacto libre.
docker build --build-arg INCLUDE_DISCOVERY=1 -t anonymization-trial:discovery .

Monta solo la entrada/política solicitada en modo solo lectura y un directorio de salida dedicado. La misma CLI del proyecto se ejecuta dentro de la imagen; el evaluador no necesita esta habilidad. Consulta docs/DISCOVERY.md del proyecto para ejemplos completos de comandos montados.

Límite de fallos y prueba

El envoltorio conserva los códigos de salida del proyecto y los códigos de error saneados. La falta del proyecto/configuración y las rutas de paquetes instalados incorrectas fallan antes del procesamiento. Usa --help para el contrato real de argumentos. El descubrimiento es material de revisión, no un lanzamiento, garantía de anonimato, probabilidad de confianza o autorización humana.

./sanity.sh ejecuta comprobaciones CLI reales positivas, negativas y adversarias. El fixtures/agentic_eval.json retenido las repite y requiere la relectura del artefacto. La calificación previa de prueba no califica automáticamente estas extensiones posteriores a la prueba.

Regla de representación (operador 2026-09-11)

El PII debe coincidir con el valor, no con la cadena: antes de que cualquier escalar JSON/SQLite se pase sin cambios, conviértelo a cadena canónicamente (números con forma de teléfono en formato E.164) y ejecuta la coincidencia de política en la forma convertida a cadena. Los fixtures deben incluir cada clase de PII en cada tipo escalar JSON. Un número de teléfono almacenado como entero es el mismo número de teléfono, incluso cuando la política lo escribe como una cadena formateada como 555-123-4567 y el corpus almacena 5551234567. Las conversiones numéricas con pérdida de precisión de cero a la izquierda o de punto flotante deben fallar de forma cerrada a menos que una regla canónica específica de tipo demuestre una equivalencia segura. Consulta $best-practices-skills "Matriz de representación de valores".

Lecciones de endurecimiento (no las reaprendas por las malas)

La prueba fue descalificada porque un teléfono almacenado como entero JSON/SQLite pasó el matcher de solo cadenas. La causa raíz fue un error de proceso: la comprobación de aceptación se redactó a partir de lo que el código hacía, no de la especificación entregada. Estas reglas existen para que ese tipo de error no pueda repetirse.

1. Deriva la comprobación de la especificación, no del código. policy.json lista los valores sensibles exactos. La comprobación de aceptación correcta es "ninguno de esos valores aparece en la salida decodificada, en ninguna representación" — lee los valores del archivo de política, nunca de una lista escrita a mano. Prueba que la comprobación depende de la especificación con una sonda de dependencia (cambia un valor de política → el resultado debe cambiar). Implementación de referencia: scripts/spec_derived_check.py del proyecto, integrado en scripts/verify.sh.

2. El verificador independiente no debe compartir ninguna suposición con la transformación. El verificador original tenía el mismo punto ciego de solo cadenas que el productor, por lo que nada falló de forma cerrada. El oráculo de verificación debe ser consciente de la representación e independiente: analizar JSON (decodificar \uXXXX), expandir escalares numéricos a formas entero/decimal, normalizar ambos lados en NFC/NFD, escanear celdas de tablas+ vistas DE SQLite Y el DDL de sqlite_master Y cada entero de cabecera, y escanear todo el límite del lanzamiento, incluido report.json, no solo corpus/.

3. La clase de representación completa es una lista de verificación, no un solo error. Cada uno de estos puede transportar un valor sensible más allá de un matcher ingenuo; el proyecto corrige y retiene un guardia para cada uno: escalares numéricos tipificados (int/float, notación científica), BLOB de SQLite (fallo cerrado), Unicode NFC/NFD, reconstrucción de vistas, residuo de freelist, esquema DB hostil (índices de expresión/parciales, vistas no deterministas, DEFAULTs computados), literales de esquema DDL y enteros de cabecera persistentes. Consulta docs/SECURITY_REMEDIATION.md del proyecto para la tabla completa.

4. Pruébalo a través de la ruta real de Docker, de forma determinista. La verificación debe ser un script comprometido que construya la imagen, ejecute los comandos exactos del briefing y lea los bytes lanzados con salidas PASS/FAIL duras, no con prosa de agente. Referencia: security/docker_brief_contract.py (construcción + ambos comandos del briefing + escaneo de fugas consciente de representación + precondición de entrada) y security/docker_hardening_matrix.py (agujeros adversarios a través de docker run). Registra el commit de git y el id de la imagen construida.

5. Alcance honestamente. Los seudónimos deterministas de espacio de nombres público revelan igualdad/frecuencia y no ofrecen resistencia a enlaces externos; el informe de ejecución lo indica en key_mode y does_not_establish. Un valor de política igual a una constante de formato SQLite obligatoria es una entrada degenerada, no PII real; la tubería falla de forma cerrada sobre ella y ese residuo se documenta como limitado.