Saltar al contenido

Referencia

Catálogo de módulos

Catálogo de módulos de Olivares AI: qué observa cada módulo y dónde la actuación está activa, bajo demanda o deny-closed.

Actualizado:

Olivares AI es una plataforma modular: un motor más un catálogo de módulos de capacidad más conectores. Un módulo consume eventos normalizados del núcleo, declara sus entidades en el modelo de datos compartido y expone su propia API y vistas — sin rearquitecturar el resto.

El binario de serie conecta 29 paquetes de módulo, organizados a continuación en áreas de capacidad numeradas (la tabla agrupa varios paquetes en una sola área, y unas pocas entradas son infraestructura de conexión fundacional o post-v1). Léelo como un catálogo, no como una lista de comprobación de funcionalidades: gobernar/observar es amplio y está activo en todo el parque; la actuación es la parte estrecha y gated — cada fila está marcada como live, aprovisionada bajo demanda (503 hasta que se configura) o como un cierre deny-closed (denegación por defecto). La plataforma es pre-1.0. Consulta Honestidad y límites para ver cómo expresamos lo que está y lo que no está construido.

Más allá del catálogo numerado hay un módulo de soporte de live-ingest (numerado XXIV en el código): la toma de eventos en vivo de la que leen los demás módulos. Es infraestructura de conexión más que una superficie autónoma, así que no se cuenta entre el catálogo numerado.

Cómo leer el estado de cada módulo

Cada módulo tiene dos mitades, y la distinción honesta entre ellas es justamente la clave:

  • Govern / Observe — catalogar, observar, comparar (diff), aplicar gates, reportar. Esto está construido y conectado hoy para los módulos marcados como activos a continuación. El producto es read-first y detective por defecto: vigila y gobierna fuera de banda, no se sitúa en la ruta de la solicitud.
  • Actuate — actuar sobre tu infraestructura real (deploy, disparar, despachar, enviar, forzar). Esto es deliberadamente estrecho y cae en tres estados:
    • live — conectado en el binario por defecto, sin aprovisionamiento requerido.
    • on-demand — el backend está construido y conectado a un punto de inyección pero permanece deny-closed hasta que un operador lo aprovisiona mediante config; hasta entonces una acción aprobada es honestamente “declarada, no actuada” (por ejemplo, el deploy apply/retire devuelve un 503 claro).
    • seam — una interfaz declarada, deny-closed, sin backend por defecto todavía.

La división es el contrato: el producto observa y gobierna ampliamente, y actúa sobre un subconjunto pequeño, en su mayoría gated por aprovisionamiento. Nada aquí reclama una ejecución que el código no realiza.

Descubrimiento y estado en vivo

#MóduloGovern/ObserveActuateQué hace
IInventario y descubrimientolive—Descubre y cataloga pasivamente agentes, sesiones, servidores MCP, herramientas, modelos, proveedores e identidades no humanas en todo el parque.
IIOperación en vivo y sesioneslive—Rastrea el estado en tiempo real de cada sesión de agente — acción actual, tokens/coste en vivo, una línea temporal reproducible — derivado de señales, nunca fabricado.
IIIMapa de acceso y recursos (R/RW)live—El diferenciador: qué agente lee (R) o lee-escribe (RW) qué recurso, y si ese acceso está permitido o meramente observado. Consulta el tour.
XXIISalud, SLA y uptimelive—Fiabilidad de los agentes y servidores MCP — sano, degradado o caído, y el mapa de dependencias — derivado de señales observadas, no sondeando tu infra.

Capacidades, identidad y gobernanza

#MóduloGovern/ObserveActuateQué hace
VMCP, skills y capacidadeslive—Gestión visual de servidores MCP, skills, plugins/subagentes y qué agente está conectado a qué herramienta. Consulta el tour de MCP.
VIIdentidad, permisos y gobernanzaliveon-demandGobierna quién y qué puede hacer qué, con aprobación HITL. Los actuadores de ciclo de vida de identidad con capacidad de escritura son opt-in y deny-closed hasta que se aprovisionan. Consulta el tour de identidad.
VIIIDatos, conocimiento y contextoliveliveEl plano de datos gobernado — bases de conocimiento y RAG con redacción antes de la indexación, recuperación gobernada, y trazabilidad sobre el plano de datos gobernado — los datos de gobernanza de Olivares permanecen en infraestructura que tú controlas; las peticiones a modelos alojados van a los proveedores que elijas. La recuperación léxica es la opción por defecto; los embeddings semánticos respaldados por modelo se conectan bajo demanda.
XIVCatálogo interno y marketplacelive—Cura y permite a la organización reutilizar agentes, servidores MCP, skills y plantillas aprobados y versionados; las solicitudes de instanciación se enrutan a través de la gobernanza.

Despliegue y la pila de modelos

