IA offline para plataformas de mensajería: por qué importan los modelos locales

Casi todas las funciones de IA que hoy trae el software de mensajería son un trato de inquilino. Se ejecutan en servidores ajenos, se miden con la tarifa de otro y funcionan solo mientras la línea entre su edificio y el de ellos siga en pie. Para la mayoría de los compradores es un intercambio razonable. Para un banco que opera una plataforma de mensajería dentro de una DMZ, para un organismo público en una red aislada, o para un revendedor en un mercado cuya moneda se movió un 30 por ciento este año, sencillamente no es viable. Esta guía trata de lo que ocurre de verdad cuando quita la nube de la ecuación: qué puede hacer con honestidad un modelo local, qué no puede, y el patrón de diseño que le permite tener ambas cosas sin jugarse el producto a ninguna de las dos.

Por qué la IA en la nube no es viable en despliegues en DMZ y regulados

Hay tres muros distintos, y los compradores suelen chocar con ellos en este orden.

El muro de la red. Una plataforma de mensajería que termina OTP para un banco no vive en la internet abierta. Vive en una DMZ, o más adentro, con una política de firewall escrita por alguien cuyo trabajo consiste en decir que no. Una salida HTTPS hacia un proveedor de IA no es una casilla que se marca: es una solicitud de cambio, una revisión, una entrada en el registro de riesgos y, en el caso aislado, es imposible sin más, porque no existe ninguna ruta de salida de esa sala. Cualquier función que llame a casa es una función que no existe para ese cliente. Esto no es hipotético ni raro: es la forma normal de las cuentas más valiosas de este sector.

El muro de los datos. Incluso donde hay ruta, el contenido es el problema. Una petición de reescritura lleva dentro el cuerpo del mensaje, y el cuerpo del mensaje es el nombre de un cliente, una referencia de cuenta, una contraseña de un solo uso, un aviso de deuda, una cita médica. Enviar eso a un tercero significa responder preguntas sobre acuerdos de tratamiento, subencargados, conservación, jurisdicción y transferencias internacionales, por cada mensaje, para siempre. Algunas de esas preguntas tienen buenas respuestas. En un mercado regulado, “el texto nunca sale del edificio” es una conversación mucho más corta que cualquiera de ellas.

El muro comercial. El precio de la IA en la nube es una decisión que se toma en el consejo de otra empresa. Las tarifas cambian, los niveles gratuitos se cierran, los modelos se retiran con un calendario que usted no fija, y una clave se puede revocar o limitar un martes cualquiera. Si la función estrella de su producto depende de eso, ha construido un negocio sobre una dependencia que no controla. Los operadores de mercados emergentes lo sienten con más fuerza, porque un precio denominado en USD y unos ingresos denominados en moneda local no se mueven a la vez.

Ninguno de estos muros significa que la IA esté descartada. Significan que la IA tiene que poder vivir dentro de su edificio.

Qué pueden hacer de verdad los modelos locales, y qué no

Aquí la honestidad importa más que el entusiasmo, porque la distancia entre el marketing y la máquina es donde mueren los proyectos.

En qué son buenos. Un modelo pequeño ajustado a instrucciones, algo de 3.000 a 8.000 millones de parámetros, cuantizado y servido en local con llama.cpp u Ollama sobre CPU normal, es realmente bueno en trabajo de texto acotado. Reescribir un mensaje para que suene más cercano, más corto o más formal. Corregir tono y gramática. Redactar una traducción para que la apruebe una persona. Responder una consulta de soporte a partir de un documento recuperado. Clasificar la intención de un chatbot y producir una respuesta breve y de guion. Son exactamente las tareas que necesita una plataforma de mensajería, y todas comparten una forma: entrada corta, salida corta, tarea acotada, una persona cerca.

En qué son malos. El razonamiento largo de varios pasos. Sostener un contexto grande y enredado. La escritura creativa con matices que tiene que salir perfecta a la primera. Cualquier cosa donde la diferencia entre una buena respuesta y una excelente valga dinero de verdad. Un modelo de frontera en la nube es notablemente mejor en todo eso, y fingir lo contrario no ayuda a nadie.

