Kindo lancia Deep Hat Sift per ridurre le esecuzioni non necessarie degli agenti IA

Un agente IA che legge ogni avviso di sicurezza o voce di registro comporta un costo anche quando conclude che non è necessario intervenire. Con volumi aziendali, queste indagini senza esito possono diventare un carico di lavoro considerevole. Kindo ha lanciato Deep Hat Sift, un modello progettato per decidere quali eventi in arrivo giustificano l’esecuzione di un agente prima che il modello più grande inizi a elaborarli.

Annunciato il 28 ottobre, Sift apprende dai verdetti dell’agente a cui è destinato, quindi filtra gli eventi che l’agente altrimenti scarterebbe. Inizialmente il prodotto osserva, senza trattenere gli eventi: tutti continuano a raggiungere l’agente finché una persona non esamina il comportamento di filtraggio proposto e approva una soglia.

Questo approccio introduce un meccanismo di controllo dei costi diverso dalla scelta di un modello linguistico meno costoso. Invece di ridurre il costo di ogni indagine, Sift mira a evitare quelle che probabilmente non richiedono interventi. La sua efficacia dipende sia dalla qualità di queste decisioni sia dai controlli applicati a ciò che viene saltato.

Un modello decisionale prima del modello linguistico

Kindo descrive Deep Hat Sift come un modello decisionale di Sistema 1: un modello rapido ed economico che risponde a una domanda di selezione anziché generare una risposta. Ogni modello viene assegnato a una specifica origine, a un agente destinatario e a un’attività di filtraggio, così che l’apprendimento rispecchi il carico di lavoro a cui è destinato.

Questa specificità è importante. Un evento rilevante per un’indagine di sicurezza può essere irrilevante per un flusso di lavoro dell’assistenza tecnica. Sift apprende quali eventi l’agente destinatario scarta, usando come segnale di addestramento i verdetti restituiti dall’agente. Kindo afferma che in questo modo si evita un progetto separato di etichettatura manuale per ogni flusso.

La distribuzione iniziale avviene in modalità ombra. Sift assegna un punteggio agli eventi in arrivo mentre l’agente continua a esaminarli tutti, consentendo al sistema di confrontare le proprie previsioni con le decisioni dell’agente. Prima che inizi il filtraggio, gli operatori ricevono un’anteprima di ciò che sarebbe stato trattenuto, basata sui loro dati.

Una persona deve quindi approvare una soglia e fornire una motivazione scritta. La decisione sul comportamento di filtraggio accettabile spetta così al team responsabile del flusso di lavoro, invece di considerare l’attivazione una conseguenza automatica dell’installazione del modello.

Campionamento e controlli per evitare di perdere eventi

Il filtraggio introduce un problema di misurazione complesso: se un evento non raggiunge mai l’agente, come può il team sapere se avrebbe dovuto farlo? Sift continua a inviare un campione casuale degli eventi che altrimenti tratterrebbe, consentendo di usare i verdetti dell’agente su quel campione per misurare costantemente il tasso di omissione.

La pagina del prodotto chiarisce il riferimento: il richiamo e il tasso di omissione vengono misurati in base alle valutazioni dell’agente. Queste metriche indicano quanto fedelmente Sift riproduce le decisioni dell’agente. Non stabiliscono, di per sé, se l’agente individui correttamente ogni incidente di sicurezza o problema operativo.

Kindo afferma che, se la qualità peggiora, Sift lascia passare gli eventi, reinviandoli all’agente perché li esamini anziché continuare a sopprimerli. L’azienda descrive anche soglie massime di attività che, in caso di picco, possono riportare il sistema alla modalità ombra. Gli eventi filtrati e le decisioni di approvazione vengono registrati, così che i team possano verificare che cosa è stato trattenuto e perché.

