MotherDuck propone el rol de Data Intelligence Engineer

El ingeniero de datos principal de MotherDuck, Nick Ursa, lo resume con una frase que suena a final feliz y no lo es: «Es la primera vez en mi carrera que no tengo backlog». El problema es que trabaja más que nunca. Su trabajo dejó de consistir en escribir pipelines y pasó a consistir en verificar que los números que produce un agente de IA sean correctos.

Ese cambio de función es el centro de una propuesta que la compañía detrás de DuckDB en la nube llevó al evento Data Outpost, el 4 de noviembre: bautizar el rol emergente como Data Intelligence Engineer y publicar su descripción de puesto completa. No es una etiqueta de marketing. Es una respuesta concreta a una pregunta que todo founder con datos va a tener que contestar pronto: si un agente ya escribe el SQL, ¿quién responde por el número que sale en el tablero?

Qué es un Data Intelligence Engineer y en qué se diferencia de un data engineer

Según la definición que publicó MotherDuck en su blog, el Data Intelligence Engineer automatiza el trabajo del data engineer (la ingesta) y el del analytics engineer (la transformación y el modelado) mediante la creación y conducción de agentes de software. No reemplaza a esas personas: cambia lo que hacen.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Su tarea central es codificar el conocimiento del sistema en un contexto compartido que otros agentes puedan usar para responder preguntas sobre la organización. Eso incluye cosas técnicas, como qué campos se pueden unir entre tablas, y cosas de negocio, como qué significa exactamente «ARR» cuando lo dice alguien de la empresa.

El segundo pilar son las evals: pruebas de sistema que validan que, ante una pregunta con respuesta conocida, el agente responde lo correcto. Una buena suite de evals da confianza sobre el tipo de preguntas que los usuarios hacen de verdad, y además avisa cuando algo se rompe.

El objetivo final es habilitar el autoservicio. En palabras del propio blog, cuando el Data Intelligence Engineer hace bien su trabajo, cualquiera que haga una pregunta obtiene la experiencia de trabajar con el analista más inteligente de la compañía.

El problema real: la respuesta llega cuando ya nadie recuerda la pregunta

La descripción del rol arranca con un diagnóstico que cualquier founder con equipo de datos reconoce. Un líder de marketing nota un pico de churn un lunes y pide una investigación. Un analista toma el ticket, descubre que falta exportar una fuente y abre otro ticket. Un data engineer cambia el pipeline, lo testea, corre el backfill y cierra. La pelota vuelve al analista, que recién ahí construye el tablero. Para cuando el dashboard está listo, el de marketing ya no recuerda por qué preguntó, y el churn se recuperó solo dos semanas después.

Nadie hizo nada mal. Pero cada traspaso implica espera, se pierde contexto y la capacidad de actuar sobre la respuesta se degrada. La generación de herramientas de IA tipo copiloto aceleró algunos tramos, pero no resolvió el fondo: seguía habiendo demasiados traspasos para actuar a tiempo.

Qué cambió para que la IA en analítica funcione ahora

Hasta diciembre de 2025, el argumento contra la IA aplicada a analítica era fácil de sostener: los modelos escribían SQL malo y la lógica de negocio era imposible de inferir. La conclusión razonable era que esto no iba a funcionar.

Después cambiaron tres cosas a la vez. Los modelos mejoraron en SQL. La lógica de negocio resultó ser algo que un agente puede deducir si tiene contexto útil. Y los agentes pasaron a ser multi-turno: pueden intentar una consulta, mirar qué volvió y volver a intentar, igual que haría un analista humano.

La prueba de existencia que da el propio autor es concreta: la presentación del evento Data Outpost no se armó en PowerPoint ni en Google Slides, sino como una app construida con MotherDuck y Claude, con datasets en vivo de cuatro fuentes distintas y visualizaciones interactivas, sin mirar una sola línea de código o SQL.

Lo que un modelo no puede adivinar: tu definición de ingresos

Acá está el punto más útil para un founder. Un modelo sabe SQL. No sabe cómo cuenta ingresos tu empresa, ni cuál de varias tablas parecidas es la buena. El blog lo ilustra con un ejemplo que duele por lo real: la tabla correcta se llama revenue_cpx_new_revised_v2_use_this_one. Tampoco sabe que cuando ventas habla de ingresos se refiere a ingresos comisionables y finanzas usa otra definición.

