Definity raise $12M: agentes IA en pipelines Spark

Por qué los pipelines de datos están rompiendo sistemas de IA en producción

33% de oportunidades de optimización identificadas en la primera semana y 70% menos esfuerzo en troubleshooting. Estos no son números teóricos: son los resultados que Nexxen, una plataforma de ad tech, obtuvo al implementar Definity en sus pipelines de Spark.

Para founders que dependen de IA agéntica en producción, un pipeline que falla silenciosamente no solo rompe un dashboard: rompe el sistema de IA completo que depende de esos datos. Y las herramientas tradicionales de monitoreo llegan demasiado tarde.

La startup de Chicago Definity acaba de anunciar $12 millones en Serie A liderados por GreatPoint Ventures, con participación de Dynatrace y los inversores existentes StageOne Ventures y Hyde Park Venture Partners. La propuesta es radical: en lugar de monitorear pipelines desde fuera, embeden agentes de IA dentro de la ejecución misma de Spark o DBT.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Quiénes están detrás de Definity y por qué esto importa?

El equipo fundador combina experiencia operativa real con contribuciones técnicas de fondo. Roy Daniel (CEO) es MBA de la Universidad de Chicago Booth School of Business y fue VP de Product Management en FIS, una de las mayores empresas de servicios financieros del mundo. Ohad Raviv (CTO) fue tech lead de big data en PayPal y es contribuidor de Apache Spark. Tom Bar-Yacov (VP R&D) también viene de PayPal como gerente de data engineering.

Los tres se conocieron a través de un amigo mutuo, compartiendo los mismos dolores de cabeza con pipelines de datos en entornos enterprise. Esta no es una solución construida desde la teoría: nació de problemas reales que enfrentaron en FIS, PayPal y sistemas financieros a gran escala.

Antes de esta ronda, Definity ya había levantado $4.5 millones en agosto de 2024 cuando salió de stealth mode, según reportó TechCrunch. La nueva inyección de capital valida que el mercado de observabilidad de pipelines está maduro para un enfoque más agresivo.

¿Por qué el monitoreo tradicional de pipelines falla a escala?

Herramientas como Datadog (que adquirió Metaplane el año pasado), las system tables de Databricks, y plataformas como Unravel Data y Acceldata abordan el problema desde fuera de la capa de ejecución. Leen métricas después de que el job se completa.

«Siempre es después del hecho», explica Daniel en la entrevista exclusiva con VentureBeat. «Para cuando sabes que algo pasó, ya pasó».

El problema estructural es arquitectónico: cuando una herramienta de monitoreo externa surfacea un problema, el pipeline ya corrió. El fallo, el compute desperdiciado y los datos corruptos ya están aguas abajo, afectando dashboards, modelos de ML y sistemas de IA que dependen de esa data.

Dynatrace, que participó en la Serie A de Definity, tiene capacidades de monitoreo pero desde la misma perspectiva externa. La diferencia de Definity no es incremental: es arquitectónica.

¿Cómo funcionan los agentes in-execution de Definity?

La diferencia central es dónde se sienta el agente. En lugar de observar desde fuera, Definity instala un agente JVM directamente dentro de la capa de ejecución del pipeline mediante una sola línea de código. Corre por debajo de la capa de plataforma, extrayendo datos de ejecución directamente de Spark.

Instrumentación inline. El agente captura comportamiento de ejecución de queries, presión de memoria, data skew, patrones de shuffle y utilización de infraestructura mientras el pipeline corre. También infiere lineage entre pipelines y tablas dinámicamente: no requiere un data catalog predefinido.

Intervención, no solo observación. Aquí está el cambio de paradigma: el agente puede modificar asignación de recursos mid-run, detener un job antes de que datos corruptos se propaguen, o preemptar un pipeline basado en condiciones de datos aguas arriba. Daniel describió un deployment en producción donde el agente detectó que un job upstream había sido preemptado y la tabla de input que debía escribir estaba stale: detuvo el pipeline downstream antes de que iniciara, evitando que datos corruptos llegaran a cualquier sistema dependiente.

