Cómo elegir una empresa de desarrollo de software en 2026

YuSMP Group Editorial Team Equipo editorial, YuSMP Group

TL;DR — la selección de proveedor de un vistazo

Acertar con la elección se reduce, en realidad, a seis dimensiones. Puntúe a cada candidato con ellas antes de que el precio entre siquiera en la conversación:

• Certificaciones: ISO 27001 (seguridad de la información) + SOC 2 Type II (empresas de EE. UU. y la UE) + DPA del artículo 28 del RGPD para datos de la UE
• Propiedad intelectual y NDA: NDA mutuo antes de compartir especificaciones; el contrato cede toda la propiedad intelectual al cliente; el código se aloja en un repositorio propiedad del cliente
• Encaje del portfolio: al menos 2 proyectos de su nivel de complejidad y de su sector, entregados en los últimos 24 meses
• Modelo de colaboración: precio cerrado (alcance pequeño y estable) / tiempo y materiales (producto en evolución) / equipo dedicado (velocidad continua)
• Referencias: 2–3 llamadas en directo con clientes de referencia, no solo testimonios escritos en una página de perfil
• Comunicación: solapamiento horario, jefe de proyecto con nombre y apellidos, vía de escalado definida

Empiece por unos requisitos claros — antes de preseleccionar a nadie

¿Qué decide si su desarrollo sale bien? Sobre todo una cosa, y se resuelve mucho antes de contactar con un solo proveedor: lo bien que haya definido el alcance del trabajo. Estudio tras estudio sobre proyectos de TI apunta en la misma dirección. Los equipos que parten de requisitos escritos y acordados entregan a tiempo y dentro del presupuesto con mucha más frecuencia que los que entregan un encargo vago. Esta es la prueba práctica que usamos: si no puede exponer el problema, quiénes son los usuarios y los resultados que de verdad necesita en unas dos páginas, ningún proveedor podrá presupuestarle con precisión — por muy sénior que sean sus ingenieros.

Así que concrete cuatro cosas antes de redactar una lista corta. Primero, el resultado de negocio que debe producir el software. Segundo, los recorridos de usuario esenciales para el lanzamiento — el resto puede esperar a fases posteriores. Tercero, sus restricciones firmes: techo de presupuesto, fecha límite, obligaciones de cumplimiento y cualquier sistema existente con el que tenga que integrarse. Cuarto, cómo medirá el éxito en los primeros 90 días tras la puesta en producción. Este es también el momento de decidir qué tipo de colaboración está comprando realmente. Un desarrollo completo de producto, un MVP para validar la demanda y un equipo que amplía a sus propios ingenieros requieren cada uno un tipo de partner distinto. Y cuando lo difícil es precisamente definir el alcance, una fase de descubrimiento estructurada con un partner de desarrollo de software a medida es lo que convierte una idea difusa en una especificación presupuestada y construible.

Un documento de requisitos claro se amortiza por partida doble. Le permite comparar propuestas en igualdad de condiciones y separa enseguida a los proveedores que se enfrentan a su problema real de los que pegan una estimación genérica. Fíjese también en las preguntas que le devuelven — lo afinadas que sean es una de las primeras señales de selección que obtendrá.

Bueno frente a barato: la contrapartida real

El equipo offshore de $25/h y el equipo nearshore sénior de $65/h le prometerán ambos construir su producto. La diferencia entre ellos suele aflorar hacia el mes 6, cuando el trabajo fácil ya ha quedado atrás. Los proveedores que cobran por debajo del mercado normalmente tienen que cuadrar las cuentas de algún modo, y se nota en alguna de estas concesiones:

• Dotar los proyectos de ingenieros júnior que requieren una supervisión intensiva
• Recurrir a subcontratistas no declarados, lo que crea riesgos en la cadena de titularidad de la propiedad intelectual
• Omitir controles de seguridad, registros de auditoría y arquitectura de cumplimiento (caros de incorporar a posteriori)
• Entregar demos que funcionan pero ocultan una deuda arquitectónica que obliga a reescribir al escalar

La investigación de Gartner sobre outsourcing de TI llega una y otra vez a la misma conclusión: el retrabajo en los encargos de bajo coste supone de media el 20–40% del total de horas. Póngale cifras. En un proyecto de $150,000, un 30% de retrabajo son $45,000 adicionales que no aparecían en ninguna parte de la propuesta. Súmele lo que le cuesta a su propio equipo vigilar un encargo que va mal. Con bastante frecuencia, la opción «barata» acaba siendo más cara que un proyecto bien dimensionado con un partner sénior.

