Sin equipo de ML: quién opera tras el lanzamiento un sistema LLM para tickets de soporte y documentos en tus propios servidores

Un sistema LLM que clasifica tickets de soporte y lee documentos en tus propios servidores sigue necesitando a alguien que lo opere después del lanzamiento. LLM son las siglas en inglés de modelo de lenguaje grande, el tipo de IA que hay detrás de ChatGPT. Una empresa sin equipo de aprendizaje automático (ML) tiene tres vías. La empresa que construyó el sistema puede seguir operándolo con un acuerdo de soporte. Tras un traspaso, tu equipo de TI puede hacerse cargo de él o repartirse el trabajo con esa empresa. En cualquiera de las vías, alguien tiene que comprobar la calidad de las respuestas de forma periódica y aprobar cada cambio de modelo antes de que entre en producción.

¿Qué supone operar un sistema LLM después del lanzamiento?

Después del lanzamiento, operar un sistema LLM se reduce a estas tareas recurrentes:

• Los servidores, que a menudo llevan GPU (los chips en los que funcionan los modelos de lenguaje), y las actualizaciones del software que ejecuta el modelo
• La versión del modelo en uso y la decisión de cuándo cambiarla
• La puntuación periódica de las respuestas con una muestra fija de tus propios tickets y documentos
• La cola de revisión, es decir, los casos que el software pasa a una persona, y el personal que la atiende
• Los cambios de tu lado, como un formulario nuevo, una nueva categoría de tickets o una nueva regla de negocio
• Los logs, que registran lo que hizo el sistema, y los permisos de acceso a tickets y documentos
• Los fallos de noche y la persona a la que se llama

vLLM es un programa de código abierto para ejecutar modelos en tus propios servidores. Su página de seguridad en GitHub, consultada el 20 de octubre de 2026, recoge un aviso del 6 de octubre de 2026 sobre un fallo corregido en la versión 0.31.0. El título del aviso dice: «Un min_tokens demasiado grande en una sola solicitud bloquea el motor de vLLM mientras /health sigue en verde». En ese título, min_tokens es un ajuste de la solicitud que fija la longitud mínima de la respuesta.

Una herramienta de monitorización consulta una dirección como /health para ver si un servidor sigue vivo. En el caso que describe el aviso de vLLM, el servidor parece sano aunque ha dejado de responder a las solicitudes. La monitorización de un sistema LLM debería enviar solicitudes de prueba reales y comprobar que llegan las respuestas.

¿En qué se diferencia nuestro propio sistema de una herramienta de helpdesk con IA integrada?

Con una herramienta de helpdesk que se vende como software como servicio (SaaS), una herramienta que alquilas por internet, el proveedor opera el servicio, y el modelo funciona en los servidores del proveedor o en los de las empresas con las que trabaja. Tus tickets van al proveedor y a esas empresas. El artículo sobre software de IA para documentos o un pipeline de LLM a medida trata la elección entre una herramienta así y un sistema propio.

Zendesk, un proveedor de helpdesk, dice en su página sobre IA generativa, consultada el mismo día, que «Zendesk integra LLM en los Servicios de dos maneras». Una usa modelos alojados en plataformas «como AWS Bedrock, Microsoft Azure, Groq o Fireworks AI», y Zendesk dice que en ese caso «el proveedor del LLM nunca accede a tus Datos de Servicio». La otra usa modelos «alojados directamente por el proveedor del modelo», como OpenAI y Google Gemini. Para estos, Zendesk dice que el texto enviado al modelo y sus respuestas «no se conservan en ningún mecanismo de registro».

Intercom, otro proveedor de helpdesk, publica una lista de subencargados del tratamiento, las empresas que tratan datos por cuenta suya. La lista, vigente desde el 25 de junio de 2026 y consultada el mismo día, nombra a OpenAI, Anthropic, Google y Microsoft, entre otros, para el «procesamiento de IA». La página dice que las listas «pueden ser actualizadas por Intercom cada cierto tiempo».

¿Puede seguir operando nuestro sistema LLM la empresa que lo construyó?

La empresa que construyó el sistema puede ofrecer un acuerdo de soporte, un contrato por el que se encarga de que el sistema siga funcionando después del lanzamiento. Comprueba qué dice el acuerdo sobre estos puntos:

• Qué cuenta como incidente, como que el sistema se detenga o que un campo se lea mal en muchos documentos, y con qué rapidez responde alguien a cada tipo
• Quién puede entrar en tus servidores, con qué cuentas y cómo se registra ese acceso
• Quién paga los servidores y quién decide cuándo hace falta más capacidad
• Qué es una solicitud de cambio, como añadir un tipo de documento o una categoría de tickets, y cómo se cobra
• Qué informes recibes cada mes, como las puntuaciones de calidad, los volúmenes de la cola de revisión y los incidentes

