Il Microsoft MAI Code of Conduct trasforma la spinta di Satya Nadella verso la superintelligenza in una promessa verificabile

Satya Nadella ha annunciato un Microsoft MAI Code of Conduct, accogliendo al contempo un rallentamento deliberato per allineare i piani concorrenti del settore sulla superintelligenza. Il CEO di Microsoft ha subordinato l’ulteriore sviluppo a due condizioni: l’AI avanzata deve aiutare l’umanità e le persone devono restare al controllo.

Questa posizione colloca Microsoft tra due schieramenti sempre più visibili. Uno chiede controlli più rigorosi prima che i sistemi acquisiscano maggiore autonomia. L’altro sostiene che distribuire ampiamente l’AI avanzata offra la migliore difesa contro il controllo concentrato.

Nadella sta cercando di sostenere entrambe le posizioni. Microsoft vuole continuare a sviluppare modelli di frontiera, presentando il controllo umano come una condizione del progresso, non come un ostacolo. Questo equilibrio appare ragionevole, ma acquista significato solo quando l’azienda pubblica regole applicabili, valutazioni e limiti di rilascio.

L’annuncio è arrivato mentre i leader dell’AI discutevano se i sistemi di sicurezza stessero tenendo il passo con le capacità dei modelli. Il CEO di Anthropic Dario Amodei aveva chiesto di rallentare lo sviluppo quanto basta affinché le salvaguardie possano recuperare terreno. Meta, nel frattempo, ha difeso una superintelligenza personale ampiamente distribuita come strumento per preservare il potere individuale.

La risposta di Microsoft non è né una pausa né una corsa senza restrizioni. È la promessa di continuare a sviluppare, nel rispetto di un codice che dovrebbe definire ciò che l’azienda non metterà in produzione. La questione centrale è se questa promessa cambi lo sviluppo dei modelli o soltanto il modo in cui Microsoft lo descrive.

Cosa ha effettivamente annunciato Satya Nadella

Microsoft ha trasformato la propria filosofia sulla superintelligenza in un impegno di governance, sebbene i dettagli operativi restino incompleti.

In una dichiarazione del 13 settembre evidenziata dall’annuncio di Nadella, il CEO ha affermato che Microsoft accoglie il ritmo deliberato necessario per raggiungere l’allineamento. Per allineamento si intende mantenere il comportamento di un sistema AI coerente con gli obiettivi e i limiti umani, soprattutto con l’aumentare delle sue capacità.

Nadella ha presentato il controllo umano come una soglia per perseguire la superintelligenza. Se un sistema non aiuta l’umanità e non resta sotto la guida umana, ha sostenuto, non vale la pena svilupparlo. Ha inoltre ribadito che i benefici dell’AI dovrebbero diffondersi tra paesi e comunità.

Questa combinazione conta. Un appello al controllo può sostenere restrizioni più stringenti, mentre un invito a una distribuzione ampia può favorire un’implementazione più rapida. Microsoft afferma che entrambi gli obiettivi appartengono alla stessa strategia.

L’accompagnante Microsoft MAI Code of Conduct è destinato a disciplinare la famiglia di modelli sviluppati internamente dall’azienda. MAI si riferisce ai modelli sviluppati da Microsoft AI, anziché ai modelli forniti da partner come OpenAI o Anthropic.

Microsoft aveva già posto MAI al centro della propria roadmap di prodotto. Al Build 2026, ha presentato una famiglia MAI di sette modelli guidata da MAI-Thinking-1, il suo primo modello di ragionamento sviluppato internamente. La gamma comprendeva anche generazione di immagini, trascrizione, sintesi vocale e coding.

Microsoft ha dichiarato che MAI-Thinking-1 utilizzava 35 miliardi di parametri attivi e supportava una finestra di contesto da 256.000 token. I parametri attivi sono le componenti del modello usate durante una particolare inferenza, mentre la finestra di contesto definisce la quantità di input che può prendere in considerazione.

Queste specifiche mostrano che l’annuncio sul codice di condotta non è un esercizio astratto. Microsoft sta già integrando i modelli MAI in Foundry, GitHub Copilot, PowerPoint, OneDrive e altri prodotti molto utilizzati.

Tuttavia, l’annuncio disponibile non stabilisce tutte le regole necessarie per valutare la conformità. Non fornisce ancora un protocollo pubblico completo di test, un processo di applicazione, una soglia di implementazione o una classificazione del rischio specifica per ciascun modello.

