La tesi di Atlan sulla creazione di valore AI con il contesto aziendale sposta l’attenzione oltre i modelli

Atlan mette in discussione l’approccio model-first all’AI aziendale, sostenendo che anche i sistemi più capaci non dispongono della comprensione del business necessaria per svolgere un lavoro utile. Creare valore AI con il contesto aziendale, tema di un articolo di MIT Technology Review Insights del 28 ottobre, sottopone questa affermazione a esame. La questione è se le organizzazioni abbiano bisogno di un ulteriore livello infrastrutturale, di una migliore gestione delle conoscenze esistenti o di entrambi.

L’argomento arriva in un contesto commerciale tutto suo. L’articolo proviene dalla divisione di contenuti su commissione di MIT Technology Review, non dalla sua redazione giornalistica. I materiali della conferenza di Atlan identificano la ricerca associata come prodotta con l’azienda. Questa relazione conta nella valutazione di una diagnosi che sostiene anche il posizionamento del prodotto del fornitore.

Work IQ di Microsoft offre un confronto utile: un altro fornitore sta organizzando la propria strategia di AI aziendale attorno al contesto di business. La tensione centrale va oltre la concorrenza tra fornitori. Le organizzazioni vogliono un’AI in grado di svolgere lavoro, ma le loro definizioni, autorizzazioni e regole operative richiedono spesso interpretazione umana. Acquistare l’accesso a un modello non risolve queste questioni.

Creare valore AI con il contesto aziendale va oltre il modello

L’analisi sul contesto aziendale del 28 ottobre presenta un noto problema di implementazione attraverso la lente preferita da Atlan. Gli strumenti AI possono rispondere rapidamente pur fraintendendo il business che servono. La cofondatrice di Atlan, Prukalpa Sankar, sostiene che un’infrastruttura di contesto possa contribuire a colmare questa lacuna.

Un livello di contesto è un’infrastruttura che fornisce ai sistemi AI definizioni aziendali, relazioni, policy e altre informazioni necessarie per interpretare i dati dell’impresa. Il concetto è rilevante perché trovare informazioni e comprenderne il significato per il business sono compiti diversi. Un documento può contenere una risposta senza stabilire se tale risposta resti autorevole.

Lo sviluppo rappresenta un argomento commerciale più esplicito sull’origine del valore dell’AI aziendale, non una nuova svolta tecnica verificata.

Questa distinzione mantiene la notizia nelle giuste proporzioni. L’articolo non dimostra che l’infrastruttura di contesto da sola generi migliori rendimenti finanziari. Propone una spiegazione per le implementazioni deludenti e una direzione per affrontarle. Gli acquirenti dovrebbero valutare la spiegazione separatamente da qualsiasi implementazione specifica.

Si consideri un flusso di lavoro commerciale esemplificativo. Un assistente trova una scheda cliente, riassume le conversazioni recenti e redige una raccomandazione di rinnovo. Ogni documento recuperato potrebbe essere accurato singolarmente. La raccomandazione può comunque fallire se l’assistente confonde l’entità di fatturazione con la sua capogruppo o trascura un’eccezione approvata.

Un modello migliore potrebbe riconoscere l’ambiguità e porre una domanda utile. Una definizione aziendale mantenuta potrebbe risolvere l’ambiguità prima che inizi la generazione. Questi approcci si integrano, ma affrontano parti diverse del problema. Trattare ogni errore come un problema del modello oscura questa distinzione.

Creare valore AI con il contesto aziendale cambia quindi la conversazione d’acquisto. Invece di chiedere soltanto quale sistema produca la risposta migliore, gli acquirenti devono chiedersi cosa renda valida una risposta all’interno della loro organizzazione. Ciò include chi ha approvato la regola sottostante e quando è stata modificata l’ultima volta.

Anche il rapporto editoriale merita attenzione. L’evento di ricerca sul contesto di Atlan ha promosso l’accesso anticipato a una ricerca prodotta in associazione con l’azienda. Ciò supporta il trattamento dell’argomento come contributo al dibattito sostenuto dal fornitore. Non giustifica l’archiviazione del problema di fondo.