La restricción que se olvida: la velocidad. Un modelo local en CPU produce del orden de 10 a 25 tokens por segundo. Una reescritura de 200 tokens tarda, por tanto, entre 8 y 20 segundos. Para un usuario que pulsa “reescribir” y espera, eso es aceptable. Para un chatbot en vivo atendiendo clientes con volumen va justo, y ese es el punto en el que usted añade una GPU modesta, mantiene las respuestas cortas, o envía esa función concreta a un motor en la nube. No hay ingenio que convierta una CPU en un centro de datos.

La consecuencia práctica. Diseñe sus prompts contra el modelo nativo, no contra el de la nube. El nativo es el motor más débil que va a ejecutar, y por eso mismo es el suelo: si un prompt da una respuesta utilizable ahí, la dará en todas partes. Si lo afina contra un modelo de frontera y luego cae al nativo, ese retorno es el momento en el que su función le deja en evidencia, y ocurrirá en el peor instante posible. Construya contra el suelo y cada mejora será un regalo.

El patrón de motor seleccionable: nativo por defecto, su clave como opción

El error es plantearlo como algo binario. Local o nube, elija uno y aténgase. La mejor respuesta es convertir el motor en un ajuste y la interfaz en un contrato.

En el diseño de IA offline de Smppcube, el administrador elige el motor una sola vez en los ajustes globales. Los modelos locales nativos son el valor por defecto y están siempre disponibles. Un proveedor en la nube con la clave del propio administrador es opcional, para los despliegues que quieren más potencia y tienen ruta a internet. Todo lo que hay aguas abajo, reescritura, traducción, chatbot, journeys, texto de campaña, RAG, llama a una única interfaz interna y ni sabe ni le importa qué hay detrás. Cambie el ajuste y todas las funciones lo siguen a la vez, sin volver a cablear nada.

Tres detalles hacen que esto funcione en la práctica y no solo en una diapositiva.

Una sola forma, construida sobre el estándar. La interfaz está construida sobre el contrato de chat-completions compatible con OpenAI, que cubre el servidor nativo y la gran mayoría de proveedores con un único camino de código. Anthropic recibe un solo adaptador adicional. Esa es toda la superficie de integración, y por eso añadir un proveedor es un cambio de ajustes y no un proyecto.

Los embeddings son un ajuste aparte. La recuperación y el chat son trabajos distintos con economías distintas, y el modelo de embeddings se elige de forma independiente del modelo de chat. Puede ejecutar la recuperación en local sobre sus propios documentos mientras apunta el chat a un motor en la nube, o al revés, y cambiar uno nunca toca al otro.

El retorno al nativo es el suelo de seguridad. Las claves se cifran en reposo, se ocultan en los registros y se limitan con un tope de gasto estricto por motor. Cuando se alcanza el tope, cuando el proveedor sufre una caída, cuando se corta la línea, la plataforma vuelve al nativo de forma automática y la función sigue funcionando. Nadie recibe una llamada de madrugada y ninguna pantalla se rompe. Esta es la pieza que hace segura la elección de la nube: no está confiando su disponibilidad al proveedor, está tomando prestada su capacidad con un suelo debajo.

Y un límite que conviene decir en voz alta: aquí la IA es asistente, no autónoma. Las campañas siguen aprobándose por una persona. Las respuestas de RAG llevan una barrera de “no está en la documentación” en lugar de inventarse algo verosímil. Un modelo offline que se inventa cosas con aplomo es peor que ningún modelo, y la barrera importa más cuanto más pequeño es el modelo.

La única tarea que siempre es nativa: el spam

Hay exactamente una función de IA que nunca recibe elección de motor, y la razón es instructiva.

