Notas: qué fundadores españoles no entienden de la integración IA

Este trimestre he tenido la misma conversación seis o siete veces. Un fundador llega con una idea que, en el fondo, es buena, y en algún momento de los primeros diez minutos dice la frase: “y aquí le metemos IA”. No hay más detalle detrás. La integración de IA se ha convertido en el ingrediente que todo el mundo quiere y casi nadie ha pensado. Como fundadora que también construye, entiendo el impulso. Pero he visto suficientes proyectos encallar en esa parte como para querer escribir el patrón, porque es donde más presupuesto se evapora sin que nadie lo vea venir.

El patrón: la IA como decoración, no como función

El error más común no es técnico, es de encuadre. El fundador piensa en la IA como una capa que se añade encima de un producto ya terminado, igual que se añade un logo o un color de marca. Llega con las pantallas dibujadas, el flujo cerrado, y la IA marcada como una casilla pendiente al final de la lista. Cuando preguntamos qué tiene que hacer exactamente ese modelo, qué datos consume, qué pasa cuando se equivoca y cómo sabremos si funciona, la respuesta suele ser silencio.

La integración de IA no es una decoración que se cuelga al final. Es una función del producto, con sus entradas, sus salidas, sus casos raros y su coste por uso. Tratarla como un adorno hace que se diseñe la última, se pruebe la peor y se presupueste la más barata, justo la combinación que garantiza problemas.

Error uno: no distinguir entre “usar un modelo” y “construir uno”

Casi ningún proyecto que nos llega necesita entrenar un modelo propio. La mayoría necesita conectar bien un modelo que ya existe, de OpenAI, de Anthropic o de quien sea, a un problema concreto y a unos datos concretos. Son dos mundos con precios y plazos completamente distintos.

Cuando un fundador me dice que quiere “su propia IA”, suele estar imaginando meses de trabajo y un coste de seis cifras que no necesita. Y al revés, cuando alguien cree que “es solo llamar a una API”, casi siempre está subestimando la parte difícil, que no es la llamada sino todo lo que la rodea: preparar el contexto, controlar la salida, gestionar los errores y medir la calidad. La conversación honesta empieza separando esas dos cosas antes de hablar de dinero.

Error dos: ignorar qué pasa cuando el modelo se equivoca

Un modelo de lenguaje se equivoca. No a veces, de forma predecible: se inventa datos, malinterpreta preguntas y da respuestas seguras que están mal. Un producto serio se diseña asumiendo eso desde el primer día. La mayoría de los briefs que recibo no mencionan el fallo en ninguna parte, como si la IA fuera a acertar siempre.

Aquí es donde se separa un prototipo de una demo de un producto real. La pregunta no es “¿funciona cuando escribo lo que espero?”, sino “¿qué ve el usuario cuando el modelo mete la pata, y cuánto daño hace eso?”. En una app de recetas, poco. En una que toca dinero, salud o datos personales bajo el RGPD, mucho. Diseñar la integración de IA es sobre todo diseñar el comportamiento cuando la respuesta no es buena.

Error tres: no contar el coste por uso

Una función normal se construye una vez y su coste es más o menos fijo. Una función con IA tiene un coste que se paga cada vez que alguien la usa, porque cada llamada al modelo cuesta dinero. Es una diferencia de modelo de negocio, no solo de ingeniería, y casi nadie la trae pensada.

He visto ideas preciosas que no sostienen sus propios números: el coste de cada interacción con el modelo se comía el margen antes de llegar al primer cliente de pago. Vale la pena hacer esa cuenta pronto, con una servilleta si hace falta. Si cada usuario activo cuesta más en llamadas de IA de lo que paga, no tienes un problema de producto, tienes un problema de aritmética, y es mejor descubrirlo en la semana uno que en la ronda de financiación.

Por qué pasa una y otra vez

Creo que pasa por dos razones. La primera es el ruido. Hay tanto hablando de IA que parece que no tenerla es quedarse atrás, así que se mete en el brief por miedo, no por función. La segunda es que la IA se demostra fenomenal en vídeos de treinta segundos y fatal en los detalles aburridos, que son justo donde vive un producto de verdad. La distancia entre la demo y el producto es enorme, y esa distancia se paga en euros.

No lo cuento para desanimar a nadie. La IA bien integrada cambia productos de forma real, y algunos de los proyectos de los que estoy más orgullosa la usan a fondo. Lo cuento porque la parte que da la ventaja es la que casi nadie planifica.

Qué funciona mejor en la integración de IA

Lo que funciona es tratar la integración de IA como una función de primera, no como el último punto de la lista. En la práctica, eso significa tres cosas concretas antes de escribir una línea de código.

Primero, escribir en una frase qué hace el modelo y cómo sabremos que lo hace bien. Si no cabe en una frase, todavía no está pensado. Segundo, dibujar el camino del fallo con el mismo cariño que el del acierto: qué ve el usuario, qué puede corregir, cuándo interviene una persona. Tercero, hacer la cuenta del coste por uso con números reales, aunque sean aproximados, para saber si la idea se sostiene a escala.

Cuando un fundador llega con esas tres respuestas, la conversación cambia por completo. Deja de ser “metemos IA” y pasa a ser un producto con una función clara, un plan para cuando falle y una economía que cuadra. Si estás en ese punto y quieres una opinión honesta sobre si tu integración de IA se sostiene, cuéntanos el proyecto y lo miramos contigo sin humo.

Si aún estás decidiendo si necesitas ayuda externa para esto, quizá te sirva leer cuándo tiene sentido una agencia de apps con IA y la guía sobre qué hace una agencia de IA en España. La mayoría de los errores de este artículo se evitan con una buena conversación antes de construir, no con más tecnología.