Por qué una buena base de conocimientos sigue sin leerse
La pregunta y la respuesta viven en aplicaciones diferentes
Esto lo es todo, y es algo mundano. Una pregunta es un acto social realizado en un cliente de chat. Consultar la documentación es un acto solitario realizado en una pestaña del navegador. Preguntar a un colega cuesta un mensaje; consultar la wiki cuesta un cambio de contexto, una búsqueda y el riesgo de no encontrar nada.
Un documento responde a una página, no a una pregunta
Incluso una base de conocimientos bien mantenida devuelve documentos. El lector hace la extracción: hojea la página, localiza el párrafo, decide si sigue vigente, lo traduce en una respuesta para el caso que tiene delante.
Ese paso es invisible en la planificación y enorme en la práctica, y es por eso que el "tenemos eso documentado" coexiste tan cómodamente con la misma pregunta que llega mensualmente. La información está presente; la respuesta no está armada. La recuperación y la memoria no son la misma operación, distinción que se detalla en por qué RAG no es memoria.
La búsqueda de tu plataforma de chat está limitada a tu plataforma de chat
Slack ha invertido en esto y funciona, dentro de un límite documentado. Sus funciones de IA están, en palabras de Slack, "respaldadas por el conocimiento en tu espacio de trabajo". Las respuestas se "basan en información relevante en Slack, en lugar de filtrar los resultados de búsqueda", e "incluyen citas que hacen referencia a los mensajes o archivos de origen que las informaron".
Dos limitaciones documentadas importan cuando tu conocimiento vive en otro lugar. La disponibilidad depende del plan: los filtros de búsqueda automática se enumeran a partir de Pro, mientras que las respuestas de búsqueda aparecen en Business+ y Enterprise+. Y el corpus es tu propio contenido accesible: "Las respuestas generadas por IA solo incluyen información disponible para ti (como mensajes y otro contenido de canales públicos, y cualquier canal privado y mensaje directo al que pertenezcas)".
Llegar al exterior es una capacidad distinta: "Si estás en el plan Enterprise+, un propietario o administrador de la organización puede habilitar la búsqueda empresarial para incluir contenido e información de otras fuentes (como Google Drive, GitHub y más) en los resultados de búsqueda". Ese es un diseño sensato y también es la respuesta a por qué el asistente en tu aplicación de chat no puede citar el manual de procedimientos (runbook) que vive en tu sistema de documentos.
El material compartido en el chat es el más contextual y el menos duradero
Los artefactos más útiles en la mayoría de los espacios de trabajo se pegan en el chat: la captura de pantalla del error, el PDF firmado, la hoja de cálculo que alguien reconstruyó a medianoche. Slack los cuenta dentro de la misma ventana de historial: "Los archivos incluyen cosas como clips, PDF, documentos, imágenes, capturas de pantalla y archivos de audio y video", y en la versión gratuita, "Puedes ver y buscar mensajes y archivos de los últimos 90 días", eliminándose los datos de "más de un año de antigüedad".
Así que la capa más rica del conocimiento de tu equipo se encuentra en el lugar menos permanente que posees, y ninguna actualización de la wiki la captura, porque nadie piensa en una captura de pantalla pegada como documentación.
El asistente privado de cada persona tiene un contexto privado
La solución alternativa a la que recurre la gente es su propia suscripción de IA: pegar el contexto de fondo, obtener una respuesta. Funciona una vez, para una persona. El contexto se queda en una cuenta individual, por lo que nada se acumula en ningún lugar compartido; la división descrita en memoria entre herramientas para trabajadores del conocimiento, y a escala de organización en el olvido de la IA empresarial.
Qué intentan los equipos
Fijar el enlace del manual en cada canal. Barato, y aun así termina en un cambio de contexto. Los elementos fijados también se convierten en una lista curada que nadie cura.
Un canal #manual o de anuncios. Convierte la base de conocimientos en un feed, y los feeds se leen una vez, el día de la publicación, por quienquiera que estuviera en línea.
Un bot de búsqueda sobre el historial de chat. Útil, y limitado al chat: no puede responder a partir de un documento que nunca se publicó.
Comprar a todos una suscripción personal de IA. Resuelve el rendimiento individual y deja el conocimiento del equipo donde estaba. Los equipos de soporte sienten esto con fuerza; el patrón descrito en cuando un asistente olvida tus tickets de soporte.
Designar a un responsable del conocimiento. A veces es lo correcto, pero concentra el fallo en el calendario de una sola persona en lugar de eliminarlo.
La solución: Dejar que la base de conocimientos responda donde se hace la pregunta
El replanteamiento: deja de intentar llevar a la gente a la base de conocimientos y lleva la base de conocimientos al chat grupal. Concretamente, eso significa un bot en el canal que responda a partir de un cuerpo de memoria designado (no del conocimiento genérico de un modelo de propósito general) y que escriba cada intercambio de vuelta en el mismo lugar.
Esa segunda mitad es lo que diferencia esto de un cuadro de búsqueda con una interfaz de chat. En la conexión de mensajería instantánea (IM) de MemoryLake, los intercambios se convierten en memoria, por lo que el corpus crece a partir de las preguntas que tu equipo realmente hace, en lugar de un sprint de documentación que alguien tiene que programar. La configuración consta de tres pasos, y las diferencias entre plataformas están todas en el paso dos.
Paso 1: Agregar la conexión de IM
En la consola, abre MemoryLake → Workspaces, abre el espacio de trabajo cuya memoria deseas exponer, cambia a la pestaña IM y elige tu plataforma. Dos requisitos previos antes de comenzar: necesitas el rol de propietario o administrador en el equipo, ya que los miembros "no pueden ver ni cambiar las integraciones", y el espacio de trabajo necesita al menos un proyecto más un agente vinculado a él.

