IBM e OpenAI puntano a un'implementazione sicura dell'AI per governi e imprese

IBM ha ampliato la sua partnership con OpenAI, dando nuovo peso a un titolo di Google News mentre le imprese affrontano un ostinato divario tra accesso all'AI e implementazione sicura. Le aziende puntano ai settori governativo, finanziario, delle telecomunicazioni e del retail, dove sistemi legacy e requisiti di conformità spesso bloccano progetti pilota promettenti.

Secondo quanto riportato, l'accordo porta modelli e prodotti OpenAI, inclusi ChatGPT Work e Codex, nella piattaforma di consulenza IBM e nelle attività di delivery per i clienti. IBM prevede inoltre una practice dedicata, composta da migliaia di consulenti e ingegneri formati attraverso l'OpenAI Partner Network.

Questa scala è importante perché la partnership non è semplicemente un altro accordo di distribuzione dei modelli. IBM scommette sul fatto che i suoi consulenti, i sistemi di governance e l'infrastruttura ibrida possano trasformare le capacità di OpenAI in processi aziendali controllati. La forza contraria è la realtà operativa: dati frammentati, software datato, controlli normativi e ritorni incerti.

Microsoft, Google Cloud, Accenture, Capgemini e altri fornitori di servizi inseguono la stessa opportunità. La loro competizione si sta spostando dall'accesso ai modelli verso la capacità di implementazione, la profondità dell'integrazione e la prova che l'AI possa funzionare anche al di fuori di una dimostrazione.

Cosa stanno effettivamente costruendo IBM e OpenAI

L'accordo assegna a IBM un ruolo più ampio nella delivery, ma non garantisce che i clienti passino dai progetti pilota alla produzione.

La partnership si concentra su tre aree. La prima è l'implementazione dell'AI nelle funzioni aziendali centrali, tra cui finanza, approvvigionamenti, servizio clienti e risorse umane. Questi flussi di lavoro contengono dati rilevanti e di norma si collegano a diversi sistemi esistenti.

La seconda area riguarda la modernizzazione delle applicazioni e lo sviluppo software. I consulenti IBM intendono combinare Codex e ChatGPT Work con l'esperienza settoriale dell'azienda e la sua piattaforma di delivery. Questa combinazione punta ad applicazioni datate la cui logica di business resta preziosa, ma la cui manutenzione crea rischi crescenti.

La terza area copre la cybersecurity e la gestione dei rischi dell'AI. IBM partecipa già all'OpenAI Daybreak Cyber Partner Program, che applica modelli frontier al lavoro di sicurezza difensiva. Il rapporto ampliato collega questo impegno ai servizi di consulenza e governance di IBM.

Si prevede inoltre che IBM entri nel livello Elite dell'OpenAI Partner Network. La sua practice dedicata includerà consulenti e ingegneri impegnati nel conseguimento di certificazioni avanzate nella tecnologia OpenAI. Nessuna delle due aziende ha divulgato pubblicamente i termini finanziari dell'accordo.

Secondo un resoconto dettagliato dell'accordo enterprise, le aziende intendono concentrarsi inizialmente sui servizi finanziari, il settore pubblico, le telecomunicazioni e il retail. Questi settori offrono carichi di lavoro interessanti, ma impongono anche requisiti rigorosi in materia di accesso, conservazione, auditabilità e continuità.

Il ruolo di IBM è quindi più articolato della semplice rivendita dell'accesso ai modelli. I suoi consulenti devono mappare i processi aziendali, collegare dati protetti, stabilire autorizzazioni, testare gli output e preparare i dipendenti a flussi di lavoro modificati. Queste attività determinano se un sistema AI diventa operativo oppure rimane un assistente isolato.

L'approccio riflette anche il modo in cui OpenAI sta ampliando la propria presenza nell'impresa. Il suo Partner Network è stato creato per aiutare le organizzazioni a riprogettare i flussi di lavoro, integrare i sistemi esistenti e gestire l'adozione. OpenAI ha dichiarato che investirà 150 milioni di dollari nella rete e punterà a 300.000 consulenti certificati entro la fine del 2026.

