Saltar al contenido
Condictor Studio
IA
IA

Second brain para una empresa: por dónde empezar

Cómo convertir conocimiento disperso de empresa en un sistema que responde con fuente: elegir un área, ordenar fuentes, pilotar y medir calidad.

Aprox. 7 min de lecturapor
Fragmentos de documentos, minerales y vidrio envían fibras verde menta y cobre a través de un índice coral hacia un archivo de conocimiento por capas

Un second brain para una empresa es un sistema en el que el conocimiento disperso —documentos, procedimientos, contratos e hilos de correo— pasa a poder buscarse con IA, y las respuestas se basan en tus datos e indican la fuente. No se empieza eligiendo una herramienta, sino eligiendo un área de conocimiento que más duele.

«RAG» y «knowledge graph» son tecnología, es decir, responden a «cómo funciona». El «segundo cerebro de empresa» es una promesa: responde a «qué gano con ello». Esta entrada trata de lo segundo.

Paso 1. Elige un área, no el conjunto completo

El proyecto «indexemos todo» crece fácilmente sin un criterio claro de finalización. Un objetivo más estrecho, por ejemplo «respondamos preguntas sobre las condiciones de garantía», permite construir antes una prueba de calidad; el plazo sigue dependiendo del número de fuentes, permisos y estado de la documentación.

Tres criterios para elegir el área:

CriterioPor qué
Las preguntas vuelven con frecuencia o un solo error es costosola frecuencia favorece el retorno, pero un caso menos habitual puede justificar la implantación por el nivel de riesgo
Las respuestas tienen una fuente fiable y accesiblesin fuente no hay base para responder ni forma de actualizar
Se puede evaluar la correcciónsin ello no medirás la calidad

Un buen primer área suelen ser procedimientos e instrucciones internos, condiciones de contratos y garantías, documentación técnica de producto o una base de solicitudes resueltas, siempre que se pueda indicar al propietario de las fuentes y evaluar la respuesta.

Paso 2. Haz un inventario de fuentes y decide qué es verdad

Esta etapa puede ocupar una parte considerable del proyecto. No se trata de copiar archivos, sino de decidir:

  • ¿Qué versión está vigente? Tres variantes del mismo procedimiento en tres carpetas pueden llevar a respuestas contradictorias. El sistema debe detectar o revelar el conflicto y dirigirlo a una decisión, en vez de escoger una versión sin base.
  • ¿Qué está desactualizado? Un documento del año pasado que nadie retiró formalmente puede ser para el sistema igual de fiable que el actual.
  • ¿Qué no dejamos entrar? Notas de trabajo, versiones intermedias y correspondencia con acuerdos individuales.
  • ¿Quién puede ver qué? Los permisos deben reproducirse en el sistema para que el asistente no revele información a alguien sin acceso adecuado. Lo desarrollamos en seguridad de datos al implantar IA.

Hablando con franqueza: ordenar las fuentes puede ocupar una parte importante del proyecto. El sistema no arreglará el desorden; puede, en cambio, presentar una información desactualizada de forma convincente si recibe esos materiales como entrada.

Paso 3. Reúne las preguntas que debe responder el sistema

Antes de construir nada, pedimos una lista de preguntas reales con respuestas esperadas. Para un piloto suelen bastar 30–50 casos bien elegidos, aunque el número debe adaptarse a la variedad de temas y al riesgo de error. Esa lista es al mismo tiempo:

  • una especificación (muestra qué debe saber hacer el sistema);
  • un conjunto de evaluación (medimos la calidad después de cada cambio);
  • una prueba de viabilidad (si para la mitad de las preguntas no hay respuesta en los documentos, lo sabemos antes de construir, no después).

El conjunto debe incluir preguntas para las que la respuesta correcta es «no lo sé». Comprueban si el sistema sabe negarse sin base; deben equilibrarse con preguntas respondibles para no optimizar la solución solo para la negativa.

Paso 4. Un piloto, no producción inmediata

Un piloto sobre el área elegida incluye indexación, búsqueda, respuesta con referencia a la fuente e interfaz sencilla. Según nuestra tarifa de agosto de 2026, tarda aproximadamente 3–5 semanas y cuesta 12.000–30.000 PLN netos.

Un piloto que incluya preguntas representativas y uso real permite medir tres cosas que no pueden predecirse de forma fiable en una presentación:

  1. Cuál es la calidad de las respuestas con tus datos. No puede deducirse de forma fiable solo de una demostración del modelo; debe medirse con preguntas del proceso.
  2. Si el equipo lo usa y cómo. Hay que distinguir la falta de necesidad de un problema de acceso, interfaz o adopción de usuarios.
  3. Cuál es el coste recurrente aproximado con el número y longitud observados de preguntas; el coste total de producción también depende de supervisión, integraciones y tiempo de respuesta exigido.
