Entrevista para un rol transversal de IA: producto, BA, UX

Una entrevista para un rol de producto, análisis funcional o diseño en un tema de IA rara vez se decide por los conocimientos técnicos y, sin embargo, ahí se concentra casi siempre la preparación. La persona repasa el vocabulario, aprende la diferencia entre fine-tuning y RAG, y luego se atasca en una pregunta de encuadre que habría resuelto en cualquier otro proyecto.

Conocer el vocabulario no es el error: es útil. El error es creer que la evaluación va de eso. En estos roles, la entrevista busca saber si sabes decidir en un contexto donde el sistema es probabilístico, donde la calidad se mide en lugar de constatarse y donde el fallo debe preverse desde el diseño.

Qué evalúa realmente la entrevista

Cuatro capacidades se repiten, sea cual sea la empresa. Casi nunca se anuncian como tales, pero cada pregunta seria pone a prueba al menos una.

1. 1

   Encuadrar un problema

   1

   Saber formular la necesidad antes que la solución y reconocer un caso en el que la IA no es la herramienta adecuada. Una respuesta que salta directamente a una arquitectura descalifica más de lo que tranquiliza.

2. 2

   Razonar en la incertidumbre

   2

   Aceptar que un sistema puede equivocarse y diseñar en consecuencia: qué error es tolerable, cuál no, quién verifica y en qué momento.

3. 3

   Definir qué significa «bueno»

   3

   Traducir una expectativa de negocio en un criterio observable. Es la capacidad más discriminante y la que más falta.

4. 4

   Trabajar con ingeniería

   4

   Hacer preguntas útiles, entender una restricción sin discutirla a ciegas y arbitrar sin pretender decidir en lugar del equipo técnico.

Ninguna de estas cuatro capacidades exige escribir código. Todas exigen haber pensado en un sistema que no siempre da la respuesta correcta.

El nivel técnico esperado y su límite

Se espera que entiendas las grandes familias de enfoques, lo que implican en datos, coste y plazo, y lo que no resuelven. No se espera que elijas una arquitectura ni que discutas la implementación.

Las preguntas recurrentes y qué buscan

• «¿Cómo decidirías si este caso de uso merece IA?»: se evalúa tu capacidad de decir no y de nombrar una alternativa más simple.
• «¿Cómo sabrías que funciona?»: se espera un criterio observable, una población de casos y un umbral, no una impresión.
• «¿Qué haces con los errores del sistema?»: se evalúa si diseñas un recorrido que asume el error en vez de ignorarlo.
• «¿Cómo priorizas entre calidad y plazo?»: se busca un arbitraje asumido, con la consecuencia aceptada nombrada.
• «¿Cómo trabajas con ingeniería?»: sobre todo se escucha cómo hablas de un desacuerdo pasado.
• «¿Qué te sorprendió en un proyecto de IA?»: se comprueba que has vivido uno de verdad, a cualquier escala.

Qué busca la entrevista en un perfil de producto o PO

En un producto de IA, la entrevista de producto no va de implementación: va de cómo eliges un caso de uso, cómo defines qué significa «bueno» y cómo decides cuando la calidad nunca está garantizada. La pregunta más discriminante sigue siendo la de la renuncia: saber decir que un caso no merece IA, o que una regla de negocio bastaría, tranquiliza más que una hoja de ruta ambiciosa.

• La elección del caso de uso: qué problema de usuario o de negocio existe ya y por qué ese y no otro.
• El valor esperado, formulado de otro modo que «ahorrar tiempo»: qué cambia concretamente para quien hace hoy ese trabajo.
• La definición de calidad: qué es una buena respuesta, quién la juzga y a partir de qué umbral la funcionalidad resulta útil.
• Métricas adaptadas al caso, en lugar de una exactitud global tomada de otro contexto.
• La priorización y el arbitraje entre calidad, coste y latencia, con el compromiso asumido y explicado.
• Las dependencias con los equipos de datos e ingeniería: qué necesitas pedirles y en qué momento.
• La decisión de lanzar, de reducir el alcance o de parar, y las señales que la desencadenan.
• La capacidad de concluir que la IA no es la solución adecuada, nombrando la alternativa.

