Cómo llevar un modelo de lenguaje a producción sin confundir demo y servicio

Reeditado el 30 de julio de 2026, este artículo propone una regla sencilla: un modelo de lenguaje no se despliega; se despliega un servicio alrededor de él. La diferencia incluye datos de entrada, instrucciones, recuperación de documentos, herramientas, filtros, permisos, personas, interfaz y respuesta a incidentes. Una puntuación de laboratorio describe solo una parte de ese sistema.

En una demo, una respuesta incorrecta puede provocar una sonrisa. En atención sanitaria, crédito, educación o soporte técnico puede cambiar una decisión, exponer datos o consumir horas de revisión. La pregunta útil no es «¿qué modelo rinde mejor?», sino «¿qué flujo admite este nivel de error, quién lo detecta y qué ocurre después?». Convertir una capacidad en servicio exige una ficha operativa antes de escribir código.

Del benchmark a una tarea con consecuencias

El primer paso es reducir el propósito a una unidad observable: clasificar solicitudes, extraer campos, proponer una respuesta o resumir un expediente. «Entender al cliente» o «ayudar al médico» son aspiraciones, no especificaciones. Para cada tarea se definen entrada permitida, salida, usuario, decisión posterior, plazo y coste de los errores.

La evaluación HELM mostró por qué una sola métrica es insuficiente: escenarios diferentes requieren considerar exactitud, calibración, robustez, equidad, sesgo, toxicidad y eficiencia. Un promedio puede ocultar que el sistema funciona en preguntas frecuentes y falla precisamente en reclamaciones, dialectos o instrucciones largas. El conjunto de prueba interno debe parecerse al tráfico futuro y conservar los casos difíciles.

La línea base importa. Una búsqueda, una plantilla, reglas o un modelo pequeño pueden resolver la tarea con menos variación. El modelo más capaz no siempre es el mejor componente: latencia, disponibilidad, jurisdicción de datos, coste de revisión y posibilidad de reproducir una salida cambian la decisión. La mejora se mide sobre el proceso completo, no solo sobre la calidad aparente de un texto.

Antes del piloto se fija un presupuesto de fallo. ¿Qué tasa de campos erróneos es tolerable? ¿Qué acciones jamás puede ejecutar el sistema? ¿Cuándo debe abstenerse? ¿Qué muestra se revisará cada semana? Sin umbral previo, el equipo tiende a reinterpretar los errores después de haber invertido y convierte impresiones en aprobación.

El piloto puede empezar en modo sombra: procesa casos reales, pero su salida no decide ni llega al usuario. Se compara con el proceso vigente y se registran desacuerdos. Después se abre a un grupo limitado, con reversión rápida y criterios de salida. Esta secuencia permite descubrir efectos de interfaz y carga de revisión que un benchmark estático no contiene. «Funciona» significa superar los umbrales acordados durante un periodo representativo, no completar una demostración escogida.

Datos, documentación y límites conocidos

Los datos atraviesan el servicio en varias direcciones: indicaciones del usuario, documentos recuperados, registros, correcciones humanas y, a veces, material enviado a un proveedor. Cada flujo necesita finalidad, base jurídica, retención, acceso y borrado. Quitar nombres visibles no siempre anonimiza; el texto libre puede contener números, historias y combinaciones que identifican.

Las Datasheets for Datasets proponen documentar motivación, composición, recogida, preprocesamiento, usos y mantenimiento de un conjunto. Las model cards hacen algo equivalente para modelos: usos previstos, factores, métricas, datos de evaluación y limitaciones. En producción conviene añadir versión de la indicación, herramientas, fuentes recuperadas y filtros, porque todos pueden cambiar la conducta.

Sesgo no es una sustancia que se elimina una vez. Es una diferencia relevante para una población y una decisión. La auditoría define grupos, daños y métricas con personas que conocen el contexto; prueba datos reales; y examina tanto falsos positivos como falsos negativos. Un filtro de palabras no arregla una cobertura lingüística desigual ni una política que ya discrimina.

La privacidad requiere minimizar antes de enviar. Si un campo no es necesario, no se incluye. Los secretos se separan del texto, los permisos se aplican a las herramientas y la recuperación respeta los controles del repositorio original. El Reglamento General de Protección de Datos contiene principios como limitación de finalidad, minimización, exactitud, limitación del plazo y seguridad; no basta con añadir una casilla de consentimiento al final.