Qué es y qué no es real time. La detección y prevención son real time. El root cause analysis y las recomendaciones de optimización corren on-demand cuando un ingeniero consulta el assistant, con todo el contexto de ejecución ya ensamblado.

Overhead y residencia de datos. El agente agrega aproximadamente un segundo de compute en un run de una hora. Solo metadata transmite externamente; hay deployment on-premises completo disponible para entornos donde ninguna metadata puede salir del perímetro.

¿Qué resultados obtienen empresas en producción?

Nexxen, una plataforma de ad tech que corre pipelines de Spark a gran escala para workloads críticos de publicidad on-premises, es uno de los early users. Dennis Meyer, Director de Data Engineering en Nexxen, explicó que el problema central no eran los fallos de pipeline, sino el costo acumulativo de ineficiencia en un entorno sin capacidad elástica en la nube para absorber desperdicio.

«El desafío principal no era que los pipelines se rompieran, sino gestionar un entorno cada vez más complejo y a gran escala», dijo Meyer. «Como operamos on-prem, no tenemos la flexibilidad de elasticidad instantánea, así que las ineficiencias tienen un impacto directo en costos».

Las herramientas de monitoreo existentes le daban a Nexxen visibilidad parcial pero no suficiente para actuar sistemáticamente. «Teníamos herramientas de monitoreo existentes, pero necesitábamos visibilidad full-stack para entender el comportamiento de workloads holísticamente y priorizar optimizaciones sistemáticamente», añadió.

Nexxen desplegó Definity sin cambios en el código del pipeline. Según Meyer, el equipo identificó 33% de sus oportunidades de optimización en la primera semana, y el esfuerzo de ingeniería en troubleshooting y optimización cayó 70%. La plataforma liberó capacidad de infraestructura, permitiendo al equipo soportar crecimiento de workloads sin inversión adicional en hardware.

«El cambio clave fue pasar de troubleshooting reactivo a optimización proactiva y continua», concluyó Meyer. «A escala, la brecha más grande a menudo no es el tooling: es visibilidad accionable».

¿Qué significa esto para tu startup?

Si tu startup depende de pipelines de datos para alimentar sistemas de IA, dashboards críticos o procesos de negocio automatizados, esto tiene implicaciones directas. No necesitas ser enterprise con miles de jobs de Spark para beneficiarte del principio central.

Pipeline ops se está convirtiendo en un problema de infraestructura de IA. Los pipelines de datos que antes soportaban analytics ahora cargan workloads de IA con dependencias directas de negocio. Fallos que antes eran una inconveniencia ahora están bloqueando delivery de IA en producción. Si tu modelo de ML o tu sistema agéntico depende de datos que llegan tarde o corruptos, tu producto falla aunque el código de IA sea perfecto.

El tiempo de troubleshooting es un costo recuperable. Nexxen redujo 70% del esfuerzo de ingeniería en troubleshooting y optimización. Para equipos lean, ese tiempo recuperado volviendo al roadmap es el caso de negocio más directo. En una startup donde cada ingeniero cuenta, liberar 70% del tiempo que tu data team pasa apagando fuegos es un multiplicador de fuerza significativo.

Acciones concretas que puedes implementar:

Audita tu stack de observabilidad actual. ¿Tus herramientas de monitoreo ven problemas antes o después de que el pipeline corre? Si es después, estás en modo reactivo. Pregunta a tu data team: ¿cuántos incidentes de datos detectasteis después de que el negocio se vio afectado? Ese número es tu oportunidad de mejora.
Calcula el costo real de ineficiencia. En entornos cloud, compute desperdiciado es dinero quemado. En on-prem, es capacidad que no puedes usar para crecimiento. Haz la cuenta: si tu data team pasa 10 horas/semana en troubleshooting, eso son 520 horas/año. A $100/hora (costo fully loaded de un data engineer), son $52,000 anuales. ¿Qué podrías construir con ese tiempo y dinero?
Evalúa si tu arquitectura permite intervención. La mayoría de herramientas de monitoreo son read-only. Si tu sistema no puede detener un pipeline antes de que datos corruptos se propaguen, estás dependiendo de la velocidad de reacción humana. Considera si puedes implementar circuit breakers o validaciones pre-execution en tu stack actual, incluso si no usas Definity específicamente.
Prioriza visibilidad accionable sobre visibilidad completa. Meyer de Nexxen lo dijo claramente: «la brecha más grande no es el tooling, es visibilidad accionable». No necesitas más dashboards. Necesitas alertas que te permitan actuar antes del impacto. ¿Tu sistema actual te da eso?