#MóduloGovern/ObserveActuateQué hace
VIIDespliegue e integraciónliveon-demand (503)Planifica y gobierna despliegues/conexiones a la infraestructura — el único módulo que puede mutarla. Cada cambio es gated por HITL, plan-before-apply y queda registrado en el ledger. El ejecutor se conecta bajo demanda: apply/retire devuelven 503 hasta que se aprovisiona.
XGestión de modelos y proveedoresliverouting onlyGobierna y enruta a través de toda la pila de modelos — Claude, OpenAI, Gemini, inferencia local — con precios de referencia verificados por el operador. La resolución de rutas está en vivo; la propia llamada al modelo se ejecuta bajo demanda una vez que se aprovisiona una credencial de inferencia.

Los modelos alojados no son self-hostable. El módulo X puede enrutar a Claude (directamente o vía Bedrock/Vertex/Foundry), pero esa inferencia sigue llegando a la API del proveedor. Solo los modelos genuinamente self-hosted (vLLM/Ollama) se ejecutan completamente offline; el air-gap se aplica al control plane de Olivares, no a la inferencia alojada.

Coste, calidad y cumplimiento

#MóduloGovern/ObserveActuateQué hace
XICoste y AI FinOpsliveliveContabiliza el gasto en IA a partir del flujo de costes del proveedor y aplica presupuestos — al alcanzar el cap, un gate de presupuesto throttle/block deniega el gasto (deny-closed). Consulta el tour de FinOps.
XIICalidad, evals y testinglive—Puntúa salidas candidatas frente a suites golden versionadas con scorers deterministas más un LLM-judge, produciendo evidencia cross-module. Consulta el tour de evals.
XIIICumplimiento y regulatoriolive—Mapea lo que la plataforma ya observa y audita sobre frameworks (EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2, GDPR, OWASP Agentic) y emite evidencia consumible por auditores. Diseñado hacia ello, no certificado. Consulta el tour de cumplimiento.

Seguridad y aseguramiento

#MóduloGovern/ObserveActuateQué hace
IXSeguridad, guardrails y auditoríaliveliveEl plano defensivo: guardrails sobre el texto de entrada/salida/herramienta del agente (PII, secretos, prompt-injection, OWASP Agentic Top 10), detección de anomalías sobre la deriva observada, y líneas temporales de incidentes reconstruibles. Los hallazgos se emiten en vivo; la evidencia almacena un hash más un extracto redactado, nunca el payload en bruto.
XVIISandbox de testing de agentesliveon-demandEjecuciones aisladas y efímeras de escenarios de agentes frente a recursos mockeados, más replay determinista. El runner sintético in-process está en vivo; el runtime aislado a nivel de SO se conecta bajo demanda.
XVIIIRed-teaming y testing adversarialliveon-demandUn harness de robustez defensiva (prompt injection, jailbreak, exfiltración, tool poisoning) mapeado a OWASP Agentic y MITRE ATLAS. Las ejecuciones aisladas se conectan bajo demanda y reportan DEGRADED — nunca un falso pass — hasta que se aprovisiona un runtime de sandbox.

Coordinación, voz y salida

#MóduloGovern/ObserveActuateQué hace
IVComunicación inter-agente y orquestaciónliveon-demandDeriva el grafo de delegación/comunicación en vivo a partir de aristas observadas y gobierna agentes programados/autónomos. Disparar uno es de dos fases y gated por HITL; el dispatch en vivo es deny-closed hasta que se aprovisiona un dispatcher.
XVIntegraciones de salida y notificacionesliveliveEl router de notificaciones — decide qué señal va a quién, por qué canal; los conectores (Slack/Teams, PagerDuty/Opsgenie, webhook firmado, SIEM) entregan. El dispatch está en vivo; los destinos los aprovisiona el operador.
XVIVoz y agentes en tiempo realliveon-demandObserve-and-govern para agentes conversacionales/en tiempo real: gobierna quién puede abrir una sesión, con qué modelo, bajo qué política default-deny. La apertura es gated por HITL; la actuación sale a través de un dispatcher deny-closed hasta que se aprovisiona un proveedor de voz.

Plataforma y reporting

#MóduloGovern/ObserveActuateQué hace
XIXAPI propia y manage-as-codelive—Gestiona el propio control plane por API/IaC, más una superficie de eventing orientada al integrador (suscripciones durables, reintentos, dead-letter, replay). Fundacional.
XXMulti-tenancy y gestión de organizacioneslive—Jerarquía de organizaciones y administración delegada para MSPs y grandes organizaciones. Fundacional.
XXIDashboards ejecutivos y reportinglive—Vistas de alto nivel para la dirección junto a la consola técnica.
XXIIIGestión de modelos propios / fine-tuningpost-v1—Gobernar modelos entrenados o alojados por la empresa. Post-v1 — no conectado hoy.

Una nota transversal: el kill switch

Más allá de cualquier módulo individual, el kill switch del parque conecta un gate de parada en cada junta de actuación: deploy, disparo de orquestación, apertura de voz, ejecución de modelo y gasto de presupuesto. Una parada es enforcement positivo y es deny-closed — un estado de parada ilegible se trata como parado, nunca como un pass. Consulta el tour del kill switch.

Relacionado

Buscar documentación