Ingeniero de IA vs Científico de Datos: en qué se diferencian

La vacante se escribe mal antes de que llegue el primer candidato

Casi ningún error de contratación en IA empieza en la entrevista. Empieza el día que alguien copia una descripción de puesto de internet y le pone el título que suena más serio. Así aparecen vacantes que piden a una sola persona estadística avanzada, arquitectura de nube, ingeniería de datos, despliegue de modelos y comunicación con directorio. Ese perfil existe, es escaso y es caro. Y la mayoría de las veces la empresa no lo necesitaba: necesitaba uno de los dos oficios, bien definido.

El síntoma llega seis meses después. El área que pidió la contratación dice que el proyecto de IA no está dando resultados. Cuando reviso, el trabajo hecho es bueno técnicamente: hay análisis serios, modelos entrenados, métricas razonables. Lo que no hay es un solo proceso funcionando distinto. Nadie cambió cómo cotiza, cómo atiende o cómo decide. El entregable fue conocimiento y la expectativa era operación. La pregunta útil antes de abrir la vacante es otra: ¿ya sé qué proceso quiero cambiar, o todavía estoy averiguando si vale la pena?

Qué problema resuelve cada uno de verdad

El científico de datos existe para reducir incertidumbre. Toma una pregunta de negocio difusa (por qué se nos caen los clientes, qué pedidos van a llegar tarde, qué precio deberíamos poner) y la convierte en una hipótesis que se puede probar con los datos que la empresa tiene. Su valor no está en el modelo, está en el veredicto: se puede o no se puede, los datos alcanzan o no alcanzan, el impacto justifica o no justifica construirlo. Esa respuesta, entregada rápido y con honestidad, ahorra mucho más dinero que un modelo con buena precisión.

El ingeniero de IA existe para reducir fricción entre una capacidad y la operación. Su trabajo es que algo que funciona en una prueba funcione todos los días, con datos reales, usuarios reales y errores reales. Eso incluye conectar el sistema a las fuentes vivas, manejar qué pasa cuando el modelo se equivoca o el proveedor se cae, controlar costos de inferencia, dejar trazabilidad de cada ejecución y hacer que el resultado aterrice donde el usuario ya trabaja, no en una pantalla nueva que nadie abre.

Hay un matiz que cambió en los últimos años: con los modelos de lenguaje comerciales, buena parte de lo que antes exigía entrenar un modelo propio hoy se compra por API. En la mayoría de empresas medianas ya no falta quien entrene un modelo, falta quien integre bien capacidades existentes con los datos y las reglas del negocio.

El entregable: la diferencia más honesta entre los dos

Si quieres saber a quién estás contratando, no mires el título: mira qué te va a entregar al final del trimestre. El entregable es lo único que puedes revisar sin ser técnico.

Qué entrega un científico de datos

• Un diagnóstico de si los datos de la empresa sirven para responder la pregunta, y qué falta para que sirvan.
• Una hipótesis probada o descartada, con impacto de negocio estimado y los supuestos que la sostienen.
• Un modelo o análisis validado contra datos históricos, con sus límites explícitos: dónde funciona y dónde no hay que confiar en él.
• Una recomendación clara de seguir o parar, con lo que costaría llevarlo a producción.
• Definiciones de métricas que el negocio va a usar después, y que casi nunca existían antes de forma consistente.

Qué entrega un ingeniero de IA

• Un sistema corriendo, con usuarios reales usándolo dentro de su flujo de trabajo habitual.
• Integración con las fuentes de datos y las herramientas que la empresa ya usa, sin pasos manuales escondidos en el medio.
• Manejo de errores y casos raros: qué pasa cuando el dato llega vacío, cuando el proveedor responde mal, cuando el usuario pide algo fuera de alcance.
• Monitoreo y trazabilidad: se puede saber qué hizo el sistema, cuándo, con qué entrada y con qué costo.
• Un plan de mantenimiento realista, porque un sistema de IA en producción se degrada si nadie lo revisa.

Cuándo hace falta cada uno según la madurez de la empresa

El mismo perfil puede ser la mejor contratación del año o un desperdicio total según el momento en que llega. No es una escala de seniority, es una secuencia de necesidades.

Etapa 1: la empresa no sabe dónde le duele

Los datos están dispersos, cada área tiene su versión de la verdad y nadie puede decir con números dónde se pierde margen. Acá no contrates a ninguno de los dos: corresponde un diagnóstico de procesos y datos, que se puede hacer con apoyo externo acotado. Un científico de datos contratado en esta etapa pasa ocho meses limpiando bases y explicando por qué no puede modelar nada. Se va, y la empresa concluye que la IA no funcionó.

Etapa 2: hay un dolor claro, pero no se sabe si se resuelve con datos

Acá sí entra el científico de datos, con un encargo explícito: no es construir un modelo, es dar un veredicto sobre viabilidad e impacto en semanas, no en trimestres. Es también el momento donde más se gana teniendo a alguien capaz de decir que algo no vale la pena sin miedo a quedarse sin proyecto. Si el negocio depende de una capacidad predictiva propia y diferencial (pricing, riesgo, demanda, fraude), este perfil no es opcional.

