Comprar software para 2027: qué pruebas pedir antes de lanzar o renovar

10 min de lectura · 5 de noviembre de 2026

Antes de comprar software para 2027, clasifica el producto, el uso de IA y el servicio de nube. Pide pruebas según las fechas que correspondan a tu función: registros de versiones y vulnerabilidades, responsabilidades y pruebas de IA, y condiciones de exportación y salida. Asigna a cada cuestión pendiente un responsable interno y una fecha de decisión.

Ámbito y fuentes comprobados el 5 de noviembre de 2026. Esta guía comercial de Wavect conecta la selección de proveedores con pruebas de ingeniería. El calendario resume determinados requisitos de la UE; los ejemplos y los hitos de proyecto son nuestro método de compra propuesto. Una persona cualificada en asesoramiento jurídico debe evaluar tu clasificación y tu contrato concretos. Una fecha posterior en un régimen no aplaza las obligaciones que ya se aplican en otro. El ámbito es la UE, no la legislación interna de todos los países de habla española.

¿Qué fechas de 2027 pueden cambiar una decisión de compra de software?

Separa en el calendario la seguridad del producto, la IA de alto riesgo y el cambio de proveedor de nube. Antes de convertir una fecha en un requisito del proyecto, determina su ámbito de aplicación. Contrastamos las siguientes fechas con la legislación enlazada, sin deducirlas de un distintivo de cumplimiento del proveedor.

Fechas legales seleccionadas, comprobadas el 5 de noviembre de 2026. El ámbito es esencial; no es un calendario completo de cumplimiento.
Fecha	Requisito que evaluar	Consecuencia para la compra
11 de septiembre de 2026, ya aplicable	Obligaciones de notificación del artículo 14 del CRA, según el ámbito del Reglamento.	Identifica ahora el responsable y el proceso de notificación. Esperar a la fecha de aplicación general de 2027 no resuelve esa responsabilidad.
11 de diciembre de 2027	Aplicación general del Reglamento de Ciberresiliencia a los productos incluidos en su ámbito.	Determina el producto y las funciones de los operadores económicos. Pide las pruebas pertinentes de seguridad antes de comercializarlo.
2 de diciembre de 2027	Secciones 1 a 3 del capítulo III del Reglamento de IA, salvo el artículo 6.5, para los sistemas de alto riesgo del artículo 6.2 y el anexo III.	Registra el uso previsto y la clasificación. Identifica qué parte aporta cada registro necesario para ese sistema.
12 de enero de 2027	Prohibición de gastos por cambio de proveedor del artículo 29 de la Ley de Datos para los servicios de tratamiento de datos cubiertos.	Separa los gastos cubiertos del proveedor del trabajo de migración y de otros importes contractuales. Comprueba las excepciones del artículo 31.

Los artículos 69 y 71 del CRA recogen las reglas de aplicación y transición. Para el proceso operativo, consulta la guía de notificación del CRA.

El artículo 113.c del Reglamento de IA, consolidado el 27 de julio de 2026, fija también el 2 de agosto de 2028 para los correspondientes requisitos de alto riesgo del artículo 6.1 y el anexo I. Son fechas específicas para esos requisitos, no un aplazamiento general de todas las obligaciones de IA. Comprueba de nuevo la legislación vigente antes de comprometerte en 2027.

Los artículos 29 a 31 de la Ley de Datos distinguen los gastos por cambio de proveedor, otros cargos y determinados servicios desarrollados a medida. El artículo 31.1 exceptúa de la aplicación del artículo 29 y de otras disposiciones concretas ciertos servicios desarrollados para un cliente individual que no se ofrecen a gran escala en un catálogo comercial. No establece una exención general de todo el capítulo sobre cambio de proveedor.

¿Qué aspectos del producto, la IA y la nube hay que clasificar primero?

Describe qué recibirá el comprador y para qué lo utilizará. Después determina las funciones pertinentes con los responsables jurídicos y técnicos. Contratar un desarrollo a medida, adquirir una licencia de producto y renovar un servicio de nube puede plantear cuestiones distintas dentro de un mismo proyecto.

Preguntas iniciales para tres compras hipotéticas. Los ejemplos no clasifican un producto real ni acreditan su conformidad.
Compra	Primera pregunta	Pruebas que solicitar
Asistente de conocimiento interno sobre una plataforma SaaS existente	¿Cuál es el uso previsto de la IA y qué función desempeña cada parte?	Descripción del flujo, movimientos de datos, modelo de acceso, resultados de evaluación, responsabilidades operativas y análisis jurídico aplicable.
Producto conectado con un componente necesario de tratamiento a distancia	¿Encaja la entrega en la definición y el ámbito de producto del CRA, y quién es el fabricante?	Límites del producto y su versión, evaluación de funciones, registros de seguridad y proceso documentado de vulnerabilidades adecuado a esa evaluación.
Renovación de un servicio de nube con cambio de proveedor previsto	¿Es un servicio de tratamiento de datos cubierto y se aplica una excepción del artículo 31?	Descripción del servicio, alcance de exportación, proceso contractual de cambio, desglose de cargos y cualquier excepción declarada.

