Para integrar IA en un software que ya funciona no hace falta rehacerlo. Lo habitual es añadir un servicio en el servidor que llama a un modelo de lenguaje (LLM) por API, con tus datos como contexto, y mostrar el resultado en la aplicación. La parte difícil no es la llamada al modelo. Es elegir bien el caso de uso, controlar el coste, proteger los datos y medir si la IA acierta.

Los resultados que salen al buscar esta pregunta suelen ser páginas de servicios o guías genéricas en inglés. Este artículo es para quien tiene una aplicación en producción (un ERP propio, una plataforma de gestión, una app de clientes) y quiere añadirle IA sin poner en riesgo lo que ya funciona.

Qué casos encajan y cuáles no

Un LLM es bueno con texto: entenderlo, resumirlo, clasificarlo, extraer datos de él y redactarlo. No es fiable para cálculos exactos ni para decisiones que exigen una regla fija.

Caso ¿Encaja? Por qué
Resumir tickets, correos o expedientes largos Sí Ahorra lectura y el usuario comprueba el resultado
Clasificar entradas (tipo de petición, prioridad, departamento) Sí Es texto libre que hoy alguien clasifica a mano
Extraer datos de documentos (facturas, contratos, formularios) Sí, con revisión Funciona bien, pero los errores deben poder corregirse antes de guardarse
Buscar y responder con la documentación interna Sí Es el caso de RAG que explicamos en chatbot con los documentos de tu empresa
Redactar borradores (respuestas, descripciones, informes) Sí Una persona revisa y envía
Calcular precios, impuestos o saldos No Usa código. Un LLM puede equivocarse en una operación sencilla
Aplicar reglas de negocio fijas No Si se puede escribir como regla, una regla es más barata y previsible
Decidir sobre personas (contratar, conceder un crédito) sin supervisión No El riesgo y las obligaciones legales son altos

Una regla práctica: la IA propone y el software o la persona decide. Si un error de la IA llega directamente a un cliente o a la contabilidad sin que nadie lo vea, el diseño no es correcto.

API de un proveedor o modelo propio

Hay dos formas de usar un LLM. La elección afecta al coste, a la privacidad y al trabajo de mantenimiento.

Opción Ventajas Inconvenientes
API de un proveedor (Anthropic, OpenAI, Google, Mistral y otros) Modelos más capaces, sin infraestructura propia, se paga por uso Los datos salen de tu sistema, dependes del proveedor y de sus cambios de precio y versión
Modelo abierto alojado por ti (en tu nube o servidor) Los datos no salen de tu infraestructura y controlas la versión Necesitas GPU, operación y mantenimiento; los modelos que caben en un servidor modesto suelen ser menos capaces
Modelo abierto en un proveedor de nube con región europea Punto intermedio en control y esfuerzo Sigues dependiendo de un tercero y hay que revisar sus condiciones

Para la mayoría de empresas, empezar con una API es lo razonable: permite validar el caso de uso en semanas. Si después el volumen o la privacidad lo justifican, se puede cambiar a otro modelo. Para eso, la arquitectura tiene que permitirlo desde el principio.

Arquitectura: dónde va la IA en tu aplicación

Estas son las decisiones de arquitectura que más importan:

  1. La llamada al modelo va siempre en el servidor. Nunca en la app móvil ni en el navegador. Si la clave de la API está en el cliente, cualquiera puede extraerla y usarla a tu costa.
  2. Un servicio o módulo propio para la IA. Aísla las llamadas al modelo detrás de una interfaz tuya. Así puedes cambiar de proveedor o de modelo sin tocar el resto de la aplicación.
  3. Salidas estructuradas. Pide al modelo que responda en un formato fijo (por ejemplo, JSON con campos definidos) y valídalo antes de usarlo. Los principales proveedores ofrecen modos de salida estructurada para esto.
  4. Tareas largas en segundo plano. Procesar un documento de cincuenta páginas no debe bloquear la pantalla del usuario. Usa una cola de trabajos y avisa cuando termine.
  5. Tiempos de espera y alternativas. La API puede tardar o fallar. Define qué pasa entonces: reintentar, usar otro modelo o seguir sin IA. La aplicación tiene que seguir funcionando.
  6. Registro de cada llamada. Guarda qué se pidió, qué modelo respondió, cuánto tardó y cuántos tokens consumió. Sin ese registro no puedes depurar errores ni controlar el coste.

Dar contexto al modelo

El modelo no conoce tus datos. Tienes que dárselos en cada petición:

  • Datos del registro: la ficha del cliente, el historial del ticket, las líneas del pedido. Los recupera tu propio código, con los permisos del usuario.
  • Documentos: si hay que buscar en mucha documentación, se usa RAG.
  • Herramientas: el modelo puede pedir que tu código ejecute una función (consultar disponibilidad, buscar un producto). Tu código decide si la ejecuta.

Envía solo lo necesario. Menos contexto es más barato, más rápido y expone menos datos.

Cuánto cuesta usar un LLM por API

Los proveedores cobran por tokens: fragmentos de texto que el modelo lee (entrada) y escribe (salida). Los precios se publican por millón de tokens y cambian a menudo. Consulta siempre la página oficial de cada proveedor, por ejemplo la de Anthropic o la de OpenAI.

Lo que mueve el coste:

