Copiloto interno con n8n: arquitectura y controles

GUÍAS · TUTORIALES · AUTOMATIZACIÓN

1. Qué es un “copiloto interno” (de verdad)

Llamo “copiloto interno” a un sistema que combina tres cosas:

• Un modelo de lenguaje (LLM) que entiende tus preguntas y genera respuestas útiles.
• Acceso a tu conocimiento interno: documentos, políticas, base de conocimiento, tickets, etc.
• Capacidad de actuar sobre tus herramientas: crear tareas, enviar emails, actualizar filas en Sheets, registrar notas en el CRM…

No es solo “un chat para preguntarle cosas”. Según los permisos y controles que configures, un copiloto puede proponer o ejecutar tareas delimitadas:

• Responder dudas típicas de equipos (RRHH, procesos internos, precios, soporte…).
• Proponer resúmenes de contratos, propuestas o actas para revisión antes de incorporarlos al gestor de tareas.
• Ayudar a preparar campañas, posts o contenidos reutilizando material que ya tenéis, como explico cuando hablo de usar IA para crear un blog que atrae clientes.
• Preparar tareas de backoffice, como clasificación de formularios o informes, con aprobación cuando afecten a personas o datos críticos.

Un modelo alojado por tu equipo puede reducir la dependencia de una API de generación externa. Las fuentes, el canal, el alojamiento y los servicios de embeddings pueden seguir siendo de terceros. Dibuja ese flujo de datos antes de llamarlo privado.

2. Arquitectura mínima: las 4 piezas que necesitas

Antes de entrar en pasos, visualiza el sistema como un diagrama muy simple de cuatro bloques:

1. Modelo con licencia comprobada: elige una versión concreta que puedas alojar y usar para el fin previsto; familias como Llama, Mistral y Qwen ofrecen variantes con licencias y requisitos distintos.
2. n8n: el “orquestador”. Un motor de workflows que recibe mensajes, llama al modelo, consulta bases de datos y ejecuta acciones.
3. Capa de conocimiento: donde viven tus documentos indexados para búsqueda semántica (RAG: embeddings + vector DB).
4. Canales de entrada/salida: Slack, Teams, email, un formulario web o incluso un botón en tu intranet.

Tu copiloto interno no es un producto mágico: es el resultado de que estos cuatro bloques hablen bien entre sí. Vamos a montar esa conversación.

3. Paso 1: elegir y probar un modelo con licencia adecuada

Lo primero es decidir qué modelo vas a usar como “cerebro” del copiloto. Aquí tienes tres variables clave:

• Idioma y dominio: si tu equipo trabaja en español, busca modelos con buen rendimiento multilingüe. Si el uso principal es código, prioriza modelos especializados en programación.
• Licencia: revisa la versión exacta del modelo, sus condiciones de uso, redistribución y alojamiento; “pesos disponibles” no equivale automáticamente a una licencia abierta.
• Hardware disponible: no es lo mismo correr un modelo de 7B parámetros en una máquina modesta que uno de 70B en una GPU potente.

Compara versiones concretas de Llama, Mistral o Qwen con tus documentos e idiomas; una etiqueta de familia no predice memoria necesaria, rendimiento ni licencia. Una guía de selección de 2025 puede dar contexto histórico, pero vuelve a comprobar modelos y condiciones actuales.

¿Dónde lo despliego?

Tienes tres caminos típicos:

• Local / on-premise: ejecutas el modelo en una máquina gestionada por tu equipo, si licencia y hardware lo permiten. Debes protegerla, actualizarla y comprobar si otros componentes siguen enviando datos fuera.
• Cuenta cloud bajo tu control: alojas el servicio en infraestructura contratada, con acceso restringido y costes de cómputo, red, almacenamiento y operación.
• Proveedor gestionado: contratas una API para un modelo concreto; revisa contrato, región, retención y compatibilidad real antes de enviar documentos internos.

