Ingeniero de datos
Construyes la infraestructura de datos e IA sobre la que corre el resto de la empresa. Pipelines, warehouses, vector stores, infraestructura de servicio de modelos, observabilidad: los cimientos que permiten a los agentes hacer su trabajo y a los analistas producir insight. El agente escribe gran parte del código; tú diseñas la arquitectura y eres dueño de los cimientos.
El trabajo
Eres dueño de la infraestructura de datos e IA de la empresa. Pipelines ETL, data warehouses, sistemas de streaming, vector stores, infraestructura de servicio de modelos, entrega de contexto a agentes, observabilidad de datos. El agente escribe gran parte del código; tú diseñas la arquitectura, validas que la infraestructura aguanta bajo carga y eres dueño de los cimientos sobre los que descansa todo lo demás.
Esta es ingeniería distinta de la ingeniería de aplicación: el material es diferente (flujos de datos, no interacciones de usuario), los modos de fallo son diferentes (corrupción silenciosa de datos, no bugs visibles) y los consumidores son diferentes (analistas, agentes, usuarios internos, no clientes externos directamente).
Día a día:
- Diseñas la arquitectura de datos. Dónde vive la data, cómo fluye, qué modelos la estructuran, cómo se accede a escala. Decisiones de arquitectura que se acumulan durante años.
- Especificas pipelines e infraestructura. El agente implementa; tú diseñas lo que se implementa y validas que sostiene.
- Construyes la capa de contexto de los agentes. Los agentes en producción necesitan contexto fiable, actual y bien estructurado. Diseñar el sustrato de datos que soporta esto es una parte sustancial del rol a escala IA-nativa.
- Eres dueño de la calidad y la observabilidad de los datos. Los datos malos corrompen silenciosamente cada consumidor aguas abajo. Diseñar observabilidad que capture problemas antes de que se propaguen es trabajo central.
- Operas la infraestructura de IA. Vector stores, pipelines de embeddings, servicio de modelos, infraestructura de evaluación: estos son sistemas de producción de primera clase con características específicas de fiabilidad y costo.
- Validas en puertas graduadas por riesgo. Los cambios rutinarios de pipeline y los ETL estándar fluyen a través de la revisión exclusiva del agente. Los cambios de esquema, las eliminaciones de datos, las decisiones de infraestructura sensibles al costo, los cambios relevantes para privacidad y las modificaciones de infraestructura de IA requieren tu aprobación directa.
- Colaboras con el analista de datos. El AD define las preguntas e interpreta los resultados; tú aseguras que los cimientos de datos respondan con fiabilidad. Definiciones, instrumentación, atribución: estas se coposeen.
- Colaboras con los ingenieros de aplicación. Sus funcionalidades generan datos; esos datos fluyen por tu infraestructura; tu infraestructura retroalimenta a sus funcionalidades. La costura importa.
Cómo se ve el éxito
Resultados concretos a este nivel:
- Fiabilidad del pipeline. Los pipelines de datos corren con fiabilidad, la latencia está acotada, los fallos se capturan y se recuperan. Los consumidores no se sorprenden por datos faltantes o corruptos.
- Calidad de los datos. Los problemas de calidad de datos, instrumentación o etiquetado se capturan en la fuente, no en el consumidor aguas abajo.
- Disciplina de costo. Costo de cómputo, costo de almacenamiento y costo de infraestructura de IA son visibles, vigentes y mejoran con el tiempo. Puedes defender el gasto en infraestructura por resultado.
- Salud de la infraestructura de agentes. Los agentes tienen acceso fiable a contexto fresco y bien estructurado. Los vector stores, pipelines de embeddings e infraestructura de servicio de modelos corren con latencia y costo predecibles.
- Coherencia arquitectónica. Las decisiones de arquitectura de datos aguantan a lo largo de años. Las migraciones de esquema son manejables. La infraestructura envejece bien en lugar de colapsar bajo su propia complejidad.
Lo que no cuenta como éxito: pipelines construidos, dashboards entregados, tecnologías adoptadas en aislamiento de los resultados.
Lo que hace interesante este trabajo
Lo interesante no son los pipelines en sí. Es situarse en los cimientos de los que el resto de la empresa depende cada vez más.
Tu trabajo es genuinamente estructural. Los analistas dependen de ti. Los agentes dependen de ti. Los ingenieros de aplicación dependen de ti. Producto depende de ti. Cuando la infraestructura de datos está bien diseñada, toda la empresa se mueve más rápido; cuando no lo está, todo lo demás lucha por compensar.
Diseñas a múltiples escalas de tiempo. Algunas decisiones (esquema, naming, particionamiento) se acumulan durante años; otras (afinamiento específico de pipeline) necesitan ajuste trimestral. Los ingenieros de datos que pueden sostener ambas escalas de tiempo producen infraestructura sólida.
Las operaciones IA-nativas necesitan un nuevo sustrato de datos. Vector stores, pipelines de embeddings, infraestructura de servicio de modelos, entrega de contexto a agentes: estos son sistemas genuinamente nuevos siendo diseñados en tiempo real. Eres parte de descubrir los patrones que la industria usará.
El trabajo diagnóstico es satisfactorio. Cuando los problemas de calidad de datos aparecen aguas abajo, la investigación a menudo involucra el flujo de trabajo, la spec, la instrumentación y a veces la infraestructura misma. El trabajo detectivesco es rico.
La ingeniería de costo es interesante. El costo de infraestructura de datos tiene características muy diferentes del costo de infraestructura de aplicación. Almacenamiento vs cómputo, batch vs streaming, fresco vs viejo, dimensionalidad de vectores, elección de modelo de embedding: la superficie de optimización es novedosa y significativa.
La colaboración entre funciones se profundiza. Con el trabajo rutinario de ETL absorbido, tienes tiempo para compromiso sustantivo con analistas de datos, ingenieros de aplicación, Producto, Workflow Architect. El rol vive en intersecciones productivas.
Tu impacto se acumula. Un sustrato de datos bien diseñado le ahorra a la empresa años de trabajo. Uno mal diseñado crea deuda técnica que constriñe decisiones por años.
La movilidad profesional es real. Los ingenieros de datos sólidos en T3 son reclutados intensamente. Las habilidades transferibles (arquitectura, diseño de sistemas, ingeniería de costo, infraestructura de IA) son valiosas a lo largo de empresas e industrias.
Lo que puede no atraerte. Tu trabajo es invisible cuando funciona. Nadie nota un pipeline que corre suavemente; solo notan el que se rompe. El reconocimiento es estructural y silencioso, no fuerte. Los ingenieros de datos que necesitan impacto directo de cara al usuario a veces encuentran que el trabajo se siente distante. También trabajas con consumidores (analistas, agentes, usuarios internos) en lugar de con clientes directamente, lo cual puede sentirse menos concreto que la ingeniería de aplicación. Y la ingeniería de datos ha sido históricamente infravalorada en relación con la ingeniería de aplicación en muchas empresas; aunque las operaciones IA-nativas están cambiando esto rápidamente, la subvaloración heredada todavía puede aparecer en algunas culturas.
Quién prospera en este rol
Las aptitudes que más importan son las de pensamiento sistémico, criterio arquitectónico y disciplina de costo, distintas de las fortalezas de la ingeniería de aplicación.
Piensas en sistemas y flujos. Los datos tienen forma de sistema. Los ingenieros que naturalmente ven flujos, dependencias y comportamiento emergente producen infraestructura de datos sólida.
Te importa la corrección por encima de la velocidad. Los datos malos corrompen todo aguas abajo silenciosamente. Los ingenieros de datos que se preocupan por la corrección producen infraestructura confiable; los que optimizan para velocidad de entrega producen problemas ocultos.
Te sientes cómodo con bucles de retroalimentación largos. Las decisiones de arquitectura muestran sus consecuencias durante meses y años. Los ingenieros de datos que necesitan feedback rápido luchan; los que pueden diseñar con cuidado y paciencia producen cimientos sólidos.
Sostienes la disciplina de costo. La infraestructura de datos puede volverse cara rápido. Los ingenieros que tratan el costo como preocupación de primera clase producen infraestructura sostenible; los que no, producen facturas sorpresa.
Puedes leer a través de los consumidores. Analistas, agentes, ingenieros de aplicación, usuarios internos: tienen necesidades diferentes de los mismos datos. Los ingenieros que pueden sostener múltiples perspectivas de consumidor producen infraestructura útil; los que solo optimizan para una fallan a los demás.
Escribes con claridad. Documentos de arquitectura de datos, especificaciones de esquema, runbooks. La escritura clara es central al rol.
Sospechas de las historias limpias. Cuando los datos se ven demasiado limpios, investigas. El escepticismo saludable sobre tus propios pipelines es esencial.
Colaboras bien con especialistas adyacentes. Analista de datos, ingeniero de aplicación, ingeniero DevOps, Workflow Architect. Los ingenieros que pueden traducir a través de estas fronteras producen infraestructura coherente.
Menos esencial que antes: dominio de alguna herramienta de datos o framework de ETL específico, la capacidad de escribir SQL complejo a mano, profundidad en algún almacén de datos específico. El agente absorbe esto. El rol valora la arquitectura, el criterio y el diseño.
Habilidades a desarrollar para llegar ahí
Las aptitudes describen la disposición. Las habilidades de abajo son lo que construyes activamente.
Especificación de arquitectura de datos. Escribir cómo fluyen los datos, dónde viven, qué modelos los estructuran, con suficiente rigor para que el agente pueda construir y el equipo pueda extender. Cómo practicar: redacta la arquitectura de datos para tu alcance actual. Pide a un colega que la cuestione; refina.
Ingeniería de fiabilidad de pipelines. Diseñar pipelines que sean observables, recuperables y predecibles bajo carga. Cómo practicar: para un pipeline, diseña la observabilidad y la recuperación antes de construir. Pruébalo simulando fallos.
Pensamiento de costo por resultado. Leer el costo de infraestructura de datos como dato de ingeniería, no de finanzas. Cómo practicar: mensualmente, audita los generadores de costo. Identifica las tres mayores oportunidades de optimización sin pérdida de calidad. Implementa una.
Custodia de esquema y definiciones. Mantener modelos de datos coherentes en los que los consumidores puedan confiar. Cómo practicar: toma un esquema central. Escribe la especificación definitiva. Consigue alineación entre funciones. La disciplina se acumula.
Diseño de infraestructura de IA. Vector stores, pipelines de embeddings, servicio de modelos, entrega de contexto a agentes. Cómo practicar: para un flujo de trabajo de IA que tu empresa ejecuta, documenta la infraestructura de la que depende. Identifica modos de fallo. Diseña controles.
Especificación de observabilidad de datos. Qué se mide, qué dispara alertas, cuál es la respuesta esperada. Cómo practicar: para cada pipeline, escribe la spec de observabilidad antes del pipeline. Si la respuesta a "¿cómo sabríamos que esto está roto?" es "quejas aguas abajo", la spec no está terminada.
Comunicación entre funciones. Escribir para analistas de datos, ingenieros de aplicación, Producto, DevOps, ejecutivos. Cómo practicar: redacta una propuesta de infraestructura. Muéstrasela a una persona de cada función. Donde se confundan es donde la escritura necesita trabajo.
Oficio de migraciones. Cambios de esquema, migraciones de infraestructura, eliminaciones de datos. Las operaciones de alto riesgo. Cómo practicar: después de cada migración significativa, escribe una reflexión de un párrafo. El patrón a lo largo de migraciones es tu entrenamiento.
Elige la habilidad que mapea con tu decepción de infraestructura más reciente. Practícala durante un mes.
Cómo difiere del rol heredado de ingeniero de datos
| Ingeniero de datos heredado (pre-IA) | Ingeniero de datos (IA-nativo) |
|---|---|
| Tiempo sustancial escribiendo pipelines, ETL y consultas de warehouse a mano | El código de pipeline es absorbido mayormente por el agente; el tiempo va a arquitectura y diseño |
| La infraestructura de datos es solo interna, para analistas y dashboards | La infraestructura de datos ahora sirve a agentes, analistas, usuarios internos y productos externos |
| La disciplina de costo es limpieza ocasional | La disciplina de costo es continua; la infraestructura de IA introduce nuevas características de costo |
| Las decisiones de esquema son mayormente locales | Las decisiones de esquema consideran consumidores agentes, elecciones de modelos de embedding, indexación de vectores |
| La observabilidad es algo después | La observabilidad se diseña dentro; los datos malos se capturan en la fuente, no en el consumidor |
| Los mejores ingenieros son los más rigurosos operativamente | Los mejores ingenieros son los arquitectos más afilados, con criterio sobre costo y fiabilidad |
| Trayectoria profesional: Ingeniero de datos → Senior → Lead → Director de datos | Trayectoria profesional: la misma, más lateral a Workflow Architect, Agent Supervisor (para foco en infraestructura de IA), Senior FSE con profundidad de infraestructura |
El rol no es un ingeniero de datos más rápido. Es uno más arquitectónico: la implementación de pipelines se absorbe, el criterio de diseño se expande.
Qué patrones de evolución de roles están en juego
- Elevación (principal). El centro de gravedad del rol asciende de la implementación a la arquitectura, el diseño de costo y la especificación de observabilidad.
- Convergencia (secundaria). Los límites con DevOps (infraestructura de IA), Ingeniero de Aplicación (funcionalidades conscientes de datos) y Analista de Datos (definiciones, instrumentación) se difuminan a medida que el rol de ingeniería de datos tiene tiempo para colaboración sustantiva entre funciones.
- Emergencia (parcial). La infraestructura de IA (vector stores, pipelines de embeddings, entrega de contexto a agentes) es responsabilidad genuinamente nueva dentro del alcance del ingeniero de datos.
La Especialización dentro de la ingeniería aplica (el rol sigue siendo distinto del Senior FSE porque el material es diferente: flujos de datos vs interacciones de usuario, modos de fallo silenciosos vs bugs visibles, consumidores de infraestructura vs experiencias de cara al cliente). El patrón de Convergencia en T3 disuelve los límites de especialidad dentro de la aplicación (FE/BE) más de lo que disuelve la frontera aplicación vs infraestructura de datos, que sigue siendo operativamente distinta.
Roles relacionados en el catálogo
el equivalente de ingeniería de aplicación; ambos entregan a través de especificaciones y criterio, pero el material difiere
colaborador en la infraestructura que soporta los sistemas de datos
consumidor principal; colabora en definiciones e instrumentación
Fuentes y lecturas adicionales
- Patel, N. (2026). From Tasks to Roles: How Agentic AI Reconfigures Occupational Structures.
- De este marco: Ingeniería para la falta de fiabilidad, Estándares de ejecución con IA y La organización IA-nativa.
← Volver a Roles · La organización IA-nativa · Patrones de evolución de roles · Marco de referencia · Ingeniería para la falta de fiabilidad