Nada de esto es un argumento para contratar al proveedor más caro que encuentre. El objetivo que de verdad debe optimizar es la relación entre valor y calidad, y rara vez coincide con la tarifa por hora más baja. Analizamos la economía completa en nuestra guía sobre outsourcing frente a desarrollo interno.

Onshore, nearshore u offshore — qué implica realmente la geografía

Antes que las certificaciones y los modelos de colaboración, hay una decisión estructural que determina todo su modelo de costes: ¿dónde estará realmente el equipo? Cada uno de los tres modelos geográficos hace una concesión distinta entre tarifa, costes de comunicación y riesgo de entrega.

Hay dos cosas que se pasan por alto con frecuencia cuando el comprador se fija solo en la tarifa. Primero, verifique la geografía: algunas agencias presentan una dirección en EE. UU. o en la UE mientras el desarrollo real se hace en otro lugar. Pregunte dónde tienen la residencia fiscal los ingenieros y dónde se hacen las revisiones de código — no dónde está la oficina comercial. Segundo, la tarifa solo tiene sentido en relación con la certidumbre del alcance. Un equipo de $25/h en un producto SaaS en evolución suele costar más que un partner de desarrollo nearshore de $70/h una vez que se tienen en cuenta el retrabajo y los costes de coordinación.

Certificaciones: ISO 27001, SOC 2, RGPD

Es tentador ver las certificaciones como un mero trámite. No lo son. Cada una es una prueba, auditada de forma independiente, de que el proveedor ha implantado realmente controles concretos. Esto es lo que significan las tres principales más allá de las siglas:

ISO 27001

Es la norma internacional para los sistemas de gestión de la seguridad de la información, o SGSI (ISMS). Para obtenerla, el proveedor se somete a una auditoría externa que cubre sus políticas, controles de acceso, respuesta a incidentes, gestión de proveedores y seguridad física y en la nube. Los organismos acreditados emiten el certificado y vuelven cada año para auditorías de seguimiento que confirman que se mantiene. Si su proyecto toca datos personales, datos financieros o cualquier ámbito regulado, considere ISO 27001 el requisito de entrada, no algo que distinga a un proveedor de otro.

SOC 2 Type II

SOC 2 nació como norma de auditoría estadounidense, y hoy los equipos de compras de empresas de EE. UU. y la UE lo piden de forma habitual. La distinción que importa es Type I frente a Type II. Type I es una instantánea tomada en un solo día. Type II observa el funcionamiento de los controles durante un periodo, normalmente 6–12 meses, lo que dice mucho más. Esa es la versión que quiere su equipo de seguridad, porque demuestra que los controles funcionaban de verdad y no solo figuraban en un archivador de políticas. Para un producto que vaya a albergar datos de clientes de EE. UU., clientes SaaS o historiales médicos, un proveedor con SOC 2 Type II suele ser un requisito de compras ineludible. Nuestro artículo sobre SOC 2 Type II para startups SaaS explica qué cubre realmente la auditoría.

Cumplimiento del RGPD (DPA del artículo 28)

En virtud del RGPD, cualquier proveedor que trate por cuenta de usted datos personales de residentes en la UE es un «encargado del tratamiento», y el artículo 28 establece que necesitan un contrato de encargo del tratamiento (DPA) por escrito. No hay forma de excluirse y no se puede renunciar a él. Un DPA correcto detalla los fines del tratamiento y su duración, las categorías de datos, los subencargados implicados, cómo se atienden los derechos de los interesados, qué ocurre con los datos al terminar el contrato y sus derechos de auditoría. Compruebe que existe antes de incorporar a nadie. Descubrir la carencia después de una violación de seguridad es la forma cara de aprender la lección.

Seguridad, NDA y protección de la propiedad intelectual

Cuando externaliza, lo que protege su propiedad intelectual y sus datos es el derecho contractual. No la buena voluntad ni un apretón de manos. Algunas cláusulas no deberían negociarse nunca:

NDA mutuo antes de compartir especificaciones

