Se está abriendo una brecha en el AI product management de la que nadie habla. En un lado, tienes a tecnólogos que entienden arquitecturas transformer y prompt engineering pero nunca han operado los procesos de negocio que automatizan. En el otro, operadores que entienden el negocio a fondo pero ven la IA como una caja negra que necesitan "adoptar". Los mejores productos de IA no los construirá ninguno de los dos grupos. Los construirán operadores que cruzaron la brecha técnica.
Lo sé porque viví la transición. Pasé siete años como la persona en la silla de operaciones: gestionando €2.000M en cuentas por cobrar, cuadrando flujos de caja en 10 países, construyendo la infraestructura de datos que soportó €1.300M en fundraising. Después pasé a AI product management. La diferencia en cómo diseño productos de IA comparado con alguien que viene de tech o PM puro no es sutil. Es fundamental.
La brecha de conocimiento que mata productos de IA
La mayoría de AI PMs que trabajan en automatización financiera nunca han cuadrado un extracto bancario. Nunca se han quedado mirando un pago que no encaja con ninguna factura intentando averiguar por qué. Nunca han explicado a un CFO a las 9 de la noche por qué la posición de caja de mañana es €3M inferior a la previsión.
Esto importa más de lo que debería.
Cuando diseñas un agente de IA para aplicación de pagos sin experiencia operativa, te centras en lo obvio: casar el importe del pago con el importe de la factura. Matching 1:1. Eso cubre quizás el 60% de los casos. Pero el 40% restante es donde está todo el valor, y donde los tecnólogos puros fallan.
Un cliente paga €47.250 contra una factura de €47.500. ¿Es un pago parcial? ¿Un descuento aplicado? ¿Una comisión bancaria deducida? ¿Un redondeo de divisa? La respuesta depende del historial del cliente, los términos de pago, las normas bancarias del país, y si tu equipo comercial ofreció un descuento informal que nadie documentó. Un operador sabe revisar todo esto. Un tecnólogo construye una tolerancia de ±1% y lo da por terminado. Un enfoque resuelve el 95% de las excepciones. El otro crea una cola permanente de partidas sin resolver que crece cada mes.
Tres cosas que ven los operadores y los tecnólogos pasan por alto
1. El flujo de trabajo detrás del flujo de trabajo
Todo proceso tiene una versión oficial y una versión real. La versión oficial vive en la documentación de procesos. La versión real vive en la cabeza de las personas que hacen el trabajo.
Cuando gestioné cobros en 10 países, el proceso oficial era: enviar recordatorio automático a 30 días de vencimiento, escalar a llamada telefónica a 60 días, enviar notificación formal a 90 días. Simple. Limpio. Y casi completamente equivocado en la práctica. En España, los primeros 30 días no significaban nada porque la mayoría de empresas pagaban a 60-90 por norma cultural. En el Reino Unido, una llamada en el día 45 era más efectiva que cualquier recordatorio automático. En Alemania, la notificación formal necesitaba referenciar cláusulas legales específicas o se ignoraba.
Si diseñas un agente de cobros basado en el proceso oficial, construyes un sistema que envía el mensaje equivocado, en el momento equivocado, por el canal equivocado, en todos los países. Los operadores conocen el flujo de trabajo real. Ese conocimiento es la diferencia entre un agente de IA que realmente reduce el DSO y uno que genera ruido.
2. Dónde mienten los datos
No "dónde están los datos". Dónde mienten.
Descubrí una discrepancia de €25M entre nuestro modelo de previsión y los cobros reales. Los datos eran técnicamente correctos: cada número en cada celda era preciso. Pero el modelo preveía cobros cuando debería haber previsto cash-in. Usaba una media simple de comportamientos históricos de cobro cuando los datos mostraban claramente patrones estacionales. Ignoraba los pagos parciales por completo.
La diferencia entre cobros y cash-in suena académica. No lo es. Cobros significa "el cliente ha aceptado pagar". Cash-in significa "el dinero ha llegado a nuestra cuenta bancaria". La distancia entre esos dos eventos puede ser de días o semanas, y varía por país, por segmento de cliente y por época del año. Un tecnólogo mirando los datos ve números. Un operador ve el proceso físico detrás de cada número y sabe qué transformaciones introducen distorsión.
3. La topología política del cambio
Construir un producto de IA dentro de una organización existente es tanto un ejercicio político como técnico. Cada proyecto de automatización amenaza el puesto de alguien, la expertise de alguien, o el imperio de alguien.
Cuando introduje agentes de IA junto a una plataforma enterprise de tesorería, los posicioné como complementarios: la plataforma gestiona la automatización estructurada, los agentes gestionan las excepciones no estructuradas. Esto no era solo posicionamiento de producto; era estrategia de supervivencia. El equipo que controlaba la plataforma enterprise tenía presupuesto, headcount y sponsorship ejecutivo. Posicionar los agentes de IA como un reemplazo habría activado anticuerpos organizacionales que habrían matado la iniciativa antes de lanzarla.
Los operadores entienden la física organizacional. Saben qué stakeholders necesitan sentir ownership, qué métricas importan a qué directivo, y cómo secuenciar un lanzamiento para que las victorias tempranas generen impulso para un despliegue más amplio. Esto no está en ningún currículo de PM. Se aprende navegando organizaciones reales con política real.
El framework del operador para diseño de productos de IA
Basándome en mi experiencia construyendo productos de IA para tesorería, este es el framework que uso:
Paso 1: Mapear el proceso real. No el documentado. El que ocurre a las 11 de la noche cuando cierra el trimestre y nadie sigue el playbook. Ese es el proceso que tu IA necesita gestionar.
Paso 2: Identificar los puntos de juicio. ¿Dónde aplican los humanos actualmente conocimiento contextual? Esas son tus oportunidades de IA, no los pasos mecánicos.
Paso 3: Diseñar para la excepción, no para la regla. La regla ya la automatiza el software existente. El valor de tu agente de IA reside enteramente en cómo maneja lo que los sistemas existentes no pueden.
Paso 4: Construir niveles de confianza, no decisiones binarias. Un agente de IA que dice "Estoy un 92% seguro de que este es un pago parcial de las facturas #4521 y #4523, descontando la nota de crédito del Q3" es útil. Uno que dice "casado" o "no casado" no lo es.
Paso 5: Instrumentar todo. Necesitas saber no solo qué decidió el agente, sino por qué. Cuando se equivoca, necesitas trazar hacia atrás hasta el paso de razonamiento específico que falló. Aquí es donde la experiencia operativa te dice cuáles serán los modos de fallo comunes antes de lanzar.
Por qué esta brecha es una oportunidad profesional
La oferta de AI PMs que entienden arquitecturas transformer crece rápidamente. Cada bootcamp, cada curso online, cada certificación de "AI Product Management" los produce por miles.
¿La oferta de AI PMs que realmente han operado los procesos que automatizan? Es minúscula. Porque requiere años de experiencia en el dominio seguidos de una transición técnica deliberada. No hay atajos.
Solo en tesorería, estimo que hay menos de 50 personas en Europa con experiencia operativa profunda en operaciones financieras que además tengan capacidad real de diseño de productos de IA. No awareness de IA. No "uso ChatGPT". La capacidad de diseñar una arquitectura de agentes, definir workflows de tool-calling, especificar umbrales de confianza, y lanzar un producto que gestione excepciones del mundo real a escala.
Si eres un operador considerando el salto a AI PM, la ventana es ahora. La tecnología es lo suficientemente madura para construir productos reales. El mercado está hambriento de aplicaciones de IA específicas de dominio. Y la ventaja competitiva que aportas, la profundidad operativa, es lo único que no se puede replicar haciendo un curso.
Los mejores productos de IA los construirán personas que han operado los sistemas que están reemplazando. No tecnólogos adivinando problemas de negocio, ni operadores con miedo a la tecnología. La intersección es donde está el valor.
La pregunta es: ¿en qué lado de la brecha estás, y estás dispuesto a cruzarla?