Cuando el proveedor falla, usted también responde: la cadena de suministro de datos bajo la LOPDP
Una API conectada al Registro Civil expuso dieciocho millones de registros con datos biométricos y domicilios. El código fuente de un core bancario utilizado por decenas de instituciones ecuatorianas fue puesto a la venta con datos sin cifrar. En ambos casos, el debate buscó un único culpable. La LOPDP no funciona así: responsable y encargado responden simultáneamente, por razones distintas, y ninguno puede escudarse en el otro.
Dos incidentes, un mismo principio legal
En mayo de 2026, dos eventos de alto impacto sacudieron el ecosistema de protección de datos en Ecuador en cuestión de días.
El primero involucró una API REST operada por una empresa intermediaria que proveía servicios de consulta de datos del Registro Civil a entidades del sector financiero e instituciones públicas. La API fue dejada operativa sin mecanismos básicos de autenticación, lo que permitió la extracción masiva de aproximadamente dieciocho millones de registros que incluían datos biométricos, domicilios y títulos académicos de ciudadanos ecuatorianos.
El segundo incidente involucró la filtración y venta del código fuente de un sistema de core bancario propietario utilizado por cooperativas, mutualistas y bancos de tamaño mediano en Ecuador. Participantes con conocimiento técnico directo señalaron que los datos personales financieros almacenados no contaban con cifrado — lo que convierte el código expuesto en un mapa de ataque hacia los datos de los clientes.
En ambos casos, el debate se centró en identificar a un único responsable: ¿el proveedor o la institución que contrató el servicio? Esa es la pregunta equivocada.
Lo que establece la LOPDP: responsabilidades simultáneas, no excluyentes
La Ley Orgánica de Protección de Datos Personales establece un esquema de responsabilidades diferenciadas que operan en paralelo. No es un sistema en cascada donde el encargado absorbe la responsabilidad del responsable, ni un mecanismo mediante el cual el responsable transfiere su riesgo firmando un contrato de servicios.
El argumento "fue el proveedor" no exime al responsable. El Art. 47 num. 11 LOPDP obliga al responsable a verificar que el encargado implementa medidas adecuadas. Si no lo hizo antes del incidente, ya estaba en incumplimiento.
Capa 1 — El encargado: el intermediario o proveedor tecnológico
El Art. 40 Reglamento SPDP establece que el encargado debe ofrecer garantías suficientes para aplicar medidas técnicas, jurídicas, administrativas y organizativas apropiadas. El Art. 41 exige que esas medidas sean equiparables a las del propio responsable.
Una API expuesta sin autenticación básica no cumple ninguno de esos estándares. Constituye una vulneración de confidencialidad bajo el Art. 24 num. 4 Reglamento. El Art. 43 LOPDP obliga al encargado a notificar al responsable en un plazo máximo de dos días desde que tuvo conocimiento de la vulneración. El incumplimiento configura infracciones graves bajo el Art. 70 nums. 4 y 5 LOPDP.
En el caso del core bancario: si el proveedor almacena datos personales financieros sin cifrado, incumple el Art. 37 LOPDP, que exige medidas de confidencialidad, integridad y disponibilidad. El Art. 47 num. 2 LOPDP refuerza esta obligación al exigir herramientas técnicas apropiadas que garanticen el tratamiento conforme a la ley.
Capa 2 — El responsable: la institución financiera o pública que contrató el servicio
Las instituciones que contrataron la API o que operan sobre el core bancario son responsables del tratamiento de los datos de sus clientes. Esa responsabilidad no se transfiere al proveedor mediante ningún contrato de servicios.
El Art. 47 num. 11 LOPDP obliga al responsable a asegurar que el encargado implementa medidas adecuadas: verificación activa, no confianza pasiva. El Art. 43 LOPDP establece un plazo máximo de cinco días para notificar a la SPDP desde que el responsable tiene conocimiento del riesgo. El Art. 46 LOPDP exige notificar a los titulares afectados dentro de tres días desde ese mismo momento.
Capa 3 — Las entidades que almacenaron datos localmente
En el incidente de la API, varias entidades almacenaban localmente las respuestas de las consultas para evitar el costo por petición. Al hacerlo, dejaron de ser meras usuarias de un servicio y pasaron a ser responsables independientes de esas copias de datos personales. Ese almacenamiento requiere base de licitud propia bajo el Art. 26 LOPDP. Cuando los datos incluyen información biométrica, aplican estándares adicionales de datos sensibles.
La EIPD: el mecanismo preventivo que debió haber existido antes
Una Evaluación de Impacto en la Protección de Datos no es un trámite administrativo. Es el instrumento que obliga a identificar estos riesgos antes de que el sistema entre en operación.
El Art. 42 LOPDP establece que la EIPD es obligatoria cuando existe tratamiento a gran escala de datos sensibles, elaboración de perfiles con efectos jurídicos, o monitoreo sistemático a gran escala. Una API con acceso a datos biométricos del universo de ciudadanos ecuatorianos activa los tres criterios simultáneamente. El Art. 31 Reglamento SPDP es explícito: la EIPD debe realizarse de forma previa al inicio del tratamiento, no como respuesta a un incidente.
La notificación oportuna del incidente y la ejecución rápida de medidas de respuesta son atenuantes bajo el Art. 46 LOPDP. Los atenuantes reducen la sanción; no eliminan la infracción por omisión de la EIPD previa ni la responsabilidad por no haber verificado al encargado.
Cinco verificaciones que su organización no puede postergar
| Verificación | Riesgo si no existe |
|---|---|
| ¿Tiene contrato de encargo (DPA) con el proveedor de la API o sistema? Con el contenido mínimo del Art. 41 Reglamento SPDP. | Sin DPA, el responsable no puede acreditar ni exigir las medidas del encargado ante la SPDP. Infracción grave bajo Art. 68 LOPDP. |
| ¿Su organización almacena copias locales de datos obtenidos de APIs externas? | Al hacerlo asume la calidad de responsable independiente de esas copias. Requiere base de licitud propia. Si incluye biométricos, aplican estándares adicionales. |
| ¿Solicitó formalmente al proveedor tecnológico evidencia de que los datos están cifrados en reposo y en tránsito? | Obligación del responsable bajo Art. 47 num. 11 LOPDP y Art. 41 Reglamento: verificación activa, no confianza pasiva. |
| ¿Realizó EIPD previa para los sistemas que procesan datos personales a escala? | Obligatoria antes del inicio del tratamiento. Su ausencia es infracción grave (Art. 68 num. 5 LOPDP). No la subsana que el incidente no haya ocurrido aún. |
| ¿Tiene activado el protocolo de notificación a la SPDP desde el momento del conocimiento del riesgo? | El plazo de 5 días del Art. 43 LOPDP comienza cuando el responsable conoce el riesgo, no cuando el ataque se consuma. Retrasos no justificados generan sanción adicional. |
El peso económico del incumplimiento
Las infracciones graves para entidades privadas se ubican entre el 0,7 % y el 1 % del volumen de negocios del ejercicio económico anterior. Para una institución financiera o cooperativa mediana, esa cifra puede ser materialmente significativa.
El costo reputacional —titulares con datos biométricos expuestos, cobertura mediática, pérdida de confianza del cliente— no tiene techo en ninguna tabla de multas. Lo que los incidentes de 2026 dejaron en claro es que la cadena de suministro de datos es tan segura como su eslabón más débil, y que la LOPDP hace responsable a quien contrató ese eslabón, no únicamente al eslabón que falló.
¿Sabe si sus proveedores cumplen los estándares que la LOPDP le exige verificar?
En Wiibiq realizamos un diagnóstico gratuito DataGuard que revisa su cadena de proveedores con acceso a datos personales, identifica contratos de encargo incompletos y evalúa si sus sistemas críticos cuentan con EIPD documentada.
Solicitar diagnóstico gratuito DataGuard →