Si un proveedor no firma un NDA antes de que le entregue las especificaciones técnicas, descártelo — eso ya le dice suficiente. Haga que el NDA sea mutuo para que proteja a ambas partes, que cubra secretos comerciales y know-how técnico, y fije la jurisdicción y las vías de reparación. Los clientes de EE. UU. suelen optar por defecto por la ley de Delaware o de Nueva York. Los clientes de la UE deberían hacer coincidir la ley aplicable con su principal país de operación.

Cláusula de cesión de la propiedad intelectual

Su contrato necesita una cláusula de obra por encargo (work-for-hire) que ceda a su empresa, en lenguaje claro, toda la propiedad intelectual creada durante la colaboración. Compruebe que lo abarca todo — código fuente, recursos de diseño, documentación, suites de pruebas, scripts de CI/CD y bibliotecas propias. Merece la pena añadir explícitamente una línea más: asegúrese de que el proveedor no incorpora discretamente componentes de código abierto con licencia GPL a sus entregables. La «viralidad» de la GPL puede socavar su capacidad de mantener el producto como propietario, y le conviene saberlo antes de que se publique, no después.

Propiedad del repositorio de código

Desde el primer día, el código debe ir a un repositorio que su organización posea y controle. Una configuración en la que el proveedor tenga el repositorio principal es motivo de rechazo directo. Y, de paso, deje la salida por escrito en el contrato: cuando termine la colaboración, se le devuelven todas las credenciales, tokens de acceso, configuraciones de infraestructura y scripts de despliegue.

Declaración de subcontratistas

Pregunte sin rodeos si subcontratistas o freelancers van a participar en el trabajo — e insista en saber quiénes son. Todos deben estar vinculados por los mismos términos de NDA y de cesión de propiedad intelectual que acordó con el proveedor. La subcontratación no declarada es una fuente recurrente de dos quebraderos de cabeza en particular: disputas sobre quién es realmente el propietario del código e incidentes de seguridad que nadie vio venir.

Prueba social: casos de éxito y referencias

De todas las señales que puede reunir, el portfolio de un proveedor y sus referencias son las que predicen con más fiabilidad la calidad de la entrega. Así que analícelos a fondo en lugar de quedarse en la superficie.

Evaluación del portfolio

Busque al menos dos proyectos de su nivel de complejidad — sencillo, medio o empresarial — y de su sector vertical, todos entregados en los últimos 24 meses. La actualidad importa aquí de verdad. Un caso de éxito de fintech de 2018 apenas dice nada del equipo, las herramientas o el enfoque de cumplimiento que tiene hoy el proveedor. También merece la pena hacer una pregunta directa: ¿siguen en plantilla los ingenieros principales de ese proyecto de referencia?

Llamadas con referencias

Trate los testimonios escritos de Clutch o de la propia web del proveedor como lo que son: material de marketing seleccionado. Una llamada en directo con una referencia es otra cosa. Pida 2–3 referencias de proyectos de complejidad similar, hable con ellas por teléfono y repase:

• ¿Se entregó el proyecto a tiempo y con una desviación de no más del 15% sobre el presupuesto inicial?
• ¿Cómo gestionó el proveedor los cambios de alcance y los retos técnicos inesperados?
• ¿Cómo fue la comunicación durante la colaboración — proactiva o reactiva?
• ¿Qué haría de otra manera si volviera a contratarlos?
• ¿Volvería a contratarlos para su próximo proyecto?

¿Y si un proveedor sencillamente no puede ponerle en contacto con un cliente de referencia real? Eso suele significar que hay algo que prefiere que usted no oiga.

Comparativa de modelos de colaboración

El modelo de colaboración que elija determina quién asume el riesgo de alcance. También condiciona cómo se estructuran los costes y cuánto puede adaptarse el trabajo cuando los requisitos cambian.

Para la mayoría de los desarrollos de empresas medianas, en la práctica funciona mejor un enfoque híbrido. Primero, una fase de descubrimiento y arquitectura a precio cerrado (4–6 semanas); después, sprints de entrega en tiempo y materiales con un tope de presupuesto mensual. Elimina el riesgo de alcance desde el principio sin perder flexibilidad más adelante. Para productos que duran años y no meses, un equipo dedicado que trabaje con objetivos trimestrales logra el mejor equilibrio entre velocidad y responsabilidad.

Haga un piloto de pago antes de comprometerse con un contrato completo

