Contratación · July 29, 2026 · 10 min de lectura

Cómo contratar a un product manager de IA: qué evaluar

Cómo contratar a un product manager de IA: qué posee el puesto, en qué difiere del product management clásico, la alfabetización en evaluación a poner a prueba y las muestras de trabajo que la revelan.

← Parte de The five pillars of hiring: what assessments measure

Si uno de tus equipos ahora lanza una funcionalidad que responde —un copiloto, un resumidor, un agente que toma acciones—, probablemente estés a punto de contratar a un product manager de IA, y deberías saber por qué existe el título antes de empezar. El product management clásico asume funcionalidades deterministas: escribes una especificación, ingeniería la construye y la cosa se comporta igual para cada usuario, cada vez. Pon un modelo debajo y esa suposición se derrumba. La salida varía, a veces se equivoca con seguridad, y «¿cumple la especificación?» deja de ser una pregunta de sí o no. El product manager de IA es propietario exactamente de esa brecha: acotar lo que el modelo debe y no debe intentar, definir qué significa «bueno» para una salida que nadie puede predecir completamente, y ser dueño de lo que sucede cuando falla. Esta guía es para los responsables de contratación que tienen que distinguir a esa persona de los muchos que simplemente añadieron «IA» a un título de producto. Es una de las cinco de nuestra serie sobre los puestos que la IA creó, junto con el ingeniero de IA, el ingeniero de prompts, el ingeniero de agentes de IA y el responsable de gobernanza de IA.

¿Qué hace realmente un product manager de IA?

Un product manager de IA ejecuta el mismo ciclo de descubrimiento a lanzamiento que cualquier product manager, pero el medio del ciclo se ve diferente porque la funcionalidad que está lanzando no se comportará igual dos veces. Su semana es menos «escribe la especificación» y más «decide qué cuenta como suficientemente bueno, y diseña para los momentos en que no lo es». Concretamente, el día a día tiende a parecerse a esto:

• Definir el ámbito de lo que el modelo debe y no debe intentar —trazando la línea entre los casos en que una respuesta generada es genuinamente útil y los casos en que es demasiado arriesgada o poco fiable para lanzar.
• Definir los criterios de evaluación de la funcionalidad: qué significa «buena salida» en términos concretos y verificables, y cómo sabrá el equipo si un cambio mejoró las cosas o las empeoró silenciosamente.
• Fijar y mantener un umbral de calidad para la salida no determinista —decidiendo qué es suficientemente bueno para lanzar, dado que ninguna versión será nunca perfecta.
• Tomar decisiones de construir-o-comprar sobre modelos: usar un modelo de terceros, ajustarlo o construir algo internamente, sopesando coste, latencia, control y la rapidez con que avanza la frontera.
• Ser dueño de los controles de seguridad y la experiencia de escalado —qué hace el producto cuando el modelo es incierto o se equivoca, y cómo llega un usuario a un ser humano o a un valor predeterminado seguro en lugar de un error con apariencia de certeza.
• Traducir los límites del modelo en honestidad en el roadmap —decirle a los stakeholders qué no puede hacer aún el modelo genuinamente, en lugar de prometer una demo que falló a la tercera vez que se ejecutó.

Fíjate en lo poco que aparece «usar bien el prompt del modelo». El prompt es un medio; el trabajo es el juicio sobre un sistema probabilístico. Esa distinción importa enormemente cuando empiezas a evaluar candidatos, porque el mercado está lleno de personas que pueden hacer una demo de un prompt ingenioso y muchas menos que pueden decirte, con la cara seria, cuándo la funcionalidad debería negarse a responder.

¿Por qué existe este puesto ahora?

Porque lanzar sobre un modelo resultó ser un oficio diferente, no una variación del anterior. Un flujo de pagos o carga la tarjeta o no lo hace; puedes escribir criterios de aceptación que pasan o fallan. Un modelo de lenguaje puede darte dos respuestas diferentes a la misma entrada, una de ellas sutilmente incorrecta, ambas fluidas. Esa única propiedad se propaga hacia todo lo que hace este puesto. No puedes escribir una especificación fija para un comportamiento que no puedes predecir, así que escribes criterios de evaluación en su lugar. No puedes prometer que una funcionalidad funciona, así que razonas sobre la frecuencia con que lo hace y lo que cuestan los fallos. Nada de eso aparece en la lista de verificación de cómo contratar a un product manager —y ese es el punto—. Ahora es un trabajo. Cubrimos el cambio más amplio en la contratación AI-native; el product manager de IA es uno de sus ejemplos más nítidos.

¿Lo necesitas realmente?

A menudo, no —y un buen candidato para el puesto te lo dirá antes de que termines el pitch—. Añadir una única llamada de modelo detrás de una funcionalidad existente no requiere una contratación dedicada; tu product manager actual, con un ingeniero capaz, puede gestionarlo perfectamente. Recurrir a un especialista demasiado pronto es un modo de fallo real: suele terminar con una persona cara gestionando una funcionalidad que no la necesitaba y aburriéndose.

