O cockpit para os agentes de IA que correm na sua infraestrutura

Já gere os painéis de tudo o resto no parque: hosts, filas, data stores, o caminho do pedido. Depois aparece uma dúzia de agentes de IA — copilots, servidores MCP, tarefas agendadas, uma instância do Claude Code que alguém ligou à produção — e não tem um único sítio que responda à primeira pergunta do operador: o que está a correr, e o que é que cada coisa consegue realmente alcançar?

É o mesmo padrão da infraestrutura-sombra não gerida, com a diferença de que as cargas de trabalho detêm credenciais e actuam por sua conta. Das organizações que sofreram uma violação relacionada com IA, cerca de 97% não dispunham de controlos de acesso a IA adequados (IBM Cost of a Data Breach 2025, Ponemon). A indústria já tem uma palavra para a causa — agent sprawl — e a Gartner prevê que mais de 40% dos projetos de IA agêntica sejam cancelados até ao final de 2027 (Gartner), muitas vezes porque ninguém os conseguia operar com segurança depois de se multiplicarem.

O que um operador obtém

O Olivares AI é uma plataforma aberta e self-hostable que corre onde os seus agentes correm. Descobre-os, constrói um mapa de acessos de leitura/escrita do que cada um toca, e dá-lhe os controlos para governar e auditar esse acesso. Para um SRE ou administrador de sistemas, há cinco propriedades que importam mais do que a lista de funcionalidades.

Passivo — fora do caminho do pedido

A descoberta é construída a partir de telemetria e de auditoria nativa da fonte, fora de banda. A vista de saúde e fiabilidade é um consumidor do bus de eventos, não um sondador que abre sockets na sua infraestrutura — a liveness é inferida a partir da atividade observada, e um agente que deixa de emitir é, ele próprio, um sinal. Como o Olivares não é um proxy nem um sidecar à frente dos seus agentes, uma indisponibilidade do Olivares não os pode derrubar. As únicas superfícies que alguma vez se colocam inline são as portas de actuação opcionais que escolher ligar, e essas falham em fechado.

Um único binário estático self-hosted

Implementa-se como um único binário estático com a consola web embebida — sem uma frota de agentes para distribuir, sem um operador Kubernetes de control plane para vigiar. O store é SQLite em Go puro (Postgres para multi-tenant), pelo que não há uma toolchain de C para combater. Instala um ficheiro, executa-o como um utilizador de serviço dedicado, e tem o cockpit. Veja instalar e self-host.

O control plane corre dentro do seu perímetro e pode correr em air-gapped — os seus dados de governação e de observação nunca saem. Há uma ressalva que os operadores devem reter: isto não é IA offline. Modelos alojados como o Claude continuam a contactar a API do fornecedor; air-gapped significa que os dados do seu parque ficam em casa, não que o modelo corre localmente. Apenas modelos genuinamente self-hostable (vLLM, Ollama) correm totalmente offline. Mais em segurança e arquitetura.

Ingestão OTel-native

O caminho de ingestão fixa as convenções semânticas OpenTelemetry GenAI a par do OCSF, dos formatos SIEM e do W3C Trace Context — pelo que a telemetria que já emite é a telemetria que lê. Uma fronteira honesta: o Olivares correlaciona o seu registo de eventos governados pelo trace_id do W3C; não armazena spans OTel completos. As durações e o estado na vista de trace são janelas de eventos do registo, não dados de span reconstruídos. Os spans completos ficam no seu próprio colector OTLP, onde devem estar. O Olivares diz-lhe quem tocou no quê e se foi permitido — não é um substituto da sua backend de tracing. (Veja a página comparar para onde se situa em relação ao LiteLLM/Langfuse.)

Sondas e saúde, como qualquer serviço que opera

O binário expõe os endpoints que o seu orquestrador já espera:

GET /livez     liveness  — is the process up
GET /readyz    readiness — is it serving (and not a cold standby)
GET /healthz   setup-exempt liveness for scrapers
GET /metrics   Prometheus exposition

O /readyz devolve 503 quando o store de suporte está inacessível em vez de ficar pendurado, para que um balanceador de carga drene o nó em vez de o transformar num buraco negro. Para além disso, o módulo XXII acompanha a saúde, o SLA e o uptime dos próprios agentes e servidores MCP — o que está saudável, o que está degradado, e o que depende do quê — e emite achados de down/degraded/ recovered/SLA-breach para o seu canal existente (Slack, PagerDuty, SIEM). Produz o sinal; não tenta ser o seu notificador.

Read-first, com uma verdadeira paragem para todo o parque

O Olivares é observador por omissão e deny-closed. Observa e governa de forma ampla; não actua de forma ampla. Mas quando um agente corre mal às 3 da manhã, um operador precisa de uma única alavanca que funcione sem cerimónia — por isso o kill-switch é real e foi feito para ser usado:

• Accioná-lo é barato. Nível de admin, um motivo obrigatório, um clique. Não existe porta de aprovação nem escalação no accionar — uma paragem de emergência que espera por quórum não é uma paragem. O âmbito de todo o parque nega todas as superfícies de actuação governadas do tenant; o âmbito do agente pára um único agente em todas as superfícies onde possa ser nomeado.
• Reactivar não é. Levantar uma paragem exige dual-control (dois humanos distintos) e é seguido de uma revisão posterior obrigatória que uma terceira pessoa, não envolvida, tem de assinar. “O parque continua parado” é o estado seguro.
• Falha em fechado. Cada porta de actuação consulta o estado de paragem em tempo real a cada chamada e nega em caso de erro de leitura — uma paragem ilegível nunca significa “avançar”.

Seja honesto consigo próprio quanto ao âmbito: a paragem é tão ampla quanto as portas que ligou. Não consegue congelar uma superfície onde o Olivares não tem costura. É a troca deliberada de um sistema read-first — e é por isso que a descoberta e o mapa vêm primeiro.

O que isto é — e o que não é

• É um cockpit passivo e self-hosted: descobre os agentes, mapeia o seu acesso de leitura/escrita, vigia a sua saúde, e mantém uma paragem para todo o parque a um clique.
• Não é um proxy inline, uma backend de tracing, nem um sistema que reconfigura silenciosamente os seus agentes. A actuação é opt-in, a pedido, e deny-closed — cada costura é ligada deliberadamente por si.
• É pré-1.0 e open-core. O catálogo lista 23 módulos de capacidade; cerca de vinte estão ligados hoje, os restantes estão em fase de concepção ou são pós-v1. A referência de módulos assinala o que está ativo.
• Não é certificado. O Olivares é concebido para SOC 2, ISO/IEC 42001 e o Regulamento de IA da UE — não detém essas certificações, e não o vai afirmar. Veja segurança para a postura honesta.
• A fidelidade é escalonada e mostrada como tal. A cobertura de leitura-vs-escrita é clean em stores com auditoria nativa, lossy em alguns document/vector stores, e unknown onde não consegue ser reconstruída passivamente (Redis, SQLite, D1); a atribuição por agente é firm apenas quando o sinal o suporta, approximate por trás de uma conta partilhada. Nada é adivinhado. Veja fidelidade.

Por onde começar

• Coloque-o de pé: self-host, depois o quickstart para um parque sintético.
• Ligue o seu primeiro sinal: conectar uma fonte.
• Compreenda o modelo: permitido vs observado e o mapa de acessos.
• Personas próximas do operador: engenharia de plataforma e líderes de segurança.