Questi dati relativi all'intera rete non misurano l'impegno specifico di IBM. Mostrano la strategia più ampia alla base dell'accordo. OpenAI vuole che i partner di implementazione portino i suoi prodotti più in profondità nelle organizzazioni che non possono ricostruire il proprio parco tecnologico attorno a un unico fornitore.

La proposta risultante è semplice. OpenAI fornisce modelli e prodotti agentici, mentre IBM fornisce integrazione, governance, cybersecurity e delivery settoriale. La questione irrisolta è se questa divisione del lavoro produca risultati ripetibili presso clienti complessi.

Un lettore di Google News può vedere l'annuncio di una partnership. Gli acquirenti enterprise dovrebbero vedere un test di delivery che coinvolge due punti di forza molto diversi.

Perché l'attenzione di Google News si sta spostando verso l'implementazione

La capacità dei modelli resta importante, ma la competizione enterprise dipende ora da chi riesce a inserire tale capacità in flussi di lavoro governati e misurabili.

Molte organizzazioni hanno già accesso a modelli avanzati. L'accesso da solo non risolve la gestione delle identità, la classificazione dei dati, le dipendenze software, i controlli sugli approvvigionamenti o la responsabilità dei dipendenti. Questi vincoli diventano più importanti quando un agente può compiere azioni anziché limitarsi a generare testo.

Un agente AI è un software che può pianificare attività, usare strumenti ed eseguire azioni autorizzate con una guida umana limitata. In un'organizzazione regolamentata, ogni parte di questa definizione solleva una questione di governance.

Quali dati può recuperare l'agente? Quali sistemi può modificare? Chi approva le sue azioni? Per quanto tempo i suoi record devono restare disponibili? Cosa accade quando produce un risultato plausibile ma errato?

La posizione di IBM è che queste domande sull'implementazione richiedano una combinazione di controlli software e competenza umana. Andy Baldwin, senior executive di IBM Consulting, ha descritto la sfida come un'integrazione sicura su larga scala in ambienti e flussi di lavoro complessi.

Questa argomentazione è in linea con la strategia dei partner di OpenAI. OpenAI ha affermato che il vincolo enterprise non è più soltanto la capacità dei modelli. Le organizzazioni devono anche individuare casi d'uso utili, riprogettare i processi, integrare sistemi e gestire l'adozione.

I clienti governativi rendono questo cambiamento particolarmente evidente. Un assistente di redazione usato su informazioni pubbliche presenta un profilo di rischio. Un agente che opera su registri delle prestazioni, decisioni di approvvigionamento, analisi di intelligence o infrastrutture critiche ne presenta un altro.

OpenAI ha perseguito l'adozione nel settore pubblico tramite ChatGPT Enterprise, ChatGPT Gov e il suo programma più ampio per il settore pubblico. La sua iniziativa governativa pone l'accento su ambienti sicuri e flussi di lavoro sensibili, inclusi ricerca, analisi, logistica e sicurezza nazionale.

L'implementazione governativa dipende anche da autorizzazioni formali. OpenAI ha annunciato che ChatGPT Enterprise e la sua API Platform hanno ricevuto l'autorizzazione FedRAMP Moderate nel 2026. FedRAMP offre un processo federale standardizzato per valutare e monitorare la sicurezza del cloud.

L'autorizzazione riduce una barriera, ma non certifica ogni flusso di lavoro di un'agenzia. Ogni implementazione richiede comunque decisioni su dati, confini dei sistemi, uso accettabile, record, revisione umana e rischio missione.

IBM porta esperienza nell'operare entro questi vincoli. La sua attività nel cloud ibrido serve organizzazioni che mantengono sistemi importanti in data center privati, cloud controllati e ambienti mainframe. Questi clienti raramente spostano ogni carico di lavoro su un'unica piattaforma pubblica.

Questo crea la ragione centrale per cui la partnership conta. OpenAI ottiene accesso alle relazioni di delivery di IBM e alla sua esperienza nei settori regolamentati. IBM ottiene un percorso diretto verso modelli e prodotti che molti clienti desiderano già valutare.