La distinzione è importante. Annunciare un codice crea un’aspettativa. Pubblicare obblighi misurabili creerebbe responsabilità.

Per ora, lo sviluppo verificato è che Nadella ha collegato il programma di superintelligenza di Microsoft a un esplicito principio di controllo umano. La questione irrisolta è come tale principio disciplinerà le decisioni reali di rilascio.

Perché il Microsoft MAI Code of Conduct arriva ora

Il codice arriva perché i modelli di Microsoft stanno diventando abbastanza importanti da creare rischi che le politiche dei partner non possono coprire.

La prima espansione di Microsoft nell’AI generativa si è basata in larga misura su OpenAI. Questa relazione ha dato all’azienda un rapido accesso a modelli di frontiera per Azure, Microsoft 365, GitHub e prodotti destinati ai consumatori.

La sua posizione è ora più complessa. Microsoft continua a offrire modelli OpenAI, ma distribuisce anche Anthropic, Mistral, Meta, DeepSeek, xAI e altre famiglie di modelli attraverso le proprie piattaforme. Al tempo stesso, sta sviluppando MAI come alternativa proprietaria.

Questa diversità risponde a obiettivi commerciali e tecnici. Un modello specializzato può ridurre latenza, uso di token o costi operativi quando un modello di frontiera per uso generale supera le esigenze di un’attività. Offre inoltre a Microsoft un maggiore controllo su addestramento, implementazione e integrazione nei prodotti.

Nadella ha sostenuto che le imprese dovrebbero evitare di dipendere da un unico modello per ogni attività. A luglio, ha affermato che le organizzazioni dovrebbero separare dati, memoria, strumenti e agent harness da qualsiasi singolo modello.

Un agent harness è il software circostante che fornisce istruzioni, memoria, strumenti e feedback. Separare questo livello consente a un’azienda di sostituire i modelli senza ricostruire l’intero flusso di lavoro.

Questa argomentazione a favore dell’indipendenza dai modelli mette sotto pressione OpenAI e altri laboratori di frontiera. Microsoft resta al contempo loro investitore, partner cloud, distributore, cliente e, sempre più, concorrente diretto.

L’espansione di MAI modifica anche le responsabilità di Microsoft. Non può più considerare la sicurezza a livello di modello come una questione gestita principalmente da un fornitore esterno. Quando Microsoft addestra il modello, stabilisce le condizioni di rilascio e lo implementa nei propri prodotti, l’azienda si assume una quota maggiore del rischio.

Microsoft mantiene già un codice AI per le imprese destinato ai clienti che utilizzano i suoi servizi AI. Il documento richiede controlli su input e output, divulgazione dei contenuti sintetici, test continui, canali di feedback, misure di sicurezza e un’adeguata supervisione umana.

Limita inoltre gli usi dannosi, la manipolazione ingannevole, determinate inferenze biometriche, il social scoring e le decisioni rilevanti prese senza un adeguato coinvolgimento umano. I sistemi autonomi devono includere monitoraggio, controlli di intervento, avvisi di malfunzionamento e documentazione dei loro limiti.

Questi obblighi per i clienti sono rilevanti, ma non coincidono con un codice per lo sviluppo dei modelli. Un accordo di servizio indica ai clienti come possono usare un sistema. Un codice sui modelli dovrebbe spiegare anche cosa Microsoft addestrerà, testerà, tratterrà, modificherà o deciderà di non rilasciare.

Questa differenza spiega perché un Microsoft MAI Code of Conduct abbia più peso di un’ulteriore policy di uso accettabile. Dovrebbe disciplinare Microsoft prima che un modello raggiunga i clienti, non solo i clienti dopo l’implementazione.

La tempistica riflette anche il piano quinquennale dell’azienda sulla superintelligenza. Microsoft ha riorganizzato la leadership AI nel marzo 2026 affinché Mustafa Suleyman potesse concentrarsi più direttamente sui modelli di frontiera e sulle linee di modelli ottimizzate per le imprese.

Quando un’azienda destina talenti, capacità di calcolo e strategia di prodotto a tale obiettivo, le rassicurazioni informali sulla sicurezza diventano inadeguate. Un codice scritto può creare confini comuni tra ricercatori, dirigenti, team di prodotto e partner di implementazione.

Può anche rivelare se Microsoft definisce il progresso soltanto in base alle prestazioni nei benchmark. Un codice serio tratterebbe controllabilità, resistenza agli abusi, monitoraggio e impatto nel mondo reale come criteri di rilascio accanto alle capacità.

