¿Cómo integrar un asistente de IA en una aplicación?

Integrar un asistente de IA en una aplicación es conectar tu app a un modelo de lenguaje, por API o instalado en tu servidor, y darle tres cosas: una tarea concreta, acceso a tus datos y unos límites. La programación es el puente entre el modelo y lo que ya tienes; el modelo se alquila o se descarga.

Lo que decide si sirve no es el modelo que elijas, sino qué le dejas hacer y con qué información. Un asistente que solo sabe lo que sabía el modelo el día que lo entrenaron responde generalidades; uno que consulta tus pedidos o tus manuales responde lo que tu cliente preguntaba.

Qué significa integrar un asistente, en la práctica

Un asistente dentro de una app es una pantalla de conversación (o un campo de texto, o nada visible) que envía lo que escribe el usuario a un modelo de lenguaje y devuelve la respuesta. Entre medias hay un programa tuyo que decide qué contexto recibe el modelo y qué puede hacer con tus sistemas. Ese programa es la integración. Sin él tienes un chat genérico con tu logotipo encima.

Hay dos formas de tener el modelo:

• Por API de un proveedor (OpenAI, Anthropic, Google, Mistral y otros): pagas por uso, no mantienes nada y tienes los modelos más capaces. Tus datos salen de tu servidor en cada consulta.
• Modelo abierto en tu propio servidor: los datos no salen y no pagas por consulta; a cambio necesitas una máquina con GPU y alguien que la mantenga. Para clasificar, resumir o extraer datos suele bastar; en tareas complejas responde peor que los grandes modelos de pago.

Los cuatro pasos de la integración

1. Acotar la tarea

«Un asistente que responda a los clientes» no es una tarea. «Un asistente que, dado un número de pedido, diga en qué estado está y cuándo llega» sí lo es. Cuanto más estrecha, más fácil es comprobar si funciona y más barata es cada consulta, porque el modelo recibe solo el contexto que necesita.

Empezamos siempre por una tarea medible: las preguntas que más se repiten en el correo o en el teléfono, con su respuesta correcta conocida. Esa lista sirve luego como examen.

2. Elegir el modelo y la vía

Elige el que resuelve la tarea con el coste y la privacidad que tu caso admite, no el primero de un ranking. La documentación de OpenAI dice que, desde el 1 de marzo de 2023, los datos enviados a su API no se usan para entrenar sus modelos salvo que tú actives esa opción, y que los registros de supervisión de abusos se conservan hasta 30 días por defecto (OpenAI, Your data). Las condiciones de cada proveedor se leen antes de firmar.

Si el asistente va a tratar datos personales de clientes, el proveedor es un encargado del tratamiento y hace falta su contrato de encargo; eso lo revisa quien lleve la protección de datos en tu empresa.

3. Conectarlo a tus datos y a tus sistemas

Aquí está la diferencia entre un juguete y una herramienta. Hay dos mecanismos, y suelen ir juntos:

• Recuperación de documentos (RAG): antes de preguntar al modelo, tu programa busca en tus documentos los fragmentos que vienen al caso y se los pasa junto con la pregunta. El modelo responde con esa información, no con lo que recuerda del entrenamiento. Sirve para manuales, condiciones y fichas de producto.
• Herramientas (function calling): le describes al modelo qué funciones existen en tu sistema («consultar pedido», «crear cita») y, cuando hace falta, el modelo pide que se ejecute una con unos argumentos. Es tu código el que la ejecuta y le devuelve el resultado: así lo describen la guía de function calling de OpenAI («when the model calls a function, you must execute it and return the result») y la documentación de tool use de Anthropic, donde el modelo responde con un bloque tool_use y tu aplicación devuelve el tool_result.

Ese detalle importa: el modelo nunca toca tu base de datos; lo hace tu programa, con los permisos que tú le des. Si el asistente solo debe leer pedidos, esa es la única función que existe para él.

