Agentes de IA en local: herramientas, permisos y aprobación humana

Un modelo dentro de un sistema de decisión

El modelo interpreta una tarea y puede proponer una llamada estructurada: buscar un cliente, recuperar un documento, consultar un inventario o preparar una respuesta. Un orquestador valida la petición, ejecuta la herramienta autorizada y devuelve el resultado al modelo.

La autoridad no debe residir en el prompt. El modelo no controla credenciales, permisos, límites de importe, listas de destinatarios ni reglas de negocio. Esas restricciones pertenecen a código determinista, políticas y sistemas de identidad.

La ejecución local reduce la necesidad de enviar el contexto al proveedor del modelo, pero no impide que una herramienta externa reciba datos. Inventaría cada conexión y aplica las reglas de IA local y RGPD.

Observar, proponer, validar, ejecutar y comprobar

El ciclo debe tener un máximo de pasos, tiempo y llamadas. Si el agente no alcanza un estado válido, detiene la tarea y pide intervención. Los reintentos ilimitados pueden producir costes, bloqueos o acciones duplicadas.

Funciones pequeñas y contratos estrictos

Una herramienta debe hacer una cosa, validar tipos y devolver errores comprensibles. El orquestador transforma el error en información para el modelo, sin exponer secretos ni trazas internas completas.

El contenido externo nunca es una instrucción de sistema

Un correo, PDF, web o comentario puede contener texto que intenta cambiar el objetivo del agente. El sistema debe etiquetarlo como datos no confiables y evitar que controle herramientas.

• Separar mensajes de sistema, instrucciones del usuario y contenido recuperado.
• Aplicar permisos por identidad antes de entregar datos al modelo.
• Validar cada argumento de herramienta con un esquema cerrado.
• Bloquear campos desconocidos, rutas, URLs y destinatarios no autorizados.
• Solicitar aprobación para acciones irreversibles o externas.
• Evitar incluir secretos en el contexto; las herramientas los usan fuera del modelo.
• Registrar decisión, herramienta, argumentos normalizados, resultado y aprobador.
• Probar inyección indirecta dentro de documentos y correos.

Aumentar capacidad por etapas

El ejemplo de n8n, Ollama y Outlook se mantiene en el segundo nivel: preparación automática y decisión humana.

Evalúa acciones, no solo respuestas

• Tasa de herramienta correcta para cada intención.
• Argumentos válidos y rechazados por el esquema.
• Acciones que requieren aprobación y porcentaje correctamente bloqueado.
• Resistencia a inyección directa e indirecta.
• Pasos medios y máximos por tarea.
• Reintentos, duplicados y recuperación tras error.
• Exactitud del resultado final frente a un caso de referencia.
• Latencia por modelo, herramienta y cola.

Versiona la batería de pruebas junto con el prompt, el modelo, el orquestador y las herramientas. Un cambio en cualquier componente puede alterar el riesgo.

Contexto, modelos residentes y concurrencia

Los agentes pueden mantener un contexto amplio, usar un modelo de embeddings, un modelo principal y herramientas simultáneas. La memoria se consume por pesos, caché y sesiones. Una GPU rápida es adecuada cuando todo cabe; DGX Spark ofrece margen con 128 GB y CUDA.

Si el problema es el número de usuarios, replicas de servicio pueden ser mejores que un modelo mayor. Consulta clústeres de DGX Spark. Para una plataforma central con mucha más memoria y administración, consulta DGX Station.

Un agente fiable es un sistema con estado, herramientas y límites externos al modelo

El modelo propone el siguiente paso, pero no debe poseer la autoridad final. La aplicación conserva identidad, permisos, presupuesto, estado, herramientas disponibles, validación y registro. Esta separación permite cambiar de modelo sin rehacer las reglas de negocio.

Solicitud → política → contexto autorizado → modelo → propuesta de herramienta
          → validación de argumentos → aprobación cuando corresponde
          → ejecución aislada → comprobación del resultado → respuesta

Un chat con una única llamada a función puede ser más seguro y útil que un agente autónomo general. Añade capacidad solo cuando una evaluación demuestre que el siguiente nivel aporta valor.

