Tus primeros 3 agentes de IA: guía de despliegue local para pymes (2026)

La mayoría de las guías sobre agentes de IA están escritas para equipos de ingeniería. Esta es para el despacho de cinco personas, el distribuidor regional con 40 empleados y la consultoría que funciona con hojas de cálculo y correo. Al terminar tendrás un plan para tres agentes, en el orden que genera confianza, corriendo en una máquina que es tuya.

Los agentes en la nube crean tres problemas a una empresa pequeña: tokens de pago en cada bucle, datos de clientes que viajan fuera de la UE (artículo 28 del RGPD: contrato de encargado y subencargados) y un modelo o un precio que cambian sin avisarte. Ejecutarlos en local con Ollama y el Model Context Protocol (MCP) elimina los tres.

Qué necesitas

• Una máquina. El Agente 1 corre en cualquier equipo con 8 GB de RAM, incluida una Raspberry Pi 5 (unos 80 EUR). Los tres caben en un Mac mini M4 de 16 GB (unos 700 EUR) o en un mini PC usado con 16 GB.
• Ollama y dos modelos: ollama pull llama3.1:8b (4,9 GB) y, para el Agente 3, ollama pull qwen2.5:14b (9 GB).
• Node.js 18+ y Python 3.11+ con uv, para ejecutar los servidores MCP.
• Un webhook entrante de Slack, o una cuenta de correo, para entregar los resultados.
• Tiempo: de 2 a 4 horas para el Agente 1, de 4 a 8 para el 2 y de 8 a 16 para el 3.

Sin cuenta, sin clave de API, sin tarjeta.

Por qué local primero en una pyme europea

El Reglamento de IA de la UE clasifica los sistemas por riesgo; resumir documentos, preparar reuniones y buscar en la documentación interna caen en el nivel mínimo o limitado. Con agentes locales, la respuesta a “¿adónde van mis datos?” es: a ninguna parte. La lista completa está en nuestra guía sobre AESIA.

Un equipo de 20 personas que hace 50 preguntas al día cuesta entre 121 y 242 dólares al mes en un modelo de nube de primera línea; un Mac mini con la misma carga, unos 3,25 EUR de electricidad. El cálculo completo está en IA en la nube o en local: calcula tu punto de equilibrio.

graph TD
    TASK["Tarea de negocio<br/>(documento, correo, consulta)"]
    ORCH["Orquestador local<br/>(Ollama + MCP)"]
    MODEL["Modelo de pesos abiertos<br/>(Llama 3.1 / Qwen 2.5)"]
    TOOLS["Servidores MCP<br/>(archivos · sqlite · correo · calendario)"]
    HUMAN["Revisión humana<br/>(puerta de aprobación)"]
    OUTPUT["Resultado<br/>(resumen · borrador · alerta)"]
    TASK --> ORCH
    ORCH --> MODEL
    ORCH --> TOOLS
    MODEL -->|"bucle ReAct"| TOOLS
    TOOLS -->|"resultados"| MODEL
    MODEL -->|"borrador"| HUMAN
    HUMAN -->|"aprobado"| OUTPUT
    HUMAN -->|"rechazado"| MODEL
    style ORCH fill:#0B1628,color:#FAFAFA
    style MODEL fill:#F5A623,color:#0B1628
    style HUMAN fill:#059669,color:#FAFAFA
    style OUTPUT fill:#059669,color:#FAFAFA

Cada flecha se queda dentro de tu red; la puerta de aprobación humana es lo que permite al equipo confiar en el sistema antes de darle autonomía.

MCP en un párrafo

MCP es el conector entre un modelo y tus herramientas: un servidor MCP expone herramientas (funciones que el agente puede llamar) y recursos (datos que puede leer), y cualquier runtime compatible los descubre sin código a medida. A principios de 2026 MCP superó los 97 millones de instalaciones, y hay servidores de la comunidad para casi todo; no necesitarás escribir el tuyo para estos tres agentes.

Paso 1: Agente 1, el resumen diario de inteligencia

