Saltar al contenido principal
No un chatbot, sino un sistema que sigue corriendo
Volver al Blog
Casos de Éxito 16 de julio de 2026 7 min de lecturapor Matthias Meyer

No un chatbot, sino un sistema que sigue corriendo

Para una consultora construimos un sistema de IA en un servidor propio. Lee el correo, prepara respuestas y no olvida nada. No envía nada por su cuenta.

Contenido

Hay una diferencia entre un asistente al que llamas y un sistema que corre.

Al asistente hay que ir a buscarlo. Te acuerdas de que existe, lo abres, explicas la situación, recibes una respuesta, lo cierras. La próxima vez empiezas de cero. Al cabo de unas semanas lo usas para formulaciones y para nada más.

Un sistema que corre no hay que ir a buscarlo. Ya está ahí cuando enciendes el ordenador por la mañana, y mientras tanto ha trabajado.

Para una consultora en Mallorca montamos un sistema así.

El servidor es del cliente#

Primero la parte poco espectacular: todo corre en un servidor propio en un centro de datos alemán. No en nuestra casa, no en una cuenta compartida, sino en una máquina que es del cliente, con sus propias credenciales.

La aplicación, la base de datos y las copias de seguridad están ahí. Lo que va al modelo de lenguaje sale de la UE, porque ahí es donde el modelo funciona, y esa distinción la escribimos en cada proyecto antes de empezar. No hay razón para difuminarlo y hay muchas para decirlo claro.

En la práctica un servidor propio significa que podemos seguir desarrollando sin que nadie tenga que volver a subir sus datos a otro sitio. Y cuando la colaboración termine, el servidor y su contenido se quedan con el cliente.

La memoria es la base, no una función#

El núcleo de este sistema es una memoria que aguanta semanas y meses. Conversaciones, clientes, proyectos, decisiones tomadas y los pequeños acuerdos que si no hay que ir a buscar en correos viejos.

El efecto es difícil de exagerar. Sin memoria le explicas al asistente los antecedentes en cada tarea. Eso cuesta más tiempo que la tarea misma, y por eso la gente lo deja. Con memoria explicas una vez, y dos meses después el asistente recupera la conexión por su cuenta.

Eso convierte a la memoria no en un añadido sino en la razón de que el sistema se use siquiera. Todo lo demás cuelga de ahí.

El correo se lee antes de que nadie lo mire#

La parte más visible en el día a día es cómo se trata el correo.

El sistema recoge el buzón por su cuenta, lee cada mensaje nuevo, lo clasifica y deja al lado de los relevantes un borrador de respuesta. No una sugerencia salida de la nada, sino una construida con lo que la memoria guarda sobre el remitente y el asunto.

Y ahí se para. No envía nada. El borrador queda puesto, la persona lee, cambia, envía o descarta.

Esa línea la trazamos en cada sistema que construimos, y no es prudencia por principio. El borrador es el trabajo, enviar es un botón. Quien delega el trabajo y se queda el botón gana casi todo sin arriesgar nada. Quien delega las dos cosas arriesga la relación con el destinatario por ahorrarse un clic.

El sistema se lleva la parte preparatoria. El resto, el punto donde hacen falta experiencia y tacto, se queda con el titular. Que es además la parte por la que le pagan.

Un sistema, no tres islas#

El error más común en montajes así es que al final corren tres cosas en paralelo: un chatbot, una herramienta de correo y un montón de notas en alguna parte. Cada una funciona por su lado, ninguna sabe de las otras.

Aquí la memoria, el correo y la asistencia comparten el mismo contexto. Cuando por la mañana llega el correo de un cliente, el borrador ya lleva lo que se habló en la última conversación, sin que nadie lo consulte. Esa es la ganancia real, y no viene de una función especial sino de que las piezas están conectadas.

Nada experimental#

La base es aburrida a propósito. Ubuntu, Docker, PostgreSQL, Claude como modelo, nuestro propio servidor de memoria y una conexión al buzón existente.

Es el mismo montaje que operamos para nosotros y para otros clientes. No le construimos a nadie una obra especial que solo tenga él y que solo entendamos nosotros. La razón es interesada: un sistema que operamos muchas veces lo conocemos por sus modos de fallo. Una pieza única se conoce en casa del cliente, y esa es la forma más cara de aprender.

Lo que un sistema así no es#

No es un sustituto de un empleado. No tiene criterio, ni responsabilidad, ni idea de lo que pasa de verdad entre dos personas.

Lo que sí puede hacer es la parte del trabajo que consiste en recordar, preparar y reunir. En una consultora esa parte es mayor de lo que parece, y es además la que se queda sin hacer por la tarde.

Ahí es exactamente donde encaja un sistema así. No donde se decide.

Matthias Meyer

Matthias Meyer

Founder & AI Director

Founder & AI Director de StudioMeyer. Construye sitios web y sistemas de IA desde hace más de 10 años. Vive en Mallorca desde hace 15 años y dirige allí un estudio de IA y diseño: diseño web, conectores IA, sistemas de IA y modelos propios, además de cuatro servidores MCP de autoservicio.

Proyectos de clientes

Tres posts más del mismo cluster temático que muestran cómo encaja el cuadro:

Visión general del cluster: Lo que hay de verdad dentro de nuestros proyectos