← Proyectos
Inteligencia artificial · Autonomía acotada

Un modelo que decide
sin salir del servidor

El sistema ya avisaba de todo lo importante, pero en el idioma de los registros. Añadirle un modelo de lenguaje planteaba una pregunta incómoda: enviar los datos operativos de la propia infraestructura a un tercero. La solución construida no sale a Internet y no puede actuar por su cuenta.

Arquitectura
4LABSSERVER modelo local Qwen2.5-7B · 4 bits sin salida a Internet bot sin privilegios consulta cola petición validada ejecutor con privilegios cortafuegos bloqueo efectivo el modelo nunca ejecuta administrador confirma o cancela ninguna acción se aplica sin confirmación explícita

El modelo ocupa la parte alta izquierda y no tiene ninguna flecha hacia el cortafuegos. Lo que llega a ejecutarse ha pasado antes por una validación determinista y por una confirmación humana. La inteligencia está en explicar; la autoridad, en otra parte.

Las decisiones, y su porqué
01
Los datos del servidor no salen del servidor
ProblemaPara que un modelo redacte el motivo de un bloqueo o responda sobre el estado del sistema, hay que darle contexto real: direcciones que atacan, rutas sondeadas, nombres de contenedores, estado del cortafuegos. Es telemetría de la propia infraestructura.
AlternativasUna API comercial. Mejor calidad de respuesta, coste por consulta y, sobre todo, un flujo continuo de datos operativos hacia un tercero. La alternativa habitual es anonimizar lo que se envía, lo que degrada precisamente el contexto que hace útil la respuesta.
DecisiónEl modelo se ejecuta en el propio servidor, sin salida a Internet. No hay nada que anonimizar porque nada sale. Es la misma decisión que ya se tomó al elegir par de claves frente a firma sin claves, y red privada propia frente a un servicio gestionado: no delegar en terceros aquello que es la razón de ser del sistema.
02
Qué modelo, y por qué ese
ProblemaEl servidor dispone de 11 GiB de memoria y seis núcleos, sin tarjeta gráfica. El modelo tiene que convivir con el servidor web, la automatización y el resto del stack sin comprometerlos.
AlternativasUn modelo de 3.000 millones de parámetros responde en quince o veinte segundos y ocupa menos de 3 GiB. Uno de 7.000 millones ocupa unos 5 GiB y tarda entre uno y dos minutos en procesador.
DecisiónQwen2.5 de 7.000 millones de parámetros, cuantizado a cuatro bits. Es el mayor que cabe con holgura dejando margen al resto de servicios, y la cuantización reduce el tamaño a un tercio con una pérdida de calidad marginal. Se optó por él frente al modelo pequeño porque en instrucciones de formato estricto falla menos. La lentitud es asumible: ninguna respuesta está en el camino crítico de una petición web.
03
El modelo redacta; nunca decide
ProblemaUn asistente que puede bloquear direcciones es un asistente que puede equivocarse bloqueando. Los modelos de este tamaño no invocan funciones de forma fiable: inventan parámetros con naturalidad.
AlternativasConfiar en la invocación de funciones del modelo y validar después. Es el patrón habitual, y traslada al modelo una responsabilidad que no sabe sostener.
DecisiónLa dirección se extrae del mensaje con una expresión regular, se valida rango por rango y se comprueba contra las redes internas antes de proponer nada. El modelo no participa en esa cadena: solo redacta el texto que se lee después. Si el modelo alucina, alucina en la explicación, nunca en la orden. La parte que ejecuta es determinista y auditable línea a línea.
04
Una restricción que resultó ser la garantía
ProblemaEl bot ya se había endurecido hasta prohibirle la elevación de privilegios. Al darle la capacidad de bloquear, el comando fallaba en silencio: el propio blindaje impide toda escalada, incluida la legítima.
AlternativasRelajar el blindaje para permitir la elevación puntual del comando de bloqueo. Un cambio de una línea que reabre exactamente la vía que se había cerrado.
DecisiónMantener la prohibición y separar la ejecución. El bot deja la petición ya validada en una cola; un proceso independiente, vigilado por el sistema de arranque, la aplica con privilegios y confirma el resultado real. La consecuencia es la garantía que da valor al conjunto: el proceso que habla con el modelo no puede tocar el cortafuegos ni aunque su código sea comprometido.
05
Confirmación humana antes de actuar
ProblemaUna petición mal redactada, un mensaje reenviado o una interpretación desafortunada bastan para dejar fuera a una dirección legítima. Y la propia del administrador es una de ellas.
AlternativasEjecutar directamente y ofrecer deshacer después. Más ágil, pero el error ya se ha producido y en el peor caso deja al administrador sin acceso.
DecisiónEl sistema responde con la dirección concreta que va a bloquear y espera una confirmación explícita que caduca a los cinco minutos. Las redes internas se rechazan antes de llegar a ese punto. Autonomía para observar y proponer; nunca para actuar sin permiso.
06
Lo que no se automatizó
ProblemaLa tentación al montar un sistema así es dejarlo decidir solo: que detecte, valore y bloquee sin intervención. Técnicamente es posible con lo ya construido.
AlternativasUn ciclo cerrado donde el modelo evalúa los registros y actúa según su criterio. Impresiona en una demostración y es difícil de auditar cuando falla.
DecisiónEl bloqueo automático sigue en manos de la herramienta determinista de siempre, con sus reglas y umbrales. El modelo aporta lo que esa herramienta no sabe hacer: explicar en castellano qué ha pasado y responder preguntas sobre el estado. Cada pieza hace aquello en lo que es fiable.
El resultado

Cada bloqueo automático llega explicado en castellano, con el origen geográfico y el proveedor de la dirección implicada. El estado del servidor se consulta preguntando en lenguaje natural, sin recordar comandos. Y los bloqueos manuales se piden hablando, pero se aplican tras una validación determinista y una confirmación explícita. Ningún dato operativo sale de la máquina y ninguna decisión del modelo llega al cortafuegos: la autonomía se concede sobre lo que se puede auditar, no sobre lo que impresiona.

OllamaQwen2.5-7BCuantización Q4Bashsystemdfail2banUFWTelegram Bot API
Connect → Automate → Augment → Deploy.
Autonomía suficiente para ser útil; acotada para ser confiable.