Cuando una empresa decide implantar IA, el primer instinto suele ser siempre el mismo: contratemos a un data scientist. El instinto es comprensible — el data scientist es el rol icónico de la era de la IA en el imaginario colectivo. Pero en la práctica observamos que precisamente esa contratación es el primer error que ralentiza o detiene el proyecto.
La composición correcta del equipo depende de lo que concretamente está construyendo: un sistema RAG sobre documentación corporativa es distinto de un modelo predictivo de anomalías en una línea de producción, que a su vez es distinto de un agente autónomo en atención al cliente. Cada uno de esos proyectos requiere una combinación diferente de personas — y algunos no necesitan ningún equipo interno.
Por qué el data scientist no es la primera respuesta
El data scientist se centra tradicionalmente en el análisis exploratorio de datos, el modelado estadístico y la experimentación. Son valiosos cuando no sabe qué está buscando en los datos — en analítica predictiva, al descubrir patrones en datos históricos, en pruebas A/B.
Sin embargo, la mayoría de los proyectos de IA que las empresas realmente necesitan no tratan de descubrir patrones. Son integraciones de sistemas: un LLM conectado a la documentación corporativa, un agente que verifica pedidos en el ERP, automatización del triaje de correos. Aquí necesita a alguien que sepa construir software en producción — no análisis exploratorio.
En la práctica ocurre así: la empresa contrata a un data scientist, este realiza experimentos elegantes en un Jupyter notebook, los resultados parecen prometedores. Luego llega la pregunta «¿cuándo lo desplegamos en producción?» — y se hace el silencio. El data scientist no es un ingeniero de software, no conoce Docker, CI/CD, diseño de API ni monitorización de sistemas en producción. El proyecto queda atascado en la fase de prototipo.
Los roles que realmente necesita
ML / AI engineer — el núcleo del equipo
Este es el rol que la mayoría de las empresas subestima, pero es fundamental para la IA en producción. El ML/AI engineer combina dos competencias: entiende los modelos (fine-tuning, embedding, inference, prompt engineering) y sabe empaquetar esas capacidades en software robusto (API, sistemas de colas, monitorización, testing).
En la práctica: el ML engineer configura el pipeline RAG con búsqueda híbrida, elige el modelo de embedding adecuado, ajusta el retrieval y expone el resultado como una API en producción con observabilidad. Un data scientist haría el primer paso; un ingeniero de software sin contexto de ML haría el último. El ML/AI engineer es capaz de hacer ambos.
Para empresas que construyen con modelos frontier a través de API (Claude, GPT, Gemini), el rol de ML/AI engineer es aún más importante — aquí se trata menos de entrenamiento y más de orquestación, prompt engineering, tool calling e integraciones. Más sobre lo que impacta en costes y fiabilidad en el artículo Costes de un agente de IA en producción.
Experto de dominio — sin él el proyecto no llega a ningún lado
Este es el rol que las empresas omiten con más frecuencia, y su ausencia es la segunda causa más común de fracaso (después de los datos de baja calidad).
El experto de dominio es alguien que conoce en profundidad el proceso que está automatizando. En la práctica es un operario experimentado, un jefe de departamento, un técnico o un especialista en el área. Esta persona no sabe nada de LLM, pero sabe exactamente: - Qué respuestas son correctas y cuáles solo lo parecen - Dónde están los casos límite, las excepciones y las situaciones en que el sistema falla - Cómo es un «buen resultado» desde el punto de vista del negocio — no desde una métrica de accuracy
Sin el experto de dominio, el ML engineer optimiza una métrica, no valor real. El resultado es un sistema que funciona de maravilla en la demo y en producción repite los mismos errores una y otra vez.
El experto de dominio no tiene que ser un miembro del equipo a tiempo completo. Son suficientes 4–8 horas semanales para revisar outputs, calibrar la evaluación y realizar ciclos de retroalimentación.
Ingeniero de datos — solo cuando tiene un problema de datos
Si su proyecto de IA depende de pipelines de datos — limpieza, transformación, streaming de eventos desde máquinas, integración de múltiples fuentes — necesita un ingeniero de datos. Este perfil construye la infraestructura que abastece de datos a la IA de forma fiable.
Pero si está construyendo RAG sobre documentos existentes o un agente que llama a APIs existentes, el ingeniero de datos no es crítico en la primera fase. No sobreestime la necesidad de este rol — incorpórelo cuando realmente esté resolviendo un problema de datos, no de forma preventiva.
Ingeniero MLOps — a partir de cierta escala
MLOps cubre el despliegue de modelos, la monitorización del drift, la gestión de versiones y el pipeline de reentrenamiento. Es un rol fundamental, pero solo cuando tiene modelos en producción que necesitan mantenimiento y actualización.
Para los primeros proyectos, esta función la suele asumir el ML engineer por sí solo — es innecesario tener un especialista MLOps dedicado antes de que haya algo que gestionar. Incorpórelo cuando gestione más de 3–5 modelos en producción o cuando afronte ciclos de reentrenamiento.
Product owner — un rol infravalorado pero imprescindible
Todo proyecto de IA necesita a alguien que sea responsable de qué problema está resolviendo y cómo medirá el éxito. Sin este rol, el ML/AI engineer optimiza cosas técnicamente interesantes, no valor de negocio.
El product owner (o AI product manager) define las métricas de éxito antes del inicio, prioriza los casos de uso según el ROI y facilita la comunicación entre el equipo técnico y los stakeholders. Este rol puede ser asumido por un project manager interno con suficiente comprensión técnica — no tiene que ser un especialista en IA.
Equipo mínimo viable para el primer proyecto
De la experiencia práctica para un primer proyecto de IA en producción típico (sistema RAG, agente, integración LLM):
- 1× ML/AI engineer (tiempo completo durante la implementación)
- 1× experto de dominio (tiempo parcial, 4–8 h/semana)
- 1× product owner / persona responsable del negocio (tiempo parcial, 2–4 h/semana)
Este es el equipo mínimo viable. Menos de tres personas con esta composición es una configuración de riesgo — o falta la competencia técnica, o falta el vínculo con el contexto de negocio real.
Para un proyecto más complejo (sistema multi-agente, fine-tuning de un modelo propio, integración con múltiples sistemas) amplíe con un ingeniero de datos y un especialista MLOps. Sobre cuándo tiene sentido el ajuste fino del modelo escribimos en el artículo RAG vs fine-tuning — toma de decisiones.
Equipo interno vs. partner — cuándo qué
Esta es una pregunta que las empresas se plantean tarde — normalmente cuando el proceso de contratación se bloquea o cuando el proyecto queda paralizado.
Construya un equipo interno cuando: - La IA es el núcleo de su producto o una ventaja competitiva clave (no un soporte para un proceso existente) - Tiene un horizonte de inversión a largo plazo (12+ meses) y un producto estable sobre el que construir la capa de IA - Necesita control total sobre los datos, los modelos y el pipeline (entorno regulado, sistemas críticos para GDPR) - Planea iterar rápido y en ciclos cortos — un equipo gestionado externamente es más lento en esto
Involucre a un partner externo cuando: - Está afrontando su primer o segundo proyecto de IA y aún no tiene competencia interna - Necesita resultados rápidos (3–6 meses) — la contratación y el onboarding de un equipo interno suele llevar 4–9 meses - El caso de uso está bien definido y tras el despliegue solo requiere mantenimiento, no desarrollo activo - Quiere transferencia de conocimiento — un buen partner no solo entrega la solución, sino que enseña al equipo interno a trabajar con ella
Sobre la decisión entre implementación propia y solución lista escribimos con más detalle en el artículo Build vs buy solución de IA.
El modelo híbrido funciona bien: un partner externo entrega el primer proyecto, el equipo interno aprende y asume la responsabilidad del mantenimiento y desarrollo. Lo esencial es que el partner apoye activamente esa transferencia — no que solo entregue y se marche.
Errores frecuentes al formar el equipo
Busca un «experto en IA» — y no lo encuentra
El experto general en IA no existe. Todo profesional verdaderamente experimentado tiene una especialización: inference y serving, fine-tuning, orquestación de agentes, arquitectura RAG. Busque a alguien con relevancia concreta para su caso de uso — no a un genio universal.
Subestima el tiempo del experto de dominio
Las empresas suelen planificar «unas pocas horas al mes para consultas». En la práctica, un proyecto de IA de calidad necesita una implicación regular y constante del experto de dominio — no un kickoff puntual al inicio y un sign-off al final.
Confunde experimentación con competencia en producción
Un candidato que le muestra prototipos impresionantes en un notebook de Colab no tiene necesariamente experiencia en despliegues en producción. Pregunte por casos concretos: ¿Qué exactamente estaba en producción? ¿Cómo gestionaba la monitorización? ¿Cómo respondía a un cambio de regresión en la calidad? Las respuestas a estas preguntas distinguen al experimentador del ingeniero.
Escala antes de validar el caso de uso
Lo vemos con regularidad: la empresa contrata a un equipo completo (3–5 personas), compra infraestructura GPU y a los seis meses descubre que el caso de uso no era suficientemente valioso para el despliegue en producción. Valide primero con un equipo mínimo y una solución externa; el scale-up llegará cuando sepa qué funciona.
Señales de que el equipo tiene la composición incorrecta
De la práctica — señales de alerta que vemos en clientes:
- El proyecto lleva más de 3 meses atascado en la fase de prototipo — típicamente falta un ML/AI engineer con experiencia en producción o un product owner que defina los criterios de salida
- El sistema «no funciona en la práctica» pese a buenos benchmarks — falta el experto de dominio en el ciclo de evaluación
- El equipo no sabe responder a «cómo medirán el éxito» — falta el product owner o las métricas están definidas en términos puramente técnicos (accuracy, F1) sin vínculo con el negocio
- La contratación lleva 6+ meses sin resultado — el perfil es demasiado genérico o las expectativas salariales no se corresponden con el mercado; considere un partner externo para la primera fase
Cómo proceder si está empezando
Si está construyendo su primer proyecto de IA y no tiene equipo interno, recomendamos:
- 1.Defina el caso de uso y las métricas de éxito antes de cualquier contratación — sin este paso no sabe a quién busca
- 2.Identifique al experto de dominio internamente — es un rol que no puede comprar fuera
- 3.Considere un partner externo para la primera fase — inicio más rápido, menor riesgo, posibilidad de transferencia de conocimiento
- 4.La contratación del ML/AI engineer comience en paralelo al piloto — el equipo estará listo para asumir el proyecto en el momento adecuado
Más sobre cómo estructurar los primeros 90 días de un proyecto de IA encontrará en el artículo Cómo empezar con IA en la empresa.
Preguntas frecuentes
¿Necesito un data scientist para un proyecto de IA con LLM?
En la mayoría de los casos no — al menos no como rol principal. El data scientist es valioso en el análisis exploratorio y el modelado estadístico. Los proyectos construidos sobre LLM (RAG, agentes, integraciones) necesitan principalmente un ML/AI engineer que entienda tanto los modelos como el software en producción. El data scientist puede complementar al equipo más adelante — por ejemplo en la evaluación o en el análisis de outputs.
¿Cuántas personas se necesitan como mínimo para un proyecto de IA en producción?
De la experiencia práctica: tres roles son el mínimo — ML/AI engineer (tiempo completo), experto de dominio (tiempo parcial) y product owner / persona responsable del negocio (tiempo parcial). Un equipo de una sola persona o sin experto de dominio tiene un riesgo significativamente mayor de fracasar o quedarse atascado en la fase de prototipo.
¿Es mejor contratar un equipo o ir a través de un partner externo?
Depende de su horizonte y de dónde se encuentra. Para el primer proyecto recomendamos un partner externo o un modelo híbrido — es más rápido y reduce el riesgo de una contratación costosa antes de validar el caso de uso. Un equipo interno tiene sentido cuando la IA es el núcleo de su producto y cuenta con un horizonte de inversión a largo plazo.
¿Cómo reconozco que un candidato tiene experiencia en producción y no solo en prototipado?
Pregunte por despliegues concretos: ¿Qué exactamente estaba en producción? ¿Cuál era el volumen de datos o de usuarios? ¿Cómo gestionaba la monitorización y los estados de error? ¿Cómo respondía cuando la calidad se degradó? Los prototipistas responden en términos generales; los ingenieros de producción describen decisiones y compromisos concretos.
¿Tiene que entender de IA el experto de dominio?
No — y ni siquiera es deseable. El experto de dominio debe entender el proceso que está automatizando: saber evaluar si el output es correcto, identificar casos límite y definir qué es un «buen resultado» desde el punto de vista del negocio. El conocimiento técnico de IA no es un requisito aquí.
*Si está definiendo la composición del equipo para un proyecto de IA o está considerando qué construir internamente y qué confiar a un partner, estaremos encantados de sentarnos para una consulta gratuita. Le ayudaremos a evaluar qué roles necesita realmente — y cuándo la colaboración externa es más rentable que la contratación.*