Asistente de IA autoalojado para Slack: opciones 2026

Por qué estás buscando esto

Ya tienes una opción de IA dentro de Slack. Slack AI viene incluido en los planes de pago, y Salesforce empuja Agentforce como la superficie de agente por defecto en la barra lateral de Enterprise Grid. Las dos funcionan, las dos son cómodas y las dos tienen la misma propiedad dura: cada mensaje que lee el agente pasa por la pipeline de inferencia de otro, y la memoria que ese agente construye sobre tu equipo vive en una base de datos del proveedor que tú no puedes inspeccionar.

Para muchos equipos ese intercambio es asumible. Para el resto - sectores regulados, agencias que manejan datos de cliente bajo NDA, founders que no quieren que un tercero indexe sus hilos de estrategia, equipos europeos preocupados por la CLOUD Act estadounidense - la respuesta tiene que ser otra. Quieres la UI de chat de Slack, pero quieres que la parte de IA corra sobre infraestructura que tú controlas, con secretos que son tuyos y sin un tercero en medio.

Este artículo recorre qué significa realmente "asistente de IA autoalojado para Slack" en 2026, las opciones open source que hoy traen un adaptador de Slack, las decisiones de arquitectura que no puedes evitar y dónde falla cada opción.

Lo que no puedes autoalojar: el propio Slack

La primera aclaración es incómoda. Slack no es autoalojable. Corre exclusivamente sobre la nube de Salesforce, y ni siquiera Enterprise Grid con International Data Residency te deja más que elegir una región geográfica para el almacenamiento. No puedes instalar Slack en tu propio servidor y no controlas las claves de cifrado.

Lo que sí puedes autoalojar es el agente al otro lado de la API de Slack. El mensaje sigue tocando los servidores de Slack - es inevitable mientras Slack sea tu superficie de chat. Pero en el momento en que Slack entrega ese mensaje a tu bot, tú decides a dónde va después: qué proveedor de LLM lo ve, qué base de datos guarda la conversación, qué almacén vectorial lo recuerda el mes que viene. Esa es la frontera real que estás trazando.

Si necesitas que la plataforma de chat en sí viva en tus servidores, lo que buscas es un reemplazo de Slack (Mattermost, Rocket.Chat, Zulip), no un bot autoalojado para Slack. La mayoría de los equipos se queda con Slack y solo autoaloja el agente.

Un esquema con un canal de Slack a la izquierda y un runtime de agente autoalojado a la derecha, unidos por una flecha etiquetada Socket Mode

Qué te compra el autohospedaje

Tres cosas concretas, y conviene ser honesto sobre cuál te importa de verdad antes de elegir stack.

Control sobre lo que sale del espacio de trabajo. Un bot autoalojado lee un evento de Slack, decide qué contexto reenvía al LLM, y esa lógica de decisión la escribes tú. Puedes quitar nombres de usuario, redactar patrones regex, enrutar solo ciertos canales a un modelo externo y dejar otros sobre un modelo local.

Tu propia factura de modelo, no una tarifa por usuario de IA. Slack AI se cobra por usuario. Agentforce se cobra por conversación. Un bot autoalojado con BYOK paga al proveedor del modelo directamente, normalmente céntimos por usuario activo y día sobre precios de API comunes.

Una memoria persistente que puedes auditar. La memoria de la IA alojada es opaca. Un agente autoalojado guarda su memoria en una Postgres o SQLite que tú posees. Puedes leerla, exportarla, borrarla y hacer copias de seguridad.

Lo que el autohospedaje no te compra: menos coste operativo el primer mes. Vas a invertir una tarde cableando el bot y vas a quedarte responsable de reinicios, actualizaciones de modelo y alguna migración esporádica de scopes de Slack. El ahorro aparece al tercer mes, no la primera semana.

Las opciones open source que de verdad traen adaptador de Slack en 2026

La mayoría de proyectos "AI bot for Slack" de GitHub resultan ser envoltorios finos sobre la API de OpenAI sin memoria, sin uso de herramientas y sin runtime de larga duración. La lista de abajo está filtrada a proyectos que sí traen un adaptador de Slack, tienen una capa de memoria y se mantienen en 2026.

| Proyecto | Forma | Modo Slack | Bueno en | Donde flojea | |---|---|---|---|---| | OpenClaw | Runtime de agente personal de larga duración, 200K+ stars | Socket Mode, 24+ canales | Amplitud multicanal (Telegram + WhatsApp + Slack + Signal + iMessage en un mismo daemon) | Orientado a cuenta personal; la ergonomía para workspaces de equipo es básica | | Hermes Agent | Agente headless con memoria y skills, corre como servicio | Socket Mode vía adaptador oficial | Allowlist por usuario, tareas programadas, skills personalizadas, soporte MCP | Tú gestionas el VPS salvo que uses un host gestionado | | Archer (SlackAgent) | Agente nativo de Slack sobre Arcade + LangGraph | Diseñado para Slack desde el principio | UX nativa de Slack (slash commands, previsualizaciones efímeras), integraciones de Google/GitHub/Search | Solo Slack; sin fallback a Telegram o WhatsApp | | Moltworker | Agente personal autoalojado sobre Cloudflare Workers | Webhook | Modelo edge-runtime, sin VPS que cuidar | Restricciones del runtime de Workers, comunidad menor | | Open Source Slack AI | Utilidades equivalentes a funciones premium de Slack AI (resúmenes de hilo y canal) | App | Encaja como reemplazo de los resúmenes premium de Slack AI | No es un agente completo - solo herramientas de resumen, sin acciones agénticas | | Mattermost + bot a medida | Alternativa open source a Slack con framework de bots | Nativo | Plataforma de chat completa y bot en un stack autoalojado | Estás reemplazando también Slack como cliente de chat, una migración mucho mayor |

