Qué hace un Científico de Datos en una empresa

El desperdicio silencioso: contratar el perfil antes de tener los datos

El patrón se repite tanto que ya lo reconozco en la primera reunión. Gerencia decide que «hay que usar los datos», publica una vacante de científico de datos, paga por encima del promedio del mercado local y contrata a alguien con buen perfil técnico. Seis meses después esa persona pasa el 70% de su tiempo pidiendo archivos, corrigiendo campos mal cargados, cruzando planillas que no coinciden entre áreas y armando reportes que un analista habría hecho en una tarde. Nadie está haciendo mal su trabajo. La empresa simplemente compró la etapa final de un proceso cuya etapa inicial nunca construyó.

El costo no es solo el sueldo. Es tener a un perfil escaso resolviendo problemas de plomería mientras el negocio sigue decidiendo por intuición. Y es el costo político: cuando ese contrato no da resultados visibles en un año, la conclusión interna casi nunca es «no teníamos los datos listos», sino «esto de los datos no funciona en nuestra industria». Eso congela cualquier iniciativa seria por los siguientes tres años.

Lo que casi nadie mide antes de contratar: cuántas de las preguntas que gerencia quiere responder tienen hoy datos que las soporten. Si la respuesta honesta es «ninguna con confianza», el problema no se resuelve con una contratación de ciencia de datos. Se resuelve ordenando cómo se captura, se valida y se guarda la información en los procesos que ya existen. Ese trabajo es menos vistoso y es el que de verdad desbloquea todo lo demás.

Qué hace de verdad un científico de datos (más allá de la definición de la vacante)

Un científico de datos convierte información histórica de la empresa en decisiones que se pueden tomar antes, mejor o con menos error. Su ciclo real de trabajo tiene cuatro etapas y solo una de ellas involucra modelos: traducir un problema de negocio en una pregunta que los datos puedan responder, verificar si esos datos existen y son confiables, construir el análisis o el modelo, y dejar el resultado dentro de un proceso donde alguien lo use para decidir algo. La cuarta etapa es la que más se salta y la que determina si el trabajo sirvió o no.

La parte que las descripciones de puesto suelen enterrar es la primera. Traducir «queremos vender más» en «queremos identificar, cada lunes, los 50 clientes con mayor probabilidad de dejar de comprar este trimestre, para que el equipo comercial los llame antes» es el trabajo más difícil y más valioso del rol. Requiere entender cómo cobra, despacha y factura la empresa, no solo saber programar. Un científico de datos que no puede hacer esa traducción va a producir análisis técnicamente correctos que nadie usa.

Cómo se ve su trabajo dentro de la operación, semana a semana

Cuando el rol está bien puesto, el científico de datos no vive en un laboratorio aparte. Se sienta con las áreas que toman decisiones repetitivas, entiende el criterio actual que usa la gente con experiencia, y busca dónde ese criterio se puede sistematizar o mejorar. Esto es lo que hace en la práctica dentro de una empresa mediana:

• Traducir el dolor en una pregunta acotada: pasar de «tenemos mucha merma» a «qué combinación de proveedor, ruta y temporada explica el 80% de la merma del último año», que sí se puede responder con datos existentes.
• Auditar la materia prima antes de prometer nada: revisar cobertura, consistencia y confiabilidad de los campos que el análisis necesita, y decir en voz alta cuando no alcanzan.
• Construir el análisis o el modelo: desde una segmentación de clientes bien hecha hasta un modelo de predicción de demanda o de detección de anomalías en facturación. La técnica se elige según el problema, no según lo que está de moda.
• Validar contra la realidad del negocio: probar el resultado contra lo que el equipo con experiencia ya sabe, para detectar si el modelo está aprendiendo un patrón real o un artefacto de cómo se cargaron los datos.
• Dejarlo dentro de un proceso: definir quién recibe el resultado, cada cuánto, en qué herramienta y qué acción se espera. Un modelo que vive en un notebook no cambió nada en la empresa.
• Medir el efecto y corregir: comparar el desempeño del proceso antes y después, y ajustar cuando el patrón cambia porque cambió el negocio.

Ese último punto separa al que produce resultados del que produce entregables. Los modelos se degradan cuando la realidad cambia: entra un competidor, se abre un canal nuevo, cambia la política de crédito. Alguien tiene que notar que la predicción dejó de ser útil antes de que la operación pierda plata confiando en ella.

Qué NO es y qué no va a resolver por más bueno que sea

Acá está la tensión que casi nadie pone por escrito en la vacante. Un científico de datos no es un arreglo para una empresa que no ordenó su información, y tampoco es la persona que va a montar tu plataforma de IA. Contratarlo esperando cualquiera de esas dos cosas garantiza frustración de ambos lados.

• No es un ingeniero de datos. No es su trabajo construir y sostener los pipelines que llevan información desde tus sistemas hasta un lugar consultable. Puede hacerlo a la fuerza, mal y de mala gana, y va a ser el uso más caro posible de su tiempo.
• No es un analista de reportes. Si lo que necesitas es un tablero confiable de ventas, cobranzas y stock, un buen analista de datos te lo entrega antes y por menos plata.
• No es un ingeniero de IA. Integrar modelos de lenguaje con tus sistemas, controlar costos de API, manejar errores en producción y dejar trazabilidad es otra disciplina, con otro perfil.
• No arregla procesos rotos. Si el equipo comercial no registra las visitas, ningún modelo va a inferir por arte de magia qué pasó en esas visitas. Los datos que no se capturan no existen.
• No sustituye la decisión de negocio. Entrega evidencia y probabilidad. Quién asume el riesgo de actuar sobre esa evidencia sigue siendo el gerente.

