Olivares AI e una piattaforma modulare: un motore più un catalogo di moduli di capacità più connettori. Un modulo consuma eventi normalizzati dal core, dichiara le proprie entita nel modello dati condiviso, e espone le proprie API e viste — senza ri-architettare il resto.
Il binario standard collega 29 pacchetti modulo, organizzati sotto in aree di capacità numerate (la tabella raggruppa diversi pacchetti in una singola area, e alcune voci sono infrastruttura fondamentale o post-v1). Leggilo come un catalogo, non come una checklist di funzionalità: governare/osservare e ampio è attivo su tutto l’estate; l’attuazione e la parte ristretta e controllata — ogni riga è marcata come live, configurata su richiesta (503 finche non configurata), o un seam deny-closed. La piattaforma e pre-1.0. Vedi Trasparenza e limiti per come formuliamo cosa e e cosa non è costruito.
Oltre al catalogo numerato c’e un modulo di supporto live-ingest (numerato XXIV nel codice): il tap eventi live da cui gli altri moduli leggono. E infrastruttura piuttosto che una superficie autonoma, quindi non viene contato tra il catalogo numerato.
Come leggere lo stato di ogni modulo
Ogni modulo ha due meta, e la distinzione onesta tra esse e il punto centrale:
- Governare / Osservare — catalogare, osservare, confrontare, bloccare, riportare. Questo è costruito e cablato oggi per i moduli marcati come live sotto. Il prodotto e lettura prima di tutto è investigativo per default: osserva e governa fuori banda, non si interpone nel percorso delle richieste.
- Attuare — agire sulla tua infrastruttura reale (deploy, fire, dispatch, send, enforce). Questo è deliberatamente ristretto e si divide in tre stati:
- live — cablato nel binario predefinito, nessuna configurazione richiesta.
- on-demand — il backend è costruito e collegato a un punto di iniezione ma resta deny-closed finche un operatore non lo configura; fino ad allora un’azione approvata e onestamente “dichiarata, non attuata” (ad esempio, deploy
apply/retirerestituiscono un chiaro503). - seam — un’interfaccia dichiarata, deny-closed, senza backend predefinito ancora.
La divisione e il contratto: il prodotto osserva e governa ampiamente, e attua su un sottoinsieme piccolo e per lo più controllato dalla configurazione. Niente qui dichiara un’esecuzione che il codice non fa.
Scoperta è stato live
| # | Modulo | Governare/Osservare | Attuare | Cosa fa | |—-|—-|—-|—-|—-| | I | Inventario è scoperta | live | — | Scopre passivamente e cataloga agenti, sessioni, server MCP, tool, modelli, provider e identità non umane in tutto l’estate. | | II | Operazioni live e sessioni | live | — | Traccia lo stato in tempo reale di ogni sessione agente — azione corrente, token/costi live, una timeline riproducibile — derivato dai segnali, mai fabbricato. | | III | Mappa degli accessi e delle risorse (R/RW) | live | — | Il differenziatore: quale agente legge (R) o legge-scrive (RW) quale risorsa, e se quell’accesso e permesso o solo osservato. Vedi il tour. | | XXII | Salute, SLA e uptime | live | — | Affidabilita di agenti e server MCP — sano, degradato o in down, e la mappa delle dipendenze — derivato da segnali osservati, non sondando la tua infrastruttura. |
Capacita, identità e governance
| # | Modulo | Governare/Osservare | Attuare | Cosa fa | |—-|—-|—-|—-|—-| | V | MCP, skill e capacità | live | — | Gestione visiva di server MCP, skill, plugin/subagent e quale agente è collegato a quale tool. Vedi il tour MCP. | | VI | Identità, permessi e governance | live | on-demand | Governa chi e cosa può fare cosa, con approvazione HITL. Gli attuatori del ciclo di vita delle identità con capacità di scrittura sono opt-in e deny-closed finche non configurati. Vedi il tour identità. | | VIII | Dati, conoscenza e contesto | live | live | Il piano dati governato — basi di conoscenza e RAG con redazione prima dell’indicizzazione, recupero governato, e lineage sul piano dati governato — i dati di governance di Olivares restano in un’infrastruttura sotto il tuo controllo; le richieste ai modelli ospitati vanno ai provider che scegli. Il recupero lessicale e il default; gli embedding semantici basati su modello sono cablati su richiesta. | | XIV | Catalogo interno e marketplace | live | — | Cura e permette all’organizzazione di riusare agenti, server MCP, skill e template approvati e versionati; le richieste di istanziazione passano attraverso la governance. |
Deployment e stack dei modelli
| # | Modulo | Governare/Osservare | Attuare | Cosa fa |
|—-|—-|—-|—-|—-|
| VII | Deployment e integrazione | live | on-demand (503) | Pianifica e governa deployment/wiring verso l’infrastruttura — l’unico modulo che può mutarla. Ogni cambiamento e HITL-gated, plan-before-apply è registrato nel registro. L’executor è cablato su richiesta: apply/retire restituiscono 503 finche non è configurato. |
| X | Gestione modelli e provider | live | solo routing | Governa e instrada su tutto lo stack dei modelli — Claude, OpenAI, Gemini, inferenza locale — con pricing di riferimento verificato dall’operatore. La risoluzione del routing e live; la chiamata al modello stessa gira su richiesta una volta che una credenziale di inferenza è configurata. |
I modelli hosted non sono self-hostabili. Il Modulo X può instradare verso Claude (direttamente o tramite Bedrock/Vertex/Foundry), ma quell’inferenza raggiunge comunque l’API del provider. Solo i modelli genuinamente self-hosted (vLLM/Ollama) funzionano completamente offline; l’air-gap si applica al piano di controllo Olivares, non all’inferenza hosted.
Costi, qualità e conformita
| # | Modulo | Governare/Osservare | Attuare | Cosa fa |
|—-|—-|—-|—-|—-|
| XI | Costi e AI FinOps | live | live | Contabilizza la spesa AI dal flusso di costi del provider e applica i budget — al tetto, un gate di budget throttle/block nega la spesa (deny-closed). Vedi il tour FinOps. |
| XII | Qualità, evals e testing | live | — | Valuta gli output candidati rispetto a suite golden versionate con scorer deterministici più un giudice LLM, producendo evidenze cross-modulo. Vedi il tour evals. |
| XIII | Conformita e regolamentazione | live | — | Mappa ciò che la piattaforma già osserva e registra su framework (EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2, GDPR, OWASP Agentic) e produce evidenze consumabili dagli auditor. Progettato verso, non certificato. Vedi il tour conformita. |
Sicurezza e garanzia
| # | Modulo | Governare/Osservare | Attuare | Cosa fa | |—-|—-|—-|—-|—-| | IX | Sicurezza, guardrail e audit | live | live | Il piano difensivo: guardrail su input/output/testo dei tool degli agenti (PII, segreti, prompt-injection, OWASP Agentic Top 10), rilevamento anomalie sul drift osservato, e timeline di incidenti ricostruibili. Le segnalazioni vengono emesse live; le evidenze memorizzano un hash più un estratto redatto, mai il payload grezzo. | | XVII | Sandbox di test degli agenti | live | on-demand | Esecuzioni isolate ed effimere di scenari agente contro risorse simulate, più replay deterministico. Il runner sintetico in-process e live; il runtime OS-isolato è cablato su richiesta. | | XVIII | Red-teaming e test avversariale | live | on-demand | Un harness di robustezza difensiva (prompt injection, jailbreak, esfiltrazione, avvelenamento dei tool) mappato su OWASP Agentic e MITRE ATLAS. Le esecuzioni isolate sono cablate su richiesta e riportano DEGRADED — mai un falso pass — finche un runtime sandbox non è configurato. |
Coordinamento, voce e output
| # | Modulo | Governare/Osservare | Attuare | Cosa fa | |—-|—-|—-|—-|—-| | IV | Comunicazione e orchestrazione inter-agente | live | on-demand | Deriva il grafo live di delegazione/comunicazione dagli archi osservati e governa gli agenti pianificati/autonomi. L’avvio e bifase e HITL-gated; il dispatch live e deny-closed finche un dispatcher non è configurato. | | XV | Integrazioni di output e notifiche | live | live | Il router delle notifiche — decide quale segnale va a chi, tramite quale canale; i connettori (Slack/Teams, PagerDuty/Opsgenie, webhook firmato, SIEM) consegnano. Il dispatch e live; le destinazioni sono configurate dall’operatore. | | XVI | Agenti voce e in tempo reale | live | on-demand | Osservazione e governance per agenti conversazionali/in tempo reale: governa chi può aprire una sessione, con quale modello, sotto quale policy default-deny. L’apertura e HITL-gated; l’attuazione passa attraverso un dispatcher deny-closed finche un provider voce non è configurato. |
Piattaforma e reporting
| # | Modulo | Governare/Osservare | Attuare | Cosa fa | |—-|—-|—-|—-|—-| | XIX | API propria e manage-as-code | live | — | Gestisci il piano di controllo stesso tramite API/IaC, più una superficie di eventing per integratori (sottoscrizioni durevoli, retry, dead-letter, replay). Fondamentale. | | XX | Multi-tenancy e gestione organizzazione | live | — | Gerarchia organizzativa e admin delegato per MSP e grandi organizzazioni. Fondamentale. | | XXI | Dashboard esecutive e reporting | live | — | Viste di alto livello per la leadership accanto alla console tecnica. | | XXIII | Gestione modelli propri / fine-tuning | post-v1 | — | Governa modelli addestrati o ospitati dall’azienda. Post-v1 — non cablato oggi. |
Una nota trasversale: il kill switch
Al di la di qualsiasi singolo modulo, il kill switch dell’estate collega un gate di stop a ogni punto di attuazione: deploy, orchestration fire, voice open, esecuzione modello e spesa budget. Uno stop e enforcement positivo ed e deny-closed — uno stato di stop illeggibile viene trattato come fermato, mai come via libera. Vedi il tour del kill switch.
Correlati
- Cos’è Olivares AI? — il prodotto in una pagina.
- Permesso vs osservato e fedeltà — come i moduli I-III restano onesti su ciò che possono dimostrare.
- Trasparenza e limiti — la postura completa live-vs-roadmap.
- Architettura — come si compongono motore, livelli e connettori.