La maggior parte delle università non ha deciso di adottare l’AI; l’AI è arrivata. I docenti redigono con essa, gli studenti scrivono codice con essa, i gruppi di ricerca collegano agenti ad account di laboratorio condivisi e a dati dipartimentali, e l’IT centrale lo scopre dopo. La ricerca EDUCAUSE (2025) descrive il divario senza giri di parole: l’uso dell’AI è ormai diffuso tra docenti e personale dell’istruzione superiore, mentre la governance formale dell’AI e la copertura delle politiche di uso accettabile restano indietro. Una politica che nessuno può vedere e che nulla applica non è un controllo — è un PDF.
Questo divario non è esclusivo del campus, ma il campus lo rende più acuto. Gli account sono condivisi per progettazione. L’integrità della ricerca dipende dal sapere cosa ha toccato cosa. E le persone che più vuoi abilitare — i ricercatori — sono esattamente quelle che un controllo troppo rigido spingerebbe verso strumenti ombra.
Il problema, in concreto
Sulla rete di un campus tre cose tendono a essere vere contemporaneamente:
- La politica di uso accettabile esiste ma non viene applicata. C’è una regola su quali sistemi l’AI può toccare e cosa può fare. Nulla trasforma quella regola in una decisione nel momento in cui un agente tenta di agire.
- Gli account condivisi cancellano l’attribuzione. Gli agenti di un laboratorio girano come un unico account di servizio dietro un connection pool. L’audit nativo attribuisce l’accesso a quella credenziale — non alla persona o all’agente che l’ha effettivamente compiuto.
- I ricercatori devono muoversi in fretta. Vogliono provare oggi un nuovo agente contro dati quasi reali, non aprire un ticket e aspettare. Se la governance è un cancello da implorare, lo aggirano.
È la stessa forma che il mercato più ampio sta incontrando. Tra le organizzazioni che hanno subito una violazione legata all’AI, circa il 97% era priva di adeguati controlli di accesso all’AI (IBM Cost of a Data Breach 2025, Ponemon), e Gartner prevede che più del 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027 — il debito di governance ne è in gran parte la causa. La versione del campus è più economica da correggere all’inizio, quando gli agenti sono pochi e il raggio d’impatto è ridotto.
Come aiuta Olivares AI
Olivares AI è una piattaforma aperta e self-hostable che scopre gli agenti AI sulla tua infrastruttura, mappa ciò che ciascuno può leggere e scrivere, e ti permette di governare e verificare quell’accesso. È read-first: osserva e registra fuori banda prima di porre cancelli, ed è deny-closed dove invece li pone. Per un campus significa che puoi iniziare vedendo la verità — e solo poi decidere cosa applicare.
Applica le politiche di uso accettabile, deny-closed
Il livello di governance trasforma le AUP in una politica che produce una decisione. Il suo motore ABAC viene eseguito dopo il controllo basato sui ruoli e può solo restringere ulteriormente: nega quando una regola di deny corrisponde, altrimenti la decisione esistente resta valida, e una politica malformata fallisce in modalità chiusa anziché aperta. Così una regola «nessun agente AI può scrivere sul sistema dei voti» o «gli agenti sandbox non possono raggiungere il SIS» diventa un diniego applicato, non un promemoria.
Sii preciso su ciò che la v1 verifica. Le regole di deny oggi si basano sul principal, sul permesso/verbo e sulla risorsa — gli attributi che raggiungono effettivamente il valutatore. Le regole che si ramificano sulla sensibilità della risorsa (ad esempio «qualsiasi cosa etichettata FERPA») richiedono un punto di estensione per gli attributi di risorsa che è un follow-up documentato, non ancora rilasciato. Dove ti serve una persona nel loop, la piattaforma registra una richiesta di approvazione più una traccia decisionale append-only, così «chi ha approvato che questo agente raggiungesse quel dataset» resta verificabile in seguito.
Vedi /docs/concepts/governance per il modello read-first, deny-closed e per capire dove l’attuazione è live rispetto a on-demand.
Attribuisci chi-ha-fatto-cosa sugli account condivisi
Questa è la capacità portante per il campus. La mappa degli accessi registra, con livelli di confidenza onesti, quale agente legge o scrive quale risorsa e se quell’accesso è consentito o solo osservato. La governance dell’identità (/product/identity) lega un agente all’identità canonica che la sua credenziale presenta, così un accesso può essere attribuito in modo solido.
La regola dell’onestà conta qui più che altrove: l’attribuzione è solida solo quando un’identità per-agente o per-sessione viene propagata nell’accesso. Quando più agenti girano come un unico account di servizio condiviso dietro un pool, l’attribuzione collassa su quell’unica identità — e il prodotto lo dichiara, facendo emergere il binding condiviso come una rilevazione di governance anziché indovinare una persona. Un’identità legata a più di un agente viene segnalata, non mascherata. Il rimedio è operativo: propaga l’identità per-agente (ad esempio nell’application name della connessione) e l’attribuzione si affina. Non stamperemo un nome che i segnali non possono sostenere.
Sandbox governate per i ricercatori
I ricercatori ottengono un’esecuzione isolata ed effimera di scenari d’agente contro risorse simulate — non la produzione. Il runner sandbox predefinito è isolato per costruzione: non detiene alcun handle verso il tuo store, la rete o i segreti, e uno step che richiede una risorsa non simulata dallo scenario restituisce un marcatore deterministico di mock-miss anziché raggiungere qualcosa di reale. Le esecuzioni sono effimere; ciascuna registra il runner reale e se era isolato, così un backend degradato è visibile, mai nascosto. Un isolamento più forte a livello di sistema operativo (un container irrobustito o una microVM) è un backend pluggable che l’operatore self-host collega.
Questo dà a un laboratorio un luogo sicuro in cui provare un nuovo agente prima ancora che tocchi dati reali — ed è così che tieni i ricercatori veloci dentro la governance invece di farli aggirarla. Per gli agenti che governano davvero sistemi reali, una batteria difensiva di red-team con consenso (prompt injection, jailbreak, esfiltrazione) può sondare la resistenza di un agente, valutata rispetto all’OWASP Top 10 for Agentic Applications. Viene eseguita solo contro agenti che possiedi e hai autorizzato — è una suite di test, non uno strumento offensivo.
Evidenze per l’integrità della ricerca e gli audit
Le valutazioni misurano gli output candidati di un agente rispetto a golden suite versionate — utili quando un gruppo di ricerca ha bisogno di un record riproducibile che un agente abbia soddisfatto un criterio, esecuzione dopo esecuzione. Il giudice è onesto: se non è collegato alcun backend di scoring, un’esecuzione viene registrata come skipped, mai come un superamento silenzioso, e gli output grezzi non vengono mai persistiti — solo un hash a senso unico e un’etichetta ripulita. Vedi /product/evals.
Per l’istituzione, il livello di compliance (/product/compliance) aggrega ciò che la piattaforma già osserva e verifica in un pacchetto probatorio sigillato e append-only, ancorato a un ledger hash-chained. Un controllo con evidenza a supporto è marcato come soddisfatto; uno senza è marcato come gap, mai come un superamento falsificato. Questa è una mappatura tecnica verso framework come l’EU AI Act e ISO/IEC 42001 — non è consulenza legale e il prodotto non rivendica alcuna certificazione.
Cos’è — e cosa non è
- È un livello aperto e self-hostable di governance e osservazione per l’AI sulla tua infrastruttura. Il control plane può girare offline / air-gapped sul tuo hardware, così i dati di attribuzione e di policy non lasciano mai il campus.
- È read-first e deny-closed. Osserva e governa in modo ampio; non attua in modo ampio. Dove può intraprendere un’azione, quella superficie è live, on-demand o un punto di estensione dichiarato — e il catalogo dei moduli indica quale.
- È pre-1.0. Il catalogo conta 23 moduli con circa 20 collegati; alcune delle capacità sopra descritte sono presenti, alcune sono on-demand, alcune sono follow-up documentati. Indichiamo quale.
- Non esegue i tuoi modelli e non è inferenza air-gapped. L’air gap è il control plane. Solo i modelli self-hosted (vLLM, Ollama) girano offline; i modelli ospitati come Claude no.
- Non è una certificazione. Nessuna certificazione SOC 2 / ISO / EU AI Act — la mappatura di compliance è «progettata verso» quei framework e produce evidenze, non un sigillo. Vedi /security per la postura e /docs/concepts/governance per il modello di governance.
L’adozione è diffusa; è la supervisione a restare indietro (EDUCAUSE, 2025). Il punto di partenza onesto è vedere cosa la tua AI già tocca, decidere cosa può fare e dimostrarlo — in quest’ordine.