CDO Advisory Report — FieldPulse Analytics

■ Bottom Line — Tres decisiones

☑ ¿Puedo entrenar mi modelo de IA?

Sí, pero solo con 5 de tus 7 fuentes. Los datos de contactos PII y los perfiles scrapeados de LinkedIn son NO-GO. La telemetría de comportamiento y los opt-ins explícitos son tu base de entrenamiento.

☑ ¿Warehouse o Lakehouse?

Muévete a Lakehouse. Con 12 consumidores internos, 3,2 TB y 2 modelos ML en producción ya superaste los umbrales de BigQuery solo. Mantén BigQuery como capa de warehouse pero añade object storage + Iceberg.

☑ ¿Son tus datos un activo para la ronda?

Sí. Score estratégico 7,8/10, moat STRONG. En escenario M&A el corpus añade 1,33–1,61x sobre ARR. Empieza por el benchmark report (baja barrera legal, alto credibility lift).

Auditoría de Derechos de Entrenamiento IA

7 fuentes auditadas · matriz origin × class × use-case

7 fuentes

MITIGATE

NO-GO

Resumen de la auditoría

2 fuentes bloqueadas para entrenamiento (PII sin opt-in + datos scrapeados). La base viable son la telemetría de comportamiento (TOS), señales CRM (TOS), agregados anónimos y opt-ins explícitos. El corpus sintético de GPT-4 necesita revisión de licencia de OpenAI para confirmar derechos de entrenamiento.

🟢

Datos de contactos (nombre, email, cargo, empresa cliente)

1st-party-tos-only PII fine-tune-model

Riesgo: PII para fine-tuning sin opt-in explícito infringe GDPR Art. 6. El consentimiento TOS es insuficiente para una finalidad materialmente diferente al servicio original.

Remediación: (a) construir pipeline de opt-in explícito antes de entrenar, o (b) anonimizar a k-anonimidad ≥ 5 y reclasificar como anonymous-aggregate. Cita: GDPR Art. 6, EDPB Opinion 28/2024.

● NO-GO

🟢

Perfiles de LinkedIn scrapeados para enrichment de prospectos

scraped PII fine-tune-model

Riesgo: Sin base legal bajo GDPR Art. 6; alto riesgo de copyright; exposición hiQ v. LinkedIn por violación de ToS; EU AI Act Art. 10 exige provenance demostrable.

Remediación: Eliminar del training set. Opciones: (a) adquirir datos licenciados de data broker, (b) reemplazar con sintéticos, o (c) pipeline de opt-in propio.

● NO-GO

🟡

Datos sintéticos generados con GPT-4 para augmentación del dataset

synthetic 3rd-party-content fine-tune-model

Riesgo: Incluso con licencia, entrenar un modelo puede exceder el scope de la licencia ("view" vs "derivative work creation"). Riesgo legal post-NYT v. OpenAI 2024.

Remediación: Revisar Terms of API de OpenAI para confirmar derechos de entrenamiento. Añadir carve-out específico en acuerdo de licencia. Provenance log por fuente para EU AI Act Art. 53.

● MITIGATE

🟠

Telemetría de actividad comercial (emails, llamadas, reuniones)

1st-party-tos-only behavioral fine-tune-model

OK para entrenamiento. Residual: modelo leakage si patrones de comportamiento son individualmente identificables. Mantener: gestión de borrado en petición del usuario + tests periódicos de memorización.

● GO

🟠

Señales CRM enriquecidas (deals, stages, close probability histórica)

1st-party-tos-only behavioral fine-tune-model

OK para entrenamiento. Tu IP principal. Mismo tratamiento que telemetría: deletion flow activo, DPIA si escala supera 50K usuarios.

● GO

🟠

Agregados anónimos de conversion rates por industria

1st-party-tos-only anonymous-aggregate train-foundation-model

OK para foundation model. La clase más segura. Mantener k-anonimidad ≥ 5 en todos los agregados publicados; differential privacy si se comparten externamente.

● GO

🟠

Opt-in explícito de 45 clientes beta para señales de deal scoring

1st-party-explicit-opt-in behavioral fine-tune-model

OK — posición más fuerte. Opt-in explícito para entrenamiento de deal scoring. Base de trabajo para ampliar opt-in al resto de la base antes de entrenar en PII. Tests de memorización periódicos.

● GO

Estrategia de Arquitectura de Datos

Series A · 12 consumidores · 3,2 TB · 2 modelos ML

💾 Recomendación: LAKEHOUSE

Con 12 consumidores internos, 2 modelos ML en producción y 3,2 TB ya superaste los umbrales para BigQuery puro. Un warehouse es demasiado rígido para ML; un data lake puro es demasiado desestructurado para BI. El lakehouse (BigQuery + Google Cloud Storage con Iceberg/Delta) cubre ambos con un único sustrato, sin cambiar de proveedor.

⚠ Criterios de abandono

▶ Degradar a warehouse-only si los modelos ML se retiran y el volumen baja de 2 TB

▶ Actualizar a data mesh solo si hay 25+ consumidores Y cultura federada instaurada

▶ Parar inversión si el vendor lock-in resulta inaceptable (los formatos de tabla Iceberg/Delta lo mitigan)

Build vs Buy — por capa

