Integrar IA en una aplicación: guía para no equivocarte

Integrar IA en una aplicación consiste en que tu servidor llame a un modelo de lenguaje (por la API de un proveedor, a través de una plataforma en la nube o con un modelo que ejecutas tú) y use la respuesta dentro de tu producto. El código de la primera llamada son diez líneas. Lo difícil son las decisiones que lo rodean: dónde vive la clave, cuánto puede gastar cada usuario, qué datos salen de tu empresa y cómo sabes que las respuestas son buenas.

Esta guía recorre esas decisiones en el orden en que te las vas a encontrar. Los datos de los proveedores (regiones, límites, recargos) son de su documentación oficial a 8 de octubre de 2026. Si buscas el código de la primera llamada, lo tienes en primeros pasos con la API de OpenAI y de Claude; si buscas cuánto cuesta cada modelo, en el precio de la API de OpenAI, Claude y Gemini.

Las tres formas de acceder a un modelo

La primera decisión es por dónde llegas al modelo. No es definitiva, pero condiciona el contrato, la región donde se procesan los datos y la factura.

La API del proveedor

Es la vía de OpenAI, Anthropic o la API de Gemini de Google: te das de alta, cargas crédito y pagas por token. Tienes todas las funciones del proveedor (el modo rápido de Claude, por ejemplo, solo está en su API) y empiezas en un rato. En contra, por defecto los datos se procesan donde decida el proveedor.

Una plataforma en la nube

Amazon Bedrock, Google Cloud (su Agent Platform, antes Vertex AI) y Microsoft Foundry ofrecen los modelos de varios proveedores y los cobran por token en la factura de tu nube. A cambio te dan regiones europeas y los permisos y contratos de la nube que ya usas. Los endpoints regionales cuestan más (un 10 % para Claude en Bedrock y Google Cloud), y los modelos nuevos llegan antes a los endpoints globales que a los regionales.

Un modelo propio

Son modelos abiertos que ejecutas en tus servidores o en tu ordenador. Pagas el hardware o el alquiler de GPU, no los tokens, y los datos no salen de tu infraestructura. Pero el mantenimiento es tuyo, y hay que medir si llegan a la calidad que necesitas.

Si tus datos deben quedarse en Europa

Esto es lo que hay a 8 de octubre de 2026. En la API de Anthropic no hay opción europea: el parámetro inference_geo solo admite global (cualquier región) o us (solo Estados Unidos, con un recargo de 1,1).

Claude sí se puede usar con los datos en Europa a través de la nube. Amazon Bedrock tiene un perfil de inferencia europeo que incluye Fráncfort, Zúrich, Estocolmo, Milán, Irlanda y la región de España, y Google Cloud, un endpoint multirregión eu. En los dos, los endpoints regionales cuestan un 10 % más que los globales.

La API de OpenAI tiene residencia de datos en Europa con el dominio eu.api.openai.com, pero hay que pedirla a ventas, estar aprobado para los controles de monitorización de abusos y firmar una adenda de retención; cuesta un 10 % más en los modelos publicados desde el 5 de marzo de 2026. La otra vía para los modelos de OpenAI es Azure: Microsoft Foundry tiene despliegues Data Zone Standard que procesan los datos dentro del límite de datos de la UE de Azure.

Para empezar y validar la idea, la API directa es lo más rápido. Si trabajas con datos personales de clientes o en un sector regulado, plantéate desde el principio una plataforma en la nube con región europea. Y si los datos no pueden salir de tu casa de ninguna manera, mira los modelos de código abierto y lo que implica ejecutar IA en local.

El esquema que funciona casi siempre

Da igual el proveedor: la arquitectura que funciona pone tu servidor en medio. El navegador o la app nunca hablan con el modelo directamente.

Navegador o app móvil
        │   petición a TU API, con la sesión del usuario
        ▼
Tu backend  ───────────────────────►  Proveedor de IA
  · guarda la clave de la API           (OpenAI, Anthropic, Google,
  · comprueba quién es el usuario        Bedrock, Foundry…)
  · aplica su límite de uso
  · arma el prompt (+ documentos RAG)
  · valida la respuesta
  · registra tokens y coste
        │
        ▼
Base de datos, registros y métricas

Cada pieza del backend tiene un trabajo, y se nota cuando falta:

