# Análisis de cumplimiento contractual ## Acuerdo de Desarrollo Tecnológico y Colaboración · Plataforma Kynda **Fecha:** 21 de agosto de 2026. Ampliado el 9 de septiembre de 2026. **Documento analizado:** Acuerdo de colaboración V8, cuerpo principal y Anexo I. **Contrastado contra:** repositorio del proyecto y entornos de Validación y Producción en explotación. **Método:** verificación cláusula por cláusula contra el código fuente. Los hallazgos relativos a la titularidad de los activos se confirmaron mediante consulta directa a la interfaz de programación de GitHub y mediante acceso al panel de configuración del repositorio, en ambos casos con credencial de la Sociedad. La ampliación de 9 de septiembre de 2026 incorpora los hallazgos derivados de la extracción íntegra de ambas bases de datos, de sus ficheros asociados y del repositorio con la totalidad de sus registros de despliegue. Esta ampliación permite acreditar por primera vez qué se encuentra realmente en ejecución en el entorno productivo, extremo que hasta la fecha solo podía inferirse de la lectura del código. Los apartados afectados se señalan de forma expresa. --- ## 1. Incumplimientos verificados ### 1.1 Titularidad y control de los activos Este es el incumplimiento de mayor solidez probatoria, dado que no depende de valoración técnica alguna y se ha confirmado con datos obtenidos directamente de la plataforma. **El repositorio no es propiedad de la Sociedad.** La cláusula 2.2 exige la entrega del código fuente en un repositorio propiedad de la Sociedad. La consulta a la plataforma devuelve que el titular es una cuenta personal de usuario, no una organización corporativa de la Sociedad. **La Sociedad carece de control sobre él.** La cláusula 6.3 exige acceso permanente con permisos suficientes para el control y la continuidad. La cuenta de la Sociedad consta como colaboradora con permiso de escritura, pero sin permisos de administración. En la práctica esto significa que la Sociedad no puede transferir el repositorio, ni gestionar sus credenciales, ni administrar quién accede a él, ni recuperarlo en caso de que la cuenta del desarrollador dejara de existir. El único administrador es el desarrollador. **Ningún activo se ha transferido.** La cláusula 6.1 exige que los activos sean titularidad de la Sociedad desde su creación, o bien que se transfieran antes de la aceptación. El inventario elaborado por el propio desarrollador conserva las diez casillas de su lista de traspaso sin marcar, y reconoce que la plataforma de despliegue, los dos proyectos de base de datos y el servicio de correo permanecen bajo cuentas de la consultora. **Existe dependencia crítica de cuentas personales**, supuesto que la cláusula 6.4 prohíbe de forma expresa. Se han identificado tres: - Una dirección de correo personal figura incorporada a una migración que se ejecuta en todos los entornos, incluido el productivo, con rol de operaciones de alcance global. Ese rol otorga acceso transversal a los datos de la totalidad de los clientes. - El titular del equipo de despliegue es una segunda cuenta de correo personal. No se trata de una deducción: la propia configuración del repositorio lo documenta al explicar que fija el autor de las modificaciones a esa cuenta por ser la titular del equipo, de modo que los despliegues superen la comprobación de la plataforma. - Los entornos de Validación y Producción comparten una misma contraseña de base de datos, extremo que el inventario reconoce. **La ausencia de control se ha verificado en el propio panel de la plataforma.** *(Ampliación de 9 de septiembre de 2026.)* Se accedió ese día a la configuración del repositorio con la cuenta de la Sociedad. La plataforma responde con el mensaje literal *"You don't have access to repository options"* y reduce el menú de configuración a tres apartados. La consulta a la interfaz de programación confirma el rol asignado: escritura, sin permisos de administración ni de mantenimiento. El titular es una cuenta personal que sí los ostenta en su totalidad. La consecuencia práctica excede la mera incomodidad administrativa. La Sociedad no puede consultar los avisos automáticos que el repositorio tenga configurados hacia servicios externos, ni el registro de accesos, ni la relación completa de personas autorizadas. La plataforma responde a esas consultas con un error de página inexistente, comportamiento deliberado que impide siquiera distinguir entre la ausencia de configuración y la ausencia de permiso. **No resulta posible, por tanto, determinar si información del proyecto se está remitiendo a terceros.** Únicamente el desarrollador se encuentra en condiciones de acreditarlo. **La Sociedad tampoco dispone de las credenciales de sus propias bases de datos.** *(Ampliación de 9 de septiembre de 2026.)* La contraseña de acceso directo a ambos entornos no obra en su poder, y la plataforma que los aloja no permite recuperarla una vez creada. La copia de seguridad practicada el 9 de septiembre hubo de realizarse por vías alternativas, sirviéndose de la condición de propietaria de la cuenta que ostenta la Sociedad. Se materializa así con precisión el supuesto que la cláusula 6.4 prohíbe: existe un dato imprescindible para operar los sistemas que reside en exclusiva en poder del desarrollador. **La declaración de no dependencia resulta materialmente inexacta.** La cláusula 5.2 exige confirmación escrita de que ningún activo permanece bajo cuentas personales, licencias nominativas o entornos controlados por el desarrollador. El inventario entregado afirma que no existen pasos dependientes de la máquina o la memoria de una persona concreta. El repositorio contradice esa afirmación en dos puntos comprobables. El fichero de reglas de arquitectura que la propia declaración invoca como prueba de que el conocimiento reside en el repositorio está excluido de él por configuración deliberada. Y el documento de bienvenida remite a documentación de credenciales alojada en el disco personal del desarrollador. ### 1.2 Tipos de evidencia admitidos El Anexo I lo exige en dos lugares distintos. El módulo 5 requiere admitir imagen en formatos JPEG, PNG y HEIC, vídeo en formatos MP4 y MOV, y texto. El módulo 2 requiere poder definir el tipo de evidencia exigida para validar cada acción, incluyendo al menos imagen, vídeo o texto. **El vídeo no existe en ninguna capa del sistema.** La búsqueda de cualquier referencia a formatos de vídeo en la totalidad del repositorio no devuelve ninguna coincidencia. El selector de ficheros admite exclusivamente imágenes, y la pantalla del validador, ante un fichero de otra naturaleza, muestra el nombre técnico del formato en lugar de un reproductor. **El texto no constituye un tipo de evidencia autónomo.** Existen campos de texto, pero el envío queda bloqueado si no se adjunta al menos una fotografía. La columna de la base de datos destinada al texto libre de la evidencia, además, no se escribe ni se lee en ningún punto del código. **No hay control sobre los formatos admitidos.** El contrato nombra tres formatos de imagen. El sistema acepta cualquiera, sin lista blanca ni validación en el servidor. El formato HEIC, propio de los dispositivos iPhone, se acepta en la subida pero no se previsualiza en los navegadores de uso mayoritario. **La configuración de tipos de evidencia carece de efecto.** El panel de administración permite marcar qué tipos se exigen y almacena esa configuración, pero ningún punto del código la consulta para condicionar el formulario del participante. Desmarcar la fotografía no produce efecto alguno, ya que continúa siendo obligatoria. ### 1.3 Formalización del cambio de alcance El desarrollador sostiene que la retirada del vídeo y del texto responde a una decisión de la Sociedad adoptada el 12 de junio de 2026. La cláusula 8 del Anexo I exige que toda eliminación de funcionalidades acordadas se formalice mediante documento de control de cambios firmado por ambas partes, en el que se identifiquen cinco elementos: la descripción del cambio, su justificación y la parte solicitante, el impacto en alcance y plazos, el impacto económico y la fecha de entrada en vigor. La cláusula concluye estableciendo que el desarrollador no podrá reducir, eliminar ni aplazar unilateralmente el alcance acordado. Se ha planteado que ese control de cambios lo constituirían las modificaciones registradas en el repositorio. Se examinó el historial completo, con el siguiente resultado. Ninguna de las noventa modificaciones registradas menciona la retirada del vídeo o del texto; la búsqueda por esos términos no devuelve coincidencia alguna relacionada con el alcance. La única modificación registrada el 12 de junio de 2026, fecha de la decisión invocada, versa sobre la documentación de direcciones de entorno. Con independencia de ese resultado, un registro de modificaciones no satisfaría la cláusula ni aunque documentara el cambio. Se trata de un acto unilateral del desarrollador, carece de firma de la Sociedad y no identifica a la parte solicitante. Acredita qué se modificó y en qué momento, pero no acredita acuerdo entre las partes. La reducción de alcance queda, por tanto, documentada por una sola de las partes y sin formalizar. El acta de aceptación que el desarrollador invoca como respaldo permanece sin firmar, en estado de plantilla. ### 1.4 Política de copias de seguridad El apartado 3.2 del Anexo I exige copias de seguridad automáticas diarias, con retención mínima de treinta días y verificación periódica de la capacidad de restauración. Los tres requisitos incumplen, y el propio desarrollador lo documenta: | Exigencia contractual | Estado documentado por el desarrollador | |---|---| | Retención mínima de 30 días | Siete días. La recuperación a punto en el tiempo consta como acción pendiente de puesta en producción | | Cobertura de las evidencias | Las copias no incluyen los ficheros de almacenamiento, esto es, las fotografías | | Verificación periódica de restauración | El registro de ensayos contiene una única línea, con la anotación "pendiente" | Es el incumplimiento de acreditación más directa, puesto que la exigencia es numérica y no admite lectura alternativa. *(Ampliación de 9 de septiembre de 2026.)* Se añade un extremo verificado en esa fecha: hasta ese día la Sociedad no disponía de copia propia alguna de la información de la plataforma. La salvaguarda de los datos dependía por completo de la infraestructura contratada por el desarrollador y de la retención de siete días que esta ofrece. La primera copia íntegra bajo control de la Sociedad, comprensiva de ambas bases de datos, de sus ficheros y del repositorio con todo su historial, se practicó ese día por iniciativa propia y sin intervención del desarrollador. Conviene dejar constancia de que esa copia hubo de obtenerse sorteando la falta de credenciales descrita en el apartado 1.1. La obligación contractual de mantener copias verificadas corresponde al desarrollador y sigue sin cumplirse; la copia practicada por la Sociedad mitiga el riesgo de pérdida, pero no subsana el incumplimiento. ### 1.5 Protección de datos: retención indefinida por defecto El apartado 3.1 exige que la plataforma se diseñe conforme a los principios de privacidad desde el diseño y por defecto, con inclusión expresa de la minimización de datos, la limitación de la finalidad y las políticas de retención. El mecanismo de purga existe, está correctamente implementado y cuenta con prueba automatizada. El problema reside en el valor predeterminado. La columna que fija el plazo de retención no es obligatoria ni tiene valor por defecto, y la purga actúa únicamente sobre las campañas que lo tengan cumplimentado. El manual de administración lo confirma al advertir que, si el campo se deja vacío, no se produce purga automática. **Una campaña creada sin cumplimentar ese campo conserva de forma indefinida fotografías de personas identificables.** Ello contraviene el principio de privacidad por defecto que la cláusula exige y que el artículo 25.2 del Reglamento General de Protección de Datos impone. **Existen además ficheros que la purga no puede alcanzar en ningún caso.** *(Ampliación de 9 de septiembre de 2026.)* El contraste entre los ficheros efectivamente almacenados y los registros de la base de datos, practicado en esa fecha sobre ambos entornos, revela once ficheros en Validación que carecen de registro asociado. Su origen es un defecto ya identificado en la auditoría de agosto: la función de envío de evidencia no comprueba el resultado de la inserción en la tabla que relaciona el fichero con la evidencia, de modo que un fallo en ese punto deja el fichero subido y sin referencia alguna. La relevancia es que el mecanismo de purga recorre la base de datos para localizar lo que debe suprimir. Un fichero sin registro le resulta invisible, y su conservación es indefinida con independencia del plazo de retención que se hubiera configurado. En Producción no se han detectado casos a fecha de hoy, ya que las cincuenta y cinco fotografías registradas se corresponden una a una con los ficheros almacenados, pero el defecto que los origina es el mismo en ambos entornos y permanece sin corregir en el productivo. A lo anterior se añade que la interfaz de ajustes ofrece al usuario la supresión de sus datos personales, mientras que el código se limita a revocar su pertenencia al portal y a cerrar la sesión. No existe ninguna vía de supresión ni de anonimización, de modo que el registro con su nombre y su dirección de correo permanece. Se trata de una promesa de interfaz carente de respaldo funcional. El consentimiento relativo a los Términos, por su parte, figura bloqueado en la interfaz y no puede retirarse, pese a que el servidor sí lo permitiría. ### 1.6 Reglas de participación: la elegibilidad no se aplica El módulo 2 exige poder configurar criterios de elegibilidad. El panel ofrece elegir entre el conjunto de la empresa o un departamento concreto, y almacena la elección. Ese valor no se comprueba en ningún momento durante la inscripción. Todas las referencias localizadas en el código corresponden a operaciones de escritura, clonado o presentación en pantalla. El modelo de datos, además, no contempla campo alguno de departamento en el usuario, por lo que la regla resulta inaplicable por construcción. Cualquier miembro del portal puede inscribirse en una campaña reservada a otro departamento. Las fechas de vigencia de campaña presentan idéntico comportamiento: se configuran y se muestran, pero no producen ningún efecto restrictivo. Una campaña activa cuya fecha de finalización haya transcurrido continúa admitiendo inscripciones hasta que un administrador la pause manualmente. ### 1.7 Aceptación y defectos El acta de aceptación permanece sin firmar, en estado de plantilla y con la tabla de firmas vacía. La cláusula 2.2 la enumera entre los entregables exigibles. En cuanto al criterio del apartado 2.3, que condiciona la aceptación a la inexistencia de defectos críticos o mayores que impidan el uso normal, conviene precisar el argumento. El cuerpo del acuerdo define el defecto relevante como aquel que impida o limite de forma significativa el uso del entregable conforme a los requisitos funcionales acordados. Una vulnerabilidad de seguridad no impide el uso, de manera que el encuadre directo resulta débil. El encuadre sólido es otro. Ese mismo apartado exige que la plataforma haya sido utilizada en los dos pilotos reales previstos. La verificación de seguridad realizada en agosto acreditó que el administrador de cualquier empresa cliente puede obtener acceso a los datos del resto. Una plataforma en la que un piloto accede a los datos del otro no se encuentra funcionalmente preparada para el uso que el propio Anexo I define como objetivo. ### 1.8 El entregable verificado no se encuentra desplegado *(Apartado añadido el 9 de septiembre de 2026.)* Este hallazgo procede de la extracción íntegra de ambos entornos y de los registros de despliegue del repositorio. No era conocido cuando se redactó la versión anterior de este análisis, y modifica el alcance de lo que puede afirmarse sobre el estado de la plataforma. El informe de verificación de agosto acreditó que las ocho deficiencias de seguridad detectadas en la auditoría estaban corregidas. Aquella conclusión se apoyaba en la lectura del código del repositorio y sigue siendo correcta en sus propios términos. Lo que no podía comprobar entonces, por no disponer de acceso a las bases de datos, es si el código verificado se encontraba efectivamente en ejecución. **No lo está.** El entorno de Producción ejecuta una versión anterior en cuatro migraciones a la que ejecuta Validación. La rama de producción no ha recibido modificación alguna desde el 18 de agosto de 2026, y veintiséis modificaciones integradas en la rama principal no han llegado a ella. La consecuencia es que cuatro de las deficiencias declaradas corregidas permanecen abiertas en el entorno que trata datos reales: | Deficiencia | Validación | Producción | |---|---|---| | Alta de usuario en empresa ajena | Corregida | **Abierta** | | Administrador de marca sin acotar por marca | Corregida | **Abierta** | | Empresa activa derivada de datos que controla el usuario | Corregida | **Abierta** | | Permisos de escritura del rol autenticado | Revocados | **Vigentes** | Los dos últimos se refuerzan entre sí. Mientras el rol autenticado conserva noventa y dos permisos de escritura sobre el esquema público, las políticas de seguridad constituyen la única defensa, y las vigentes en Producción son las anteriores a la corrección. La secuencia descrita en la auditoría de agosto resulta ejecutable hoy contra el entorno productivo. **Sobre la causa, conviene ser preciso, porque exonera a la automatización.** Las doce ejecuciones del proceso de despliegue sobre la rama de producción concluyeron todas con éxito. No consta fallo técnico alguno. Lo que no llegó a producirse es la promoción de la rama principal a la rama de producción, operación que corresponde al desarrollador. Al no moverse la rama, el proceso automático no tenía contenido nuevo que desplegar, y al concluir cada ejecución sin error, ninguna alerta lo delató durante tres semanas. **Relevancia contractual.** El apartado 2.3 condiciona la aceptación a que la plataforma haya sido utilizada en los dos pilotos reales previstos. Los pilotos se ejecutan sobre Producción, que es precisamente el entorno donde las correcciones no están aplicadas. La verificación favorable de agosto no acredita, por tanto, la aptitud del sistema para el uso que el Anexo I define como objetivo. Debe señalarse además que este hallazgo matiza el apartado 2 de este informe. El panel de operaciones, que se computa entre los extremos cumplidos, requiere cuentas con rol global creadas por una de las migraciones ausentes. En Producción esas cuentas no existen, de modo que el módulo cumple en el repositorio y en Validación, pero no puede afirmarse que sea operativo en el entorno productivo. Como observación adicional sobre el proceso, ochenta y cuatro de las ciento cincuenta y ocho ejecuciones de integración continua registradas terminaron en fallo. Una señal de calidad que falla en más de la mitad de las ocasiones deja de emplearse como señal, circunstancia que guarda relación directa con que una desviación de tres semanas entre entornos pasara inadvertida. --- ## 2. Extremos cumplidos Reclamar aquello que ha sido entregado debilita la posición contractual, razón por la cual conviene dejar constancia. El módulo 3, relativo a la gestión de cadenas, cumple sus ocho requisitos y presenta una construcción superior a la exigible: las reglas de negocio se imponen mediante restricciones y disparadores en la base de datos, y no únicamente en la capa de aplicación. El módulo 4, relativo a las pulseras con código QR, cumple, si bien con la salvedad de que el código es único por campaña y no por pulsera, lo que obliga a introducir manualmente el código lateral y resta automatismo al escaneo. El módulo 8, relativo al flujo de usuario, cumple sus seis requisitos. El módulo 6, relativo a la validación manual, cumple, incluida la trazabilidad completa de cada decisión sobre un registro de auditoría inmutable. El módulo 9 cuenta con pruebas automatizadas de extremo a extremo. La documentación mínima exigida por el apartado 5.1 se encuentra prácticamente completa, con documento de arquitectura y diagramas, descripción del modelo de datos, manuales de administración y de usuario, inventarios y procedimientos de copia de seguridad. Los entornos de Validación y Producción están separados en los niveles de base de datos, rama de código y proceso de despliegue. Merece constancia que la documentación del desarrollador es honesta y declara con precisión sus propios pendientes. Buena parte de los incumplimientos recogidos en este informe se acreditan con sus propios documentos. El problema no radica, por tanto, en la opacidad, sino en que diversos entregables contractuales figuran documentados como planificados en lugar de ejecutados. La única declaración que afirma cumplimiento categórico, la relativa a la ausencia de dependencia personal, es precisamente aquella que el repositorio contradice. --- ## 3. Cuadro resumen | Cláusula | Materia | Dictamen | |---|---|---| | 2.2 · 6.1 · 6.3 | Titularidad y control de activos | Incumple | | 6.4 · 5.2 | Dependencia de cuentas personales | Incumple | | Anexo I, Mód. 2 y 5 | Tipos de evidencia admitidos | Incumple | | Anexo I, cláusula 8 | Formalización del cambio de alcance | Incumple | | Anexo I, 3.2 | Copias de seguridad | Incumple en sus tres requisitos | | Anexo I, 3.1 | Privacidad por defecto y supresión de datos | Incumple | | Anexo I, Mód. 2 | Criterios de elegibilidad | Incumple | | 2.2 | Registro de aceptación firmado | No emitido | | 2.3 | Despliegue efectivo de las correcciones en Producción | Incumple | | Anexo I, Mód. 3, 4, 6, 8, 9 | Funcionalidad principal | Cumple en repositorio y Validación | | Anexo I, 5.1 | Documentación | Cumple | Los apartados 1.1, 1.4, 1.5 y 1.8 incorporan hallazgos verificados el 9 de septiembre de 2026 sobre los entornos en explotación. --- ## 4. Orden de prioridad para la reclamación **Cuestión previa, de carácter urgente.** Antes de cualquier consideración contractual procede aplicar a Producción las cuatro migraciones pendientes, conforme se detalla en el apartado 1.8. Están escritas, probadas y en funcionamiento en Validación desde hace tres semanas, de modo que no se trata de un desarrollo sino de un despliegue. Mientras no se ejecute, el entorno que trata datos personales reales mantiene abiertas cuatro vías de acceso indebido entre empresas clientes. Esta actuación no debe supeditarse al resultado de la reclamación ni emplearse como instrumento de negociación. Sentado lo anterior, tres incumplimientos admiten defensa sin margen de discusión, por resultar verificables con datos objetivos y no depender de criterio técnico. **Primero, la titularidad de los activos.** El repositorio reside en una cuenta personal, la Sociedad consta con rol de escritura y sin permisos de administración, y ningún activo ha sido transferido. La comprobación es inmediata y afecta a la continuidad del negocio, no solo al cumplimiento contractual. La verificación de 9 de septiembre añade dos elementos de peso: la Sociedad no puede auditar hacia dónde sale la información de su propio repositorio, y tampoco dispone de las credenciales de sus bases de datos. La medida que resuelve este bloque en su integridad es la transferencia del repositorio a una organización titularidad de la Sociedad, junto con la de los proyectos de base de datos, la plataforma de despliegue y el servicio de correo. Es una operación de minutos para quien ostenta la titularidad, y con ella se recuperan de una vez el gobierno de los accesos, la visibilidad de las integraciones con terceros y la capacidad de custodiar las credenciales. **Segundo, las copias de seguridad.** Siete días de retención frente a los treinta exigidos, las fotografías sin respaldo alguno y ningún ensayo de restauración realizado. Lo documenta el propio desarrollador. **Tercero, los tipos de evidencia.** El vídeo no existe, el texto no constituye un tipo autónomo y la reducción de alcance no se ha formalizado conforme a la cláusula 8. El historial del repositorio, examinado, tampoco la documenta. La retención indefinida de datos personales por defecto y la supresión ofrecida pero no implementada requieren tratamiento separado. No constituyen únicamente un incumplimiento contractual: exponen a la Sociedad, en su condición de responsable del tratamiento, frente a la autoridad de protección de datos, con independencia de lo que finalmente se acuerde con el desarrollador. Por último, el hallazgo del apartado 1.8 tiene naturaleza mixta y conviene no confundir sus dos planos. Como riesgo operativo es el más apremiante de cuantos recoge este informe y se corrige en horas. Como argumento contractual es de segundo orden, puesto que las correcciones existen y están hechas, y lo que falta es un paso de despliegue. Reclamarlo como si fuera un defecto de construcción debilitaría la posición de la Sociedad. Su valor probatorio es otro: acredita que la aceptación no puede tenerse por producida mientras el entorno donde se ejecutan los pilotos no contenga aquello que se declaró entregado.