Realmente lo necesitas cuando el componente probabilístico pasa de guarnición a plato principal —cuando la salida del modelo es central para el valor del producto, y el coste de que se equivoque con seguridad es lo suficientemente alto como para que alguien deba ser propietario de ese modo de fallo como su trabajo real—. Un copiloto de soporte que redacta reembolsos, un agente que archiva tickets, un resumidor del que dependen los abogados: esos necesitan un propietario que piense en las tasas de error de manera profesional. Un botón de «resumir esto» añadido a una página de configuración no lo necesita. Si no estás seguro de cuál tienes, esa incertidumbre es en sí misma la respuesta —empieza con tu product manager actual y contrata al especialista cuando las decisiones de juicio empiecen a acumularse—.

¿Qué distingue a un buen product manager de IA de uno rebautizado?

Todos estos títulos atraen CVs rebautizados, y este los atrae en grandes cantidades. El impostor clásico aquí es el product manager que lanzó un chatbot, añadió «IA» al título y ahora se presenta como especialista. Lanzar un chatbot no es poco —pero no es evidencia de la habilidad que importa, y la entrevista tiene que estar construida para distinguir a los dos—. Así es como se ve lo real:

• Alfabetización en evaluación —la señal más fuerte. ¿Puede definir qué significa «buena salida» para una funcionalidad, en términos suficientemente concretos para medirlos? Un candidato rebautizado habla de que el modelo es «preciso»; el verdadero especialista te dice qué significa preciso para esta tarea, cómo lo muestrearías y cómo detectarías una regresión antes de que lo hagan los usuarios.
• Juicio sobre cuándo no usar un modelo —saber qué problemas son el modelo incorrecto para resolver, y estar dispuesto a decir que una regla determinista o un formulario sencillo serviría mejor a los usuarios. El impostor llega al modelo de forma reflexiva; el candidato fuerte lo usa de forma selectiva.
• Comodidad al razonar sobre tasas de error con stakeholders —sentarse frente a un directivo no técnico y explicar, sin ambigüedades, que la funcionalidad es correcta la mayoría de las veces y aquí está el plan para el resto. Aquí es donde se desmorona la mayoría de los candidatos rebautizados, porque es incómodo y específico.
• Sentido del diseño de controles de seguridad y escalado —tratar «qué pasa cuando el modelo se equivoca» como trabajo central de producto, no como un caso límite a archivar después.
• Honestidad en el roadmap —describir qué no puede hacer aún el modelo genuinamente, en lugar de lo que una demo seleccionada sugería que podría.

Notarás que las matemáticas profundas de machine learning no están en esa lista. Son útiles, y para algunos productos importan, pero no es lo que distingue a los fuertes de los débiles. Muchos excelentes product managers de IA no podrían derivar una función de pérdida para salvar sus vidas. Lo que sí pueden hacer es acotar un problema probabilístico, mantener un umbral de calidad bajo presión y razonar honestamente sobre los fallos —y eso es una habilidad de producto, no de investigación—.

¿Cómo se ponen a prueba esas habilidades?

Las evalúas de la misma manera que evaluarías cualquier habilidad real: con trabajo con forma real, no con preguntas triviales. Las preguntas de entrevista sobre arquitectura de transformers te dicen si alguien estudió de memoria; no dicen nada sobre si esta persona puede mantener un umbral de calidad. Dales el trabajo real y observa cómo lo hacen —tres ejercicios cubren la mayor parte de la señal, cada uno mapeado a una de las habilidades anteriores—. Ejecútalos con herramientas de IA genuinamente disponibles, porque así se hace el trabajo. Esta es la misma lógica de «muéstrame, no me digas» detrás de las pruebas de muestra de trabajo.

1. Escribe los criterios de evaluación para una funcionalidad

Dales una funcionalidad de IA plausible —digamos, un copiloto que redacta respuestas a correos electrónicos de clientes— y pídeles que escriban los criterios de evaluación: qué significa «buena salida» aquí, cómo lo medirían y cómo detectarían una regresión cuando el modelo cambie por debajo de ellos. Este es el ejercicio de mayor señal del proceso. Un candidato fuerte produce criterios concretos y verificables y nombra los modos de fallo que importan para esta tarea específica. Uno rebautizado produce adjetivos vagos y espera que asienta.

2. Gestionar una incidencia de alucinación

Dales un escenario: tu funcionalidad lanzada acaba de decirle a un cliente algo falso con seguridad, y está en redes sociales. ¿Qué harías en la próxima hora, al día siguiente, en el próximo sprint? Observa si pueden separar la mitigación inmediata de la corrección sistémica, si razonan sobre la frecuencia con que sucede esto en lugar de tratarlo como algo puntual, y si piensan en el usuario afectado, no solo en la métrica. Este ejercicio revela el pensamiento sobre controles de seguridad y el razonamiento sobre tasas de error al mismo tiempo.