Crear funciones pequeñas, tipadas y comprensibles para el revisor

Una herramienta debe representar una acción de negocio concreta. Evita funciones como «ejecutar SQL», «hacer petición HTTP» o «modificar ERP»: conceden demasiada libertad y son difíciles de auditar. Prefiere contratos como «consultar estado de pedido», «crear borrador de respuesta» o «proponer cambio de fecha».

consultar_pedido({
  "numero": "string",
  "campos": ["estado", "transportista"]
})

crear_borrador_respuesta({
  "mensaje_id": "string",
  "asunto": "string",
  "cuerpo": "string"
})

• Esquema cerrado y tipos validados por el servidor
• Longitud, formato, rangos y enumeraciones limitados
• Identidad y permisos obtenidos fuera del prompt
• Tiempo máximo y número de reintentos definidos
• Resultado estructurado con código de error
• Operación idempotente o protegida por una clave única
• Registro suficiente para reconstruir la decisión

No ejecutes directamente el JSON del modelo. Analízalo con un validador, descarta campos desconocidos y vuelve a comprobar permisos justo antes de la acción.

Tratar correo, páginas y documentos como contenido potencialmente adversario

La inyección de prompt aparece cuando una fuente intenta convencer al modelo de que cambie sus instrucciones, revele datos o utilice una herramienta. El texto puede estar visible, oculto en un documento o incluido en resultados recuperados. No existe una frase de sistema que elimine por completo este riesgo; la defensa combina arquitectura y pruebas.

1. Separa instrucciones y datos. Etiqueta el contenido externo y prohíbe que defina políticas o herramientas.
2. Reduce el contexto. Entrega únicamente los fragmentos necesarios y autorizados para la tarea.
3. Limita herramientas por paso. Una tarea de lectura no necesita funciones de escritura disponibles.
4. Valida argumentos fuera del modelo. Bloquea rutas, dominios, destinatarios o identificadores no permitidos.
5. Solicita aprobación para efectos relevantes. El revisor debe ver la fuente, la propuesta y el efecto exacto.
6. Comprueba el resultado. Verifica que la operación se realizó una vez y sobre el recurso previsto.
7. Prueba entradas hostiles. Incluye documentos que piden ignorar reglas, revelar secretos o llamar a otras herramientas.

Los secretos no deben entrar en el contexto. La herramienta utiliza credenciales en el servidor y devuelve el mínimo resultado. Los mensajes de error tampoco deben revelar tokens, rutas internas o consultas.

Conservar lo necesario sin transformar cada conversación en un expediente permanente

El historial completo es una forma costosa y poco controlada de estado. Resume hechos aprobados en campos explícitos y conserva la procedencia. Una preferencia, una instrucción de empresa y un dato transitorio no tienen la misma autoridad ni la misma retención.

Cuando un modelo resume memoria, la aplicación debe validar campos y asociarlos a una fuente. No permitas que una suposición se convierta silenciosamente en un hecho persistente.

Evaluar trayectorias, efectos y recuperación ante errores

Una respuesta final correcta puede ocultar llamadas innecesarias o peligrosas. Registra la trayectoria: decisiones, herramientas propuestas, argumentos, validaciones, aprobaciones, errores y resultado. La puntuación debe penalizar efectos laterales incluso cuando el texto final sea aceptable.

1. Fija un conjunto de escenarios. Incluye normales, límites, errores y ataques.
2. Ejecuta varias veces. Los modelos son probabilísticos; mide tasa de éxito, no una demostración favorable.
3. Valida con reglas deterministas. Esquemas, permisos y efectos se comprueban con código.
4. Revisa una muestra humana. Especialmente en decisiones que afectan a clientes, empleados o contratos.
5. Bloquea regresiones. Un cambio de modelo o prompt no se publica si empeora seguridad o exactitud.

Pasar de asistente a agente sin saltar directamente a la autonomía

Define una condición de parada técnica y operativa. El agente debe finalizar al alcanzar el objetivo, agotar pasos, superar tiempo, recibir un error no recuperable o requerir información humana. La ausencia de salida no justifica seguir llamando herramientas.