Los artículos 2 y 3 del CRA definen el ámbito y los productos, incluidas las soluciones pertinentes de tratamiento a distancia. No clasifiques toda compra SaaS como producto del CRA solo porque sea software. Del mismo modo, dos funciones que usan un mismo modelo de IA no pertenecen automáticamente a una misma categoría de riesgo. Documenta el uso previsto en lugar de deducir la clasificación de la etiqueta del producto.

¿Qué pruebas pedir antes de firmar o renovar?

Pide registros vinculados al sistema y a la versión que vas a contratar. Una respuesta útil identifica la versión, explica qué se comprobó y señala lo que sigue pendiente. Pregunta quién mantendrá esas pruebas cuando cambie una dependencia, el modelo operativo o el uso previsto.

Antes de adjudicar: registro de ámbito y funciones, responsable propuesto de entrega, dependencias, condiciones de aceptación y desglose completo de costes operativos.
Antes de lanzar: resultados de verificación acordados, defectos conocidos, instrucciones de despliegue y recuperación, y persona autorizada para aceptar los riesgos residuales.
Antes de renovar: alcance del soporte, cambios del producto y de sus dependencias, capacidad de exportación, condiciones de transición y lista actualizada de pruebas pendientes.

Para un producto incluido en el CRA, vincula las solicitudes con la evaluación de riesgos y la documentación técnica del fabricante conforme al artículo 13. El acuerdo debe concretar qué registros recibirás y qué derechos obtendrás. Una obligación interna del proveedor no concede automáticamente al comprador todos sus documentos internos ni la propiedad de su código fuente.

Nuestra revisión de cláusulas de propuestas de software profundiza en las cuestiones contractuales. La guía para elegir una agencia ayuda a comparar candidatos con un mismo documento de requisitos.

¿Cómo planificar hacia atrás desde el lanzamiento?

Fija las fechas de entrega de pruebas a partir de tu lanzamiento o renovación real, dejando margen para resolver carencias. La siguiente secuencia de 90, 60 y 30 días es un plan interno ilustrativo, no un plazo legal mínimo ni una promesa de que cualquier proyecto cabe en tres meses.

90 días antes de la decisión: acuerda el uso previsto y los límites del sistema. Asigna responsables para la clasificación jurídica y las pruebas técnicas. Registra las dependencias de acceso, compra y proveedor.
60 días antes: revisa los registros propuestos y ejecuta casos normales y de fallo representativos. Pide al proveedor que explique las pruebas incompletas y acuerde un plan de subsanación con fecha.
30 días antes: ensaya la recuperación o exportación acordada. Resuelve las incógnitas críticas, registra los límites restantes y decide si seguir, reducir el alcance o aplazar.

Las obligaciones de notificación ya aplicables necesitan un proceso operativo ahora; no esperan a esta secuencia. Una propuesta tardía tampoco desplaza una fecha legal. Si no puedes completar a tiempo una decisión esencial, modifica el plan comercial o de lanzamiento con los responsables.

¿Cambiar de proveedor de nube será gratis en 2027?

La partida de gastos por cambio de un proveedor cubierto puede pasar a cero conforme al artículo 29. Eso no vuelve gratuitos tu trabajo de migración, la operación simultánea ni todos los compromisos contractuales. Identifica el servicio y cualquier excepción del artículo 31 antes de aplicar la prohibición de cargos.

Importes netos hipotéticos para planificar, no precios, ofertas ni referencias del mercado. Evalúa por separado el ámbito legal y las condiciones reales.
Categoría	Importe supuesto	Tratamiento
Gasto del proveedor por cambio cubierto legalmente	0 €	Se supone incluido en el artículo 29 después del 12 de enero de 2027; comprueba ese supuesto.
Implementación de la migración con alcance separado	4.000 €	Trabajo de ingeniería supuesto, no un gasto del proveedor por cambio al que se le ha puesto otro nombre.
Operación simultánea	600 €	Solapamiento supuesto entre los dos entornos.
Pruebas y conciliación internas	900 €	Valor económico del tiempo interno; no necesariamente una factura externa.
Coste económico total del modelo	5.500 €	4.000 € + 600 € + 900 €, antes de impuestos y sin incluir compromisos por terminación anticipada.

