Honestidad y límites

Una plataforma que gobierna los agentes de IA de tu infraestructura es un producto de seguridad. Si exagera lo que cubre, da una falsa sensación de seguridad — que es peor que no tener ninguna herramienta. Por eso esta página es el contrato explícito: qué funciona hoy, qué está en fase de diseño y qué queda fuera del alcance a propósito. El resto de la documentación se atiene a ello. Donde el producto aún no cubre algo, la página lo dice en lugar de dar a entender que sí.

Olivares AI es previo a 1.0 y open-core. Trata la profundidad a nivel de módulo como trabajo en curso salvo que una página indique lo contrario.

Qué funciona hoy

• Un único binario arranca hasta un grafo de acceso poblado. El binario del control plane se compila a un solo artefacto estático con la interfaz web integrada. Arrancarlo contra el estate sintético de demostración y recorrer discover → grafo R/RW → drift permitido-vs-observado → inventario lo ejercita de extremo a extremo la suite de tests. El quickstart reproduce ese recorrido.
• El primer arranque es sin credenciales. Una instalación nueva no tiene credenciales por defecto. En el primer arranque, sin usuarios todavía, el motor genera un token de configuración de un solo uso y lo imprime en stdout (nunca en los logs); lo canjeas para crear el primer administrador.
• La API REST y el ledger de auditoría son reales. La superficie pública la describe el propio contrato OpenAPI 3.1 del producto. El ledger de auditoría es append-only y encadenado por hash, con checkpoints firmados, y puede exportarse a formatos SIEM para reverificación offline.
• Las releases están firmadas y son verificables offline. Cada release lleva firmas cosign, procedencia SLSA y SBOMs (SPDX y CycloneDX). Todo ello puede verificarse sin acceso a red. Se admite la firma basada en clave (no OIDC) para pipelines de build air-gapped, y se distribuye un bundle air-gap para instalaciones sin salida a red.

Qué está en fase de diseño o es previo a 1.0

El catálogo son 23 módulos; aproximadamente 20 están cableados en una instalación estándar hoy. Aquí nada afirma que los 23 estén plenamente operativos. Consulta la referencia de módulos para el estado por módulo.

La fidelidad del mapa R/RW es escalonada, por diseño

La fidelidad depende de lo que la fuente pueda demostrar, y el mapa de acceso lo muestra con honestidad en lugar de fingir certeza. Consulta fidelidad para el modelo completo.

• La cobertura es clean en stores con auditoría nativa (SQL, almacenamiento de objetos, warehouses/lakes), lossy en document y vector stores donde las aristas existen pero son toscas, y opaque donde no hay ninguna señal pasiva de lectura/escritura (por ejemplo Redis, SQLite, D1). Donde no se puede determinar lectura frente a escritura, la arista se marca como unknown.
• La atribución es firm cuando una fuente lleva identidad por agente, y colapsa a approximate cuando una cuenta de servicio compartida la oculta. Cualquier cosa sin resolver permanece como approximate — nunca se promociona silenciosamente a un agente fabricado.

Fuentes: observadores de host cableados; algunos conectores se cargan bajo demanda

El composition root registra los observadores R/RW a nivel de host en la ruta serve estándar, configurables mediante la configuración de fuentes. Varios conectores de fuente están construidos pero aún no cableados en el serve estándar — por ejemplo las fuentes de documentos de conocimiento, que se cargan bajo demanda mediante peticiones de ingesta en lugar de ejecutarse como observadores permanentes. La guía de conectar una fuente y la referencia de módulos marcan cuál es cuál.

El valor por defecto es un único binario; el bus distribuido es opcional

La instalación por defecto se ejecuta como un único binario con un event bus in-process — backpressure bloqueante, sin pérdida local. Hay un bridge NATS distribuido, construido y cableado para escalado horizontal en HA, opcional mediante la configuración del bus; un bus mal configurado hace fallar el arranque en lugar de particionar silenciosamente. La entrega entre nodos a través del bridge está documentada con honestidad como at-most-once (la captura in-process es la frontera de durabilidad); las pérdidas se contabilizan en las métricas, nunca son silenciosas.

La actuación gobernada tiene tres estados honestos