L'accordo esercita inoltre pressione su altri fornitori di consulenza e cloud. Accenture, Capgemini, BCG e McKinsey hanno relazioni con OpenAI. Google Cloud e Microsoft mantengono propri modelli, piattaforme, prodotti di sicurezza ed ecosistemi di consulenza.

I clienti non stanno scegliendo tra AI e assenza di AI. Stanno scegliendo quale combinazione di modelli, infrastruttura, consulenti e sistemi di controllo debba mediare il lavoro importante.

Questa competizione favorisce i fornitori con un'ampia capacità di integrazione. Crea anche un rischio di dipendenza concentrata se una partnership diventa incorporata in troppe funzioni aziendali.

Un titolo di Google News non può rispondere alla domanda se il metodo di IBM supererà le strade concorrenti. Mostra però dove si è spostata la competizione: dalle dimostrazioni dei modelli al controllo operativo.

La vera sfida è la scala sicura contro la complessità enterprise

IBM e OpenAI promettono una scala controllata, mentre i sistemi che devono modificare sono stati costruiti per resistere a cambiamenti improvvisi.

Le grandi organizzazioni accumulano tecnologia invece di sostituirla in modo netto. Un singolo flusso di lavoro può attraversare un'applicazione mainframe, un database cloud, un provider di identità, diversi fogli di calcolo e il giudizio non documentato di un dipendente.

L'aggiunta di un agente AI non elimina queste dipendenze. Può creare un ulteriore livello che richiede test, monitoraggio e manutenzione.

La modernizzazione delle applicazioni illustra questa tensione. Codex può aiutare ad analizzare repository, proporre modifiche, scrivere test e spiegare codice poco familiare. Tuttavia, la generazione di codice rappresenta solo una parte della modernizzazione di un sistema critico.

I team devono individuare dipendenze nascoste, confermare le regole di business, proteggere i dati, convalidare le prestazioni e pianificare procedure di rollback. Devono inoltre stabilire se le modifiche generate preservino requisiti legali e operativi che non sono mai comparsi nella documentazione formale.

I consulenti IBM possono apportare contesto settoriale a questo lavoro. La piattaforma di delivery dell'azienda può anche offrire metodi e agenti riutilizzabili. Tuttavia, nessuna piattaforma generale comprende automaticamente l'architettura o la storia istituzionale di ogni cliente.

Lo stesso problema emerge nelle operazioni aziendali. Un agente per gli approvvigionamenti può riassumere contratti o confrontare informazioni sui fornitori. Consentirgli di modificare ordini o approvare eccezioni richiede autorizzazioni, evidenze e supervisione più robuste.

Il servizio clienti offre un altro esempio. Un modello può redigere risposte e recuperare informazioni sugli account. Deve comunque rispettare le regole di divulgazione, le preferenze dei clienti e inoltrare i casi che richiedono giudizio umano.

I servizi finanziari alzano ulteriormente la posta. Un agente a supporto della conformità o dell'analisi del rischio deve lavorare con fonti tracciabili. Le sue raccomandazioni necessitano di una chiara attribuzione di responsabilità, soprattutto quando gli output influenzano concessioni di credito, trading, indagini sulle frodi o rendicontazione normativa.

I flussi di lavoro governativi aggiungono responsabilità pubblica. Le agenzie devono considerare obblighi di conservazione dei record, giusto processo, accessibilità, regole di approvvigionamento e la possibilità che l'assistenza automatizzata incida sui cittadini in modo diseguale.

Questi requisiti spiegano l'attenzione di IBM per la governance. Per governance si intendono le politiche, i controlli tecnici, le valutazioni e i processi di responsabilità che definiscono il funzionamento di un sistema AI. Non è un documento preparato dopo l'implementazione.

Una governance efficace inizia con un compito circoscritto e un responsabile identificato. I team definiscono quindi i dati consentiti, gli output attesi, i comportamenti inaccettabili, le procedure di revisione e criteri di successo misurabili.

Questo lavoro può essere tedioso. È anche il punto in cui una partnership conquista fiducia oppure produce software costoso che i dipendenti evitano.