La integración puede usar un nodo compatible o una llamada HTTP, según la API real del proveedor. No todos los modelos exponen /v1/chat/completions; prueba autenticación, formato, tiempos de respuesta y fallos con el modelo elegido.

4. Paso 2: n8n como cerebro orquestador

n8n es un orquestador de flujos con código disponible bajo una licencia de uso sostenible, no una licencia open source sin restricciones. Conecta aplicaciones y ofrece nodos de IA; la disponibilidad y la configuración dependen de la edición y versión. Revisa la licencia oficial antes de prestar un servicio a terceros.

Para un copiloto interno, n8n suele jugar tres papeles:

• Punto de entrada: recibe mensajes desde Slack, un webhook, un formulario, etc.
• Router controlado: decide por reglas cuándo buscar documentos autorizados, cuándo responder y cuándo pedir ayuda humana.
• Ejecutor delimitado: prepara tareas, correos o cambios de registro; requiere autorización antes de escribir o enviar.

Puedes autoalojar n8n o usar su nube. Elige tras revisar licencia, permisos, acceso a registros, retención, mantenimiento y proveedores conectados. Alojarlo tú no concede por sí solo aislamiento de datos ni funciones empresariales.

Piensa en n8n como una capa intermedia entre “la inteligencia del modelo” y “la realidad de tu negocio”. Ahí es donde pones reglas, permisos y lógica para que el copiloto haga cosas útiles y no se convierta en un juguete más en la empresa.

5. Paso 3: conectar el modelo con n8n

Con el modelo corriendo y n8n instalado, el siguiente paso es unirlos. Hay dos enfoques comunes:

A) Usar nodos de LLM de n8n

n8n incorpora nodos tipo “Basic LLM Chain” y “AI Agent” que abstraen parte del trabajo de hablar con modelos. El modelo debe ser compatible con el nodo elegido; verifica versión, credenciales y formato antes de importar un ejemplo. Tú defines:

• El endpoint y la clave de la API de tu modelo.
• El prompt base (rol del asistente, instrucciones, formato de salida).
• Opcionalmente, cómo parsear la respuesta (por ejemplo, devolver siempre JSON con campos concretos).

Ventaja: menos “pegamento” que escribir y mejor integración con otros nodos de IA que ya trae n8n (herramientas, memoria, etc.).

B) Tratar tu modelo como cualquier API HTTP

La alternativa simple: usas el nodo “HTTP Request” de n8n para llamar a tu modelo como llamarías a cualquier API REST. Sueles mandar un JSON con:

• El historial de mensajes (usuario / sistema / asistente).
• Parámetros como máximo de tokens, temperatura, top_p, etc.
• Metadatos opcionales (id de usuario, contexto, etc.).

Después validas la estructura de la respuesta y la devuelves al canal de origen con el nodo adecuado, por ejemplo Code o Edit Fields. Una llamada HTTP ofrece flexibilidad, pero exige gestionar autenticación, errores y formato de cada proveedor.

En ambos casos, te recomiendo encapsular esta lógica en un workflow o sub-workflow que haga solo una cosa: recibir un mensaje + contexto y devolver una respuesta del modelo. Ese será el “core” de tu copiloto, reutilizable desde otros flujos.

6. Paso 4: darle memoria con tus documentos (RAG)

Un LLM “puro” puede responder bien a preguntas generales, pero tu equipo quiere respuestas sobre vuestros procesos, plantillas, clientes, productos.... Para eso necesitas RAG (Retrieval Augmented Generation): buscar primero en tus datos y luego pasar ese contexto al modelo.

Cómo montar la capa de conocimiento con n8n

El patrón típico es:

