Errori nel legal prompting: come evitarli – IA e Avvocati (20)
Intelligenza artificiale e Avvocati
Scrivere prompt per un modello linguistico di grandi dimensioni (LLM) non è un esercizio di stile: è progettazione.
Quando il destinatario è un sistema che genera contenuti con ricadute professionali, ogni ambiguità si moltiplica.
Questo articolo propone una bussola pratica per l’avvocato che desidera risultati coerenti, verificabili e riutilizzabili: prima mappiamo gli errori più frequenti, poi vediamo come prevenirli con pattern semplici da applicare, come controllare i prompt prima dell’invio e come “recuperare” quando l’output deraglia.
1. Gli errori tipici
🧭
Ambiguità di partenza. Un collega chiede al modello: “Spiegami questa sentenza e dimmi se posso usarla nel ricorso”. Il sistema risponde con un riepilogo corretto, ma ignora il tema dell’utilizzabilità, perché il prompt non definisce ruolo, obiettivo e vincoli.
Task confusi nella stessa richiesta. Capita spesso di voler ottenere sintesi, validazione e proposta di modifica in un’unica battuta. L’effetto è un testo lungo, con parti ripetute e conclusioni oscillanti. In questi casi la soluzione non è “scrivere di più”, ma separare gli step: prima la sintesi, poi il controllo, poi le opzioni di intervento.
Assenza di formato. Un parere generato “a testo libero” può sembrare elegante, ma è fragile: come lo archivi? come lo confronti con casi simili? come estrai le citazioni? Senza uno schema di output (sezioni, tabella o JSON) perdi riuso e controllo.
Contesto insufficiente. “Redigi una bozza di lettera di contestazione disciplinare” senza fatti, date, CCNL ecc. equivale a chiedere un modulo vuoto. Il modello può riempirlo con assunzioni implicite: utile per ispirazione, pericoloso per un documento da inviare.
Sovra‑istruzioni e sotto‑istruzioni. A volte carichiamo il prompt con regole in ogni riga (over‑prompting) e il modello resta intrappolato; altre volte diamo quattro parole vaghe (under‑prompting) e l’output diventa imprevedibile. L’equilibrio sta nell’essenzialità mirata: poche regole, espresse bene, accompagnate da un esempio positivo e uno negativo.
Fonti assenti. Un testo senza citazioni non è riusabile in contesti legali. Le fonti non servono per “abbellire” il risultato, ma per tracciarlo: norme, sentenze, circolari – con estremi e, se disponibile, link alla base documentale o al vostro RAG.
Prompt fiume senza marcatori. Anche un buon contenuto si perde se non è sezionato. I marcatori (titoli brevi, elenchi, separatori) aiutano il modello a “capire” e l’umano a verificare.
⚠️ Mini‑casi di insuccesso
• Ambiguità iniziale → output generico → bozza inutilizzabile.
• Task multipli in un prompt → risposte contraddittorie → rilanci e perdita di tempo.
• Assenza di formato → testo non strutturato → impossibilità di essere letto automaticamente da software → nessuna possibilità di riutilizzo tramite librerie o sistemi di automazione.
• Contesto insufficiente → assunzioni implicite → rischio errore.
• Over/under‑prompting → blocco o deriva → qualità incostante.
• Fonti assenti → contenuto non verificabile → rischio professionale.
• Prompt fiume → parti rilevanti ignorate → revisione lenta.
• Chiarezza prima della lunghezza.
• Formato e fonti sono parte del compito, non accessori.
• Se il prompt non si può verificare, l’output non si può usare.
2. Come rendere robusto un prompt: un metodo che non ingombra
🛠️
Il nostro riferimento è R‑CAFAR, con una sua versione “compatta” che non appesantisce la scrittura:
Ruolo. “Sei un avvocato giuslavorista italiano che redige contestazioni disciplinari per aziende del settore {settore}.” Un ruolo chiaro riduce l’uso di formule generiche.
Contesto con fatti essenziali. Indicate materia, sottotema, foro o ambito, documenti a supporto. Meglio poche righe ma dense di dati che paragrafi narrativi.
Finalità (il deliverable). Non “parlami di…”, bensì “consegna una bozza con 6 sezioni e una tabella rischi/azioni”. Se potete, aggiungete i criteri di accettazione: quando considererete “buona” la risposta?
Richieste specifiche su formato e citazioni. Scegliete tra Markdown, Tabella o JSON; indicate lo schema (campi obbligatori, ordine, limiti di lunghezza). Pretendete citazioni con estremi. Se usate un RAG, aggiungete: “collega ogni citazione a un source_id”.
Aggiornamento e confini. Chiarite gli orizzonti: “Se non hai il testo integrale del provvedimento, fermati e chiedi integrazioni prima di procedere.” Queste sono le vostre stop rules.
📎 Schema citazionale uniforme (da includere nel prompt e nell’output).
- Norme nazionali:
art. [n] [codice/legge] ([anno])es.art. 1373 c.c.;art. 7 L. 300/1970. - Norme UE:
Reg. (UE) [anno]/[numero], art. [n]. - Giurisprudenza:
Cass., Sez. [___], n. [____]/[anno];Cons. St., Sez. [___], n. [____]/[anno]; per merito:Trib. [Città], [data], n. [____]. - Prassi/atti amministrativi:
Circolare Min. Interno n. [__] del [gg/mm/aaaa]. - Fonti/RAG:
fonte: [URL]oppureRAG: source_id=[...].
Questa struttura non allunga il prompt: lo rende leggibile. E se domani dovete riutilizzarlo, troverete tutto dove ve lo aspettate.
🎯 Principio guida
Un prompt robusto non è solo strutturato: è progettato per minimizzare i fattori d’errore. Ogni incarico professionale richiede struttura, verifica e correzione sistematica.
• R‑CAFAR compatto = meno errori ricorrenti.
• Lo schema dell’output è il vostro “contratto” con l’LLM.
• Le stop rules proteggono qualità e tempi.
3. Il controllo pre‑invio che fa risparmiare ore
✅
Checklist lampo
- Deliverable in 1 riga (cosa deve consegnare l’LLM).
- Fatti minimi presenti.
- Formato + schema citazionale obbligatori.
- Fallback strategy esplicita (se manca X → chiedi Y).
Prima di premere “Invio”, fatevi queste domande:
- Che cosa sto chiedendo esattamente? Se non sapete descrivere il deliverable in una riga, il modello faticherà il doppio.
- Ho fornito i minimi vitali? Fatti, documenti, parti, ambito/foro, norme applicabili, scadenze…
- In che forma voglio l’output? Sezioni, tabella o JSON, con limiti di lunghezza per evitare tagli.
- Le citazioni sono obbligatorie? Se sì, indicate formato e, se possibile, la base da cui attingere.
- E se mancano dati? Concepite una fallback strategy: “Se manca X, ferma il lavoro e chiedi Y”.
- Limiti numerici chiari (token/word): • Parere breve: 700–900 parole (hard stop ≤ 1.500 token). • Executive summary: 150–200 parole. • JSON: ogni campo testuale ≤ 120 parole, niente testo libero fuori schema. • Tabelle: ≤ 12 righe x 5 colonne (oltre, segmenta in più tabelle).
Trasformare queste domande in un piccolo form interno è il modo più efficace per standardizzare la qualità in studio.
• Una riga di deliverable vale più di dieci righe di contesto.
• Numeri espliciti (parole/token/righe) evitano tagli e divagazioni.
• La fallback strategy fa risparmiare scambi inutili.
4. Un generatore guidato che non fa perdere tempo
🧩
Qui sotto trovate un template. È conciso e pretende l’essenziale.
Compilandolo, evitate da soli l’80% degli errori sopra descritti.
### RUOLO
{ruolo}
### CONTESTO
{materia} – {sottotema} – Foro/ambito: {foro}
### ATTORI E FATTI
Parti: {parti}. Fatti essenziali: {fatti}. Documenti: {documenti}
### FINALITÀ
{deliverable_descrizione} (criteri di accettazione: {criteri})
### VINCOLI E STILE
Citazioni: {si_no}+formato. Tono: {tono}. Esclusioni: {esclusioni}
### FORMATO DI OUTPUT
{markdown_o_tabella_o_json}
### LIMITI DI LUNGHEZZA
Parere: 700–900 parole (≤ 1.500 token). Executive summary: 150–200 parole. JSON: ogni campo testuale ≤ 120 parole; nessun testo fuori JSON. Tabelle: ≤ 12 righe x 5 colonne.
### SCHEMA DI CITAZIONE (uniforme)
Norme nazionali: "art. [n] [codice/legge] (anno)"; Giurisprudenza: "Cass., Sez. [__], n. [__]/[anno]" o "Trib. [Città], [data], n. [__]"; Prassi: "Circolare Min. Interno n. [__] del [gg/mm/aaaa]"; UE: "Reg. (UE) [anno]/[numero], art. [n]"; Fonti/RAG: URL o "RAG: source_id=[...]".
### ESEMPI (Do/Don't)
Do: {esempio_buono}
Don't: {esempio_cattivo}
### STOP RULES
Se mancano {campi_critici} → fermati e chiedi integrazioni
Come usarlo: salvate questo modello come “Prompt card” in libreria.
📝 Esempi per materia
- Civile
Sì: “Valuta questa clausola di recesso B2B con tabella rischi/proposte e citazioni (es. art. 1373 c.c.).”
No: “Commenta questa clausola.” - Lavoro
Sì: “Bozza contestazione ex art. 7 L. 300/1970 in JSON, conrichiamo_normativo“
No: “Scrivi una lettera disciplinare.” - Penale
Sì: “Schema memo su cause di giustificazione per {fattispecie}, 6 bullet con articoli e massime essenziali.”
No: “Spiegami la legittima difesa.”
5. Quando l’output deraglia: diagnosi e recovery
🩺
Diagnosi rapida. Chiedetevi: cosa manca? contesto? formato? ci sono istruzioni in conflitto? Quasi sempre il problema è qui.
🔁 Mini‑flowchart di correzione
Output manca di FONTI? → Aggiungi schema citazionale + richiedi RAG/source_id → Rilancia
↓ No
Output fuori FORMATO? → Imposta schema (MD/Tabella/JSON) + limiti numerici → Rilancia
↓ No
Mancano CONTESTO/FATTI? → Inserisci fatti minimi + stop rule → Rilancia
↓ No
ISTRUZIONI in conflitto? → Separa task (analisi / proposte / redazione) → Rilancia
Correzione incrementale. Aggiungete uno o due vincoli mirati, inserite un esempio positivo, oppure separate i task (prima analisi, poi proposte). Evitate riscritture integrali finché la diagnosi non è completa.
🔍 Verifica automatica. Lanciate l’output in un mini‑prompt di controllo: “Verifica che siano presenti le 6 sezioni, che ogni affermazione riporti la fonte e che il testo non superi 900 parole. In caso contrario, elenca i problemi senza riscrivere”.
🕵️ Prompt di autoverifica (da eseguire dopo l’output)
Sei un validatore AI legal, incaricato di una revisione finale dell’output. Dopo la produzione del testo, esegui questi controlli:
1. Struttura e Formato
Sono presenti tutte le sezioni richieste?
Il formato richiesto (Markdown, Tabella, JSON, narrativa, allegati) è rispettato integralmente?
2. Citazioni e Fonti
Ogni affermazione è supportata da fonte normativa, giurisprudenziale o RAG [source_id], come prescritto?
Le fonti sono conformi allo schema citazionale prescritto?
Sezione finale riepilogativa delle fonti (se richiesta)?
3. Limiti Quantitativi
Sono rispettati i limiti di parole/token e le dimensioni delle tabelle (righe × colonne)?
I campi dei JSON non superano i 120 parole come da specifica?
4. Copertura e Completezza
Tutti i fatti minimi e le istruzioni del prompt sono stati rispettati e coperti sintatticamente e semanticamente in modo corretto?
Gli edge case sono stati gestiti (se richiesto)?
5. Spiegabilità e Trasparenza
Sono state indicate eventuali limitazioni informative, incertezze o rischi di interpretazione? (Esempio: normativa non aggiornata, casistica controversa ecc.)
L’output cita la versione modello, il log interazione, e la data/generazione (se richiesto)?
6. Non Conformità e Audit
Elenca con precisione tutte le non conformità, omissioni, errori formali, o superamenti dei limiti.
Indica se serve riesame umano o audit ulteriore.
Restituisci esclusivamente in questo formato:
json
{
"esito": "OK" / "KO",
"violazioni": [
"Elenco puntuale di tutte le violazioni riscontrate (puoi usare marcatori numerici o elenco puntato)"
],
"azioni_consigliate": [
"Massimo 3 azioni pratiche da suggerire al revisore o al sistema"
],
"log": {
"modello": "nome e versione IA",
"versione_prompt": "data/ID interno",
"timestamp_output": "data e ora",
"autore revisione": "opzionale"
}
}
Non riscrivere o parafrasare il testo revisionato. Limita la risposta al solo report strutturato come sopra.
🗂️ Logging. Annotate in libreria che cosa non ha funzionato e come lo avete corretto. La prossima volta, partirete già un passo avanti.
• Prima si diagnostica, poi si riscrive.
• La verifica post‑output evita errori ricorrenti.
• Ogni risultato imprevisto contribuisce ad affinare la vostra libreria.
6. Tre casi pratici
📚
A) Civile/contratti – Clausola di recesso
Prima. “Analizza questa clausola di recesso e dimmi se va bene.” Il modello produce considerazioni generiche sul recesso, senza distinguere ad nutum e per inadempimento, senza misurare il rischio, senza indicare alternative.
Dopo. Stessa richiesta, ma strutturata: ruolo (avvocato civilista B2B), contesto (contratto di fornitura, recesso unilaterale del fornitore), fatti minimi (es. durata 24 mesi, preavviso 15 giorni…), finalità (valutazione di validità + rischi + proposte), formato tabellare con colonne “profilo/valutazione/fonte‑citazione/rischio/proposta”, vincoli (articoli del c.c., giurisprudenza, evidenza di eventuali clausole vessatorie) (es. art. 1373 c.c.; Cass., Sez. _, n. _/_), limiti (tabella ≤ 12 righe; testo argomentativo ≤ 400 parole; hard stop ≤ 1.500 token), stop rules (se mancano il testo integrale e l’indicazione B2B/B2C, fermati e chiedi). Perché funziona. Avete trasformato una richiesta vaga in un compito verificabile e orientato all’azione.
B) Lavoro – Lettera di contestazione disciplinare (output JSON)
Obiettivo. Preparare una bozza di contestazione disciplinare che rispetti l’art. 7 dello Statuto dei lavoratori e il CCNL applicabile, pronta per alimentare un sistema documentale.
Come si imposta. Ruolo chiaro; ambito (settore e sede); fatti con data, luogo, condotta addebitata; finalità (bozza) e schema JSON con campi obbligatori (intestazione, oggetto, richiamo normativo, fatti, diritti difensivi, firma, allegati). Limiti: nessun testo fuori JSON; ogni campo testuale ≤ 120 parole; output complessivo ≤ 1.500 token. Schema citazioni: norme in forma art. 7 L. 300/1970; CCNL CCNL [settore], art. [n]; fonte: [URL] o RAG: source_id=[...]. Perché il JSON. Vi consente di controllare che ogni campo essenziale sia presente. Se manca qualcosa, il validatore ve lo segnala subito.
C) Immigrazione – Parere su diniego cittadinanza (tabellare)
Situazione. Un cliente ha ricevuto un diniego della domanda di cittadinanza italiana jure sanguinis per carenza di prova della linea materna. Vi servono opzioni chiare, con pro e contro.
Impostazione. Ruolo (avvocato immigrazionista italiano), contesto (Prefettura X, motivazione del diniego, documenti disponibili), finalità (parere con opzioni), formato tabellare con colonne “quesito/fonte/valutazione/rischi/prossimi passi”, schema citazioni come sopra (es. L. 91/1992), limiti (tabella ≤ 10 righe, testo esplicativo ≤ 700 parole). Vantaggio. In un’unica vista potete condividere il quadro con il cliente e decidere la strategia.
7. Una mappa rapida: dall’errore alla soluzione
🗺️
| Errore frequente | Come lo correggo subito |
|---|---|
| Ruolo assente o generico | Apri il prompt con “Sei un avvocato italiano … [materia] … [contesto]”. |
| Obiettivo vago | Formula un deliverable con criteri di accettazione. |
| Mancanza di formato | Imponi Markdown con sezioni, tabella o JSON con schema. |
| Contesto insufficiente | Elenca fatti, atti, parti, foro, documenti allegati. |
| Troppe/pochissime istruzioni | Mantieni poche regole chiare + un esempio Do/Don’t. |
| Fonti assenti | Richiedi citazioni con schema uniforme e, se possibile, link al RAG. |
| Prompt fiume | Inserisci titoli brevi, elenchi, separatori. |
💡 Un prompt robusto non è “più lungo”, è più chiaro. Riduce i gradi di libertà solo dove serve e lascia spazio all’analisi dove è utile.
8. Conformità, riservatezza, governance
⚖️
L’uso professionale dell’IA non è solo efficienza, è governance.
Tenete traccia dei prompt (chi li ha scritti, quando, su quale caso), conservate le versioni, annotate gli esiti.
Prevedete sempre una revisione umana prima dell’invio al cliente o del deposito, e adottate regole chiare sui dati: anonimizzazione nei test, niente dati personali in servizi cloud non contrattualizzati, preferenza per l’inferenza locale quando basta.
♻️ Miglioramento continuo
Programmate una retrospettiva mensile sui failure_mode emersi nel Registro errori: aggiornate i template, aggiungete esempi Do/Don’t e tarate i limiti numerici dove servono.
KPI di qualità (per audit interno)
Usali come micro-rubrica (0–2) per ogni consegna AI; soglia consigliata: ≥ 8/10.
| KPI | Definizione | Scala | Soglia minima (KPI) | Note revisioni |
|---|---|---|---|---|
| Copertura fatti | Fatti minimi presenti e corretti | 0 = assente 1 = parziale 2 = completa | 2 | Se <2 indica errori o omissioni gravi |
| Formato | Rispetto rigoroso schema richiesto (MD/tabella/JSON) | 0 = assente 1 = parziale 2 = conforme | 2 | Focus su output condivisibile |
| Citazioni | Completezza, correttezza e schema uniforme | 0 = assente 1 = parziale 2 = completa | 2 | Fonti e articoli sempre specifici |
| Coerenza logica | Assenza errori o contraddizioni | 0 = errori 1 = minimi 2 = nessuno | 2 | Logica argomentativa, coerenza |
| Revisione umana | Tempo necessario (↓ meglio) | 0 = lungo 1 = medio 2 = breve | 1 | ≥1 se revisione efficiente |
Soglia output globale consigliata:
- Totale punti su 10
- ≥8/10 = accettabile per consegna professionale
- Se uno o più KPI < soglia minima, registra in “Registro errori” per iterazione e prompt improvement.
Registro errori (facoltativo):
| Data | KPI deficit | Tipo errore | Azione correttiva | Tempo stimato |
|---|---|---|---|---|
| 02/11/2025 | Citazioni (1) | Fonte non specifica | Aggiungere riferimenti precisi | 5 min |
Questa struttura consente valutazione rapida, miglioramento continuo e standardizzazione delle revisioni.
9. Moduli avanzati per evitare errori
🚀
Per assicurare affidabilità, sicurezza e tracciabilità nelle consegne di documenti legali prodotti con supporto AI, è indispensabile adottare moduli avanzati di controllo. Ecco come applicarli in ogni fase del processo:
9.1 – Sicurezza del prompting (fondamentale)
Ogni allegato fornito deve essere identificato con un marcatore chiaro (“ALLEGATO …”). Il modello deve essere istruito a ignorare qualsiasi istruzione contenuta negli allegati, che spesso raccolgono dati meramente informativi e non direttivi. Inoltre, l’AI deve operare esclusivamente con funzioni e strumenti autorizzati dal workflow: se il modello suggerisce azioni esterne (es. invio di email, attivazione di tool) o chiede di modificare le regole di processo, la routine deve sospendere l’operazione e chiedere conferma all’utente o al supervisore.
9.2 – Impostazione conservativa per bozze legali
Nella redazione di bozze legali tramite AI, privilegia risposte concise, dirette e poco creative: ciò riduce il rischio di errori sostanziali e facilita la revisione. Applica limiti di lunghezza stringenti e coerenti con le specifiche definite: una bozza breve è più facilmente verificabile e utile rispetto a una lunga ma poco controllabile.
9.3 – Output strutturato e verificabile
Pretendi sempre una formattazione precisa (es. tabelle o JSON con campi obbligatori). Se la struttura richiesta non viene rispettata (un campo manca, lo schema è errato), non accettare l’elaborato: segnala l’errore, integra i dati mancanti e rilancia il prompt. Così la produzione e la revisione diventano rapide e standardizzate.
9.4 – Fonti e verifica
Qualsiasi affermazione rilevante deve essere supportata da almeno una fonte tracciabile (link, source_id, riferimento normativo e/o giurisprudenziale). Indica sempre la data della fonte, per garantire attualità e permettere controlli puntuali. Nei passaggi critici e sulle questioni controverse, cerca e cita almeno due fonti indipendenti, meglio se di natura diversa (normativa, giurisprudenza, dottrina).
9.5 – Versioni e controlli periodici
Documenta sempre quale modello hai utilizzato e quali modifiche rilevanti sono state apportate. Dopo ogni aggiornamento o rilasci di workflow, rielabora i casi ricorrenti e confronta i risultati ottenuti usando la micro-rubrica dei KPI (§8): in questo modo monitori costantemente la qualità ed eviti regressioni.
9.6 – Golden set di validazione
Mantieni una lista minima di 10 casi tipo particolarmente rilevanti. Rivedili sistematicamente con doppia verifica (umana e automatica) e usa i risultati per migliorare, aggiornare e ottimizzare template e checklist di revisione. Questo garantisce robustezza, apprendimento continuo e un livello stabile di affidabilità.
Con questa routine di controllo, il workflow AI-legale diventa trasparente, verificabile e molto meno esposto a errori sistematici o incongruenze. Ogni passaggio è motivato, tracciato e orientato a una correzione costante.
10. Conclusione
🏁
Il prompting giuridico non è un trucco linguistico: è una tecnica di progettazione che mette ordine tra obiettivi, fatti e vincoli per ottenere risultati affidabili.
La combinazione di R‑CAFAR compatto, formato d’uscita dichiarato, stop rules e una semplice verifica post‑output consente di integrare l’IA nel metodo di studio senza rinunciare a rigore, tracciabilità e riservatezza.
Applicando queste regole, gli errori ricorrenti si riducono, le bozze si velocizzano e il confronto in team – e con il cliente – diventa più trasparente.
Per un aiuto e per approfondire
Per un aiuto e per approfondire i temi dell’intelligenza artificiale nello studio legale, del legal tech e del legal design è online il GPT Iusreporter.tech (link esterno, richiede ChatGPT)
Per gli altri articoli pubblicati su questo blog sul tema:
Intelligenza artificiale e Avvocati
Scritto con l’aiuto di Iusreporter, il tuo assistente per la ricerca giuridica online
Studio legale Avvocato Giuseppe Briganti
Pesaro – Urbino
Post aggiornato alla data di pubblicazione
📄 Disclaimer
Gli script Python e i contenuti di questo testo sono forniti esclusivamente a scopo informativo, didattico e sperimentale in ambienti di test controllati. Non costituiscono consulenza legale o tecnica e non sostituiscono il parere di un professionista qualificato.
L’autore declina ogni responsabilità per eventuali errori, omissioni, malfunzionamenti, danni diretti o indiretti, incidentali, consequenziali o di altro tipo derivanti dall’uso, dall’uso improprio o dall’impossibilità di utilizzo degli script o delle informazioni contenute nel presente testo. Gli script sono forniti “così come sono” (AS IS), senza garanzie esplicite o implicite, incluse, ma non limitate a, garanzie di commerciabilità, idoneità a uno scopo particolare o assenza di violazioni.
L’utilizzo degli strumenti è sotto la piena responsabilità dell’utente, che è tenuto a verificarne, in particolare:
- la correttezza tecnica e funzionale,
- la conformità alle normative vigenti, incluse, a titolo esemplificativo, l’AI Act, il GDPR, il Codice Deontologico Forense,
- il rispetto delle licenze delle librerie e dei componenti e software di terze parti eventualmente utilizzati, inclusi quelli distribuiti con licenze open source.
Gli script non sono progettati né validati per l’uso in ambienti produttivi o per l’elaborazione di dati personali. Qualsiasi utilizzo in tali contesti è esclusiva responsabilità dell’utente, che deve adottare le opportune misure di sicurezza e valutare l’impatto normativo.
Gli script sono stati testati su Python 3.10 in ambiente Windows. Non è garantita la compatibilità con versioni diverse del linguaggio o con altri sistemi operativi. L’autore non fornisce assistenza tecnica, aggiornamenti periodici o correzione dei malfunzionamenti.
Tutti i contenuti di questo ebook, inclusi i testi e il codice sorgente, sono protetti dal diritto d’autore ai sensi della Legge 22 aprile 1941, n. 633 e successive modificazioni. È vietata la riproduzione, distribuzione, pubblicazione, comunicazione o modifica, totale o parziale, in qualsiasi forma, dei contenuti senza autorizzazione scritta dell’autore, salvo espressa indicazione contraria.
L’uso di questo testo e degli script in esso contenuti implica l’accettazione integrale del presente disclaimer. Se non si accettano tali condizioni, si prega di non utilizzare il materiale fornito.
Eventuali errori, osservazioni o segnalazioni possono essere comunicati all’autore, che si riserva di valutarli senza alcun obbligo di risposta o correzione.