Agregar IA a un producto es facil. Decidir si mantenerla es lo dificil. Este es el framework de decision que uso para el ciclo de vida de funcionalidades de IA: cuando agregar, como medir y cuando matar.
Celestino Salim
Senior Software Engineer | AI Systems | Product Engineering
La mayoria de los equipos tratan fine-tuning y RAG como alternativas. No lo son. Resuelven problemas distintos, cuestan diferente, y a veces necesitas ambos. Este es el framework de decision que uso en produccion.
Todos los equipos de producto con los que hablo estan lanzando funcionalidades de IA. La mayoria estaran muertas dentro de un anio.
No porque los modelos sean malos. No porque la ingenieria haya sido descuidada. Porque nadie hizo la unica pregunta que importa: esta funcionalidad se gana su lugar en el producto?
He lanzado funcionalidades de IA que transformaron flujos de trabajo y funcionalidades que los usuarios ignoraron por completo. La diferencia nunca fue la calidad del modelo. Siempre fue el pensamiento de producto detras.
Estas son funcionalidades reales que vi lanzar, celebrar en demos internas, y despues eliminar en silencio.
El resumen automatico de reuniones. Un producto SaaS agrego resumenes automaticos. El demo se veia genial. En produccion, el 4% de los usuarios abrio un resumen alguna vez. El problema: la gente ya tenia sus propias notas. El resumen de IA era una segunda version, peor, de algo que ya tenian.
El asistente de onboarding con IA. Un chatbot que guiaba a usuarios nuevos durante la configuracion. Respondia preguntas con precision. Los datos de uso mostraron que el 92% de los usuarios lo cerraba en menos de 8 segundos. El wizard paso a paso existente funcionaba bien. Los usuarios no querian una conversacion. Querian una checklist.
El compositor de texto predictivo. Una herramienta de email agrego sugerencias de respuestas generadas por IA. La precision era del 70%. Suena decente hasta que te das cuenta de que los usuarios pasaban mas tiempo leyendo y editando las sugerencias que lo que hubieran tardado escribiendo desde cero. Tiempo neto ahorrado: negativo.
El dashboard inteligente. Un producto de analytics lanzo una IA que mostraba "insights" de los datos de usuario. Los insights eran tecnicamente correctos pero obvios. "Tu trafico aumento 23% esta semana." Los usuarios podian ver eso en la grafica. Necesitaban el por que, y la IA no podia darlo.
Cada una de estas funcionalidades costo entre $40,000 y $150,000 construir. Cada una se elimino en menos de seis meses. El patron siempre es el mismo: el equipo construyo para el demo, no para el flujo diario.
La decision de producto mas cara en 2025-2026 es agregar un chatbot porque tu competidor tiene uno.
Vi a una plataforma B2B pasar cuatro meses construyendo una interfaz conversacional para su pagina de configuracion. Cuatro meses. La UI existente tenia menus desplegables y toggles. Los usuarios podian configurar todo en menos de un minuto. El chatbot tardaba mas porque los usuarios tenian que describir lo que querian en vez de simplemente hacer clic.
Cuando pregunte por que lo construyeron, el PM dijo: "Nuestro competidor lanzo un asistente de IA el trimestre pasado."
Eso no es una decision de producto. Es una respuesta de miedo.
La pregunta nunca es "deberiamos agregar IA?" La pregunta es "que problema del usuario estamos resolviendo, y es la IA la mejor forma de resolverlo?" Si no puedes responder la segunda parte con especificos, estas construyendo un demo, no una funcionalidad.
Funcionalidad de IA
Paso cada idea de funcionalidad de IA por tres filtros. Si falla en cualquiera, no la construyo.
No hipotetica mente. No en una encuesta donde hiciste preguntas dirigidas. Hoy, ahora mismo, los usuarios estan luchando con esta tarea?
Revisa tickets de soporte. Mira grabaciones de sesion. Encuentra los puntos donde los usuarios abandonan flujos o repiten acciones. Esos son problemas reales.
Una vez propuse una funcionalidad de IA que auto-categorizaria documentos subidos. Parecia obvio. Luego mire los datos: el 89% de los usuarios subia menos de 5 documentos al mes. No tenian un problema de categorizacion. Tenian un problema de "donde deje ese archivo", que era un problema de busqueda, no de clasificacion.
La solucion fue una mejor barra de busqueda. Costo: dos semanas de ingenieria. El clasificador de IA hubiera costado tres meses.
Este es el filtro que mata mas ideas, y deberia.
Un dropdown de filtros le gana a un motor de recomendaciones de IA cuando los usuarios saben lo que quieren. El autocomplete le gana a un chatbot cuando el espacio de entrada es acotado. Los templates le ganan a la IA generativa cuando el formato de salida es predecible.
Uso una prueba simple: puede una regla hardcodeada o un database query resolver el 80% de este problema? Si es asi, empieza ahi. Siempre puedes agregar IA despues. No puedes quitarla facilmente una vez que los usuarios dependen del 20% que maneja.
Una empresa de logistica con la que trabaje queria un sistema de IA para recomendar rutas optimas de envio. Revisamos sus datos. Doce rutas representaban el 94% de los envios. Una tabla de consulta resolvio el problema. Tiempo total de desarrollo: tres dias.
Si no puedes definir como se ve un "buen resultado", no puedes mejorar la funcionalidad ni justificar su costo.
Para cada funcionalidad de IA, defino tres metricas antes de escribir una sola linea de codigo:
Si no puedes definir estas tres para tu funcionalidad, no entiendes la funcionalidad lo suficiente para construirla.
Lanzaste la funcionalidad. Paso los tres filtros. Ahora necesitas saber si esta funcionando. Sigo cuatro numeros.
Que porcentaje de usuarios que empiezan a usar la funcionalidad de IA realmente terminan la tarea? No es lo mismo que uso. Un usuario que abre el asistente de IA, recibe una mala respuesta y completa la tarea manualmente es un fracaso, no un exito.
Referencia: por debajo del 60% de completacion despues de 30 dias significa que la funcionalidad tiene un problema. Por debajo del 40% significa matala.
Cuanto tarda desde hacer clic en la funcionalidad de IA hasta obtener un resultado util? Mido esto en segundos, no en minutos.
Una herramienta de AI code review que construi inicialmente tardaba 45 segundos en devolver resultados. Los developers cambiaban de pestania y se olvidaban. Bajamos la latencia a 8 segundos. El uso se triplico. Misma calidad, misma precision. La unica diferencia fue la velocidad.
Si tu funcionalidad de IA tarda mas que la alternativa manual, los usuarios no la adoptaran independientemente de la calidad.
De los usuarios que prueban la funcionalidad una vez, que porcentaje la usa de nuevo dentro de 7 dias? Esta es la mejor senial individual del valor de una funcionalidad de IA.
Nunca he visto una funcionalidad recuperarse de menos del 15% de uso de retorno. Ni una vez.
Mide la tarea con la funcionalidad de IA versus sin ella. Cuenta clics, teclas, tiempo y tasa de error. Si la version con IA no reduce el esfuerzo al menos un 30%, los usuarios volveran al camino manual porque les es familiar.
Aqui es donde la mayoria de los equipos dejan de pensar, y donde ocurren las decisiones reales.
Cada funcionalidad de IA tiene un costo por usuario por mes. Calculalo:
Costo mensual de la funcionalidad =
(llamadas API x costo promedio por llamada)
+ (costos de computo / usuarios activos)
+ (horas de mantenimiento de ingenieria
x tarifa por hora / usuarios activos)
Para un ejemplo real, saque estos numeros de una funcionalidad de analisis de documentos con IA:
| Componente | Costo Mensual | |-----------|-------------| | Llamadas API LLM (GPT-4o) | $2,400 | | Generacion de embeddings | $180 | | Almacenamiento de vectores | $95 | | Mantenimiento de ingenieria (8 hrs) | $1,200 | | Total | $3,875 |
Con 1,200 usuarios activos, el costo por usuario por mes era de $3.23.
La funcionalidad ahorraba a cada usuario aproximadamente 25 minutos al mes. A un salario promedio de usuario de $85/hora, eso son $35.42 en tiempo ahorrado.
$3.23 de costo por $35.42 en valor. Eso es un retorno de 10.9x. Esa funcionalidad vive.
Ahora considera el resumen de reuniones de antes. Estructura de costos similar, pero solo 4% de adopcion. El costo por usuario activo salto a $80/mes. Para una funcionalidad que ahorraba quiza 5 minutos. Esa funcionalidad muere.
La matematica es simple. Hacer la matematica es la parte que la mayoria de los equipos se salta.
Uso tres disparadores. Si cualquiera se activa, la funcionalidad entra en revision de 30 dias. Si dos se activan, la mato inmediatamente.
Disparador 1: Adopcion por debajo del 10% despues de 90 dias. Les diste tres meses a los usuarios. Iteraste en el UX. Enviaste emails de producto. Si el 90% de los usuarios todavia no toca la funcionalidad, el problema que resuelve no es suficientemente importante.
Disparador 2: Costo por usuario activo mayor a $15/mes (para un producto B2B con $50-200 de ARPU). Ajusta este umbral segun tu pricing, pero el principio se mantiene: si una sola funcionalidad cuesta mas del 10% de lo que los usuarios te pagan, necesita entregar valor proporcional.
Disparador 3: Sin mejora medible despues de tres iteraciones. Cambiaste los prompts. Mejoraste el retrieval. Redisenaste la UI. Los scores de calidad no se movieron. Esto usualmente significa que el problema es estructural, no resoluble con mejor ingenieria.
Matar una funcionalidad no es fracaso. Mantener una funcionalidad que cuesta dinero y no entrega nada es fracaso.
Cuando mato una funcionalidad de IA, casi siempre la reemplazo con algo mas simple que funciona mejor.
Autocomplete en lugar de generacion. Los usuarios escriben tres caracteres, obtienen sugerencias de sus propios datos historicos. Sin llamadas a LLM. Latencia de menos de 50ms. Funciona offline.
Templates en lugar de redaccion con IA. Dale a los usuarios 5-10 templates probados que pueden personalizar. Mas rapido que esperar la salida de IA, mas predecible, cero costo por uso.
Smart defaults en lugar de recomendaciones de IA. Analiza el comportamiento del usuario en batch. Configura defaults basados en lo que el 80% de usuarios similares eligio. Actualiza semanalmente, no en tiempo real. El costo de computo baja de dolares por usuario a fracciones de centavo.
Flujos estructurados en lugar de chatbots. Un wizard de tres pasos con ramificacion condicional maneja el 90% de los casos de uso mejor que una conversacion de texto libre. Los usuarios prefieren caminos guiados sobre prompts abiertos.
Estas alternativas no son emocionantes. No se ven bien en un demo. Pero si se usan.
En cada producto en el que he trabajado, una funcionalidad de IA justifica su costo consistente- mente: la busqueda.
La busqueda funciona porque la intencion del usuario es explicita. Cuando alguien escribe una consulta, sabes exactamente lo que quiere. Puedes medir si lo encontro. Puedes calcular precision y recall. Puedes hacer A/B testing de algoritmos de ranking.
La busqueda semantica con embeddings cuesta $0.001-0.01 por consulta a escala. Maneja typos, sinonimos y consultas en lenguaje natural. Los usuarios ya entienden el modelo de interaccion. No hay friccion de adopcion.
Compara eso con un chatbot donde:
Si estas empezando tu estrategia de producto con IA, empieza con la busqueda. Hazla rapida. Hazla precisa. Despues mide si los usuarios hacen preguntas que la busqueda no puede responder. Esas preguntas sin respuesta son tu roadmap para la siguiente funcionalidad de IA.
Asi es como evaluo cada solicitud de funcionalidad de IA ahora:
La mayoria de las ideas de funcionalidades de IA mueren en el paso 1. Ese es el punto. Las funcionalidades que sobreviven los cinco pasos son las que realmente hacen mejor tu producto.
El objetivo no es lanzar IA. El objetivo es resolver problemas de usuarios. A veces la IA es la respuesta. La mayoria de las veces, no lo es. Los equipos que entienden la diferencia son los que construyen productos que duran.