3. Decidir una decisión modelo-frente-a-reglas

Presenta un problema que podría resolverse con un modelo o con reglas deterministas —enrutar un ticket de soporte, por ejemplo— y pídeles que tomen y defiendan la decisión. El punto no es la respuesta; es el razonamiento. Un candidato fuerte sopesa el coste del error, la carga de mantenimiento, la explicabilidad y el modo de fallo de cada opción, y a veces llega a «no uses un modelo aquí en absoluto». Esa disposición es la clave. Conecta directamente con la fluidez en IA como señal de contratación —saber cuándo no usar la herramienta es la mitad de la fluidez—.

Ejecutar estas observadas, con herramientas de IA en la sala, es donde aterriza nuestra propia perspectiva. El AI Sandbox está construido para poner a un candidato en un entorno realista con esas herramientas disponibles y dejarte observar el proceso, no solo leer el artefacto —que es, admitidamente, exactamente lo que diría un proveedor—. Lo que estás calificando es el juicio bajo no-determinismo, y solo puedes ver el juicio observando a alguien ejercerlo. Para el marco detrás de leer esas señales con claridad, cómo evaluar la fluidez en IA y el Marco 4D hacen el trabajo pesado; Delegation y Discernment tienen más peso para este puesto.

¿Cómo es el proceso de entrevistas?

Mantenlo estructurado y corto. Una tarjeta de puntuación compartida, los mismos ejercicios para cada candidato en un nivel dado, y un debate que discute sobre evidencias en lugar de intercambiar primeras impresiones —esa disciplina es lo que hace la decisión justa y justificable, y aquí importa más de lo habitual porque «parecía entender realmente la IA» es exactamente el tipo de intuición que oculta un CV rebautizado. Lee entrevistas estructuradas para la mecánica. Un proceso que funciona:

• Preselección de reclutador —confirmar alcance y seniority, y explorar una vez: pídeles que describan una funcionalidad de IA que poseyeron y qué significaba «bueno» para ella. La respuesta ordena el campo rápidamente.
• Muestra de trabajo sobre criterios de evaluación —el ejercicio anterior, realizado como trabajo observado con IA disponible, puntuado con una rúbrica compartida.
• Entrevista multifuncional —un ingeniero de ML o aplicado sondea el razonamiento de construir-o-comprar y modelo-frente-a-reglas; un compañero de diseño sondea la experiencia de controles de seguridad y escalado.
• Entrevista de comunicación con stakeholders —alguien no técnico, idealmente, comprueba si el candidato puede explicar tasas de error y honestidad en el roadmap sin esconderse detrás de la jerga.
• Debate frente a la tarjeta de puntuación —cada entrevistador trae evidencia vinculada a las dimensiones anteriores, y decides sobre el conjunto, no sobre la voz más alta en la sala.

Seniority y compensación, honestamente

No inventaremos números —los rangos de mercado para este puesto cambian demasiado rápido para citarlos de forma responsable—. Cualitativamente: porque el puesto combina el juicio de producto clásico con una habilidad más nueva y escasa, tiende a situarse en el nivel del product manager clásico equivalente o por encima, con una prima de escasez que es real pero se está enfriando a medida que la habilidad se extiende. La seniority rastrea las apuestas del componente probabilístico más que los años de experiencia. Compara con tu propio mercado y da más peso a la alfabetización en evaluación demostrada que a la inflación de títulos —en este puesto los títulos son especialmente ruidosos—.

Los primeros 90 días: qué tiene buen aspecto

Un buen product manager de IA pasa su primer mes haciendo algo sin glamour: siendo honesto sobre cómo se comporta realmente la funcionalidad existente. Eso significa construir o arreglar la configuración de evaluación para que el equipo pueda saber si un cambio ayudó, y sentarse con casos de fallo reales en lugar de la demo. A los 90 días, «bueno» se parece a un equipo con una definición concreta y compartida de «buena salida» para su funcionalidad principal, una historia de controles de seguridad y escalado para cuando el modelo se equivoca, y un roadmap en el que los stakeholders confían porque fue honesto sobre los límites desde el principio. Si en cambio tienes un aluvión de nuevas demos y no tienes más claro si la cosa funciona, contrataste al piloto de demos —y lo notarás en el segundo trimestre—.

Este puesto no es product management clásico con una mano de pintura, y tampoco es investigación de machine learning. Es un oficio específico: ser propietario de una funcionalidad que se comporta probabilísticamente, definir qué significa bueno cuando la salida no se estabiliza, y ser honesto —con los usuarios, los stakeholders y contigo mismo— sobre dónde el modelo se queda corto. Contrata para eso, evalúalo con trabajo con forma real, y está dispuesto a concluir que todavía no necesitas el puesto.