El punto de partida
Toda empresa que quiere usar la IA en 2026 descubre, ya en la segunda semana del proyecto, que la parte de IA es la parte fácil. La parte difícil es la capa de debajo: dónde viven los datos, si alguien confía en ellos, si pueden unirse entre los sistemas y si esas uniones seguirán siendo correctas mañana.
La ingeniería de datos es la disciplina que decide si la funcionalidad de IA se entrega o fracasa en silencio. Es también la disciplina que menos crédito recibe, porque cuando funciona, el resultado es un número en un panel que nadie cuestiona. Cuando no funciona, el número está mal, la IA está aguas abajo y el panel miente con educación.
Este artículo trata del trabajo de construcción de pipelines de datos, almacenes y capas de análisis que aguantan bajo una carga moldeada por la IA, y de la manera en que la IA misma transforma ese trabajo.
La IA ha vuelto más costosos los datos malos
Una funcionalidad de IA hereda cada defecto de los datos que la sostienen, y los amplifica.
Antes de la IA, un mal pipeline de datos producía un panel erróneo, que alguien notaba de vez en cuando. Después de la IA, un mal pipeline de datos produce salidas de IA erróneas a gran escala, que se acumulan, derivan y son difíciles de rastrear hasta una unión que falta en una tarea ETL caducada escrita en 2023.
El efecto económico es que la calidad de los datos ha pasado de una preocupación de trastienda a una característica del producto. El coste marginal de los datos no fiables ha aumentado, porque lo que se encuentra aguas abajo de los datos no fiables (recomendaciones, puntuación, evaluaciones, automatización) es más visible para el cliente y más costoso de deshacer.
Los equipos que se toman esto en serio empiezan por reducir la superficie: menos fuentes, menos pipelines, menos copias, mejor trazabilidad. Los que no lo hacen entregan funcionalidades de IA sobre una capa de datos que no podrían explicar a un auditor, y luego pasan el año siguiente depurando los síntomas.
Pipelines, almacenes y las partes que deciden
La ingeniería de datos en 2026 se extiende sobre cuatro capas. Ingesta: captar los eventos, los snapshots y los flujos de captura de cambios de datos desde las bases de datos de producto, las API de terceros y las herramientas operativas. Almacenamiento: un almacén (Snowflake, BigQuery o Postgres autoalojado para escalas más pequeñas) capaz de responder a las consultas analíticas sin competir con la base de datos operativa. Transformación: una capa (dbt, SQLMesh) que transforma los eventos en bruto en conceptos de negocio fiables, versionados y probados. Y servicio: paneles, API y el almacén de características que alimenta los modelos de IA.
Lo que distingue una capa de datos creíble de un caos acumulado es un pequeño conjunto de hábitos. Cada transformación es código, revisado y probado. Cada tabla tiene un responsable, una expectativa de frescura y un contrato en el que sus consumidores pueden apoyarse. Cada unión está documentada lo bastante bien para que una persona que se incorpora al equipo pueda responder a la pregunta de qué significa el número.
No son prácticas exóticas. Son los valores por defecto de operación que deciden si el equipo de IA puede entregar sin paranoia.
Tres maniobras de alto apalancamiento en cada proyecto de datos
A través de los proyectos de datos que SDEN ha entregado, tres maniobras explican la mayor parte del valor. Primero, consolidar las fuentes de verdad: la mayoría de las empresas en operación tienen tres o cuatro sistemas que pretenden cada uno ser la lista de clientes canónica, y conciliarlos produce mejoras visibles de inmediato. Después, añadir la trazabilidad: poder remontar cualquier número de cualquier panel a través de cada transformación, en unos segundos, cambia la forma en que la dirección confía en la capa analítica. Por último, automatizar la calidad de los datos: tests que se ejecutan en cada refresco y bloquean la publicación cuando algo falla previenen el modo de fallo por pudrición lenta que destruye la confianza a lo largo de meses.
Ninguna de esas maniobras es glamurosa. Ninguna exige nueva tecnología. Las tres son lo que distingue una capa de datos sobre la que la IA puede apoyarse de una capa que la IA envenenará en silencio.
Tres valores por defecto en cada pipeline que entregamos
Hábitos aburridos que deciden si la capa de datos aguanta seis meses después de nuestra marcha.
Toda transformación es código
Ningún SQL sin seguimiento en una herramienta de BI, ninguna copia manual de un sistema a otro. Las transformaciones viven en el repositorio, revisadas y probadas como el resto del código.
Contratos en la frontera de las tablas
Cada tabla de la que otros equipos dependen tiene un contrato escrito: esquema, frescura, responsabilidad y el SLA en el que los consumidores pueden apoyarse. Romper el contrato exige un ciclo de obsolescencia, no una disculpa en Slack.
Una trazabilidad sobre la que se puede de verdad hacer clic
Cualquier número de cualquier panel puede remontarse, en una interfaz, hasta cada fuente que lo alimentó. Cuando el número está mal, el diagnóstico lleva minutos, no días.
El panel en el que el CEO confía a las 8 de la mañana un lunes
Una capa de datos que funciona se siente como la ausencia de peleas sobre las cifras.
Una capa de datos madura cambia la forma de las conversaciones que tiene la dirección. La reunión de ingresos del lunes deja de ser un debate sobre qué cifra es la correcta; se convierte en una conversación sobre lo que la cifra significa. La revisión de producto deja de ser un intercambio sobre los indicadores de engagement; se convierte en una discusión sobre el comportamiento de usuario que el equipo debería fomentar. El plan de contratación deja de depender de una hoja de cálculo mantenida por una sola persona que sabe dónde están enterrados los cadáveres.
El artefacto técnico detrás de ese cambio es poco lucido: un almacén con un pequeño número de modelos fiables, tablas con responsables, tests automatizados y una trazabilidad que todo el mundo en la empresa puede leer. El artefacto cultural es el que importa.
Cuando SDEN termina un proyecto de datos, el entregable no es un panel. Es un equipo que ya no tiene que pelearse sobre las cifras porque las cifras son defendibles.
Ingeniería de datos
las preguntas que más nos hacen.
Respuestas directas a las preguntas que más nos hacen. Si la tuya no está, escribe al equipo.