Un piloto de pago de 2–4 semanas es la señal más fiable que puede obtener sobre cómo trabaja realmente un proveedor — no cómo se presenta en una llamada comercial, sino cómo gestiona la ambigüedad, comunica los bloqueos y entrega código con una fecha límite real. El coste adicional (aproximadamente un mes de una colaboración completa) le aporta pruebas sólidas que sustituyen semanas de ilusiones sobre referencias y propuestas.

Estructure el piloto en torno a un problema real y acotado: una sola funcionalidad, un módulo de integración o la refactorización de un componente existente. Después, observe cuatro cosas:

• Reacción ante lagunas deliberadas. Incluya en su encargo dos o tres supuestos no explícitos — requisitos reales, pero con lagunas que un equipo diligente detectaría y plantearía. Que señalen la ambigüedad o la rellenen en silencio sin decírselo anticipa cómo irán todas las conversaciones futuras sobre el alcance.
• Calidad del código bajo presión. Revise al final el historial de pull requests: patrones de comentarios, cobertura de pruebas, si van limpiando sobre la marcha o aplazan la deuda técnica sin avisar.
• Actitud en la comunicación. ¿Le llegan las actualizaciones de forma proactiva o tiene que perseguirlas? ¿El PM saca a la luz los bloqueos con la antelación suficiente para que usted pueda actuar?
• Preparación para la salida. Al cerrar el piloto, pregunte: ¿podría otro equipo retomar este trabajo mañana mismo solo con el repositorio y la documentación? Un sí sincero es una prueba sólida de mantenibilidad a largo plazo.

Un proveedor que se resiste incluso a hacer un piloto de pago también le está dando información. A veces la objeción es comercial y comprensible — pero un equipo seguro de sí mismo y con recursos verá el piloto como una vía rápida hacia una colaboración más larga, no como una amenaza que gestionar.

IA y capacidades de ingeniería moderna (2026)

En 2026, un partner creíble tiene que mostrarle trabajo real, ya entregado, con ingeniería asistida por IA. Una línea sobre ello en la presentación comercial no cuenta. El informe Octoverse 2025 de GitHub situó la programación asistida por IA en manos de la inmensa mayoría de los desarrolladores activos, y la distancia entre los equipos que manejan bien esas herramientas y los que no repercute ya de lleno en la velocidad y el coste de entrega. Haga dos preguntas a cada proveedor preseleccionado. ¿Cómo integran las herramientas de IA en su propio flujo de trabajo — generación de código, revisión, pruebas? ¿Y han entregado realmente a un cliente de pago funcionalidades en producción que usen IA, ya sea recuperación, clasificación, agentes o integración de LLM?

Aquí es fácil confundir capacidad real con bombo publicitario, así que preste atención a la franqueza. Un partner sólido le dirá con claridad dónde la IA acelera la entrega y dónde no, mantendrá la revisión de código y los controles de propiedad intelectual y licencias sobre todo lo que genere la IA, y no dejará que el código generado eluda las prácticas de seguridad que vimos más arriba. Si en su hoja de ruta figuran específicamente funcionalidades basadas en IA, dé mucho peso a esta dimensión y examine la trayectoria del partner en IA, ML y datos exactamente igual que cualquier otra afirmación de su portfolio: referencias y ejemplos entregados, no diapositivas.

Señales de alarma que vigilar

Cualquiera de estos patrones debería ponerle en guardia, y dos o tres juntos deberían ponerle muy en guardia:

• Precio cerrado presupuestado sin descubrimiento — cualquier proveedor que dé un precio cerrado firme para un sistema mediano o complejo sin una fase de descubrimiento de 4–6 semanas está subestimando o escondiendo supuestos de alcance que aflorarán como solicitudes de cambio a mitad del proyecto.
• Sin certificado ISO 27001 o SOC 2 vigente cuando se pide — afirmar que se cumple sin poder presentar el certificado no es cumplir.
• Referencias con las que no se puede contactar directamente — solo testimonios escritos, sin datos de contacto reales.
• Repositorio de código controlado por el proveedor — si el repositorio es del proveedor, usted depende de él para acceder a su propio producto en cualquier momento, también en caso de disputa.
• Política de subcontratación vaga — un «puede que recurramos a partners» sin una declaración concreta es un riesgo para el tratamiento de datos y la propiedad intelectual.
• Plazos poco realistas para el alcance — un equipo sénior que entrega en 6 semanas un desarrollo de 4 meses debería hacerle preguntarse qué se está omitiendo (pruebas, revisión de seguridad, documentación).
• Sin jefe de proyecto con nombre y apellidos — «el equipo será su punto de contacto» es una estructura de comunicación que se viene abajo bajo presión.
• Confidencialidad excesiva sobre información básica de la empresa — los proveedores legítimos facilitan el registro mercantil, los certificados de seguro y las referencias financieras; una opacidad excesiva sobre el negocio es una señal de alarma en la diligencia debida.

