Quién responde si el software de tu clínica incumple
Para directores, gestores y responsables legales de clínicas privadas que necesitan entender la cadena de responsabilidad cuando un fallo del software genera un incumplimiento normativo.
La administración sanciona a la clínica primero; la clínica reclama al proveedor después. El orden importa más que el contrato.
1. El principio: la clínica responde ante la administración
1.1. La regla general
La clínica es el sujeto obligado ante la administración: es quien tiene la licencia sanitaria, quien emite las facturas, quien trata los datos de los pacientes y quien presta el servicio sanitario. Cuando Hacienda inspecciona una factura, cuando la AEPD investiga una brecha de datos o cuando un paciente reclama su historia clínica, el interlocutor es la clínica — no su proveedor de software. El software es una herramienta que la clínica elige y usa; el incumplimiento que se derive de su uso es, en primera instancia, responsabilidad de quien lo usa.
1.2. La excepción: el defecto del producto
Si el incumplimiento se produce por un defecto del software — un error en el cálculo del impuesto, un fallo en el cifrado, una exportación que pierde datos —, la clínica tiene una vía de reclamación contra el proveedor. Pero esa vía es contractual (entre la clínica y el proveedor) o civil (por responsabilidad del producto), no administrativa. La administración sanciona a la clínica primero; la clínica reclama al proveedor después. El orden importa: la multa la pagas tú, y la recuperas — si la recuperas — del proveedor.
1.3. La obligación de elegir bien
La normativa de protección de datos es explícita en esto: el responsable del tratamiento (la clínica) tiene la obligación de elegir un encargado del tratamiento (el proveedor) que ofrezca garantías suficientes. Si el proveedor falla y la clínica no había verificado sus garantías, la responsabilidad es compartida — no porque la clínica haya causado el fallo, sino porque no cumplió su obligación de diligencia en la selección. Elegir mal al proveedor no es una desgracia que te pasa: es un incumplimiento en sí mismo.
2. El contrato con el proveedor: la segunda línea
2.1. Lo que el contrato debería cubrir
El contrato entre la clínica y el proveedor de software es el documento que define quién responde de qué cuando algo falla. Debería cubrir: las obligaciones de cumplimiento normativo del proveedor (protección de datos, fiscalidad, interoperabilidad), las responsabilidades en caso de incumplimiento, los SLA de disponibilidad y recuperación, las condiciones de portabilidad de datos al terminar el contrato, y las penalizaciones por incumplimiento. Si el contrato no cubre alguno de estos puntos, la clínica está desprotegida precisamente donde más lo necesita.
2.2. El contrato de encargado del tratamiento
El contrato de encargado del tratamiento (artículo 28 del RGPD) es obligatorio y tiene cláusulas que no son negociables: el proveedor solo trata los datos según las instrucciones de la clínica, garantiza la confidencialidad, implementa las medidas de seguridad adecuadas, asiste en el ejercicio de derechos, notifica las brechas, devuelve o destruye los datos al terminar, y se somete a auditoría. Si tu contrato con el proveedor no tiene estas cláusulas, el contrato incumple el RGPD — y la responsabilidad de ese incumplimiento es de la clínica por no haberlas exigido.
2.3. El contrato de licencia o servicio
Además del contrato de encargado del tratamiento, el contrato de licencia o de prestación de servicios define las condiciones comerciales: qué incluye el servicio, qué soporte hay, qué actualizaciones se garantizan, qué pasa si el proveedor desaparece. Las cláusulas de limitación de responsabilidad del proveedor son especialmente relevantes: muchos contratos limitan la responsabilidad del proveedor al importe anual de la licencia — lo que significa que si un fallo del software genera una multa de 20.000 euros y la licencia cuesta 2.000, el proveedor solo responde por 2.000.
El contrato define quién paga qué cuando el software falla — pero si el contrato limita la responsabilidad al importe de la licencia, la diferencia la asume la clínica.
3. Protección de datos: responsable y encargado
3.1. La clínica como responsable del tratamiento
El RGPD asigna el rol de responsable del tratamiento a quien determina los fines y los medios del tratamiento de datos personales. La clínica trata datos de salud de sus pacientes con fines asistenciales: es el responsable del tratamiento. Eso significa que la clínica responde ante la AEPD por cualquier incumplimiento en el tratamiento de esos datos — incluidos los que se producen a través del software que utiliza. La responsabilidad no se delega al proveedor por el hecho de usar su software.
3.2. El proveedor como encargado del tratamiento
El proveedor de software que aloja, procesa o accede a los datos de los pacientes de la clínica es un encargado del tratamiento. Tiene obligaciones propias bajo el RGPD: implementar medidas de seguridad, notificar brechas al responsable, no subcontratar sin autorización y tratar los datos solo según las instrucciones del responsable. Si el encargado incumple sus obligaciones, puede ser sancionado directamente por la AEPD — pero eso no exime al responsable (la clínica) de su propia responsabilidad en la elección y supervisión del encargado.
3.3. La corresponsabilidad en la práctica
En la práctica, un incumplimiento de protección de datos relacionado con el software puede generar responsabilidad compartida. Si el proveedor no cifra los datos y la clínica no lo verificó, ambos pueden ser sancionados: el proveedor por no implementar la medida y la clínica por no elegir un proveedor con garantías suficientes. Las sanciones del RGPD pueden llegar a 20 millones de euros o el 4 % de la facturación anual — y se aplican tanto al responsable como al encargado, cada uno por sus propias obligaciones.
Antes de elegir software, conoce las preguntas que debes hacerte
En 30 minutos de análisis gratuito identificamos qué procesos de tu clínica se pueden digitalizar hoy.
4. Incumplimiento fiscal: VeriFactu, factura electrónica
4.1. La factura es responsabilidad del emisor
Cuando una factura no cumple los requisitos legales — formato incorrecto, datos erróneos, incumplimiento de VeriFactu —, la responsabilidad es del emisor: la clínica. Hacienda no sanciona al proveedor de software por emitir una factura incorrecta; sanciona a quien la emite. Si el software tiene un error en el cálculo del IVA o en la generación del registro VeriFactu, la clínica es quien recibe la inspección, la corrección y, en su caso, la sanción. La reclamación al proveedor viene después, por vía contractual.
4.2. VeriFactu y la responsabilidad del software
VeriFactu introduce una obligación técnica específica: el software de facturación tiene que generar registros firmados, encadenados y comunicados a Hacienda en tiempo real. Si el software no genera esos registros correctamente, la clínica incumple la normativa. Pero VeriFactu también introduce una responsabilidad del fabricante de software: el proveedor debe declarar que su software cumple los requisitos técnicos. Eso crea una cadena de responsabilidad más clara que en la facturación tradicional — aunque la sanción sigue llegando primero a la clínica.
4.3. Factura electrónica obligatoria
La factura electrónica obligatoria bajo la Ley Crea y Crece exigirá que las facturas entre empresas se emitan en formato electrónico estructurado. Si el software de la clínica no puede emitir facturas en ese formato cuando entre en vigor, la clínica incumple la ley — no el proveedor. La obligación de tener un software que cumpla es de la clínica; la obligación de actualizar el software para que cumpla es del proveedor si el contrato lo establece. Sin esa cláusula contractual, la clínica paga la licencia y la actualización.
5. Portabilidad: cuando el paciente no puede llevarse sus datos
5.1. El derecho del paciente y la obligación de la clínica
Cuando un paciente ejerce su derecho de portabilidad, la obligación de cumplir es de la clínica. Si el software no puede exportar la historia clínica en un formato estructurado y el paciente reclama ante la AEPD, la responsable es la clínica — no el proveedor. La clínica eligió el software, conoce (o debería conocer) sus capacidades de exportación, y es quien tiene la relación con el paciente. El proveedor tiene una responsabilidad contractual con la clínica, pero no una responsabilidad administrativa ante la AEPD por la portabilidad del paciente.
5.2. El lock-in como problema regulatorio
Si tu proveedor de software dificulta la exportación de datos — formatos propietarios, exportaciones incompletas, costes desproporcionados por la extracción — estás ante un problema que combina lo contractual con lo regulatorio. El RGPD te obliga a poder entregar datos al paciente en formato estructurado; si tu proveedor lo impide, estás incumpliendo por causa de tu proveedor. La solución no es quejarte: es tener las cláusulas de portabilidad en el contrato antes de firmarlo, y verificar que funcionan antes de necesitarlas.
5.3. El EHDS y la portabilidad obligatoria
El EHDS va a reforzar las obligaciones de portabilidad con formatos definidos y plazos concretos. Cuando esas obligaciones entren en vigor, un software que no exporte en los formatos requeridos hará que la clínica incumpla automáticamente. La responsabilidad seguirá siendo de la clínica ante la administración, pero la presión sobre los proveedores será mayor porque el incumplimiento será objetivo y verificable — no hay margen para «cumplimos de otra forma».
6. Brecha de seguridad: quién notifica y quién paga
6.1. La obligación de notificar
El RGPD establece dos notificaciones obligatorias en caso de brecha de datos personales: a la autoridad de control (AEPD) en 72 horas, y al afectado sin dilación si hay riesgo alto. La obligación de notificar a la AEPD es del responsable del tratamiento — la clínica. El encargado (el proveedor) tiene la obligación de notificar al responsable (la clínica) sin dilación cuando detecta la brecha. Si el proveedor no te avisa a tiempo y tú no puedes notificar a la AEPD en 72 horas, ambos incumplen: él su obligación de informar, tú tu obligación de notificar.
6.2. El coste de una brecha
El coste de una brecha de datos de salud incluye: la posible sanción de la AEPD (que puede ser de miles a millones de euros), el coste de la notificación a los afectados, el coste reputacional para la clínica, los honorarios legales y, en casos graves, la indemnización a los pacientes afectados. Si la brecha se produjo por un fallo del software del proveedor, la clínica puede reclamar esos costes al proveedor — si el contrato lo prevé. Si el contrato limita la responsabilidad del proveedor al importe de la licencia, la clínica asume la diferencia.
6.3. El seguro de ciber-responsabilidad
Un seguro de ciber-responsabilidad cubre parte de los costes de una brecha de datos: notificación a afectados, respuesta al incidente, defensa legal y, en algunos casos, sanciones. Para una clínica que trata datos de salud, es una cobertura relevante que complementa — pero no sustituye — la responsabilidad contractual del proveedor. Antes de contratar el seguro, verifica que cubre específicamente datos de salud y que las exclusiones no dejan fuera los escenarios más probables.
Documentar el fallo con precisión es el primer paso: sirve para gestionar el incidente, para reclamar al proveedor y para responder ante la administración.
7. Las cláusulas que te protegen y las que no
7.1. Cláusulas que sí protegen
Las cláusulas contractuales que realmente protegen a la clínica son: obligación del proveedor de cumplir la normativa aplicable (especificando cuál), responsabilidad del proveedor por incumplimiento con indemnización sin tope o con tope alto, obligación de notificación de brechas con plazo concreto, obligación de actualización para cumplimiento normativo incluida en la licencia, y portabilidad de datos al terminar el contrato en formato estructurado y sin coste adicional. Cada una de estas cláusulas tiene que estar explícita; lo que no está en el contrato no te protege.
7.2. Cláusulas que no protegen
Las cláusulas que parecen proteger pero no lo hacen: «el proveedor cumple la normativa vigente» sin especificar cuál, limitación de responsabilidad al importe anual de la licencia, «el proveedor se compromete a colaborar con el cliente» sin obligación concreta, y «los datos se entregarán en un formato razonable» sin definir el formato. Cada una de estas cláusulas da una falsa sensación de protección: cuando las necesitas, descubres que no dicen nada ejecutable.
7.3. La cláusula de actualización normativa
La cláusula más importante para una clínica que depende de su software para cumplir normas cambiantes es la de actualización normativa. ¿El proveedor se compromete a actualizar el software cuando cambia la normativa? ¿Esa actualización está incluida en la licencia o tiene coste adicional? ¿Con qué plazo se compromete a implementarla? Una norma como VeriFactu o la factura electrónica obliga a partir de una fecha: si el proveedor no actualiza a tiempo, la clínica incumple. Esa cláusula es la que decide si el problema es del proveedor o es tuyo.
8. Cómo prevenir: lo que hay que revisar antes de firmar
8.1. Revisar las certificaciones y medidas de seguridad
Antes de firmar, verifica las certificaciones del proveedor en los registros públicos (qué vale cada certificado) y pide documentación de las medidas técnicas de seguridad: cifrado, control de acceso, copias de seguridad, plan de respuesta a incidentes. Si el proveedor no puede documentar sus medidas de seguridad, no cumple la obligación del artículo 28 del RGPD — y tú no cumples tu obligación de diligencia al elegirlo.
8.2. Probar la exportación de datos
Antes de firmar, prueba la exportación de datos del software. ¿En qué formatos exporta? ¿La exportación incluye todos los datos clínicos, incluidas imágenes y documentos? ¿Los datos exportados son legibles por otro sistema o son un bloque opaco? Si la exportación es un PDF de cien páginas, ya sabes que cuando el paciente pida portabilidad o cuando quieras cambiar de proveedor, tus opciones serán limitadas. Mejor saberlo antes de firmar que cuando el paciente reclame.
8.3. Negociar la responsabilidad
El contrato estándar del proveedor suele estar redactado para proteger al proveedor, no a la clínica. La limitación de responsabilidad, la exclusión de garantías y la cláusula de fuerza mayor están ahí por defecto. Tu trabajo es negociar: subir el tope de responsabilidad, incluir la actualización normativa en la licencia, definir los formatos de portabilidad y establecer penalizaciones por incumplimiento de SLA. Un contrato que no se negocia es un contrato que protege al proveedor.
9. Qué hacer cuando el incumplimiento ya ha ocurrido
9.1. Documentar el fallo
Lo primero es documentar el fallo con precisión: qué norma se incumple, qué función del software falla, desde cuándo, qué datos están afectados, qué pacientes se ven impactados. Esa documentación sirve para tres cosas: para gestionar el incidente, para reclamar al proveedor y para responder ante la administración si hay inspección. Sin documentación, tu posición ante el proveedor y ante la administración es más débil.
9.2. Notificar según corresponda
Si el incumplimiento implica una brecha de datos personales, notifica a la AEPD en 72 horas y al paciente si hay riesgo alto. Si el incumplimiento es fiscal, consulta con tu asesor si hay que presentar una regularización voluntaria — hacerlo antes de que Hacienda lo detecte reduce la sanción. Si el incumplimiento afecta a la historia clínica del paciente, infórmale directamente. La transparencia en la gestión del incidente no elimina la responsabilidad, pero sí reduce el daño reputacional y la sanción.
9.3. Reclamar al proveedor
Con la documentación del fallo, reclama al proveedor por vía contractual. Exige la corrección del fallo con plazo, la compensación por los daños causados según las cláusulas del contrato, y un informe del proveedor explicando la causa raíz y las medidas para evitar la recurrencia. Si el contrato tiene cláusulas de responsabilidad claras, la reclamación tiene base. Si el contrato es ambiguo o limita la responsabilidad a un importe simbólico, la vía contractual puede no ser suficiente y puede ser necesario recurrir a la vía civil.
Riesgo normativo
¿Tu infraestructura resistiría una inspección de la AEPD?
El RGPD clasifica los expedientes clínicos como datos de categoría especial. Una brecha técnica o un consentimiento mal custodiado puede acarrear sanciones muy elevadas. Solicita un análisis técnico de viabilidad normativa.
10. Preguntas frecuentes sobre responsabilidad por incumplimiento del software
¿Puedo trasladar toda la responsabilidad al proveedor de software?
No. La responsabilidad administrativa — ante Hacienda, la AEPD o la autoridad sanitaria — es de la clínica como sujeto obligado. Puedes repercutir los daños al proveedor por vía contractual o civil, pero la sanción administrativa la recibes tú primero. El RGPD es explícito: el responsable del tratamiento no puede eludir su responsabilidad delegándola al encargado. Lo que sí puedes hacer es configurar el contrato para que el proveedor te indemnice si el incumplimiento se debe a un fallo de su software — pero eso requiere cláusulas específicas que muchos contratos estándar no incluyen.
¿Qué pasa si el proveedor desaparece o quiebra?
Si el proveedor desaparece, tus datos están en riesgo y tu capacidad de cumplir la normativa depende de lo que hayas previsto. Un contrato con cláusula de escrow — el código fuente se deposita en un tercero de confianza y se libera si el proveedor cesa su actividad — y con exportación de datos periódica te da opciones. Sin esas previsiones, la desaparición del proveedor te deja sin software, sin acceso a los datos y sin capacidad de cumplir obligaciones que siguen siendo tuyas. La quiebra del proveedor no suspende tus obligaciones normativas.
¿La AEPD puede sancionar directamente al proveedor de software?
Sí. El RGPD permite sancionar tanto al responsable como al encargado del tratamiento. Si el proveedor (encargado) incumple sus obligaciones — no cifra los datos, no notifica una brecha, subcontrata sin autorización —, la AEPD puede sancionarlo directamente. Pero eso no exime a la clínica (responsable) de su propia responsabilidad: si la clínica no verificó que el proveedor tenía medidas de seguridad adecuadas, también puede ser sancionada. Las sanciones pueden ser independientes: una a la clínica por no elegir bien, otra al proveedor por no cumplir.
¿Las multas del RGPD se aplican realmente a clínicas pequeñas?
Sí, aunque las cuantías se adaptan al tamaño de la organización. La AEPD ha sancionado a clínicas y consultorios por incumplimientos como falta de contrato de encargado del tratamiento, medidas de seguridad insuficientes y no atender derechos de los pacientes. Las multas a clínicas pequeñas suelen ser de miles a decenas de miles de euros — no los millones que los titulares asocian al RGPD —, pero para una clínica con facturación modesta, una sanción de 10.000 euros es significativa. El tamaño de la clínica no es un escudo; la proporcionalidad reduce la cuantía, no la elimina.
¿Qué hago si mi proveedor se niega a actualizar el software para cumplir una nueva norma?
Si tu contrato incluye una cláusula de actualización normativa, exígela por escrito y documenta la negativa. Si no la incluye, estás en una posición más débil: el proveedor puede argumentar que la actualización no está cubierta por la licencia. En cualquier caso, el incumplimiento normativo sigue siendo tuyo — no del proveedor. Si el proveedor no actualiza y la norma entra en vigor, tienes dos opciones: cambiar de proveedor (lo que requiere portabilidad de datos) o implementar una solución alternativa mientras gestionas la transición. Ninguna de las dos es cómoda, y ambas se previenen mejor en el contrato.
¿El proveedor es responsable si un paciente sufre un daño por un error del software?
Si un error del software causa un daño al paciente — por ejemplo, una interacción medicamentosa no detectada, un dato clínico perdido que afecta a una decisión — la responsabilidad civil puede alcanzar tanto a la clínica como al proveedor. La clínica responde ante el paciente como prestador del servicio sanitario; el proveedor puede responder como fabricante del producto defectuoso. La cadena de responsabilidad depende de los hechos concretos, del contrato y de la jurisdicción. Pero el primer recurso del paciente es siempre contra la clínica, que es con quien tiene la relación asistencial.
¿Necesito un abogado especializado para revisar el contrato con mi proveedor?
Para una clínica que trata datos de salud, sí. El contrato con el proveedor de software combina derecho tecnológico, protección de datos, derecho sanitario y derecho mercantil. Un abogado generalista puede revisar las condiciones comerciales, pero las cláusulas de encargado del tratamiento, la limitación de responsabilidad en el contexto del RGPD y las obligaciones de actualización normativa requieren conocimiento específico. El coste de esa revisión es una fracción del coste de una sanción o de un cambio de proveedor forzado por un contrato mal negociado.
¿El seguro de responsabilidad civil de mi clínica cubre fallos del software?
Depende de la póliza. El seguro de responsabilidad civil profesional de una clínica cubre los daños derivados de la actividad sanitaria, pero no siempre cubre los daños derivados de un fallo tecnológico del proveedor. Las sanciones administrativas (AEPD, Hacienda) suelen estar excluidas de los seguros de RC estándar. Un seguro de ciber-responsabilidad es el producto específico que cubre brechas de datos, respuesta al incidente y, en algunos casos, sanciones regulatorias. Revisa tu póliza de RC y complementa con ciber-responsabilidad si tus datos están en un software en la nube.
Más sobre qué exigirle al proveedor
Todo lo que va a obligar a tu clínica hasta 2031, con fecha
VeriFactu, el Reglamento de IA, el EHDS, la factura electrónica y el marcado CE del software sanitario: lo…
Leer artículo →
Qué vale un certificado que te enseña un proveedor de software clínico
ENS, ISO 27001, RGPD compliance: qué se puede verificar en un registro público, qué no se comprueba y…
Leer artículo →
En qué formato salen tus datos de la clínica — y por qué importa
CSV, PDF, SQL y los archivos: qué se lleva cada formato, qué se pierde y por qué un…
Leer artículo →Información adicional
Última actualización: septiembre de 2026.