El resumen honesto: si quieres seguir en Slack y quieres un agente de verdad (memoria, herramientas, tareas programadas, razonamiento multi-paso), la lista realista en 2026 es OpenClaw, Hermes Agent o Archer. El resto son utilidades de propósito único o reemplazos completos de Slack.

Socket Mode es lo que hace indoloro el autohospedaje

Todas las opciones de arriba excepto Moltworker usan Socket Mode de Slack. Entender por qué importa antes de elegir stack.

Una app tradicional de Slack usa la Events API: Slack envía un POST HTTPS a una URL pública que tú controlas cada vez que pasa algo. Autoalojar eso significa exponer un endpoint HTTPS público con un certificado TLS válido, lo que implica un dominio, un proxy inverso, un certificado TLS que se autorrenueva y un puerto entrante abierto en el firewall. Para un Mac personal o un servidor de oficina pequeño, esa es la parte que normalmente mata el proyecto.

Socket Mode invierte la dirección. Tu bot abre un WebSocket saliente hacia Slack y lo mantiene abierto. Cada evento llega por esa misma conexión. Sin URL pública, sin puerto entrante, sin TLS que gestionar. El bot puede correr en tu portátil, en un VPS de $5 o detrás de un firewall corporativo y va a recibir los mensajes igual.

La contrapartida es que las conexiones Socket Mode se caen. La documentación de Slack es explícita: a escala el WebSocket reconecta y cualquier evento que se dispare durante el hueco se pierde - Slack no lo reproduce. Cualquier agente autoalojado de calidad necesita lógica de reconexión y un handler de mensajes idempotente, y eso es algo que los proyectos mantenidos de arriba ya traen.

El checklist de endurecimiento que nadie menciona hasta que duele

Las cinco cosas que cerrar antes de dejar que un bot autoalojado lea algo sensible:

Una allowlist numérica. Todo agente de Slack serio soporta una variable SLACK_ALLOWED_USERS (o equivalente). Espera IDs numéricos de Slack (U01ABC234), no handles. Sin eso el valor por defecto seguro tiene que ser deny-all - si no, un bot invitado a un canal público respondería a cualquiera. Saca tu ID desde el menú de tres puntos de tu perfil de Slack, "Copy member ID".

Tokens con scopes, no tokens de usuario. Usa un bot token (xoxb-…) con los scopes mínimos que necesitas - típicamente app_mentions:read, chat:write, im:history, im:write, users:read. Evita los user tokens (xoxp-…) por completo; le dan al bot acceso total a tu cuenta, lo que multiplica el radio de impacto si el host se compromete.

Secretos fuera de git. Cada token (bot token de Slack, app-level token, clave del proveedor de modelo) vive en un fichero .env que está en gitignore, o en un gestor de secretos. Los repos públicos de GitHub con un xoxb- filtrado se explotan en minutos.

Un proxy inverso para cualquier ruta webhook. Si no usas Socket Mode, tu bot necesita un endpoint HTTPS público. Pon Caddy o Traefik delante para terminar TLS y para rate limiting. Nunca enlaces el agente directamente a un puerto público.

Un proveedor de modelo en el que confíes. Autoalojar el agente no sirve de nada si después mandas cada mensaje de Slack a un LLM con garantías de privacidad débiles. Elige un proveedor con cláusula de no-entrenamiento, o ejecuta el modelo localmente (Ollama en una workstation con VRAM suficiente) para los canales más sensibles.

Un recorrido más profundo por estas decisiones vive en la guía Docker del agente de IA autoalojado, que es la base más popular para cualquiera de los runtimes anteriores.

Dónde encaja Hermes Agent y cuándo tiene sentido Hermify

Hermes Agent es la opción más cercana en espíritu a lo que buscan la mayoría de los equipos que hacen esta búsqueda: un único runtime headless, soporte de Slack vía Socket Mode listo de fábrica, allowlist por ID numérico, memoria persistente en una base de datos que tú controlas, skills personalizadas, tareas programadas y una imagen Docker que corre en cualquier VPS de $5. La instalación paso a paso de Slack está documentada en Cómo configurar Hermes Agent en Slack - unos diez minutos si ya tienes el runtime arriba.

Una terminal oscura de VPS mostrando una salida de docker compose ps con un contenedor hermes-agent en estado healthy y un pequeño punto verde de status

El enfoque honesto sobre Hermify: lo construimos para la segunda mitad del autohospedaje, la que el README nunca te avisa. Elegir runtime es el día fácil. Mantener el VPS parcheado, rotar tokens de Slack, sobrevivir a un incidente del proveedor del modelo, reconstruir el contenedor tras una actualización de Hermes y ver que el bot reconecta limpio tras una caída de Slack es la parte que se come las tardes. Hermify ejecuta esa capa de ops por ti y al mismo tiempo te deja BYOK sobre el modelo - la misma frontera de datos, menos fontanería. Si prefieres poseer todo el stack desde el VPS hacia arriba, el desglose de precios self-hosted vs gestionado pone los números reales sobre la mesa para que decidas con fundamento, no por intuición.

Si estás listo para saltarte las tardes de infra, empieza con Hermify y tendrás un Hermes Agent listo para enchufar a Slack en menos de cinco minutos. Si prefieres hacerlo tú mismo, las opciones open source de arriba son reales y merecen tu tiempo. Cualquiera de los dos caminos mantiene el contenido de tu Slack fuera de la pipeline de inferencia de otro, que es el objetivo de verdad.