Nadie espera que un perfil de producto elija una arquitectura. Se espera encuadre, priorización y arbitraje en un contexto probabilístico, y después saber explicar ese compromiso a un equipo técnico.

Qué busca la entrevista en un perfil funcional, BA o de consultoría

La entrevista funcional se juega en la descomposición. Reformular «negocio quiere un chatbot» no es un análisis: es repetir una solución ya elegida. Lo que se observa es tu capacidad de remontar de la necesidad expresada al proceso real y de volver a bajar hacia criterios de aceptación que alguien pueda verificar.

• El proceso existente: qué ocurre hoy, paso a paso, antes de cualquier idea de solución.
• Los actores: quién hace qué, quién valida, quién asume el error cuando se produce.
• Los datos necesarios, su disponibilidad real, su frescura y su calidad conocida.
• Las excepciones: los casos raros que suelen concentrar la mayor parte de la carga y de los litigios.
• Los permisos: quién puede ver qué y qué implica eso cuando un asistente devuelve información.
• Las dependencias y los riesgos, incluidos los no técnicos: regulación, subcontratación, calendario.
• Los criterios de aceptación, escritos de forma verificable, incluso para los casos en los que el sistema debe negarse a responder.
• La integración en el funcionamiento real y la adopción: en qué momento del día se usa la herramienta y quién la usa.

La cadena esperada es siempre la misma: problema → proceso → actores → datos → reglas → excepciones → resultado esperado → criterios de aceptación. No cubre las responsabilidades del AI Engineer, y no debe hacerlo.

Qué busca la entrevista en un perfil de UX, research o diseño

Diseñar una experiencia de IA no consiste en añadir una conversación a la interfaz. El sistema puede fallar de forma plausible, producir una respuesta falsa pero convincente y variar de una ejecución a otra. La entrevista observa cómo diseñas para esa inestabilidad en lugar de darla por inexistente.

• El modelo mental del usuario: qué cree que el sistema puede hacer y la distancia con lo que hace realmente.
• La confianza apropiada: ni desconfianza que lleva a abandonar la herramienta, ni confianza ciega en una respuesta falsa.
• La representación de la incertidumbre, cuando ayuda a decidir en lugar de decorar la pantalla.
• El tratamiento de los errores plausibles: qué ve el usuario cuando la respuesta es fluida e incorrecta.
• Los fallbacks: qué ocurre cuando el sistema no sabe, y por qué es un momento de diseño en sí mismo.
• La corrección y la recuperación: poder señalar, corregir, deshacer o devolver el control a una persona.
• El nivel de control que se deja al usuario y los puntos en los que hace falta una confirmación explícita.
• La transparencia útil: lo que realmente ayuda a juzgar una respuesta, más allá de una explicación decorativa.
• La investigación con usuarios en un sistema no determinista: observar sesiones reales, comparar variantes y medir la confianza y el uso en lugar de la satisfacción declarada.

El human-in-the-loop no es un parche añadido al final. Es una decisión de diseño que determina dónde recupera el control el usuario, a qué coste de atención y qué hace el sistema con esa corrección.

Un caso transversal para situar las tres perspectivas

El escenario siguiente es ficticio y pedagógico; no describe ninguna empresa ni ningún proyecto real. Una organización quiere añadir un asistente de IA a un proceso interno: las personas podrían buscar información dispersa en varios repositorios documentales y obtener ayuda para preparar ciertas tareas de negocio recurrentes. No todos los documentos están actualizados, no todo el mundo tiene acceso a los mismos recursos y parte de las preguntas tratará sobre casos particulares poco documentados.

1. 1

   Producto / PO

   valor

   Qué problema merece realmente resolverse, para qué población y con qué alcance empezar. Cómo decidir que el resultado es suficientemente útil para ampliarlo y qué arbitrajes aceptar entre cobertura, coste y tiempo de respuesta.

2. 2

   Funcional / BA / consultoría

   proceso

   Qué proceso se modifica, quién hace qué hoy, qué datos y qué reglas intervienen, qué permisos deben respetarse, qué excepciones deben seguir en manos de una persona y cómo se inserta el asistente en el funcionamiento real.