1. Ingesta: un workflow que escucha cambios en tu fuente de documentos (carpetas de Google Drive, Notion, Confluence, CRM, etc.).
2. Particionamiento: divide cada documento en trozos pequeños (párrafos, secciones) para que las respuestas sean granulares.
3. Embeddings: transforma los fragmentos con un modelo elegido tras revisar dónde se procesan y conservan los textos.
4. Almacenamiento vectorial: guarda los vectores en una base de datos vectorial (Postgres+pgvector, Qdrant, Pinecone, Supabase, lo que prefieras).
5. Búsqueda: cuando llegue una pregunta, creas un vector de la query y recuperas los fragmentos más cercanos para pasárselos al LLM como contexto.

La guía de RAG de n8n explica recuperación de contexto. Decide qué documentos puedes indexar, cómo eliminar versiones obsoletas y cómo comprobar permisos antes de entregar fragmentos al modelo: una base vectorial no hereda automáticamente los permisos de Drive o Notion. Métodos como GraphRAG añaden complejidad y necesitan una justificación concreta.

Empieza con pocas fuentes, vigentes y autorizadas, por ejemplo preguntas frecuentes internas y políticas no sensibles. Evalúa respuestas con preguntas reales y comprueba citas, errores y casos que el asistente debe rechazar.

7. Paso 5: que no solo hable, que haga cosas (automatizaciones)

Una respuesta útil puede convertirse en una propuesta de acción. Configura lectura por defecto, herramientas con permisos mínimos y aprobación humana para escrituras o mensajes externos. Los ejemplos siguientes son hipotéticos:

• Cuando pides “resúmeme esta reunión y crea tareas para marketing”, el flujo:

– Genera el resumen.
– Extrae las acciones en formato estructurado (JSON).
– Propone tareas para que una persona revise responsable y fecha antes de crearlas.
– Publica el resumen solo después de comprobar permisos y destinatarios.

• Cuando subes un nuevo contrato a una carpeta, el workflow:

– Lo detecta.
– Lo pasa por el modelo para extraer campos clave (fechas, importes, partes).
– Prepara los campos para revisión antes de escribir en Sheets o en un ERP.
– Notifica al responsable legal con un resumen.

• Cuando recibes un formulario web de un lead, el copiloto:

– Clasifica al lead según criterios internos.
– Propone un email de respuesta para aprobación humana.
– Propone datos para el CRM y próximos pasos; valida identidad, base de datos y duplicados antes de guardar.

Este patrón también se puede estudiar para datos de Excel/Sheets. La integración con procesos reales debe limitar acciones, registrar aprobaciones y admitir reversión.

8. Seguridad, permisos y límites (muy importante si usas datos sensibles)

En cuanto montas un copiloto que habla con documentos internos, la pregunta obvia es: ¿y esto quién lo puede ver? Algunas prácticas básicas:

• Segmenta fuentes de conocimiento: no mezcles en el mismo índice documentos de RRHH, finanzas y soporte. Crea varios “espacios” y haz que cada canal de entrada solo consulte lo que debe.
• Aplica permisos en cada consulta: verifica la identidad del usuario y filtra los fragmentos recuperados por sus derechos actuales. Una cuenta de servicio amplia puede revelar documentos aunque la fuente original limite el acceso.
• Limita los registros: configura qué datos de ejecución se guardan, quién puede verlos y cuánto se conservan. Evita prompts y respuestas sensibles cuando no sean necesarios; la documentación oficial de n8n describe estas opciones.
• Separa lectura y escritura: empieza con propuestas y exige aprobación humana para crear tareas, modificar registros o enviar mensajes. n8n documenta la revisión de herramientas.

Prueba también instrucciones maliciosas dentro de los documentos recuperados, respuestas sin fuente y cambios de permisos. La guía de seguridad RAG de OWASP describe la inyección desde documentos y los controles del flujo. Separa pruebas de producción, supervisa errores y define quién puede detener el flujo.

9. Blueprint rápido: ejemplo de copiloto interno con Slack + Drive + LLM local

Para aterrizarlo, te dejo un flujo sencillo que puedes usar como referencia. Imagina que quieres un copiloto al que tu equipo de operaciones pueda hablar desde Slack para:

