PII en Fabric: ¿qué harías al ingerir datos sensibles?

Las columnas de texto libre de las exportaciones es donde se esconden nombres, teléfonos y correos. Esas mismas columnas suelen contener códigos y direcciones que la política sigue permitiendo. Vaciarlo todo es lo cómodo. Repartir regexp_replace por todo un notebook es la forma de que dos ingenieros oculten datos de manera distinta el mismo viernes.

Pon el contrato de ocultación en una celda de configuración que reutilice el resto del notebook. Los flags, los tokens, los patrones y los helpers de nombres conocidos pasan a poder revisarse. Las decisiones de riesgo residual salen del historial del chat y entran en el artefacto que promocionas.

Figura 1. La ocultación como puerta de publicación. Configuración compartida, tokens estables y una ruta de escritura que no puede ejecutarse si se ha saltado la limpieza.

Contexto y restricción

Un fallo habitual: notebooks de exportación en los que una ejecución elimina los teléfonos y otra los deja en un campo de comentarios. El lakehouse está bien. La ruta de publicación es folclore. Las revisiones de privacidad preguntan qué ocultamos. La respuesta honesta es "lo que recordara la última persona".

Todo lo que cruza la frontera del lakehouse debería pasar por las mismas reglas. La ocultación basada en configuración hace visibles esas reglas: qué eliminas, qué conservas, qué token sustituye a qué y qué riesgos residuales aceptaste a propósito.

La figura 2 es la página de Learn sobre los ámbitos de las sensitivity labels. Las etiquetas clasifican y controlan el acceso. No sustituyen una reescritura en el notebook de la ruta de exportación.

Figura 2. El tratamiento de PII es un contrato de gobierno. Los ámbitos de las etiquetas y las reglas de ocultación van en una configuración revisable, no en el folclore de los notebooks. Fuente: Microsoft Learn: sensitivity labels.

La figura 3 explica por qué la configuración de ocultación va junto al notebook que es dueño de la exportación. Los revisores necesitan ver qué se entrega con el artefacto.

Figura 3. Mantén la configuración de ocultación junto al notebook dueño de la ruta de exportación para que los revisores vean qué se entrega con el artefacto. Fuente: Microsoft Learn: how to use notebooks.

Diseño

1. Una celda de configuración, muchos consumidores

Declara una sola vez, cerca del principio, los flags de activación, las listas de columnas, los patrones regex, los tokens de sustitución y los hooks opcionales de UDF. Las celdas posteriores importan esa configuración. No vuelvas a implementar la eliminación de teléfonos tres veces con tres patrones distintos. Las diferencias entre celdas son un bug de privacidad disfrazado de cuestión de estilo. Si un segundo notebook exporta la misma granularidad, comparte un módulo o un fragmento de notebook para que el contrato no se degrade a base de copiar y pegar.

2. Separa en el texto libre lo que la política permite de lo que prohíbe

Los nombres, los teléfonos personales y los correos personales normalmente se eliminan. Los códigos de referencia, los identificadores operativos y muchas direcciones postales pueden quedarse según una política escrita. Codifica esa separación con ejemplos. Un único martillo de "limpiar todas las cadenas" destruye el valor analítico y enseña a la gente a saltarse el notebook. Y el atajo acaba siendo la ruta de producción real.

La figura 4 es la separación que escribes una vez para que cada extracción deje de redescubrirla.

Figura 4. Separación del texto libre según la política. Discute personal frente a operativo una vez, escribe ejemplos y deja de redescubrir la regla en cada extracción.

3. Tokens estables y revisables

Sustituye las coincidencias por tokens como {{EMAIL}} o {{PHONE}} que los procesos posteriores puedan contar y auditar. Borrar de forma aleatoria dificulta detectar huecos. Los tokens estables también ayudan a soporte a demostrar que una extracción se procesó cuando alguien pregunta si un nombre pudo sobrevivir. Cuenta los tokens en las pruebas igual que cuentas filas en los trabajos de paridad.

4. Una UDF de nombres conocidos como capa deliberada

Las regex se pierden nombres informales y dan falsos positivos. Una lista o una UDF de nombres conocidos es una segunda pasada con responsable: quién actualiza la lista, con qué frecuencia y qué pasa con lo que se escapa. Documenta el riesgo residual de cargos y tratamientos si los dejas a propósito. Esa decisión va en el contrato, no en un hilo de Slack del trimestre pasado.