El control de spam se ejecuta en el camino caliente del mensaje. Todos y cada uno de los mensajes pasan por él, lo que significa que la comprobación tiene que costar prácticamente nada y no puede esperar jamás a un salto de red. En Smppcube es fastText más reglas, corriendo en torno a una décima de milisegundo, nunca un LLM. Con 3.000.000 de mensajes al mes, una llamada a la nube de 200 ms por mensaje no es un problema de coste, es un problema de física: su rendimiento se desploma y su cola se atasca detrás de la latencia de un tercero.

La política importa tanto como el mecanismo: marcar, no bloquear. El filtro señala lo que parece spam y le deja a usted la decisión de enviar. Un falso positivo que mata en silencio el tráfico de OTP de un cliente es un error mucho más caro que un mensaje marcado que una persona revisa de un vistazo. Esta es la regla general de la IA en un camino caliente, y por eso el clasificador rápido, aburrido y offline es la herramienta correcta, y no la impresionante.

Las cuentas, con honestidad

Sáltese el “la IA es cara” dicho al aire y haga la aritmética, porque la respuesta es de verdad distinta según el volumen.

El uso asistido ligero sale barato en la nube. Cincuenta usuarios cliente haciendo cuarenta reescrituras al día cada uno son unas 60.000 llamadas al mes. A razón de mil tokens por llamada, eso son 60 millones de tokens, que con un modelo de gama media se sitúan en torno a 30 a 60 USD al mes. Quien le diga que la factura de tokens por sí sola justifica pasarse al nativo con ese volumen le está vendiendo algo. A esa escala usted va al nativo por la DMZ y por los datos, no por la factura.

Los chatbots cambian la forma. Ahora ponga un chatbot con RAG delante del tráfico entrante. Veinte mil conversaciones al mes a seis turnos cada una son 120.000 llamadas, y cada una lleva contexto recuperado, digamos 4.500 tokens entre entrada y salida. Eso son unos 540 millones de tokens al mes, de 200 a 400 USD según el modelo, o de 2.400 a 4.800 USD al año. La parte incómoda es la dirección del movimiento: esa factura crece cada vez que crece el negocio, así que el éxito le sube los costes justo en el trimestre en el que usted quería el margen.

El nativo no tiene contador. El coste de una llamada nativa es cero. El coste del nativo es el equipo: un servidor existente con holgura, o unos 40 a 80 USD al mes de capacidad adicional, plano, tanto si hace mil llamadas como un millón. Frente a una licencia de plataforma de pago único que ya vive sobre su propio hierro, según la misma lógica de alquilar o poseer de la guía del gateway autoalojado, la partida de IA deja de ser un coste variable y pasa a formar parte de la máquina que ya compró.

El resumen honesto: para uso ligero, vaya al nativo por soberanía y a la nube por calidad, y el dinero será un error de redondeo en cualquiera de los dos casos. Para volúmenes de chatbot, el nativo es notablemente más barato y, sobre todo, predecible. Lo predecible es lo que le permite dar a un cliente un precio para todo un año.

Elegir con honestidad

Si su despliegue tiene una ruta limpia a internet, ninguna restricción de residencia de datos y usted quiere la mejor salida posible en un puñado de tareas de alto valor, use un motor en la nube con su propia clave. Es una buena decisión y el patrón de arriba la respalda por completo. Nativo para el spam y la recuperación, nube para la escritura, y el retorno al nativo siempre activo.

Vaya al nativo primero cuando se cumpla cualquiera de estas: su plataforma vive en una DMZ o en una red aislada; sus clientes preguntan por los subencargados antes que por el precio; sus ingresos están en una moneda que no sigue al USD; o su volumen de IA tiene forma de chatbot y va en aumento. Y vaya al nativo primero, pase lo que pase, si entrega un producto a clientes cuyos entornos usted no controla, porque una función que necesita ruta a internet es una función que, en silencio, no existe para una parte de su mercado.

Lo que merece la pena diseñar no es local o nube. Es que la elección pertenezca a quien es dueño de los servidores, que sea un ajuste y no una reconstrucción, y que el suelo de debajo aguante siempre. Desenchufe el cable y sigue pensando. Todo lo demás es una preferencia.