L’implicazione pratica è più circoscritta dell’ampia narrazione commerciale. Il contesto è una fonte credibile di fallimento dell’AI aziendale, ma la sua importanza deve essere stabilita per ogni flusso di lavoro. Le organizzazioni hanno ancora bisogno di prove che colleghino l’intervento proposto a un miglioramento misurabile. Senza questo collegamento, il contesto diventa un’altra spiegazione difficile da verificare.

I responsabili del business ereditano il problema dell’affidabilità dell’AI

L’argomento del contesto mette sotto pressione sia i responsabili del business sia i team tecnologici. Se un assistente fraintende una policy approvata, cambiare il modello potrebbe aiutare. Se i reparti non concordano sulla policy stessa, l’organizzazione deve risolvere quel disaccordo prima che il software possa applicarla in modo coerente.

L’AI aziendale trasforma una proprietà trascurata della conoscenza in una questione operativa.

Uno sviluppatore AI può collegare un archivio documentale senza avere l’autorità per decidere quale policy prevalga su un’altra. Un team di sicurezza può applicare restrizioni di accesso senza decidere come la finanza definisca un cliente. Queste responsabilità si intersecano, ma non appartengono alla stessa persona.

Ciò crea un onere di implementazione diverso dall’installazione di un’interfaccia conversazionale. Qualcuno deve identificare le fonti autorevoli, assegnare responsabili, documentare le eccezioni e mantenere queste decisioni. Il lavoro può far emergere disaccordi che i dipendenti gestivano in precedenza attraverso conversazioni informali. L’automazione rende più difficile lasciare tali disaccordi irrisolti.

Per i responsabili finanziari, la pressione riguarda la coerenza. Un assistente che risponde a una domanda sui ricavi necessita della definizione contabile appropriata, del periodo di rendicontazione e dell’ambito organizzativo. Una spiegazione fluida non compensa la scelta della misura sbagliata. Il responsabile del business deve rendere disponibile e verificabile l’interpretazione prevista.

Per i responsabili dei servizi, la pressione riguarda l’applicabilità. Un agente, ovvero un sistema AI che seleziona passaggi o usa strumenti per completare un lavoro, necessita delle circostanze rilevanti del cliente. Una policy di rimborso valida può variare in base al contratto o alla regione. Recuperare la policy generale è solo una parte della decisione.

Questi esempi sono illustrativi, non risultati riportati dai clienti. Mostrano perché la responsabilità del contesto diventi rilevante quando il software passa dalla redazione di testi alla raccomandazione di azioni. Un riepilogo errato crea lavoro di correzione. Un’azione errata può anche creare un obbligo che un altro team deve annullare.

I team di procurement affrontano una sfida correlata. Una piattaforma di contesto può promettere definizioni comuni, ma il contratto non può garantire che i reparti concordino su di esse. Gli acquirenti devono distinguere le responsabilità del fornitore da quelle organizzative. Altrimenti, un acquisto infrastrutturale può nascondere una decisione operativa non conclusa.

I knowledge worker affrontano lo stesso problema su scala minore. Un archivio ricercabile aiuta le persone a localizzare il materiale, mentre una base di conoscenza autorevole stabilisce quale materiale debba guidare il lavoro. La distinzione tra conoscenza personale e di team diventa rilevante quando il ricordo individuale alimenta decisioni condivise.

La risposta a breve termine dovrebbe seguire il problema affrontato. La mancanza di materiale di origine richiede una migliore copertura. Definizioni in conflitto richiedono proprietà e risoluzione. Ragionamenti errati richiedono modifiche al modello o all’applicazione. Riunire queste categorie in un unico punteggio di accuratezza può nascondere dove sia necessario intervenire.