Il vero avversario di Microsoft è la corsa senza limiti di rilascio

Il conflitto principale non è Microsoft contro un singolo rivale; è la promessa di controllo di Microsoft contro la pressione competitiva a distribuire sistemi sempre più autonomi.

Ogni grande laboratorio AI ha incentivi a muoversi rapidamente. Modelli migliori attirano sviluppatori, contratti aziendali, talenti, investimenti e preziosi dati di utilizzo. Un ritardo può lasciare indietro un’azienda anche quando quel ritardo migliora la sicurezza.

La pressione aumenta quando i rivali descrivono la superintelligenza come abbastanza vicina da influenzare le decisioni attuali. Le aziende spendono quindi di più, accelerano gli esperimenti e annunciano tempistiche ambiziose perché temono di perdere un cambio di piattaforma.

Dario Amodei di Anthropic ha reso più acuta questa tensione sostenendo che le salvaguardie necessitano di tempo per recuperare terreno. Un avvertimento sulla sicurezza dell’AI riportato dall’Associated Press ha indicato che Amodei sosteneva un rallentamento dello sviluppo sufficiente a rafforzare i controlli attorno a sistemi sempre più capaci.

Secondo quel rapporto, Amodei ha avvertito che l’AI avanzata potrebbe presto coordinare grandi gruppi di agenti in grado di operare su Internet. La tempistica esatta è una previsione, non un fatto stabilito in modo indipendente.

Tuttavia, la preoccupazione di fondo è concreta. Gli agenti AI possono svolgere attività in più passaggi, richiamare strumenti, scrivere ed eseguire codice, comunicare con altri sistemi e continuare a lavorare con supervisione limitata.

Un modello che produce una risposta dannosa crea una categoria di rischio. Un agente che agisce in base a quella risposta ne crea un’altra. Il secondo sistema può trasformare un errore, un inganno o un’istruzione sfruttata in un’azione esterna.

Il sostegno di Nadella a un ritmo deliberato riconosce che capacità e governance non avanzano sempre insieme. Evita anche di avallare un arresto a tempo indeterminato. Microsoft vuole comunque sviluppare e distribuire sistemi avanzati.

Meta rappresenta un’enfasi differente. La sua argomentazione sulla superintelligenza personale sostiene che dare ampio potere agli individui può impedire che un controllo eccessivo si concentri nei governi o in un piccolo gruppo di aziende.

Meta riconosce inoltre il pericolo di sistemi che migliorano autonomamente o perseguono obiettivi al di là di una significativa supervisione umana. La risposta proposta punta su controlli, privacy, potere distribuito e coordinamento quando emergono comportamenti dannosi.

La posizione di Microsoft si sovrappone a parti di entrambe le argomentazioni. Come Anthropic, considera allineamento e controllo ragioni per regolare il ritmo dello sviluppo. Come Meta, afferma che i benefici dell’AI avanzata dovrebbero essere ampiamente distribuiti.

La parte difficile consiste nel decidere cosa accade quando questi principi entrano in conflitto. Una distribuzione ampia può aumentare l’accesso, ma può anche espandere il numero di persone in grado di usare impropriamente un sistema capace. Un’implementazione restrittiva può ridurre gli abusi, ma può concentrare il potere nel fornitore.

Un codice utile deve specificare chi risolve questo conflitto. Dovrebbe spiegare se un team di sicurezza possa bloccare un rilascio, se i dirigenti di prodotto possano annullare tale decisione e se revisori esterni ricevano prove significative.

Dovrebbe anche definire operativamente il controllo umano. Un pulsante di arresto è insufficiente se gli operatori non possono comprendere le azioni di un sistema, rilevare i guasti o intervenire prima che si verifichino conseguenze irreversibili.

Per gli acquirenti aziendali, il controllo include scelta del modello, confini dei dati, registri di audit, accesso basato sui ruoli, documentazione delle valutazioni, procedure di rollback e limiti all’azione autonoma. Include anche il mantenimento del contesto organizzativo al di fuori di qualsiasi singolo fornitore.

Questa architettura richiama un più ampio principio di knowledge blending: i sistemi diventano più utili quando collegano fonti pertinenti senza cancellare la provenienza né il controllo dell’utente. In un agente aziendale, la provenienza può determinare se un’azione viene considerata affidabile, sottoposta a revisione o respinta.