«Non filtra nulla finché una persona non approva la soglia e, se la qualità peggiora, lascia passare tutto perché venga valutato da un LLM», ha dichiarato nell’annuncio Troy Presley, ingegnere di Deep Hat Sift presso Kindo.

Questi meccanismi rendono evidente il compromesso, senza eliminarlo. Un filtraggio più prudente può mantenere la copertura, ma consente di risparmiare meno esecuzioni. Un filtraggio più aggressivo può evitare una maggiore quantità di lavoro, ma rende più importanti il campionamento, il rilevamento dei cali di qualità e l’affidabilità dell’agente a valle.

Progettato per avvisi, ticket e flussi continui di registri

Il lancio è rivolto a carichi di lavoro caratterizzati da volumi elevati di dati in ingresso e da una bassa percentuale di elementi che richiedono un intervento. Kindo cita gli avvisi SIEM e di rilevamento degli endpoint, le code dei ticket, le segnalazioni di phishing, i registri di sistema e di rete e i flussi provenienti da piattaforme come Kafka. Tra le fonti di monitoraggio figurano Splunk, Datadog e New Relic.

Sift si colloca a monte dell’agente, senza sostituire questi sistemi di origine. Una piattaforma di sicurezza continua a generare rilevamenti, un sistema di gestione dei ticket continua a gestire la propria coda e l’agente resta responsabile dei casi che lo raggiungono. Il nuovo livello decide quali eventi avviano questo ulteriore lavoro svolto dall’IA.

Lo stesso schema potrebbe applicarsi ai flussi di lavoro finanziari e di conformità normativa che esaminano flussi di transazioni o di policy. Anche in questo caso, selezionare gli eventi da esaminare è diverso dal formulare una valutazione antifrode o di conformità. L’agente destinatario e il processo aziendale circostante restano elementi importanti per il risultato.

Come si integra Sift nella piattaforma di gestione degli agenti di Kindo

La più ampia piattaforma di Kindo collega gli agenti ai sistemi aziendali per la sicurezza, l’infrastruttura e le operazioni IT. Riunisce l’esecuzione con il contesto, le autorizzazioni e la supervisione operativa, offrendo ai team un ambiente in cui gestire il lavoro dopo aver selezionato un modello.

Il sito web dell’azienda descrive la titolarità degli agenti, le politiche di accesso e l’attribuzione dei costi per agente, titolare e team. Sift aggiunge un controllo in una fase precedente del flusso di lavoro: stabilire se un evento debba effettivamente avviare un agente. In questo modo, una decisione tecnica di filtraggio si collega alla questione operativa di quali carichi di lavoro generino costi di inferenza.

Secondo l’annuncio del lancio, Deep Hat Sift è ora disponibile in sede, in un cloud autogestito, nel cloud di Kindo e in ambienti isolati dalle reti esterne. Il calcolo dei punteggi avviene dove è installato Kindo, mentre le chiamate ai modelli sono gestite tramite la piattaforma. Il prodotto funziona con gli agenti Kindo.

I risparmi dipenderanno dal flusso

Kindo non ha fornito una percentuale di risparmio generale né un parametro di accuratezza valido universalmente per Sift. La pagina del prodotto invita invece i team a visualizzare in anteprima il filtraggio dei propri eventi. Per chi valuta l’acquisto, è una distinzione utile: il risultato economico dipende dal volume degli eventi, dal costo di ogni esecuzione evitata, dalla quota di eventi su cui è possibile intervenire e dalla soglia operativa che il team è disposto ad accettare.

Nei flussi rumorosi, evitare esecuzioni non necessarie degli agenti potrebbe rendere più accessibile una revisione continua tramite IA. Nei flussi in cui un evento non rilevato può avere conseguenze gravi, i controlli di campionamento e di escalation diventano importanti quanto il costo dell’inferenza. Deep Hat Sift integra queste decisioni nel flusso di lavoro degli agenti, spostando la domanda centrale da quale modello debba gestire un evento a se quel modello debba gestirlo del tutto.