Camino desde un montón de documentos dispersos, a través de un filtro que aparta versiones desactualizadas, hasta un índice ordenado desde el que una pregunta vuelve como respuesta con el fragmento fuente señalado
Desde fuentes dispersas hasta una respuesta con su fuente: el tramo más largo está antes del índice.

Paso 5. Decide si necesitas un grafo

La búsqueda de fragmentos (RAG) resuelve bien preguntas como «¿dónde está escrito esto?». Puede no bastar para preguntas que exigen recorrer de forma fiable varias relaciones, por ejemplo: «¿qué contratos con este subcontratista vencen antes de la auditoría?».

Si esas preguntas son importantes, una solución es un knowledge graph, más costoso y que requiere un modelo de dominio. La alternativa puede ser una consulta directa a una base bien estructurada. Recomendación: empieza por la solución más simple, mide en qué preguntas falla el sistema y añade un grafo solo donde las relaciones mejoren realmente el resultado. El orden inverso es construir por intuición.

Paso 6. Planifica el mantenimiento desde el primer día

El conocimiento cambia. Un documento añadido a una carpeta debe entrar en el índice, y uno retirado debe desaparecer de él según una política de actualización acordada. De otro modo aumenta el riesgo de respuestas que parecen fiables, pero se apoyan en una versión antigua; sin pruebas y marcado de fuentes, el problema puede permanecer invisible durante mucho tiempo.

El alcance mínimo de mantenimiento suele incluir actualización automática del índice, registro de lo que entró y salió, ejecución periódica del conjunto de evaluación y una persona propietaria del conocimiento por parte del cliente que resuelva casos dudosos.

Cuándo no funciona un second brain

  • Cuando el conocimiento no tiene una fuente fiable y accesible. Puede ser texto, tabla, grabación tras transcripción o material tratado multimodalmente, pero debe poder obtenerse, controlarse y actualizarse. El sistema no sustituye conocimiento que existe solo en cabezas humanas.
  • Cuando las preguntas se refieren a números y agregaciones. «¿Cuántos clientes se fueron en junio?» exige una consulta controlada de datos, no solo búsqueda semántica. Diseñamos estos casos dentro de datos y analítica.
  • Cuando el conjunto es pequeño y cabe con seguridad en el contexto. Proporcionar al modelo el conjunto verificado puede ser más simple que construir un pipeline, si coste, permisos y límites de contexto lo permiten.
  • Cuando nadie quiere ordenar las fuentes. Sin decidir las versiones vigentes, los permisos y un propietario del conocimiento, es difícil mantener respuestas con seguridad.

Cuánto cuesta

Nuestros rangos de agosto de 2026: piloto, 12.000–30.000 PLN netos; sistema de producción con integraciones, 30.000–120.000 PLN netos. El mantenimiento se presupuesta por separado según frecuencia de actualización, alcance de observabilidad y tiempo de respuesta. A ello se añaden tarifas de modelos e infraestructura; dependen, entre otras cosas, del número de consultas, longitud de contexto, modelo elegido y uso de caché.

Preguntas frecuentes

¿Nuestros documentos servirán para entrenar el modelo?

No necesariamente; depende del proveedor, producto y condiciones contractuales elegidos. En una arquitectura RAG típica los documentos permanecen en el repositorio indicado y al modelo solo llegan los fragmentos necesarios para responder. Aun así, hay que comprobar retención, ubicación de tratamiento, reglas de uso de datos y acceso de subencargados, y dejar estas condiciones por escrito en el contrato.

¿Se puede conectar con las herramientas que ya utilizamos?

Normalmente sí, si la herramienta expone API, webhooks u otra forma de integración segura. La interfaz puede ser un chat, un buscador en la intranet o un mensajero. La forma final depende de restricciones técnicas, permisos y forma de trabajo del equipo.

¿En qué se diferencia de una búsqueda normal en archivos?

Un buscador clásico devuelve documentos o fragmentos. Un second brain puede componer una respuesta a una pregunta en lenguaje natural e indicar las fuentes utilizadas; la calidad de esa síntesis sigue requiriendo evaluación.


También construimos grafos de conocimiento y pipelines RAG para nosotros mismos: los mostramos en el laboratorio, porque son nuestras propias herramientas, no implantaciones ajenas de una presentación. Consulta second brain para empresas o descríbenos qué buscas con más frecuencia.

Maciej Szukalski

Autor

Maciej Szukalski

Fundador de Condictor · arquitecto de sistemas · investigación y desarrollo

Diseña y desarrolla productos digitales desde 2014. Se especializa en arquitectura, investigación y aplicaciones con capas de automatización e inteligencia.

¿Tienes un problema que resolver?

Veamos cuál es el mejor primer paso

Describe tu situación en unas frases. Volveremos con preguntas o una propuesta concreta para el siguiente paso.

Describe tu tema

Ver también

Todos los artículos