Il codice di Microsoft sarà quindi giudicato attraverso i prodotti, non la retorica. La prova più forte sarebbe un caso visibile in cui l’azienda ha rinviato, limitato o annullato un rilascio perché un modello non ha superato la soglia dichiarata.

Un Codice È Forte Solo Quanto i Suoi Test e la Sua Applicazione

La maggiore incertezza è se i principi di Microsoft produrranno decisioni verificabili in modo indipendente.

Microsoft sviluppa da anni un programma di IA responsabile. Il suo programma di IA responsabile pubblicato è organizzato attorno a trasparenza, responsabilità, equità, inclusività, affidabilità, sicurezza, privacy e protezione.

L’azienda descrive inoltre un processo per mappare, misurare e gestire i rischi. Queste pratiche creano una base per la governance dei modelli, ma un codice per la superintelligenza deve soddisfare uno standard più rigoroso.

In primo luogo, Microsoft deve definire i sistemi coperti dal codice. La famiglia MAI comprende modelli per ragionamento, programmazione, voce, trascrizione e immagini. Questi sistemi hanno modalità di fallimento differenti e richiedono valutazioni diverse.

Un modello vocale solleva questioni di consenso, impersonificazione, frode e divulgazione. Un modello di coding solleva questioni di cybersecurity, dipendenze, esecuzione e integrità del software. Un modello di ragionamento connesso a strumenti solleva questioni più ampie sulla pianificazione e sull’azione autonoma.

Un principio universale non può sostituire questi controlli specifici per modello. Il codice necessita di una base comune, oltre a requisiti separati per ciascuna capacità e contesto di distribuzione.

In secondo luogo, le valutazioni devono assomigliare all’uso reale del prodotto. Un modello di coding testato soltanto su attività di benchmark isolate potrebbe comportarsi diversamente all’interno di un agente che modifica repository, esegue comandi e accede a credenziali.

Microsoft ha dichiarato che i suoi modelli MAI sono addestrati e ottimizzati per attività specifiche dei prodotti. Questo rende particolarmente importante la valutazione a livello di prodotto. L’unità pertinente è spesso il sistema completo, inclusi harness, strumenti, memoria, policy e flusso di approvazione umana.

In terzo luogo, i risultati richiedono una rendicontazione chiara. Un punteggio ha valore limitato se gli esterni non possono vedere la definizione del test, le condizioni di confronto, la versione del modello, l’accesso agli strumenti o le categorie di errore.

Microsoft non deve pubblicare pesi sensibili dei modelli o dettagli di sicurezza per fornire prove utili. Può diffondere metodi di valutazione, risultati sintetici, limitazioni note, restrizioni di distribuzione e descrizioni delle mitigazioni significative.

In quarto luogo, l’applicazione deve raggiungere i team interni. Le restrizioni per i clienti sono più facili da osservare perché Microsoft può sospendere l’accesso al servizio. L’applicazione interna è più difficile perché scadenze di prodotto e obiettivi di fatturato operano all’interno della stessa azienda.

Una struttura di governance credibile separa la revisione dei rischi dai team premiati per la rapidità di rilascio. Crea percorsi di escalation documentati e definisce chi ha autorità quando sicurezza e obiettivi commerciali entrano in conflitto.

In quinto luogo, il codice dovrebbe affrontare le modifiche successive al lancio. I modelli possono ricevere nuovi strumenti, contesto più lungo, istruzioni di sistema aggiornate o autorizzazioni più ampie senza ricevere un nuovo nome pubblico.

Queste modifiche possono alterare il rischio più di un aggiornamento convenzionale del modello. La governance deve quindi coprire l’intera configurazione di distribuzione, non soltanto il checkpoint prodotto alla fine dell’addestramento.

Ricercatori indipendenti hanno inoltre sottolineato che il rischio di perdita di controllo resta difficile da misurare. Le priorità globali di ricerca pubblicate attraverso il Singapore Consensus del 2026 descrivono il settore come sempre più verificabile, pur riconoscendo una notevole incertezza predittiva.

Questa incertezza agisce in entrambe le direzioni. Non dimostra che esiti catastrofici siano imminenti. Non giustifica nemmeno il considerare l’assenza di fallimenti osservati come prova che un sistema sia sicuro.

Microsoft dovrebbe evitare di suggerire che un codice scritto risolva l’allineamento. L’allineamento rimane un problema tecnico, organizzativo e politico che coinvolge valori contestati e misurazioni incomplete.