Qué hace. Cada día laborable a las 07:00 lee entre 10 y 20 fuentes RSS de tu sector, resume lo relevante en un informe breve (noticias, señales de la competencia, cambios regulatorios) y lo publica en Slack o por correo.

Por qué el primero. Es de solo lectura: no toca ningún sistema interno ni toma decisiones, y lo peor que puede pasar es un informe raro. Tu equipo lo lee cada día y empieza a preguntar qué más podría hacer el agente.

# agents/digest_agent.yaml
agent_id: "digest_agent"
model: "llama3.1:8b"          # rápido, bueno resumiendo
schedule: "0 7 * * 1-5"       # laborables a las 07:00
mcp_servers:
  - name: "filesystem"
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data/feeds"]
  - name: "fetch"
    command: "uvx"
    args: ["mcp-server-fetch"]
system_prompt: |
  Eres analista de investigación para una pyme española. Cada mañana
  revisas las noticias del sector y produces un informe estructurado.
  Sé conciso. Señala solo lo verdaderamente relevante. Nunca especules.
tools: [read_file, fetch, write_file]
output_destination:
  type: "slack_webhook"
  url: "${SLACK_DIGEST_WEBHOOK}"
quality_threshold: 0.75       # repetir si la autoevaluación baja del 75 %

ollama pull llama3.1:8b
ollama serve &                     # se queda en ejecución
npx -y @modelcontextprotocol/server-filesystem /data/feeds   # comprueba que el servidor arranca
uvx mcp-server-fetch                                          # ídem
python agents/run_agent.py --config agents/digest_agent.yaml

run_agent.py es un bucle de unas 80 líneas que lee el YAML, se conecta a los servidores MCP con el SDK de MCP para Python y llama a /api/chat de Ollama con las herramientas. Pídele a tu asistente que lo escriba a partir de esta configuración y conéctalo a cron o n8n. Resultado esperado: un archivo Markdown en /output/ y un mensaje en Slack. Si el modelo no llama a ninguna herramienta, comprueba que ollama show llama3.1:8b lista tools entre sus capacidades.

A las cuatro semanas tu equipo lo echará de menos cuando llegue tarde: ese es tu permiso para desplegar el Agente 2.

Paso 2: Agente 2, el monitor de calidad de la base de conocimiento

Qué hace. Una vez a la semana recorre tu documentación interna (carpeta compartida, Notion, Confluence) y devuelve los diez artículos que más atención necesitan: sin modificar desde hace más de 90 días, con enlaces rotos, sin resumen, sin destinatario claro.

Por qué el segundo. Toda empresa tiene una carpeta donde los documentos van a morir, y el coste aparece como incorporaciones lentas y decisiones sobre información caducada. El agente encuentra los problemas; una persona decide qué arreglar.

Hardware. La misma máquina, con 4 GB más de RAM para el modelo de embeddings.

# quality_rubric.py — el agente puntúa cada documento con estos criterios
CRITERIOS = {
    "recencia":         {"peso": 0.25, "comprobacion": lambda meta: (hoy - meta["ultima_modificacion"]).days <= 90},
    "tiene_resumen":    {"peso": 0.20, "comprobacion": "llm"},   # el primer párrafo dice para qué sirve
    "enlaces_validos":  {"peso": 0.20, "comprobacion": "llm"},   # el servidor de archivos resuelve los enlaces internos
    "audiencia_clara":  {"peso": 0.15, "comprobacion": "llm"},   # dice a quién va dirigido
    "accionable":       {"peso": 0.20, "comprobacion": "llm"},   # contiene próximos pasos o decisiones
}
# Puntuación 0-1 por criterio, media ponderada = nota del documento. Se marca por debajo de 0,65.

Es el primer agente con permiso de escritura, y solo sobre el informe semanal; todo lo demás sigue en solo lectura, a propósito.

Paso 3: Agente 3, el informe de preparación de reuniones

Qué hace. Treinta minutos antes de una reunión lee el evento del calendario, lista a los asistentes, recupera la agenda y los documentos internos relevantes, añade opcionalmente contexto público sobre los participantes y envía un informe de una página al organizador.

