Pervaziv AI ha ampliato il proprio Cortex AI Model Ensemble con Cortex Router, un nuovo modello specializzato progettato per interpretare l’intento dello sviluppatore e indirizzare ogni richiesta verso il modello, il workflow o il livello di supervisione più appropriato. Con questa aggiunta l’ensemble passa a otto modelli e assume una struttura nella quale la scelta della capacità AI da utilizzare non deve più essere effettuata manualmente dall’utente: Cortex Router analizza il tipo di lavoro richiesto, ne valuta portata e sensibilità e determina quale percorso debba essere attivato prima che gli altri modelli inizino l’elaborazione.
Il ruolo di Cortex Router è quindi differente da quello dei sette modelli che coordina. Il sistema è stato addestrato specificamente per riconoscere l’intento espresso in linguaggio naturale, classificare la richiesta e distinguere tra interazioni semplici, attività di sviluppo, analisi di sicurezza, operazioni che richiedono verifica e situazioni nelle quali è necessario introdurre ulteriori controlli o coinvolgere direttamente una persona. Il router costituisce così il punto di ingresso dell’ensemble, mentre le capacità specialistiche successive vengono selezionate in funzione del lavoro effettivamente richiesto.
La struttura deriva dalla strategia introdotta con Cortex 5.2, versione con la quale Pervaziv AI aveva presentato inizialmente un ensemble composto da sei modelli specializzati. L’architettura comprendeva Cortex-LLM 1.0 per workflow strutturati legati alla sicurezza del software, Cortex Privacy 1.1 per l’individuazione locale di dati sensibili, Cortex Prompt Guard 1.2 per il rilevamento di prompt injection e manipolazioni delle istruzioni, Cortex Analysis 1.3 per analisi di sicurezza strutturate, Cortex Safety 1.4 per decisioni sensibili al rischio e Cortex Code 1.5 per attività generali di programmazione. A queste capacità è stato successivamente aggiunto Cortex Verify, dedicato alla verifica di codice e patch, portando l’ensemble a sette modelli prima dell’arrivo del nuovo Router.
Le diverse componenti non vengono eseguite necessariamente nello stesso ambiente. Cortex Privacy e Cortex Prompt Guard sono stati progettati per lavorare vicino al dispositivo e al contesto dello sviluppatore, effettuando controlli prima che le informazioni vengano inviate a servizi AI più ampi. Cortex Privacy può identificare credenziali, riferimenti a clienti, endpoint interni, valori di configurazione, log e altre informazioni considerate sensibili; Cortex Prompt Guard analizza invece contenuti non attendibili per individuare tentativi di prompt injection o istruzioni costruite per modificare il comportamento dell’agente.
I modelli backend svolgono operazioni più complesse. Cortex Analysis si concentra sull’analisi strutturata dei problemi di sicurezza, Cortex Safety interviene nelle situazioni nelle quali una richiesta presenta un livello di rischio superiore e può richiedere restrizioni o ulteriori verifiche, mentre Cortex Code fornisce capacità di generazione, modifica, spiegazione, debug, refactoring e pianificazione del software. Cortex Verify aggiunge una fase distinta di controllo sulle modifiche prodotte, con l’obiettivo di verificare codice e patch prima che proseguano nel ciclo di sviluppo.
Cortex Router viene collocato a monte di queste funzioni. Una richiesta che necessita semplicemente di una spiegazione può quindi essere trattata diversamente da una modifica effettiva al repository; una richiesta relativa a una vulnerabilità può essere indirizzata verso un percorso di analisi di sicurezza, mentre una patch proposta dall’AI può attivare Cortex Verify prima che venga considerata completata. Se il contenuto coinvolge dati sensibili, prompt provenienti da fonti non attendibili o azioni potenzialmente rilevanti dal punto di vista della sicurezza, il sistema può inserire i controlli specifici dell’ensemble prima di consentire al workflow di procedere.
Questa impostazione separa il routing dalla capacità generativa vera e propria. Nei sistemi nei quali l’utente deve scegliere direttamente il modello, la corretta configurazione dipende dalla conoscenza delle caratteristiche di ciascuna opzione; aumentando il numero di specialisti, cresce anche la complessità della scelta. Cortex Router viene introdotto proprio per evitare che lo sviluppatore debba conoscere la distinzione operativa tra otto modelli, diversi workflow e differenti modalità di esecuzione. L’utente può descrivere il risultato desiderato e il router determina quali componenti dell’ambiente Cortex devono partecipare.
Il modello considera anche il livello di rischio associato all’azione. Una domanda informativa e una modifica automatizzata a codice destinato alla produzione possono utilizzare capacità simili nella fase iniziale, ma richiedono livelli differenti di controllo prima dell’esecuzione. Cortex Router è quindi progettato per valutare non soltanto l’argomento della richiesta, ma anche la natura dell’azione che potrebbe derivarne, decidendo quando sia sufficiente una risposta diretta, quando debba essere attivato un workflow più articolato e quando siano necessarie validazione o supervisione umana.
L’integrazione con Cortex Verify rende questa logica particolarmente rilevante nel ciclo di sviluppo. La verifica non deve essere necessariamente richiesta esplicitamente dallo sviluppatore al termine del lavoro, perché il router può identificare in anticipo una modifica per la quale è opportuno aggiungere una fase di controllo. L’ensemble può quindi passare dalla comprensione iniziale della richiesta alla generazione o modifica del codice e successivamente alla sua validazione, utilizzando modelli distinti per compiti che presentano requisiti differenti.
La stessa struttura viene applicata alla sicurezza. Cortex 5.2 era stato progettato per distribuire i controlli tra modelli locali e backend, consentendo alle informazioni sensibili o ai contenuti potenzialmente manipolati di essere intercettati prima di raggiungere i modelli più generali. Cortex Router aggiunge un ulteriore livello di coordinamento, perché può stabilire quando questi controlli devono entrare nel workflow e quale componente debba intervenire successivamente, senza affidare a un solo modello generale l’intera sequenza di classificazione, generazione e verifica.
Pervaziv AI definisce Cortex come un Enterprise AI Control Layer proprio per questa separazione delle responsabilità. La piattaforma riunisce sviluppo software, sicurezza, privacy, governance, orchestrazione dei modelli e attività agentiche all’interno dello stesso ambiente, mentre i singoli modelli vengono utilizzati per compiti circoscritti. Cortex Router diventa il componente che collega l’esperienza dello sviluppatore a questa architettura, traducendo una richiesta iniziale nella combinazione di capacità necessarie per completarla.
Il modello rafforza inoltre la strategia di model independence della piattaforma. L’indipendenza dal modello non viene interpretata soltanto come possibilità di sostituire un provider o scegliere manualmente tra diversi LLM, ma come separazione tra le funzioni svolte dai modelli e il workflow utilizzato dall’applicazione. Un componente dedicato alla privacy, alla verifica o all’analisi può essere modificato o sostituito mantenendo stabile il ruolo che occupa all’interno dell’ensemble; il router continua a indirizzare le richieste verso quella funzione senza richiedere allo sviluppatore di adattare ogni volta il proprio modo di utilizzare Cortex.
Questa modularità permette anche di far evolvere indipendentemente le diverse capacità. Il modello destinato alla programmazione può essere aggiornato senza modificare quello per il prompt security, mentre un nuovo sistema di verifica può sostituire Cortex Verify mantenendo invariato il percorso attraverso il quale il router attiva il controllo. L’architettura utilizza quindi la specializzazione non soltanto per ottenere prestazioni diverse, ma anche per isolare responsabilità operative che nelle piattaforme costruite attorno a un unico modello generalista rimangono concentrate nello stesso componente.
Cortex Router è stato addestrato intorno alle distinzioni tipiche del lavoro di ingegneria software, nel quale una stessa sessione può passare rapidamente da una domanda a un’analisi, da un’indagine a una modifica del codice e successivamente a una verifica. Il router deve riconoscere questi cambiamenti e modificare il percorso utilizzato dall’ensemble senza costringere l’utente ad aprire strumenti differenti o selezionare manualmente un altro modello ogni volta che cambia la natura dell’attività.
L’approccio si inserisce nell’evoluzione più ampia di Cortex, che nei mesi precedenti era passato da assistente di coding a piattaforma comprendente analisi dei repository, workflow DevSecOps, threat modeling, security review, orchestrazione multi-agente e integrazione con ambienti multicloud. Cortex 3.5 aveva già introdotto più di 40 agenti, oltre 12 connector aziendali e più di 300 capacità operative distribuite tra AWS, Azure e Google Cloud; le versioni successive hanno aggiunto controlli di sicurezza, continuità delle sessioni e sistemi dedicati all’esecuzione governata delle attività AI.
Il passaggio all’ensemble di modelli specializzati modifica il livello nel quale viene effettuata questa orchestrazione. Gli agenti e gli strumenti possono continuare a svolgere attività specifiche nei sistemi aziendali, mentre Cortex Router decide quale forma di intelligenza debba essere utilizzata per interpretare e gestire la richiesta prima che l’azione venga eseguita. La piattaforma combina quindi orchestrazione degli agenti, routing dei modelli e controlli di sicurezza come livelli differenti dello stesso workflow.
Con Cortex Router, l’ensemble passa da una raccolta di sette capacità esecutive a un sistema composto da sette modelli specializzati e da un ottavo modello incaricato di coordinarne l’accesso. Il nuovo componente non sostituisce Cortex Code, Cortex Verify o i modelli dedicati a privacy e sicurezza, ma determina quando ciascuno debba essere utilizzato e con quale grado di controllo. Pervaziv AI punta così a mantenere un unico punto di ingresso per lo sviluppatore anche mentre aumenta il numero delle capacità interne, lasciando al router la classificazione dell’intento, la valutazione della sensibilità del task e la scelta del percorso operativo successivo.