¿Cómo se compara Definity con alternativas en el mercado?

El espacio de data observability está consolidándose rápidamente. Datadog adquirió Metaplane en 2025, integrando data quality monitoring en su plataforma de observabilidad generalista. Databricks ofrece system tables nativas para sus workspaces, pero solo cubre su propio ecosistema. Unravel Data y Acceldata se enfocan en optimización de costos y performance, pero desde fuera de la ejecución.

La arquitectura de Definity lo diferencia: al estar dentro del runtime de Spark, tiene acceso a contexto que herramientas externas nunca tendrán. Es la diferencia entre un médico que te observa desde fuera de la habitación versus uno que está en el quirófano contigo, viendo los signos vitales en tiempo real y pudiendo intervenir inmediatamente.

Para startups evaluando este espacio, la pregunta no es «¿necesito monitoreo de pipelines?» (la respuesta es sí si dependes de datos). La pregunta es: «¿necesito intervención en tiempo real o me basta con alertas post-mortem?» Si tu negocio puede tolerar que un pipeline falle y te enteres 30 minutos después, herramientas tradicionales pueden servir. Si un fallo de datos significa que tu sistema de IA toma decisiones incorrectas en producción, necesitas algo más cercano a la arquitectura de Definity.

¿Hay casos similares en el ecosistema hispanohablante?

No se identificaron casos documentados de startups en LATAM o España usando Definity específicamente. Sin embargo, el dolor que resuelve es universal: equipos de datos en Mercado Libre, Glovo, Cabify y scaleups de fintech en la región corren pipelines de Spark a gran escala y enfrentan los mismos desafíos de visibilidad y optimización.

En España, empresas como BBVA, Santander y Repsol tienen equipos de data engineering masivos que probablemente evalúan soluciones similares. En LATAM, las fintech y proptech que dependen de datos en tiempo real para decisiones de crédito, pricing o matching tienen el mismo problema: ineficiencia en pipelines = costo directo + riesgo de decisiones basadas en datos stale.

La oportunidad para founders hispanohablantes: si estás construyendo en este espacio (data observability, pipeline optimization, agentic data ops), hay mercado validado en ambos lados del Atlántico. Definity acaba de demostrar que inversores de Silicon Valley están dispuestos a pagar por soluciones que resuelven esto de forma arquitectónica, no incremental.

Conclusiones para founders

La Serie A de $12M de Definity no es solo otra ronda de funding en el espacio de data tools. Es validación de que el problema de confiabilidad de pipelines está alcanzando un punto de inflexión, especialmente ahora que sistemas de IA agéntica dependen de esos datos.

Para founders: si tu producto depende de pipelines de datos, esto debería estar en tu radar. No necesitas implementar Definity específicamente (aunque si corres Spark a escala enterprise, vale la pena evaluarlo). Pero sí necesitas preguntarte: ¿mi stack actual me permite detectar y prevenir fallos antes de que impacten el negocio, o solo me alerta cuando ya es tarde?

El principio es más importante que la herramienta específica: observabilidad con capacidad de intervención vale más que monitoreo con alertas post-mortem. En un mundo donde IA toma decisiones autónomas basadas en tus datos, la diferencia entre detectar un problema 30 minutos antes o 30 minutos después puede ser la diferencia entre un negocio que escala y uno que colapsa bajo la complejidad de sus propios sistemas.

Como dijo Meyer de Nexxen: «A escala, la brecha más grande a menudo no es el tooling: es visibilidad accionable». Esa es la lección que todo founder debería llevarse.