• La autenticación dice quién pide. Sin ella, cualquiera que encuentre la URL gasta tu crédito.
• El límite por usuario reparte el gasto. Sin él, un solo usuario (o un bot) te vacía la cuenta.
• La plantilla de prompt guarda las instrucciones fijas y versionadas. Sin ella, cada cambio es un experimento a ciegas.
• La validación de la salida comprueba el formato y las reglas de negocio. Sin ella, un JSON roto tumba la pantalla siguiente.
• El registro de usage apunta tokens y coste por petición y por usuario. Sin él, descubres el gasto en la factura.

La clave de la API, siempre en el servidor

La clave de la API es una contraseña con tarjeta de crédito detrás. Todo lo que llega al navegador se puede leer: si la clave está en el JavaScript de la página, cualquiera la copia con las herramientas de desarrollo. OpenAI lo pide en su referencia: que no la expongas en ningún código de cliente, ni en navegadores ni en apps. Google lo dice igual de claro para Gemini: las claves compiladas en el código de una app se pueden extraer, y la solución es un servidor intermedio.

Los frameworks web lo ponen fácil para equivocarse. En Vite, cualquier variable que empiece por VITE_ acaba dentro del código que se descarga el navegador; en Next.js pasa lo mismo con NEXT_PUBLIC_. Si una web hecha con IA llama a OpenAI desde el navegador, tiene la clave a la vista.

Hay dos formas de no tener ni siquiera una clave fija que proteger. La primera es la federación de identidad, que ofrecen OpenAI y Anthropic: tu servidor en AWS, Google Cloud o GitHub Actions obtiene credenciales temporales y no hay ninguna cadena sk-... que robar. La segunda, para apps de iOS y macOS, es App Attest de Anthropic: cada instalación demuestra que es tu app legítima y recibe un token que caduca en una hora y solo sirve para pedir mensajes.

Elegir modelo sin casarte con él

Empieza por el modelo más barato que haga bien la tarea y sube solo si no llega. En la generación actual de OpenAI y de Anthropic, el modelo de gama alta (GPT-6 Astra, Claude Fable 5.1) cuesta 100 veces más que el pequeño (GPT-6 Luna, Claude Haiku 5.5), y para clasificar, extraer datos o resumir el pequeño suele bastar. Cómo probarlo con tus propios casos está en cómo elegir un modelo de IA para un proyecto.

Tres decisiones de diseño te ahorran disgustos:

1. Envuelve las llamadas en una función propia. Si todo tu código llama a generar_respuesta() y solo esa función conoce el SDK del proveedor, cambiar de modelo o de proveedor es tocar un archivo.
2. Fija la versión. OpenAI recomienda fijar en producción una instantánea concreta del modelo (pone como ejemplo gpt-5.5-2026-04-23) para que el comportamiento no cambie solo. En Anthropic, cada identificador de modelo ya es una instantánea fija desde la generación 4.6, y cada modelo tiene una fecha mínima de retirada publicada en su página de modelos.
3. Controla el razonamiento. Los modelos actuales piensan antes de responder, y ese razonamiento se cobra como salida. Los dos proveedores tienen un parámetro de esfuerzo: bajo para tareas mecánicas, alto para las difíciles. Lo explicamos en modelos de razonamiento.

Streaming: que el usuario vea la respuesta mientras se escribe

Una respuesta larga puede tardar decenas de segundos en completarse. Con streaming, el texto llega a trozos mientras el modelo lo genera, mediante eventos enviados por el servidor (SSE), y el usuario empieza a leer enseguida. Es lo que hace que un chat parezca rápido aunque tarde lo mismo.

En la arquitectura de arriba, tu backend recibe el stream del proveedor y lo reenvía al navegador. Tres cosas a tener en cuenta:

• Úsalo para cualquier petición larga. Anthropic recomienda streaming para evitar que la conexión se corte por tiempo de espera; sin él, una respuesta muy larga puede acabar en error.
• Los errores pueden llegar a mitad. El proveedor puede responder 200 y fallar después, dentro del stream. Tu código tiene que tratar ese caso y avisar al usuario.
• Comprueba que nada en medio acumula la respuesta. Algunos proxys y algunas plataformas serverless guardan la respuesta entera antes de enviarla, y el efecto de streaming desaparece.

Salidas estructuradas: JSON que no se rompe

