AI Admin Console: cosa fa realmente ciascuna delle sei capacità
AI Admin Console espone sei capacità. Ciascuna è una voce del menu laterale e ciascuna risponde a una specifica domanda che un revisore di procurement o un responsabile di compliance porrà nel corso della due diligence aziendale. Le sei coprono insieme quelli che l'EU AI Act chiama obblighi del deployer [1] e quelli che il NIST AI RMF chiama "registri delle azioni del sistema sufficienti a ricostruire le decisioni" [2] — da un'unica applicazione desktop che il team IT sa già come installare.
Le capacità sono elencate nell'ordine in cui compaiono nel menu laterale della Console. Ogni sezione qui sotto indica la domanda di procurement, cosa fa la Console al riguardo e dove vivono i dati.
Membri e accessi
La domanda: chi nella nostra organizzazione è autorizzato a utilizzare AI Suite, e su quale piano di licenza?
La Console consente a un amministratore di invitare colleghi via email, di assegnare posti di licenza Personal o Commercial (Monthly, Annual o One-Time) e di revocare l'accesso quando il personale lascia l'organizzazione. Bulk-invite da CSV. Il roster è l'unica fonte di verità del deployer per il "chi ha accesso" — la stessa risposta che il team di compliance produce quando gli viene chiesto di dimostrare la supervisione umana.
Cosa vive sul backend Software Tailor: il roster dell'organizzazione. Cosa non vi vive: alcuna traccia di ciò che quei membri hanno fatto all'interno del modello. La Console è la superficie d'accesso; l'inferenza avviene localmente.
Licenze
La domanda: quale piano ha ciascun membro e come viene applicato offline?
Le chiavi di licenza per utente vengono convalidate offline. Utile quando i posti devono continuare a funzionare senza un round-trip di rete — un requisito comune per i settori regolamentati in cui la workstation AI si trova su una rete segmentata. La Console emette e revoca le chiavi; gli override del piano per singolo utente sono visibili accanto al default dell'organizzazione.
È l'unica capacità in cui la Console scrive un valore che deve viaggiare verso la macchina dell'utente. Tutto il resto è metadato sul deployment, non sul contenuto.
Arruolamento dell'AI Server
La domanda: su quale hardware la nostra organizzazione sta facendo affidamento per eseguire l'inferenza?
Le installazioni di AI Suite dialogano con un processo locale aisuite-server; quel processo può dialogare con un modello on-device oppure con un AI Server controllato dal cliente in esecuzione all'interno della rete del cliente. L'arruolamento dell'AI Server è il modo in cui la Console vincola quelle istanze server all'organizzazione affinché accettino richieste firmate dalle installazioni di AI Suite approvate. Esegui il pairing, ruota le credenziali, revoca senza toccare la macchina server stessa.
L'angolatura di procurement: l'hardware di inferenza è del deployer. L'arruolamento lo dimostra. La Console non vede mai l'input o l'output del modello.
Policy
La domanda: quali modelli, provider e regole di gestione dei dati si applicano alle installazioni di AI Suite della nostra organizzazione?
La policy è la configurazione a livello di organizzazione che ogni app AI Suite rispetta: quali modelli sono consentiti, gli hint di data-residency, i provider di sign-in e la configurazione del tenant OIDC. Le modifiche si propagano a ogni installazione al successivo avvio. È ciò a cui il deployer indirizza la compliance quando gli viene chiesto "quali guard-rail sono in vigore?" — ed è ciò che modifica quando entra in vigore un'integrazione dell'EU AI Act (più di recente, l'accordo omnibus del 7 maggio 2026 ha inasprito la definizione di sistema ad alto rischio [1]).
Audit
La domanda: cosa è accaduto, quando, da parte di chi — e possiamo produrlo su richiesta?
Ogni azione amministrativa atterra in una riga di audit JSONL: timestamp, email dell'autore, verbo dell'azione, risorsa interessata, X-App-Id del client di origine. Nessun prompt. Nessuna risposta. Nessun contenuto di documenti. Lo store di contenuto del deployer conserva il contenuto delle inferenze; la riga di audit della Console conserva la prova che un'azione sia avvenuta.
Questa separazione è ciò che rende la riga conforme ai "registri delle azioni del sistema sufficienti a ricostruire le decisioni" del NIST AI RMF [2] senza conservare contenuto del modello che il deployer non vuole conservare. L'architettura e il formato della riga sono documentati nel nostro articolo sui log di audit privi di contenuto.
Utilizzo per organizzazione
La domanda: cosa sta realmente accadendo all'interno della nostra organizzazione, in forma aggregata?
Un roll-up di telemetria in sola lettura, riferito all'organizzazione: installazioni attive, eventi principali, durata media di inferenza, valutazioni dei modelli. Nessun prompt grezzo. Tutto è aggregato e privo di contenuto per design. Il team IT del deployer lo utilizza per il capacity planning; il team di compliance lo utilizza per "la policy viene davvero rispettata?".
È l'unico punto in cui compare un numero che attraversa i membri ed è l'unico punto in cui la Console riassume il comportamento nel tempo.
Perché un unico strumento
Il NIST AI RMF [2] richiede "registri delle azioni del sistema sufficienti a ricostruire le decisioni". L'EU AI Act richiede ai deployer di dimostrare la supervisione umana, di monitorare il funzionamento del sistema, di conservare i log e di produrli su richiesta [1]. In entrambi i quadri il deployer — non il fornitore — è titolare dell'obbligo. La Console esiste perché il team IT del deployer ha bisogno di un unico luogo in cui adempiervi.
Le sei capacità non sono una checklist di funzionalità. Sono la risposta alle sei domande che un revisore di procurement porrà in sequenza. I team che avviano questa fase di due diligence su un deployment di AI on-prem dovrebbero iniziare dall'inquadramento in Perché i deployment di AI on-prem si bloccano in fase di procurement; la Console è il luogo in cui vivono le risposte.
Riferimenti
- European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultato il 2026-07-01.
- NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-07-01.
Articoli correlati
- EU AI Act nel 2026: cosa cambia il deployment on-prem in termini di conformità
- Perché i deployment di AI on-prem si bloccano in fase di procurement (e l'inquadramento che risolve il blocco)
- Log di audit privi di contenuto: come dimostriamo cosa ha fatto il modello senza conservare i prompt
- Tutti gli articoli →
Vedi AI Admin Console in azione su un carico di lavoro reale.
Un pilot gratuito di 1 settimana mette il modello sull'hardware del cliente, la riga di audit nel SIEM del cliente e le sei capacità della Console nelle mani del team IT.