IBM e OpenAI hanno già testato una versione più circoscritta della loro relazione nella cybersecurity. IBM è entrata nell'OpenAI Daybreak Cyber Partner Program nel giugno 2026 e ha introdotto un servizio di sicurezza applicativa che utilizza le capacità dei modelli OpenAI.

Il servizio di cybersecurity valuta il codice delle applicazioni e assegna priorità alle aree che potrebbero contenere vulnerabilità o percorsi sfruttabili. IBM afferma che il servizio opera con accesso in sola lettura ai repository ed esecuzione limitata all'interno di un ambiente cliente controllato.

L'esecuzione limitata restringe ciò a cui un sistema guidato da modelli può accedere o le azioni che può compiere. Questa progettazione riduce l'esposizione quando il modello analizza codice sensibile, anche se non elimina gli errori o le vulnerabilità non rilevate.

IBM offre il servizio attraverso valutazioni mirate che possono estendersi al monitoraggio continuo. Questa progressione crea un modello di implementazione utile: iniziare con un ambito limitato, raccogliere evidenze, quindi ampliare l'accesso solo dopo che i controlli si sono dimostrati efficaci.

Il modello è meno eclatante di un annuncio di trasformazione su vasta scala. È anche più credibile per i clienti regolamentati.

I lettori che seguono la vicenda tramite Google News dovrebbero quindi distinguere la portata della partnership dalle sue evidenze. Le aziende hanno descritto un ampio campo di lavoro. Il loro più solido dettaglio pubblico di implementazione continua a provenire da un servizio di cybersecurity a esecuzione limitata.

I controlli di sicurezza non eliminano il rischio dei modelli

La partnership può migliorare la supervisione, ma né la portata della consulenza né l'autorizzazione formale rendono il comportamento dei modelli completamente prevedibile.

I modelli generativi possono produrre affermazioni errate, codice non sicuro, sintesi fuorvianti e decisioni incoerenti. Questi fallimenti diventano più rilevanti quando un sistema opera su dati sensibili o compie azioni tramite strumenti connessi.

Un'architettura controllata può ridurne l'impatto. L'accesso in sola lettura impedisce alcune modifiche non autorizzate. I confini delle autorizzazioni limitano i sistemi disponibili. La registrazione consente indagini successive. L'approvazione umana può fermare azioni ad alto rischio.

Ogni controllo comporta anche costi operativi. I dipendenti devono revisionare gli output, i team di sicurezza devono esaminare i log e i proprietari dei sistemi devono mantenere le integrazioni. Se questi costi si avvicinano allo sforzo risparmiato, l'adozione può rallentare.

C'è anche un problema di misurazione. Un progetto pilota può dimostrare che un agente completa le attività più rapidamente. Questo risultato non rivela se l'organizzazione abbia sperimentato più rilavorazioni, errori sottili, esposizione alla sicurezza o confusione tra i dipendenti.

Una valutazione utile deve confrontare il flusso di lavoro completo. I team devono misurare l'accuratezza delle attività, il tempo di completamento, i tassi di eccezione, lo sforzo dei revisori, l'adozione da parte degli utenti e gli incidenti. Devono anche disporre di una baseline del processo precedente.

I clienti governativi e regolamentati affrontano un'altra preoccupazione: le modifiche ai modelli. Un fornitore può aggiornare un modello ospitato, modificare le salvaguardie o ritirare una versione. I clienti hanno quindi bisogno di procedure per ripetere i test dei flussi di lavoro il cui comportamento dipende da quel modello.

La storia multivendor di IBM può essere d'aiuto in questo caso. L'azienda ha promosso architetture che consentono ai clienti di utilizzare i modelli IBM Granite insieme a opzioni di terze parti. Questo approccio può preservare la possibilità di scelta, ma la portabilità rimane difficile.

Prompt, strumenti, filtri di sicurezza, gestione del contesto e comportamento degli output variano tra le famiglie di modelli. Spostare un'applicazione da un modello a un altro può richiedere test e riprogettazioni sostanziali.