Mantén las penalizaciones por terminación anticipada y las tarifas ordinarias del servicio como cuestiones separadas; el artículo 29.4 reconoce esas categorías distintas. Solicita una evaluación de los importes y condiciones reales, sin asumir que todo cargo es válido por su nombre. Para la transición práctica, consulta la guía de cambio de proveedor de software.

¿Qué debe contener el registro de decisión sobre el proveedor?

Mantén un registro que vincule cada requisito con un responsable y con pruebas que se puedan revisar. Indica el estado: demostrado, confirmado en contrato, publicado solo en la oferta o pendiente de resolver. Estas etiquetas describen lo que sabes. No crean una puntuación del proveedor ni certifican cumplimiento.

Campos para copiar: sistema y versión; uso previsto; decisión sobre función y ámbito; prueba solicitada; documento o fuente del proveedor; responsable interno; referencia legal cuando proceda; fecha interna; cuestión pendiente; decisión de lanzamiento o renovación.

Registro ilustrativo: sistema y versión: portal de clientes 1.0; uso previsto: consulta de facturas; función y ámbito: pendientes de evaluación jurídica; prueba solicitada: el rol A no puede acceder a la factura del rol B; fuente: informe de pruebas de la versión; responsable: responsable de producto; referencia legal: pendiente de evaluar el ámbito; fecha interna: antes del piloto; cuestión pendiente: ensayo de restauración; decisión: piloto pendiente. Es un registro propuesto, no el resultado de un cliente. Mantén explícita una incógnita crítica en lugar de compensarla con pruebas sobre otros aspectos.

El caso publicado de Bond Analytics ofrece contexto de ingeniería relacionado. No demuestra un resultado regulatorio de 2027 ni asesoramiento jurídico formal. El servicio de consultoría tecnológica de Wavect puede ayudarte a estructurar las decisiones de ingeniería y las pruebas necesarias. Lleva los límites de tu sistema propuesto a una conversación para delimitar tu compra de software.

Preguntas sobre contratar software para 2027

¿Una dirección austriaca demuestra que todos los datos se procesan en la UE?

Una dirección identifica una ubicación empresarial, no el tratamiento completo de los datos. Pide los participantes propuestos, los servicios de modelos y las ubicaciones de registros, copias de seguridad y acceso de soporte. Los responsables de privacidad y jurídicos deben evaluar el acuerdo real. Confirma las restricciones necesarias en el contrato, sin deducirlas del país del proveedor o de una marca europea.

¿Una renovación convierte automáticamente el software existente en un producto nuevo a efectos del CRA?

No clasifiques un producto solo por la fecha de renovación. El artículo 69 del CRA establece el régimen transitorio para productos comercializados antes del 11 de diciembre de 2027, con la condición de modificación sustancial y una excepción separada para notificación. Registra el historial del producto y los cambios previstos, y solicita una evaluación del ámbito real. La etiqueta de renovación no resuelve esa evaluación.

¿Puede una aplicación necesitar pruebas para varios regímenes?

Sí. Una compra puede incluir un producto, un uso de IA y servicios de tratamiento de datos. Mantén separados el ámbito y la función responsable de cada parte. Una fecha no anula un requisito ya aplicable de otro régimen. El calendario organiza las preguntas; la clasificación final depende del sistema y del uso concretos.

¿La Ley de Datos concede al comprador el código fuente del proveedor?

No interpretes los derechos de cambio de proveedor como una transferencia de toda la propiedad intelectual. El artículo 30.6 de la Ley de Datos protege determinados límites de propiedad intelectual y secretos comerciales. Acuerda expresamente los datos exportables, la configuración, la documentación y los derechos sobre código encargado por separado. Comprueba qué disposiciones se aplican antes de reclamar un activo interno concreto.

¿Qué hacer si el proveedor todavía no puede aportar un registro solicitado?

Registra qué falta, quién se encarga y qué decisión impide tomar. Pide un plan de entrega de pruebas con fecha o una alternativa que cumpla el requisito. Puede ser necesario reducir el alcance o aplazar un lanzamiento. La promesa de aportar pruebas más adelante debe distinguirse de un control demostrado o una prueba de aceptación completada.

¿Quién debe revisar la clasificación y el contrato?

Recurre a asesoramiento jurídico cualificado para la clasificación legal y la interpretación contractual, junto con el responsable técnico que conozca el producto y los flujos de datos. Wavect puede ayudar a organizar pruebas de ingeniería y cuestiones de entrega dentro del alcance acordado. Esta guía no concede una evaluación de conformidad, certificación ni aprobación jurídica para una compra concreta.