Conocimiento

Redacción de una política de recopilación de datos de empresa: una plantilla funcional

La mayoría de los equipos que recopilan datos web no tienen normas escritas para ello. Una plantilla de política funcional: alcance, aprobaciones, fuentes, datos personales y retiradas.

Matt Brown

Matt Brown

4 de octubre de 2026 · 11 min de lectura

La mayoría de las empresas que recopilan datos web no tienen normas escritas para hacerlo. Un desarrollador crea un scraper para un proyecto de precios, otro equipo lo copia para investigación de leads, un contratista añade un tercero, y nadie puede decir qué sitios se recopilan, qué datos personales se almacenan ni quién respondería a una queja de un propietario de sitio. El trabajo suele estar bien. El problema es que nadie puede demostrar que está bien.

Una breve política interna soluciona esto. Da a los ingenieros reglas claras por defecto, da a los equipos legales y de seguridad algo que revisar una vez en lugar de cada vez, y da a la empresa una respuesta cuando un cliente, un auditor o un sitio web pregunta cómo recopila datos. Esta guía explica qué debe cubrir dicha política y ofrece una plantilla que puedes adaptar.

Puntos clave

  • Una política de recopilación debe ser lo bastante breve para que los ingenieros la lean: alcance, un paso de aprobación, reglas para las fuentes, reglas para los datos personales, y qué ocurre cuando alguien se opone.
  • Haz que la ruta segura sea la opción por defecto. Las páginas públicas y sin sesión iniciada, la identificación honesta, un ritmo moderado y el respeto del robots.txt no necesitan aprobación especial; todo lo demás sí.
  • Trata las objeciones como objeciones. La autoridad francesa de protección de datos, por ejemplo, espera que los recopiladores excluyan los sitios que se oponen mediante robots.txt o CAPTCHAs.
  • Los datos personales lo cambian todo: define qué puedes recopilar, minimízalos en el momento de la recopilación, establece un periodo de retención y haz posible su eliminación.
  • Nombra a un responsable y un proceso de retirada. La primera queja no es el momento adecuado para decidir quién la responde.
  • Esta plantilla es un punto de partida, no asesoría legal; haz que un abogado la revise frente a tus jurisdicciones y contratos.

Por qué importa una política escrita

Hay tres razones prácticas.

Coherencia. Sin reglas escritas, cada proyecto toma sus propias decisiones sobre robots.txt, ritmo, datos personales y retención. Algunos serán cuidadosos, otros no, y la empresa carga con el riesgo del menos cuidadoso.

Velocidad. Una política con reglas claras por defecto permite que la mayoría de los proyectos empiecen sin necesidad de una reunión. Legal y seguridad revisan la política una vez, y después solo las excepciones.

Pruebas. Los reguladores de protección de datos esperan que los responsables del tratamiento puedan demostrar qué garantías aplican. La autoridad francesa de protección de datos, la CNIL, por ejemplo, ha publicado una guía sobre la recopilación de datos personales mediante web scraping que enumera medidas como definir los criterios de recopilación de antemano, excluir los sitios que se oponen claramente, incluso mediante robots.txt o CAPTCHAs, filtrar los datos innecesarios y eliminar los datos sensibles en cuanto se identifican. Una política escrita es cómo demuestras que esas medidas existen.

Qué debe cubrir la política

SecciónLa pregunta que responde
Propósito y alcance¿A qué actividades y equipos se aplica esto?
Roles¿Quién es el propietario de la política, quién aprueba los proyectos, quién responde a las quejas?
Reglas por defecto¿Qué puede hacer cualquier proyecto sin pedir permiso?
Aprobación¿Qué necesita visto bueno, de quién, con qué información?
Fuentes¿Qué sitios y páginas están dentro de los límites, y cómo tratamos sus señales?
Datos personales¿Qué podemos recopilar sobre las personas, y cómo los minimizamos y protegemos?
Conducta técnica¿Cómo se identifican los recopiladores, regulan el ritmo de las solicitudes y gestionan las credenciales?
Proveedores¿Qué exigimos a los proveedores de proxies y datos?
Almacenamiento y retención¿Dónde residen los datos recopilados, quién puede acceder a ellos, cuánto tiempo los conservamos?
Objeciones y retiradas¿Qué ocurre cuando un propietario de sitio, una persona o un regulador se opone?
Registros y revisión¿Qué registramos, y cuándo revisamos la política?