La plataforma observa y gobierna ampliamente; no actúa ampliamente. Lee permitido vs observado para entender por qué importa esa línea. La actuación se reparte en tres estados:

• Live en el binario por defecto, sin aprovisionamiento: aplicación de presupuestos FinOps (un presupuesto que aplica enforcement en su tope deniega el gasto — in-process, siempre cableado), envío de notificaciones una vez configurado un destino, hallazgos detective de seguridad y el runner del sandbox sintético in-process.
• On-demand — backend construido y cableado, pero deny-closed o degradado hasta que un operador lo aprovisiona: deploy apply/retire (un 503 hasta que se aprovisiona un executor), fire de orquestación y envío de voz (deny-closed hasta que se configura un dispatcher), el runtime aislado de sandbox/red-team (sintético hasta que se aprovisiona) y la ejecución de modelos (un 503 hasta que se configura una credencial de inferencia).
• Seam — una interfaz declarada, deny-closed, todavía sin backend.

El air-gap aplica al control plane, no a la inferencia de Claude

Esta es la salvedad más importante. El control plane — gobernanza y observación — se ejecuta totalmente self-hosted y puede estar air-gapped: nodo único, release firmada offline, bundle air-gap.

Claude en sí no es self-hostable. Anthropic no publica los pesos, así que cualquier inferencia de Claude llega a la API de Anthropic, directamente o vía Bedrock / Vertex / Foundry. En Olivares AI esos seams de inferencia son fail-closed: sin credencial de inferencia el LLM judge queda omitido y los embeddings recurren a un embedder local de cero salida a red. “Air-gapped” aquí significa que tu plano de gobernanza y observación y sus datos permanecen dentro de tu perímetro — no significa que Claude se ejecute offline. Solo los modelos que self-hosteas de verdad (por ejemplo vía vLLM u Ollama bajo el módulo de gestión de modelos) pueden ejecutarse air-gapped; los modelos de frontera intermediados no. Consulta conectar Claude Code y seguridad.

No todas las rutas de módulo están en el contrato público de la API

Algunos endpoints de módulo (por ejemplo el grafo del mapa de acceso y el drift) son accesibles pero no forman parte deliberadamente del documento OpenAPI servido; sus contratos a nivel de campo viven en las interfaces tipadas del producto. Las referencias de CLI y configuración cubren la superficie operativa; el contrato OpenAPI es la superficie REST principal, no el producto entero.

No certificado

Olivares AI está diseñado hacia SOC 2, ISO 27001 y la EU AI Act — no está certificado frente a ninguno de ellos. Consulta cumplimiento para entender qué significa “diseñado hacia” y qué evidencia produce la plataforma.

Qué decide el producto no hacer deliberadamente

• Sin funciones ofensivas. Esto no es un framework de command-and-control y no escanea las credenciales de otros. El mapa de acceso es reconocimiento para que los defensores gobiernen su propio estate — verlo es una acción privilegiada, acotada al tenant y plenamente auditada. La línea defensiva es intencionada.
• Sin forwarder nativo Splunk S2S. El reenvío a Splunk es una postura documentada (apuntar un Universal Forwarder a un fichero al que el control plane hace append, o hacer push mediante Splunk HEC), no un emisor nativo Splunk-a-Splunk.
• Sin webhooks salientes en el contrato REST. El documento OpenAPI no define ningún webhooks. La entrega saliente firmada existe como destino de notificación interno, y el endpoint entrante SCIM Security-Event-Token es un receptor — ninguno de los dos es un webhook de OpenAPI.
• Sin fine-tuning antes de v1. El fine-tuning de modelos (el módulo de gestión de modelos) es posterior a v1. Su ausencia es una decisión, no una carencia.

Una nota sobre la exportación de auditoría

La exportación del ledger por CLI apunta a cef, syslog y otlp. La ruta de push de eventos a un SIEM renderiza un conjunto de dialectos más amplio (incluidos OCSF y LEEF) cuando hay un sink configurado. La exportación pull es la forma adecuada para el archivado WORM y la reverificación offline.

Si encuentras un comando que no se comporta como está documentado, eso es un bug en la documentación o en el producto — por favor, repórtalo. Esta página es el ancla de confianza; todo lo demás se remite a ella.