Nel tempo, la pressione si sposta verso la manutenzione. Il contesto di business cambia quando cambiano prodotti, contratti, team e policy. Un’implementazione che funziona bene al lancio può diventare inaffidabile senza alcun aggiornamento del modello. L’argomento del contesto è quindi anche un’affermazione sulla responsabilità operativa continuativa.

Microsoft mostra perché il contesto sta diventando una questione di piattaforma

Microsoft offre un confronto concreto perché descrive anch’essa il contesto aziendale come infrastruttura condivisa. Nel suo resoconto dell’11 giugno sull’uso interno di Work IQ, l’azienda spiega come le informazioni organizzative supportino risposte AI più pertinenti. Presenta il contesto come parte dell’ambiente che circonda gli assistenti.

Microsoft afferma che Work IQ attinge ai segnali del luogo di lavoro e rispetta le autorizzazioni esistenti. I suoi esempi interni includono il collegamento delle informazioni sulle riunioni con i partecipanti e l’applicazione delle circostanze dei dipendenti alle indicazioni fornite. Si tratta di esempi riportati dall’azienda, non di misurazioni indipendenti dei rendimenti aziendali. Ciononostante, mostrano un fornitore che affronta lo stesso problema generale.

La questione competitiva è dove debba risiedere la comprensione del business e quanto ampiamente possa essere riutilizzata.

L’approccio all’intelligence del workplace di Microsoft descrive un contesto che si sviluppa nel suo ambiente di lavoro. L’argomento di Atlan si concentra sulla fornitura di comprensione del business tra sistemi diversi. Queste posizioni generano domande differenti per gli acquirenti, anche quando entrambi i fornitori usano un linguaggio simile.

Per un’organizzazione concentrata in un particolare ambiente software, il contesto incorporato può offrire un punto di partenza naturale. Documenti, identità e registri di collaborazione esistenti sono già nelle vicinanze. L’acquirente deve comunque stabilire quali fonti siano coperte e se l’interpretazione risultante si applichi oltre tale ambiente.

Per un’organizzazione che utilizza diversi sistemi aziendali, il riuso diventa più importante. Una definizione mantenuta per un assistente finanziario non dovrebbe divergere silenziosamente da quella usata da un assistente operativo. Il contesto condiviso promette di ridurre questa duplicazione. Il suo successo dipende dai dettagli dell’integrazione e della governance.

Non si tratta di una semplice competizione tra architettura centralizzata e distribuita. Un’architettura è la disposizione dei componenti e delle loro responsabilità. Un servizio centrale può distribuire definizioni obsolete, mentre un contesto specifico dell’applicazione può restare accurato in un ambito limitato. La collocazione da sola non determina la qualità.

Il confronto più utile riguarda il cambiamento. Quando una definizione cambia, quali applicazioni ricevono l’aggiornamento? Quando l’accesso viene revocato, quali rappresentazioni archiviate smettono di esporre le informazioni? Quando una risposta viene contestata, i revisori possono ricostruire la fonte e la regola usate? Queste domande collegano la progettazione della piattaforma alle conseguenze operative.

Anche la portabilità merita attenzione. Gli acquirenti dovrebbero chiedere se le definizioni approvate possano passare tra strumenti senza perdere proprietà, cronologia delle versioni o restrizioni di accesso. Esportare il testo è più facile che preservarne l’autorità. Una migrazione che conserva le parole ma perde l’applicabilità può ricreare il problema originario.

Il confronto tra fornitori supporta quindi un giudizio più ampio senza dimostrare che l’approccio di uno dei due sia superiore. Il contesto sta diventando una responsabilità di piattaforma perché più applicazioni necessitano della stessa comprensione del business. Ciò crea un’opportunità per un’infrastruttura condivisa, insieme al rischio che molte applicazioni dipendano da un errore comune.

Per gli acquirenti, la risposta utile è esaminare un flusso di lavoro che attraversi un effettivo confine organizzativo. Una dimostrazione confinata a una raccolta ordinata di documenti lascia senza risposta la questione centrale. La prova rilevante è se il contesto resti coerente quando le informazioni passano tra reparti, applicazioni e responsabili delle decisioni.