5. Trata la ocultación como una puerta, no como un detalle

Configura el notebook para que la publicación falle en cerrado cuando se salta la celda de ocultación o los flags están desactivados en prod. La limpieza opcional en modo de depuración está bien en local. La limpieza opcional en la ruta que escribe en una ubicación compartida es un fallo de control. Haz que la ruta de salida dependa de que el paso de ocultación termine bien en la misma ejecución.

6. Prueba con fixtures que incluyan casi coincidencias

Mantén un conjunto pequeño de fixtures: correos evidentes, los formatos de teléfono que te importan, códigos que parecen teléfonos, direcciones que deben sobrevivir y nombres junto a cargos. Comprueba los recuentos de tokens y las cadenas permitidas que sobreviven. Revisar capturas de pantalla no es un control de privacidad. Vuelve a ejecutar los fixtures cuando alguien "mejore" un patrón.

La figura 5 es el ciclo operativo de cuatro partes que mantiene honesta la puerta después del primer merge.

Figura 5. Tokens estables, una pasada de nombres conocidos con responsable, fixtures con casi coincidencias y una puerta de publicación que falla en cerrado. Las métricas van en la salida de la ejecución que los revisores leen por encima.

Mecánica de la puerta de publicación que aguanta

Configura la ruta de exportación para que la escritura en la ubicación de salida no pueda ejecutarse salvo que la ocultación haya terminado con los flags adecuados para esa etapa. La depuración local puede saltársela con un aviso bien visible. Las ejecuciones en el workspace compartido que generan archivos para partners no pueden. Acompaña la puerta de una celda de métricas sencilla: filas procesadas, tokens emitidos por tipo y columnas tocadas. Esas métricas van en la salida de la ejecución que los revisores leen por encima antes de aprobar una compartición.

Errores comunes

Arqueología de regex celda a celda. Nadie puede decir qué oculta el notebook sin leer todas las celdas.

Vaciar direcciones y códigos que la política permite. Los usuarios exigen un atajo. El atajo se convierte en la ruta real.

Sustituciones inestables. A veces se borra, a veces se enmascara, a veces se aplica un hash. Los auditores no pueden cuadrar nada.

Dejar sin decidir los cargos y las notas de texto libre. "Ya lo veremos más adelante" significa que las exportaciones de producción salen con nombres de personas junto a sus puestos.

Ocultar solo las columnas bonitas. Los campos de comentarios, descripciones y notas son donde de verdad vive la PII.

Confiar en las etiquetas sin un paso de reescritura. Los datos etiquetados salen igualmente si el notebook de exportación nunca los limpió.

Úsalo tal cual o adáptalo

Úsalo tal cual

• Todas las extracciones que salen del lakehouse usan un módulo de configuración de ocultación compartido o un contrato en una celda del notebook.
• Las categorías de texto libre permitidas y prohibidas están escritas con ejemplos.
• Los tokens de sustitución son estables y se cuentan en las pruebas.
• Las decisiones sobre el riesgo residual (por ejemplo, los cargos) son explícitas en el contrato.
• Las rutas de publicación fallan si la ocultación está desactivada fuera de los modos de depuración aprobados.
• Las pruebas con fixtures cubren teléfonos, correos, nombres y códigos que la política permite.

Adáptalo antes de usarlo

Una configuración compartida se cambia más despacio que un reemplazo puntual. Esa fricción es útil. Las reglas de privacidad no deberían ser algo informal. Los falsos positivos en códigos exigen patrones cuidadosos y listas de permitidos; cuenta con iterar con los responsables del dominio. Las listas de nombres conocidos necesitan un responsable operativo o se pudren. Siempre quedará riesgo residual. El objetivo es un riesgo documentado y acotado, no una certeza mágica. También dedicarás tiempo a discutir si un campo es personal u operativo. Ten esa discusión una vez, déjala por escrito y deja de redescubrirla en cada extracción.

Referencias principales: Microsoft Learn sobre data protection and governance in Fabric y sensitivity labeling. Combina las etiquetas de la plataforma con puertas en los notebooks; ninguna sustituye a la otra.

Pon el contrato en la configuración del notebook. Reutilízalo. Pruébalo. Haz que la publicación dependa de él. Las exportaciones de texto libre dejan de ser una sorpresa semanal.