Catálogo de módulos
Olivares AI integra, gestiona y asegura la IA en la empresa, un único ground truth: Claude Code al nivel más profundo, Codex y Grok Build a su lado. Es una plataforma modular — un motor, una consola y 35 módulos seleccionables en el catálogo — que observa dónde se ejecutan los agentes, gobierna lo que se les permite hacer y (sobre un subconjunto creciente) actúa sobre tu infraestructura real. Cada módulo (a) consume eventos/datos normalizados del núcleo, (b) declara sus entidades en el modelo de datos compartido y (c) expone sus propios endpoints de API y vistas de UI — sin tocar el núcleo ni otros módulos.
Estos 35 módulos seleccionables se implementan en 32 paquetes de módulos;
el paquete governance proporciona cuatro módulos seleccionables por separado. Se organizan por las nueve áreas de capacidad de abajo. Lee el
estado de cada módulo como dos mitades: Gobernar/Observar (catalogar,
observar, restringir, informar) está construido y cableado hoy; Actuar (actuar
sobre infraestructura real — desplegar, despachar, enviar, aplicar, ejecutar) cae
en estados honestos — live en el binario por defecto para un subconjunto,
on-demand para varios (el backend está construido y cableado a un punto de
inyección pero permanece deny-closed o degradado hasta que un operador lo
aprovisiona vía configuración de entorno), PARTIAL donde la superficie está
restringida/opt-in, y un seam deny-closed declarado para el resto. En
particular, deploy planifica y gobierna despliegues pero no los aplica a
la infraestructura en vivo hasta que se aprovisiona un executor: apply/retire
devuelven un 503 claro. Deploy es una función Business; Community responde 501 en cada ruta de deploy. La profundidad varía según el módulo, y buena parte del
producto está pre-1.0 / en fase de diseño donde así se indica (consulta
Honestidad y límites).
El access map (iii-access-map) — el grafo de lectura/lectura-escritura de lo
que cada agente puede tocar y de hecho toca, con la desviación de mínimo
privilegio = Permitted ≠ Observed — es una de las capacidades más útiles entre
las 35, no el producto entero. La amplitud es lo que importa: nueve áreas, un
motor, una consola.
Los 35 módulos seleccionables, por área de capacidad
Sección titulada «Los 35 módulos seleccionables, por área de capacidad»Cada fila enlaza a su página de módulo (/reference/modules/<slug>/). La columna
Actuar es el estado honesto de la mitad que actúa; — significa que el módulo
gobierna/observa por naturaleza y no tiene superficie de actuación.
Observar
Sección titulada «Observar»| Módulo | Actuar | Propósito |
|---|---|---|
| Inventario y descubrimiento | — | Descubre y cataloga los agentes, sesiones, servidores MCP, herramientas, modelos e identidades que los conectores observaron. |
| Operación en vivo y sesiones | — | Estado en tiempo real de cada agente y sesión; también aloja el runtime gobernado de sesiones de Claude Code. |
| Mapa de acceso y recursos (R/RW) | — | A qué accede cada agente, y si lee o escribe; desviación de mínimo privilegio = Permitted ≠ Observed. |
| Orquestación y A2A | on-demand | Observa-y-gobierna el grafo en vivo de delegación/comunicación; el despacho está cableado on-demand, deny-closed hasta aprovisionarse. |
| MCP, skills y capacidades | — | Gobierna las herramientas y capacidades de los agentes, visualmente. |
| Salud, SLA y uptime | — | Fiabilidad de los agentes y servidores MCP del estate; comprobaciones, incidentes, mapa de dependencias. |
| Modelo de lectura de observabilidad | — | El modelo de lectura que el motor tiene de sí mismo: estándares de interoperabilidad fijados, vista de ledger/traza correlacionada con W3C, atestación de la cadena de suministro. |
| Adopción de Claude Code | — | Modelo de lectura de la adopción/productividad de Claude Code: sesiones, líneas de código, commits, PRs, accept-reject de herramientas, tokens por modelo, por equipo/desarrollador/día; por equipo por defecto, drill-down por desarrollador opt-in. Frontera solo-API-de-Claude; nunca lleva coste. |
| Live-ingest | PARTIAL | Productor in-process de eventos detective que un conector no puede emitir; restringido por entorno, deny-closed, datos mínimos. |
Gobernar y aplicar
Sección titulada «Gobernar y aplicar»| Módulo | Actuar | Propósito |
|---|---|---|
| Identidad, permisos y gobernanza | — | Quién y qué puede hacer qué, granular: Cedar RBAC + deny-overlay + grants acotados, reconciliación del roster, admin acotado/roles personalizados, break-glass, kill-switch. |
Identidad (identity) |
— | Postura de solo lectura de federación de identidad de cargas de trabajo, SSO, claves externas y residencia. |
| Acotamiento de fuentes y credenciales | — | Vincula fuentes a un workspace/grupo-de-agentes; resolver acotado deny-closed + credenciales acotadas en el momento de la resolución. |
| Despliegue e integración | Business, on-demand (503) | Función Business: Community responde 501. Planifica y gobierna despliegues a infraestructura real; el executor es on-demand — apply/retire en vivo devuelven 503 hasta aprovisionarse. |
| Publicación Git gobernada | on-demand | Envía commits, abre solicitudes de incorporación y fusiona mediante vínculos aprobados del host Git, con autorización vigente y resultados registrados. |
Identity es un módulo seleccionable por separado para la consola de postura de identidad de solo lectura. Comparte el paquete governance y requiere gobernanza, que posee el modelo de autorización y el ciclo de vida de identidad. Compartir paquete no implica compartir el interruptor del módulo.
Ecosistema de Claude y agentes
Sección titulada «Ecosistema de Claude y agentes»| Módulo | Actuar | Propósito |
|---|---|---|
Política gestionada de Claude Code (claude-policy) |
— | Valida y previsualiza políticas gestionadas; Business las publica en toda la flota e inspecciona su distribución y la deriva observada. |
Confirmaciones de agentes Claude (claude-agents) |
— | Lee los eventos de hilos de agentes gestionados y aprueba o rechaza una confirmación de herramienta pendiente. |
| Gestión de modelos y proveedores | on-demand (503) | Gobierna toda la pila de modelos/proveedores: acceso a modelos, ventana de contexto por superficie, gate de grupo de modelos; la ejecución de modelos es on-demand — 503 hasta aprovisionar una credencial de inferencia. |
| Proxy de inferencia inline | PARTIAL | Configuración de egress de inferencia por tenant + DLP para el proxy PEP inline /v1/messages; la configuración del módulo está live, el listener es opt-in, loopback por defecto, fail-CLOSED. |
| Catálogo y marketplace internos | — | Marketplace curado de agentes, servidores MCP y skills aprobados/firmados. |
| Catálogo y asignaciones de skills | — | Catálogo inmutable de skills y asignaciones fijadas: packs validados por digest instalados bajo /v1/m/skills/packs, fijados por objetivo, nunca editados en sitio. |
| Agentes de voz y tiempo real | on-demand | Observa-y-gobierna agentes conversacionales/de tiempo real (default-DENY, HITL en dos fases); nunca abre un flujo de medios; despacho on-demand. |
Seguridad y protección de datos
Sección titulada «Seguridad y protección de datos»| Módulo | Actuar | Propósito |
|---|---|---|
| Seguridad, guardrails y auditoría | live | Guardrails (PII/inyección/jailbreak), anomalías, cronologías de incidentes; BYOK/DLP/RTBF/retención/WORM/residencia viven en este plano. |
| Grabación de sesiones privilegiadas | live | Grabación alineada con PAM de sesiones privilegiadas: frames hash-chained, expurgo en escritura, anclados al ledger. |
| Datos, conocimiento y contexto | on-demand | Plano de datos gobernado: KBs + RAG, recuperación gobernada, linaje, registro de prompts, memoria de agentes; los embeddings semánticos respaldados por modelo son on-demand. |
Cumplimiento y evidencia
Sección titulada «Cumplimiento y evidencia»| Módulo | Actuar | Propósito |
|---|---|---|
| Cumplimiento y regulatorio | — | 26 catálogos de marcos + evidencia sellada y derivada del ledger con verificación de cadena en vivo. |
| Forwarder SIEM/ITSM | live | Envía el ledger sellado + los findings a torres SIEM (OCSF 1.8/CEF/LEEF/syslog/OTLP), recorrido de cursor con gate de líder, at-least-once. |
| Exportación de postura | PARTIAL | Pull de postura/inventario de solo lectura para torres de control (JSON neutral); no afirma un push downstream verificado. |
| Reporting | — | Generación profesional de informes PDF/HTML a partir de los datos de compliance, auditoría y FinOps de la plataforma — cinco tipos integrados; un auditor descarga un documento en vez de copiar y pegar JSON. |
| Módulo | Actuar | Propósito |
|---|---|---|
| Coste y FinOps de IA | live | Presupuestos que actúan denegando/limitando en el tope, coste-por-resultado, riesgo de cancelación; presupuesto firme a la identidad. |
Evals y seguridad
Sección titulada «Evals y seguridad»| Módulo | Actuar | Propósito |
|---|---|---|
| Calidad, evals y testing | — | LLM-judge calibrado + un gate de regresión bloqueante en CI; juez offline → SKIPPED, nunca un pase silencioso. |
| Sandbox de agentes | on-demand | Entorno seguro para probar agentes antes de producción; el aislamiento de SO real (gVisor/Firecracker) es on-demand. |
| Red-teaming y pruebas adversariales | on-demand | Batería adversarial restringida por consentimiento; DEGRADED — nunca un falso pase — hasta aprovisionar un runtime de sandbox. |
Plataforma e integraciones
Sección titulada «Plataforma e integraciones»| Módulo | Actuar | Propósito |
|---|---|---|
| Integraciones de salida y notificaciones | live | Router de notificaciones a los sistemas que la empresa ya opera; el despacho está cableado live, los destinos aprovisionados por el operador. |
| Eventing | live | Superficie de suscripción externa sobre el bus: suscripciones tipadas, entrega durable at-least-once, retry/backoff, DLQ, replay de cursor. |
| Vistas guardadas de la consola | — | Instantáneas con nombre y compartibles del estado de las vistas de la consola (filtros, rangos), almacenadas server-side por tenant: guarda una investigación, compártela con el equipo. Acepta un objeto JSON con tope de 4096 bytes pensado para parámetros de vista — no guardes en él datos sensibles ni resultados de consultas. Crear/actualizar son solo del propietario; los administradores/propietarios del tenant y los superadmins pueden borrar para limpieza; toda mutación queda auditada. |
Columna Actuar: live = la actuación está cableada y live en el binario por
defecto, sin aprovisionamiento requerido (p. ej. la aplicación de presupuesto de
FinOps deniega en el tope, el router de notificaciones despacha); on-demand /
on-demand (503) = el backend está construido y cableado a un punto de inyección
pero permanece deny-closed o degradado hasta que un operador lo aprovisiona vía
configuración de entorno (deploy, una función Business, responde 501 en Community y 503 hasta que existe un executor; el
despacho de orquestación/voz es deny-closed hasta configurarse; red-team corre
DEGRADED hasta aprovisionar un runtime de sandbox; la ejecución de modelos y los
embeddings semánticos devuelven 503 hasta aprovisionar una credencial);
PARTIAL = la superficie es real pero está restringida/opt-in o no afirma un
downstream verificado (el listener del inference-proxy es opt-in y loopback por
defecto; live-ingest está restringido por entorno; posture-export es una proyección
neutral de solo lectura); — = el módulo gobierna/observa por naturaleza y no
tiene superficie de actuación. Esta división es el contrato honesto: el producto
observa y gobierna ampliamente hoy, y actúa sobre un subconjunto creciente, en
su mayoría restringido por aprovisionamiento — consulta
Honestidad y límites. El catálogo seleccionable procede de
core/modulespec/modules.json, la misma fuente que usan olivares modules ls
y la lista Edición y módulos de la consola. npm run test:modules comprueba
que cada namespace seleccionable enlaza una página de referencia y verifica
el recuento.
Costura de disponibilidad de edición (no contada entre los 35 módulos seleccionables)
Sección titulada «Costura de disponibilidad de edición (no contada entre los 35 módulos seleccionables)»El catálogo de arriba cubre los 35 módulos seleccionables de la
especificación compartida de módulos. Por separado, Community registra un
descriptor de disponibilidad bajo el espacio de nombres API session-cockpit.
No es uno de esos 35.
- Cockpit de sesiones (disponibilidad) —
cero manejadores en Community;
/v1/m/session-cockpitdevuelve 404 por ausencia. No hay cockpit interactivo en este artefacto. Las sesiones en vivo, AgentOps y el ciclo de vida de las CLI oficiales siguen en el producto abierto — Operación en vivo y sesiones y Ejecutar Claude Code con Olivares.
Capacidades de plataforma y núcleo (no contadas entre los 35 módulos seleccionables)
Sección titulada «Capacidades de plataforma y núcleo (no contadas entre los 35 módulos seleccionables)»Estas son capacidades reales, entregadas, pero son capacidades de motor/núcleo/web, no módulos seleccionables por separado — así que no se cuentan entre los 35:
- API propia + manage-as-code — Capacidad de motor/núcleo. La propia API REST/gRPC versionada del motor más el provider de Terraform; gestiona la plataforma misma por API e IaC.
- Multi-tenancy y gestión de org — Capacidad de motor/núcleo. Jerarquía de org y admin delegado, con aislamiento de tenant por row-level-security de Postgres.
- Dashboards ejecutivos — Capacidad web. Vistas de consola para dirección junto a la UI técnica. (Su backend de generación de informes es el módulo reporting, que SÍ se cuenta entre los 35.)
- Operaciones de modelos (modelos propios) — Capacidad del módulo de modelos (se cuenta a través de la fila del módulo X, no como fila aparte): el registro gobernado de modelos propios, la admisión de modelos firmados, los registros de linaje de datasets/trabajos de fine-tuning, la gobernanza de despliegues de inferencia local y la evidencia AIBOM/model card.
Planificado: la ejecución de fine-tuning de modelos propios y de inferencia local (xxiii-fine-tuning) — la plataforma gobierna y registra ese trabajo hoy (ver operaciones de modelos arriba) pero no ejecuta entrenamiento ni sirve inferencia por sí misma; la mitad ejecutora es trabajo planificado documentado, no entregado y no uno de los 35.
Cómo aparecen los módulos en la API y en el bus
Sección titulada «Cómo aparecen los módulos en la API y en el bus»- REST. La referencia de API renderiza la superficie REST del núcleo a partir del contrato OpenAPI 3.1 del producto. Algunas rutas de módulo son alcanzables pero deliberadamente no están en ese documento; sus contratos a nivel de campo viven en las interfaces tipadas del producto.
- Eventos. Los módulos reaccionan al bus de eventos: el
access map consume
edge.observed, FinOps consumecost.sampled, y seguridad consumefinding.reportedyguardrail.observed.
Los 35 módulos seleccionables se construyen sobre capas por encima del motor, junto a las capacidades de motor/núcleo y web de arriba:
- Motor (capa 0) — las capacidades de API-propia/manage-as-code y multi-tenancy (núcleo, no contadas en los 35).
- Núcleo (capa 1) — inventory, sessions, access-map, models, health, observability.
- Gestión (capa 2) — capabilities, governance, identity, claude-policy, claude-agents, skills, sourcescope, deploy, gitpublish, knowledge.
- Inteligencia (capa 3) — orchestration, security, recording, inference proxy, finops, evals, compliance, reporting, siemforward, posture-export, catalog, notify, eventing, voice, sandbox, redteam, live-ingest, consoleviews.
- Web (capa 4) — la UI y la capacidad de dashboards ejecutivos.
Consulta la vista general de arquitectura para ver cómo se componen el motor y estas capas.