Paso 2: Introducir las credenciales de la aplicación
Cada plataforma emite un par diferente y cada una tiene una realidad de aprobación distinta. Esta es la parte que vale la pena planificar.
| Plataforma | Lo que pegas | Lo que te cuesta administrativamente |
|---|---|---|
| Slack | Bot User OAuth Token (xoxb-) + App-Level Token (xapp-) | Nada que revisar. La documentación lo indica directamente: "Nada en el lado de Slack requiere un ciclo de revisión; una sola persona puede terminar la configuración en unos diez minutos". |
| Feishu | App ID (cli_) + App Secret | Derechos de administrador, y "publicar una versión requiere la revisión del administrador". Los alcances (scopes) están inactivos hasta entonces: "Los permisos solo surten efecto una vez que se ha publicado y aprobado una versión". |
| DingTalk | Client ID + Client Secret | Derechos de administrador de DingTalk, porque tú creas la aplicación, solicitas los permisos y la publicas. |
Dos notas que ahorran tiempo real. En Slack, crear la aplicación desde un manifiesto configura los alcances (scopes), las suscripciones a eventos, la entrada de mensajes directos (DM) y el Socket Mode en un solo pegado; y cualquier cambio posterior en los alcances o eventos requiere una Reinstall to Workspace (Reinstalación en el espacio de trabajo) antes de que surta efecto. En DingTalk hay un tercer campo opcional, un AI card template ID (ID de plantilla de tarjeta de IA): dejarlo vacío significa un mensaje por respuesta, mientras que configurarlo permite la transmisión (streaming) carácter por carácter.
Una trampa de nombres que vale la pena detectar antes de solicitar nada: "Feishu y Lark son dos plataformas independientes". Feishu es la edición para China, Lark la internacional; las cuentas y las aplicaciones no se transfieren, y con cuál habla una implementación determinada es una configuración a nivel de implementación en lugar de una opción por integración. Confirma esto con tu administrador antes de que se cree una aplicación en la consola incorrecta.

Paso 3: Crear y conectar
Elige el agente que responde a los mensajes desde el lado del chat, luego establece el alcance de la memoria: un proyecto de lectura y escritura obligatorio del cual el bot recupera y en el cual escribe, más cualquier cantidad de proyectos de solo lectura que pueda buscar pero nunca escribir.