Ejemplo seguro: preparar un borrador de correo

1. El disparador obtiene un mensaje autorizado.
2. Se eliminan firmas, rastreadores y adjuntos no necesarios.
3. Un RAG recupera política y datos permitidos.
4. El modelo devuelve asunto, cuerpo, nivel de confianza y fuentes en JSON.
5. El validador comprueba esquema y destinatarios.
6. Microsoft Graph crea un borrador; no se llama al método de envío.
7. La persona revisa y decide desde Outlook.

La guía n8n + Ollama + Outlook desarrolla esta integración con separación entre modelo, orquestación y correo.

Dimensionar para contexto, herramientas y sesiones simultáneas

Los agentes consumen más contexto que un chat simple: instrucciones, esquema de herramientas, resultados, memoria y varios ciclos. Mide tokens de entrada por paso, número medio y máximo de pasos, latencia de cada herramienta y sesiones concurrentes. Un modelo rápido no compensa una herramienta lenta ni un flujo con demasiadas iteraciones.

Construir un agente local mínimo con una herramienta de solo lectura

El primer agente no debería enviar correos, modificar el ERP ni ejecutar órdenes. Empieza con una función que solo consulta un dato acotado, valida sus argumentos y devuelve una estructura pequeña. El modelo decide si necesita la herramienta; la aplicación conserva la autoridad para permitirla, ejecutarla y registrar el resultado.

import json
import re
from ollama import chat

MODEL = "familia:variante-validada"
MAX_STEPS = 4

# Sustituye este diccionario por una consulta de solo lectura con permisos mínimos.
INCIDENCIAS = {
    "INC-100": {"estado": "en_revision", "responsable": "soporte"},
    "INC-101": {"estado": "resuelta", "responsable": "sistemas"},
}

def consultar_incidencia(codigo: str) -> dict:
    if not re.fullmatch(r"INC-[0-9]{3,8}", codigo):
        raise ValueError("Formato de incidencia no permitido")
    return INCIDENCIAS.get(codigo, {"estado": "no_encontrada"})

TOOL_SCHEMA = {
    "type": "function",
    "function": {
        "name": "consultar_incidencia",
        "description": "Consulta el estado de una incidencia por su código",
        "parameters": {
            "type": "object",
            "properties": {"codigo": {"type": "string"}},
            "required": ["codigo"],
            "additionalProperties": False,
        },
    },
}

ALLOWED_TOOLS = {"consultar_incidencia": consultar_incidencia}
messages = [{"role": "user", "content": "¿En qué estado está INC-100?"}]

for _ in range(MAX_STEPS):
    response = chat(model=MODEL, messages=messages, tools=[TOOL_SCHEMA])
    messages.append(response.message)

    calls = response.message.tool_calls or []
    if not calls:
        print(response.message.content)
        break

    for call in calls:
        name = call.function.name
        if name not in ALLOWED_TOOLS:
            raise RuntimeError(f"Herramienta no autorizada: {name}")
        try:
            result = ALLOWED_TOOLS[name](**call.function.arguments)
        except (TypeError, ValueError) as exc:
            result = {"error": str(exc)}
        messages.append({
            "role": "tool",
            "tool_name": name,
            "content": json.dumps(result, ensure_ascii=False),
        })
else:
    raise RuntimeError("El agente superó el límite de pasos")

Este ejemplo incorpora cuatro límites que deben mantenerse al conectar sistemas reales: lista explícita de herramientas, validación de parámetros, máximo de pasos y función de solo lectura. En producción añade identidad del usuario, autorización por recurso, timeout, idempotencia, registro de decisiones y una salida que el revisor pueda entender.

Elegir entre n8n, Open WebUI y un orquestador en Python

El framework organiza el bucle, pero no resuelve autorización, calidad del dato ni responsabilidad. Para el primer despliegue, una sola herramienta de lectura y una métrica clara ofrecen más información que un sistema con muchos agentes y permisos amplios.

Antes de habilitar escritura, conecta la evaluación descrita en esta guía con la arquitectura de n8n, Ollama y Outlook y con los controles de IA local y RGPD.