Dejar el sistema en manos de la empresa es lo que menos exige a tu personal. El conocimiento se queda entonces en la empresa proveedora, y tú dependes de ella para la mayoría de los cambios. Qué debería ser tuyo cuando la empresa se vaya lo explica el artículo sobre las preguntas que debe hacer un director de operaciones antes de firmar.

Nuestro equipo de TI no tiene experiencia en ML. ¿Puede hacerse cargo del sistema?

Un equipo de TI que ya opera los servidores de tu empresa suele poder sumar a su trabajo los servidores, los permisos de acceso, las copias de seguridad y la monitorización del sistema LLM. Las tareas propias de los modelos de lenguaje, como interpretar las puntuaciones de calidad y probar una nueva versión del modelo, requieren formación previa.

Para el traspaso, el equipo de TI necesita runbooks, guías paso a paso para las tareas diarias y para cada fallo conocido, como que se llene la cola de revisión. El equipo también necesita la muestra de prueba de tus tickets y documentos con las respuestas correctas y el script que puntúa el sistema con ella. El código y los archivos del modelo deben estar en un almacenamiento que controle tu empresa.

Antes del lanzamiento debería existir un entorno de pruebas, una copia del sistema donde se prueban los cambios antes de que lleguen a los tickets reales. La formación puede hacerse ahí: tu equipo hace las tareas rutinarias en la copia y los ingenieros de la empresa revisan el trabajo.

Los cambios en el prompt y en las reglas necesitan un responsable. Un prompt es el texto que le dice al modelo qué hacer. Cuando cambia un formulario o aparece una nueva categoría de tickets, alguien tiene que actualizar el prompt o las reglas y volver a puntuar la muestra de prueba. Decide si esa persona está en TI, en la empresa proveedora o en el equipo responsable del proceso, como soporte.

¿Cómo funcionaría un reparto entre nuestro equipo de TI y la empresa?

En un reparto, tu equipo de TI se queda con los servidores y los accesos, y a la empresa se la llama para los cambios de modelo y los problemas de calidad.

Un reparto puede dejar un hueco. Cuando baja la calidad, TI puede culpar al modelo mientras la empresa culpa a los servidores, así que el acuerdo debería decir por escrito quién decide qué.

Por ejemplo, tu empresa aprueba cada nueva versión del modelo después de que la empresa proveedora la haya puntuado con la muestra de prueba. Corregir un problema de calidad es tarea de la empresa proveedora, mientras que el acceso a los servidores sigue siendo decisión de tu equipo de TI. Nombra también a la persona que mira primero cuando salta una alerta de noche y cómo contacta esa persona con la otra parte.

¿Por qué a veces baja la calidad de las respuestas después del lanzamiento?

La precisión puede sufrir deriva, es decir, cambiar poco a poco sin ningún mensaje de error. Pueden causarla los temas nuevos de los tickets tras el lanzamiento de un producto, un formulario modificado o una nueva versión del modelo. Los servidores siguen funcionando como antes, así que la monitorización de servidores no muestra la caída.

La deriva aparece cuando se vuelve a puntuar la misma muestra de tus tickets y documentos con las respuestas correctas. Eso debería hacerse de forma periódica, por ejemplo cada mes, y después de cada cambio en el modelo, en el prompt o en las reglas. Compara cada puntuación con la registrada en el lanzamiento.

Los artículos sobre un piloto de IA estancado y sobre las preguntas para un director de operaciones explican cómo preparar la muestra de prueba. Elijas la vía que elijas, el contrato debería nombrar a la persona que repite la puntuación y decir quién ve los resultados.

¿Quién decide cuándo cambia el modelo?

Con un modelo de pesos abiertos en tus propios servidores, tu empresa decide cuándo cambiar. Un modelo de pesos abiertos es aquel cuyo creador publica los archivos del modelo para que cualquiera pueda descargarlos y ejecutarlos según su licencia. La licencia sigue aplicándose, y una versión más nueva puede venir con otra distinta.

Los modelos Gemma de Google son un ejemplo. La página de Gemma 3 en Hugging Face, el sitio de modelos, consultada el mismo día, remite a los Gemma Terms of Use, las condiciones de uso de Gemma, que incorporan una Prohibited Use Policy, una política de usos prohibidos. El blog de código abierto de Google dijo el 2 de abril de 2026 que «los modelos Gemma 4 son los primeros del Gemmaverse que se publican con la licencia Apache 2.0, aprobada por la OSI». Pasar de Gemma 3 a Gemma 4 cambia, por tanto, la licencia que leen tus abogados: de las condiciones propias de Google a Apache 2.0, una licencia de código abierto.

