Cuándo los equipos de ingeniería deben adoptar Dust en lugar de mantener pipelines RAG propios

Construir un prototipo de generación aumentada por recuperación (RAG) es sencillo: un proyecto de fin de semana con LangChain o LlamaIndex, un modelo de incrustación (embeddings) y una base de datos vectorial como pgvector o Pinecone puede responder preguntas a partir de una carpeta de archivos Markdown en cuestión de horas. Sin embargo, operar un sistema de recuperación de conocimiento interno a escala empresarial para toda una organización tecnológica y de negocio es un desafío completamente diferente.

Los equipos de ingeniería deben adoptar Dust cuando el objetivo principal es la habilitación interna y la recuperación de conocimiento operativo entre herramientas SaaS empresariales (Notion, Slack, Google Drive, Confluence y GitHub) sin tener que destinar ingenieros de plataforma a tiempo completo al mantenimiento de conectores, la sincronización de permisos y la fiabilidad de la infraestructura.

Por el contrario, los equipos deben mantener pipelines RAG internos personalizados cuando la recuperación constituye la propuesta comercial central del producto, requiere acuerdos de nivel de servicio (SLA) con latencias p99 inferiores a 100 milisegundos, exige algoritmos propietarios de búsqueda híbrida o embeddings multimodales a medida, o debe operar en entornos aislados (air-gapped) con prohibición estricta de llamadas a LLM en la nube.

La parte oculta del iceberg: La realidad del "Día 2" en RAG propio

La mayoría de los directores de ingeniería subestiman el coste total de propiedad (TCO) de los sistemas RAG propios porque el desarrollo inicial representa menos del 20% del esfuerzo total. El 80% restante consiste en fricción operativa continua.

1. Inestabilidad de conectores SaaS y fragilidad en la ingesta

Conectar con plataformas SaaS corporativas dista mucho de ser una simple llamada a una API:

• Límites de peticiones (rate limiting) y retroceso exponencial: Slack y Notion imponen límites estrictos al indexar espacios de trabajo voluminosos, lo que exige diseñar colas distribuidas resilientes y políticas complejas de reintentos.
• Ciclo de vida de webhooks: Los webhooks de terceros pierden eventos durante caídas de red, pasan por alto cambios de permisos en carpetas anidadas y sufren expiraciones periódicas de tokens OAuth.
• Procesamiento de formatos complejos: Analizar presentaciones de Google Slides, bases de datos anidadas de Notion, hojas de cálculo con múltiples pestañas y archivos PDF escaneados requiere actualizar constantemente librerías de extracción y reglas de fragmentación (chunking).

2. Herencia de permisos y riesgo de fuga de listas de control de acceso (ACL)

La seguridad en la recuperación de conocimiento interno no admite concesiones: un ingeniero de software no debe ver archivos salariales de la dirección, y un agente de soporte no debe acceder a datos personales identificables (PII) restringidos de clientes. En un pipeline propio, sincronizar los grupos del proveedor de identidad (IdP) con los permisos a nivel de documento de múltiples herramientas SaaS requiere construir un motor de sincronización a medida. Cada vez que cambian los permisos de una carpeta en Google Drive o Notion, los metadatos vectoriales deben actualizarse de inmediato. Si el filtrado de metadatos falla en el momento de la consulta, se produce una fuga de datos inmediata.

3. Latencia de reindexación y fragmentos huérfanos

Los documentos corporativos cambian a diario. En una base vectorial básica, actualizar una especificación técnica de 50 páginas requiere eliminar fragmentos obsoletos, insertar los nuevos y purgar fragmentos huérfanos. Si el índice vectorial pierde sincronización con el estado real del archivo, el modelo generará alucinaciones basadas en políticas obsoletas. Además, al actualizar el modelo de incrustación (por ejemplo, de text-embedding-ada-002 a text-embedding-3-large), todo el corpus debe recalcularse e indexarse sin interrumpir el servicio.

4. Evolución acelerada de modelos y enrutamiento

El ecosistema de LLM evoluciona mensualmente. Un pipeline mantenido internamente exige refactorizar continuamente el código de orquestación para aprovechar nuevas ventanas de contexto, modos JSON estructurados y parámetros de razonamiento entre OpenAI, Anthropic Claude, Google Gemini, Mistral y DeepSeek.

5. Desarrollo de interfaces de usuario multicanal

