No necesitas entender backpropagation para trabajar con IA generativa, pero sí necesitas entender por qué miente con tanta seguridad. Los equipos de producto que integran LLMs sin ese conocimiento básico terminan diseñando flujos que amplifican exactamente los fallos más peligrosos del modelo. Este artículo cubre lo mínimo indispensable que un Product Owner y su equipo deben saber antes de tomar cualquier decisión de diseño con un modelo de lenguaje.
Cómo funciona un LLM (lo que importa para producto)
Un modelo de lenguaje predice el siguiente token más probable dado todo el contexto anterior. No busca en una base de datos, no razona paso a paso por defecto, no tiene memoria entre sesiones a menos que se le provea explícitamente. La ventana de contexto es la cantidad de texto que el modelo puede «ver» a la vez. Todo lo que está fuera de esa ventana no existe para él. Diseñar un flujo que asuma memoria ilimitada es diseñar un flujo que se rompe en producción.
Alucinaciones, temperatura y confianza sin fundamento
Las alucinaciones no son bugs: son el comportamiento esperado de un sistema que predice texto plausible sin verificar hechos. La temperatura controla cuánta aleatoriedad se inyecta: temperatura cero produce respuestas más deterministas; temperaturas altas producen respuestas más creativas pero menos confiables. Para workflows de producto que requieren precisión, la temperatura debe ser baja y el output verificable por el sistema.
«Un LLM no sabe lo que no sabe. Por eso el diseño del workflow importa más que la capacidad del modelo.»
Qué puede y qué no puede hacer la IA de forma confiable
Los LLMs son excepcionalmente buenos en transformación de texto con estructura conocida: resumir, reformatear, clasificar, generar borradores bajo plantillas rígidas. Son poco confiables para aritmética exacta, razonamiento causal complejo y hechos factuales sin fuente en el contexto.
Diseñar workflows que aprovechen las fortalezas
La clave es insertar la IA donde su output es verificable y el coste del error es recuperable. Define siempre: ¿qué pasa cuando el modelo se equivoca? Si la respuesta es «nada, el usuario lo detecta», el flujo es frágil. En FAST Delivery, el PO define estos criterios de fallo antes de que el Delivery Master empiece a construir. El conocimiento mínimo sobre LLMs no hace ingenieros de ML a los POs; los hace responsables de las decisiones que toman.