Guías
Software a medida y protección de datos: qué exige el RGPD
En cuanto se procesen datos personales en software a medida, se aplican obligaciones claras. Cuáles son concretamente, qué falta casi siempre en la práctica y qué es realmente suficiente.
En cuanto se procesen datos personales en software a medida, se necesitan base jurídica, vinculación de finalidad, plazos de supresión definidos, información a los afectados y un contrato de encargo de tratamiento con cada proveedor de servicios implicado. En la práctica faltan casi siempre los mismos tres puntos: el plazo de supresión, la indicación en el punto de recogida y la aclaración de si el proveedor usa los datos para entrenamiento propio.
01 — Protección de datos
Qué exige el RGPD
En cuanto se procesan datos personales — y eso ocurre más rápido de lo que se piensa, por ejemplo en cuanto alguien introduce un nombre o un número de teléfono — se aplican las obligaciones habituales: nombrar la base legal, establecer la finalidad, cumplir la minimización de datos, definir plazos de eliminación, informar a los interesados.
En la práctica, eso significa para el software a medida: un contrato de encargo de tratamiento con cada proveedor de servicios implicado, la comprobación de dónde se procesa, un plazo de supresión documentado y un párrafo comprensible en la declaración de protección de datos. Tres cosas faltan casi siempre en la práctica: el plazo de supresión definido, la indicación en el lugar donde se recogen los datos y la aclaración de si el proveedor usa los datos para entrenamiento propio.
Una evaluación de impacto en la protección de datos solo es necesaria cuando existe un riesgo previsiblemente alto — en la mayoría de proyectos de este tipo no. La comprobación en sí debería documentarse de todos modos, para que en caso necesario sea comprensible por qué se ha omitido.
02 — Contrato
Qué debe aclararse por escrito
- Propiedad de datos y accesos. Pertenecen al cliente. Si un proveedor no lo confirma claramente, esa es la información más importante de la conversación.
- Entrega en caso de finalización. En qué formato, en qué plazo, a qué costes.
- Sin permanencia mínima sin contraprestación. La vinculación es defendible si se entrega algo a cambio — si no, no.
- Qué cuesta un cambio posterior. No es el precio del proyecto lo que decide sobre los costes totales, sino la tarifa horaria para el tercer año.
- Documentación como objeto de entrega. No como promesa, sino como partida en el presupuesto.
03 — Riesgos
Qué puede salir mal
- El sistema responde incorrectamente. Limitado al trabajar exclusivamente con contenidos revisados y derivar en caso de duda en lugar de adivinar. Eso es una decisión de configuración, no una característica de la tecnología.
- Se subestima el esfuerzo. Motivo más frecuente: situación de partida poco clara. Un balance honesto antes del presupuesto lo previene de forma más fiable que cualquier margen.
- Nadie lo mantiene. El mayor riesgo de todos — y el más fácilmente evitable.
- Lagunas en la protección de datos. Surgen casi siempre por plazos de eliminación inexistentes y responsabilidad poco clara, raramente por la tecnología en sí.
- Dependencia del proveedor. Evitable si los accesos, datos y documentación quedan contractualmente en manos del cliente.
04 — Preguntas
Preguntas frecuentes
¿Cómo evitamos que el proyecto se descontrole?
Pasos pequeños con resultado útil, presupuestos fijos por paso y la posibilidad de salir después de cada paso. Los grandes proyectos a precio fijo de doce meses son el camino más seguro hacia la decepción, para ambas partes.
¿Podemos empezar con una hoja de cálculo?
A menudo sí, y es una buena prueba. Si la hoja de cálculo refleja el proceso y solo falla en capacidad multiusuario, permisos o volumen de datos, el requisito está claro y el proyecto es calculable.
¿A quién pertenece el código fuente?
A vosotros, completamente, desde el pago. Está en el contrato. Podéis ir con él a cualquier otro desarrollador, ese es el punto.
¿Qué pasa si durante el desarrollo descubrimos nuevos requisitos?
Es normal y está previsto, porque se trabaja en pasos pequeños. Un nuevo requisito se incorpora al siguiente paso, en lugar de detener todo el proyecto.
¿Cuántos usuarios soporta un sistema así?
Depende de la arquitectura, que planificamos según vuestro crecimiento esperado, desde pocos usuarios en el propio negocio hasta varios cientos en múltiples ubicaciones.
¿Cuándo vale la pena el software propio frente al software estándar?
Cuando tu proceso es una ventaja competitiva real, cuando el software estándar solo encaja al setenta por ciento y el resto termina en trabajo manual, o cuando los costes de licencia por usuario superan el desarrollo en pocos años. Si solo se trata de comodidad, el software estándar es más barato.
¿Funciona en nuestros propios servidores o en la nube?
Ambas opciones son posibles. Para la mayoría de los negocios una solución en la nube requiere menos mantenimiento; donde los datos no pueden salir del local, lo configuramos en infraestructura propia.
05 — Continuar
Páginas relacionadas
- Software individual — Resumen
- Software a medida — Costes
- Software a medida — Por dónde empezar
- Software a medida — Medir el éxito
- Software a medida — Comparación de proveedores
- Software a medida — Riesgos
- Software a medida — Pequeñas empresas
- Software individual — Financiación
- Automatización de procesos
- Integración CRM
- Interfaces API
- Todas las guías
Software individual por región
Siguiente paso
Enviadnos unas líneas sobre vuestro proyecto.
Leemos cada consulta personalmente y respondemos de forma directa. Sin equipo comercial, sin formulario de devolución de llamada al vacío.