Por qué el tercero. Es el más visible: su resultado llega al buzón de un directivo antes de cada reunión, así que los errores se notan al instante. Para entonces llevas semanas escribiendo system prompts y el listón es más alto.

Hardware. El mismo Mac mini con los tres agentes; el pico de memoria ronda los 6 a 8 GB con el modelo de 8B, más con el de 14B.

ollama pull qwen2.5:14b            # mejor razonamiento para este agente
# Calendario: elige un servidor comunitario de Google Calendar en
# https://github.com/modelcontextprotocol/servers y anota su comando de arranque.
cat > agents/meeting_prep_agent.yaml << 'EOF'
agent_id: "meeting_prep_agent"
model: "qwen2.5:14b"
trigger: "calendar_event_minus_30min"
mcp_servers:
  - name: "filesystem"
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data/knowledge-base"]
  - name: "calendar"
    command: "<comando de arranque del servidor de calendario>"
    auth: "${GOOGLE_CALENDAR_OAUTH}"
  - name: "fetch"
    command: "uvx"
    args: ["mcp-server-fetch"]
    rate_limit: "10/min"           # cortesía con los sitios públicos
approval_gate:
  enabled: true
  channel: "slack"
  timeout_minutes: 20              # sin aprobación en 20 min: omitir y registrar
output:
  format: "markdown"
  destination: "slack_dm_to_organiser"
EOF

Si el agente confunde a un asistente clave, no quieres que eso se envíe solo; tras 20 o 30 informes correctos decide si relajar la puerta.

Paso 4: conecta los tres

Cuando los tres funcionan, se refuerzan: el resumen diario alimenta al monitor de la base de conocimiento, y el informe del monitor alimenta a la preparación de reuniones, que lee la misma base. El patrón es un bus de eventos: cada agente escribe su salida como una fila en una tabla eventos de SQLite y los demás leen las que les interesan.

Qué medir

Métrica	Objetivo	Por qué
Tareas completadas / semana	Según la carga	Línea base de rendimiento
Tasa de revisión humana	< 20 % en los Agentes 1 y 2	Fiabilidad
Tasa de corrección humana	< 5 %	Alineación con las preferencias del equipo
Coste por tarea	< 0,01 EUR (inferencia local)	Confirma la economía
Tasa de falsos positivos	< 10 % en las marcas de calidad	Específico del Agente 2

Revísalas cada semana; en la cuarta tendrás datos para ajustar prompts y umbrales y elegir el cuarto agente.

Errores que hemos cometido nosotros

• No te saltes la puerta de aprobación en el Agente 3. Es una función, no un ruedín.
• No dejes que dos agentes escriban el mismo archivo a la vez. Los bloqueos de SQLite pierden datos en silencio; usa el modo WAL y un semáforo de escritura.
• Reserva medio día por agente para ajustar el prompt. Un buen system prompt necesita de tres a cinco iteraciones.
• Pon un cortacircuitos. Tres salidas seguidas de baja calidad: pausa el agente y avisa al operador.

Dónde encaja, y los límites

Un modelo de 8B resume, clasifica y redacta bien; es más flojo en razonamientos largos y en conocimiento muy especializado. Mantén una clave de nube con límite de gasto para esa pequeña parte y manda el volumen rutinario y privado a la máquina local. Los agentes cuarto, quinto y sexto naturales son el triaje de soporte, la extracción de facturas y el seguimiento de la competencia, con el mismo stack de Ollama, MCP y SQLite.

Siguientes pasos

• La capa de flujos de trabajo: n8n + MCP: conecta agentes de IA a las herramientas de tu negocio.
• Qué tamaño de modelo: SLM frente a LLM: modelos pequeños o grandes para tu empresa.
• ¿Está lista tu empresa?: Checklist de preparación para IA local.
• Referencia: documentación de MCP y biblioteca de modelos de Ollama.

Trabaja con nosotros

Llevamos nuestra propia empresa con este patrón (una persona y un conjunto de agentes locales en una estación de trabajo) y lo desplegamos para pymes españolas y europeas. Si quieres ayuda para elegir tus tres primeras automatizaciones, reserva una llamada de 15 minutos o mira cómo trabajamos en consultoría.