# Auditoría técnica de la plataforma Kynda ## Qué funciona, qué falta y cómo lo resolvemos **Fecha:** 23/07/2026 · **Preparado por:** LUME OFFICE · **Material analizado:** presentación corporativa v28, base de datos (31 tablas) y panel de administración del piloto Easyfairs · **Detalle técnico completo:** Propuesta técnica v2 (16 págs.) --- Este documento resume en lenguaje claro lo que encontramos al revisar vuestra plataforma. El análisis técnico completo, con arquitectura y estimaciones, está en la Propuesta técnica v2; esto es la versión para leer en diez minutos y discutir en una reunión. > La plataforma tiene unos cimientos excelentes, pero las tres promesas estrella de vuestra presentación todavía no están conectadas. No hay que tirar nada: proponemos construir sobre lo que ya existe los tres motores que faltan. --- ## 1. Empecemos por la buena noticia La base de datos, que es el armazón donde vive toda la información (empresas, campañas, empleados, evidencias, pulseras), está muy bien diseñada. Quien la construyó pensó en el producto completo: ya tiene hueco previsto para la validación con inteligencia artificial, para las fórmulas que calculan el impacto y hasta para la cadena de la pulsera. Esto importa porque descarta el escenario caro. Rehacer la plataforma desde cero costaría meses y dinero para acabar llegando al mismo sitio. La imagen que usamos: la casa tiene buena cimentación y los cables ya pasados por las paredes; lo que falta es conectar los interruptores. Nuestro trabajo es conectarlos. --- ## 2. Las tres promesas que hoy no se cumplen Vuestra presentación vende tres cosas que el producto actual todavía no hace. Conviene verlas juntas, porque son exactamente el motivo por el que el producto "no se adecua a los objetivos": | La presentación vende | Lo que ocurre hoy | |---|---| | Verificación por inteligencia artificial ("no proof, no impact") | Cada evidencia la revisáis David y tú, a mano | | Impacto auditable y trazable | Las cifras (16.845 kg, 1.203 personas) se escriben a mano en el panel | | Informes con sello de auditoría | Un panel con gráficas y un botón de "Exportar a Excel" | ### 2.1 La verificación "con IA" la hacen dos personas Hoy, cada foto que sube un empleado espera a que alguien de vuestro equipo la abra, la mire y la apruebe. En el piloto, con 30 evidencias, funciona. Con un cliente de 10.000 empleados es sencillamente imposible, y mientras tanto los fundadores hacen de revisores en lugar de dirigir la empresa. Hay además un problema comercial: estáis vendiendo inteligencia artificial y entregando trabajo manual. Si un cliente grande lo descubre, la conversación se complica. Lo que falta: activar el circuito de revisión automática que vuestra base de datos ya tiene previsto y que nunca se llegó a construir. En la sección 4 explicamos cómo. ### 2.2 Las cifras de impacto se escriben a mano Los 16.845 kilos de alimentos del piloto no los calculó la plataforma: los escribió una persona en una casilla. Lo mismo con las 1.203 personas beneficiadas y el valor económico del voluntariado. El problema aparece el día que un auditor, o el director de sostenibilidad de vuestro cliente, pregunte de dónde sale la cifra. Hoy la respuesta honesta es "la escribimos nosotros", y esa respuesta desmonta el argumento central del producto, que es precisamente poder demostrar el impacto. Lo que falta: que cada cifra se calcule sola a partir de las evidencias aprobadas, y que cualquiera pueda hacer clic en el número y llegar hasta las fotos y los datos que lo sustentan. Y si un dato hay que corregirlo a mano (por ejemplo, porque el banco de alimentos os pasa el pesaje oficial), que quede registrado quién lo cambió, cuándo y por qué. Se puede corregir; lo que no se puede es corregir en silencio. ### 2.3 El sello de auditoría todavía no existe La presentación habla de registros verificables y huellas criptográficas. Hoy el reporting es un panel bonito y un Excel exportable, y un Excel se edita en dos clics. Para un producto que se vende como "a prueba de auditores", eso es una carencia de fondo. Lo que falta: un libro de registro digital donde cada apunte queda encadenado al anterior y sellado con fecha por un tercero independiente. Si alguien tocara un apunte antiguo, se notaría al instante. La buena noticia es que esto se consigue con técnicas estándar bien conocidas, sin necesidad de blockchain, que encarecería y complicaría todo para lograr el mismo efecto. El formato electrónico oficial que exigen los reguladores europeos (XBRL) lo dejamos para una fase posterior: primero el contenido fiable, después el formato oficial. --- ## 3. El riesgo que hay que comprobar antes que nada > **Riesgo crítico pendiente:** todavía no hemos podido comprobar si existe la barrera que separa los datos de cada empresa cliente (en técnico, RLS). Vuestra plataforma aloja a todos los clientes sobre la misma base de datos, algo normal y eficiente, pero que exige que cada dato lleve su candado. Si ese candado faltase, un cliente podría llegar a ver información de otro. Es lo primero que comprobamos en cuanto tengamos acceso al código. Queremos ser claros: no sabemos si falta. Puede estar perfectamente montada. Pero es la clase de cosa que no se puede dar por supuesta, porque un fallo aquí no es un error estético sino un incidente de protección de datos con nombre y apellidos de por medio. Aprovechamos para señalar dos hábitos que conviene corregir ya, sin esperar a ninguna fase: - Las contraseñas de la plataforma y de la base de datos han circulado por email en texto normal. Hay que cambiarlas y pasar a compartirlas por un gestor de contraseñas. - En la plataforma en producción conviven empleados reales de Easyfairs con usuarios de prueba creados con correos personales. Además de dar mala imagen en una demo, mezcla datos reales y ficticios en un entorno sujeto a RGPD. Lo limpiaremos y montaremos un entorno de demostración separado. --- ## 4. Cómo se resuelve: los tres motores ### El motor de verificación Funciona por capas, de lo barato a lo caro. Primero, las comprobaciones automáticas que no cuestan nada: ¿la foto se hizo en el lugar y a la hora de la jornada? ¿los datos ocultos que guarda cada imagen (hora, ubicación, dispositivo) cuadran entre sí? ¿es una foto repetida o una captura de pantalla? Solo lo que pasa ese primer filtro llega a la inteligencia artificial de visión, que mira la foto como lo haría una persona: ¿esto es de verdad una jornada en un banco de alimentos? Lo claramente correcto se aprueba solo, en segundos. Lo dudoso, que estimamos entre un 10 y un 25%, va a una bandeja de revisión humana, ya ordenado por prioridad y con el motivo de la duda señalado, para que revisar cueste segundos y no minutos. Y una regla de diseño que os protege legalmente: la máquina nunca rechaza a nadie por su cuenta. Aprobar sí puede aprobar sola cuando está muy segura; rechazar lo decide siempre una persona. Así ningún empleado queda acusado por error por un algoritmo, y ningún dato dudoso entra en un informe sin que unos ojos humanos lo hayan visto. ### El motor de cálculo Es la respuesta al punto 2.2: las cifras dejan de escribirse y pasan a calcularse a partir de las evidencias aprobadas, usando las fórmulas que vuestra base de datos ya trae definidas. Cada número del panel se puede desplegar hasta la evidencia individual. Cuando enseñéis el producto a un director de sostenibilidad, la demostración es esa: haced clic en el titular y llegad hasta la foto. ### El libro sellado La capa de auditoría del punto 2.3: cada aprobación, cada cálculo y cada corrección deja un apunte encadenado y sellado con fecha. Incluye una vista de solo lectura pensada para el auditor del cliente y la exportación de informes. Está planificada para la segunda fase, pero el motor de verificación ya deja las huellas preparadas desde el primer día. --- ## 5. ¿Y no saldrá carísima la IA? Hicimos números con las tarifas oficiales de julio de 2026. Verificar una evidencia (una foto con sus datos) cuesta entre medio céntimo y dos céntimos de dólar, según lo exigente que sea el modelo elegido. Vuestro plan más grande contempla 10.000 evidencias al año: son unos 200 dólares anuales de inteligencia artificial, en planes que se venden entre 35.000 y 130.000 euros. El coste nunca fue el obstáculo. Lo que no escala es lo de ahora: que cada foto pase por las manos de los fundadores. --- ## 6. El plan, por fases Una "jornada" es un día de trabajo de un desarrollador. Las duraciones de las fases 1 a 3 son orientativas y se convierten en presupuesto cerrado al terminar la fase 0. | Fase | Qué entrega | Duración | |---|---|---| | **0 — Auditoría** | Revisión de seguridad (el candado del punto 3) y del código, y una prueba real: pasar vuestras 30 evidencias del piloto por el motor de verificación para medir aciertos y coste por evidencia. Con los resultados, presupuesto firme. | 1–2 semanas | | **1 — Núcleo creíble** | Verificación automática funcionando, cifras calculadas y trazables, recorrido de invitaciones reparado y protección de datos al día. | 58–84 jornadas (6–10 semanas con 2 desarrolladores) | | **2 — Confianza** | El libro sellado, la vista para auditores, el contenido listo para redes sociales y la puesta en marcha de la pulsera. | 30–45 jornadas | | **3 — Grandes clientes** | Acceso con usuario corporativo, conexión con sistemas de RRHH, formato regulatorio oficial (XBRL) y contador de consumo para facturar por uso. | 42–65 jornadas | Sobre el "recorrido de invitaciones" de la fase 1: la puerta de entrada prevista, invitar por email a los empleados de cada cliente, está construida a medias y sin estrenar. En el piloto la gente acabó registrándose por su cuenta, y por eso el panel muestra cosas como "0% de 0 invitados". Sin ese recorrido no podéis medir cuánta plantilla se activa en cada cliente, que es justo uno de los datos que vendéis. En la misma fase dividiremos también el formulario de crear campañas, hoy diez bloques de una sentada, en pasos cortos con los datos de la plantilla ya precargados, y dejaremos el inglés preparado, porque añadir idiomas ahora es barato y hacerlo tarde es caro. --- ## 7. Qué necesitamos para empezar - Acceso de solo lectura al código de la plataforma. - Un acceso de desarrollador a la base de datos (con eso basta; no necesitamos la cuenta propietaria) y el cambio de las contraseñas que circularon por email. - Una o dos sesiones con la persona que construyó la versión actual, para el traspaso. - Vuestro criterio experto en ESG para validar las metodologías de cálculo (por ejemplo, cómo se convierten kilos de alimentos en personas beneficiadas). El siguiente paso es la fase 0: una o dos semanas que convierten este análisis en un presupuesto firme y en la primera demostración del motor de verificación funcionando con vuestros propios datos.