Los desarrolladores trabajan en Slack, terminales y GitHub; los equipos de ventas y operaciones dependen de navegadores web y gestores de tickets. Construir una solución propia obliga a programar y mantener bots de Slack, interfaces de chat web con Server-Sent Events (SSE), ventanas de citas bibliográficas y flujos de autenticación.

Desglose arquitectónico: Lo que Dust ofrece como plataforma gestionada

Dust está diseñado como un sistema operativo de agentes empresariales pensado para eliminar la carga de infraestructura en la recuperación de conocimiento.

Conectores y fuentes de datos gestionadas

Dust proporciona integraciones nativas y gestionadas con Slack, Notion, Google Drive, Confluence, GitHub, Zendesk, Intercom, Snowflake y BigQuery.

• Ciclo de vida automatizado: Los documentos ingeridos reciben un identificador único (document_id). Cada inserción es una operación Upsert: actualizar un documento reemplaza de forma automática sus fragmentos anteriores en el índice vectorial.
• Fragmentación y preprocesamiento: El sistema elimina espacios redundantes y divide los textos según límites definidos de tokens (max_chunk_size).
• Infraestructura de embeddings: Emplea por defecto text-embedding-3-large de OpenAI (con opción de modelos personalizados en planes Enterprise). Durante la consulta, Dust vectoriza la pregunta, busca fragmentos relevantes, los agrupa por documento y los clasifica en orden descendente de similitud.

Gobernanza mediante Spaces y permisos de doble capa

En lugar de intentar replicar frágiles árboles de permisos individuales para cada archivo, Dust aplica un modelo de gobernanza estructurado mediante Spaces (Espacios):

• Espacios abiertos (Open Spaces): Accesibles para todos los miembros del espacio de trabajo; ideales para manuales técnicos, guías de desarrollo y documentación global. Incluye el espacio inmutable Company Data.
• Espacios restringidos (Restricted Spaces): Limitados a miembros designados o grupos sincronizados mediante SCIM desde el IdP corporativo (Okta, Microsoft Entra ID).
• Control de acceso de doble capa:
  1. Agente a Datos: Los agentes solo pueden consultar las fuentes de datos vinculadas a su espacio configurado.
  2. Usuario a Agente: Los usuarios solo pueden ver, invocar y ejecutar agentes si pertenecen a los espacios asociados. Los datos confidenciales jamás se filtran en las respuestas a usuarios no autorizados.
• Cuentas de servicio dedicadas: Para Google Drive y Notion, Dust recomienda configurar cuentas de servicio administradas (como dust-admin@empresa.com), permitiendo al equipo de seguridad supervisar con precisión qué unidades compartidas y espacios de equipo se sincronizan.

Flexibilidad multimodelo y enrutamiento dinámico

Dust abstrae a los proveedores de LLM bajo una interfaz homogénea. Los equipos pueden asignar a sus agentes más de 20 modelos de frontera (OpenAI GPT-4o, Anthropic Claude 3.5 y 3.7 Sonnet, Google Gemini 1.5 y 2.0, Mistral Large, DeepSeek) sin tocar una línea de código. Los administradores pueden establecer niveles de acceso y límites de esfuerzo de razonamiento por grupo para controlar los costes.

Extensibilidad para desarrolladores: API REST y servidores MCP

Dust no es un entorno cerrado sin código:

• API para desarrolladores y OpenAPI 3.0: Ofrece endpoints para crear fuentes de datos, insertar documentos de texto o PDF, ejecutar llamadas a agentes y recibir eventos por streaming SSE.
• Compatibilidad con Model Context Protocol (MCP): Admite servidores MCP remotos y en cliente (preview), lo que permite a los agentes consultar microservicios internos, bases de datos operativas o canalizaciones de CI/CD de forma segura.
• Disparadores y agentes programados: Permite ejecutar flujos autónomos mediante tareas programadas (cron) o webhooks activados por sistemas externos.
• Transparencia de código abierto: El núcleo de Dust es de código abierto en GitHub (dust-tt/dust), lo que permite a los arquitectos auditar el funcionamiento interno y evitar el bloqueo por proveedor (vendor lock-in).

Comparativa directa: Pipeline RAG propio frente a Dust

Coste Total de Propiedad (TCO): La ecuación financiera

Al evaluar si construir o comprar, la dirección tecnológica debe contraponer la suscripción de software frente al salario cargado de los ingenieros y el coste de oportunidad.

Escenario: Empresa tecnológica de 150 empleados (50 ingenieros)

