Product Owner en la era de la IA: ¿qué competencias se vuelven indispensables?

Qué cambia realmente en el puesto

Un Product Owner que trabaja en un producto con un componente de IA no cambia de oficio: sigue siendo responsable del valor para el usuario, del backlog, de los arbitrajes y de la relación con las partes interesadas. Lo que cambia es la naturaleza de aquello que pilota. Una funcionalidad clásica se describe con reglas: ante esta entrada, el sistema devuelve exactamente eso. Una funcionalidad basada en un modelo de lenguaje o en un sistema de recomendación produce un comportamiento, no una regla. Dos formulaciones parecidas pueden dar respuestas distintas, y la misma formulación puede funcionar hoy y fallar mañana porque el contexto recuperado ha cambiado.

La consecuencia es concreta: ya no basta con validar una funcionalidad probándola una vez. El PO debe describir qué se espera de media, qué resulta inaceptable en cualquier caso y qué debe ocurrir cuando el sistema se equivoca. Es una competencia de especificación y evaluación, no de ingeniería.

El PO no necesita entrenar modelos ni leer código de inferencia. Necesita formular un problema, definir qué significa responder bien y decidir cuánto error puede absorber el negocio.

Encuadrar el caso de uso antes de hablar de modelos

La petición casi nunca llega como problema: llega como solución. «Queremos un asistente», «queremos resumir los tickets», «queremos un agente que gestione las solicitudes». El primer trabajo del PO es retroceder un paso: qué decisión o tarea humana se quiere acelerar, quién la hace hoy, con qué frecuencia y qué pasa si se hace mal.

• Qué tarea concreta se persigue y en qué momento del recorrido aparece.
• Quién es el usuario real: cliente final, agente, operador interno.
• Qué resultado se espera: un texto, una clasificación, una sugerencia, una acción.
• Qué cuesta un error: tiempo perdido, decisión equivocada, riesgo contractual.
• Qué alternativa ya existe y por qué no es suficiente.

Este encuadre condiciona todo lo demás. Un asistente de redacción interno cuya salida siempre se revisa tolera un nivel alto de imperfección. Un sistema que envía la respuesta directamente al cliente no lo tolera. No es una cuestión de modelo, es una cuestión de responsabilidad.

Definir el valor para el usuario, no la proeza técnica

Muchas funcionalidades de IA se lanzan porque son posibles, no porque sean útiles. El PO sigue siendo el garante de la pregunta de valor: qué podrá hacer el usuario después de la puesta en producción que antes no podía, y cómo se verá. La respuesta debe ser observable: un plazo más corto, un paso eliminado, una información encontrada sin cambiar de herramienta, una decisión documentada antes.

Un indicador de valor no equivale a un indicador de calidad del modelo. El segundo mide el comportamiento del sistema; el primero mide el efecto sobre el trabajo real. Un sistema puede tener buenas métricas internas y no usarse nunca, porque llega tarde en el recorrido o porque el usuario no confía en él.

De los criterios de aceptación a los criterios evaluables

Un criterio de aceptación clásico es binario: la funcionalidad lo cumple o no. Con un comportamiento probabilístico la pregunta cambia: sobre un conjunto representativo de casos, qué proporción de salidas es aceptable y según qué definición de aceptable. El PO no necesita métricas estadísticas, pero sí aportar la materia prima con la que se construyen: ejemplos reales, salidas esperadas y ejemplos de salidas inaceptables.

Construir un conjunto de pruebas y trabajar los casos límite

El conjunto de pruebas es el activo más duradero que un PO puede producir en un producto de IA. Sobrevive a los cambios de modelo, de prompt y de proveedor. Debe ser pequeño pero representativo: casos ordinarios, casos frecuentes y molestos, y casos límite elegidos por su consecuencia, no por su rareza.

• Casos nominales: lo que el sistema encontrará la mayor parte del tiempo.
• Casos ambiguos: información parcial, formulación vaga, petición contradictoria.
• Casos fuera de alcance: aquello a lo que el sistema debe negarse a responder.
• Casos sensibles: datos personales, compromisos contractuales, importes, salud, legal.
• Casos de regresión: los errores ya detectados, conservados para siempre.

Cada caso lleva una expectativa escrita en lenguaje de negocio. Esa colección, revisada con regularidad, es lo que permite al equipo técnico comparar dos versiones de forma objetiva.

Alucinaciones, respuestas incorrectas y calidad aceptable

Un sistema generativo puede producir una respuesta falsa formulada con seguridad. Es un comportamiento propio de este tipo de sistema, no un fallo aislado que se corrige una vez. El papel del PO es decidir, caso de uso a caso de uso, qué es absorbible y qué no, y después organizar el producto en torno a esa decisión.

• Error visible y corregible por el usuario: suele ser aceptable si corregirlo cuesta poco.
• Error invisible que se propaga a otro sistema: rara vez aceptable sin control.
• Error sobre un compromiso, un precio o una obligación legal: se evita por diseño, no con advertencias.

Existen tres palancas de producto antes de tocar el modelo: acotar el alcance de la funcionalidad, exigir que la respuesta cite su fuente y prever explícitamente el caso «no lo sé». Un sistema capaz de abstenerse casi siempre es más utilizable que uno que siempre responde.

Decidir dónde se sitúa el humano en el bucle

El human-in-the-loop no es una casilla, es una decisión de diseño con coste. Revisar cada salida protege la calidad pero suele anular el ahorro de tiempo. No revisar nada maximiza el ahorro pero traslada el riesgo al usuario final. Entre ambos extremos hay posiciones que el PO debe elegir de forma explícita: revisar solo lo marcado como incierto, revisar por muestreo, exigir validación únicamente antes de una acción irreversible.

