De curiosidad de laboratorio a pieza obligatoria del stack

En 2023, montar un endpoint contra GPT-3.5 para clasificar tickets era vudú. Tres años después, cualquier dev junior conecta una API de Claude o GPT-4 en una tarde y deja un clasificador en producción antes de cenar. El salto es brutal, y no solo por el modelo: ha cambiado lo que el usuario espera del software. Si tu aplicación no entiende contexto ni sugiere la siguiente acción, queda vieja en meses.

Si eres CTO de una aplicación web a medida, la conversación ya no es "¿metemos IA?". Es "¿cómo, sin que se caiga el sistema, sin que el CFO entre en pánico con la factura de tokens y sin abrir un agujero por el que se cuele media base de datos?". Vamos a recorrer ese camino: dónde empezar, qué arquitectura aguanta, qué prompts sobreviven y cómo testear algo no determinista.

Dónde un LLM te devuelve euros, y dónde no

Antes de tocar código, un ejercicio honesto: pasear por el producto y marcar dónde hay un humano leyendo o reescribiendo lo mismo cien veces al día. Ahí un modelo de lenguaje devuelve dinero. En el resto, suele ser ruido caro.

Redactar y resumir lo que nadie quiere redactar

Borradores de emails transaccionales, resúmenes de soporte, notas internas de un CRM. Un LLM se come ese trabajo y reduce el tiempo de redacción entre un 60 y un 70 por ciento. Eso sí, nada llega al usuario sin filtro: reglas de negocio, validación de tono o, si el riesgo es alto, revisión humana.

Clasificar con criterio, no con expresiones regulares

Tickets, formularios, solicitudes internas. Los clasificadores basados en palabras clave llevan décadas fallando con cualquier matiz. Un LLM lee la intención, capta el sarcasmo, distingue una queja de una pregunta. Los falsos positivos caen en cuanto sustituyes esas reglas frágiles por una llamada bien instruida.

Extracción estructurada: el caso de uso que paga la fiesta

Facturas en PDF, contratos escaneados, correos con datos dispersos. Combina OCR si hace falta, pide salida JSON con campos definidos y vuelcas a base de datos. He visto este patrón eliminar puestos enteros de entrada manual con acierto por encima del 95 por ciento si el prompt está afinado.

Asistentes que conocen tu producto

No hablo del chatbot genérico de FAQs. Hablo de un asistente con acceso a tu base de conocimiento mediante RAG, que consulta tu API para responder con datos reales del usuario. Es el caso de uso con más impacto percibido y el más difícil de hacer bien. Vale la pena.

API gestionada o modelo en tu propio servidor

La primera decisión arquitectónica: ¿tiras de la API de OpenAI, Anthropic o Google, o despliegas un Llama 3 en tu GPU? No hay respuesta universal. Hay cuatro ejes que pesan, y depende de cuál duela más en tu contexto.

Privacidad y normativa

Si manejas datos sanitarios, financieros o algo que el RGPD mire de cerca, necesitas saber dónde acaba cada token. Las APIs serias firman DPAs y ofrecen residencia en la UE, pero algunos compliance officers no duermen tranquilos hasta que el modelo corre en su VPC. Mide el riesgo real: a veces el autoalojamiento es un capricho caro disfrazado de seguridad.

Latencia y dependencia de red

Una API externa añade un salto de red, y en flujos síncronos críticos —una validación durante un checkout— cada centésima cuenta. Un modelo autoalojado elimina esa latencia, pero te toca mantener GPUs y rezar para que no se cuelgue un martes a las nueve.

El coste real cuando subes el volumen

Con volúmenes modestos, la API gana siempre: pagas céntimos por mil tokens y olvidas la infraestructura. A partir de cierto umbral —antes de lo que crees si tu app es transaccional— el coste se vuelve goteo constante. Calcula con tus volúmenes a doce meses, picos incluidos, y compáralo con el TCO de una GPU dedicada.

Velocidad a la que evoluciona el modelo

Las APIs gestionadas estrenan modelos cada pocos meses, normalmente mejores y más baratos. Si autoalojas, controlas cuándo cambias, lo que da estabilidad pero te puede dejar dos generaciones por detrás mientras la competencia sirve respuestas más finas.

Patrones de arquitectura que sobreviven al primer año

Da igual si usas API o modelo propio: lo que decide si la integración aguanta es cómo la ensamblas. El modelo es el motor; la arquitectura es el chasis y los frenos.

Servicio dedicado: aísla la rareza

Mete toda la lógica de IA en un microservicio aparte con su propia API interna. Tus servicios de negocio le hablan en HTTP o gRPC y reciben respuestas estructuradas. Cuando salga un modelo mejor, cambias el proveedor en un sitio. Cuando el coste se dispare, escalas o limitas en un sitio. Cuando algo falle, sabes dónde mirar.

Capa de prompts: trátalos como código

Nunca incrustes un prompt como literal en un controlador. Crea una capa con plantillas versionadas, variables de contexto, fallbacks y registro de qué versión generó cada respuesta. Te permite iterar sin redesplegar, hacer A/B real y, cuando un cliente diga que el asistente respondió algo raro hace dos semanas, reconstruir qué se le pidió al modelo.

Colas asíncronas: deja de bloquear al usuario

Muchas tareas no necesitan respuesta inmediata. Resúmenes nocturnos, clasificación batch, informes. Manda esos jobs a una cola —SQS, RabbitMQ, Redis Streams— y procésalos en segundo plano. Suavizas picos contra la API, reduces rate limits y dejas de torturar al usuario con un spinner de catorce segundos.