L'accordo IBM crea quindi una tensione strategica nella posizione stessa di IBM. L'azienda promuove architetture aperte e flessibili mentre costruisce una grande attività attorno a uno dei principali fornitori di modelli proprietari.

Questa tensione non rende contraddittoria la partnership. I clienti spesso desiderano sia l'accesso a un modello preferito sia la capacità di evitare una dipendenza totale. IBM deve dimostrare che la sua attività OpenAI preserva una scelta architetturale significativa.

OpenAI affronta una sfida correlata. Vuole che i partner accelerino l'adozione, ma la qualità dell'implementazione incide sulla fiducia nei suoi prodotti. Un'implementazione governata in modo inadeguato può danneggiare il fornitore del modello anche quando un integratore ha compiuto le scelte progettuali decisive.

Anche le dichiarazioni sulla sicurezza meritano una formulazione attenta. IBM afferma che il suo servizio correlato a Daybreak può identificare e convalidare vulnerabilità con maggiore velocità e precisione. Il materiale pubblico non dimostra prestazioni universali su diverse basi di codice o classi di attacco.

Gli acquirenti dovrebbero chiedere quali convalide siano avvenute su sistemi simili ai propri. Dovrebbero anche chiedere come siano stati misurati falsi positivi, risultati mancati, patch generate e carico di lavoro dei revisori.

Gli standard indipendenti offrono un quadro utile. Il framework per il rischio dell'AI del National Institute of Standards and Technology organizza il lavoro sui rischi attorno a governance, mappatura, misurazione e gestione.

Un framework non approva un prodotto. Offre agli acquirenti un modo coerente per mettere in discussione un'implementazione proposta.

Quali rischi sono stati mappati prima del lancio? Quale comportamento è stato misurato? Chi può sospendere il sistema? Come vengono segnalati gli incidenti? Quali evidenze supportano l'espansione a un altro flusso di lavoro?

Queste domande contano più di ampie rassicurazioni sulla sicurezza di livello enterprise. Rivelano anche la differenza tra controlli che esistono sulla carta e controlli che funzionano sotto pressione reale.

Le organizzazioni dovrebbero mantenere i propri registri di implementazione, note di valutazione e decisioni di policy. Una base di conoscenza tecnica ricercabile può aiutare i team a conservare il motivo per cui un'integrazione è cambiata e chi l'ha approvata.

Questo archivio istituzionale diventa importante quando cambia il personale, viene aggiornata una versione del modello o un revisore mette in discussione una decisione mesi dopo.

La visione scettica, quindi, non è che IBM e OpenAI manchino di capacità utili. È che le ampie affermazioni sull'implementazione restano in anticipo rispetto ai risultati verificati in modo indipendente.

L'attività OpenAI di IBM entra in una corsa enterprise affollata

IBM dispone di vantaggi riconoscibili nei sistemi ibridi e nella consulenza, ma i concorrenti offrono già percorsi alternativi verso gli stessi clienti.

Accenture ha ampliato il proprio lavoro con OpenAI, inclusa una partnership federale focalizzata su un'implementazione sicura. BCG, McKinsey e Capgemini partecipano alle Frontier Alliances di OpenAI per la trasformazione enterprise.

Queste società competono direttamente con IBM per il lavoro su strategia, integrazione e gestione del cambiamento. Il loro successo dipenderà in parte dall'esperienza settoriale e in parte dalla capacità di trasformare asset AI riutilizzabili in minori costi di delivery.

Microsoft rappresenta un avversario diverso. Combina infrastruttura Azure, software enterprise, prodotti di sicurezza, GitHub e una relazione di lunga data con OpenAI. Molte organizzazioni possono aggiungere l'AI attraverso sistemi che già concedono in licenza e gestiscono.

Google Cloud offre un altro percorso integrato tramite Gemini, la sua piattaforma dati, i prodotti di cybersecurity e i partner di consulenza. IBM stessa ha annunciato una practice Google Cloud per il governo e le industrie regolamentate nel giugno 2026.

Questo accordo precedente è importante perché dimostra che IBM non sta abbandonando un modello multivendor. Sta costruendo practice attorno a diversi grandi fornitori di AI, posizionando al contempo i propri consulenti come livello di integrazione.

