Una risposta dell’IA può sembrare precisa e, tuttavia, essere inadeguata per operare su un sistema. Il fatto che classifichi una richiesta come urgente, suggerisca di completare un campo o raccomandi di avviare un flusso non significa che disponga dell’autorizzazione, di un contesto sufficiente o che rispetti le regole di business. Il rischio emerge quando un suggerimento testuale o strutturato viene trasformato in un comando eseguibile senza barriere indipendenti.
Per validare gli output strutturati dell’IA in PHP, è opportuno trattare il modello come un componente che prepara proposte, non come un’autorità che modifica record, assegna responsabili, invia comunicazioni o avvia processi. L’applicazione mantiene la decisione, applica le proprie regole e registra perché una proposta è stata accettata, corretta o rifiutata.
Un output plausibile non è un’istruzione valida
I modelli possono restituire JSON sintatticamente corretto e, nonostante ciò, includere una priorità inesistente, un identificatore che non corrisponde al cliente, una data impossibile o un’azione che l’utente non può richiedere. Possono inoltre completare dati non presenti nell’input, interpretare erroneamente un’ambiguità o seguire un formato precedente dopo una modifica del contratto.
Il limite operativo deve essere esplicito: l’IA può proporre un’azione e spiegare i dati che ha utilizzato; il sistema decide se tale proposta diventa una bozza, richiede revisione o può essere eseguita in condizioni molto circoscritte. Questa separazione protegge sia l’integrità dei dati sia la responsabilità della decisione.
Un buon punto di partenza è classificare ogni azione in base all’impatto:
- Basso impatto: etichettare una bozza, suggerire una categoria o estrarre campi non critici.
- Impatto medio: creare un’attività in sospeso, proporre un responsabile o preparare una risposta per la revisione.
- Alto impatto: modificare stati contrattuali, assegnare lavoro irreversibile, modificare importi, eliminare dati, comunicare all’esterno o attivare processi sensibili.
L’autonomia ammissibile non dipende dal fatto che l’IA dichiari un’elevata confidenza. Dipende dalla reversibilità, dal costo di un errore, dalla qualità verificabile dei dati e dall’esistenza di controlli esterni al modello.
Definire un contratto di proposta prima di integrare il modello
Il contratto di output definisce ciò che il componente IA può proporre e ciò che resta fuori dal suo ambito. Deve essere piccolo, tipizzato e versionato. Invece di chiedere “decidi cosa fare con questa richiesta”, specificate un elenco chiuso di azioni e i campi necessari per ciascuna.
{
"version": "1",
"action": "create_task_draft",
"category": "billing",
"priority": "normal",
"summary": "Revisione discrepanza in fattura",
"sourceReferences": ["message:123"],
"confidence": 0.82
}L’elenco delle azioni deve utilizzare valori controllati, ad esempio create_task_draft, request_more_information o no_action. Non è opportuno accettare nomi di metodi, query, frammenti di codice, destinatari liberi né istruzioni del tipo “aggiorna l’ordine”. L’applicazione traduce un’azione consentita in una specifica operazione interna.
Campi, stati ed evidenze
Oltre a tipi e valori consentiti, il contratto deve indicare quali campi sono obbligatori, quali combinazioni sono incompatibili e quali evidenze deve fornire la proposta. Una categoria può essere valida, ma richiedere almeno un riferimento al messaggio o al documento di origine. La confidenza, se raccolta, è un dato ausiliario per ordinare le revisioni; non sostituisce una validazione.
Versionare lo schema consente di rifiutare in sicurezza gli output di contratti ritirati. Se una modifica aggiunge un campo obbligatorio o ritira un’azione, l’adattatore deve riconoscere la versione ed evitare interpretazioni implicite.
Applicare quattro barriere prima di qualsiasi effetto
La validazione deve avvenire in livelli separati. Un fallimento in un livello non è compensato da una risposta apparentemente ragionevole in un altro.
- Formato: verificare che la risposta possa essere decodificata, che rispetti lo schema previsto, che non contenga campi critici inattesi e che ogni valore abbia il tipo corretto. Un JSON non valido, un’enumerazione sconosciuta o un campo obbligatorio mancante vengono rifiutati.
- Dominio: verificare le regole proprie dell’applicazione. Ad esempio, che la categoria esista, che la priorità sia applicabile al tipo di richiesta, che l’account indicato sia attivo e che il riferimento di origine appartenga al contesto elaborato.
- Autorizzazione: verificare cosa può fare l’attore che ha avviato il flusso e quali permessi richiede l’operazione. L’IA non eredita privilegi illimitati né decide l’ambito di accesso. Il server applica l’identità, il tenant e le policy vigenti.
- Condizioni operative: controllare concorrenza, stati attuali, limiti, dipendenze e idempotenza. Una proposta valida potrebbe non essere eseguibile se il caso è già stato chiuso, un altro processo ha modificato il record o è stata superata una soglia di carico.
La validazione semantica deve consultare fonti di verità interne. Non basta che il modello restituisca un identificatore ben formato: il repository o il servizio di dominio deve verificarne l’esistenza, l’appartenenza e lo stato. Evitate che la risposta del modello trasporti dati di autorizzazione che l’applicazione può risolvere autonomamente.
Architettura PHP: proposta, decisione ed esecuzione separate
Un’architettura manutenibile separa le responsabilità. L’adattatore IA prepara la richiesta, applica limiti di dimensione e ottiene un output; non scrive nel database di business. Un DTO rappresenta la proposta già sottoposta a parsing. Il validatore di dominio trasforma tale proposta in una decisione con errori espliciti. Infine, un esecutore autorizzato applica solo decisioni approvate.
final class ActionProposal {
public function __construct(
public string $action,
public string $category,
public string $priority,
public array $sourceReferences,
) {}
}
$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);
if (!$validation->isApproved()) {
$auditLog->recordRejected($proposal, $validation->reasons());
return $validation;
}
return $decisionService->route($validation->approvedProposal(), $context);Il servizio decisionale può creare una bozza, inserirla in una coda di revisione o richiedere approvazione umana. L’esecutore finale deve ricevere un oggetto decisionale interno, non la risposta grezza né il JSON dell’IA. In questo modo si evita che un’estensione accidentale del contratto si trasformi in una nuova capacità operativa.
Utilizzate transazioni per modifiche correlate, chiavi di idempotenza per i tentativi ripetuti e controlli di concorrenza quando più persone o processi possono agire sullo stesso caso. Distinguete anche il deployment dall’attivazione: il codice può essere distribuito senza esporre il flusso a utenti reali. Un’attivazione graduale consente di osservare rifiuti, tempi e correzioni prima di ampliarne l’ambito.
Scegliere revisione umana, automazione limitata o rifiuto
La revisione umana è appropriata quando vi sono ambiguità rilevanti, dati sensibili, conseguenze esterne, eccezioni di policy o costi elevati di correzione. L’interfaccia di revisione dovrebbe mostrare la proposta, l’evidenza di origine consentita, le regole superate e i motivi di allerta, senza presentare la raccomandazione come un fatto.
L’automazione limitata può essere ragionevole per operazioni reversibili e circoscritte: creare una bozza non assegnata, applicare un’etichetta provvisoria o instradare una richiesta verso una coda generale. Deve prevedere limiti di frequenza, possibilità di annullamento e supervisione successiva. Se mancano dati, vi è un conflitto tra regole o l’azione è al di fuori dell’elenco consentito, il comportamento sicuro è rifiutare o inoltrare a un livello superiore, non improvvisare.
Prima di usare l’IA, valutate un’alternativa deterministica. Se gli input seguono schemi stabili, regole, moduli guidati, elenchi di selezione o un classificatore convenzionale possono essere più economici, verificabili e prevedibili. Quando si usa l’IA, definite il caso d’uso, un set di valutazione rappresentativo, soglie operative, costo per volume e una modalità di degrado nel caso in cui il fornitore fallisca o superi il tempo previsto.
Esempio: convertire una richiesta in una bozza di attività
Supponete una richiesta in entrata che menzioni una discrepanza in una fattura. L’IA può proporre la categoria billing, priorità normale e il riepilogo di un’attività. Il validatore verifica che il messaggio appartenga al tenant corrente, che la categoria sia abilitata e che non esista già un caso aperto con lo stesso riferimento. Se tutto è corretto, il sistema crea una bozza senza assegnare un responsabile né modificare lo stato della fattura.
Un operatore esamina la bozza, conferma o corregge la categoria e decide l’assegnazione in base al carico e ai permessi vigenti. Questa distinzione impedisce che un’inferenza plausibile su un responsabile o un importo si trasformi in una modifica errata. Se il contratto richiede un numero di fattura e questo non compare nel messaggio, la proposta deve richiedere informazioni aggiuntive, non inventarlo.
Tracciabilità, privacy e test prima di ampliare il flusso
Registrate un identificatore di correlazione, la versione del contratto, un’impronta o un riferimento dell’input minimizzato, la proposta normalizzata, i risultati di ogni validazione, la decisione finale, l’attore approvatore quando presente e il motivo del rifiuto. Il registro deve essere utile per investigare incidenti senza duplicare dati personali o contenuti sensibili non necessari. Applicate retention, accesso ristretto e tecniche di minimizzazione adeguate al rischio del processo.
Testate il flusso con casi rappresentativi e avversi: input incompleti, istruzioni contraddittorie, valori inventati, riferimenti di un altro tenant, cambiamenti di stato concorrenti, risposte in formato precedente, latenza e assenza del servizio IA. I criteri di accettazione devono misurare se le operazioni non autorizzate vengono bloccate, se le bozze sono recuperabili, se i rifiuti sono comprensibili e se il sistema mantiene un’alternativa funzionante in caso di guasti.
Un’operatività sicura non consiste nell’ottenere che il modello risponda sempre. Consiste nel garantire che, quando risponde in modo errato, impiega troppo tempo o non risponde, l’applicazione PHP mantenga il controllo e non produca effetti che non possa giustificare.
