Modifica

Ridimensionare le iniziative di intelligenza artificiale e di apprendimento automatico nei settori regolamentati

Azure Machine Learning
Azure Synapse Analytics
Azure Databricks

In questo articolo vengono illustrate le considerazioni sull'architettura di Azure correlate all'analisi e all'implementazione di un set comune di controlli ISRM (Information Security Risk Management).

Architettura

L'architettura è illustrata in questo diagramma e segue il principio delle zone di destinazione su scala aziendale, in particolare l'architettura di riferimento per l'analisi su scala aziendale e l'intelligenza artificiale.

Diagram of a scalable AI platform for regulated industries.

Scaricare un file di Visio di questa architettura.

Workflow

L'architettura è costituita dal flusso di lavoro descritto nelle sezioni seguenti. Ogni componente dell'architettura ha un numero corrispondente nel diagramma. Viene descritto lo scopo principale del componente, il modo in cui si inserisce nell'architettura e qualsiasi altra considerazione importante da prendere durante l'adozione:

  1. Sottoscrizioni della piattaforma: sottoscrizioni di Azure di base che forniscono gestione, connettività e identità tramite Microsoft Entra ID. Non sono descritti qui in modo più dettagliato e si presuppone che siano pronti e disponibili come parte della configurazione di base su scala aziendale.

Gestione dati

  1. Zona di gestione dei dati: la zona di gestione dei dati è responsabile della governance dei dati nella piattaforma e applica protezioni per offrire maggiore flessibilità downstream nelle zone di destinazione dei dati. Dispone di una propria sottoscrizione e ospita servizi centralizzati, ad esempio catalogazione, monitoraggio, controlli dei dati e così via. Tale ambiente è soggetto a verifiche stringenti e risulta estremamente controllato. Tutti i tipi di classificazione dei dati vengono archiviati nel catalogo dati centrale (Azure Purview). In base ai metadati, vengono applicati criteri e modelli di accesso diversi. È disponibile una sola sottoscrizione della zona di gestione dati per l'intero tenant. La zona di gestione dati viene sottoposta a peering (tramite peering reti virtuali) con tutte le altre zone di destinazione dei dati. Gli endpoint privati vengono usati ogniqualvolta possibile per garantire che i servizi distribuiti non siano accessibili tramite rete Internet pubblica.
  2. Gruppo di risorse di rete: viene effettuato il provisioning di azure Rete virtuale, gruppi di sicurezza di rete e tutte le altre risorse correlate alla rete necessarie per l'area di gestione dati all'interno del gruppo di risorse di rete.
  3. Gruppo di risorse di distribuzione: un gruppo di risorse di distribuzione ospita agenti CI/CD privati di Azure DevOps (macchine virtuali) necessari per l'area di gestione dei dati e un insieme di credenziali delle chiavi per l'archiviazione di eventuali segreti correlati alla distribuzione.
  4. Gruppo di risorse per la governance dei dati: Azure Purview viene usato come soluzione di governance e catalogo dei dati e consente di applicare le protezioni necessarie per i set di dati al fine di rispettare i requisiti e le normative sui dati imposti dalla legge o da altre entità. Purview è ospitato centralmente in questo gruppo di risorse insieme con un'istanza di Key Vault per l'archiviazione di segreti.
  5. Asset centralizzati: gli asset centralizzati ospitano asset importanti e preziosi che sono fondamentali per la piattaforma, ad esempio:
    • Registri Azure Container che ospitano immagini di base usate nei prodotti dati basati su Azure Machine Learning (immagini analizzate in precedenza e senza vulnerabilità)
    • Modelli di Intelligenza artificiale/Machine Learning pubblicati e resi disponibili per i consumer nella piattaforma (in modo che possano essere distribuiti in una o più zone di destinazione dei dati, se necessario).
  6. Servizi aggiuntivi: qualsiasi altro servizio che deve essere centralizzato può essere ospitato in uno di questi gruppi di risorse, che può includere istanze centralizzate di Azure Gestione API, software di terze parti e così via.
  7. Gruppo di risorse di visualizzazione dei dati: questo gruppo di risorse ospita soluzioni di visualizzazione dei dati condivise tra zone di destinazione dei dati. Le soluzioni possono essere Power BI, Tableau o qualsiasi altra soluzione di visualizzazione.
  8. Controlli e governance dell'infrastruttura aggiuntivi: Microsoft Defender per il cloud e Monitoraggio di Azure vengono usati come soluzioni di sicurezza e monitoraggio di base.

