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 catálogo enumera 23 módulos. Léelo como un catálogo, no como una lista de comprobación de funcionalidades: alrededor de veinte están cableados hoy, y el resto están en fase de diseño o son post-v1. 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): el grifo de eventos en vivo del que leen los demás módulos. Es fontanería más que una superficie autónoma, así que no se cuenta entre los 23.
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 cableado 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 — cableado en el binario por defecto, sin aprovisionamiento requerido.
- on-demand — el backend está construido y cableado 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/retiredevuelve un503claro). - 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ódulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| I | Inventario y descubrimiento | live | — | Descubre y cataloga pasivamente agentes, sesiones, servidores MCP, herramientas, modelos, proveedores e identidades no humanas en todo el parque. |
| II | Operación en vivo y sesiones | live | — | 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. |
| III | Mapa 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. |
| XXII | Salud, SLA y uptime | live | — | 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 gobierno
| # | Módulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| V | MCP, skills y capacidades | live | — | Gestión visual de servidores MCP, skills, plugins/subagentes y qué agente está cableado a qué herramienta. Consulta el tour de MCP. |
| VI | Identidad, permisos y gobierno | live | on-demand | Gobierna 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. |
| VIII | Datos, conocimiento y contexto | live | live | El plano de datos gobernado — bases de conocimiento y RAG con redacción antes de la indexación, recuperación gobernada, y trazabilidad de datos que demuestra que los datos nunca salieron del perímetro. La recuperación léxica es la opción por defecto; los embeddings semánticos respaldados por modelo se cablean bajo demanda. |
| XIV | Catálogo interno y marketplace | live | — | 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 del gobierno. |
Despliegue y la pila de modelos
| # | Módulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| VII | Despliegue e integración | live | on-demand (503) | Planifica y gobierna despliegues/cableados 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 cablea bajo demanda: apply/retire devuelven 503 hasta que se aprovisiona. |
| X | Gestión de modelos y proveedores | live | routing only | Gobierna 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ódulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| XI | Coste y AI FinOps | live | live | Contabiliza 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. |
| XII | Calidad, evals y testing | live | — | 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. |
| XIII | Cumplimiento y regulatorio | live | — | 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ódulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| IX | Seguridad, guardrails y auditoría | live | live | El 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. |
| XVII | Sandbox de testing de agentes | live | on-demand | Ejecuciones 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 cablea bajo demanda. |
| XVIII | Red-teaming y testing adversarial | live | on-demand | Un harness de robustez defensiva (prompt injection, jailbreak, exfiltración, tool poisoning) mapeado a OWASP Agentic y MITRE ATLAS. Las ejecuciones aisladas se cablean bajo demanda y reportan DEGRADED — nunca un falso pass — hasta que se aprovisiona un runtime de sandbox. |
Coordinación, voz y salida
| # | Módulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| IV | Comunicación inter-agente y orquestación | live | on-demand | Deriva 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. |
| XV | Integraciones de salida y notificaciones | live | live | El 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. |
| XVI | Voz y agentes en tiempo real | live | on-demand | Observe-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ódulo | Govern/Observe | Actuate | Qué hace |
|---|---|---|---|---|
| XIX | API propia y manage-as-code | live | — | Gestiona el propio control plane por API/IaC, más una superficie de eventing orientada al integrador (suscripciones durables, reintentos, dead-letter, replay). Fundacional. |
| XX | Multi-tenancy y gestión de organizaciones | live | — | Jerarquía de organizaciones y administración delegada para MSPs y grandes organizaciones. Fundacional. |
| XXI | Dashboards ejecutivos y reporting | live | — | Vistas de alto nivel para la dirección junto a la consola técnica. |
| XXIII | Gestión de modelos propios / fine-tuning | post-v1 | — | Gobernar modelos entrenados o alojados por la empresa. Post-v1 — no cableado hoy. |
Una nota transversal: el kill switch
Más allá de cualquier módulo individual, el kill switch del parque cablea 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
- ¿Qué es Olivares AI? — el producto en una página.
- Permitido vs observado y fidelidad — cómo los módulos I–III se mantienen honestos sobre lo que pueden demostrar.
- Honestidad y límites — la postura completa de live-vs-roadmap.
- Arquitectura — cómo se componen el motor, las capas y los conectores.