Una buena pregunta de encuadre: «¿cuál es la última acción a partir de la cual el error se vuelve caro?». El control humano se coloca justo antes de esa acción, no en todas partes.

Arbitrar entre calidad, latencia y coste

En un producto de IA tres variables se mueven juntas. Una respuesta más fiable suele requerir más contexto, más pasos o un modelo más pesado: cuesta más y llega más tarde. Estos arbitrajes no son técnicos, son de producto. El PO debe poder decir en qué situación el usuario prefiere esperar y en cuál una respuesta imperfecta inmediata vale más que una respuesta perfecta tardía.

El coste merece tratarse como restricción de diseño desde el encuadre, igual que el rendimiento. Una funcionalidad cuyo coste unitario supera el valor que genera no escalará, por buena que fuera la demostración.

Datos, dependencias y trabajo con el equipo

Una funcionalidad de IA rara vez depende solo del modelo. Depende sobre todo de lo que se le entrega: documentos actualizados, alcance de permisos, frescura, estructura. Un PO que ignora el estado real de las fuentes se arriesga a descubrir tarde que el producto prometido no se puede alimentar.

• Qué fuentes se necesitan y quién es su responsable en la organización.
• Quién puede ver qué: un asistente nunca debe ampliar los permisos de un usuario.
• Con qué frecuencia cambian los datos y en qué se convierte una respuesta basada en una versión caducada.
• Qué trazas se conservan para poder explicar una respuesta a posteriori.

Frente al equipo de AI Engineering y Data, al PO le conviene separar lo que exige (comportamiento esperado, casos prohibidos, umbrales) de lo que no impone (arquitectura, elección de modelo, estrategia de recuperación de información). Esa frontera evita el peor escenario: imponer una solución técnica y seguir siendo responsable del resultado de negocio.

Caso concreto: una historia de usuario que no se sostiene

Un equipo de soporte quiere proponer una respuesta pre-redactada a sus agentes. Historia inicial: «Como agente, quiero que se me proponga una respuesta automáticamente para ganar tiempo. Criterio de aceptación: la respuesta propuesta es correcta.» Esta historia no es comprobable: «correcta» no está definido, no hay alcance, no hay comportamiento previsto ante la duda y nada dice qué ocurre si la respuesta se apoya en un procedimiento obsoleto.

La misma necesidad, encuadrada de otro modo, sí es utilizable:

• Alcance: solo consultas de seguimiento de pedido, en español, sobre pedidos de los últimos 90 días.
• Fuentes autorizadas: la base de procedimientos publicada y el estado del pedido; ninguna otra.
• Comportamiento esperado: la propuesta cita el procedimiento utilizado y el número de pedido.
• Abstención: si el estado no aparece o el procedimiento es ambiguo, el sistema propone una plantilla vacía y señala la incertidumbre en lugar de inventar.
• Prohibiciones: ningún compromiso de plazo, reembolso o gesto comercial en la propuesta.
• Control: la respuesta nunca se envía automáticamente; el agente valida o modifica.
• Evaluación: sobre 80 conversaciones reales anonimizadas, al menos 60 propuestas se envían con como máximo una corrección menor, y ninguna contiene un compromiso prohibido.
• Seguimiento: uso real, tasa de reescritura profunda, incidencias reportadas por los agentes.

Nada de esto exige competencia técnica. Todo es trabajo de producto: alcance, fuentes, comportamiento ante la duda, prohibiciones, control y medición. Es exactamente lo que un equipo de IA espera de un PO.

Del POC a una funcionalidad realmente explotable

Una demostración lograda prueba que un comportamiento es posible sobre unos pocos ejemplos elegidos. Una funcionalidad explotable supone otra cosa: comportamiento estable sobre casos no elegidos, tratamiento de errores, traza de decisiones, coste controlado y un equipo capaz de hacerla evolucionar. Ese salto es donde se detienen muchos proyectos de IA, casi siempre porque no se anticipó en el encuadre.

Después de la puesta en producción

Un producto de IA se degrada sin que nadie toque el código: los usos derivan, los documentos cambian, los usuarios formulan de otra manera. El seguimiento posterior forma parte del alcance del PO, igual que el backlog.

• Uso real: quién usa la funcionalidad, con qué frecuencia y quién la ha abandonado.
• Incidencias: una vía sencilla para reportar una respuesta problemática, revisada con regularidad.
• Reevaluación: relanzar el conjunto de pruebas ante cada cambio de modelo, prompt o fuente.
• Coste: coste por uso y su evolución con el volumen.
• Decisiones: qué se cambió, cuándo y con qué efecto observado.

Las preguntas que un PO debe saber hacer

• ¿En qué datos se apoya la respuesta y cómo se seleccionan?
• ¿Qué hace el sistema cuando no encuentra la información?
• ¿Cómo sabremos que una versión nueva es mejor que la actual?
• ¿Qué casos hemos decidido no tratar y es visible para el usuario?
• ¿Cuánto cuesta una llamada y cómo evoluciona si el uso se duplica?
• ¿Cuánto tarda una respuesta en el peor caso, no de media?
• ¿Qué podemos explicar a un usuario que impugna una respuesta?
• ¿Qué parte del comportamiento depende de un proveedor externo y qué pasa si cambia?

Estas preguntas no sirven para controlar al equipo técnico: sirven para hacer explícitas decisiones que, de otro modo, se toman de forma implícita y se descubren en producción.

• Producto IA
• Encuadre de casos de uso
• Evaluación