Tampoco garantiza que el resultado se use. He visto modelos sólidos, con buen desempeño validado, muertos en la carpeta compartida porque nadie definió quién los iba a mirar un martes a las nueve de la mañana.

Cuándo se justifica contratarlo y cuándo es quemar presupuesto

Señales de que sí se justifica

• Tienes decisiones repetitivas de alto impacto que hoy se toman por intuición: a qué cliente atender primero, cuánto stock comprar, qué operación auditar.
• Esas decisiones ocurren con frecuencia suficiente para que una mejora pequeña se acumule: semanal o diaria, no una vez al año.
• Tus sistemas transaccionales registran la operación de forma consistente y hay al menos uno o dos años de historia utilizable.
• Existe alguien del negocio dispuesto a cambiar cómo trabaja su equipo si el análisis muestra algo incómodo.
• Ya hiciste el análisis fácil con reportes y llegaste al techo de lo que la descripción histórica te puede decir.

Señales de que todavía no toca

• La información crítica vive en Excels que cada área versiona a su manera y nadie sabe cuál es el archivo bueno.
• No hay una pregunta concreta, solo la ambición general de «aprovechar los datos» o de «hacer algo con IA».
• El volumen de decisiones es bajo y el criterio del equipo con más experiencia todavía funciona mejor que cualquier modelo.
• Nadie en dirección va a cambiar una decisión aunque el análisis contradiga lo que se viene haciendo hace diez años.
• El presupuesto alcanza para la contratación pero no para ordenar la captura de datos que ese rol va a necesitar.

Cómo se evalúa este rol: por resultado y criterio, no por títulos ni librerías

Regla dura, y va a incomodar a más de uno en Recursos Humanos: el científico de datos se evalúa por el resultado de negocio que produce y por su criterio sobre procesos y datos. No por su maestría, no por las certificaciones de la nube de turno, y no por qué tan al día está con la librería que salió el mes pasado. Las herramientas cambian cada dieciocho meses. El criterio para saber si una pregunta se puede responder con los datos que hay, ese no se aprende en un curso.

En una entrevista real, la pregunta que más información me da no es técnica. Es: «cuéntame un proyecto en el que decidiste no construir el modelo, y por qué». Quien nunca ha frenado un proyecto por calidad de datos o por falta de una decisión clara del otro lado, o tuvo mucha suerte, o entrega lo que le piden sin cuestionar la premisa. Lo segundo es exactamente el perfil que termina haciendo reportes carísimos durante dos años.

La segunda pregunta que uso: «qué proceso de la empresa cambió por tu trabajo, y cómo lo supiste». La respuesta buena es concreta y menciona a personas: el equipo de cobranzas empezó a priorizar distinto, la operación cambió el orden de revisión, se dejó de auditar el 100% para auditar el 12% donde estaba el riesgo. La respuesta débil habla de precisión del modelo, de dashboards entregados y de reuniones sostenidas. Esa diferencia predice mejor el desempeño futuro que cualquier prueba técnica.

Errores típicos que veo en empresas reales

• Contratar el rol sin dueño de negocio asignado. Si nadie del área operativa es responsable de usar el resultado, el trabajo queda flotando entre todos y no lo reclama nadie.
• Pedirle que arregle la calidad de los datos como parte del puesto. Se puede, pero entonces estás pagando sueldo de científico de datos por trabajo de ingeniería de datos y no vas a ver modelos en un año.
• Medirlo por cantidad de entregables. Cuatro modelos entrenados y cero decisiones cambiadas es peor resultado que un solo análisis que hizo que operaciones dejara de revisar todo a mano.
• Dejarlo aislado en un área de innovación. Sin contacto diario con la gente que toma las decisiones, sus análisis van a ser técnicamente correctos y operativamente inútiles.
• No documentar el criterio. Si el conocimiento sobre qué datos son confiables vive solo en la cabeza de una persona, la empresa vuelve a foja cero el día que renuncie.

Todos estos errores comparten la misma raíz: se compra el rol y no se compra la condición que lo hace útil. Nadie contrata un chofer antes de tener el camión, pero con datos eso pasa todo el tiempo.

Cómo medir si la contratación funcionó

La forma de medir este rol es la misma que uso para cualquier inversión en datos o IA: no se mide la actividad, se mide el cambio en la operación. A los seis meses estas señales te dicen si valió la pena, y ninguna de ellas es un número de vanidad.

• Cuántas decisiones operativas concretas se toman hoy distinto que antes, con nombre del proceso y del área responsable.
• Tiempo que le toma a la empresa responder una pregunta de negocio nueva: si antes eran tres semanas de recolectar archivos y ahora son dos días, hubo trabajo de fondo bien hecho.
• Porcentaje de trabajo del científico de datos dedicado a limpiar y perseguir información versus a analizar y modelar. Si supera la mitad en limpieza, tienes un problema de ingeniería de datos, no de análisis.
• Efecto medible en la métrica del proceso intervenido: merma, tasa de recompra, días de cobranza, casos auditados por hallazgo encontrado.
• Si el resultado sigue usándose pasados tres meses sin que nadie lo recuerde, o si el equipo volvió a su criterio anterior en cuanto bajó la presión.

Si a los seis meses ninguna de estas señales se movió, la lectura correcta rara vez es «contratamos a la persona equivocada». Casi siempre es que la empresa pidió respuestas sobre datos que nunca estuvo dispuesta a ordenar, o que no había nadie del lado del negocio con autoridad e interés para cambiar cómo se decide. Eso no se arregla con otra contratación. Se arregla decidiendo qué proceso vale la pena, y poniendo la base antes de comprar el techo.