3. 3

   UX / research / diseño

   uso

   Cómo entiende el usuario lo que el asistente puede y no puede hacer, qué ocurre cuando se equivoca, cuándo pedir confirmación, cuándo permitir la recuperación humana y cómo observar la confianza y el uso real en lugar del entusiasmo inicial.

Los equipos de ingeniería y datos siguen siendo socios del escenario: son quienes harán viables la recuperación documental, los derechos de acceso y la frescura de los contenidos. Lo que se espera de un perfil de producto, funcional o UX no es hacer ese trabajo, sino discutir sus restricciones sin apropiárselas.

Conectar el caso con las preguntas de la entrevista

Un mismo escenario permite responder a la mayoría de las preguntas esperadas, siempre que se despliegue un razonamiento en lugar de recitar una respuesta: hipótesis, preguntas que harías, arbitrajes considerados y, después, una decisión asumida.

• «¿Cuándo no elegirías IA?»: cuando los documentos de referencia son pocos y estables; un buscador y una limpieza del repositorio cuestan menos y fallan de forma más legible.
• «¿Cómo sabrías si es suficientemente bueno?»: construyendo un conjunto de preguntas reales del proceso, definiendo qué es una respuesta aceptable con quienes hacen el trabajo y fijando el umbral antes del lanzamiento.
• «¿Qué haces si los usuarios creen respuestas incorrectas?»: tratarlo como un problema de diseño y de medición: hacer visible la fuente, degradar la presentación cuando la respuesta es débil y observar las correcciones más que las opiniones.
• «¿Cómo definirías con ingeniería criterios evaluables?»: aportando los casos y la definición de negocio del resultado esperado, dejando el método de medición al equipo y acordando juntos qué bloquea una puesta en producción.
• «¿Qué habría que observar tras el lanzamiento?»: el uso real por población, las preguntas sin respuesta, las correcciones humanas, las diferencias entre confianza mostrada y exactitud, y qué cambió realmente en el proceso.

Apoyar tus respuestas en un caso vivido

La respuesta más sólida no es la más general: es la que se apoya en una situación real, descrita con su restricción y su decisión. Un taller de encuadre interno, un piloto abandonado o una evaluación manual sobre cincuenta casos bastan, si se cuentan con honestidad.

1. 1

   El contexto

   situar

   Qué problema, para quién y con qué restricción real: plazo, datos, regulación, adopción.

2. 2

   Tu rol exacto

   aclarar

   Qué decidiste tú y qué decidieron otros. La precisión en este punto es una señal de fiabilidad.

3. 3

   La dificultad

   asumir

   Qué no funcionó a la primera y cuánto costó.

4. 4

   La decisión

   decidir

   Qué arbitraste, sobre qué base y qué aceptaste perder.

5. 5

   Qué harías distinto

   cerrar

   Una reflexión, no una autocrítica de fachada.

Tres trampas frecuentes

La primera es hablar del modelo en lugar del problema: el detalle técnico sustituye entonces al razonamiento de producto. La segunda es prometer una medición imposible, como una tasa de acierto en un tema donde nadie sabe definir la respuesta correcta. La tercera es presentar un trabajo colectivo como propio: la pregunta de seguimiento llega casi siempre y la distancia se nota de inmediato.

Decir «esa parte la llevaba el equipo de datos, mi aportación fue el encuadre y la evaluación» no resta valor a una respuesta. Es lo que la hace verificable.

Preguntas que conviene hacer al final

• ¿Cómo medís hoy la calidad de lo que ya está en producción?
• ¿Quién decide cuando la calidad percibida y la medición no coinciden?
• ¿Qué parte del trabajo es exploración y qué parte es industrialización?
• ¿Cómo se reparten las decisiones los roles de producto, funcional y UX con los equipos de ingeniería y datos?
• ¿Qué caso de uso se abandonó recientemente y por qué?

La última es la más informativa. Una empresa que sabe nombrar un caso de uso abandonado tiene un proceso de decisión; una que no tiene ninguno probablemente aún no se ha topado con la restricción de la producción.

• Entrevista
• Producto IA
• Encuadre