Объяснение

Этот раздел ориентирован на понимание. Он объясняет, почему Olivares AI имеет именно такую форму — принципы дизайна, поза безопасности и модель лицензирования — а не проводит вас через задачу. Если вы хотите что-то сделать, начните с туториала или практических руководств; если вам нужен точный контракт, используйте справочник. О том, где живёт каждый вид страницы, см. Как организована документация.

Модульная платформа: движок + модули + коннекторы

Olivares AI помогает предприятиям интегрировать, управлять и защищать AI, который они уже эксплуатируют — один источник истины: Claude Code на самом глубоком уровне, Codex и Grok Build рядом, дополняя их, а не конкурируя. Он поставляется как единый статический бинарный файл Go (olivares) со встроенным веб-UI, раздаваемым с того же origin, что и API. Архитектура — это платформа, а не единый инструмент: базовый движок предоставляет общие подсистемы — сбор и внутрипроцессную шину событий, SDK коннекторов, среду выполнения модулей, многоарендную модель данных, API REST/gRPC, аутентификацию и авторизацию, и журнал аудита только-на-добавление — и каждая возможность является одним из 30 модулей, который держится на этих подсистемах без перепроектирования ядра. Коннекторы питают движок снаружи через стабильный SDK; коннектор никогда не импортирует из ядра, что сохраняет границу лицензирования чистой.

Хранилище по умолчанию — SQLite (чистый Go) для одноузлового и изолированного использования, переходящее к Postgres с защитой на уровне строк для многоарендности и масштаба. Шина событий по умолчанию внутрипроцессная; NATS — опциональная распределённая привязка, а не требование. Платформа поставляет 30 модулей сегодня, каждый со своей честной зрелостью — большинство живые и связанные сквозным образом, некоторые частичные или opt-in — по девяти областям возможностей; реестр собственных моделей и дообучение — это запланированная возможность, а не поставленный модуль.

→ Прочтите Обзор архитектуры о полном движке, модели данных и топологиях развёртывания.

Карта доступа: read-first, минимум данных, Permitted-vs-Observed

Среди наиболее полезных из 30 возможностей — карта доступа R/RW. Она строит граф того, какой агент читает или пишет какой ресурс, и делает это с двумя преднамеренными ограничениями:

Read-first. Карта наблюдает через телеметрию, нативные логи аудита и запасной механизм eBPF на уровне ядра — она находится вне пути данных, никогда в нём. Она не проксирует, не перехватывает и не гейтит живой трафик.
Минимум данных. Она хранит только связь (агент → ресурс, чтение или запись) вместе с источником сигнала и уровнем уверенности. Она не хранит полезные данные, секреты или PII.

Поверх этого графа лежит наиболее отличительное представление: дифф Permitted-vs-Observed, который обнажает дрейф наименьших привилегий, сравнивая то, что политика разрешает, с тем, что агенты наблюдаемо делают. Кооперативный, высокоточный путь — это Claude Code через OpenTelemetry плюс интроспекция MCP, подтверждаемые нативным аудитом хранилища (например, pgAudit, классифицирующий чтения и записи, или CloudTrail, обнажающий доступ только-на-чтение в объектном хранилище); некооперативный запасной механизм — eBPF на уровне ядра. Аннотации MCP считаются недоверенными согласно спецификации MCP и подтверждаются, никогда не доверяются в одиночку.

→ Прочтите Модель безопасности о позе и Модель угроз о допущениях и ограничениях.

Самостоятельно размещаемый и open-core

Слой данных — коллекторы — всегда работает на инфраструктуре заказчика, так что данные владения не обязаны покидать границу заказчика. Управляющий слой может работать как единый самостоятельно размещаемый бинарный файл, как распределённое развёртывание (коллекторы пушат в центральное ядро через gRPC с mTLS, опираясь на Postgres) или полностью изолированно (air-gapped) с нулевым исходящим трафиком и офлайн-лицензией; управляемый вариант — будущая работа.

Лицензирование — open-core. Ядро движка, модули и веб-UI распространяются под AGPL-3.0-only; SDK и коннекторы — под Apache-2.0; корпоративный уровень коммерческий. Это разделение и есть то, что позволяет третьим сторонам строить коннекторы без того, чтобы граница copyleft дотягивалась до их кода.

→ Прочтите Open core и лицензирование о карте лицензий по каталогам и что это означает на практике.

Архитектурные решения

Обоснование несущих выборов — непрозрачные bearer-токены вместо JWT, подключаемый PDP авторизации за единым швом, SQLite-к-Postgres, скреплённый хэш-цепочкой и подписанный журнал аудита — зафиксировано как Architecture Decision Records.

Регулирование, позиционирование и соответствие контексту

Две дополнительные ориентированные на понимание линии стоят рядом с архитектурой. Первая — регуляторная: как управляющий слой превращает живое поведение вашего владения в технические свидетельства, нужные для досье EU AI Act, сгенерированные из данных времени выполнения и хранимые в управляющей плоскости, которую вы эксплуатируете сами.

→ Прочтите Свидетельства EU AI Act из данных времени выполнения.

Вторая — где продукт стоит на рынке — определённое честно, с каждой статистикой, прослеженной до первоисточника. Эти страницы объясняют словарь аналитиков (agent sprawl, guardian agents, AI TRiSM), как Olivares AI соотносится со смежными инструментами (LLM-шлюзы/наблюдаемость, AI control towers — мы интегрируем, мы не конкурируем), вертикаль высшего образования и откуда берутся данные и утверждения.

→ Просмотрите Позиционирование и соответствие, начиная с проверенного контекста рынка и источников.