La strategia può attrarre clienti che non vogliono una sola famiglia di modelli per ogni attività. Una banca potrebbe usare un modello per il lavoro software, un altro per l'analisi dei documenti e un modello più piccolo per un flusso di lavoro interno controllato.

Tuttavia, più fornitori di modelli creano anche un sovraccarico di gestione. I team devono confrontare le prestazioni, stabilire contratti separati, monitorare le modifiche di versione e applicare policy coerenti tra piattaforme diverse.

IBM deve dimostrare che i suoi strumenti di governance e delivery semplificano questa complessità. Altrimenti, una promessa multivendor può diventare un ulteriore livello di spesa per software e consulenza.

L'azienda compete anche con i team di ingegneria interni dei clienti. Alcune organizzazioni preferiranno costruire internamente gateway per modelli, sistemi di valutazione e piattaforme per agenti. Potrebbero assumere consulenti solo per migrazioni specifiche o revisioni di sicurezza.

Lo sviluppo interno offre maggiore controllo, ma richiede competenze scarse e manutenzione continua. L'implementazione guidata dalla consulenza offre un accesso più rapido alle competenze, ma può creare dipendenza da team esterni.

L'espansione della rete di partner di OpenAI aumenta questa possibilità di scelta. La rete offre ai clienti più potenziali percorsi di implementazione, rendendo al contempo più difficile la differenziazione per ciascun partner.

La distinzione di IBM deve quindi derivare dall'esecuzione in ambienti difficili. Ciò include mainframe, cloud ibridi, dati regolamentati, sistemi di identità frammentati e applicazioni con decenni di regole aziendali accumulate.

Il lavoro su Daybreak offre un primo esempio perché la sicurezza delle applicazioni si adatta naturalmente al background di IBM nella consulenza e nell'infrastruttura. Tuttavia, l'accordo più ampio copre funzioni nelle quali il successo è più difficile da misurare.

Una revisione software più rapida può essere confrontata con un processo precedente. Misurare il contributo dell'AI agli approvvigionamenti, alla pianificazione della forza lavoro o alle operazioni rivolte ai clienti implica più variabili e periodi più lunghi.

Le ambizioni della partnership nel settore governativo devono inoltre confrontarsi con cicli di approvvigionamento che procedono più lentamente dei rilasci di prodotto. Le agenzie possono condurre progetti pilota limitati prima di autorizzare l'uso in produzione, soprattutto per lavori sensibili o rivolti ai cittadini.

Le priorità politiche possono cambiare durante questo processo. I requisiti di sicurezza possono anche evolvere dopo l'emergere di nuove capacità dei modelli o di incidenti.

Per queste ragioni, il risultato competitivo non apparirà in un singolo annuncio trimestrale. Emergerà attraverso le implementazioni dei clienti, il comportamento dei rinnovi, risultati misurabili dei flussi di lavoro ed evidenze che i controlli restano efficaci.

L'attenzione di Google News dà visibilità alla partnership. IBM ha ancora bisogno di clienti di riferimento che possano descrivere cosa è cambiato in produzione.

Cosa dovrebbero osservare ora i lettori di Google News

Tre segnali riveleranno se la partnership diventerà un modello operativo o rimarrà una grande promessa di consulenza.

Il primo segnale è rappresentato da implementazioni in produzione nominate. IBM e OpenAI hanno bisogno di clienti disposti a identificare il flusso di lavoro, il perimetro di implementazione e il risultato misurato.

Un caso credibile indicherebbe cosa facevano i dipendenti prima del sistema, cosa ha cambiato l'AI e come i revisori hanno misurato la qualità. Dovrebbe anche descrivere eccezioni e supervisione umana.

I soli nomi dei clienti non sono sufficienti. Un'organizzazione può essere cliente mantenendo al contempo la maggior parte degli utenti nella fase di sperimentazione. Le evidenze di produzione implicano lavoro ricorrente, responsabilità definite, monitoraggio e una risposta approvata quando qualcosa fallisce.