Le prove sul recupero delle informazioni sostengono un’affermazione più circoscritta

La generazione aumentata dal recupero, o RAG, recupera informazioni pertinenti e le fornisce a un modello prima che risponda. È un metodo consolidato per collegare le risposte generate alla conoscenza esterna. I suoi limiti aiutano a spiegare perché l’argomento del contesto aziendale attira attenzione.

La ricerca di Anthropic del settembre 2024 offre un esempio tecnico. Il suo metodo Contextual Retrieval aggiunge informazioni esplicative ai frammenti di documenti prima dell’indicizzazione. L’obiettivo è preservare il significato che può andare perso quando un passaggio viene separato dal documento originale.

Anthropic ha segnalato una riduzione del 49% dei fallimenti di recupero combinando le sue tecniche contestuali e una riduzione del 67% aggiungendo il reranking. Il reranking è una seconda fase di selezione che riordina il materiale recuperato in base alla rilevanza. Si trattava di risultati delle valutazioni dell’azienda, non di misurazioni dei rendimenti finanziari aziendali.

Un recupero migliore sostiene l’argomento del contesto, ma non dimostra che sia necessaria una piattaforma completa di contesto aziendale.

La ricerca sul recupero contestuale affronta un fallimento specifico: un sistema non individua informazioni pertinenti perché un frammento non dispone del significato circostante. È un problema più circoscritto rispetto alla risoluzione di politiche aziendali in conflitto. È inoltre più circoscritto rispetto alla determinazione dell’autorità di un utente per eseguire un’azione.

La distinzione conta nelle decisioni di acquisto. Se un assistente di supporto non trova risposte perché i frammenti dei documenti non contengono dettagli identificativi, vale la pena esaminare modifiche al recupero. Se individua il passaggio corretto ma lo applica in modo errato, il fallimento avviene altrove. Una proposta infrastrutturale ampia dovrebbe spiegare quale fallimento affronta.

Un esempio contrattuale illustrativo rende più chiara la separazione. Un passaggio afferma che un cliente ha diritto a un’eccezione, ma il nome del cliente compare in una pagina precedente. Preservare tale relazione può migliorare il recupero. Stabilire se l’eccezione sia ancora valida richiede ulteriori informazioni su date, modifiche e autorità.

Un sistema può quindi recuperare le informazioni con precisione e produrre comunque una raccomandazione aziendale errata. Al contrario, un flusso di lavoro con fonti ristrette e mantenute può funzionare adeguatamente senza un esteso servizio di contesto condiviso. L’intervento appropriato dipende dal compito reale, dai suoi requisiti informativi e dalle conseguenze dei suoi errori.

La creazione di valore dell’AI tramite il contesto aziendale dovrebbe essere valutata attraverso questa catena di dipendenze. La copertura delle fonti influenza ciò che il sistema può trovare. L’interpretazione delle fonti influenza ciò che comprende. Le regole decisionali influenzano ciò che raccomanda. I controlli sulle azioni influenzano ciò che può eseguire. Un miglioramento in una parte non dimostra automaticamente un miglioramento dell’intero sistema.

Questo ragionamento cambia anche il modo in cui dovrebbero essere interpretate le dimostrazioni. Una risposta riuscita dimostra che una particolare configurazione ha gestito una particolare domanda in determinate condizioni. Non dimostra affidabilità generale tra i vari reparti. Gli acquirenti hanno bisogno di prove che includano input ambigui, politiche modificate e fonti in conflitto.

Il caso tecnico più solido identificherà il fallimento originario, l’intervento sul contesto e la differenza risultante. Mantenere comparabili il modello e il compito aiuta a isolare ciò che è cambiato. Riportare separatamente il successo del recupero e l’accuratezza decisionale rende il risultato più facile da interpretare e impedisce che un vantaggio ristretto diventi un’affermazione più ampia.

Più contesto può diffondere più lontano la risposta sbagliata

