Antes de conectar un feed de productos, obtén una prueba que autorice con precisión la recopilación, la transformación, la conservación y el uso previstos. Una URL pública, una cuenta válida, un endpoint que responde o un robots.txt permisivo no bastan. Vincula cada tratamiento a una cláusula de licencia, unos términos de uso, un contrato con el proveedor o una autorización por escrito, y anota los límites de frecuencia, territorio, duración y redistribución. Si un derecho esencial sigue siendo ambiguo, bloquea la automatización y pide confirmación al proveedor o un asesoramiento legal adecuado. La verificación protege tanto a la fuente como la reversibilidad del proyecto.
Separar cinco preguntas que suelen confundirse
El primer error consiste en reducir los derechos de uso a «¿podemos descargar el archivo?». El acceso técnico es solo una capa. Una conexión bien hecha distingue al menos cinco preguntas:
1. Acceso: ¿se han facilitado la cuenta, la clave, la ruta o la exportación para este uso? 2. Recopilación: ¿está autorizada la descarga automatizada, con qué frecuencia y dentro de qué límites? 3. Transformación: ¿se pueden normalizar las columnas, calcular indicadores o emparejar productos? 4. Conservación: ¿qué datos se pueden almacenar, durante cuánto tiempo y con qué medidas de eliminación? 5. Difusión: ¿se pueden mostrar títulos, imágenes, precios o stocks a usuarios, exportarlos o transmitirlos a un tercero?
Una respuesta positiva a una pregunta no es válida para las demás. Un proveedor puede autorizar la importación en una herramienta interna sin autorizar la republicación pública de sus imágenes. También puede permitir una exportación manual sin prever una consulta automatizada. Solo el texto aplicable y, si es necesario, una confirmación explícita permiten decidir.
Elaborar un expediente de prueba por fuente
El expediente debe estar vinculado a una fuente claramente identificada. Evita notas generales como «catálogo autorizado». Anota el nombre del proveedor, el servicio implicado, el tipo de cuenta, el documento, su versión o fecha, la URL oficial y la persona que validó la interpretación. Una sola captura de pantalla es frágil si el texto se puede descargar o archivar en su formato original.
| Pregunta | Prueba a buscar | Decisión posible | Punto a reexaminar |
|---|---|---|---|
| ¿Quién facilita el acceso? | contrato, invitación, documentación de la cuenta | acceso reconocido | cambio de titular o de cuenta |
| ¿Qué canal está permitido? | documentación de API, FTP o exportación | canal elegido | cambio de endpoint o fin del servicio |
| ¿Con qué frecuencia? | cuota, ventana horaria, regla de cortesía | cadencia limitada | errores repetidos o nueva cuota |
| ¿Qué datos? | perímetro del catálogo y exclusiones | campos autorizados | añadir imágenes, textos o precios |
| ¿Qué tratamiento? | finalidad descrita en la licencia | importación interna, análisis u otra finalidad indicada | nueva función o nuevo público |
| ¿Qué conservación? | duración, fin de contrato, eliminación | política de retención | rescisión o retirada de un producto |
| ¿Qué redistribución? | cláusula de publicación o de compartición | difusión autorizada o prohibida | añadir una exportación a terceros |
La forma del feed no cambia esta obligación. Las diferencias técnicas entre CSV, XML, API y FTP ayudan a construir la conexión, pero ninguna de estas tecnologías otorga por sí misma un derecho de reutilización.
Qué cambia la directiva europea sobre bases de datos
La Directiva 96/9/CE regula la protección jurídica de las bases de datos en la Unión Europea. Prevé, entre otras cosas y bajo ciertas condiciones, un derecho sobre la extracción o la reutilización de la totalidad o de una parte sustancial del contenido cuando se ha realizado una inversión sustancial. También aborda ciertos actos repetidos y sistemáticos sobre partes no sustanciales. La aplicación a un catálogo concreto depende, no obstante, de los hechos, del derecho nacional y del contrato.
Esta directiva no es ni una licencia de acceso ni una prohibición automática de cualquier importación. Muestra por qué «las páginas son visibles» o «solo tomamos unas pocas líneas cada vez» no basta como análisis. Los derechos contractuales, los posibles derechos de autor sobre los contenidos, la protección de la base de datos y el resto de normas aplicables deben examinarse por separado. Ante un riesgo real o una cláusula ambigua, la validación corresponde a un profesional del derecho competente; este artículo ofrece un método documental, no un asesoramiento jurídico.
Por qué robots.txt no resuelve la cuestión
La RFC 9309 formaliza el Robots Exclusion Protocol. Indica que las reglas publicadas se solicitan a los robots que exploran URI y precisa expresamente que no constituyen una forma de autorización de acceso. El archivo sirve, por tanto, para respetar las preferencias técnicas del servicio, pero no sustituye ni la autenticación, ni la licencia, ni los términos de uso.
La consecuencia práctica es doble. Una ruta permitida por robots.txt no otorga el derecho a copiar o republicar su contenido. Una ruta prohibida debe ser respetada por el robot correspondiente, aunque el equipo crea tener un interés comercial. Si un contrato específico parece contradecir una restricción técnica, no intentes eludirla: pide al proveedor el canal oficial correspondiente al acuerdo.
Procedimiento de validación antes de conectar
Paso 1: describir el uso real
Escribe una frase concreta: «recuperar tal archivo por tal canal, con tal cadencia, conservar tales campos y usarlos para tal finalidad». Menciona a los usuarios y las posibles transmisiones. Una finalidad vaga impide comparar el proyecto con las cláusulas.
Paso 2: reunir los textos aplicables
Recopila el contrato, los términos de uso de la cuenta, la licencia del feed, la documentación técnica y los correos que precisen la autorización. Anota su fecha y su alcance. Las páginas comerciales pueden explicar el servicio, pero no sustituyen necesariamente las condiciones contractuales.
Paso 3: rellenar la matriz de derechos
Para cada acción —recopilar, transformar, almacenar, mostrar, exportar, eliminar— cita la prueba y clasifica el resultado: autorizado, prohibido, condicional o indeterminado. No uses «autorizado» sin referencia. Una casilla indeterminada se convierte en una pregunta que dirigir al proveedor.
Paso 4: traducir los límites en salvaguardas
Convierte las obligaciones confirmadas en configuraciones: frecuencia máxima, campos excluidos, duración de retención, registro de auditoría, eliminación al finalizar el contrato y limitación de las exportaciones. La documentación y la ejecución deben permanecer coherentes. Si el permiso caduca, la recopilación debe poder detenerse sin eliminar las pruebas necesarias para la auditoría.
Paso 5: probar sobre un perímetro reversible
Una vez establecidos los derechos, usa un lote canario de proveedor para verificar el canal y los límites sobre un perímetro pequeño y controlado. Esta prueba no regulariza un uso no autorizado; se realiza después de la validación documental.
Paso 6: prever la revisión
Fija los eventos que obligan a una nueva lectura: cambio de los términos de uso, nuevo dominio, cambio de cuenta, adición de imágenes, compartición con un tercero, aumento de frecuencia, nueva finalidad o rescisión. Una autorización no debe considerarse eterna si su contexto cambia.
Gestionar las zonas grises sin inventar un permiso
Cuando falta una cláusula, formula una pregunta cerrada y trazable al proveedor. Por ejemplo: «¿Nuestra cuenta autoriza una recuperación diaria de este archivo para un análisis interno, con conservación del identificador, el precio y el stock?». Añade la pregunta sobre la visualización y la exportación si esos usos están previstos. Una respuesta comercial vaga debe aclararse antes de automatizar nada.
No copies datos adicionales «por si acaso». La minimización reduce los riesgos y simplifica la eliminación. El control de las columnas de un catálogo mayorista permite identificar los campos realmente necesarios y aquellos cuya finalidad no está demostrada.
Por último, registra los rechazos. Una fuente bloqueada por falta de autorización no es un fallo técnico: es una decisión de cumplimiento. El estado debe indicar el motivo, la fecha y la próxima acción posible, sin reanudar automáticamente la recopilación.
Qué puede automatizar ArbitragePro+ / qué debe verificar el vendedor
La función registro-derechos-fuente es una especificación propuesta, no una función declarada disponible. Podría asociar a cada fuente una matriz de usos, los documentos oficiales, sus fechas, las restricciones, un plazo de revisión y un estado bloqueante. También podría impedir una recopilación cuando falte o haya caducado una autorización requerida, conservando el historial de decisiones.
El vendedor debe interpretar los contratos aplicables, obtener los permisos, confirmar las finalidades y pedir asesoramiento jurídico cuando sea necesario. También verifica que la configuración técnica respeta realmente la cadencia, los campos, la conservación y la difusión autorizados. Ningún registro automatizado convierte una cláusula ambigua en un permiso.
Checklist antes de activar
- El uso real, el canal, la frecuencia y los destinatarios están descritos.
- El titular de la cuenta y el proveedor de la autorización están identificados.
- Los términos de uso, licencias y documentos técnicos están fechados y archivados.
- Recopilación, transformación, conservación y difusión tienen cada una su prueba.
- Las reglas de
robots.txtse respetan sin tratarse como una licencia. - Los campos recopilados tienen una finalidad explícita.
- Los límites se traducen en salvaguardas técnicas.
- Existe un procedimiento de parada y eliminación.
- Los cambios de finalidad activan una nueva revisión.
- Cualquier zona indeterminada permanece bloqueada hasta que se aclare.
Documentar una fuente autorizada
Abrir la gestión de fuentes en ArbitragePro+
Fuentes oficiales
- EUR-Lex, Directiva 96/9/CE relativa a la protección jurídica de las bases de datos: https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A31996L0009 (consultado el 2026-08-17).
- IETF, RFC 9309 — Robots Exclusion Protocol: https://www.rfc-editor.org/rfc/rfc9309.html (consultado el 2026-08-17).