Se IBM pubblicherà diversi casi nei settori regolamentati con metriche comparabili, l'affermazione centrale della partnership diventerà più forte. Se gli annunci resteranno generici, il divario di evidenze persisterà.

Il secondo segnale è la forma dell'attività OpenAI di IBM. Le aziende hanno descritto migliaia di consulenti e ingegneri formati, ma organico e certificazioni misurano la capacità piuttosto che il valore per il cliente.

Gli acquirenti dovrebbero osservare modelli di delivery riutilizzabili. Potrebbero coprire modernizzazione delle applicazioni, approvvigionamenti, operazioni di sicurezza, assistenza clienti o ricerca regolamentata.

Un modello riutilizzabile dovrebbe definire architettura, autorizzazioni, valutazioni e processo di escalation. Dovrebbe comunque consentire modifiche per i dati e gli obblighi normativi di ciascun cliente.

IBM deve inoltre spiegare come i prodotti OpenAI interagiscano con i modelli Granite e altri fornitori. Policy multivendor chiare sosterrebbero l'argomento di flessibilità di IBM. Una forte dipendenza da un singolo stack lo indebolirebbe.

Il terzo segnale sono le evidenze provenienti dal lavoro di cybersecurity ampliato. Daybreak offre alla partnership un contesto concreto in cui i modelli analizzano codice con accesso controllato.

I risultati importanti includono vulnerabilità convalidate, tassi di falsi positivi, tempo dei revisori, velocità di remediation e incidenti evitati. I risultati riportati pubblicamente dovranno avere un contesto sufficiente per evitare confronti fuorvianti.

Il lavoro sulla sicurezza verifica anche se le aziende riescono a gestire la forma più difficile di capacità dei modelli. Lo stesso ragionamento che aiuta a individuare vulnerabilità può essere usato impropriamente, perciò controlli di accesso e monitoraggio sono fondamentali.

Una solida esperienza in implementazioni difensive circoscritte sosterrebbe l’espansione verso altri flussi di lavoro sensibili. Fallimenti nella sicurezza o affermazioni vaghe sulle prestazioni solleverebbero dubbi su un’adozione più ampia da parte delle amministrazioni pubbliche.

Questi tre segnali dovrebbero emergere prima che gli acquirenti accettino una narrativa di trasformazione radicale. I riferimenti in produzione mettono alla prova l’adozione. I modelli di delivery riutilizzabili mettono alla prova la scalabilità. Le evidenze di cybersecurity mettono alla prova il controllo.

I leader aziendali possono prepararsi documentando i flussi di lavoro attuali prima di scegliere un fornitore. Dovrebbero registrare il tempo necessario per le attività, i tassi di errore, l’impegno di revisione, l’accesso ai dati e le responsabilità di approvazione.

Dovrebbero poi iniziare con un caso d’uso circoscritto il cui risultato sia misurabile. Un sistema che recupera informazioni o prepara bozze di lavoro è più facile da valutare rispetto a un agente dotato di ampia autonomia.

I team hanno inoltre bisogno di una raccolta accessibile di esperimenti, decisioni e materiali di riferimento. Un sistema personale di gestione della conoscenza può aiutare i knowledge worker a preservare il contesto mentre strumenti e politiche cambiano.

IBM e OpenAI hanno riunito molti degli elementi necessari per un’AI aziendale sicura: modelli molto richiesti, capacità di consulenza, esperienza nella governance e un programma di cybersecurity. Il loro accordo deve ora produrre prove che questi elementi funzionino insieme.

Questa è la decisione che si trovano davanti i lettori che hanno scoperto la notizia tramite Google News. Chiedetevi quale flusso di lavoro in produzione sia cambiato, quale risultato misurabile sia migliorato e quali controlli abbiano intercettato gli errori prima degli utenti.

Nei prossimi mesi, osservate implementazioni nominate, modelli di implementazione ripetibili e risultati di sicurezza comprensibili in modo indipendente. Questi segnali mostreranno se IBM ha costruito un ponte affidabile verso operazioni regolamentate oppure un’altra strada ben pubblicizzata verso la fase pilota.