Antes de tocar código: decisiones que condicionan todo
Integrar un modelo de lenguaje en una web no empieza instalando un SDK. Empieza respondiendo tres preguntas que determinan el resto de la checklist: qué tarea concreta resuelve el LLM, dónde se ejecuta la inferencia y quién asume el coste por token. Si no tienes respuesta cerrada para las tres, cualquier integración acabará siendo un prototipo caro que nadie mantiene.
Esta lista de comprobación está ordenada por fases reales de proyecto. No es una guía teórica: cada punto incluye el motivo por el que existe y el fallo típico que evita. Algunos puntos no aplican a todos los casos y lo indico explícitamente.
Fase 1. Definición del caso de uso (no saltes esta parte)
1.1. Escribe la tarea en una frase verificable
«Mejorar la experiencia del usuario» no es una tarea. «Clasificar tickets de soporte entrantes en cinco categorías con una etiqueta de confianza» sí lo es. Si no puedes medir si la respuesta del modelo es correcta, no puedes integrarlo con garantías.
1.2. Comprueba si un LLM es realmente necesario
Muchas tareas que se atribuyen a LLMs se resuelven con reglas, expresiones regulares o un clasificador clásico más barato y determinista. Un LLM brilla en lenguaje libre, ambigüedad y generación; falla en cálculos exactos, lógica estricta y datos que cambian cada minuto. Si tu caso es «extraer un importe de una factura con formato fijo», probablemente no necesites un modelo generativo.
1.3. Define el coste máximo aceptable por interacción
Los precios por millón de tokens varían mucho entre proveedores y entre modelos de la misma familia. Antes de integrar, calcula: longitud media del prompt + longitud media de la respuesta × volumen diario estimado. Un chatbot que recibe 3.000 consultas al día con prompts de 2.000 tokens puede costar más que el hosting anual del sitio. Ten ese número antes de escribir la primera línea.
Fase 2. Arquitectura y seguridad
2.1. La clave de API nunca viaja al navegador
Este es el error más común y el más caro. Cualquier llamada desde JavaScript del cliente expone la clave en las herramientas de desarrollo. La llamada al proveedor debe salir de tu servidor o de una función edge. Si necesitas streaming hacia el navegador, usa un proxy en tu backend que reenvíe los chunks.
2.2. Decide entre API externa y modelo autoalojado
API externa: rápida de implementar, sin infraestructura, pero dependes de disponibilidad y precios del proveedor, y los datos salen de tu entorno. Modelo autoalojado (por ejemplo, pesos abiertos servidos con herramientas de inferencia locales): control total y coste fijo, pero exige GPU, mantenimiento y know-how. Para webs pequeñas o medianas, la API suele ser la decisión sensata; para datos sensibles con requisitos estrictos de residencia, el autoalojamiento puede ser obligatorio.
2.3. Filtra y minimiza los datos que envías
Antes de mandar un prompt, elimina identificadores personales, correos y datos de pago que el modelo no necesita. No es solo cumplimiento normativo: reduce tokens y mejora la calidad de la respuesta al eliminar ruido.
2.4. Protección frente a prompt injection
Si el LLM procesa contenido que el usuario controla (comentarios, descripciones de producto, textos pegados), asume que ese contenido puede contener instrucciones maliciosas. Mitigaciones prácticas: separa instrucciones del sistema y contenido del usuario con delimitadores claros, valida la salida contra un esquema, y nunca dejes que la salida del modelo dispare acciones destructivas sin confirmación humana.
Fase 3. Diseño del prompt y de la salida
3.1. Instrucción del sistema estable y versionada
Guarda el prompt del sistema en un archivo con control de versiones. Cuando cambies una palabra, podrás comparar resultados. Los prompts que viven dentro del código mezclados con la lógica de negocio son imposibles de auditar.
3.2. Salida estructurada siempre que sea posible
Si el resultado alimenta una base de datos o una interfaz, pide JSON con un esquema definido y valida la respuesta con un parser estricto. Si el modelo devuelve texto libre y tú haces split por comas, romperás en cuanto el modelo cambie de formato. La mayoría de proveedores actuales ofrecen modos de salida estructurada; úsalos.
3.3. Incluye ejemplos en el prompt (few-shot)
Dos o tres ejemplos de entrada-salida correcta suelen mejorar más el resultado que párrafos de instrucciones. Cuestan tokens, así que resérvalos para tareas donde el formato importa.
3.4. Define el comportamiento ante la duda
Indica explícitamente qué debe hacer el modelo cuando no sabe: devolver un campo confianza: baja, una frase concreta de derivación a humano, o una respuesta vacía que tu interfaz interprete. Sin esta instrucción, el modelo inventará con total seguridad.
Fase 4. Integración en el frontend
4.1. Estados de carga y cancelación
Las respuestas generativas tardan segundos. La interfaz necesita un estado de espera visible y un botón de cancelar que aborte la petición. Si usas streaming, muestra el texto a medida que llega: reduce la percepción de lentitud de forma notable.
4.2. Accesibilidad del componente
El contenedor de respuestas debe tener aria-live=»polite» para que los lectores de pantalla anuncien el texto nuevo. El streaming sin gestión de accesibilidad genera experiencias rotas para usuarios con lectores de pantalla.
4.3. Límites en el cliente y en el servidor
Limita la longitud de entrada en ambos lados. Un campo de texto sin límite es una vía directa a prompts gigantes que inflan tu factura. Añade también un límite de peticiones por sesión o por IP.
Fase 5. Calidad, evaluación y monitorización
5.1. Conjunto de pruebas con respuestas esperadas
Antes de publicar, reúne entre 30 y 100 casos representativos con la respuesta correcta anotada a mano. Ejecuta el prompt contra ellos cada vez que lo modifiques. Sin este banco de pruebas, cada cambio es una apuesta.
5.2. Registro de peticiones y respuestas (con cuidado)
Guarda el prompt, la respuesta y la latencia para poder depurar. Anonimiza antes de almacenar y define un periodo de retención. Un log sin política de retención se convierte en un pasivo.
5.3. Alertas de coste y de latencia
Configura un umbral de gasto diario que te avise antes de que la factura se descontrole. Un bucle infinito en el cliente o un bot que repite peticiones pueden multiplicar el consumo en horas.
Fase 6. SEO y visibilidad
6.1. El contenido generado no se indexa por arte de magia
Si el LLM genera páginas o fragmentos que quieres posicionar, necesitan URL propia, título, meta descripción y renderizado en servidor. Un widget que genera texto dentro de un div tras una interacción del usuario no aporta nada al rastreo.
6.2. No generes contenido masivo sin revisión
Las políticas de calidad de los buscadores desincentivan el contenido producido a escala sin valor añadido. Si usas el LLM para redactar, úsalo como borrador con revisión editorial. Según la documentación oficial de los principales buscadores, el criterio sigue siendo la utilidad para el usuario, no el método de producción.
6.3. Bloquea o marca las rutas internas del asistente
Los endpoints de tu API y las rutas de generación no deben ser rastreables ni indexables. Añade noindex y restricciones en robots.txt donde corresponda.
Fase 7. Lanzamiento y mantenimiento
7.1. Despliegue progresivo
Activa la función para un porcentaje de usuarios primero. Mide tasa de error, latencia y satisfacción antes de abrirlo a todo el tráfico.
7.2. Plan de degradación
¿Qué pasa si el proveedor devuelve errores 429 o 500? Define una respuesta de reserva: mensaje de indisponibilidad, formulario de contacto o respuesta cacheada. Un asistente que rompe la página cuando falla la API es peor que no tener asistente.
7.3. Revisión periódica del modelo
Los proveedores retiran versiones de modelos con avisos previos. Anota la fecha de deprecación de la versión que uses y prueba la migración antes de que sea forzosa. Los prompts afinados para una versión pueden comportarse distinto en la siguiente.
Un caso concreto y su lección
En un proyecto de asistente para una tienda de componentes, el equipo probó el prompt con preguntas de catálogo y funcionaba bien. Al publicarlo, los usuarios empezaron a preguntar por compatibilidades entre piezas. El modelo respondía con seguridad sobre combinaciones que no existían en el catálogo. La causa: el prompt incluía una muestra de productos, no el catálogo completo, y el modelo rellenaba los huecos con plausibilidad. La solución no fue un prompt mejor, sino recuperar los productos relevantes de la base de datos y pasarlos como contexto en cada consulta. Lección: si la respuesta depende de datos que cambian, el modelo necesita acceso a esos datos en el momento de la consulta, no una muestra estática en el prompt.
Lo que esta checklist no resuelve
No hay garantía de que el modelo responda correctamente a todo. Los LLMs alucinan, y ninguna configuración elimina ese comportamiento por completo. Tampoco existe un prompt perfecto: lo que funciona hoy puede degradarse con la siguiente actualización del proveedor. Y hay tareas donde un LLM no es la herramienta adecuada: búsquedas exactas, cálculos financieros, filtros deterministas. Reconocerlo a tiempo ahorra presupuesto y frustración.
Si repasas estas fases en orden y dejas por escrito las decisiones de cada una, tendrás algo más valioso que una integración funcionando: tendrás una integración que puedes mantener cuando cambie el modelo, el proveedor o el equipo.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.