Prompt engineering sin esoterismo

El prompt es el contrato entre tu aplicación y el modelo. Si lo escribes mal, recibes basura. Si lo escribes bien, el modelo es tan fiable como cualquier otro servicio de tu stack.

Anatomía de un prompt que aguanta producción

Cuatro bloques: rol del sistema, instrucciones explícitas (qué hace y qué no), contexto relevante (datos del usuario, historial, restricciones) y formato de salida exigido. Cuanto más cierres el formato —idealmente con structured output o function calling—, más fácil parsear sin romper. Pedir "responde en JSON con estos campos" funciona; exigirlo con schema enforcement funciona mucho mejor.

Temperatura: el dial que casi nadie mira

Para clasificación y extracción, donde quieres consistencia, mantén la temperatura entre 0.0 y 0.3. Para generación creativa, sube a 0.7 o 0.9. Documenta esos valores por caso de uso: no los dejes como constantes mágicas en un config.py.

Lo que viene de vuelta: validar siempre

Un LLM puede sorprender incluso con el prompt mejor escrito. Tu aplicación tiene que asumirlo.

Validación de esquema, no de fe

Si esperas JSON, valida contra un schema explícito (JSON Schema, Zod, Pydantic). Si falla, reintentas con prompt corregido o devuelves un fallback. Confiar en que el modelo "casi siempre devuelve bien el JSON" es la receta perfecta para una incidencia de fin de semana.

Límites de longitud

Los modelos pueden enrollarse. Define max_tokens en la llamada y trunca o resume en tu capa de aplicación si excede lo que la UI puede mostrar.

Moderación propia

Aunque los modelos modernos traen filtros internos, añade tu capa cuando el contenido vaya a usuarios finales. Lista de términos prohibidos más un clasificador de toxicidad cubre el 90 por ciento de los disparates. El otro 10 por ciento es por lo que existe el feedback humano.

Que la factura de tokens no te dé un susto

El coste se mide en tokens, y suma rápido. Estas prácticas mantienen la factura en territorio razonable.

• Caché agresivo: si un mismo input produce siempre el mismo output (clasificaciones deterministas, extracciones de campos fijos), cachea y olvida. La diferencia es brutal.
• Modelos escalonados: usa un modelo barato (Haiku, GPT-4o-mini, un Llama pequeño) como primer filtro, y reserva el modelo potente para los casos que lo justifiquen. Suele dividir el coste entre tres o cuatro.
• Rate limiting por usuario: protege el presupuesto y evita que un script accidental se coma tu gasto mensual en una tarde.
• Observabilidad granular: registra el coste de cada llamada vinculado al caso de uso que la generó. Sin esa visibilidad por feature, optimizar es a ciegas.

Seguridad: nuevos vectores, viejos principios

Integrar un LLM abre puertas que en una web tradicional no existían. Conviene cerrarlas desde el día uno.

Prompt injection: el XSS de los LLMs

Un usuario malintencionado puede meter instrucciones en su input para reescribir el prompt del sistema. Separa el prompt de sistema del input de usuario, sanitiza entradas y limita lo que el modelo puede hacer aguas abajo: nunca le des acceso directo a ejecutar SQL, código arbitrario o APIs sensibles sin validación intermedia.

Datos que se van al proveedor

Si inyectas datos sensibles en el prompt —clientes, importes, historiales médicos—, viajan al proveedor. Minimiza lo que mandas, usa identificadores en lugar de payloads completos y revisa las políticas de retención. "Zero retention" no es lo mismo en todos los planes.

Auditoría completa

Registra cada interacción: prompt, respuesta, latencia, coste, usuario. Sirve para depurar incidencias, defender decisiones del modelo ante un cliente cabreado y, en sectores regulados, suele ser obligatorio.

Testear lo no determinista sin volverse loco

Los tests clásicos asumen determinismo. Con un LLM, dos llamadas idénticas pueden devolver respuestas distintas. Esto rompe el manual de QA tradicional.

Tests de contrato

Verifica que la respuesta cumple el esquema (campos, tipos, longitudes razonables), no que el texto coincida palabra por palabra con una referencia fija. Eso es perder el tiempo.

Regresión semántica con embeddings

Compara la respuesta nueva contra una de referencia usando embeddings y similitud coseno. Detectas derivas de calidad cuando cambias de modelo o ajustas el prompt, sin exigir coincidencia literal.

Feature flags y rollout progresivo

Antes de soltar una funcionalidad de IA al 100 por ciento de tu base, despliega con flags a un 5 o 10 por ciento. Mide aceptación, rechazos, ediciones manuales. Si los números aguantan, escalas. Si no, retiras sin ruido.

La IA en producción es 20 por ciento modelo y 80 por ciento plomería

Integrar inteligencia artificial y modelos de lenguaje en una aplicación web a medida no es un proyecto de todo o nada. Es elegir un caso de uso acotado, medir su impacto, iterar sobre prompt y arquitectura, y expandir cuando los números acompañen. Lo que separa una integración que aguanta de otra que acaba comentada en el código es la disciplina alrededor: servicio dedicado, prompts versionados, respuestas validadas, costes observados y seguridad desde el primer commit. El modelo es la parte sexy; el resto decide si vive o muere en producción.

Si estás dándole vueltas a cómo meter LLMs en los flujos de tu aplicación y quieres un equipo que haya pasado por esta plomería unas cuantas veces, hablamos cuando quieras.