Un sistema en tus propios servidores puede, aun así, llamar a un modelo a través de una API alojada, una conexión por internet a los servidores de otra empresa. Ese modelo se retira según el calendario de esa empresa. La página de Anthropic sobre la retirada de modelos (model deprecations), consultada el mismo día, dice: «Las solicitudes a modelos que hayan pasado su fecha de retirada fallarán». Anthropic dice que da a los clientes con despliegues activos «un preaviso de al menos 60 días antes de la retirada de los modelos lanzados públicamente». La página añade que sus fechas se aplican a las plataformas propias de Anthropic y que Amazon Bedrock y Google Cloud «fijan sus propios calendarios de retirada».

Cada cambio supone puntuar la nueva versión con tu muestra antes de que entre en producción, con la versión anterior lista por si bajan las puntuaciones. La página de Anthropic recomienda «probar a fondo tus aplicaciones con los nuevos modelos mucho antes de la fecha de retirada».

¿Puede un ticket de soporte engañar al sistema?

La prompt injection es un ataque en el que el texto enviado al sistema lleva instrucciones dirigidas al modelo. Los tickets de soporte vienen de fuera de tu empresa, así que un sistema que los lee sigue expuesto mientras funciona. El OWASP Top 10 for LLM Applications 2025, una lista de riesgos que publica el proyecto de seguridad OWASP, consultada el mismo día, sitúa la prompt injection en primer lugar. Uno de sus ejemplos dice: «Un atacante inyecta un prompt en un chatbot de atención al cliente y le indica que ignore las directrices anteriores, consulte almacenes de datos privados y envíe correos electrónicos, lo que provoca un acceso no autorizado y una escalada de privilegios».

Las reglas de diseño contra la prompt injection, como no dar al sistema más acceso del que necesita su tarea, están en el artículo sobre el piloto estancado. OWASP también recoge una medida que hay que repetir mientras el sistema funciona: «Realizar pruebas de penetración y simulaciones de brechas con regularidad, tratando el modelo como un usuario no confiable». En las pruebas de penetración, unos evaluadores intentan entrar a propósito, con tu permiso.

Las pruebas de penetración forman parte del calendario de tareas de operación, y el contrato debería decir qué parte las encarga y corrige lo que encuentren. Los logs pueden contener el texto completo de los tickets, así que decide quién puede leerlos y cuánto tiempo se conservan.

¿Cuánto costará operar el sistema cada mes y qué deberíamos preguntar antes de firmar?

En tus propios servidores, los costes mensuales empiezan por los servidores y sus GPU, comprados o alquilados, y por el tiempo del personal en la cola de revisión. Un acuerdo de soporte se suma a ellos si la empresa mantiene algún papel, y lo mismo ocurre con las nuevas pruebas tras cada cambio. Aquí no se dan cifras, porque cada una depende de tus volúmenes y de tu configuración.

El reparto de costes depende de la vía que elijas. Si la empresa opera el sistema, buena parte del coste está en el acuerdo de soporte. Tras un traspaso, una parte mayor es tiempo de tu propio personal, incluida la formación.

Haz las mismas preguntas a cada empresa que se ofrezca a construir y operar el sistema:

• ¿De qué tareas de operación se encargarán ustedes después del lanzamiento y cuáles hará nuestro equipo de TI?
• ¿Con qué frecuencia puntuarán el sistema con nuestra muestra de prueba?
• ¿Quién paga las nuevas pruebas cuando se retire una versión del modelo que usamos?
• ¿Qué recibe nuestro equipo de TI en el traspaso y cómo comprobarán que puede operar el sistema por su cuenta?

Las condiciones de licencia varían de un modelo a otro, y las normas de protección de datos, según el país. Este artículo no constituye asesoramiento jurídico, así que revisa con un abogado las condiciones que se te aplican.

¿Dónde encaja amBrain?

El único proyecto con modelos de lenguaje que amBrain describe en público es este: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes. La frase citada no dice quién opera hoy ese sistema, dónde funciona su modelo ni cuáles de los pasos de este artículo incluía. Los tickets de soporte, los documentos y las vías de operación de este artículo son ejemplos generales y no proceden de ese proyecto ni de ningún otro trabajo de amBrain.

Los proveedores, los creadores de modelos y los proyectos de software que se nombran aquí son ejemplos tomados de páginas publicadas, y el artículo no afirma que amBrain tenga relación alguna con ninguno de ellos. El artículo no da precios, plazos ni condiciones de amBrain.

amBrain desarrolla software desde 2019. Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Si amBrain está en tu lista corta, hazle las mismas preguntas que a cualquier otra empresa.