--- title: "Cómo tratar datos personales (PII) en datos de scraping" description: "Los datos de scraping suelen traer datos personales: nombres, perfiles, emails y teléfonos. Cómo detectarlos, reducirlos, enmascararlos y protegerlos." url: https://proxynet.io/es/blog/personal-data-in-scraped-datasets date: 2026-09-28 author: "Acar Diveroli" category: "Web scraping, Proxy 101" lang: es --- # Cómo tratar datos personales (PII) en datos de scraping Haces scraping de 20.000 reseñas de productos para ver qué quejas se repiten más. El plan era quedarte con la puntuación y el texto. Al abrir el CSV, también encuentras los nombres de los autores, enlaces a sus páginas de perfil y, en unos cientos de reseñas, una dirección de email o un número de teléfono que el autor escribió en el texto. Nada de eso sirve para el análisis, pero ahora está en tu portátil y en la copia de seguridad de anoche. Este artículo explica qué cuenta como dato personal en un conjunto de datos obtenido por scraping (a menudo se habla de PII, del inglés *personally identifiable information*, información de identificación personal: todo lo que apunta a una persona concreta), por qué «era público» no zanja la cuestión y cómo tratarlo: recoger menos, enmascarar lo que se cuela, seudonimizar las claves que necesitas y borrar según un calendario. También muestra por qué el hash de un email es más débil de lo que parece, incluye un script de enmascaramiento en Python probado y remite al Reglamento General de Protección de Datos (RGPD), a la KVKK de Türkiye y a la CCPA de California. > **Nota: Respuesta breve** > > Cualquier información sobre una persona identificable es un dato personal, y obtenerla de una página pública por scraping no cambia eso ni en el RGPD ni en la KVKK. Define primero la finalidad y recoge solo los campos que la sirven. Descarta los nombres y enlaces de perfil que no necesites, enmascara emails y teléfonos del texto libre en el momento de la ingesta, sustituye los identificadores que debas conservar por un hash con clave, cifra y restringe el almacenamiento y borra los archivos en bruto según un calendario fijo. Los datos seudonimizados siguen siendo datos personales; solo son anónimos los datos que ya no pueden vincularse con nadie. > **Aviso: Esto no es asesoramiento jurídico** > > Este artículo explica prácticas técnicas y cita la ley a modo de orientación. Si puedes recoger y usar un conjunto de datos concreto depende de tu finalidad, tu base jurídica, las condiciones del sitio y los países implicados. Para un proyecto real, consulta a un abogado especializado en protección de datos o al delegado de protección de datos de tu empresa. ## ¿Qué cuenta como dato personal en un conjunto de datos de scraping? La definición del RGPD en el [artículo 4, apartado 1](https://eur-lex.europa.eu/eli/reg/2016/679/oj/spa) es amplia: «toda información sobre una persona física identificada o identificable», directa o indirectamente, con ejemplos como un nombre, un número de identificación, datos de localización o un identificador en línea. La Ley n.º 6698 de Protección de Datos Personales de Türkiye (KVKK) usa esencialmente la misma formulación en su artículo 3. En un proyecto de scraping, los datos personales aparecen en tres lugares: - **Campos que seleccionas a propósito.** Nombres de autor, nombres de usuario, URL de perfil, avatares, cargos en la página de una empresa, nombres de vendedores en un marketplace. - **Texto libre.** Reseñas, comentarios, mensajes de foros y descripciones de anuncios, donde la gente escribe su email, su teléfono, su calle o la matrícula de su coche. - **Tus propios logs.** Los registros de peticiones y los volcados de errores suelen guardar el HTML completo de la página, con todo lo anterior. Más difícil de ver: campos que por sí solos no identifican a nadie. Un nombre de usuario, una ciudad, una fecha y un producto poco común pueden señalar juntos a una sola persona, así que un conjunto de datos sin columna «nombre» puede contener datos personales igualmente. ## ¿«Público» significa libre de usar? En general, no, y la respuesta cambia según la ley. - **RGPD.** No hay ninguna excepción para los datos personales disponibles públicamente. Los datos de scraping necesitan una base jurídica y deben cumplir los principios del artículo 5. El artículo 14 establece lo que debes a las personas cuyos datos no obtuviste de ellas mismas. - **KVKK.** El artículo 5 enumera las condiciones para tratar datos sin consentimiento explícito. Una de ellas es que la propia persona haya hecho públicos los datos. No es un cheque en blanco: los principios del artículo 4, como la finalidad determinada y la proporcionalidad, siguen aplicándose. - **CCPA.** La definición californiana de información personal del [Civil Code 1798.140](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV§ionNum=1798.140) incluye las direcciones IP y de email entre los identificadores y después excluye la información «publicly available» (disponible públicamente), definida de forma estricta: por ejemplo, registros públicos de la administración o información que el consumidor puso a disposición del público en general. La cuestión jurídica más amplia, incluidas las condiciones de uso y los derechos de autor, está en [¿El web scraping es legal?](/es/blog/is-data-web-scraping-legal). ## Cómo tratar los datos personales en un pipeline de scraping El artículo 25 del RGPD pide «protección de datos desde el diseño y por defecto»: las salvaguardas forman parte del diseño, no de una limpieza al final. Junto con el principio de «minimización de datos» del artículo 5, para un scraper eso significa: 1. **Escribe la finalidad.** «Encontrar las quejas de entrega más frecuentes por producto» es una finalidad. «Recoger reseñas por si resultan útiles» no lo es. 2. **Enumera los campos que la sirven.** Para el ejemplo anterior: producto, fecha, puntuación y texto. El nombre del autor y la URL de su perfil no están en la lista. 3. **Filtra al recoger.** No selecciones lo que no vas a usar. 4. **Enmascara el texto libre en la ingesta.** Sustituye emails y teléfonos por marcadores antes de escribir la fila en cualquier sitio. 5. **Seudonimiza las claves que necesitas.** Si tienes que contar autores que repiten, guarda un hash con clave del ID del autor en lugar del ID. 6. **Guarda la clave aparte.** La clave de seudonimización vive en un gestor de secretos o en una variable de entorno, nunca en el conjunto de datos ni en el mismo repositorio. 7. **Protege el almacenamiento.** Cifra en reposo, limita el acceso a las personas que trabajan en el proyecto y mantén los volcados en bruto fuera de las unidades compartidas. 8. **Borra según un calendario.** El HTML en bruto y los archivos sin enmascarar tienen un plazo de conservación corto; el conjunto de datos limpio tiene el suyo, ligado a la finalidad. 9. **Documenta lo que hiciste.** Finalidad, campos, plazo de conservación y base jurídica, en una nota breve. ## Enmascaramiento, seudonimización y anonimización: la diferencia Estos términos no son intercambiables, y la diferencia decide si la ley sigue aplicándose a tus datos. | Técnica | Qué hace | ¿Se puede volver a identificar a la persona? | ¿Sigue siendo dato personal? | |---|---|---|---| | Eliminación al recoger | El campo nunca se guarda | No, el dato no existe | No, para ese campo | | Enmascaramiento | Sustituye un valor por un marcador como `[EMAIL]` | No a partir del valor enmascarado, pero quizá sí por otros campos | Depende de lo que quede en la fila | | Seudonimización | Sustituye un identificador por un token; el vínculo está en información aparte y protegida | Sí, con la clave o la tabla de correspondencias | Sí (considerando 26 del RGPD) | | Anonimización | Elimina o generaliza datos hasta que nadie pueda ser identificado por medios razonablemente probables | No | No | | Cifrado | Hace ilegibles los datos sin una clave | Sí, para quien tenga la clave | Sí | | Agregación | Guarda solo recuentos, medias o grupos | Solo si los grupos son muy pequeños | Normalmente no, si los grupos son lo bastante grandes | ### Qué dice el RGPD sobre la seudonimización El artículo 4, apartado 5, define la seudonimización como el tratamiento de datos personales de manera que «ya no puedan atribuirse a un interesado sin utilizar información adicional», siempre que esa información figure por separado y esté protegida. El considerando 26 marca después la línea: los datos personales seudonimizados que cabría atribuir a una persona mediante información adicional «deben considerarse información sobre una persona física identificable». La información anónima queda fuera del Reglamento. Para determinar si alguien es identificable, el considerando 26 pide tener en cuenta todos los medios «que razonablemente pueda utilizar el responsable del tratamiento o cualquier otra persona», incluidos el coste, el tiempo y la tecnología disponible. Por eso anonimizar texto obtenido por scraping es difícil: quitar el nombre rara vez sirve si la reseña sigue mencionando el pueblo, la fecha y el modelo de coche. El Comité Europeo de Protección de Datos adoptó sus [Directrices 01/2025 sobre seudonimización](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en) en enero de 2025. La propuesta «Digital Omnibus» de la Comisión Europea, de noviembre de 2025, cambiaría cómo se aplica la definición de datos personales a los datos seudonimizados; según la [página del tren legislativo](https://www.europarl.europa.eu/legislative-train/theme-a-new-plan-for-europe-s-sustainable-prosperity-and-competitiveness/file-digital-package) del Parlamento Europeo, no se había adoptado cuando se escribió este artículo. Mientras no entre en vigor un cambio, trata los datos seudonimizados como datos personales. La KVKK no define la seudonimización. Su artículo 3 define la anonimización como hacer que los datos no puedan vincularse con una persona «ni siquiera cruzándolos con otros datos», y el artículo 7 exige suprimirlos, destruirlos o anonimizarlos cuando desaparece el motivo del tratamiento. ## Por qué el hash de un email no es anonimización Un atajo habitual es aplicar `sha256(email)` y llamar anónima a la columna. No lo es, por dos motivos. Primero, el hash siempre es el mismo. Cualquiera que tenga una lista de direcciones de email, por ejemplo una filtrada en una brecha, puede calcular el hash de cada dirección y buscar coincidencias; en nuestra prueba, una lista de dos candidatos encontró al instante la dirección «anónima». Esas mismas listas filtradas alimentan el [credential stuffing](/es/blog/what-is-credential-stuffing), un motivo más para no guardar emails en claro que no necesitas. Segundo, algunos identificadores tienen un espacio de búsqueda pequeño. Un número de teléfono nacional tiene un número limitado de dígitos, así que calcular el hash de todos los números posibles de ese rango es viable con hardware corriente, y el token que coincide devuelve el número. Lo que funciona mejor: - **Un hash con clave (HMAC) con una clave secreta** guardada lejos de los datos. El resultado son datos seudonimizados, no anónimos. - **Un token aleatorio y una tabla de correspondencias** guardada por separado, si necesitas revertir la asignación. - **Ningún identificador**, si solo necesitas recuentos. Agrega primero y descarta la clave. ## Ejemplo en Python: enmascarar emails y teléfonos El script lee un CSV de reseñas obtenidas por scraping y escribe una copia limpia: descarta las columnas innecesarias, enmascara emails y teléfonos en la columna de texto libre y sustituye el ID del autor por un hash con clave, de modo que todavía se pueden contar los autores que repiten. Solo biblioteca estándar, probado con Python 3.13. ```python import csv import hashlib import hmac import os import re # Columnas que el análisis nunca necesita: se descartan en la ingesta DROP_COLUMNS = {"author_name", "profile_url"} # Columna que solo se conserva como seudónimo, para contar autores que repiten PSEUDONYM_COLUMN = "author_id" # Columnas de texto libre donde la gente escribe datos de contacto; las estructuradas no se tocan TEXT_COLUMNS = {"text"} EMAIL_RE = re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}") # Secuencias con aspecto de teléfono: + o ( opcional y luego 9-15 dígitos con espacios, puntos, guiones o paréntesis entre ellos PHONE_RE = re.compile(r"(? str: text = EMAIL_RE.sub("[EMAIL]", text) return PHONE_RE.sub("[PHONE]", text) def pseudonym(value: str) -> str: # Hash con clave (HMAC-SHA256): sin la clave, nadie puede reconstruir la asignación probando candidatos return hmac.new(SECRET, value.encode(), hashlib.sha256).hexdigest()[:16] def clean_row(row: dict) -> dict: out = {} for col, value in row.items(): if col in DROP_COLUMNS: continue if col == PSEUDONYM_COLUMN: out[col] = pseudonym(value) elif col in TEXT_COLUMNS: out[col] = mask_text(value) else: out[col] = value return out def main(src: str, dst: str) -> None: if not SECRET: raise SystemExit("Set PSEUDONYM_KEY first") with open(src, newline="", encoding="utf-8") as f_in, \ open(dst, "w", newline="", encoding="utf-8") as f_out: reader = csv.DictReader(f_in) fields = [c for c in reader.fieldnames if c not in DROP_COLUMNS] writer = csv.DictWriter(f_out, fieldnames=fields) writer.writeheader() for row in reader: writer.writerow(clean_row(row)) if __name__ == "__main__": main("reviews_raw.csv", "reviews_clean.csv") ``` Ejecútalo con la clave definida en el entorno (`export PSEUDONYM_KEY=...` en Linux y macOS, `$env:PSEUDONYM_KEY="..."` en PowerShell) y luego `python mask_pii.py`. En nuestra muestra inventada, «Llámame al +90 532 000 00 00 o al (0212) 000-0000» se convirtió en «Llámame al [PHONE] o al [PHONE]», los emails pasaron a `[EMAIL]` y las dos reseñas de un mismo autor recibieron el mismo token. Conoce sus límites: - **La expresión regular enmascara de más.** En nuestras pruebas, el patrón de teléfono también tapó un ISBN de 13 dígitos, un número de pedido de 10 dígitos y una fecha escrita junto con una hora. Por eso el script solo toca las columnas de texto libre. - **La expresión regular se queda corta.** No detecta números escritos con letras, «nombre arroba dominio punto com», IBAN, direcciones ni nombres dentro del texto; para eso hace falta un modelo de reconocimiento de entidades o una revisión manual de una muestra. - **Enmascarar no es anonimizar.** La fila conserva texto, fecha y producto; comprueba si eso por sí solo puede señalar a una persona. Aplica este paso donde se escriben las filas por primera vez, no como una tarea posterior. La [guía de limpieza con pandas](/es/blog/clean-scraped-data-with-pandas) muestra dónde encaja en una limpieza completa, y [cómo guardar datos de scraping en CSV, JSON y SQLite](/es/blog/save-scraped-data-csv-json-sqlite) trata el almacenamiento. ## Seguridad del almacenamiento, acceso y conservación El artículo 32 del RGPD pide un nivel de seguridad «adecuado al riesgo» y menciona la seudonimización y el cifrado, la resiliencia de los sistemas, la restauración de los datos tras un incidente y las pruebas periódicas. El artículo 12 de la KVKK establece un deber parecido. Para un scraper eso significa: - **Cifrado en reposo** para los discos, buckets y bases de datos que guardan scraping en bruto. - **Zonas separadas.** El HTML en bruto y las filas sin enmascarar en un lugar restringido; el conjunto de datos limpio donde trabajan los analistas. - **Acceso mínimo.** Solo las personas y cuentas de servicio que necesitan la zona en bruto pueden leerla. - **Conservación como código.** Una tarea programada de borrado vale más que un documento de política. - **Las copias de seguridad cuentan.** Un archivo que sigue vivo en una copia de hace un año no se ha borrado. Alinea ambos plazos de conservación. Nuestra página de [seguridad de datos](/es/data-security) trata los proxies en el trabajo de seguridad; un proxy cambia la IP desde la que sale una petición, no lo que guardas. ## Dónde aparece esto - **Seguimiento de precios y stock.** Las páginas de producto rara vez contienen datos personales, pero los nombres de vendedores en marketplaces sí pueden. Consulta [cómo hacer seguimiento de precios de la competencia](/es/blog/competitor-price-tracking). - **Análisis de reseñas y de sentimiento.** Campos de autor y datos de contacto dentro del texto. Consulta [estudios de mercado](/es/market-research). - **Investigación y minería de datos.** Los mensajes de foros están llenos de datos personales; agrega pronto. Consulta [qué es la minería de datos](/es/blog/what-is-data-mining). - **Rastreos grandes.** Un [web crawler](/es/web-crawler) general recoge páginas enteras, así que todo lo que contienen acaba en tu almacenamiento si no filtras. - **Listas de contactos comerciales.** Recoger datos de contacto de particulares para captación es el caso de mayor riesgo; revisa antes la ley y las condiciones del sitio. ## Errores comunes - Hacer scraping de la página entera «por si acaso» y dejar el volcado en bruto guardado indefinidamente. - Llamar «anonimizado» a un SHA-256 de un email. - Guardar la clave de seudonimización en el mismo repositorio o bucket que los datos. - Enmascarar la tabla de análisis, pero no los logs, los volcados de errores ni el HTML de depuración. - Ignorar `robots.txt` y las condiciones del sitio porque los datos «ya son públicos». [robots.txt](/es/blog/robots-txt) indica lo que el propietario permite rastrear. - Conservar los datos al terminar el proyecto porque nadie es responsable del borrado. - Dar por hecho que se aplican las normas de tu país cuando las personas del conjunto de datos viven en otro. ## Guía de decisión | Necesidad | Recomendación | |---|---| | Análisis de precios, stock o datos de producto | No recojas campos de vendedores ni de usuarios | | Análisis de texto de reseñas o comentarios | Descarta los campos de autor y enmascara los datos de contacto del texto en la ingesta | | Contar autores que repiten o seguir una cuenta en el tiempo | Hash con clave (HMAC) del ID, con la clave guardada aparte | | Compartir un conjunto de datos con un cliente o publicarlo | Agrega y después revisa grupos pequeños y combinaciones poco comunes | | Guardar HTML en bruto para depurar | Conservación corta, zona restringida, cifrado | | Los datos de contacto de particulares son la finalidad | Detente y pide asesoramiento jurídico antes de recoger nada | ## Preguntas frecuentes ### ¿Los datos públicos obtenidos por scraping están exentos del RGPD? No. El RGPD no tiene ninguna excepción general para los datos personales disponibles públicamente. Sigues necesitando una base jurídica, el artículo 5 sigue aplicándose y el artículo 14 regula la información que debes a las personas cuyos datos no obtuviste de ellas mismas. ### ¿Una dirección IP es un dato personal? Puede serlo. El RGPD menciona los identificadores en línea en el artículo 4, apartado 1, y la CCPA cita la «Internet Protocol address» (dirección IP) entre sus ejemplos de identificadores. En el scraping importa sobre todo en tus propios logs. ### ¿Un hash hace anónimos los datos? No. Un hash simple de un email o un teléfono se puede revertir calculando el hash de una lista de candidatos. Un hash con una clave secreta guardada en otro lugar es seudonimización, y el RGPD sigue considerándolo dato personal. ### ¿Qué dice la KVKK sobre los datos que una persona hizo públicos? El artículo 5 permite tratarlos sin consentimiento explícito cuando la propia persona los hizo públicos. Los principios del artículo 4, como la finalidad determinada y la proporcionalidad, siguen aplicándose. ### ¿Cuánto tiempo puedo conservar datos personales obtenidos por scraping? Solo el tiempo que exija la finalidad. El artículo 5 del RGPD lo llama «limitación del plazo de conservación», y el artículo 7 de la KVKK exige suprimirlos, destruirlos o anonimizarlos cuando desaparece el motivo del tratamiento. ### ¿Usar un proxy cambia mis obligaciones? No. Un proxy envía las peticiones a través de otra dirección IP. No cambia lo que recoges, dónde lo guardas ni qué leyes se aplican. ## En resumen Los datos personales rara vez llegan a un conjunto de datos de scraping porque alguien los quisiera; vienen con la página. La solución es sobre todo de ingeniería: define la finalidad, recoge solo los campos que la sirven, enmascara lo que se cuela en el texto libre, seudonimiza las claves con un secreto guardado en otro lugar, cifra el almacenamiento y borra según un calendario. Los datos seudonimizados siguen siendo datos personales para el RGPD; anónimo significa que nadie puede ser identificado por medios razonablemente probables. Para la parte de la recogida, consulta [extracción de datos web](/es/data-scraping): un [Proxies residenciales](https://proxynet.io/es/residential-proxy) te permite elegir país y ciudad, un [Proxies rotativos](https://proxynet.io/es/rotating-proxy) reparte las peticiones y nuestra página de [proxies](/es/proxy) reúne todos los productos.