10 min de lectura
Agregar IA a un producto es fácil. Decidir si mantenerla es lo difícil. Este es el framework de decisión que uso para el ciclo de vida de funcionalidades de IA: cuándo agregar, cómo medir y cuándo matar.
Celestino Salim
Senior Software Engineer
El mercado de bases de datos vectoriales quiere que adoptes Pinecone o Weaviate. Para la mayoría de equipos, Postgres con pgvector elimina un servicio entero de tu stack -- y rinde dentro del 5% de las soluciones dedicadas con 1M de vectores.
Todos los equipos de producto con los que hablo están lanzando funcionalidades de IA. La mayoría estarán muertas dentro de un año.
No porque los modelos sean malos. No porque la ingeniería haya sido descuidada. Porque nadie hizo la única 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 detrás.
Estas son funcionalidades reales que vi lanzar, celebrar en demos internas, y después eliminar en silencio.
El resumen automático de reuniones. Un producto SaaS agregó resúmenes automáticos. El demo se veía genial. En producción, el 4% de los usuarios abrió un resumen alguna vez. El problema: la gente ya tenía sus propias notas. El resumen de IA era una segunda versión, peor, de algo que ya tenían.
El asistente de onboarding con IA. Un chatbot que guiaba a usuarios nuevos durante la configuración. Respondía preguntas con precisión. 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 querían una conversación. Querían una checklist.
El compositor de texto predictivo. Una herramienta de email agregó sugerencias de respuestas generadas por IA. La precisión era del 70%. Suena decente hasta que te das cuenta de que los usuarios pasaban más 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 lanzó una IA que mostraba "insights" de los datos de usuario. Los insights eran técnicamente correctos pero obvios. "Tu tráfico aumentó 23% esta semana." Los usuarios podían ver eso en la gráfica. Necesitaban el por qué, y la IA no podía darlo.
Cada una de estas funcionalidades costó entre $40,000 y $150,000 construir. Cada una se eliminó en menos de seis meses. El patrón siempre es el mismo: el equipo construyó para el demo, no para el flujo diario.
La decisión de producto más 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 página de configuración. Cuatro meses. La UI existente tenía menús desplegables y toggles. Los usuarios podían configurar todo en menos de un minuto. El chatbot tardaba más porque los usuarios tenían que describir lo que querían en vez de simplemente hacer clic.
Cuando pregunté por qué lo construyeron, el PM dijo: "Nuestro competidor lanzó un asistente de IA el trimestre pasado."
Eso no es una decisión de producto. Es una respuesta de miedo.
La pregunta nunca es "¿deberíamos agregar IA?" La pregunta es "¿qué problema del usuario estamos resolviendo, y es la IA la mejor forma de resolverlo?" Si no puedes responder la segunda parte con específicos, estás 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 hipotética mente. No en una encuesta donde hiciste preguntas dirigidas. ¿Hoy, ahora mismo, los usuarios están luchando con esta tarea?
Revisa tickets de soporte. Mira grabaciones de sesión. Encuentra los puntos donde los usuarios abandonan flujos o repiten acciones. Esos son problemas reales.
Una vez propuse una funcionalidad de IA que auto-categorizaría documentos subidos. Parecía obvio. Luego miré los datos: el 89% de los usuarios subía menos de 5 documentos al mes. No tenían un problema de categorización. Tenían un problema de "dónde dejé ese archivo", que era un problema de búsqueda, no de clasificación.
La solución fue una mejor barra de búsqueda. Costo: dos semanas de ingeniería. El clasificador de IA hubiera costado tres meses.
Este es el filtro que mata más ideas, y debería.
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 así, empieza ahí. Siempre puedes agregar IA después. No puedes quitarla fácilmente una vez que los usuarios dependen del 20% que maneja.
Una empresa de logística con la que trabajé quería un sistema de IA para recomendar rutas óptimas de envío. Revisamos sus datos. Doce rutas representaban el 94% de los envíos. Una tabla de consulta resolvió el problema. Tiempo total de desarrollo: tres días.
Si no puedes definir cómo se ve un "buen resultado", no puedes mejorar la funcionalidad ni justificar su costo.
Para cada funcionalidad de IA, defino tres métricas antes de escribir una sola línea de código:
Si no puedes definir estas tres para tu funcionalidad, no entiendes la funcionalidad lo suficiente para construirla.
Lanzaste la funcionalidad. Pasó los tres filtros. Ahora necesitas saber si está funcionando. Sigo cuatro números.
¿Qué 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 éxito.
Referencia: por debajo del 60% de completación después de 30 días significa que la funcionalidad tiene un problema. Por debajo del 40% significa mátala.
¿Cuánto tarda desde hacer clic en la funcionalidad de IA hasta obtener un resultado útil? Mido esto en segundos, no en minutos.
Una herramienta de AI code review que construí inicialmente tardaba 45 segundos en devolver resultados. Los developers cambiaban de pestaña y se olvidaban. Bajamos la latencia a 8 segundos. El uso se triplicó. Misma calidad, misma precisión. La única diferencia fue la velocidad.
Si tu funcionalidad de IA tarda más que la alternativa manual, los usuarios no la adoptarán independientemente de la calidad.
¿De los usuarios que prueban la funcionalidad una vez, qué porcentaje la usa de nuevo dentro de 7 días? Esta es la mejor señal 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 versión con IA no reduce el esfuerzo al menos un 30%, los usuarios volverán al camino manual porque les es familiar.
Aquí es donde la mayoría de los equipos dejan de pensar, y donde ocurren las decisiones reales.
Cada funcionalidad de IA tiene un costo por usuario por mes. Calcúlalo:
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, saqué estos números de una funcionalidad de análisis de documentos con IA:
| Componente | Costo Mensual | |-----------|-------------| | Llamadas API LLM (GPT-4o) | $2,400 | | Generación de embeddings | $180 | | Almacenamiento de vectores | $95 | | Mantenimiento de ingeniería (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 adopción. El costo por usuario activo saltó a $80/mes. Para una funcionalidad que ahorraba quizá 5 minutos. Esa funcionalidad muere.
La matemática es simple. Hacer la matemática es la parte que la mayoría de los equipos se salta.
Uso tres disparadores. Si cualquiera se activa, la funcionalidad entra en revisión de 30 días. Si dos se activan, la mato inmediatamente.
Disparador 1: Adopción por debajo del 10% después de 90 días. Les diste tres meses a los usuarios. Iteraste en el UX. Enviaste emails de producto. Si el 90% de los usuarios todavía 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 según tu pricing, pero el principio se mantiene: si una sola funcionalidad cuesta más del 10% de lo que los usuarios te pagan, necesita entregar valor proporcional.
Disparador 3: Sin mejora medible después de tres iteraciones. Cambiaste los prompts. Mejoraste el retrieval. Rediseñaste la UI. Los scores de calidad no se movieron. Esto usualmente significa que el problema es estructural, no resoluble con mejor ingeniería.
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 más simple que funciona mejor.
Autocomplete en lugar de generación. Los usuarios escriben tres caracteres, obtienen sugerencias de sus propios datos históricos. Sin llamadas a LLM. Latencia de menos de 50ms. Funciona offline.
Templates en lugar de redacción con IA. Dale a los usuarios 5-10 templates probados que pueden personalizar. Más rápido que esperar la salida de IA, más 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 eligió. Actualiza semanalmente, no en tiempo real. El costo de cómputo baja de dólares por usuario a fracciones de centavo.
Flujos estructurados en lugar de chatbots. Un wizard de tres pasos con ramificación condicional maneja el 90% de los casos de uso mejor que una conversación de texto libre. Los usuarios prefieren caminos guiados sobre prompts abiertos.
Estas alternativas no son emocionantes. No se ven bien en un demo. Pero sí se usan.
En cada producto en el que he trabajado, una funcionalidad de IA justifica su costo consistente- mente: la búsqueda.
La búsqueda funciona porque la intención del usuario es explícita. Cuando alguien escribe una consulta, sabes exactamente lo que quiere. Puedes medir si lo encontró. Puedes calcular precisión y recall. Puedes hacer A/B testing de algoritmos de ranking.
La búsqueda semántica con embeddings cuesta $0.001-0.01 por consulta a escala. Maneja typos, sinónimos y consultas en lenguaje natural. Los usuarios ya entienden el modelo de interacción. No hay fricción de adopción.
Compara eso con un chatbot donde:
Si estás empezando tu estrategia de producto con IA, empieza con la búsqueda. Hazla rápida. Hazla precisa. Después mide si los usuarios hacen preguntas que la búsqueda no puede responder. Esas preguntas sin respuesta son tu roadmap para la siguiente funcionalidad de IA.
Así es como evalúo cada solicitud de funcionalidad de IA ahora:
La mayoría 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 mayoría de las veces, no lo es. Los equipos que entienden la diferencia son los que construyen productos que duran.