I critici dovrebbero evitare l’esagerazione opposta. Un codice volontario non è automaticamente privo di significato. Può influenzare le decisioni ingegneristiche quando include test concreti, responsabili decisionali nominati, gate di rilascio e conseguenze documentate.

Lo standard appropriato è l’evidenza. Il codice cambia ciò che viene addestrato, il modo in cui viene testato, le capacità che restano limitate e il momento in cui la distribuzione si ferma?

Cosa Dovrebbero Chiedere Sviluppatori e Acquirenti Aziendali

I clienti dovrebbero tradurre l’impegno di Microsoft al controllo umano in domande di approvvigionamento prima di assegnare ai modelli MAI compiti con conseguenze rilevanti.

La prima domanda riguarda l’ambito. Gli acquirenti devono sapere se il Microsoft MAI Code of Conduct si applica soltanto ai modelli pubblicamente disponibili o anche alle versioni interne usate nei prodotti Microsoft.

Un modello integrato in Copilot può influenzare utenti che non lo selezionano mai direttamente. Microsoft dovrebbe indicare quale modello svolge un’attività, quando avviene l’instradamento e se gli amministratori possono limitare specifiche famiglie di modelli.

La seconda domanda riguarda la valutazione. Le organizzazioni dovrebbero chiedere quali test di sicurezza e qualità si applichino al loro caso d’uso, non se un modello abbia ottenuto un punteggio elevato in un benchmark generale.

Un assistente per il servizio clienti necessita di test su affermazioni non supportate, escalation, privacy e gestione dei registri. Un agente di coding necessita di test su comandi non sicuri, codice vulnerabile, esposizione di segreti, integrità dei pacchetti e modifiche non autorizzate.

Un flusso di lavoro sanitario o finanziario richiede una revisione umana più rigorosa perché gli errori possono influire su diritti, opportunità o benessere fisico. Il codice aziendale esistente di Microsoft considera già le decisioni consequenziali come soggette a una supervisione appropriata.

La terza domanda riguarda l’autonomia. Gli acquirenti dovrebbero documentare quali azioni un agente possa intraprendere, quali richiedano approvazione e quali restino proibite in ogni circostanza.

Il controllo umano dovrebbe esistere prima di un’azione con conseguenze rilevanti, non soltanto dopo un fallimento. Schermate di revisione, confini delle autorizzazioni, limiti di transazione e ambienti di staging reversibili offrono maggiore protezione di una generica istruzione a comportarsi in modo sicuro.

La quarta domanda riguarda il monitoraggio. I team necessitano di registri che mostrino input, contesto recuperato, chiamate agli strumenti, output del modello, interventi delle policy, approvazioni e azioni finali.

Questi registri dovrebbero rimanere comprensibili quando un flusso di lavoro utilizza più modelli. Un’azienda non può indagare su un incidente se la sua piattaforma instrada silenziosamente ogni passaggio e non conserva una traccia decisionale utilizzabile.

La quinta domanda riguarda le modifiche ai modelli. Le distribuzioni aziendali dovrebbero definire periodi di preavviso, test di regressione, opzioni di rollback e controlli di versione quando Microsoft aggiorna un modello MAI o modifica il livello di instradamento.

Il miglioramento automatico è interessante, ma un modello aggiornato può alterare il comportamento in un flusso di lavoro convalidato. I team regolamentati potrebbero dover ripetere i test prima di adottare la nuova versione.

La sesta domanda riguarda i dati. Nadella ha sostenuto che le aziende devono mantenere il controllo sui propri cicli di apprendimento, ossia sulle informazioni generate quando dipendenti e sistemi svolgono il lavoro.

Gli acquirenti dovrebbero chiarire se prompt, output, feedback e tracce degli strumenti addestrino i modelli Microsoft. Dovrebbero inoltre stabilire dove risiedano tali registrazioni e come possano esportarle o eliminarle.

La settima domanda riguarda la risposta agli incidenti. Un codice necessita di canali di segnalazione, ma le aziende hanno anche bisogno di tempi di risposta, contatti per l’escalation, procedure di contenimento e spiegazioni successive all’incidente.

Gli sviluppatori hanno una propria responsabilità pratica. Dovrebbero trattare l’output del modello come non attendibile finché il sistema circostante non lo convalida. Questo principio è particolarmente importante quando un agente scrive codice, modifica dati o comunica all’esterno.