Etapa 3: ya se sabe qué construir y hay que ponerlo a funcionar

Este es el terreno del ingeniero de IA, y es donde está hoy la mayoría de empresas medianas sin darse cuenta. Ya saben qué proceso duele, ya validaron con un piloto que la IA puede ayudar, y falta alguien que lo conecte al CRM, al ERP o al canal de atención y lo deje corriendo con control. Contratar acá un perfil de investigación es el error más caro del que habla la siguiente sección.

Etapa 4: hay varios sistemas en producción

Con tres o cuatro sistemas vivos aparece un problema nuevo: se contradicen, duplican datos, nadie sabe quién es dueño de qué y el costo mensual sube sin explicación. Acá el rol siguiente no es ninguno de los dos, es alguien que ordene arquitectura y gobierno. Sumar ingenieros a un desorden solo lo hace más rápido.

Lo que ninguno de los dos resuelve, aunque lo contrates bien

Contratar bien a cualquiera de los dos no arregla lo que la organización arrastra desde antes, y ambos perfiles se queman rápido cuando los mandan a pelear contra eso sin respaldo.

• No arreglan un proceso que la empresa nunca definió. Si dos áreas tienen criterios distintos para lo mismo, ningún modelo va a inventar el criterio que falta. Lo va a exponer más rápido, eso sí.
• No consiguen los datos que no existen. Si la información crítica vive en la cabeza de tres personas o en un cuaderno, el primer trabajo no es de IA, es de captura y disciplina operativa.
• No tienen autoridad para cambiar cómo trabaja otra área. Un sistema que exige que ventas registre distinto no se sostiene sin un sponsor con poder real. Sin eso queda instalado y sin uso.
• No reemplazan la decisión de negocio. Ninguno debería definir qué caso de uso es prioritario. Esa decisión es de dirección, y delegarla al perfil técnico garantiza que se elija lo más interesante, no lo más rentable.
• No sostienen solos un sistema crítico. Una sola persona que entiende todo es un riesgo operativo, no un ahorro.

El error clásico: contratar investigación cuando necesitabas producción

El error se ve así. La empresa tiene un dolor operativo concreto y urgente. Alguien en el comité dice que hay que meterse con IA. Recursos Humanos abre la vacante más prestigiosa que encuentra, con maestría o doctorado y dominio de frameworks. Llega alguien brillante, entrenado para investigar preguntas abiertas, y le entregan un dolor cerrado que exigía integración. A los seis meses hay tres modelos excelentes y ni un proceso cambiado.

El criterio de procesos es lo que casi nadie evalúa y lo que más predice el resultado. Alguien con criterio de procesos pregunta quién usa esto hoy, qué pasa si el sistema se equivoca, cuánto cuesta ese error y qué se rompe en el flujo si lo cambiamos. Alguien sin criterio de procesos pregunta qué modelo vamos a usar. Los dos pueden tener el mismo currículum. Solo uno te va a dar un resultado de negocio.

Errores típicos que veo repetirse

• Escribir una sola vacante que junta los dos oficios más ingeniería de datos, y esperar que alguien haga todo por el sueldo de uno.
• Contratar por el prestigio del título en vez de por el entregable que la empresa necesita en los próximos seis meses.
• Meter a la persona en un área sin poder de cambiar procesos, y después culparla de la falta de adopción.
• No definir por escrito qué se considera éxito antes de que empiece, y evaluarla con expectativas que nadie enunció.
• Pedir un caso de uso nuevo cada mes, con lo que ningún sistema llega a producción.

Cómo decidir a quién contratar y cómo saber si acertaste

La decisión se resuelve con dos preguntas honestas antes de abrir la vacante. Primera: ¿puedo nombrar el proceso, la decisión y la persona que van a cambiar con esto? Si no puedes, sigues en descubrimiento y necesitas al científico de datos, o un diagnóstico previo. Segunda: ¿hay alguien en la empresa que vaya a usar esto todos los días y que ya lo esté pidiendo? Si la respuesta es sí, necesitas ejecución y el perfil correcto es el ingeniero de IA.

Para medir si acertaste, olvida las métricas que se ven bien en una lámina: precisión del modelo, casos explorados y dashboards creados no dicen nada del negocio. Estas son las señales que sí importan.

• Hay al menos un proceso que funciona distinto que hace seis meses, y el área dueña puede explicar en qué cambió sin ayuda del área técnica.
• Existe un usuario que seguiría usando el sistema por decisión propia si mañana le dijeras que es opcional.
• Alguien puede responder qué pasa cuando el sistema falla, y esa respuesta no es avisar por correo y hacerlo a mano.
• El costo de operar el sistema es conocido, previsible y alguien lo revisa cada mes.
• Más de una persona entiende cómo funciona lo que se construyó, aunque sea a nivel de operación.
• Los casos que se decidieron no construir están documentados con su razón: señal de que hubo criterio y no solo entusiasmo.