La tesi scettica parte da un problema semplice: il contesto aziendale può essere errato. Una definizione condivisa potrebbe essere obsoleta, incompleta o contestata. Fornirla in modo coerente può rendere concordi gli output lasciandoli comunque errati. L’accordo è una prova utile di coerenza, ma non è una prova sufficiente di verità.

Un livello di contesto può distribuire l’autorità senza dimostrare che tale autorità sia giustificata.

Questo conta quando le organizzazioni trasformano conoscenze informali in regole mantenute. I dipendenti esperti talvolta sanno quando un processo documentato non si adatta a una situazione. Codificare tale giudizio richiede di decidere quali eccezioni siano legittime. Estrarre automaticamente un’affermazione da una conversazione non risolve la questione se debba diventare una politica.

Un partecipante a una riunione potrebbe descrivere una soluzione temporanea. Un altro dipendente potrebbe ripetere una pratica obsoleta. Un documento di progetto potrebbe registrare una proposta abbandonata. Ogni fonte contribuisce con informazioni, ma ciascuna comporta un diverso grado di autorità. Trattarle come equivalenti crea un problema di governance prima ancora che inizi la generazione.

Esiste anche un limite a livello di modello. Il profilo di rischio dell’AI generativa del NIST descrive la confabulazione, ovvero contenuti falsi o erronei generati con sicurezza, come un rischio caratteristico. Rileva inoltre che spiegazioni e citazioni generate possono fuorviare gli utenti. Il materiale di origine pertinente non elimina la necessità di valutare gli output.

L’analisi del NIST sostiene un’interpretazione prudente della tesi del contesto. Informazioni migliori possono affrontare conoscenze mancanti senza garantire un ragionamento corretto. Un sistema potrebbe applicare erroneamente una regola valida o sovrastimare un’inferenza incerta. La qualità del contesto e l’affidabilità dell’output richiedono un esame correlato ma distinto.

Le autorizzazioni creano un ulteriore punto critico. La capacità di un dipendente di leggere un documento non autorizza necessariamente un sistema automatizzato ad agire sul suo contenuto. Un servizio di contesto necessita di una relazione chiara con i controlli che governano le azioni a valle. Altrimenti, informazioni accurate possono sostenere una decisione non autorizzata.

Anche il caso finanziario resta incerto. Mantenere definizioni, risolvere controversie, verificare autorizzazioni e riesaminare i fallimenti richiede tempo del personale. Parte di questo lavoro può migliorare processi esistenti oltre l’AI. Gli acquirenti dovrebbero comunque considerarlo nel valutare l’economia dell’implementazione.

Un’organizzazione potrebbe ottenere risposte migliori aumentando al contempo il lavoro totale necessario per produrle. Un’altra potrebbe ridurre lo sforzo di revisione abbastanza da giustificare una manutenzione significativa. Il confronto significativo comprende l’intero flusso di lavoro, anziché la velocità visibile della generazione. Questo è un requisito analitico, non un risultato riportato nell’articolo di origine.

La creazione di valore dell’AI tramite il contesto aziendale richiede anche l’accettazione dei limiti. Quando un conflitto di policy rimane irrisolto, un assistente utile dovrebbe esporre il conflitto. Quando l’autorità non è chiara, dovrebbe indirizzare la decisione in modo appropriato. Un sistema che produce sempre una risposta sicura può nascondere proprio l’incertezza organizzativa che l’infrastruttura di contesto dovrebbe rivelare.

La posizione scettica non richiede quindi di rifiutare gli investimenti nel contesto. Richiede un’affermazione più specifica su ciò che l’investimento modifica. Un fornitore dovrebbe identificare quali errori diventano meno frequenti, quali responsabilità restano al cliente e quali modalità di fallimento persistono. Questo rende la proposta verificabile.

Le prossime prove dovrebbero collegare il contesto al lavoro completato