Si la respuesta del modelo la va a leer tu código, no un humano, pídela en JSON con un esquema. Los dos grandes proveedores tienen salidas estructuradas que garantizan que la respuesta cumple un esquema JSON: en OpenAI, con text.format de tipo json_schema y strict: true; en Claude, con output_config.format (y el SDK de Python valida la respuesta contra un modelo de Pydantic con messages.parse()). Detalles en las guías de OpenAI y de Anthropic.

Un esquema para extraer datos de una factura sería algo así:

{
  "type": "object",
  "properties": {
    "proveedor": { "type": "string" },
    "fecha": { "type": "string", "description": "AAAA-MM-DD" },
    "base_imponible": { "type": "number" },
    "iva": { "type": "number" },
    "total": { "type": "number" }
  },
  "required": ["proveedor", "fecha", "base_imponible", "iva", "total"],
  "additionalProperties": false
}

El esquema garantiza la forma, no el contenido. Que el JSON sea válido no significa que el total sea la suma de la base y el IVA. Esas reglas de negocio las compruebas tú antes de guardar nada.

Herramientas: cuando el modelo tiene que hacer cosas

Con el uso de herramientas (function calling), le describes al modelo unas funciones de tu código (consultar un pedido, buscar en el catálogo, reservar una cita) y el modelo decide cuándo llamarlas y con qué argumentos. Quien las ejecuta es tu código, nunca el modelo, y luego le devuelves el resultado para que siga.

Lo que hay que saber antes de dar herramientas a un modelo:

• Cuestan tokens. Las definiciones de las herramientas se cobran como entrada en cada llamada, y Anthropic añade además un prompt de sistema propio (286 tokens en Claude Opus 5.5).
• Mínimo privilegio. Una herramienta que solo lee es mucho menos peligrosa que una que borra, paga o envía correos. Para lo irreversible, pide confirmación al usuario.
• Inyección de prompts. Si el modelo lee contenido de terceros (un correo, una web, un PDF subido), ese texto puede llevar instrucciones escondidas. Trata lo que el modelo decide a partir de contenido externo como una entrada no fiable.

Cuando el modelo encadena muchas herramientas por su cuenta, ya estás construyendo un agente; en qué es un agente de IA explicamos cuándo compensa y cuándo basta un flujo fijo. Para conectar herramientas de forma estándar, mira MCP.

RAG o contexto largo: que responda con tus datos

El modelo no conoce tus documentos, tu catálogo ni tus normas internas. Hay dos formas de dárselos:

• Meterlos en el prompt. Los modelos actuales de Claude tienen una ventana de un millón de tokens, y los GPT-6, de 1.050.000. Si tu documentación cabe y se repite en cada llamada, la caché de prompts la abarata mucho (siguiente apartado).
• RAG (generación aumentada por recuperación). Antes de cada llamada, buscas en tu base de documentos los fragmentos relevantes para esa pregunta y solo envías esos. Es lo que necesitas cuando los documentos son muchos, cambian a menudo o hay que citar la fuente. Lo explicamos a fondo en qué es RAG.

Una cuenta para decidir: 50.000 tokens de documentación en cada llamada, 10.000 llamadas al mes, con Claude Sonnet 5.5 a 2 dólares el millón de entrada. Sin caché son 500 millones de tokens, 1.000 dólares al mes solo en entrada. Leídos de la caché, a 0,10 dólares el millón, son 50 dólares más las escrituras. Si aun así el contexto no cabe o la factura no sale, toca RAG.

Caché de prompts: la rebaja que hay que diseñar

La caché de prompts guarda el principio de la petición cuando se repite y te lo cobra a una fracción del precio: en Claude Sonnet 5.5 y Opus 5.5, al 5 % del precio de entrada; en GPT-6.1 Sol, también al 5 %, y en la mayoría de los demás modelos, al 10 %. En OpenAI funciona sola desde 1.024 tokens; en Claude se activa con un campo cache_control. Los multiplicadores completos están en el artículo de precios.

La caché solo acierta si el principio de la petición es idéntico byte a byte. Eso es una decisión de arquitectura:

• Lo fijo, delante. Primero las definiciones de herramientas y el prompt de sistema; después los documentos estables; al final, la pregunta del usuario.
• Nada variable en el prompt de sistema. Una fecha con hora, un identificador de petición o el nombre del usuario al principio invalidan la caché en cada llamada.
• Mide. Las respuestas indican cuántos tokens se leyeron de la caché (cache_read_input_tokens en Claude). Si sale cero en peticiones repetidas, algo cambia al principio.