Coste de desarrollar y mantener un sistema propio

• Fase inicial de desarrollo (4 meses): Dos ingenieros sénior construyendo ingesta, indexación, suites de evaluación e integración con Slack. Coste laboral cargado (~150.000 $/año por ingeniero): aproximadamente 100.000 $.
• Mantenimiento continuo (anual): 0,75 ingenieros equivalentes a tiempo completo dedicados a resolver fallos de webhooks, actualizar embeddings y gestionar la base vectorial: 112.500 $/año.
• Infraestructura y consumo de LLM: Base vectorial gestionada (Pinecone/Qdrant Cloud), computación y llamadas a API de modelos: 15.000 $ a 25.000 $/año.
• Gasto total del primer año: ~227.500 $ a 237.500 $, con un gasto recurrente anual superior a 125.000 $.

Coste de adoptar Dust

• Plan Business autoservicio: Asientos Pro a 24 €/mes (facturación anual) para usuarios estándar y Max a 120 €/mes para creadores intensivos, con créditos de uso mensuales.
• Plan Enterprise: Precios por volumen con bolsa compartida de créditos, conectores y servidores MCP ilimitados, SCIM, SLA y residencia de datos en UE o EE. UU.
• Coste anual total: Representa una pequeña fracción del coste laboral de un único ingeniero sénior.
• Impacto en el producto: Dos ingenieros sénior permanecen enfocados al 100% en el desarrollo del producto comercial que genera ingresos directos.

Marco de decisión: Cuándo elegir cada alternativa

Adoptar Dust si:

1. El conocimiento está repartido en múltiples herramientas SaaS: Las especificaciones técnicas, actas y tiques residen en Slack, Notion, Google Drive, Confluence y GitHub.
2. Se busca que expertos de negocio creen sus propios agentes: Responsables de producto, soporte y operaciones pueden diseñar y probar agentes RAG con lenguaje natural y herramientas MCP sin abrir tiques de desarrollo.
3. El tiempo de ingeniería es crítico: El equipo no puede justificar cientos de horas depurando caídas de webhooks o migraciones de bases vectoriales.
4. Se requiere cumplimiento normativo inmediato: Se necesita certificación SOC 2, cumplimiento con RGPD, inicio de sesión único SAML y registros de auditoría desde el primer día.

Mantener un pipeline RAG propio si:

1. La búsqueda RAG es el producto comercial de la empresa: Si comercializas un software de descubrimiento legal, un buscador de diagnóstico médico o un analizador de repositorios de código donde los algoritmos de recuperación son tu ventaja competitiva.
2. Existen requisitos extremos de latencia (<100 ms): Se necesitan índices vectoriales en memoria dedicados, memorias intermedias acopladas o aceleración por hardware en servicios transaccionales críticos.
3. El entorno es estrictamente aislado (air-gapped): Normativas bancarias o de defensa prohíben la salida a servicios SaaS y LLM comerciales, requiriendo modelos locales autohospedados (vLLM/Ollama con Milvus local).
4. Volúmenes masivos de datos públicos con permisos homogéneos: Indexación de 50 millones de artículos de catálogo público donde el coste por asiento SaaS no encaja y la seguridad documental es idéntica para todos los usuarios.

Arquitectura híbrida: El enfoque pragmático

Los equipos de ingeniería más eficientes suelen adoptar una estrategia combinada:

• Conocimiento corporativo centralizado en Dust: Utilizan Dust para resolver el autoservicio de documentación interna, la incorporación de nuevos empleados y la colaboración entre departamentos sobre herramientas estándar.
• Sistemas internos conectados vía MCP: En lugar de desarrollar un pipeline RAG desde cero, los ingenieros programan servidores MCP ligeros o exponen APIs REST internas. Dust asume la autenticación, la interfaz de usuario, el enrutamiento de modelos y la búsqueda semántica, mientras el equipo técnico se limita a suministrar datos limpios de los servicios internos.

Delegar el trabajo no diferenciado de conectores y permisos en una plataforma gestionada permite a los ingenieros centrarse en lo que realmente genera valor para su negocio.

Referencias

• Dust Pricing: Business and Enterprise Plans for AI Agents
• Understanding Retrieval Augmented Generation (RAG) and the search method in Dust
• Chunks and Documents
• Datasources
• Access Controls and Permissions
• Spaces management
• Google Drive Connection
• Notion Connection
• The economics of multiplayer AI