Nei prossimi mesi, i segnali più utili riguarderanno le prove di implementazione piuttosto che nuovo vocabolario. La discussione di ottobre stabilisce una proposizione chiara: la comprensione del business merita maggiore attenzione accanto alle capacità dei modelli. Il passo successivo consiste nel determinare dove tale proposizione produca benefici misurabili.

La tesi del contesto diventa più forte quando una conoscenza aziendale mantenuta migliora il lavoro completato in condizioni mutevoli.

Il primo segnale è un confronto documentato all’interno di un flusso di lavoro reale. Gli acquirenti dovrebbero cercare risultati che mostrino cosa è accaduto prima e dopo un intervento contestuale definito. Il confronto dovrebbe includere errori nelle fonti, errori decisionali, correzioni umane e attività completate. Un risultato che isoli il miglioramento rafforzerebbe l’argomento.

Una dimostrazione che offrisse solo risposte di successo selezionate lascerebbe intatta l’incertezza centrale. Lo stesso varrebbe per un confronto che modificasse contemporaneamente il modello, l’interfaccia, la raccolta delle fonti e il processo di revisione. Tali modifiche potrebbero migliorare il prodotto, ma renderebbero difficile separare il contributo del contesto aziendale.

Il segnale successivo è un comportamento affidabile dopo un cambiamento aziendale. Una policy rivista, un’autorizzazione revocata o un cliente rinominato creano un utile punto di osservazione. Il sistema adotta il cambiamento in tutte le applicazioni interessate? Conserva abbastanza cronologia da spiegare le risposte precedenti? Un comportamento coerente sosterrebbe il caso di un’infrastruttura condivisa.

Contraddizioni persistenti indebolirebbero tale argomento. Se ogni applicazione necessita ancora di riparazioni manuali, il livello comune proposto non ha eliminato la manutenzione duplicata. Se informazioni obsolete sopravvivono negli archivi derivati, l’organizzazione deve comprendere come si propagano le correzioni. La qualità della configurazione iniziale non può rispondere a queste domande.

Il segnale finale è l’onere operativo totale. Le organizzazioni dovrebbero esaminare se i revisori spendano meno tempo a correggere gli output dopo aver considerato la manutenzione del contesto. Dovrebbero inoltre monitorare se i casi irrisolti raggiungano le persone giuste. Una riduzione del lavoro di revisione visibile significa poco se il lavoro nascosto di preparazione cresce più rapidamente.

Questi segnali non dipendono dalla vittoria di un particolare fornitore. Microsoft, Atlan e gli sviluppatori di applicazioni possono contribuire con prove attraverso approcci diversi. La distinzione utile è tra affermazioni sulle capacità disponibili e osservazioni sull’uso sostenuto. Gli acquirenti hanno bisogno di entrambe, ma non dovrebbero confonderle.

Per i knowledge worker, la rilevanza immediata è pratica. Un assistente che sa dove risiedono le informazioni può far risparmiare tempo nella ricerca. Un assistente che comprende quali informazioni si applicano può sostenere una decisione. Il valore di questa comprensione aggiuntiva dipende dalla possibilità per gli utenti di ispezionarla, contestarla e mantenerla.

Partite da un flusso di lavoro in cui una risposta errata genera rilavorazioni identificabili. Esaminate i fallimenti con le persone responsabili della policy sottostante, anziché trattare ogni correzione come un problema di prompting. Separate le informazioni mancanti dalle definizioni in conflitto, dagli errori di ragionamento e dalle azioni inappropriate. Quindi valutate se l’investimento di contesto proposto affronti quei fallimenti specifici. Per il lavoro individuale, un sistema di conoscenza personale mantenuto può aiutare a organizzare il materiale pertinente, mentre le decisioni condivise richiedono comunque un’autorità condivisa. La creazione di valore dell’AI tramite il contesto aziendale diventa una proposizione credibile quando questa distinzione resiste all’implementazione. Chiedete al prossimo fornitore di mostrare come il suo sistema gestisca una regola modificata, una fonte contestata e una decisione che dovrebbe lasciare irrisolta.