Zone di destinazione dei dati

  1. Zona di destinazione dei dati 001 : una zona di destinazione dei dati è una sottoscrizione che rappresenta un'unità di scala all'interno della piattaforma dati. Le zone di destinazione dei dati vengono distribuite in base all'architettura principale della zona di destinazione dei dati (progetto), incluse tutte le funzionalità principali per ospitare un'analisi e una piattaforma di intelligenza artificiale. All'interno dell'ambiente possono essere presenti una o più zone di destinazione dei dati. Criteri di Azure viene applicato per mantenere sicuro l'accesso e le configurazioni di vari servizi di Azure. La zona di destinazione dei dati è sottoposta a peering (tramite peering reti virtuali) con tutte le altre zone di destinazione dei dati e la zona di gestione dei dati. Gli endpoint privati vengono usati ogniqualvolta possibile per garantire che i servizi distribuiti non siano accessibili tramite rete Internet pubblica.

  2. Gruppo di risorse di rete: viene effettuato il provisioning di azure Rete virtuale, gruppi di sicurezza di rete e tutte le altre risorse correlate alla rete necessarie per la zona di destinazione dei dati all'interno di questo gruppo di risorse.

  3. Gruppo di risorse di distribuzione: un gruppo di risorse di distribuzione ospita agenti CI/CD privati di Azure DevOps (macchine virtuali) necessari per la zona di destinazione dei dati e un insieme di credenziali delle chiavi per l'archiviazione di eventuali segreti correlati alla distribuzione.

  4. Gruppo di risorse di archiviazione dati: un gruppo di risorse di archiviazione dati contiene gli account di archiviazione dati principali per questa zona di destinazione dei dati, distribuiti come Azure Data Lake Archiviazione Gen2, con spazio dei nomi gerarchico. Gli account sono distribuiti in tre aree principali:

    • Non elaborato: i dati vengono inseriti dall'origine dati nello stato originale
    • Curato e arricchito : i dati vengono puliti, convalidati e aggregati
    • Area di lavoro : specifici prodotti dati possono archiviare i set di dati o gli output dei modelli di Machine Learning e così via

    Le frecce nei diagrammi mostrano il flusso di dati previsto, dai dati non elaborati ai dati curati e arricchiti (attendibili) e oltre, fino all'area di lavoro per l'esplorazione, l'analisi e l'offerta di un valore aggiuntivo dal prodotto dati.

  5. Gruppo di risorse di integrazione dei dati: il gruppo di risorse di integrazione dei dati ospita un'istanza di Azure Data Factory che condivide la connettività con il runtime di integrazione self-hosted locale. Il suo scopo principale è stabilire la connettività. Altre istanze di Data Factory lo riutilizzano in modo che la connettività venga mantenuta solo in un'unica posizione. L'altro scopo è ospitare il runtime di integrazione self-hosted per il servizio Azure Purview in modo che possa accedere alle origini dati in questa zona di destinazione dei dati, a scopo di analisi.

  6. Gruppo di risorse di gestione dei metadati: il gruppo di risorse di gestione dei metadati ospita i metadati per Azure Databricks (meta store Hive) e le pipeline di inserimento ed elaborazione di Azure Data Factory. Ospita anche un insieme di credenziali delle chiavi per archiviare i segreti per l'accesso a questi dati. Per archiviare i metadati, viene usato il database SQL di Azure.

  7. Gruppo di risorse di inserimento dati: il gruppo di risorse di inserimento dati ospita un'istanza di Azure Data Factory in cui vengono distribuite tutte le pipeline di inserimento dati specifiche per un dominio dati. Azure Databricks viene usato come motore di elaborazione per caricare e trasformare i dati e archiviarli in account data lake.

  8. Gruppo di risorse di Analisi: il gruppo di risorse di analisi include due servizi condivisi per altre analisi ed esplorazione dei dati: Azure Synapse e Azure Databricks. Entrambi i servizi offrono una vasta gamma di risorse di calcolo e scalabilità per l'esplorazione e l'analisi di dati di grandi dimensioni.

  9. Gruppo di risorse del prodotto dati: il gruppo di risorse del prodotto dati è un progetto per un prodotto dati, con un gruppo di risorse contenente risorse di Azure di base che potrebbe essere necessario per un prodotto dati. La distribuzione deve essere configurabile tramite una pipeline Azure DevOps in base alle esigenze specifiche dell'azienda. I servizi principali di Azure distribuiti sono i seguenti:

    • Area di lavoro di Azure Machine Learning come base per qualsiasi progetto di apprendimento automatico aziendale con servizi correlati, ad esempio Key Vault (per l'archiviazione di segreti)
    • Application Insights (per il monitoraggio dei modelli)
    • Archiviazione di Azure (per l'archiviazione di set di dati)
    • Registro Azure Container per l'archiviazione di immagini del modello durante lo sviluppo

    Servizi cognitivi viene distribuito come bundle per fornire all'API l'accesso a più servizi supportati dall'intelligenza artificiale, mentre per lo sviluppo, la compilazione di modelli e i cluster di calcolo di Azure Machine Learning vengono usati a scopo di sviluppo, compilazione di modelli e test. Azure Data Factory viene usato per orchestrare l'assegnazione dei punteggi batch dei modelli, se necessario. app Azure Servizio e Azure Cosmos DB offrono un livello aggiuntivo per la distribuzione del prodotto dati, in cui un'applicazione o un'API personalizzata può essere ospitata con il proprio archivio dati interno.

    Per i settori regolamentati, in genere, sono previste restrizioni rigorose per l'accesso ai dati e l'hosting dei dati di produzione è consentito solo all'interno dell'ambiente di produzione stesso. Per questo motivo, il ciclo di vita di sviluppo dei prodotti dati si verifica solo nella zona di destinazione dei dati di produzione e viene effettuato il provisioning di un ambiente separato o di un gruppo di risorse per scopi di sviluppo, test e distribuzione.

  10. Prodotti dati aggiuntivi: questi gruppi di risorse ospitano altri prodotti dati poiché una zona di destinazione dei dati può ospitare uno o più di tali prodotti.

  11. Gruppo di risorse di elaborazione condivise: tutte le risorse di elaborazione condivise necessarie per l'hosting e la distribuzione di prodotti dati vengono sottoposte a provisioning in questo gruppo. Un cluster servizio Azure Kubernetes è un esempio.

  12. Controlli e governance dell'infrastruttura aggiuntivi: Microsoft Defender per il cloud e Monitoraggio di Azure vengono usati come soluzioni di sicurezza e monitoraggio di base.

  13. Zona di destinazione dei dati 002 : questa zona di destinazione è un segnaposto per sottoscrizioni di Azure aggiuntive che verranno usate per ospitare nuove zone di destinazione dei dati. Tali zone si basano su criteri indicati in precedenza, ad esempio i requisiti di residenza dei dati o una Business Unit diversa con un proprio team interfunzionale e un set di casi d'uso da associare.

Componenti

Alternative

Nelle organizzazioni distribuite i gruppi aziendali operano in modo indipendente e con livelli elevati di autonomia. Di conseguenza, si potrebbe prendere in considerazione una progettazione alternativa della soluzione, con isolamento completo dei casi d'uso nelle zone di destinazione di Azure, condividendo un set minimo di servizi comuni. Anche se questa progettazione consente un avvio rapido, richiede un elevato impegno da parte delle organizzazioni IT e ISRM, poiché la progettazione di singoli casi d'uso può rapidamente divergere dalle progettazioni dei progetti. Inoltre, richiede processi e controlli ISRM indipendenti per ognuno dei prodotti di Intelligenza artificiale e Machine Learning ospitati in Azure.

Dettagli dello scenario

Il ridimensionamento delle iniziative di intelligenza artificiale e apprendimento automatico in ambienti regolamentati pone sfide significative alle organizzazioni, indipendentemente dalle dimensioni e dalla maturità in ambito digitale. Questo articolo illustra le decisioni architetturali chiave da prendere in considerazione quando si adottano i servizi di ingegneria dei dati e di apprendimento automatico di Azure nei settori regolamentati. Tali decisioni si basano su quanto appreso da una recente implementazione in un'azienda globale nel settore sanitario e delle scienze biologiche di Fortune 500.

L'architettura presentata in questo articolo segue la progettazione dell'architettura di riferimento per l'analisi su scala aziendale e l'intelligenza artificiale ed è stata una delle sue prime implementazioni.

Se si configurano progetti di data science e si sviluppano modelli di Machine Learning in ambienti sanitari e scienze biologiche, in quasi tutti i casi è necessario accedere alle origini dati ad alto impatto aziendale (HBI). Ad esempio, queste fonti possono essere informazioni sul protocollo di sperimentazione clinica senza dati dei pazienti, formule chimiche della molecola o segreti del processo di produzione.

Nei settori regolamentati, i sistemi IT sono catalogati in base alla classificazione delle origini dati a cui accedono. Gli ambienti di intelligenza artificiale e Machine Learning in esecuzione in Azure vengono classificati come HBI e sono necessari per rispettare un ampio set di criteri e controlli ISRM.

Principi di progettazione

Questa architettura si basa sui principi seguenti:

  • La scalabilità aziendale è un approccio architetturale e un'implementazione di riferimento allineata alla roadmap di Azure e parte di Microsoft Cloud Adoption Framework (CAF). Consente di costruire le zone di destinazione in Azure e di operarvi in modo efficace, su larga scala. La zona di destinazione del nome viene usata come limite in cui le applicazioni nuove o migrate vengono spostate in Azure. In questo scenario si riferisce anche a parti della piattaforma dati usate per ospitare i dati e i modelli di Intelligenza artificiale e Machine Learning.
  • Le architetture tradizionali della piattaforma dati monolitica presentano una limitazione intrinseca che rallenta la distribuzione di funzionalità e valori. L'architettura qui descritta consente alle organizzazioni di ridimensionare il proprio ambiente di dati e di affrontare le sfide di un data lake monolitico centralizzato tramite un approccio decentralizzato con separazione della proprietà (mesh di dati). L'approccio consente alle organizzazioni di ridimensionarsi a migliaia di pipeline di inserimento e prodotti dati, mantenendo la piattaforma dati sicura e gestibile separando la piattaforma dati di base e i servizi di gestione dei dati (distribuiti in una zona di destinazione separata denominata zona di gestione dei dati) dai domini dati e dai prodotti dati (distribuiti in una o più zone di destinazione dei dati).
  • Le sottoscrizioni vengono usate come unità di gestione e scalabilità allineate alle esigenze e alle priorità aziendali. Il ridimensionamento viene ottenuto fornendo nuove sottoscrizioni (zone di destinazione dei dati) alle business unit in base a criteri quali stakeholder aziendali diversi, obiettivi e requisiti aziendali diversi e requisiti di residenza dei dati (dove i dati devono essere ospitati in un'area geografica specifica).
  • Criteri di Azure viene usato per fornire protezioni e garantire la conformità continua all'interno del panorama IT dell'azienda.
  • Un unico piano di controllo e gestione (tramite il portale di Azure) offre un'esperienza coerente in tutte le risorse e i canali di provisioning di Azure soggetti ad accesso basato sui ruoli e a controlli basati su criteri. I servizi e le funzionalità della piattaforma nativa di Azure vengono usati quando possibile.
  • I team interfunzionali assumono la proprietà della progettazione, dello sviluppo e delle operazioni per ridurre il time-to-market e l'agilità nella piattaforma. I principi di base come DevOps, l'infrastruttura come codice (IaC, Infrastructure as Code) e le progettazioni resilienti vengono usati per evitare errori umani e singoli punti di guasto.
  • Gli esperti del dominio e dell'origine dati possono usare domini di dati per eseguire il pull di asset di dati da ambienti azure, di terze parti o locali. Un dominio dati è un gruppo di risorse all'interno di una zona di destinazione dei dati che i team interfunzionali possono usare per l'inserimento dati personalizzato. Possono essere presenti uno o più domini dati all'interno di una zona di destinazione dei dati. I domini di dati possono essere visualizzati in modo analogo ai domini in Progettazione basata su dominio, in cui forniscono un limite di contesto e sono autosufficienti e isolati. Un esempio di dominio dati è costituito da dati clinici o da supply chain.

Potenziali casi d'uso

Le considerazioni sull'architettura descritte in questo articolo hanno origine nel settore delle scienze biologiche e della sanità, Tuttavia, sono rilevanti anche per le organizzazioni in altri settori regolamentati, inclusi questi settori:

  • Servizi finanziari
  • Operatori di servizi sanitari
  • Petrolio e gas

L'implementazione dell'architettura di riferimento di analisi e intelligenza artificiale su scala aziendale in ambienti regolamentati segue modelli di progettazione simili.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

In questa sezione vengono illustrate le lezioni apprese dall'implementazione dell'architettura descritta in precedenza in un ambiente regolamentato per le scienze della vita e il settore sanitario. Vengono anche descritte considerazioni generali sulla progettazione per soddisfare i controlli e i criteri ISRM comuni.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Ambienti

Negli ambienti regolamentati, i sistemi IT classificati come HBI devono avere più ambienti separati, ad esempio sviluppo, qualità e produzione o simili. L'accesso alle origini dati protette è autorizzato solo in ambienti certificati per la produzione.

Poiché lo sviluppo di intelligenza artificiale e Machine Learning richiede l'accesso a set di dati sensibili, le diverse fasi del processo operativo di Machine Learning, ad esempio la compilazione, il training e l'inferenza del modello (o simili), tutte vengono eseguite nell'ambiente di produzione. Gli ambienti di sviluppo e qualità sono in genere limitati all'infrastruttura, alle operazioni e al tipo di progettazione dei dati, per garantire miglioramenti continui man mano che diventano disponibili nuovi servizi e funzionalità di Azure.

Le attività di sviluppo di intelligenza artificiale e data science devono essere eseguite in ambienti di produzione, ad eccezione del lavoro sandbox o esplorativo precoce.

Crittografia

I sistemi IT che accedono, archiviano ed elaborano dati aziendali sensibili sono necessari per implementare requisiti specifici per la gestione delle chiavi di crittografia, ad esempio criteri FIPS 140-2 di livello 2 o 3, con l'integrazione di chiavi gestite dal cliente. I dati protetti devono essere sempre crittografati quando sono inattivi e in transito, tramite protocolli TLS 1.2 o versione successiva.

Durante la progettazione dell'architettura, è necessario eseguire un'attenta analisi del supporto e dell'integrazione dei servizi di Azure nell'infrastruttura di chiavi gestite dal cliente di un'organizzazione. Eventuali eccezioni alla crittografia dei dati devono essere documentate. Il supporto per i fornitori del modulo di protezione hardware viene sempre esteso e altre informazioni sono disponibili nel modulo di protezione hardware gestito in Azure Key Vault.

Progettazione della rete e limitazione ad anello

Gli ambienti di intelligenza artificiale e machine learning devono avere un'isolamento circolare sul posto, con la segmentazione di rete e i controlli di accesso alla rete implementati. La comunicazione di rete tra i componenti dell'architettura è limitata ai flussi di dati necessari e all'infrastruttura sottostante per funzionare in un approccio di inserimento consentito. È consigliabile applicare l'analisi basata su firma e quella basata sul comportamento.

Applicare i controlli di accesso alla rete in diversi livelli nell'architettura, tra cui Firewall di Azure, esaminare la connettività di rete in ingresso e in uscita, i gruppi di sicurezza di rete e l'accesso all'endpoint applicazione Web protetto con web application firewall (WAF).

Gestione delle autorizzazioni

Gli ambienti di intelligenza artificiale e apprendimento automatico in esecuzione in Azure devono essere integrati con il sistema di provisioning dell'account principale dell'organizzazione, in cui le richieste per concedere l'accesso alle applicazioni aziendali critiche vengono inviate, approvate e controllate.

È previsto che i sistemi di provisioning degli account si connettano ad Active Directory e Microsoft Entra ID di un'organizzazione, in modo che i ruoli di autorizzazione aziendale vengano mappati ai gruppi di sicurezza di Active Directory e Microsoft Entra corrispondenti.

Gli ambienti di intelligenza artificiale e Machine Learning seguono un modello di controllo degli accessi in base al ruolo. Le autorizzazioni di controllo a livello di accesso assicurano che gli utenti possano eseguire solo le attività e le azioni per il proprio ruolo di lavoro e i requisiti aziendali. Si prevede che i casi d'uso di apprendimento automatico siano effettivamente separati poiché gli scienziati dei dati che lavorano su un particolare caso d'uso sono autorizzati ad accedere solo alle risorse che ne fanno parte, in base a un principio di privilegio minimo. Tali risorse possono includere:

  • Account di archiviazione
  • Aree di lavoro di Azure Machine Learning
  • Istanze di calcolo

Il controllo degli accessi in base al ruolo usa i gruppi di sicurezza in Microsoft Entra ID.

Autenticazione a più fattori

L'autenticazione a più fattori deve essere implementata e implementata per l'accesso a tutti gli ambienti in esecuzione in Azure e classificati come un impatto aziendale elevato. L'autenticazione a più fattori può essere applicata usando i servizi di autenticazione a più fattori Di Microsoft Entra. Gli endpoint dell'applicazione, tra cui Azure DevOps, portale di gestione di Azure, Azure Machine Learning, Azure Databricks e servizio Azure Kubernetes, devono essere configurati nei criteri di controllo dell'accesso con autenticazione a più fattori.

L'autenticazione a più fattori deve essere applicata a tutti gli utenti, inclusi i responsabili dei servizi di Azure, i data engineer e i data scientist.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Registrazione e monitoraggio

Tutti i servizi di Azure devono inserire gli eventi di sicurezza nella piattaforma del centro operazioni per la sicurezza (SOC, Security Operations Center) di un'organizzazione e devono essere registrati gli eventi di sicurezza seguenti:

  • Tentativi di autenticazione riusciti e non riusciti
  • Accesso ai dati sensibili
  • Modifiche ai criteri di sicurezza
  • Modifiche a gruppi di utenti, utenti o ruoli amministratori
  • Trasferimenti di dati sensibili a posizioni esterne, se applicabile
  • Attivazione e disattivazione dei sistemi di protezione, ad esempio controlli ABAC
  • Accesso aggiornato ai log e interruzione della registrazione

I log di sicurezza di Azure possono essere inseriti nel centro operazioni per la sicurezza tramite schemi diversi:

  • Area di lavoro Azure Log Analytics centrale
  • Hub eventi connesso ai sistemi della piattaforma SOC, ad esempio Splunk
  • Macchina virtuale Windows e altre risorse di calcolo distribuite con agenti del centro operazioni per la sicurezza

DevOps

Negli ambienti regolamentati, i sistemi IT devono seguire rigorosi processi di controllo qualitativo in stile cascata, con approvazioni formali (o cancelli) tra fasi di processo, ad esempio specifiche dei requisiti utente, specifiche funzionali, progettazione e specifiche di test o simili, con documentazione di supporto estesa e dispendiosa in termini di tempo.

Lo sviluppo di ambienti di Azure e di data science seguono processi iterativi, basati sulla cultura DevOps. Un impegno significativo nel ridimensionare le iniziative di intelligenza artificiale e machine learning è dedicato alla comunicazione dei pilastri di un'organizzazione DevOps e alla creazione di mapping automatizzato di tracciabilità end-to-end tra epiche di Azure DevOps, funzionalità, storie utente, piani di test e pipeline CI/CD e entità e prove di controllo qualità necessarie.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Per dimensionare l'intelligenza artificiale e l'apprendimento automatico in ambienti regolamentati e favorire l'adozione rapida tra le aree aziendali dell'organizzazione, è consigliabile progettare e mettere in atto un framework di adozione per misurare, monitorare e valutare il valore creato dai servizi di Azure. Nell'esempio del settore sanitario e delle scienze biologiche sono state valutate le leve di valore aziendale e gli indicatori KPI indicati di seguito.

Scalabilità - Per garantire che l'architettura di Azure possa essere dimensionata sulla base dei requisiti aziendali, indipendentemente dal punto di scalabilità, sono consigliati gli indicatori KPI seguenti:

  • Numero di istanze di ambiente di calcolo e spazio di archiviazione e memoria totali usati
  • Numero di esperimenti eseguiti
  • Numero di modelli distribuiti

Accelerazione dello sviluppo di intelligenza artificiale: per accelerare lo sviluppo di soluzioni di intelligenza artificiale e Machine Learning, sono suggeriti gli indicatori KPI seguenti:

  • Numero di business unit diverse che usano i servizi di Intelligenza artificiale e Machine Learning di Azure
  • Numero di utenti di cui è stato eseguito l'onboarding per categoria, ad esempio ingegneri e scienziati dei dati, citizen data scientist e utenti aziendali
  • Numero di esperimenti eseguiti
  • Tempo tra l'onboarding degli utenti e l'uso attivo
  • Tempo necessario per effettuare il provisioning dei servizi, dalla richiesta di modifica della configurazione al completamento del provisioning del servizio

Conformità : per garantire la conformità continua delle soluzioni di intelligenza artificiale e Machine Learning distribuite, vengono suggeriti gli indicatori KPI seguenti:

  • Conformità generale con i controlli ISRM applicabili
  • Numero di avvisi di vulnerabilità di sicurezza
  • Numero di eventi imprevisti di sicurezza per l'ultimo periodo

Esperienza utente - Per garantire esperienze utente di alta qualità e coerenti, sono consigliati gli indicatori KPI seguenti:

  • Numero di richieste all’help desk da parte degli utenti
  • Net Promoter Score (NPS)

Basi sicure - Per garantire la sicurezza delle basi, sono consigliati gli indicatori KPI seguenti:

  • Tempo di attività dei servizi critici
  • Numero di eventi imprevisti segnalati e correlati alla disponibilità delle prestazioni

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

La gestione dei costi è una parte importante della progettazione nell'implementazione di piattaforme scalabili di intelligenza artificiale e Machine Learning, poiché i costi in esecuzione non seguono modelli semplici e prevedibili. Il costo dipende principalmente dal numero e dalle dimensioni degli esperimenti di intelligenza artificiale e machine learning eseguiti nella piattaforma e in particolare dal numero e dagli SKU delle risorse di calcolo usate per il training e l'inferenza del modello.

Ecco alcune procedure consigliate:

  • Assegnare ogni caso d'uso e intelligenza artificiale e prodotto di Machine Learning il proprio budget per i servizi di Azure, che è una buona procedura di gestione dei costi.
  • Definire un modello di costo trasparente per i servizi condivisi della piattaforma.
  • Usare i tag in modo coerente per associare le risorse dei casi d'uso e dei prodotti ai centri di costo.
  • Usare Azure Advisor e il servizio di budget di Azure per individuare il punto in cui le risorse non vengono usate in modo ottimale ed esaminare regolarmente le configurazioni.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

  • Eran Sagi | Progettista di soluzioni di intelligenza artificiale

Passaggi successivi

Informazioni su come eseguire il training e distribuire modelli e gestire il ciclo di vita di Machine Learning con Azure Machine Learning. Esercitazioni, esempi di codice, riferimenti alle API e altre risorse sono disponibili qui:

Informazioni su come implementare una zona di destinazione su scala aziendale per l'analisi dei dati e l'intelligenza artificiale in Azure:

Documentazione sui prodotti:

Articoli di panoramica del Centro architetture di Azure: