¿Qué es Olivares AI?

Olivares AI integra, gestiona y asegura la IA que ejecutas — en una sola máquina o a lo largo de toda una infraestructura, un único ground truth: Claude Code al nivel más profundo, Codex y Grok Build a su lado, complementándolos en lugar de competir. A medida que pones a trabajar más modelos, agentes, servidores MCP y herramientas sobre infraestructura real y heterogénea, dos cosas se vuelven difíciles a la vez: hacer la IA genuinamente útil y mantenerla bajo control. Esto es tan cierto para una sola máquina autoalojada como para una infraestructura regulada; la diferencia es de escala, no de naturaleza.

Olivares AI hace ambas. Por un lado da a tu IA lo que necesita para trabajar — contexto, acceso a los recursos adecuados, sesiones gestionadas. Por otro te da a ti los permisos granulares, las políticas, los presupuestos y la evidencia de auditoría para operarlo todo: qué modelo y qué agente puede alcanzar qué, los datos que tocan, qué se les permite ejecutar, cuánto gastan, y la prueba que puedes entregar a un regulador.

Todo corre como un único binario autoalojado en tus propios hosts. No hay telemetría obligatoria ni egreso del plano de control de forma predeterminada. Solo cruza tu perímetro lo que tú configuras para que lo cruce: llamadas a tus API de modelos, las salidas SIEM/webhook que conectas y un proveedor externo de embeddings si aprovisionas uno. Es una propiedad de la arquitectura y de tu configuración; es una descripción, no una garantía.

Una capacidad: el mapa de acceso de lectura/escritura

Entre esas capacidades está el mapa de acceso L/RW. Para cada origen que una fuente observó (un agente, una identidad no humana, una sesión) construye una arista hacia cada recurso que esa señal muestra que toca, clasificada como lectura, escritura, lectura-escritura o desconocido, y etiquetada con:

de dónde vino la señal (SignalSource) — OpenTelemetry desde un agente cooperativo, una clasificación READ/WRITE de pgAudit de Postgres, un registro de AWS CloudTrail, un backstop a nivel de kernel eBPF/Tetragon, una anotación MCP (tratada como no confiable y corroborada, nunca confiable por sí sola), una concesión de política declarada, o una señal de agente a agente (A2A); y
cuánto confiar en la atribución (Confidence) — attributed cuando está firmemente ligada a una identidad por agente, approximate cuando se infiere (una cuenta de servicio compartida, o un almacén con pérdida).

En su centro está el diff: Permitido frente a Observado. Las aristas permitidas vienen de concesiones declaradas; las aristas observadas vienen de telemetría y auditoría reales. Compararlas saca a la superficie accesos inesperados (un agente leyendo una tabla que nunca le fue concedida), concesiones sin usar (un permiso que ningún agente ejerció jamás) y aristas pendientes de reconciliación (un acceso que el sistema aún no puede atribuir firmemente).

El producto es honesto sobre la fidelidad. La cobertura es escalonada: limpia en almacenes con auditoría nativa (SQL, almacenamiento de objetos, almacenes de datos), con pérdida en algunos almacenes (documento/vector), e imposible de reconstruir pasivamente en otros (p. ej. Redis, SQLite, D1). Cuando no se puede determinar la naturaleza de lectura/escritura, el modo es unknown — el producto nunca fabrica una clasificación.

Una plataforma, no una única funcionalidad

El mapa de acceso es una capacidad entre muchas. El producto es una plataforma modular (en el espíritu de Grafana o Backstage): un motor más módulos más conectores, diseñada para que cualquier módulo se acople sin rearquitecturar el resto. Incluye 32 módulos — inventario y sesiones en vivo, el mapa L/RW, orquestación de agentes (A2A, en desarrollo), gestión de MCP y de skills, identidad e identidad no humana, despliegue, conocimiento y contexto, seguridad y guardrails, gestión de modelos y proveedores, coste/FinOps, evals y un sandbox de pruebas, red-teaming, cumplimiento y evidencia, un catálogo interno, integraciones de salida y push a SIEM, voz/tiempo real, y salud/SLA — más capacidades de plataforma no contadas entre los 30 (su propia API y manage-as-code, multi-tenancy, cuadros de mando ejecutivos) — a través de 136 integraciones (un recuento medido desde el código por scripts/check-public-counts.sh). Unas pocas capacidades son pre-v1 o seams deny-closed hasta que se aprovisionan; los docs son explícitos sobre cuáles.

Community conserva la observabilidad local, los ajustes guardados y la exportación de copias de seguridad. El envío SIEM/ITSM, la telemetría externa y la exportación de postura se incluyen en la edición base de Business.

Consulta el catálogo de módulos para la lista completa, y el resumen de arquitectura para ver cómo encajan el motor y los módulos.

Cómo observa: lectura primero, datos mínimos

El access map observa logs, OpenTelemetry y eBPF fuera de banda. El fallo de un colector de observación crea un hueco de visibilidad; no condiciona el tráfico del agente. El grafo de acceso guarda relaciones — origen → recurso, lectura/escritura, fuente, confianza y marca de tiempo — nunca payloads, cuerpos SQL, secretos ni PII.

Los puntos de enforcement son inline y deny-closed. Las sesiones gestionadas de Claude Code instalan hooks de llamadas a herramientas que llaman al punto de enforcement de política (PEP) del motor. El motor monta este PEP de hooks por defecto. Si resulta inaccesible durante una caída o un reinicio del motor, se deniega toda llamada gobernada a herramientas. Planifica la disponibilidad del motor en consecuencia. El proxy de inferencia inline y los gates MCP tools/call y de delegación A2A aplican sus controles al tráfico encaminado por ellos; las llamadas al modelo no pasan por el proxy de inferencia por defecto.

Esta es también la razón por la que es autoalojable y compatible con air-gap: no hay telemetría obligatoria ni egreso del plano de control de forma predeterminada. Solo cruza tu perímetro lo que tú configuras para que lo cruce — llamadas a tus API de modelos, las salidas SIEM/webhook que conectas y un proveedor externo de embeddings si aprovisionas uno. Olivares AI no está en esa lista: el proveedor nunca está en la ruta de datos. Solo se le llega cuando le pides algo — olivares upgrade, o una descarga por suscripción de módulos comerciales y sus actualizaciones — nunca como efecto de ejecutar. Y olivares upgrade --endpoint apunta incluso eso a tu propio mirror. Es un argumento sólido para la residencia de datos, el RGPD y los entornos air-gapped.

A dónde ir después

Pruébalo: el tutorial de cero a grafo arranca el binario único y llega a un grafo Permitido-frente-a-Observado poblado.
Entiéndelo: el resumen de arquitectura y el modelo de seguridad y amenazas.
Opéralo: autoalojamiento y instalación air-gapped.