Decisión bajo revisión
Productización de activo de datos — NutriFlow pretende convertir datos de comportamiento de 47.000 usuarios clínicos en un endpoint de API comercializable (NutriInsights API) para venta B2B a seguros, apps de fitness y hospitales. ARR proyectado: 150.000 € en año 1.
1
¿Qué decisión desbloquea estos datos?
ALINEADO
Decisión identificada: "¿Debemos abrir un nuevo vertical de ingresos vendiendo predicciones clínicas a compradores B2B?" — es una decisión real de portfolio de negocio, no una aspiración vaga. La proyección de 150K€ ARR en año 1 es testable, y el segmento de compradores (seguros, hospitales) está definido. Esto es suficiente para pasar el filtro 1.
Sin acción requerida
La decisión de negocio está correctamente formulada y ligada a un revenue stream verificable.
2
Provenance de consentimiento — Auditoría de fuentes
BLOQUEADOR
El plan combina 4 fuentes con perfiles de consentimiento radicalmente distintos. 2 de las 4 fuentes son NO-GO para el uso comercial propuesto. La fuente Fitbit viola TOS de tercero; los datos B2B2C carecen de consentimiento del usuario final para re-licensing.
NO-GO — Datos B2B2C sin consentimiento del usuario final
Datos de categoría 9 RGPD (salud) requieren consentimiento explícito del interesado (Art. 9.2.a). El TOS de la clínica no puede delegarse al usuario final para un nuevo fin material (re-licensing comercial).
NO-GO — Fitbit/Garmin TOS violation
Los TOS de Fitbit (sec. 6.2) prohíben explícitamente usar datos obtenidos via OAuth para entrenar modelos vendidos a terceros. Riesgo de terminación de integración + demanda contractual.
MITIGAR — k-anonimato insuficiente para datos de salud
k=5 en datos de salud está por debajo del umbral recomendado (k≥15 para datasets de salud según ENISA 2022). Elevar a k≥15 + añadir differential privacy antes de publicar benchmarks.
3
Consumidores internos → Arquitectura recomendada
AJUSTAR
Con 8 consumidores internos, NutriFlow está en la banda lakehouse (5–25). Sin embargo, el plan de lanzar una API externa introduce consumidores externos no contabilizados. La arquitectura actual (PostgreSQL + BigQuery ad-hoc, sin data catalog) es insuficiente para productización segura.
WAREHOUSE
< 5 consumidores
RECOMENDADO
LAKEHOUSE
5–25 consumidores
MESH
25+ con cultura federada
Build vs Buy
BigQuery + dbt (ya existente) como base; añadir Apache Iceberg para lineage. Evitar Databricks hasta serie B (coste no justificado a 12 personas).
Prerrequisito bloqueante
Data catalog + lineage ANTES de abrir la API. Sin trazabilidad de origen-dato no se puede demostrar consentimiento en producción.
Kill criteria
Revisar si consumidores internos superan 20 o si se incorporan 3+ dominios funcionales (clínico, producto, datos, negocio). Ahí evaluar data mesh.
Coste estimado
~8.000–12.000€ migración + 1.200€/mes ops. ROI positivo si la API genera >60K€ ARR.
4
Impacto en diligencia M&A
RIESGO MEDIO
Si un adquirente (hospital, aseguradora, SaaS de salud) revisa NutriFlow hoy, los gaps de consentimiento y ausencia de lineage depreciarían el activo de datos un 30–50% del valor estimado o activarían un escrow de representaciones y garantías elevado.
2/10
Madurez datos
Sin catalog, sin lineage
DÉBIL
Moat
Corpus 47K usuarios replicable
1.5–2.5x
Multiplicador M&A
ARR (vs 3–4x si corpus clean)
0%
Logs provenance
No existen actualmente
5
¿Puede el modelo entrenarse sin la fuente conflictiva?
BLAST RADIUS ALTO
El modelo predictivo depende estructuralmente de los datos de usuarios B2B2C (90% del corpus). Eliminando esa fuente, el modelo no es viable — lo que confirma que NutriFlow está comprometida con esa fuente. Por tanto, la remediación de consentimiento NO es opcional; es el camino crítico del lanzamiento.
Sin datos B2B2C
Corpus residual: n=4.200 (encuestas). Estadísticamente insuficiente para predicciones clínicas. No viable.
Sin datos Fitbit/Garmin
Pérdida de señal biométrica continua. Modelo degradado ~40% en precisión según datos internos. Remediable con fuente alternativa (Apple HealthKit con TOS más permisivo).
6
¿Cuál es la contratación correcta?
HIRE INCORRECTO
El plan propone contratar un Data Scientist Senior para construir los modelos. Este es el hire equivocado en este momento. Sin data engineer ni data platform, el DS Senior pasará el 70% del tiempo haciendo plomería de datos en lugar de modelado, y abandonará en 12 meses. El prerrequisito ausente es un Analytics/Data Engineer.
Orden
Rol
Razón
Estado
1
Analytics Engineer / Data Engineer
Construir el lakehouse, data catalog y lineage. Prerrequisito para cualquier modelo.
2
Data Privacy Officer (parcial/externo)
Articular el reconsent flow y el DPIA (obligatorio para Art. 9 RGPD). Puede ser asesor externo 15h/mes.
3
Data Scientist Senior
Solo contratar DESPUÉS de que el Data Engineer entregue el lakehouse limpio (3–4 meses).
Budget recomendado — reallocation
De los 60.000€ presupuestados para el DS Senior: 45.000€ Analytics Engineer + 15.000€ DPO externo (12 meses). Revisar DS Senior en Q1 2027.
🟡
SHARPEN
Plan viable, no lanzable. Ventana de remediación: 60–90 días.
Bloqueadores (3)
• Consentimiento usuarios B2B2C (Art. 9 RGPD)
• TOS Fitbit — violación contractual
• Hire incorrecto (DS antes de DE)
• TOS Fitbit — violación contractual
• Hire incorrecto (DS antes de DE)
Remediaciones (3)
• Reconsent flow activo (DPIA incluido)
• Drop Fitbit → negociar Apple HealthKit
• Contratar AE + DPO antes que DS
• Drop Fitbit → negociar Apple HealthKit
• Contratar AE + DPO antes que DS
Fortalezas
• Decisión de negocio bien formulada
• Corpus de 47K usuarios único en España
• ARR proyectado conservador y testable
• Corpus de 47K usuarios único en España
• ARR proyectado conservador y testable
Próximas 3 acciones concretas
01
DPIA + Reconsent Campaign
Contratar DPO externo para redactar DPIA (Art. 35 RGPD). Diseñar reconsent flow in-app para los 47.000 usuarios: finalidad explícita "análisis e insights externos". Meta: 30% opt-in = corpus de 14.000 usuarios limpio y suficiente.
Owner: Legal / DPO · 30 días
02
Migrar wearables a Apple HealthKit
Drop inmediato de datos Fitbit/Garmin del pipeline de entrenamiento. Negociar integración Apple HealthKit (Research API) que permite uso de datos en estudios de salud con opt-in. Evaluar TOS de Oura Ring como alternativa.
Owner: CTO · 21 días
03
Contratar Analytics Engineer
Publicar JD para Analytics Engineer con foco en dbt + BigQuery + Iceberg. Reasignar budget DS Senior (60K€) a AE (45K€) + DPO externo (15K€). Iniciar búsqueda esta semana; DS Senior se evalúa en Q1 2027 con plataforma ya construida.
Owner: CEO / Talent · 14 días
Derivar a — revisiones adicionales recomendadas
/cs:gc-review contractual Fitbit + licensing path
/cs:ciso-review arquitectura + datos clínicos en tránsito
/cs:cfo-review TCO lakehouse + ROI proyectado
cs-chro-advisor comp plan AE vs DS
/cs:freeze 90 congelar contrato Fitbit hasta revisión legal