Capa	Decisión	Herramienta sugerida	Justificación
Storage / Warehouse	BUY	BigQuery + GCS (ya lo tienes)	El almacenamiento es commodity. Construirlo requiere 50 años-ingeniero sin retorno de negocio.
ELT / Ingest	BUY	Fivetran / Airbyte / Stitch	El mantenimiento de conectores es trabajo interminable (200+ API fuentes). Construir solo si la fuente no está soportada y es crítica.
Modeling / Transformaciones	BUILD	dbt + lógica de dominio propia	Esta es tu IP. Tu lógica de dominio (signals, conversion rates, deal patterns) no puede venir de un vendor.
BI / Dashboards	BUY	Metabase / Looker / Hex	Con 12 consumidores, construir BI es una distracción. El BI SaaS es maduro; elige el que mejor encaja con el skillset del equipo.
Feature Store	DEFER	(usar dbt + tablas de features simples)	2 modelos en prod. Los feature stores rinden a partir de 3+ modelos compartiendo features. Inversión prematura = carga de mantenimiento.
ML Platform	DEFER	(notebooks + scheduled training jobs)	2 modelos. Las ML platforms (Vertex AI, SageMaker) tienen sentido a partir de 5+ modelos con reentrenamiento activo.

Roadmap 12 meses

Q1 — Jul-Sep 2026

Pipeline reliability

SLA en los 3 pipelines más críticos (freshness, completeness); rotación de on-call; data quality tests en dbt sobre marts de deal scoring y actividad comercial.

Q2 — Oct-Dic 2026

Self-serve BI

Despliegue de herramienta BI a equipos no-datos; semantic layer (dbt metrics o LookML); programa de formación para equipos de Ventas y Customer Success.

Q3 — Ene-Mar 2027

ML enablement

Primera tabla de feature-store para el modelo de deal scoring; experiment tracking (MLflow / W&B); model monitoring para detectar degradación del modelo en producción.

Q4 — Abr-Jun 2027

Evaluar y decidir

Re-ejecutar el picker de arquitectura con el perfil actualizado; decidir si introducir feature store (si modelos = 3+); evaluar prerrequisitos de data mesh (consumidores 25+, cultura).

Valoración del Corpus de Datos de Cliente

285 clientes · 2,1 años de historia · exclusividad alta

7,8

Score estratégico

sobre 10

🛡 Moat STRONG

Exclusividad + amplitud de cohorte significa que replicarlo requiere 2+ años de adquisición de clientes. Un competidor bien financiado necesita 24-36 meses.

Exclusividad

9/10

Amplitud cohorte

8/10

Freshness

7/10

Profundidad historial

6/10

Multiplicador M&A (comprador estratégico)

1,33× – 1,61× ARR

El corpus de datos añade 33-61% de uplift sobre el ARR en un escenario de adquisición por un CRM enterprise. Penalización del ~5% por el 10,9% de carve-outs en MSAs (31 clientes con restricciones).

Impacto en valoración (ARR $8,5M)

$11,3M – $13,7M

Equivalente ARR en escenario de comprador estratégico: $8,5M × (1,33 – 1,61) = $11,3M – $13,7M. Para la ronda Series B: el corpus refuerza el narrative de defensibilidad del producto ante inversores.

Vías de productización del corpus

★ Recomendado

Benchmark report sector (agregados anónimos)

Riesgo bajo Viabilidad alta

💰 €50K-€500K/año + alto credibility lift para ventas

Bloqueadores

Auditoría de anonimización (k-anonimidad ≥ 5) requerida antes de publicar

Primer paso

Auditar las 3 métricas top (conversion rate por industria, pipeline velocity, win rate por deal size); publicar quarterly benchmark report; enviar primero a clientes como opt-in antes de publicación pública.

Endpoint de embeddings anónimos (IA features para clientes)

Riesgo medio Viabilidad alta

💰 €500K-€3M/año como feature de plataforma o add-on

Bloqueadores

Auditoría de anonimización: los embeddings pueden filtrar datos de entrenamiento

31 clientes con carve-outs en MSA bloquean el uso productizado de sus datos

Primer paso

Piloto con 3 clientes design-partner; tests de memorización; addendum DPA cubriendo el flujo de training data.

Licenciamiento directo de datos (a AI labs o data brokers)

Riesgo alto Viabilidad baja

💰 €2M-€20M/año a escala, pero alto coste de confianza del cliente

Bloqueadores

10,9% de clientes (31) con carve-outs — licenciamiento directo inviable sin re-papering

Requiere análisis GDPR Art. 26 (joint-controller) si hay clientes en la UE

Primer paso

Primero decidir si el impacto en confianza del cliente es aceptable. Si sí: re-paper los 31 clientes con carve-outs O construir dataset excluido de carve-outs.

Evolución del Equipo de Datos

Series A · 2 personas actuales · próxima contratación

Equipo actual

👨

Analytics Engineer Junior

Pipelines + dbt + BI básico

👨‍💻

CTO como CDO improvisado

Decisiones estratégicas + arquitectura

Próxima contratación recomendada

Data Engineer Senior

La decisión que FieldPulse no puede tomar hoy es la fiabilidad de pipelines. Un Data Engineer Senior desbloquea: SLAs de datos, observabilidad, y la base para el lakehouse. No contratar un Data Scientist todavía — primero necesitas la infraestructura para que los modelos funcionen en producción de forma fiable.

Trigger de centralización vs. embed

Actualmente con 12 consumidores internos y 2 personas, el equipo central puede absorber las peticiones. El trigger para pasar a hub-and-spoke (plataforma central + analistas embebidos en funciones) es cuando 3+ equipos funcionales (Ventas, Marketing, Product, Ops, CS) necesiten datos a medida semanalmente. A tu ritmo de crecimiento, eso ocurre probablemente a Series B con 20+ consumidores. Plan: contratar el Data Engineer Senior ahora, evaluar el primer analista embebido en GTM a finales de Q2 2027.