15 preguntas que debe hacer a todo proveedor de desarrollo de software

Inclúyalas en la primera revisión de las respuestas al RFP y en las llamadas de seguimiento. A menudo, las respuestas débiles y evasivas le dicen más que las pulidas.

1. ¿Puede facilitarnos su certificado ISO 27001 vigente y, si procede, su informe SOC 2 Type II más reciente?
2. ¿Tiene un contrato de encargo del tratamiento (DPA) estándar del artículo 28 del RGPD y podemos revisarlo antes de firmar?
3. ¿Quién será el titular de la propiedad intelectual de todo el trabajo entregado — en concreto, código fuente, recursos de diseño y documentación?
4. ¿Realizarán parte del trabajo subcontratistas o freelancers? En tal caso, ¿quiénes son y a qué términos de NDA y propiedad intelectual están sujetos?
5. ¿En qué repositorio se alojará nuestro código y tendremos acceso completo de administrador desde el primer día?
6. ¿Puede facilitarnos 2–3 clientes de referencia de proyectos de nuestro nivel de complejidad con los que podamos contactar directamente?
7. ¿Qué modelo de colaboración propone para nuestro proyecto y por qué?
8. ¿Quién será el jefe de proyecto designado y cuál es su proceso de escalado cuando surgen problemas?
9. ¿Cuál es la antigüedad media de su equipo de ingeniería y cuál es su tasa de rotación actual?
10. ¿Cómo gestionan los cambios de alcance en un contrato a precio cerrado?
11. ¿Qué prácticas de seguridad incorpora su proceso de desarrollo (revisión de código, SAST, análisis de dependencias, pruebas de penetración)?
12. ¿Cómo gestionan la localización y el tratamiento de los datos personales de la UE en virtud del RGPD?
13. ¿Cuáles son sus entregables estándar de traspaso al final del contrato (código, credenciales, documentación, transferencia de conocimiento)?
14. ¿Qué SLA ofrecen para el soporte y la corrección de errores tras el lanzamiento?
15. ¿Puede facilitarnos un desglose de costes completo por fases, con supuestos explícitos para cada partida?

Plantilla de evaluación de proveedores

Esta matriz de puntuación ponderada le permite comparar a los proveedores preseleccionados con algo más sólido que la intuición. Ajuste las ponderaciones a sus propias prioridades — una empresa regulada debería dar más peso a la seguridad, mientras que una startup en fase inicial quizá valore más la comunicación y la agilidad.

Si un proveedor obtiene menos de 3.0 en certificaciones o en condiciones de propiedad intelectual, queda fuera, diga lo que diga su total. Son criterios de umbral: no se compensan con una buena puntuación en otro apartado. Una vez que haya elegido partner, nuestra guía sobre el proceso de desarrollo de software a medida explica cómo es el resto de la colaboración.

Preguntas frecuentes

¿Cómo elijo una empresa de desarrollo de software?

Empiece por las certificaciones y el encaje de cumplimiento (ISO 27001, SOC 2, DPA del RGPD). Revise en el portfolio proyectos de su nivel de complejidad y sector de los últimos 24 meses. Verifique contractualmente la titularidad de la propiedad intelectual y las condiciones del NDA. Compare los modelos de colaboración con la estabilidad de su alcance. Haga llamadas en directo con referencias — no se quede en los testimonios escritos. Puntúe a los candidatos con una matriz ponderada y elimine a cualquier proveedor que no alcance el umbral en certificaciones o propiedad intelectual, sea cual sea su precio.

¿Qué certificaciones debe tener un proveedor de desarrollo de software?