Trata esto como la decisión de seguridad que es. La documentación lo dice claramente: "El proyecto de lectura y escritura es una decisión de autorización", porque todos los que pueden comunicarse con el bot escriben en ese proyecto y pueden leer lo que ya está en él. Apúntalo a un proyecto que tenías la intención de compartir con el equipo, no al que contiene material confidencial. Luego crea la integración y confirma que la tarjeta muestra Connected (Conectado).
Tres límites sinceros. El bot no lee tu historial de chat: en todas las plataformas solo recibe mensajes que lo mencionan, por lo que no puede ver otras conversaciones en el canal o grupo. Responde desde el proyecto que conectaste, lo que significa que la calidad de la primera semana es la calidad de lo que cargaste. And es contexto más que imposición: para cualquier cosa que deba ser cierta, una política o una verificación es la garantía, no una capa de memoria.
Qué difiere según la plataforma una vez que está en funcionamiento
La mecánica diverge de formas que sorprenden a los equipos desde el primer día.
Llamar la atención del bot. En los chats grupales, los tres requieren una @mención; los mensajes no mencionados nunca se entregan. Los mensajes directos (DM) difieren: en Slack, los miembros encuentran la aplicación en Apps (Aplicaciones) en la barra lateral y preguntan sin necesidad de @; los DM de Feishu se rigen por el alcance de disponibilidad de la aplicación; la integración de DingTalk está documentada en torno al uso grupal.
Dónde aparece la respuesta. Slack responde en un hilo debajo de tu pregunta, manteniendo legible un canal con mucha actividad. Feishu cita tu mensaje y te devuelve la @mención, que es lo que evita que la respuesta se pierda en un grupo rápido.
Cómo se transmiten las respuestas. Feishu transmite palabra por palabra. Slack transmite editando el mismo mensaje en segmentos; se espera el marcador (editado) y la velocidad de actualización disminuye después de aproximadamente los primeros doce segundos. DingTalk envía un mensaje por respuesta a menos que hayas proporcionado un AI card template ID.
Enviar un archivo o una captura de pantalla. Slack necesita el archivo y la mención en un solo mensaje: "Un archivo publicado en un canal por sí solo (sin una mención) nunca llega al bot; Slack no lo entrega". La ruta documentada de Feishu para un documento grupal es publicar el archivo, luego responder a ese mensaje y @mencionar al bot. DingTalk acepta @bot más texto más imagen como un único mensaje de texto enriquecido.
Cuánto dura el contexto. Los canales de Slack son por hilo sin caducidad; volver al mismo hilo un día después sigue funcionando. Los grupos de Feishu y DingTalk tienen un alcance por tema: después de 8 minutos de silencio, la siguiente pregunta inicia un nuevo tema, y esa ventana se amplía a 30 minutos justo después de un archivo o captura de pantalla para que los seguimientos sobre la misma imagen sigan funcionando.
Empezar de nuevo. En Feishu y DingTalk, envía /new. En Slack, la palabra de reinicio no lleva barra diagonal (slash); el cliente intercepta cualquier cosa que comience con / como un comando de barra diagonal, por lo que es new por sí solo en un DM, o @bot new dentro de un hilo.
Quién tiene permitido entrar. El acceso se decide del lado de la plataforma de chat, no mediante una segunda lista de permitidos. Los usuarios de Slack Connect de organizaciones externas se ignoran silenciosamente: sin uso de cuota ni escrituras en la memoria. DingTalk maneja mensajes solo de miembros de tu propia organización. En Feishu, los DM siguen el alcance de disponibilidad de la aplicación y los grupos siguen la membresía del grupo.
Privacidad dentro de un grupo. En los tres, el contexto de la conversación es por persona: en el mismo grupo o hilo, el intercambio de una persona nunca aparece en el de otra. La memoria del proyecto se comparte, que es el propósito de conectarlo en primer lugar.
Buenas prácticas para una base de conocimientos que responde
Conecta un proyecto, no todo lo que posees. Comienza con un proyecto limitado a lo que el equipo debe saber colectivamente, y agrega proyectos de solo lectura para el material que el bot pueda citar pero nunca modificar.
Aliméntalo con las preguntas que ya respondes, no con tu biblioteca de documentos. Veinte preguntas recurrentes con sus respuestas y motivos superan a doscientas páginas, porque el motivo es lo que sobrevive cuando cambian los detalles específicos.
Escribe una afirmación por entrada. Las entradas cortas e independientes se recuperan limpiamente. Los documentos largos se devuelven completos y devuelven el trabajo de extracción al lector, el mismo fallo que tenía la wiki.
Elige la plataforma en la que realmente vives. La integración no vale nada si las preguntas llegan a otro lugar. Una configuración perfecta de Slack es peso muerto en una empresa que funciona con DingTalk.
Dile a la gente las dos reglas el día del lanzamiento. Menciona al bot cada vez, incluidas las respuestas a hilos, y adjunta archivos en el mismo mensaje que la mención. Casi todos los informes de "me ignoró" se deben a uno de esos detalles.
Pregunta primero a un administrador en Feishu o DingTalk. Ambos necesitan publicación y revisión de permisos, por lo que una solicitud enviada el lunes no significa un bot funcionando el lunes. Slack es el que puedes terminar tú mismo en una tarde.
Mantén el criterio en las personas. El bot devuelve lo que el equipo ha establecido; qué hacer con un caso que nadie documentó sigue siendo una decisión humana. Ese límite se traza en qué es realmente la memoria de IA.
Conclusión
Una base de conocimientos falla en el punto de uso, no en el de escritura. Las preguntas se hacen en el chat grupal porque ahí es donde están los colegas, y la documentación pide a las personas que salgan de esa ventana, busquen y armen una respuesta por sí mismas. Las plataformas de chat han cerrado parte de la brecha (las respuestas de IA de Slack funcionan bien sobre el contenido de Slack, en los planes que las incluyen, para el contenido al que cada persona puede acceder), pero el conocimiento que vive en documentos en lugar de mensajes queda fuera de ese alcance a menos que estés en el nivel que llega a fuentes externas.
Poner la base de conocimientos detrás de una @mención elimina el cambio de contexto y el paso de ensamblaje a la vez, y escribir cada intercambio de vuelta significa que el corpus crece a partir de preguntas reales en lugar de un sprint de documentación. La configuración es corta; las partes a planificar son administrativas. Decide quién puede aprobar una aplicación en Feishu o DingTalk, y qué proyecto te sientes cómodo haciendo legible para todos los que puedan comunicarse con el bot. Haz bien esas dos cosas y la wiki dejará de ser algo que se le pide a la gente que lea.