Seguridad: tratar el texto externo como entrada no confiable

Un modelo conectado a correo, web o documentos puede recibir instrucciones dentro del propio contenido. Esa inyección de indicaciones intenta hacer que el sistema ignore su tarea, revele datos o use herramientas de forma indebida. El catálogo OWASP Top 10 for LLM Applications incluye inyección, divulgación de información sensible, manejo inseguro de salidas y agencia excesiva entre los riesgos.

La defensa no consiste en una frase más fuerte en el prompt. Se separan datos e instrucciones, se limitan herramientas por identidad y tarea, se validan argumentos, se confirman acciones de alto impacto y se escapan las salidas antes de pasarlas a código, bases de datos o navegadores. Un modelo no debe decidir por sí mismo qué permisos necesita.

También se diseña la degradación. Si falla el proveedor, desaparece una fuente o sube la latencia, el servicio puede pasar a búsqueda, plantilla o cola humana. Los registros conservan versión, entradas relevantes, fuentes, acciones y resultado, respetando la privacidad. Un interruptor de apagado útil tiene dueño, criterio y ensayo; no es un botón dibujado que nadie se atreve a pulsar.

El perfil de IA generativa del NIST organiza riesgos y acciones a lo largo del ciclo de vida, incluyendo confabulación, privacidad, integridad de la información, seguridad y cadena de valor. Su valor práctico es recordar que una mitigación necesita responsable, medición y seguimiento, no solo una advertencia en la interfaz.

Regulación, supervisión y responsabilidad

El Reglamento de IA de la Unión Europea no impone una obligación universal de que todo modelo «justifique cada decisión». Distingue actores, usos, sistemas de alto riesgo, obligaciones de transparencia y modelos de propósito general. Para saber qué aplica hay que clasificar el rol de la organización y el uso previsto, no inferirlo del nombre de la tecnología.

La supervisión humana tampoco se satisface poniendo a alguien frente a una pantalla. Esa persona necesita tiempo, información, competencia, autoridad para discrepar y una interfaz que no empuje a aceptar. Se mide cuánto corrige, qué errores no ve y cuándo el volumen convierte la revisión en trámite. En decisiones sensibles, el usuario afectado necesita una vía de explicación, rectificación y recurso adecuada al proceso.

Un registro de responsabilidades asigna propietario del producto, de datos, de seguridad, del dominio y de cumplimiento. Define quién aprueba cambios de modelo o prompt, quién recibe incidentes y quién puede detener el servicio. El proveedor aporta documentación, pero la organización que integra y usa el sistema conserva obligaciones sobre su propio contexto.

Coste, energía y vigilancia después del lanzamiento

La huella no se resume en una cifra viral sobre «un entrenamiento». El análisis de emisiones de carbono de grandes redes muestra que hardware, ubicación, mezcla eléctrica, eficiencia del centro de datos y tiempo cambian el resultado. En un servicio, además del entrenamiento cuentan inferencia, almacenamiento, redes, experimentos, modelos auxiliares y volumen. Se informa el denominador: por consulta, usuario o tarea completada.

La destilación de conocimiento puede transferir conducta de un modelo o conjunto grande a uno más pequeño. También existen cuantización, almacenamiento en caché, enrutado y reducción de contexto. Cada optimización requiere volver a medir calidad, subgrupos y seguridad; comprimir puede alterar los fallos. La opción más eficiente sigue siendo no llamar a un modelo cuando una regla fiable basta.

Tras el lanzamiento se vigilan distribución de entradas, tasa de abstención, correcciones, reclamaciones, incidentes, latencia y coste. Una muestra periódica se reevalúa con criterios fijos. Los cambios de proveedor, versión, herramientas o corpus de recuperación activan pruebas de regresión. No se espera a que caiga la métrica media: un daño grave puede ser raro.

La capacidad transferible es convertir cualquier demo en una especificación de servicio: tarea, datos, prueba, presupuesto de fallo, permisos, escalado humano, regulación, coste y monitorización. Si uno de esos campos está vacío, el piloto aún está formulando una hipótesis. Implementar con rigor no frena la utilidad del modelo; establece dónde esa utilidad es real y quién responde cuando deja de serlo.