Architetture decisionali per contesti regolati
Perché un modello AI generalista non è ammissibile dove l'errore costa
L'inquadramento prevalente nel mercato italiano dell'integrazione AI nelle imprese regolate (studi medici, banche di nicchia, boutique fiscali) ruota intorno a una domanda sbagliata: "come adottiamo l'AI?". La domanda corretta è opposta: cosa, della nostra catena decisionale, può essere delegato a un modello, e cosa no, e perché.
Il contesto: dove l'errore costa
Esistono dominî dove un sistema di decisione automatica può sbagliare senza conseguenze rilevanti — un consiglio di abbigliamento, una raccomandazione editoriale, un'interpolazione fra parole. La ricerca sull'AI generalista degli ultimi anni si è concentrata, comprensibilmente, su questi dominî.
Esistono altri dominî, fra cui i nostri quattro principali (medicina libera professionale, ospitalità regolata, advisory patrimoniale, sostegno legale) dove un errore di sistema produce: sanzioni amministrative, responsabilità civile professionale, danno reputazionale non recuperabile, e in alcuni casi responsabilità penale. La distinzione non è di grado. È di natura.
In questi dominî, un modello generalista — qualunque LLM commerciale — non è ammissibile come decisore terminale. Lo dice non solo il buon senso operativo, ma sempre più anche il quadro regolatorio in costruzione: l'AI Act europeo (Reg. UE 2024/1689) classifica gran parte di questi usi come "alto rischio", con obblighi di trasparenza, supervisione umana e auditabilità che i modelli generalisti non soddisfano nativamente.
I cinque principi di Consistory
Costantini & Partners, attraverso il sub-cluster AI Architecture (Consistory), opera intorno a cinque principi che strutturano ogni progettazione. Sono pubblicati apertamente perché vogliamo che i potenziali clienti li conoscano prima di ingaggiarci.
Confinamento verticale
Un sistema decisionale automatico va costruito per un singolo dominio regolato, non per "casi d'uso generali". Una funzione che estrae i dati anagrafici da una tessera sanitaria italiana è separata, architetturalmente, da una funzione che valida un codice IBAN. Sembra ovvio. Non lo è in pratica. La tentazione di costruire "agenti che fanno tutto" è quasi sempre l'origine dei sistemi che falliscono in produzione.
Validazione deterministica dell'output
Ogni output di un modello viene confrontato con un validator deterministico prima di essere accettato. Il modello propone, il validator dispone. Per il codice fiscale italiano: una regex più la verifica del check digit. Per uno schema XML Sogei: validazione XSD. Per una data: parsing strict e range check. Se il validator fallisce, il sistema non chiede di nuovo al modello — lo segnala all'umano. Il modello non è il giudice della sua stessa output.
Supervisione esibita, non implicita
L'AI Act richiede "supervisione umana effettiva" sui sistemi ad alto rischio. La supervisione effettiva non è una checkbox firmata dall'utente. È una interfaccia che mostra, per ogni decisione automatica significativa, l'input ricevuto, l'output proposto, la confidenza del modello, e che richiede un'azione attiva di accettazione o correzione. Il design dell'interfaccia è un elemento sostanziale del compliance, non cosmetico.
Local-first quando i dati sono sensibili
Quando il dominio implica trattamento di dati sensibili (sanitari, di pubblica sicurezza, finanziari), l'inferenza del modello deve avvenire dove i dati risiedono — sul dispositivo del cliente. Modelli piccoli specializzati (sub-7B) eseguiti localmente sono ormai tecnicamente fattibili e cambiano sostanzialmente il profilo GDPR del fornitore. Quando questo non è praticabile, l'alternativa è il cloud OCR con contratto art. 28 specifico (cfr. il nostro DPA pubblico).
Auditabilità permanente
Ogni decisione automatica significativa produce un log immutabile (timestamp, input hash, output hash, identità del modello, identità dell'umano che ha confermato). Il log è esportabile dal cliente. È la condizione per poter rispondere in modo difensivo a qualunque indagine successiva delle autorità di vigilanza, dell'ASL, della Polizia di Stato, di un giudice. Senza log permanenti il sistema non è auditabile e quindi non è ammissibile.
Cosa significa operativamente
I cinque principi si traducono in scelte tecniche specifiche che il cliente può verificare prima di ingaggiarci. Tre esempi.
Esempio 1 — OCR documentale. La tessera sanitaria italiana ha un retro standardizzato. Il sistema decisionale corretto qui non è un LLM multimodale generalista. È un OCR specializzato (Google Cloud Vision, Apple Vision API, o Tesseract con dictionary CF), seguito da un validator deterministico del CF (regex + check digit), seguito da una user confirmation UI. Architettura semplice, auditabile, conforme.
Esempio 2 — Classificazione tributaria di una prestazione sanitaria. La codifica della prestazione ai fini Sistema TS ha un set chiuso di codici (codice prestazione, opposizione, riconducibilità). Un LLM può proporre la classificazione a partire dalla descrizione della prestazione, ma la accettazione finale è dell'utente medico, e il sistema mostra esplicitamente l'alternativa più plausibile per consentire correzione. L'output è loggato permanentemente con la combinazione modello-utente.
Esempio 3 — Anomalia in un flusso di schedine Alloggiati. Un classificatore può segnalare schedine "sospette" (codice documento improbabile, data nascita incoerente con maggiore età, ecc.). La segnalazione è un alert all'umano, non un blocco automatico. L'umano decide. Il sistema registra la decisione per audit successivo.
Quello che non facciamo
Per chiarezza, alcuni casi d'uso che riteniamo non ammissibili nel nostro framework e per i quali non accettiamo mandato:
- Chatbot di assistenza che rispondono autonomamente a pazienti, ospiti o clienti senza supervisione umana attiva
- Sistemi di triage medico, anche solo "decisionali assistiti", su pazienti reali (l'AI Act li classifica espressamente ad alto rischio)
- Generatori di documenti legali firmabili senza revisione professionale per cliente non avvocato
- Sistemi di credit scoring o decisione finanziaria automatica su persone fisiche
- Riconoscimento facciale in qualsiasi forma, salvo controllo accessi del proprietario sul proprio dispositivo
L'elenco non è esaustivo. È indicativo dell'orientamento.
Per concludere
La pratica di Consistory non è "consulenza AI". È architettura di sistemi decisionali per ambiti dove l'errore costa, costruiti con metodo. Il fatto che il cuore di questi sistemi sia oggi spesso un modello statistico addestrato è un dettaglio tecnico, importante ma non centrale. Il centro è il frame intorno al modello: il confinamento verticale, il validator deterministico, la supervisione esibita, il local-first, l'auditabilità permanente.
Costruire questo frame richiede competenze giuridiche, tecniche e operative in proporzioni equilibrate. È la combinazione di Costantini & Partners come holding, e il motivo per cui AI Architecture è una delle cinque practice della casa, non un'aggiunta posticcia.