Desarrollo interno vs proveedores externos: ¿dónde está el riesgo real?

La responsabilidad sigue a los datos, no al equipo de desarrollo. Así se demuestra el control sobre todo el ecosistema de software.

Por Mladen Petrovic | 2 de agosto, 2026

Los líderes de salud enfrentan una pregunta operativa crítica: cuando ocurre un fallo de software o una brecha de datos, ¿quién asume la responsabilidad? La respuesta ha cambiado drásticamente. El entorno regulatorio actual no distingue entre software desarrollado internamente y soluciones de terceros. La organización de salud sigue siendo completamente responsable en ambos casos. Esta realidad transforma la manera en que los ejecutivos deben abordar la gobernanza de software, la gestión del riesgo y la continuidad operativa.

El software no falla de forma aislada. Las operaciones, sí. Independientemente de si el software es desarrollado internamente o suministrado por proveedores externos, se convierte en parte del mismo ecosistema operativo. El agendamiento, la comunicación con el paciente, las derivaciones, la documentación clínica, la facturación y la identidad del paciente dependen de que la tecnología funcione en conjunto.

Cuando un sistema crítico falla, la interrupción rara vez se queda dentro de esa aplicación. Se propaga a lo largo del viaje del paciente.

---

La responsabilidad no tiene fronteras

A los reguladores no les importa si tu portal de pacientes fue construido por tu equipo interno o adquirido a un proveedor. HIPAA, el RGPD y los marcos emergentes de ciberseguridad en salud tratan a la organización de salud como la última responsable de proteger los datos del paciente y mantener la integridad del sistema. Las acciones de cumplimiento recientes y las directrices del HHS, CISA y organismos internacionales refuerzan este principio: la responsabilidad sigue a los datos, no al equipo de desarrollo.

Bajo la Regla de Seguridad de HIPAA y la Ley HITECH, las entidades cubiertas y sus socios comerciales comparten responsabilidad legal directa por la protección de la información de salud electrónica protegida (ePHI). Esto significa que incluso cuando un proveedor desarrolla y aloja tu solución, tu organización debe garantizar que esa solución cumple con los requisitos de seguridad, privacidad y auditoría. La Regla Final Ómnibus de 2013 lo dejó claro: los socios comerciales son directamente responsables de las infracciones de HIPAA, y las entidades cubiertas siguen siendo responsables de su supervisión.

El desafío rara vez es elegir entre desarrollo interno y proveedores externos. El verdadero desafío es garantizar que todos los sistemas sigan los mismos estándares operativos de seguridad, privacidad, trazabilidad y continuidad.

Cuando cada plataforma opera de forma independiente, las brechas de cumplimiento suelen aparecer entre sistemas, no dentro de ellos.

---

Los cuatro pilares de la gobernanza moderna de software

La pregunta clave ya no es “¿quién lo construyó?” sino “¿puedes demostrar seguridad, privacidad, trazabilidad y resiliencia operativa?” Estos cuatro pilares definen la gobernanza moderna de software en salud.

La seguridad implica que el sistema protege contra el acceso no autorizado, las brechas de datos y las interrupciones operativas. Esto requiere controles documentados, pruebas periódicas y monitoreo continuo, no solo en el lanzamiento sino a lo largo de todo el ciclo de vida del sistema.

La privacidad garantiza que los datos del paciente se recopilen, usen y compartan únicamente de formas que cumplan con HIPAA, el RGPD y otras regulaciones aplicables. La privacidad debe estar integrada en el diseño del sistema desde el inicio, no añadida después del despliegue.

La trazabilidad exige que todo acceso, modificación y decisión que involucre datos del paciente pueda ser reconstruida y auditada. Esto incluye mantener registros de auditoría completos, inventarios de componentes de software y registros de gestión de cambios.

La resiliencia operativa garantiza que las funciones críticas de salud continúen durante las interrupciones, ya sea por ciberataques, fallos del sistema o crisis externas. La resiliencia requiere planes de recuperación probados, sistemas redundantes y responsabilidades claras de continuidad. Para las organizaciones de salud, la resiliencia también implica mantener la comunicación con el paciente, el agendamiento, las derivaciones y la coordinación clínica mientras los sistemas se recuperan.