Cuando los datos viven en un programa sin API, hay que construir el puente, y ahí es donde muchas integraciones se encarecen sin aviso. Si lo que buscas es que el asistente dispare procesos (avisar a alguien, mover un pedido), suele salir más barato un flujo de automatización alimentado por el modelo que una app nueva.

4. Ponerle límites y medirlo

Un modelo de lenguaje puede inventarse una respuesta con total seguridad. La integración tiene que asumirlo:

• Instrucciones de sistema que fijan qué puede responder y qué debe derivar a una persona.
• Respuestas con la fuente a la vista cuando salen de un documento.
• Un registro de cada conversación (lo que el modelo recibió y lo que contestó) para revisar los fallos.
• El examen del paso 1, repetido cada vez que cambias el modelo o las instrucciones.
• Un tope de coste por usuario y por día: las API cobran por token y un bucle mal cerrado se nota en la factura.

API o modelo propio: dónde pesa cada criterio

No hay una columna ganadora: un asistente que lee facturas con datos bancarios y uno que recomienda productos del catálogo público no tienen la misma respuesta.

El aviso obligatorio: tu asistente tiene que decir que es una IA

Desde el 2 de agosto de 2026 se aplica el artículo 50 del Reglamento europeo de Inteligencia Artificial: los sistemas de IA diseñados para interactuar directamente con personas tienen que informarlas de que están hablando con una IA, salvo que sea evidente para una persona razonablemente informada (texto del artículo 50). En un chat dentro de tu app, eso es una frase visible al empezar la conversación. El reglamento no obliga a que haya una persona detrás, pero conviene una salida a alguien de tu equipo cuando el asistente no sabe o el cliente lo pide.

Errores que vemos repetirse

1. Empezar por el chat y no por la tarea: sale una pantalla bonita que no resuelve nada.
2. Darle al modelo acceso directo a la base de datos. El modelo pide; tu código ejecuta y filtra.
3. No guardar las conversaciones: sin registro no se sabe qué falla ni cuánto cuesta.
4. No contar con el cambio de modelo. Los proveedores retiran versiones, y una integración atada a una concreta un día deja de funcionar.

Preguntas frecuentes

¿Hace falta una app nueva para tener un asistente de IA?

No. Un asistente se añade a una app que ya existe, a una web o a un canal como el correo o WhatsApp, siempre que tu programa pueda recibir el mensaje y devolver la respuesta. Lo que se construye es el intermediario entre el modelo y tus datos, no la aplicación entera.

¿Puedo tener el asistente sin que mis datos salgan de mi servidor?

Sí, con un modelo abierto instalado en tu propia máquina y con la automatización alojada también en casa: n8n se puede instalar en tu infraestructura y sin clave de licencia funciona como edición Community gratuita (documentación de n8n). A cambio asumes la máquina y su mantenimiento.

¿Qué pasa si el asistente responde mal a un cliente?

Pasa, y hay que diseñar para ello con lo del paso 4: límites, fuentes a la vista, registro y una salida a una persona. Un asistente que admite «no lo sé, te paso con alguien» es mejor que uno que responde siempre.

Siguiente paso

Si tienes una tarea concreta en mente, cuéntanosla en la página de contacto: te decimos si un asistente la resuelve, por qué vía y qué datos necesita. Lo que hacemos con IA dentro de las apps y en los procesos de una empresa está en el servicio de inteligencia artificial.

Fuentes

• OpenAI, «Your data»: uso de los datos de la API y conservación de registros.
• OpenAI, guía de function calling: el modelo pide la función y es tu código el que la ejecuta y le devuelve el resultado.
• Anthropic, «Tool use with Claude»: el bloque tool_use del modelo y el tool_result que devuelve tu aplicación.
• Reglamento (UE) 2024/1689, artículo 50: obligaciones de transparencia.
• n8n, documentación de alojamiento: cómo instalar n8n en tu propia infraestructura.