Progettare il data processing e il grounding
Il grounding data è l’informazione fornita al modello al momento dell’inferenza per generare risposte pertinenti alla domanda dell’utente: non faceva parte dell’addestramento e viene combinata con la query per costruire il prompt. La Well-Architected Framework per i carichi AI distingue quattro tipi di dato che un architetto deve tenere separati: source data (i dati di produzione, strutturati, semi-strutturati o non strutturati), il grounding data vero e proprio, le behavioral instructions (che influenzano stile e comportamento e alimentano semmai un fine-tuning) e gli user data, cioè i dati di turno della conversazione, da conservare per il tempo minimo necessario e idealmente da distruggere a fine sessione.
La prima decisione architetturale non è quale modello usare, ma se interrogare direttamente il sistema di origine o esternalizzare i dati in un search index. La raccomandazione è esternalizzare: si modella la copia secondo le query attese, si evita di caricare il sistema primario e si garantisce disponibilità. Ma il compromesso è esplicito: interrogare il database di origine semplifica la sicurezza, perché in un indice condiviso il security trimming — filtrare i risultati in base a ciò che l’utente è autorizzato a vedere — è complesso e soggetto a errori.
Prendiamo un vincolo concreto. Una compagnia assicurativa vuole un agente che risponda su polizze e sinistri, con l’obbligo che un liquidatore non veda mai documenti di un ramo che non gestisce. In Microsoft Copilot Studio le knowledge source non sono equivalenti su questo punto: SharePoint e OneDrive, le Dataverse tables e i Graph connectors usano autenticazione delegata Microsoft Entra ID e restituiscono solo contenuti che l’utente ha diritto di leggere; una knowledge source Azure AI Search collegata non è delegata, quindi non c’è security trimming né requisito di autenticazione per l’utente. Il vincolo di autorizzazione, non la qualità del retrieval, decide qui l’architettura.
Restano tre scelte da governare. Il chunking contro il full-document grounding: passare l’intero documento aumenta l’accuratezza ma consuma molti token, aumenta la latenza e si scontra con la context window; suddividere è più flessibile ma perde accuratezza se i chunk sono progettati male. La freschezza: si misura la finestra fra creazione o modifica del dato di origine e il suo ingresso nell’indice, e si confronta con gli SLO. E il deployment dell’indice: la strategia side-by-side, con il nuovo indice che convive con quello esistente finché non è testato, contro l’in-place update, più economico ma rischioso. Il Cloud Adoption Framework aggiunge una regola di priorità per gli agenti: usare come standard di default le capacità di retrieval integrate — Foundry IQ in Microsoft Foundry, Fabric IQ, la connessione SharePoint, Azure AI Search — e scegliere MCP quando l’agente deve compiere azioni o leggere dati in tempo reale, per esempio la giacenza attuale di uno SKU. Ogni dominio di dati va documentato con il metodo di retrieval scelto e il perché.
Componenti AI dentro una canvas app di Power Apps
Nella canvas app i modi documentati per inserire intelligenza sono distinti e la scelta fra loro è una decisione di processo, non di interfaccia. I componenti AI Builder si dividono in due famiglie: quelli che usano modelli prebuilt, pronti all’uso (business card reader, receipt processor, text recognizer), e quelli che usano modelli custom, che vanno costruiti, addestrati e pubblicati (form processor e object detector). Accanto ai componenti c’è il consumo dei modelli tramite Power Fx dalla barra della formula, funzionalità dichiarata in preview, e l’invocazione di un custom prompt aggiunto come origine dati e chiamato come funzione con .Predict.
Vincolo esplicito: un’azienda vuole automatizzare le note spese entro il trimestre e non ha un set di documenti etichettati da usare per l’addestramento. La risposta è receipt processing, prebuilt; document processing è custom e richiederebbe training, quindi entra nel ciclo ALM di solution ed environment prima di poter essere rilasciato. È esattamente il tipo di compromesso build contro buy che l’esame formula.
Un’ultima distinzione che confonde spesso. L’agent builder in Power Apps genera un agente dai metadati dell’app e dall’obiettivo dichiarato, estraendone istruzioni, knowledge e trigger, ma poi l’agente si modifica, si testa e si pubblica in Copilot Studio: la superficie di costruzione cambia a metà percorso. E sul piano di governance, disattivare Copilot a livello tenant lo disattiva solo per i maker: non spegne il Copilot control della canvas app.
Il Well-Architected come vocabolario dei compromessi
Il Microsoft Power Platform Well-Architected Framework poggia su cinque pilastri: Reliability, Security, Operational Excellence, Performance Efficiency ed Experience Optimization, quest’ultimo unico rispetto alla Azure Well-Architected Framework da cui derivano gli altri quattro. Il percorso è sempre lo stesso: design principles, poi checklist, poi recommendation guide; tradeoff e rischi sono segnalati con icone dedicate. Non esiste una checklist separata per i carichi di tipo intelligent application: si applicano i cinque pilastri a quel carico, perché valgono per tutte le classi di workload.
Qui sta il valore d’esame. La raccomandazione PE:03, Select the right services, dice di preferire le funzionalità di piattaforma al codice custom, che aggiunge complessità; il principio Keep it simple di Reliability dice di non sovraingegnerizzare. I tradeoff pubblicati sono altrettanto espliciti: Security contro Reliability significa più dipendenze critiche e più rischio di misconfigurazione; Security contro Experience Optimization significa attrito, perché la classificazione dei dati rende più difficile trovarli e consumarli; Security contro Performance Efficiency significa latenza e overhead aggiunti dai controlli di ispezione. Attenzione a una trappola: Cost Optimization non è un pilastro del Power Platform Well-Architected. Il costo compare come tradeoff dentro gli altri pilastri — abilitare filtro, ricerca e ordinamento su molti campi dell’indice aumenta lo spazio e quindi la spesa — e chi arriva dalla Azure Well-Architected Framework tende a cercare un pilastro che qui non c’è. Quando una domanda oppone affidabilità e costo, la risposta si costruisce nominando il pilastro pertinente e il compromesso documentato, non improvvisando una gerarchia.