Nessuna di queste domande richiede di attendere la superintelligenza. Si applicano ai sistemi attuali che già combinano modelli linguistici con strumenti e dati organizzativi.

L’annuncio di Nadella conta perché offre ai clienti uno standard che possono citare. Se Microsoft afferma che l’IA deve rimanere sotto controllo umano, gli acquirenti possono chiedere all’azienda di mostrare dove tale controllo esista.

Tre Segnali Mostreranno se Microsoft Fa Sul Serio

Il prossimo test è l’implementazione, e tre segnali osservabili riveleranno se il codice cambia il comportamento di Microsoft.

Il primo segnale è la pubblicazione di requisiti specifici per modello e risultati di valutazione. Microsoft dovrebbe collegare il codice ai singoli modelli MAI anziché lasciarlo come dichiarazione generale.

Per MAI-Thinking-1, ciò potrebbe includere affidabilità del ragionamento, test di inganno, limiti nell’uso degli strumenti, valutazioni di cybersecurity e risultati sul controllo degli agenti. Per i modelli vocali e di immagini, dovrebbe coprire impersonificazione, provenienza, consenso e salvaguardie contro contenuti dannosi.

Il dettaglio decisivo non è se ogni punteggio sembri favorevole. Limitazioni trasparenti renderebbero il quadro più credibile, poiché nessun modello avanzato opera in modo affidabile in ogni ambiente.

Se Microsoft pubblica metodi riproducibili, risultati versionati e chiare restrizioni di distribuzione, la promessa di Nadella diventa più forte. Se pubblica soltanto principi, l’annuncio rimane difficile da verificare.

Il secondo segnale è la prova che i gate di rilascio abbiano conseguenze. Osservate una capacità MAI che Microsoft rinvia, limita o mantiene in anteprima dopo che i test rivelano rischi irrisolti.

Una simile decisione dimostrerebbe che una cadenza deliberata può prevalere sulla pressione commerciale. Stabilirerebbe inoltre un precedente per dipendenti e partner che valutano rilasci successivi.

Un ritardo da solo non dimostra una buona governance. Le aziende rinviano prodotti per ragioni tecniche, finanziarie o strategiche. Microsoft dovrebbe spiegare quando il suo codice ha influenzato la decisione e identificare la soglia pertinente senza esporre dettagli sensibili di sicurezza.

Se nessun rilascio cambia mai a causa del codice, gli osservatori dovrebbero chiedersi se il quadro governi lo sviluppo o si limiti a documentare intenzioni già esistenti.

Il terzo segnale è il modo in cui Microsoft gestisce gli agenti autonomi in Foundry, Copilot e Microsoft 365. La sicurezza dei modelli e quella degli agenti non possono restare separate una volta che i modelli ricevono strumenti e autorizzazione ad agire.

Cercate controlli amministrativi più forti, autorizzazioni granulari, requisiti di approvazione, monitoraggio, rollback e identificazione coerente dei modelli. Queste funzionalità trasformerebbero il controllo umano in una proprietà del prodotto.

Osservate anche se Microsoft applica standard equivalenti ai modelli partner distribuiti attraverso le sue piattaforme. I clienti vivono l’esperienza del servizio Microsoft completo, anche quando un modello sottostante proviene da un altro laboratorio.

Un codice limitato a MAI potrebbe migliorare le pratiche interne di Microsoft lasciando però protezioni incoerenti nel catalogo più ampio. Un livello di controllo a livello di piattaforma potrebbe ridurre questo divario.

Il Microsoft MAI Code of Conduct crea quindi un utile test per la strategia di superintelligenza dell’azienda. Microsoft desidera contemporaneamente progresso di frontiera, modelli specializzati a minor costo, ampia distribuzione e un controllo umano significativo.

Questi obiettivi non sono automaticamente compatibili. I loro conflitti emergeranno nelle riunioni sui rilasci, nelle autorizzazioni dei prodotti, nei rapporti di valutazione e nelle risposte agli incidenti.

Sviluppatori e leader aziendali dovrebbero conservare il principio di Nadella e confrontarlo con tali decisioni. Dovrebbero chiedere quali test possano fermare una distribuzione, chi abbia l’autorità di applicarli e quali prove ricevano i clienti.

Se Microsoft risponde pubblicamente a queste domande, una cadenza deliberata diventa una disciplina operativa. Se non lo fa, il codice resterà una dichiarazione di valori collegata a un programma di modelli in accelerazione.