Factor Efecto
Modelo elegido Los modelos más capaces cuestan bastante más por token que los pequeños
Tamaño del contexto Enviar documentos enteros en cada petición multiplica los tokens de entrada
Longitud de la respuesta Los tokens de salida suelen ser más caros que los de entrada
Volumen Peticiones por usuario y día multiplicadas por el número de usuarios
Reintentos y cadenas de llamadas Un flujo con varios pasos hace varias llamadas por cada acción del usuario

Cómo controlarlo:

  • Usa el modelo más pequeño que resuelva bien la tarea. Clasificar un correo no necesita el modelo más potente.
  • Reutiliza el contexto fijo. Varios proveedores ofrecen caché de prompts, que abarata la parte que se repite en cada petición.
  • Procesa en lote lo que no es urgente. Algunos proveedores tienen APIs por lotes más baratas a cambio de responder más tarde.
  • Pon límites por usuario y por día, y una alerta de gasto.
  • Estima antes de lanzar: tokens medios por petición, peticiones al día y precio vigente. Con el registro de llamadas, compara la estimación con el consumo real en las primeras semanas.

Privacidad y datos

Cuando llamas a una API, los datos que envías salen de tu sistema. Antes de enviar nada, revisa estos puntos:

  • Condiciones del proveedor: si usa los datos de la API para entrenar, cuánto tiempo los guarda y en qué región los procesa.
  • Minimización: envía solo los campos necesarios. Si el modelo no necesita el nombre o el DNI para clasificar un ticket, no los envíes.
  • Seudonimización: sustituye identificadores por códigos antes de enviar y recupéralos al recibir la respuesta.
  • Permisos: la IA no debe ver datos que el usuario que la usa no puede ver.
  • Contrato: si el proveedor trata datos personales por tu cuenta, necesitas un contrato de encargo del tratamiento.

Si los datos son especialmente sensibles (salud, datos financieros detallados), valora un modelo alojado en tu infraestructura o en una región europea con garantías contractuales.

Seguridad: los riesgos propios de un LLM

Integrar un LLM añade riesgos que un software clásico no tiene. El OWASP Top 10 para aplicaciones con LLM los recoge. Tres de ellos afectan a casi cualquier integración:

  • Inyección de instrucciones (prompt injection). Un texto que procesa la IA (un correo, un documento, una web) puede contener instrucciones que el modelo obedece. Si la IA puede ejecutar acciones, un correo malicioso podría intentar que haga algo indebido.
  • Exposición de información sensible. Si el contexto incluye datos de otros usuarios, el modelo puede acabar mostrándolos.
  • Confianza excesiva en la salida. Usar la respuesta del modelo sin validar, por ejemplo para construir una consulta a la base de datos.

Las defensas son de diseño, no de redacción del prompt:

  • Trata todo lo que devuelve el modelo como entrada no fiable: valídalo como validarías un formulario.
  • Limita las acciones que la IA puede pedir y exige confirmación para las que tienen impacto.
  • Filtra el contexto por los permisos del usuario antes de enviarlo al modelo.

Cómo saber si la IA funciona bien: evaluación

Probar una integración de IA no es como probar una función normal. La misma entrada puede dar respuestas distintas. Por eso necesitas una evaluación:

  1. Reúne casos reales: entre cincuenta y unos cientos de ejemplos con la respuesta correcta, revisados por alguien que conoce el negocio.
  2. Define qué es acertar: campo extraído correcto, categoría correcta, respuesta que cita el documento adecuado.
  3. Mide antes de lanzar y cada vez que cambies el prompt, el modelo o el contexto.
  4. Recoge la opinión del usuario en producción: un botón de “útil / no útil” o las correcciones que hace.

Sin evaluación, cambiar de modelo o de prompt es una apuesta. Con ella, es una decisión con datos.

Cómo empezar sin poner en riesgo lo que ya funciona

  1. Elige un caso acotado con un beneficio medible: horas de clasificación manual, tiempo de respuesta, errores de tecleo.
  2. Lanza detrás de un interruptor (feature flag) para un grupo pequeño de usuarios.
  3. Mantén a una persona en el circuito: la IA propone y el usuario acepta o corrige.
  4. Mide durante unas semanas: aciertos, correcciones, coste real y tiempo ahorrado.
  5. Amplía o descarta con esos datos.

Si no tienes claro si tu aplicación está preparada para integrar IA (versiones antiguas, sin API interna, sin registros), empieza por una auditoría técnica. Te dirá qué hay que preparar antes.

Preguntas frecuentes

¿Tengo que entrenar un modelo con mis datos?

Casi nunca. Lo habitual es dar los datos como contexto en cada petición o usar RAG. El ajuste fino (fine-tuning) tiene sentido en casos concretos, por ejemplo para un formato de salida muy específico, y exige datos de entrenamiento de calidad.

¿Puedo cambiar de proveedor más adelante?

Sí, si aislaste la IA en un módulo propio y tienes una evaluación para comparar. Cada modelo responde de forma distinta, así que el cambio requiere ajustar prompts y volver a medir.

¿La IA puede trabajar con mi base de datos directamente?

Puede pedir que tu código ejecute consultas concretas a través de funciones que tú defines. No le des acceso libre a la base de datos: define qué puede consultar y con qué permisos.

Conclusión

Integrar IA en un software existente es un proyecto de integración como otros: servidor, permisos, registros, pruebas y mantenimiento. Lo que cambia es que el resultado no es exacto, y por eso hay que medirlo y diseñar para el error.

¿Quieres añadir IA a tu aplicación? Cuéntanos qué proceso quieres mejorar y te decimos si la IA encaja y cómo empezar. Más sobre nuestro servicio de inteligencia artificial.