Un modello operativo in cui una persona supervisiona, conferma o corregge le decisioni di un sistema automatico prima che producano effetti reali.
Nei nostri progetti gli agenti autonomi partono sempre sotto supervisione human-in-the-loop: ogni azione sensibile (invio di email, scrittura su database, pagamenti, cancellazioni) passa da una conferma umana. È così che si costruisce fiducia e si misura il comportamento reale del sistema. Solo quando il comportamento è verificato e stabile l’autonomia viene ampliata gradualmente, mantenendo log, soglie e possibilità di intervento. È il contrario della scatola nera: l’automazione resta sotto controllo, tracciabile e reversibile.
Lo sviluppo di software guidato da un essere umano che dirige modelli di AI di frontiera in linguaggio naturale, mantenendo il controllo su architettura, qualità e sicurezza.
Il termine “vibe coding” è entrato nell’uso comune nel 2025 per descrivere la scrittura di codice in cui l’AI fa la maggior parte della digitazione e l’essere umano dirige, rivede e decide. Per noi non significa “lasciar fare all’AI”: significa unire la velocità dei modelli alla disciplina ingegneristica: revisione del codice, test, hardening di sicurezza, controllo dell’architettura. Il risultato è software reale, in produzione, costruito in tempi molto più brevi senza rinunciare a qualità e responsabilità. La persona resta autrice e garante del prodotto.
Un sistema basato su modelli linguistici che non si limita a rispondere, ma pianifica ed esegue azioni con strumenti reali (API, database, email) per raggiungere un obiettivo.
Un agente AI combina un modello linguistico con strumenti e memoria: riceve un obiettivo, lo scompone in passi, usa strumenti (interrogare un gestionale, inviare una notifica, aggiornare un record) e valuta i risultati. La differenza con un chatbot è l’azione: l’agente fa cose, non solo parla. Proprio per questo richiede un perimetro chiaro (quali strumenti può usare, con quali limiti) e supervisione: gli stessi rischi di sicurezza (OWASP Top 10 for LLM Applications, MITRE ATLAS) si applicano in modo amplificato quando un sistema può agire sul mondo reale.
Un attacco in cui istruzioni malevole nascoste nei dati in input dirottano il comportamento di un’applicazione basata su LLM, facendole ignorare le sue regole.
La prompt injection è il rischio numero uno della OWASP Top 10 for LLM Applications. Poiché un modello non distingue nativamente tra “istruzioni di sistema” e “dati da elaborare”, un contenuto ostile (in una email, in una pagina web, in un documento caricato) può contenere comandi del tipo “ignora le istruzioni precedenti” e indurre il sistema a rivelare dati o compiere azioni indebite. La difesa non è un singolo trucco ma una combinazione: separazione dei privilegi, validazione e sanitizzazione dell’input, guardrail sull’output, conferma umana sulle azioni sensibili. È uno dei motivi per cui progettiamo la sicurezza fin dall’inizio.
Una tecnica che fa rispondere un modello linguistico a partire da documenti recuperati su misura (i tuoi dati), invece che solo dalla sua memoria di addestramento.
Con la RAG, prima di rispondere il sistema cerca i passaggi più pertinenti in una base di conoscenza (manuali, schede prodotto, contratti, ticket) e li fornisce al modello come contesto. Così le risposte sono ancorate ai dati reali dell’azienda, aggiornabili senza riaddestrare il modello e corredabili di citazioni verificabili. È l’architettura tipica di un assistente che “conosce” la tua documentazione. Riduce molto le allucinazioni, ma non le elimina: vanno comunque gestiti la qualità del recupero, i permessi sui documenti e i guardrail sull’output.
Un modello di intelligenza artificiale addestrato su grandi quantità di testo per comprendere e generare linguaggio, ed eseguire compiti descritti in linguaggio naturale.
Gli LLM sono il motore della maggior parte delle applicazioni AI odierne: comprendono istruzioni, riassumono, traducono, classificano, scrivono codice. Ogni lab di frontiera ne offre famiglie diverse, ognuna con i suoi compromessi tra capacità di ragionamento, velocità e costo: Claude (Anthropic), GPT (OpenAI), Gemini (Google), Nova (Amazon), Llama (Meta), Mistral. Non esiste “il modello migliore” in assoluto: esiste il modello giusto per un certo compito. Per questo lavoriamo multi-provider, senza lock-in, scegliendo e instradando i modelli in base al lavoro da fare.
Una base di conoscenza pubblica delle tattiche e tecniche reali usate per attaccare i sistemi di intelligenza artificiale e machine learning.
ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) è l’equivalente, per l’AI, della celebre matrice MITRE ATT&CK usata in cybersecurity. Cataloga in modo strutturato come gli attaccanti possono compromettere un sistema di AI: avvelenamento dei dati, estrazione del modello, evasione, abuso degli agenti. Lo usiamo come checklist di minacce quando progettiamo applicazioni che usano modelli: aiuta a ragionare su scenari concreti invece che su sicurezza generica. Insieme alla OWASP Top 10 for LLM Applications è uno dei riferimenti che applichiamo davvero.
L’elenco curato dalla comunità OWASP dei dieci rischi di sicurezza più critici nelle applicazioni che usano modelli linguistici di grandi dimensioni.
OWASP è l’organizzazione di riferimento mondiale per la sicurezza applicativa. La sua Top 10 dedicata agli LLM porta l’attenzione su rischi specifici dell’AI: prompt injection, gestione insicura dell’output, avvelenamento dei dati di addestramento, fuga di informazioni sensibili, eccesso di autonomia (excessive agency), consumo incontrollato di risorse. È un linguaggio comune per parlare di sicurezza dell’AI con i clienti senza fuffa. Nei nostri progetti la usiamo come griglia di controllo concreta, accanto alle classiche OWASP Top 10 e OWASP ASVS per il web e le API.
Un controllo automatico posto attorno a un modello AI per filtrare input e output e impedire comportamenti fuori perimetro o pericolosi.
I guardrail sono i “binari” entro cui un sistema AI può muoversi: validano ciò che entra (per intercettare prompt injection o dati malformati) e ciò che esce (per bloccare informazioni riservate, comandi pericolosi, contenuti fuori tema). Possono essere regole, classificatori dedicati o un secondo modello che controlla il primo. Non sono un optional estetico: sono parte dell’architettura di sicurezza, soprattutto quando il sistema può compiere azioni. Insieme alla separazione dei privilegi e alla conferma umana, definiscono il perimetro entro cui un agente è autorizzato a operare.
Quando un modello AI produce un’affermazione plausibile ma falsa o inventata, presentandola con sicurezza come se fosse vera.
Le allucinazioni sono un limite intrinseco dei modelli linguistici: generano testo statisticamente verosimile, non verità verificate. In contesti aziendali questo è un rischio concreto: una cifra sbagliata, una norma inesistente, una citazione inventata. Si gestisce con l’architettura: ancorare le risposte ai dati reali (RAG con citazioni), aggiungere controlli e verifiche e, per le decisioni che contano, mantenere l’essere umano nel ciclo. Per questo sul nostro sito non pubblichiamo numeri o casi inventati: la stessa disciplina che chiediamo ai modelli la applichiamo ai nostri contenuti.
L’adattamento di un modello pre-addestrato a un compito o a uno stile specifico, continuando l’addestramento su un insieme di esempi mirati.
Il fine-tuning serve quando un modello generale deve assumere un comportamento, un tono o un formato molto specifici e ripetuti. Non è quasi mai il primo strumento da usare: spesso un buon prompt e un’architettura RAG ben fatta risolvono il problema a costo molto inferiore e con maggiore flessibilità. Quando serve davvero, ad esempio per un formato di output rigoroso o per ridurre i costi su un compito ad alto volume, va valutato rispetto alle alternative. La regola è la stessa che applichiamo ai modelli: lo strumento giusto per il problema giusto, senza mode.
La rappresentazione numerica di un testo (o di un’immagine) che ne cattura il significato, così da poter misurare quanto due contenuti sono simili.
Un embedding trasforma una frase in un vettore di numeri: contenuti con significato simile finiscono “vicini” in questo spazio. È il meccanismo che rende possibile la ricerca semantica e la RAG: trovare i documenti pertinenti a una domanda anche quando non condividono le stesse parole. Gli embedding si conservano in un database vettoriale e si interrogano per similarità. Capire questo concetto aiuta a capire perché un assistente AI ben costruito può “trovare” la risposta giusta in mezzo a migliaia di documenti aziendali.
Uno standard aperto per collegare i modelli AI a strumenti e fonti di dati esterne in modo uniforme e controllato.
Il Model Context Protocol, introdotto da Anthropic nel 2024 e adottato sempre più ampiamente, definisce un modo standard con cui un’applicazione AI può scoprire e usare strumenti esterni (un database, un gestionale, un servizio) senza integrazioni su misura per ognuno. Per chi costruisce software è importante perché riduce il lock-in e rende gli agenti componibili. Resta valido però lo stesso principio di sicurezza: dare a un modello l’accesso a strumenti reali richiede perimetro, permessi e supervisione, perché ogni strumento collegato amplia anche la superficie d’attacco.
La capacità di capire cosa sta facendo un sistema in produzione attraverso log, metriche e tracce, per diagnosticare problemi e migliorarlo.
Un software non finisce quando va online: lì comincia la parte difficile. L’osservabilità è ciò che permette di sapere se funziona, quanto costa, dove rallenta e cosa è andato storto. Nei sistemi che usano l’AI è ancora più importante: bisogna poter vedere cosa ha deciso un agente, quali strumenti ha usato, quali input ha ricevuto, sia per il debug sia per la sicurezza e la conformità. Per questo, quando costruiamo un’applicazione, costruiamo anche l’ambiente che la rende osservabile e mantenibile nel tempo, non solo il codice.
La pratica di attaccare deliberatamente il proprio sistema, pensando come un avversario, per scoprirne le debolezze prima che lo faccia qualcun altro.
Nel contesto dell’AI, il red teaming significa mettere alla prova un modello o un agente con input ostili: tentativi di prompt injection, richieste fuori perimetro, scenari di abuso. Serve a trasformare la sicurezza da dichiarazione a verifica. È complementare ai framework: OWASP e MITRE ATLAS dicono quali sono i rischi noti, il red teaming controlla se il tuo sistema specifico vi resiste. Lo consideriamo parte del “secure by design”: non basta progettare bene, bisogna anche provare a romperlo, in modo controllato, prima della produzione.
Un approccio in cui la sicurezza è una decisione di progetto presa fin dall’inizio, non una verniciatura aggiunta alla fine.
Secure by design significa che le scelte di sicurezza (separazione dei privilegi, validazione degli input, gestione dei segreti, minimo accesso necessario) vengono prese mentre si disegna l’architettura, non rincorse dopo un incidente. Costa meno e protegge di più, perché molti rischi vengono semplicemente esclusi dalla struttura del sistema. È il principio che attraversa tutto il nostro lavoro: applichiamo standard riconosciuti (OWASP, MITRE ATT&CK e ATLAS, NIST AI RMF) dal codice fino all’ambiente, e progettiamo gli agenti con perimetro e supervisione. La sicurezza non è una feature in più: è la forma del prodotto.