• Preguntar por procesos y políticas internas.
• Subir documentos y recibir resúmenes.
• Crear tareas en el gestor de proyectos.

Pasos resumidos

1. Despliega el modelo (por ejemplo, un Llama o Mistral mediano) en una máquina accesible por n8n, exponiendo un endpoint HTTP de chat.
2. Instala n8n en tu servidor y crea credenciales para Slack, Google Drive y tu gestor de tareas.
3. Crea un workflow de ingesta limitado a documentos autorizados y vigentes; conserva metadatos de acceso y define cómo retirar documentos. Antes de cada búsqueda, filtra por permisos actuales del usuario.
4. Crea un sub-workflow “LLM Chat” que reciba {usuario, mensaje, contexto autorizado} y llame al modelo por HTTP o con un nodo compatible.
5. Monta el flujo principal de chat con un trigger de Slack (slash command o mensajes en un canal concreto).
6. Según el mensaje, tu lógica puede:

– Comprobar identidad y permisos, después recuperar fragmentos relevantes; el número depende de la prueba.
– Construir un prompt que mezcle esos fragmentos con la pregunta del usuario.
– Llamar al sub-workflow “LLM Chat” y devolver la respuesta a Slack.

7. Si el usuario pide crear tareas, el flujo prepara una propuesta:

– Pide al LLM que devuelva las acciones en formato JSON (título, responsable, fecha).
– Valida ese JSON y presenta la propuesta para aprobación antes de crear tareas.
– Confirma qué se aprobó y creó, o informa de que quedó pendiente.

8. Añade métricas sin contenido sensible: registra acierto evaluado, rechazo correcto, permisos denegados, propuestas aprobadas y errores. Revisa muestras autorizadas para mejorar el sistema.

Con este patrón básico, puedes ir añadiendo capas: otros equipos, otros canales (Teams, email), otras fuentes de datos (tickets, CRM) e incluso agentes más complejos como los que veremos cada vez más en escenarios de asistentes multimodales y agentic.

10. Errores típicos al montar un copiloto interno

Algunos tropiezos que veo una y otra vez (y que puedes ahorrarte):

• Intentar cubrir toda la empresa de golpe. Mucho mejor empezar con un equipo o proceso concreto (por ejemplo, soporte interno de TI) y expandir desde ahí.
• Meter todos los documentos sin filtrar. Si tu índice está lleno de basura, tu copiloto también. Curar el contenido inicial es trabajo pesado, pero marca la diferencia.
• Obsesionarse solo con el modelo. Un LLM espectacular con workflows mal pensados da una experiencia mediocre. Invertir tiempo en los flujos de n8n y en el diseño de prompts compensa mucho.
• Olvidar la parte humana. Hay que explicar al equipo qué hace el copiloto, qué no hace, cómo se usan las respuestas y cómo se reportan errores o mejoras. Sin eso, acabará cogiendo polvo.

Al final, tu copiloto interno es tanto un proyecto de producto y cambio cultural como uno de tecnología. Igual que cuando montas un sistema de automatización comercial o una intranet nueva, no va solo de “ponerlo a funcionar”, sino de integrarlo en la rutina diaria.

11. Cierre: tu propio copiloto, a tu manera

Un producto gestionado y una arquitectura propia son opciones distintas. Decide a partir de un caso de uso, permisos, coste total, soporte y capacidad del equipo. Si eliges construir, empieza por un piloto con fuentes autorizadas y sin escritura automática.

El trabajo técnico sigue importando: licencias, calidad de datos, permisos, evaluación y operación. Define un problema concreto, mide la calidad con casos de prueba y amplía solo cuando el equipo pueda mantener los controles.

Un piloto útil deja evidencia: preguntas resueltas con fuente, errores identificados, permisos respetados y tiempo neto. Esa evidencia decide si merece extenderlo.