Límites de uso, reintentos y plan B

Hay dos tipos de límites y los dos te afectan. Los del proveedor: peticiones y tokens por minuto según tu nivel, y un tope de gasto mensual (500 dólares en el primer nivel de pago de OpenAI y en el nivel Start de Anthropic). Y los tuyos: cuánto puede usar cada usuario de tu aplicación.

Cuando el proveedor te frena, responde con un error 429. Las reglas para tratarlo:

• Reintenta solo lo pasajero. Los SDK oficiales de OpenAI y Anthropic ya reintentan dos veces los errores de conexión, los 429 y los 5xx, con espera creciente y respetando la cabecera retry-after.
• No reintentes lo que no se arregla solo. Un 400 (petición mal hecha) o un 401 (clave mala) fallarán siempre. OpenAI avisa de que reintentar errores de facturación, de crédito o de límite de gasto no devuelve el acceso. En Anthropic, el tope mensual de tu nivel también llega como 429, pero sin retry-after y con el código enforced_spend_limit_reached.
• Sube el tráfico poco a poco. Los dos proveedores tienen límites de aceleración: un salto brusco de peticiones puede dar 429 aunque estés por debajo de tu límite por minuto.

Dentro de tu aplicación, pon límites por usuario (mensajes al día, longitud máxima de la entrada, un max_tokens razonable) y decide qué pasa cuando el modelo no responde: un mensaje claro, un modelo de respaldo de otro proveedor o la función desactivada. Una caída del proveedor no debería tumbar tu aplicación entera.

Coste: estimarlo antes y vigilarlo después

La cuenta básica es sencilla: tokens de entrada por su precio más tokens de salida por el suyo, con el razonamiento contado como salida. Lo que se suele olvidar es que en un chat cada turno reenvía todo lo anterior, así que la entrada crece con cada mensaje. En el artículo de precios hacemos la cuenta de un chatbot de 10.000 conversaciones al mes: entre 14 y 1.434 dólares según el modelo, y la caché recorta entre un 36 % y un 53 % con un modelo intermedio.

Para que el coste no te sorprenda:

• Registra el usage de cada respuesta junto al usuario y la función de tu aplicación que la pidió. Así sabes qué cuesta cada función de tu producto, además del total.
• Separa entornos. Un proyecto (OpenAI) o un espacio de trabajo (Anthropic) para pruebas y otro para producción, cada uno con su clave y su límite.
• Pon topes duros. OpenAI permite un límite de gasto duro por proyecto, además de avisos por correo; Anthropic, límites por organización y por espacio de trabajo; Google, un tope por proyecto en AI Studio.
• Revisa la recarga automática. En OpenAI viene activada al configurar el pago.

Evaluación: cómo saber si funciona (y si sigue funcionando)

Un prompt que funciona con los tres ejemplos que has probado a mano no está probado. Antes de salir, y cada vez que cambies el prompt o el modelo, necesitas un conjunto de pruebas:

1. Entre 20 y 50 casos reales con la respuesta que esperas, incluidos los difíciles y los que deberían rechazarse.
2. Comprobaciones automáticas para lo que se puede verificar con código: el JSON es válido, el campo obligatorio está, la respuesta no pasa de cierta longitud, no menciona a la competencia.
3. Un modelo como juez para lo que no se mide con código (tono, exactitud), con una rúbrica escrita. Revisa a mano una muestra de sus notas: el juez también se equivoca.
4. Revisión humana periódica de conversaciones reales en producción, y un botón de «esta respuesta no me sirve» que alimente nuevos casos de prueba.

OpenAI ofrece evaluaciones dentro de su plataforma (lo explica en su guía de evals), pero un script que recorre tus casos y guarda los resultados en una hoja de cálculo ya es un gran paso. Los fallos más peligrosos son las respuestas inventadas con seguridad; por qué ocurren y cómo reducirlas está en por qué la IA se inventa cosas.

Privacidad y RGPD: qué datos salen y con qué contrato

Cuando envías datos personales a un proveedor de IA, ese proveedor actúa como encargado del tratamiento y el RGPD se aplica igual que con cualquier otro servicio en la nube. Esto es lo que dicen los proveedores a 8 de octubre de 2026.