La conclusión del artículo es incómoda para quien invirtió en documentar todo: el contexto es una muñeca ortopédica difícil de mantener. Mejor es construir un modelo de datos limpio desde el principio. La analogía es de producto: si tu usuario tiene que leer el manual, es una falla de diseño. El contexto es el manual de los agentes.

Las tres capas de supervisión: Wild West, Curated y Core

Más gente construyendo significa más chances de equivocarse con menos supervisión, y ahora el equipo de datos puede quedar como responsable. La mitigación que propone MotherDuck tiene dos partes.

La primera es que quien está más cerca del problema detecta mejor el error: la persona que convive con la métrica de churn nota cuando algo se ve raro, incluso en los datos de origen.

La segunda es graduar la vigilancia. Ursa lo formula así: «Los agentes necesitan supervisión proporcional a su radio de explosión». De ahí salen tres círculos:

Wild West: cualquiera construye, idealmente sobre una base razonable, y el equipo de datos no interviene.
Curated: dashboards, visualizaciones, apps y métricas importantes para el negocio. Si algo se rompe, el equipo de datos hace su mejor esfuerzo por arreglarlo.
Core: métricas clave de la organización, que deben ser de alta calidad y predecibles siempre. El número que va al board vive acá.

Las piezas que MotherDuck ya tiene en el mercado

La propuesta no es solo conceptual. SiliconANGLE reportó que la compañía lanzó Flights, una capacidad que permite crear y operar flujos de ingesta conversando con asistentes de IA como ChatGPT, Claude y Gemini, con un precio basado en consumo de runtime desde aproximadamente 60 centavos por hora. Antes había lanzado Dives, para generar dashboards y apps con IA. A eso se suman Guides (archivos markdown con el modelo de datos y el contexto de negocio, que un admin puede promover a toda la organización) y Duckling, una instancia dedicada de DuckDB por persona y por agente.

El mismo medio consigna que el servicio en la nube tiene alrededor de 850 clientes de pago tras 18 meses de operación comercial, y que la empresa acumula US$100M levantados. CRN recuerda que el primer release de su plataforma serverless salió en junio de 2023 y que en septiembre de ese año cerró una Serie B de US$52,5M, y cita a IDC para dimensionar el terreno: el volumen total de datos crece a más del 20% anual y llegaría a unos 291 zettabytes en 2027.

Qué significa esto para tu startup

Si tienes un equipo de datos de tres personas o si tú eres el equipo de datos, el mensaje operativo es el mismo: el cuello de botella dejó de ser escribir la consulta y pasó a ser definir qué significa cada número.

Acciones concretas para esta semana:

Escribe el glosario antes que el prompt. Un documento único con la definición de tus cinco métricas críticas (ingresos, churn, ARR, margen, activación) y cuál es la tabla canónica de cada una. Si ventas y finanzas usan definiciones distintas, escríbelo explícitamente: eso es exactamente lo que el agente no puede adivinar.
Arma una suite mínima de evals. Diez preguntas con respuesta conocida, del tipo «¿cuánto facturamos el mes pasado?», y córrelas cada vez que cambies el modelo o el agente. Sin eso, no tienes forma de saber si el sistema se rompió o simplemente cambió de opinión.
Clasifica tus dashboards en tres capas. Marca cuáles son Core (los que van al board y a inversores), cuáles Curated y cuáles Wild West. La supervisión y el esfuerzo de mantenimiento deben seguir esa clasificación, no repartirse por igual.
Nombra un responsable. El blog lo dice sin vueltas: data engineering, sin importar la herramienta ni quién lo haga, es una función de rendición de cuentas. Alguien tiene que poder firmar que el número está bien.

Conclusión

El título de Data Intelligence Engineer puede parecer una etiqueta nueva para un trabajo viejo, pero describe bien un desplazamiento real: el valor del equipo de datos ya no está en producir el número, sino en garantizar que el número que produce un agente sea confiable y en hacer que el resto de la empresa pueda preguntar sin intermediarios. Para un founder, eso es una buena noticia doble: menos dependencia de contratar un equipo grande y más presión para tener claridad sobre cómo funciona su propio negocio. El equipo de datos no desaparece. Cambia de dueño de la pregunta a dueño de la respuesta.