La plantilla

Adapta el texto a tu empresa, elimina lo que no se aplique y mantenlo breve. El texto entre corchetes es para que lo completes.

1. Propósito y alcance

Esta política rige la recopilación automatizada de datos de sitios web y servicios en línea por parte de [Empresa], sus empleados y sus contratistas, incluyendo scrapers, crawlers, automatización de navegador, y datos comprados a terceros que recopilan en nuestro nombre. No cubre los datos que nuestros propios usuarios nos proporcionan, ni las APIs oficiales usadas bajo sus propios términos, excepto cuando se aplique la sección 6.

2. Roles

  • Propietario de la política: [rol, por ejemplo Responsable de Datos] mantiene esta política y el registro de proyectos de recopilación.
  • Aprobadores: [contacto Legal] y [contacto de Seguridad] aprueban los proyectos que necesitan aprobación según la sección 4.
  • Responsable del proyecto: cada proyecto de recopilación nombra a una persona responsable de seguir esta política.
  • Contacto de retirada: [rol y buzón compartido] recibe y responde a las objeciones según la sección 10.

3. Reglas por defecto para cada proyecto

Cualquier proyecto puede proceder sin aprobación adicional si:

  • recopila solo páginas disponibles públicamente que cualquier visitante puede ver sin iniciar sesión;
  • respeta el robots.txt y otras exclusiones legibles por máquina que se apliquen al recopilador;
  • identifica al recopilador honestamente y no disfraza el tráfico automatizado como una persona concreta;
  • regula el ritmo de las solicitudes de modo que no cause una carga perceptible en el objetivo;
  • no recopila datos personales más allá de lo que permite la sección 6;
  • se registra en el registro de proyectos antes de empezar.

4. Proyectos que necesitan aprobación

Un proyecto necesita aprobación escrita de los aprobadores antes de empezar si:

  • recopila datos personales más allá de los datos de contacto comerciales publicados con fines comerciales;
  • recopila cualquier categoría especial de datos, como salud, religión u opinión política;
  • recopila de páginas tras un inicio de sesión, un muro de pago o cualquier otro control de acceso;
  • continúa después de que un sitio haya mostrado su oposición, incluso mediante robots.txt, un CAPTCHA, un bloqueo, una cláusula contractual o una solicitud directa;
  • recopila para entrenar, ajustar o evaluar modelos de aprendizaje automático;
  • vende, licencia o comparte los datos recopilados fuera de [Empresa].

La solicitud indica el propósito, las fuentes, los campos de datos, los datos personales y su base legal, el volumen esperado, el periodo de retención y el responsable del proyecto.

5. Fuentes y sus señales

  • Preferir una API oficial, un feed de datos o una licencia cuando exista una y cubra la necesidad.
  • Leer y registrar los términos relevantes de cada fuente antes de que empiece la recopilación.
  • Tratar el robots.txt, los límites de frecuencia, los CAPTCHAs, los bloqueos y las reservas publicadas como señales de los deseos del sitio, no como obstáculos a sortear mediante ingeniería.
  • No eludir controles de acceso, medidas técnicas de protección ni autenticación.
  • Dejar de recopilar de una fuente con prontitud cuando esta se oponga, y registrar el cese en el registro.

6. Datos personales

  • Recopilar solo los datos personales que necesite el propósito declarado, y filtrar otros datos personales en el momento de la recopilación cuando sea posible.
  • Nunca recopilar categorías especiales de datos a menos que esté aprobado según la sección 4; si se recopilan por accidente, eliminarlos en cuanto se identifiquen.
  • Seudonimizar los identificadores cuando el análisis no necesite la identidad en sí.
  • No combinar los datos recopilados con otras fuentes para identificar a individuos a menos que esté aprobado.
  • Hacer posible encontrar y eliminar los datos de una persona a petición.

7. Conducta técnica

  • Almacenar las credenciales de proxies, APIs y cuentas objetivo en el gestor de secretos aprobado, nunca en el código.
  • Usar solo proveedores de proxies y datos que cumplan la sección 8.
  • Registrar, para cada ejecución de recopilación, la hora, la fuente, la ubicación de recopilación y la configuración utilizada.
  • Monitorizar los volúmenes de solicitudes y las tasas de error, y pausar la recopilación automáticamente cuando una fuente empiece a rechazar solicitudes.