En OpenAI, los datos enviados a la API no se usan para entrenar desde el 1 de marzo de 2023, salvo que lo autorices expresamente. Los registros de monitorización de abusos se guardan hasta 30 días, y la Responses API guarda el estado de las respuestas 30 días por defecto (se puede desactivar con store: false).

En Anthropic, según su documentación de retención, lo que conserva no se usa para entrenar sin tu permiso expreso. Los modelos Claude Fable y Claude Mythos exigen una retención de 30 días, así que no admiten la retención cero. Su adenda de tratamiento de datos forma parte de sus condiciones comerciales e incluye las cláusulas contractuales tipo de la UE.

En Google, el nivel gratuito de la API de Gemini permite a Google usar tu contenido para mejorar sus productos; el de pago, no. Con datos de clientes, nunca uses el nivel gratuito.

Lo que te toca a ti, con la ayuda de quien lleve la protección de datos en tu empresa:

• Base jurídica e información. Tu política de privacidad tiene que decir que usas un proveedor de IA, para qué y con qué datos.
• Minimización. No envíes lo que el modelo no necesita. Para clasificar una incidencia no hace falta el DNI del cliente: quítalo o sustitúyelo por un identificador antes de llamar.
• Contrato y transferencias. Firma o acepta el contrato de encargo (DPA) de cada proveedor, y si los datos salen de la UE, comprueba qué mecanismo cubre la transferencia.
• Evaluación de impacto si el tratamiento es de riesgo alto (datos de salud, decisiones sobre personas, tratamiento a gran escala).

Esto es un mapa, no asesoramiento legal: con datos sensibles, consulta a un abogado o a tu delegado de protección de datos.

El reglamento europeo de IA también te toca

El artículo 50 del reglamento europeo de IA se aplica desde el 2 de agosto de 2026 y afecta a casi cualquier aplicación con IA de cara al público:

• Si tu aplicación conversa con personas (un chatbot, un asistente, un avatar), quien la ofrece debe diseñarla para que el usuario sepa desde la primera interacción que habla con una IA, salvo que sea evidente.
• Quien ofrece sistemas que generan audio, imagen, vídeo o texto debe marcar ese contenido de forma legible por máquina. Los sistemas que ya estaban en el mercado antes del 2 de agosto de 2026 tienen hasta el 2 de diciembre de 2026 para cumplir esta parte.
• Quien publica deepfakes debe avisar de que lo son, y quien publica textos generados con IA para informar sobre asuntos de interés público también, salvo que haya revisión humana o control editorial.

Las obligaciones de los sistemas de alto riesgo (selección de personal, crédito, educación, entre otros) se han retrasado a diciembre de 2027 y agosto de 2028. El calendario completo y qué significa para cada caso está en nuestra guía del reglamento europeo de inteligencia artificial.

Lista antes de salir a producción

• La clave solo está en el servidor, con un tope de gasto y una por entorno.
• Cada usuario tiene un límite de uso, y hay max_tokens en cada llamada.
• Los errores 429 y 5xx se reintentan; los 400 y 401, no; y hay un mensaje claro cuando el modelo no responde.
• Las respuestas largas van en streaming.
• Lo que lee tu código llega en JSON con esquema y se valida antes de usarse.
• Las herramientas tienen los permisos mínimos y lo irreversible pide confirmación.
• El prompt fijo va delante y la caché se mide.
• Se registra el usage de cada petición por usuario y por función.
• Hay un conjunto de pruebas y se pasa con cada cambio de prompt o de modelo.
• La política de privacidad menciona al proveedor, hay DPA y los datos se minimizan.
• El usuario sabe que habla con una IA.

Por dónde seguir

Esta guía tiene cuatro piezas que la completan:

• Primeros pasos con la API de OpenAI y de Claude: cuenta, clave y primera llamada en Python, JavaScript y curl.
• Precio de la API de OpenAI, Claude y Gemini: la tabla oficial y los cálculos de un chatbot, 1.000 resúmenes y 100.000 clasificaciones.
• Qué hacer si se filtra una API key: revocar, limpiar el historial y evitar que se repita.
• Cómo publicar gratis una web hecha con IA: si tu aplicación es una web, dónde alojarla sin pagar.

Y si tu aplicación tiene que responder con tus documentos, el siguiente paso es RAG.