Cómo VibeBI funciona.

1 · Descripción general

VibeBI es una plataforma de analítica empresarial on-premise que convierte un almacén en bruto en un servicio de BI gobernado de autoservicio. Se construye sobre tres superficies de producto que comparten contratos pero mantienen las responsabilidades separadas:

• VibeBI Desktop — la superficie de usuario avanzado y administración: BI Agent (informes), DG Agent (gobernanza de datos), Explorer, Store y pantallas de certificación y acceso.
• VibeBI Web — una superficie de consumo ligera y de solo lectura para descubrir y abrir enlaces de informes gobernados.
• VibeBI Server — el plano de control on-prem sin interfaz: identidad, control de acceso, almacén de informes, programación, auditoría, broker del almacén y puerta de enlace LLM.

VibeBI se entrega con su propio motor de agentes embebido. El agente hace la mayor parte de la redacción; los stewards humanos y los custodios de TI aprueban y ejecutan a través de puertas de certificación — nunca son el cuello de botella.

2 · Arquitectura

La plataforma separa el runtime del agente (en el portátil del usuario) del plano de control (servidor on-prem). Las credenciales del almacén y del LLM nunca llegan a los dispositivos del usuario final.

flowchart LR
  subgraph client["User laptop"]
    DT["VibeBI Desktop"]
    SC["Agent sidecar :4580
VibeBI agent engine"]
    DT --> SC
  end
  subgraph server["On-prem server :8080"]
    AUTH["Auth / SSO"]
    BRK["Warehouse broker
read-only SQL"]
    GW["LLM gateway"]
    STORE["Report store
Postgres + object store"]
    ACL["Access control"]
  end
  CH[("Warehouse (EDW)
bronze · silver · gold")]
  WEB["VibeBI Web viewer"]
  SC --> AUTH
  SC --> BRK
  SC --> GW
  BRK --> CH
  DT --> STORE
  WEB --> AUTH
  WEB --> STORE
  STORE --> ACL
            

3 · The Alchemist (medallón)

El alcance de VibeBI empieza en bronce — posterior a la ingesta. Promueve los datos a través de un medallón gobernado: bronce → plata → oro + semántica. La única regla estricta: el oro nunca se construye directamente desde el bronce; primero deben existir vistas de plata certificadas.

flowchart LR
  B["Bronze
source-shaped landing
source__entity"] --> S["Silver
silver_<domain>
conformed views"]
  S --> G["Gold
gold_<domain>
facts & dims"]
  G --> SEM["Semantics
entities · grain · tags"]
  SEM --> CR["Create / Web
published gold only"]
            

La etapa 1 (Bronce → Plata) cubre perfilado, análisis de calidad de datos, conformación y propuestas de dominio/clasificación. La etapa 2 (Plata → Oro) cubre resolución de entidades, redacción de manifiestos y vistas de oro, validación y bucles de reparación. Los nombres físicos de las bases de datos son configuración de despliegue, no están fijos en los binarios.

4 · Capa semántica

La capa semántica es lo que hace duraderos los informes. En lugar de vincular dashboards a tablas físicas, VibeBI expone entidades, granularidades, mapeos, métricas certificadas y metadatos de modelos de oro mediante un solo contrato.

• Métricas certificadas — medidas aprobadas por el steward, con expresión, granularidad y vinculación al oro. Una definición, reutilizada en todas partes.
• Glosario de negocio — términos con alcance de empresa / equipo / personal, con definiciones y alias, inyectados en las sesiones del agente.
• Etiquetas de campo — cada campo expuesto lleva ≥ 1 dominio de datos y un nivel de clasificación.

Como los informes leen la capa semántica, un cambio de esquema aguas arriba se absorbe en el mapeo plata→oro — los informes posteriores siguen funcionando sin reescribirse.

# Agent discovery contract
GetSemantics      # entities, tables, grains, mappings, certified metrics
QueryVibeBIGold  # read-only SQL against published gold for real answers

5 · Aprendizaje BI de oro (bucle de autocrecimiento)

El oro no es una publicación de un solo disparo. VibeBI captura señales de demanda de cada turno del agente de BI — preguntas de usuarios, métricas dispersas o nulas de sondeos en vivo, errores de consulta, huecos de join y entidades que el asistente no pudo responder — y las convierte en mejoras revisadas por el steward sobre drivers de negocio, manifiestos y joins.

flowchart LR
  BI["BI Agent turns
chat + gold/silver probes"] --> SIG["Learning signals
catalog backlog"]
  SIG --> PROC["Process backlog
drivers · joins · hints"]
  PROC --> STW["Steward review
Gold → BI Learning tab"]
  STW --> GOLD["Approve drivers
publish manifests · build gold"]
  GOLD --> SEM["Updated semantics
fewer gaps next turn"]
  SEM --> BI
            

Los stewards conservan el control. Las propuestas crean bi_learning drivers de negocio en propuesto hasta su aprobación. Las reconstrucciones de manifiestos por métricas dispersas vuelven a borrador hasta su republicación. Los stewards pueden procesar paso a paso o ejecutar un pipeline completo (procesar → aprobar → publicar → construir oro) desde el escritorio.

El agente de BI recibe un huecos de aprendizaje en turnos posteriores (medidas dispersas, entidades no cubiertas, drivers pendientes) para que responda con honestidad en lugar de volver a sondear columnas nulas conocidas. El DG Agent usa el mismo backlog al regenerar drivers de negocio.

6 · Motor de agentes

VibeBI ejecuta un runtime de agente embebido, diseñado a propósito — no un chatbot general. Dos roles de agente impulsan el producto:

7 · Modelo de gobernanza

El control de acceso usa dos planos ortogonales, definidas por el cliente y aplicadas en cada campo, consulta, informe y compartir.

Plano A — Dominios de datos (tema de negocio)

Áreas temáticas de propiedad del negocio (Ingresos, Cadena de suministro, Compensación de RR. HH.), con subdominios opcionales. Cada dominio tiene un propietario quien aprueba las solicitudes de acceso — la parte responsable de negocio, no el constructor técnico de tablas.

Plano B — Niveles de sensibilidad

Roles (RACI)

• Propietario del dominio de datos — quién puede acceder a un dominio; aprueba solicitudes de acceso; cofirma publicaciones sensibles.
• Steward de datos — qué significa el dato: definiciones, granularidad, métricas, aprobación de manifiestos, certificación DQ y aprendizaje BI de oro (procesar señales de chat → aprobar drivers → publicar oro).
• Custodio de datos (TI) — cómo se ejecutan los pipelines: ejecución de DDL, rendimiento, copias de seguridad, break-glass.

8 · Acceso derivado a informes

Esta es la regla central de acceso, y no tiene elusión:

Las concesiones a nivel de informe (roles, enlaces compartidos) solo pueden restringir acceso — nunca ampliarlo más allá de las autorizaciones de datos subyacentes. Un modelo de oro construido a partir de varias tablas de plata hereda la unión de sus etiquetas de dominio, de modo que los propietarios de todos los dominios heredados se convierten en los aprobadores.

9 · Despliegue

El 100 % on-premise es nuestra ventaja — VibeBI se ejecuta por completo dentro de su red, con credenciales del almacén y claves del modelo que nunca la abandonan. El piloto es una instalación Docker Compose en una sola VM; la producción se endurece a un clúster HA sin rediseñar el producto.

On-premise es la opción predeterminada, no la única. La misma arquitectura se despliega en la nube de su elección — pública, privada, híbrida o multinube — para que pueda ubicar el plano de control y el almacén donde lo exija su estrategia de residencia de datos y de operaciones.

El servidor es intencionadamente ligero — un binario ligero que se ejecuta sin dificultad en hardware convencional. Todo el cómputo agéntico — perfilado, extracción semántica, generación de modelos, redacción de informes — se ejecuta distribuido en el cliente de escritorio de cada usuario, no en el servidor. El servidor solo gestiona gobernanza, intermediación y servicio, de modo que los requisitos de recursos del servidor se mantienen mínimos aunque crezca su base de usuarios.

Para clientes sensibles a los datos, VibeBI admite un despliegue totalmente aislado (air-gapped): 100 % on-premise, sin dependencia de internet, ejecutándose contra un LLM interno. Ningún dato, ninguna consulta y ningún metadato salen de su red. Todo el sistema — servidor, cliente de escritorio y LLM — opera como un bucle sellado dentro de su perímetro.

• Los agentes de creación se ejecutan en los portátiles de los usuarios (~100 creadores concurrentes).
• El visor web sirve a consumidores ocasionales en PC y móvil (~500 concurrentes).
• La producción entrega artefactos compilados — no hay código fuente en las imágenes de runtime, no hay source maps en producción.
• Los informes se almacenan como .report.ts + HTML generado, renderizado mediante API con ACL.

10 · Invariantes de seguridad

Cinco no negociables se mantienen en cada despliegue:

1. Las credenciales del almacén nunca en dispositivos cliente — todo el oro y la semántica fluyen a través del broker del servidor.
2. Las claves LLM nunca en dispositivos cliente — únicamente puerta de enlace del servidor o tokens emitidos de corta duración.
3. Los enlaces para compartir son URL de capacidad — id opaco + SSO/ACL + token de renderizado de corta duración, no rutas HTML estáticas.
4. El acceso a informes se deriva de las autorizaciones de datos — ningún permiso de informe independiente puede eludir las concesiones de dominio + clasificación.
5. La producción despliega artefactos compilados — no hay src/ en las imágenes de runtime.

11 · Stack tecnológico