Para el producto que vendes
Cómo agregar funciones de IA a un producto que ya existe
Tienes usuarios, datos, permisos y una hoja de ruta. “Agregar IA” es el pedido del directorio. Esta es la versión práctica: qué funciones encajan en un producto que ya existe, qué las hace funcionar, y cómo entregar una en semanas sin romper la confianza que construiste.
Empieza por el trabajo, no por el modelo
La forma más rápida de agregarle IA a un producto y hacerlo mal es empezar por el modelo. Aparece un chatbot en la esquina, responde preguntas que nadie le hizo, y lo cierran. Sale a producción, demuestra bien, y seis meses después nadie puede señalar un número que haya movido.
Las funciones que quedan empiezan por algo que tus usuarios ya hacen: de forma repetida, a desgano, o lento. Tres preguntas las encuentran:
¿Dónde producen los usuarios un primer borrador?
Informes, respuestas, resúmenes, configuraciones, descripciones. Cualquier cosa que se escriba desde cero y podría escribirse desde una sugerencia.
¿Dónde esperan?
En una búsqueda, en una revisión, en la aprobación de otra persona, en un reporte que corre de noche.
¿Dónde buscan en vez de preguntar?
Artículos de ayuda, registros viejos, archivos de otras personas. Cada caja de búsqueda es una pregunta que tu producto podría responder directamente.
Cada respuesta es una función candidata con una métrica adosada: borradores aceptados, minutos no esperados, búsquedas que se volvieron respuestas.
Las cuatro formas que toman las funciones de IA dentro de un producto que ya existe
Casi toda función de IA que funciona dentro de un producto es una de cuatro formas. Nombrar la forma temprano decide la arquitectura, el riesgo y la métrica.
Asistir
Un borrador o una sugerencia dentro del flujo de trabajo en el que el usuario ya está: la respuesta, el resumen, el próximo campo, la categoría probable. El usuario mantiene el control; el modelo le ahorra los primeros noventa segundos. El menor riesgo, lo más fácil de medir (aceptado o editado), y la primera función correcta para la mayoría de los productos.
Recuperar
Respuestas sobre los datos propios del cliente: sus documentos, sus registros, su historia, con la fuente a la vista. Aquí es donde preguntarle al producto se vuelve real, y donde los permisos deciden todo: la respuesta nunca debe incluir lo que el usuario no podría abrir a mano.
Extraer y clasificar
Convertir lo que llega —documentos, tickets, correos, imágenes— en campos estructurados sobre los que tu producto pueda actuar. Invisible para el usuario cuando funciona, y a menudo la función con el beneficio operativo más claro.
Automatizar, con una compuerta
Un agente que toma acciones dentro del producto en nombre del usuario —archiva, actualiza, agenda, notifica— con una persona aprobando hasta que ese tipo de acción se haya ganado la autonomía. El mayor valor, lo que más está en juego; nunca la primera función.
La mayoría de los productos va a entregar una función de asistencia, descubrir una función de recuperación por debajo, y solo entonces estar lista para un agente.
Lo que tu producto ya tiene, y lo que no
Un producto que ya existe trae tres cosas que un proyecto de IA desde cero nunca tiene: una UX que los usuarios ya conocen, un modelo de permisos y un modelo de datos con historia dentro. La función debería vivir dentro de los tres. Esa es toda la ventaja sobre una herramienta pegada por fuera, y es donde están las trampas.
Permisos
Una recuperación que ignora el tenant es una filtración de datos con una interfaz amable. El modelo ve solo lo que puede ver el usuario que pregunta, impuesto en el momento de la consulta y no por prompt.
Latencia
Una espera de tres segundos está bien para un borrador que el usuario pidió, y es inaceptable en un campo que autocompleta. Decide por función si el modelo corre en el camino del request, en segundo plano, o de antemano.
Costo por llamada
Una función que llama a un modelo grande en cada tecla puede costar más que el plan en el que vive. Diséñala para eso: modelos más chicos donde alcanzan, caché, procesamiento por lotes, y un presupuesto por tenant que el producto respete.
Evaluación
No puedes entregar lo que no puedes medir. Antes del lanzamiento, un conjunto de prueba tomado del uso real —borradores reales, preguntas reales, documentos reales— con respuestas correctas conocidas, que corra cada vez que cambia el prompt, el modelo o los datos. Es la única forma de saber si un cambio mejoró la función o solo movió las fallas.
Preparación de los datos
“Tenemos los datos” y “un modelo puede usarlos” son estados distintos. Calidad, estructura, acceso y recuperación: cada uno hay que verificarlo contra la función que realmente quieres; la brecha suele ser lo primero que hay que arreglar, y rara vez es glamorosa. Datos listos para IA es ese trabajo.
Elección de modelo, en breve
Es la decisión en la que los equipos de producto pasan más tiempo y la que menos importa al principio.
Los modelos comerciales por API te llevan más rápido a una función que funciona. Empieza por ahí para funciones de asistencia y de recuperación, salvo que una restricción dura diga lo contrario.
Los modelos de pesos abiertos en tu propia infraestructura ganan cuando los datos no pueden salir de tu entorno, cuando el volumen vuelve insostenible el precio por llamada, o cuando hay que controlar la latencia. Cuestan más de operar y menos de correr.
El machine learning clásico —que no es un modelo de lenguaje en absoluto— es la respuesta correcta cuando la entrada es una tabla y la salida es una predicción o un puntaje. Más barato, más rápido y explicable.
El fine-tuning le enseña a un modelo un formato o una tarea angosta, no tu negocio. Eso lo hace el anclaje en tus datos. Recurre al fine-tuning tarde, por costo o por latencia, no primero.
Cualquiera sea la elección, el modelo es un componente detrás de una interfaz que tu producto controla. Cambiarlo debería ser un cambio de configuración, y el conjunto de evaluación es lo que vuelve eso seguro.
Entregarla sin romper la confianza
Los usuarios que ya están tienen expectativas que un producto nuevo no tiene. Una función que se equivoca con seguridad una sola vez cuesta más que una que nunca estuvo.
Entrega a un grupo detrás de un flag
Diez clientes que se anotaron, después cien. La función se gana la salida.
Muestra la fuente, permite la edición
Las respuestas recuperadas citan; los borradores son editables; el usuario puede ver por qué el producto sugirió lo que sugirió.
Mantén una compuerta sobre las acciones
Todo lo que cambia datos espera a una persona hasta que ese tipo de acción tenga un historial. La autonomía es algo que una función se gana, una acción a la vez. Agentes y asistentes de IA está construido exactamente alrededor de eso.
Mide adopción, no uso
No “cuántos hicieron clic”, sino cuántos la seguían usando en la cuarta semana, cuántos borradores se aceptaron, cuántas respuestas se corrigieron. La tasa de corrección es la salud de la función.
Instruméntala como cualquier otra función
Logs, seguimiento de errores, y una traza desde cada salida hasta el modelo, el prompt y los datos que la produjeron.
Di qué es
No le digas “con IA”. Di qué hace: “redacta tu respuesta”, “responde desde tus documentos”, “marca las facturas que no coinciden”. Los usuarios confían en funciones, no en adjetivos.
Cuánto tarda y cuánto cuesta
Una primera función de asistencia o de extracción, limitada a un flujo de trabajo, son semanas de trabajo y no trimestres, si los datos están listos y el conjunto de evaluación existe. La recuperación sobre datos de clientes suma el trabajo de permisos. Un agente que actúa suma la compuerta, la traza de auditoría y el tiempo que lleva ganarse la autonomía.
Cuánto cuesta depende de cuál de esas estés construyendo y de qué pueden sostener tus datos hoy, que es la razón por la que no publicamos una lista de precios. Lo que sí publicamos es cómo averiguarlo: un Sprint de AI Discovery de dos semanas con los ingenieros que lo construirían, que termina con las dos o tres funciones que vale la pena construir primero, su factibilidad contra tus sistemas reales, y un piloto dimensionado con un presupuesto que puedes llevar al directorio.
Donde los productos se equivocan
El chatbot pegado por fuera. Genérico, desconectado del modelo de datos, cerrado en una semana.
La demo que nunca sale. Impresionante con entradas curadas, nunca medida con las reales.
La recuperación que ignora los permisos. Descubierta por un cliente, no por QA.
Sin conjunto de evaluación. Cada cambio de prompt es una adivinanza; cada actualización de modelo es un riesgo.
“IA” como nombre de la función. Una etiqueta en lugar de un trabajo; los usuarios no saben cuándo usarla, así que no la usan.
Empezar por el agente. La forma con más en juego como la primera, antes de que el producto se haya ganado nada de confianza para eso.
Preguntas que hacen los equipos de producto
¿Necesitamos nuestro propio modelo?
Casi nunca al principio. Necesitas tus datos, tus permisos y una función limitada a un trabajo. El modelo es un componente.
¿Los datos de nuestros clientes van a entrenar el modelo de otra empresa?
No debería, y no tiene por qué. Los proveedores comerciales ofrecen términos que excluyen tus datos del entrenamiento; los modelos de pesos abiertos en tu infraestructura eliminan la pregunta por completo. Decídelo en la arquitectura, y dilo con claridad en el producto.
¿Y las alucinaciones?
Anclaje en tus datos, citar las fuentes, decir “no lo sé” cuando la recuperación vuelve vacía, y un conjunto de evaluación que mida la tasa. Reducidas, no eliminadas, que es la razón por la que el usuario conserva la edición y la acción conserva la compuerta. IA responsable es cómo lo diseñamos para que sea así.
¿Puede construirla nuestro propio equipo?
A menudo sí, una vez que el alcance está bien. Las partes difíciles son definir el alcance, la preparación de los datos y la evaluación: las partes que produce un sprint, y que una hoja de ruta escrita para ejecutarse con nosotros o sin nosotros le entrega a tu equipo.
¿Cómo sabemos si funcionó?
Por la métrica que le adosaste al trabajo en la primera sección. Si no puedes nombrarla, la función no está lista para construirse.
Encuentra la función que rinde primero.
Dos semanas con los ingenieros que la construirían: un mapa de oportunidades de tu producto, las dos o tres funciones que vale la pena entregar primero, factibilidad contra tus datos y permisos reales, y un piloto dimensionado para salir a producción.