8. Proveedores

Los proveedores de proxies y datos deben poder demostrar cómo se obtiene su red o sus datos y con qué consentimiento, operar un proceso de conocimiento del cliente (know-your-customer), aplicar una política de uso aceptable, y firmar términos acordes con esta política. El propietario de la política mantiene una lista de proveedores aprobados.

9. Almacenamiento y retención

  • Almacenar los datos recopilados solo en [sistemas aprobados], con acceso limitado a las personas que lo necesiten.
  • Conservar las páginas recopiladas en bruto durante no más de [periodo] y los datos extraídos durante no más de [periodo], a menos que una aprobación establezca un periodo diferente.
  • Eliminar los datos al final de su periodo de retención, y registrar la eliminación.

10. Objeciones y retiradas

  • Cualquier objeción de un propietario de sitio, un individuo o una autoridad se dirige al contacto de retirada en [un día laborable].
  • La recopilación afectada se pausa mientras se revisa la objeción, a menos que legal indique lo contrario.
  • El contacto de retirada responde en [periodo] y registra la objeción, la decisión y cualquier dato eliminado.
  • Las objeciones repetidas sobre el mismo proyecto desencadenan una revisión de la aprobación de ese proyecto.

11. Registros y revisión

El propietario de la política mantiene el registro de proyectos, las aprobaciones, la lista de proveedores y el registro de retiradas, y revisa esta política al menos [anualmente] y siempre que la ley o las actividades de la empresa cambien de forma sustancial.

Hacer que se cumpla

Una política que se queda en una unidad compartida no cambia nada. Unos pocos hábitos la hacen real:

  • Pon el registro donde empiezan los proyectos. Un formulario breve en la herramienta que los ingenieros ya usan, con las reglas por defecto como casillas de verificación, detecta los proyectos antes de que existan en lugar de después.
  • Incorpora las reglas por defecto en el código. Una biblioteca de recopilación compartida que respete el robots.txt, establezca un User-Agent honesto, regule el ritmo de las solicitudes y registre el contexto de recopilación hace que la política sea el camino fácil, no un paso adicional. Respetar el robots.txt y las exclusiones de IA cubre qué señales hay que leer.
  • Registra dónde se observaron los datos. Registrar la hora, la ubicación y la configuración de cada ejecución es lo que hace que los datos recopilados sean defendibles más adelante, como se argumenta en el argumento a favor de un estándar de punto de observación.
  • Revisa a tus proveedores. Pregunta a los proveedores de proxies cómo obtienen sus IPs, y consulta cómo los proveedores obtienen IPs residenciales de forma ética y la economía del malware detrás de los proxies baratos para entender por qué importa.
  • Mantén los secretos fuera del código. Ejecutar scrapers en CI/CD muestra cómo gestionar las credenciales de proxy de forma segura.
  • Lee las señales antes de construir. Una comprobación rápida de qué protege a una fuente, como en nuestra búsqueda de stack anti-bot, te dice pronto si un proyecto cae dentro de las reglas por defecto o necesita aprobación.

Para el panorama legal más amplio, consulta es legal el web scraping y proxies residenciales y el RGPD; para la práctica del día a día, buenas prácticas de web scraping.

La conclusión

Una política de recopilación de datos no necesita ser larga. Necesita un alcance claro, reglas por defecto seguras que permitan que la mayoría del trabajo proceda, un paso de aprobación para los casos de riesgo, reglas firmes para los datos personales, y una persona designada que responda cuando alguien se oponga.

Escríbela una vez, incorpora sus reglas por defecto en las herramientas que usan los ingenieros, y mantén el registro actualizado. Entonces, la próxima vez que alguien pregunte cómo recopila tu empresa datos web, la respuesta será un documento en lugar de una improvisación. Adapta la plantilla a tu situación, y haz que un abogado la revise antes de adoptarla.

Fuentes y referencias

¿Listo para empezar?

Prueba los proxies residenciales de Shifter, más de 205M IPs, más de 195 países, desde 0,75 $/GB.

Comenzar