Desplegar un modelo de lenguaje en producción no es descargar un ZIP y ejecutar un comando. He visto equipos gastar meses en una prueba de concepto que funcionaba en el portátil de un ingeniero y se caía el primer lunes con veinte usuarios concurrentes. Esta guía describe el proceso real de configuración, con las decisiones que importan y los puntos donde casi todos tropiezan.
Antes de tocar nada: define el caso de uso y el criterio de éxito
La configuración técnica depende del trabajo que vaya a hacer el modelo. No es lo mismo un asistente interno que responde sobre documentación corporativa (recuperación aumentada sobre PDFs) que un clasificador de tickets de soporte (una tarea acotada donde un modelo pequeño bien ajustado gana a uno grande con prompt genérico).
Escribe una frase concreta antes de elegir proveedor: «el comercial escribe una pregunta sobre precios y recibe una respuesta con el enlace al apartado del catálogo en menos de tres segundos». Si no puedes medir eso, no puedes configurar nada con criterio.
Un error común: equipos que empiezan pidiendo «un ChatGPT interno» sin acotar dominio ni fuentes. El resultado es un chat que alucina con la política de vacaciones porque nadie le dio acceso al documento correcto. Acota las fuentes antes que el modelo.
Decisión 1: API gestionada, modelo abierto autoalojado o híbrido
Tres rutas reales, con costes y fricciones distintas:
- API de un proveedor cloud: pones en marcha en horas. El coste es variable por token y la latencia depende de la red. Apto para casi todo, salvo cuando hay datos que no pueden salir del perímetro.
- Modelo abierto en tu infraestructura: control total del dato, coste fijo de GPU. Requiere saber operar inferencia: cuantización, memoria de vídeo, colas de peticiones. Un modelo de 7-8 mil millones de parámetros en cuantización de 4 bits corre en una GPU de 24 GB; uno de 70B necesita varias o cuantizaciones agresivas que degradan la calidad.
- Híbrido: modelo pequeño local para clasificar y enrutar, modelo grande vía API solo para las consultas complejas. Reduce coste y exposición de datos.
Según documentación oficial de los principales frameworks de inferencia (vLLM, TGI, Ollama), el rendimiento en producción depende más del batching y de la gestión de la caché KV que del modelo elegido. Un servidor mal configurado con un modelo excelente da peor experiencia que uno bien ajustado con un modelo mediano.
El factor que nadie presupuesta: la GPU
Si optas por autoalojar, calcula memoria antes de comprar. Regla práctica: parámetros en miles de millones × bytes por parámetro según cuantización (≈0,5 bytes en 4 bits, ≈1 byte en 8 bits, ≈2 bytes en 16 bits) más el espacio para el contexto. Un 7B en FP16 ocupa unos 14 GB solo en pesos; con contexto largo te quedas sin VRAM antes de lo que crees.
Decisión 2: cómo le das el conocimiento de la empresa
Aquí está el 80% del trabajo real. Dos aproximaciones:
Recuperación aumentada (RAG)
Troceas documentos, generas embeddings, los guardas en un índice vectorial y en cada consulta recuperas los fragmentos relevantes para inyectarlos en el prompt. Pasos de configuración:
- Ingesta con control de versiones. Cada documento lleva metadatos: fuente, fecha, departamento, permisos. Sin permisos en los metadatos, un becario puede leer actas del consejo.
- Troceado consciente. Fragmentos de 300-800 tokens con solapamiento. Trocear por caracteres rompe tablas y listas; trocea por estructura (encabezados, párrafos).
- Embeddings y reindexado. Elige un modelo de embeddings multilingüe si hay documentos en varios idiomas. Planifica reindexar cuando cambie el corpus; un índice obsoleto responde con datos de hace dos años sin avisar.
- Recuperación híbrida. Combina búsqueda semántica con búsqueda léxica (BM25). Los códigos de producto y nombres propios fallan en la búsqueda puramente vectorial.
- Reranking y umbral. Un reranker descarta fragmentos irrelevantes. Define un umbral: si la similitud es baja, el asistente debe decir «no lo sé» en lugar de inventar.
Ajuste fino (fine-tuning)
Útil para estilo, formato de salida y tareas repetitivas con muchos ejemplos etiquetados. No es la herramienta para inyectar conocimiento cambiante: un modelo ajustado con el catálogo de enero seguirá respondiendo con el de enero. Para datos que cambian, RAG.
Configuración del prompt de sistema y las salvaguardas
El prompt de sistema es configuración, no redacción creativa. Define: rol, tono, límites, formato de salida y qué hacer ante la duda. Sé explícito con el formato si vas a parsear la respuesta (JSON con esquema fijo, por ejemplo) y valida la salida con un parser antes de mostrarla al usuario.
Salvaguardas mínimas que debes configurar:
- Filtro de entrada y salida para datos personales según la política interna.
- Límite de longitud de contexto y de tokens de salida (evita costes desbocados).
- Registro de conversaciones con retención definida y acceso auditado.
- Rate limiting por usuario y por IP.
- Botón de «reportar respuesta incorrecta» que alimente una cola de revisión.
Un detalle que descubres en producción: los usuarios pegan conversaciones completas de otros chats en el prompt. Sin límite de longitud, el coste por sesión se multiplica y el modelo se distrae con contexto irrelevante.
Integración con los sistemas de la empresa
El asistente rara vez vive aislado. Configuración típica:
- Capa de orquestación (backend propio o framework de agentes) que recibe la petición, decide si consulta el índice, llama a una herramienta o responde directamente.
- Conectores a sistemas internos vía API con credenciales de servicio de solo lectura y permisos mínimos. Nunca des al modelo credenciales de escritura sobre el ERP en la primera versión.
- Autenticación y herencia de permisos. El asistente debe responder solo con lo que el usuario puede ver. Esto se implementa en la capa de recuperación, no en el prompt: pedirle al modelo que «no revele datos confidenciales» no es un control de acceso.
- Observabilidad. Trazas por petición: tokens de entrada y salida, latencia, fragmentos recuperados, coste estimado. Sin esto no puedes optimizar ni justificar el gasto.
Prueba con datos reales antes de abrir la puerta
Monta un conjunto de evaluación con preguntas reales de usuarios y respuestas esperadas. Mide: precisión de la respuesta, tasa de «no lo sé» correctos, latencia percentil 95 y coste medio por consulta. Según estudios del sector, una parte significativa de los fallos en asistentes corporativos proviene de la recuperación, no de la generación: el modelo responde bien a un fragmento equivocado.
Prueba también los casos límite: preguntas ambiguas, peticiones fuera de dominio, intentos de manipulación del prompt. Y revisa el comportamiento con documentos escaneados mal digitalizados: el OCR sucio genera respuestas con cifras corruptas.
Despliegue gradual y mantenimiento
Empieza con un grupo piloto de diez o veinte personas de un solo departamento. Recoge feedback durante dos semanas, ajusta el prompt y el corpus, y solo entonces amplía. Ten un plan de vuelta atrás: poder desactivar el asistente sin romper el flujo de trabajo del equipo.
Mantenimiento continuo imprescindible: reindexar cuando cambien los documentos, revisar costes semanales, monitorizar latencia y actualizar el modelo cuando aparezca una versión mejor solo tras pasar la evaluación. Cambiar de modelo sin evaluar es la forma más rápida de degradar un sistema que funcionaba.
Lo que este enfoque no resuelve
Un LLM configurado así no sustituye a un sistema de reglas en procesos donde la exactitud es obligatoria (cálculo de nóminas, cumplimiento normativo con cifras). Tampoco es fiable para razonamiento matemático complejo sin herramientas externas. Y no elimina la necesidad de revisión humana en comunicaciones externas sensibles.
La configuración paso a paso que funciona es la que empieza acotada, mide, y amplía solo lo que demuestra valor. El resto es gasto en tokens.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.