---

Los marcos que definen las expectativas

Los marcos líderes ofrecen orientación clara sobre lo que esperan los reguladores, independientemente del origen del desarrollo:

• OWASP SAMM (Modelo de Madurez de Aseguramiento de Software) ayuda a las organizaciones a evaluar y mejorar sus prácticas de seguridad de software en gobernanza, diseño, implementación y operaciones.
• NIST SSDF (Marco de Desarrollo de Software Seguro) describe las prácticas para construir software seguro, desde los requisitos hasta el despliegue y el mantenimiento.
• CISA Diseño Seguro enfatiza que la seguridad debe ser parte integral de la arquitectura del software, no una adición posterior.
• Prácticas de Ciberseguridad para la Industria de la Salud del HHS (HICP) ofrece orientación específica para el sector salud sobre la gestión de riesgos cibernéticos en todos los entornos tecnológicos.
• ISO/IEC 27001 e ISO/IEC 27701 proporcionan estándares internacionales reconocidos para la gestión de la seguridad de la información y la privacidad.

Estos marcos convergen en un único principio: la seguridad y la privacidad deben ser demostrables, no asumidas. Ya sea que tu equipo escriba el código o lo haga un proveedor, debes demostrar que tu software cumple con estos estándares a través de documentación, pruebas y supervisión continua.

---

Excelencia operativa a través de la gobernanza

Posicionar la ciberseguridad como parte de la excelencia operativa significa tratar la gobernanza de software como una función central de negocio, no como una casilla de TI. Esto requiere:

• Responsabilidad clara: Asignar la responsabilidad de la seguridad, la privacidad y la resiliencia a nivel ejecutivo.
• Toma de decisiones basada en el riesgo: Evaluar las decisiones de software en función del impacto operativo y la exposición regulatoria, no solo del costo o las funcionalidades.
• Supervisión continua: Monitorear el rendimiento del software, la postura de seguridad y el estado de cumplimiento a lo largo de todo su ciclo de vida.
• Evidencia documentada: Mantener registros que demuestren la diligencia debida en los controles de seguridad, las salvaguardas de privacidad y la planificación de la continuidad.

La gobernanza operativa ya no se mide por la cantidad de controles de seguridad que una organización ha implementado. Se mide por la consistencia con que esos controles sostienen las operaciones de salud cotidianas.

Las organizaciones que destacan en este ámbito tratan la ciberseguridad como algo inseparable de la seguridad del paciente, la estabilidad financiera y la reputación de marca. Entienden que la resiliencia operativa depende de la capacidad de rastrear, verificar y responder a los problemas en todo el software, interno o externo.

---

El camino a seguir

Para los ejecutivos de salud, el camino a seguir es claro: pasar de preguntar “¿quién lo construyó?” a exigir “¿cómo sabemos que es seguro?” Esto implica integrar la gobernanza de software en la gestión integral de riesgos empresariales, garantizando que cada sistema, ya sea desarrollado internamente o adquirido externamente, cumpla los mismos estándares de seguridad, privacidad, trazabilidad y resiliencia.

Las plataformas que sostienen la orquestación operativa, la continuidad y la trazabilidad ayudan a las organizaciones de salud a transformar la gobernanza de un ejercicio de cumplimiento en una capacidad operativa. Al alinearse con estándares internacionales reconocidos como ISO 27001 e ISO 27701, y al mantener prácticas rigurosas de documentación y pruebas, las organizaciones de salud pueden demostrar la diligencia debida independientemente del origen del software. Este enfoque no solo satisface a los reguladores, sino que también genera confianza entre pacientes, socios y partes interesadas.

En el entorno de salud actual, la gobernanza de software ya no se trata de decidir quién desarrolla la tecnología.

Se trata de garantizar que cada sistema — interno o externo — sostenga los mismos estándares de seguridad, privacidad, trazabilidad y continuidad operativa.

Porque los reguladores ya no miden solo las políticas. Miden cada vez más si las organizaciones de salud pueden ejecutarlas en las operaciones cotidianas.