ISO 27001 es la base para cualquier colaboración con datos sensibles. SOC 2 Type II es el estándar en las compras de empresas de EE. UU. El DPA del artículo 28 del RGPD es obligatorio para tratar datos personales de la UE. Añadidos por sector: HIPAA para datos sanitarios de EE. UU., PCI-DSS para el procesamiento de pagos, ISO 13485 para productos sanitarios. Pida el certificado o el informe de auditoría reales, no una afirmación de marketing sobre «cumplimiento».

¿Cómo protejo mi propiedad intelectual y mis datos al externalizar?

Hay cuatro protecciones contractuales innegociables: NDA mutuo antes de compartir especificaciones; cláusula de cesión que transfiera a su empresa toda la propiedad intelectual creada; código alojado en su propio repositorio desde el primer día; y un DPA del artículo 28 del RGPD si hay datos personales de la UE. Exija además la declaración explícita de cualquier subcontratista y confirme que está sujeto a condiciones equivalentes. Pida a su asesor jurídico que revise todas las cláusulas — no solo el SOW — antes de firmar.

¿Precio cerrado o tiempo y materiales para el desarrollo de software?

El precio cerrado es adecuado para desarrollos pequeños, bien definidos y estables (normalmente por debajo de $75,000). Tiempo y materiales es mejor para productos iterativos y en evolución cuyos requisitos cambiarán durante la entrega. Una iguala de equipo dedicado encaja con desarrollos continuos de larga duración. El enfoque más pragmático para desarrollos de empresas medianas es una fase de descubrimiento a precio cerrado (4–6 semanas) seguida de entrega en T&M, que combina claridad de alcance con flexibilidad de entrega.

¿Cuáles son las señales de alarma en una agencia de desarrollo de software?

Principales señales de alarma: precio cerrado presupuestado sin fase de descubrimiento; sin certificado ISO 27001 o SOC 2 vigente; referencias con las que no se puede contactar directamente; repositorio de código controlado por el proveedor; declaración de subcontratistas vaga; plazos poco realistas para el alcance; sin jefe de proyecto designado; y una opacidad excesiva sobre la situación jurídica y financiera de la empresa.

¿Cómo compruebo las referencias de una empresa de desarrollo de software?

Pida 2–3 contactos de referencia reales de proyectos de su nivel de complejidad entregados en los últimos 18 meses. Llámelos directamente. Pregunte si el proyecto se entregó a tiempo y dentro del presupuesto, cómo se gestionaron los cambios de alcance y los problemas, si volverían a contratar al proveedor y qué harían de otra manera. Contraste con las reseñas de Clutch o G2, pero tome las llamadas en directo como la señal principal — los testimonios escritos seleccionados no las sustituyen.

¿Debe tener experiencia en IA una empresa de desarrollo de software?

En 2026, sí. El desarrollo asistido por IA ya es habitual — el Octoverse 2025 de GitHub registró su adopción entre la gran mayoría de los desarrolladores activos — y afecta de forma sustancial a la velocidad y el coste de entrega. Pregunte al proveedor cómo integra las herramientas de IA en su flujo de trabajo y si ha entregado funcionalidades de IA en producción (recuperación, clasificación, agentes, integración de LLM) para clientes reales. Trate la capacidad en IA como una afirmación del portfolio que hay que verificar con referencias, y confirme que aplica al código generado por IA la misma disciplina de seguridad y revisión de código que a cualquier otro código.

¿Debo hacer un proyecto piloto antes de contratar a una empresa de desarrollo de software?

Un piloto de pago de 2–4 semanas es uno de los pasos más reveladores de la selección de proveedor. Muestra cómo gestiona un equipo los requisitos ambiguos, con qué proactividad comunica y si la calidad de su código se mantiene con una fecha límite real. Estructure el piloto en torno a un problema real y acotado — una sola funcionalidad o un módulo de integración — e incluya en el encargo dos o tres lagunas deliberadas para ver si el equipo las detecta y las escala. Al terminar el piloto, pregunte si otro equipo podría continuar el trabajo solo con el repositorio y la documentación. Un proveedor que se resiste a un piloto de pago es, en sí mismo, una señal que conviene anotar.

Última actualización: 16 de septiembre de 2026. Los requisitos de certificación reflejan ISO/IEC 27001:2022, AICPA SOC 2 y el Reglamento (UE) 2016/679 (RGPD) a la fecha de publicación. Los requisitos legales varían según la jurisdicción; consulte a un asesor jurídico cualificado para revisar los contratos.