Cosa non conta come evidenza di AI
Nota: Questo documento è una traduzione automatica della versione originale in inglese.
Cosa non conta come evidenza di AI
Un progetto può presentare molti artefatti che sembrano prove di un AI component funzionante — ma che a un esame più attento non lo dimostrano affatto. Questa pagina elenca gli anti-pattern più comuni: segnali che rivendicano capacità AI senza fornire evidenza verificabile. È la pagina complementare a Cosa conta come evidenza di un AI component.
In sintesi: testi di marketing, repository vuoti, metriche senza metodologia, API wrapper senza logica proprietaria e "AI" nel nome di un token non sono evidenza di un AI component funzionante.
Perché riconoscere i falsi segnali è importante
Il confine tra "evidenza" e "non evidenza" è il fondamento dell'approccio di DecAIHub all'AI-washing. Riconoscere gli schemi qui sotto non è un'accusa contro il progetto — significa che lo specifico artefatto non sposta l'ago della bilancia sulla AI reality verificabile e non deve essere scambiato per evidenza Tier-1.
Anti-pattern comuni
"Usiamo l'AI" nei testi di marketing
Dire "alimentato dall'AI", "costruito con il machine learning" o "guidato da reti neurali" su una landing page o in un pitch deck è una dichiarazione di posizionamento, non un'evidenza. Senza artefatti Tier-1 (codice, documentazione, demo), queste parole non hanno alcun peso verificabile.
DecAIHub non penalizza i progetti per l'uso della parola — ma non la tratta nemmeno come evidenza. La presenza di "AI" nel marketing alza l'asticella: se un progetto rivendica l'AI in modo prominente, l'assenza di artefatti a supporto diventa più evidente.
Repository vuoto o non pertinente
Un repository GitHub che esiste ma non contiene codice AI/ML — o contiene solo un README, boilerplate o script non pertinenti — è un segnale d'allarme. Un repository significativo ha commit, release, test e codice in linea con le affermazioni del whitepaper o della documentazione.
Schemi comuni: un repository creato di recente con un singolo commit iniziale; un fork di un framework popolare senza modifiche; una raccolta di file di configurazione senza codice del modello; un repository senza commit da oltre un anno mentre il progetto continua a rivendicare uno sviluppo AI attivo.
Metriche senza metodologia
Dichiarare "95% di accuratezza" o "prestazioni allo stato dell'arte" non significa nulla senza contesto: cosa è stato misurato, su quali dati, quando e con quale versione del modello. Le metriche senza metodologia non sono evidenza Tier-1.
"Il nostro modello raggiunge 0,92 F1 sul benchmark XYZ, valutato sulla versione 2.1 a gennaio 2026" è una metrica. "Raggiungiamo il 92% di accuratezza" è un'affermazione. DecAIHub registra le affermazioni come dichiarazioni annotate ma non imposta il flag AI_3 sulla loro base.
API wrapper senza logica proprietaria
Chiamare l'API di OpenAI, Anthropic o di un'altra terza parte e restituire il risultato non è evidenza di AI propria del progetto. Un API wrapper può essere un prodotto valido, ma non rende il progetto un progetto AI nel senso in cui DecAIHub lo valuta. L'AI appartiene al provider, non al progetto.
Se un progetto applica il proprio fine-tuning, combina l'output di terze parti con modelli proprietari o aggiunge un post-processing misurabile, il quadro cambia. La domanda chiave è se il progetto aggiunga un valore verificabile a livello AI oltre a quanto fornisce l'API grezza. Se l'intero "AI component" è una singola chiamata API con un system prompt, l'AI reality appartiene al provider.
"AI" solo nel nome del token o nel branding
Se l'unico legame di un progetto con l'AI è la parola "AI" nel ticker del token, nel nome di dominio o nel branding — senza alcuna implementazione tecnica dietro — questo è posizionamento, non evidenza.
Il ticker di un token è un'etichetta, non una funzionalità. DecAIHub tratta la denominazione come un segnale neutro — non contribuisce né sottrae alla valutazione dell'evidenza. Ciò che conta è se esistano artefatti dietro il nome.
Partnership con un'azienda AI
Un annuncio di partnership (ad esempio "in partnership con NVIDIA" o "integrato con OpenAI") è al massimo Tier-2. Mostra un'associazione, non un AI component funzionante all'interno del progetto. Le partnership non sostituiscono codice, documentazione o demo.
Le partnership spaziano da collaborazioni tecniche profonde (ricerca congiunta, modelli co-sviluppati) ad affiliazioni deboli (adesione a un acceleratore, presenza in una directory di partner). La maggior parte delle partnership annunciate nello spazio crypto-AI si colloca verso l'estremità più debole. Solo le partnership con output tecnico verificabile contribuiscono al quadro dell'evidenza, e anche allora come contesto Tier-2 anziché come prova Tier-1.
"Roadmap AI" o intento AI senza implementazione
Una voce di roadmap che dice "funzionalità AI in arrivo nel Q3" mostra un intento (AI_0), non un AI component funzionante. L'intento viene registrato come singolo flag ma, da solo, non indica un AI component funzionante. La formula dell'ai_score ha un tetto di 3, quindi AI_0 da solo contribuisce in modo minimo.
I piani cambiano, subiscono ritardi o vengono cancellati. DecAIHub registra l'intento AI ufficiale attraverso il flag AI_0 per distinguere i progetti che hanno dichiarato ambizioni AI da quelli che non lo hanno fatto. Ma il flag è il pavimento, non il soffitto — contribuisce al massimo con ai_score = 1, e solo quando l'intento proviene da una fonte Tier-1.
Demo senza backend AI verificabile
Un frontend curato che dichiara di mostrare risultati AI ma non fornisce alcun modo per verificare che un modello AI stia girando dietro di esso — nessuna documentazione API, nessuna versione del modello, nessun output riproducibile — non è evidenza sufficiente.
Una demo verificabile accetta input diversi e produce output contestualmente variati. Può esporre un endpoint API, mostrare informazioni sulla versione del modello o offrire una modalità sandbox. Una vetrina, al contrario, segue un percorso predefinito o produce output identici indipendentemente dall'input. DecAIHub cerca la prima; la seconda viene annotata ma non contribuisce ai flag di evidenza oltre AI_0.
"Modello sottoposto a fine-tuning" senza dettagli
Dichiarare di avere un modello sottoposto a fine-tuning non è evidenza a meno che il progetto non specifichi: il modello di base, il dataset usato per il fine-tuning, il miglioramento rispetto al modello di base e le metriche di qualità con metodologia.
Un'affermazione credibile di fine-tuning nomina il modello di base, descrive i dati di addestramento e mostra un miglioramento misurabile su un compito definito. Senza questi dettagli, "abbiamo fatto il fine-tuning di un modello" è indistinguibile da "abbiamo usato un modello".
Tabella di riferimento degli anti-pattern
| Anti-pattern | Cosa dichiara | Cosa dimostra realmente |
|---|---|---|
| "Alimentato dall'AI" sul sito | Il progetto ha l'AI | Nulla senza artefatti Tier-1 |
| Repo GitHub vuoto | Codice AI open source | Il repository esiste; il codice AI no |
| "95% di accuratezza" senza contesto | AI di alta qualità | Un numero è stato dichiarato; la validità è sconosciuta |
| Wrapper dell'API di OpenAI | Il progetto "usa l'AI" | Il progetto chiama l'AI di qualcun altro |
| "AI" nel nome del token | Progetto legato all'AI | È stata fatta una scelta di denominazione |
| Partnership con un laboratorio AI | Capacità AI | Esiste un'associazione |
| "AI nella roadmap Q3" | Futuro AI component | Solo intento (AI_0) |
| Demo curata, nessuna evidenza di backend | AI funzionante | È stato costruito un frontend |
| "LLM sottoposto a fine-tuning" senza dettagli | Modello proprietario | È stata fatta un'affermazione |
Come distinguere i falsi segnali dall'evidenza debole ma reale
Non ogni artefatto che non raggiunge lo standard Tier-1 è privo di valore. Alcuni artefatti sono un'evidenza autenticamente debole — insufficiente da sola ma significativa in combinazione. La tabella qui sotto chiarisce il confine:
| Artefatto | Falso segnale (nessun valore di evidenza) | Evidenza debole ma reale |
|---|---|---|
| Repository | Vuoto o solo boilerplate | Contiene del codice AI ma manca di test o release |
| Metrica | Numero senza metodologia | Numero con metodologia parziale (manca una delle quattro domande di contesto) |
| Demo | Vetrina preconfezionata con output fissi | Demo interattiva senza documentazione API o versione del modello |
| Partnership | Logo su una pagina partner | Output tecnico congiunto (articolo co-firmato, repo condiviso) |
| Documentazione | Whitepaper di marketing senza profondità tecnica | Whitepaper tecnico che descrive l'architettura ma manca dei dettagli di versione |
L'evidenza debole può contribuire a impostare singoli flag quando corroborata da altri artefatti. I falsi segnali non contribuiscono indipendentemente dalla quantità — dieci repository vuoti non sono più forti di uno.
Come DecAIHub registra questi casi
Quando non viene trovata alcuna evidenza Tier-1 di un AI component funzionante, l'ai_score del progetto resta a 0 o 1. Se l'AI è attivamente promossa nel marketing mentre l'evidenza è assente, sulla scheda può essere impostato un flag di AI-washing.
Non è un'accusa — è una registrazione del divario tra affermazioni e artefatti alla data di verifica. Quando compare nuova evidenza, la scheda viene aggiornata.
L'ai_score somma i flag binari da AI_0 ad AI_4 (con tetto a 3). Un progetto che mostra solo anti-pattern di questa pagina avrà tipicamente ai_score = 0 o ai_score = 1 (se AI_0 è impostato tramite una roadmap ufficiale), il che limita direttamente il suo DecAI Fit massimo.
Cosa questo elenco da solo non dimostra
- Esibire uno o più anti-pattern non è un'accusa contro il progetto. Molti progetti in fase iniziale mancano di artefatti semplicemente perché la tecnologia non è ancora pubblica.
- L'assenza di anti-pattern non dimostra che l'AI sia reale. Un progetto può evitare ogni segnale d'allarme di questo elenco e comunque non avere un AI component funzionante.
- Questo elenco è un'istantanea — gli anti-pattern possono risolversi man mano che i progetti maturano e pubblicano nuovi artefatti.
Domande frequenti
Perché avere "AI" nel nome del token non conta come evidenza?
Il nome di un token è una decisione di branding, non un artefatto tecnico. Qualsiasi progetto può scegliere un ticker che include "AI" senza costruire alcuna tecnologia. DecAIHub valuta l'evidenza sulla base di artefatti ispezionabili e verificabili — codice, documentazione, demo, metriche con metodologia. Un nome non soddisfa nessuno di questi criteri. Il nome del token è registrato nella scheda del progetto come metadato ma non influenza nessuno dei cinque flag di AI reality (da AI_0 ad AI_4).
Una partnership con NVIDIA (o un'altra azienda AI) è evidenza di AI?
No. Un annuncio di partnership è classificato al massimo come Tier-2 — fornisce contesto ma non dimostra che esista un AI component funzionante all'interno del progetto. Le partnership variano molto in profondità: da sforzi profondi di co-ingegnerizzazione a semplici inserimenti come "membro dell'ecosistema". A meno che la partnership non abbia prodotto un output tecnico verificabile (una codebase condivisa, ricerca co-pubblicata, un deployment mantenuto congiuntamente), rimane un'associazione anziché un'evidenza. Può supportare un riscontro Tier-1 se ne esiste uno, ma non può sostituirlo.
E i progetti che promettono funzionalità AI nella loro roadmap?
Una voce di roadmap proveniente da una fonte ufficiale Tier-1 (il blog del progetto stesso, la documentazione o una proposta di governance) viene registrata attraverso il flag AI_0, che cattura l'"intento AI dichiarato". Questo imposta l'ai_score almeno a 1, distinguendo il progetto da quelli che non menzionano affatto l'AI. Tuttavia, una roadmap è un piano, non un'implementazione. Il flag AI_0 è il segnale positivo più basso possibile e, da solo, limita il DecAI Fit a un massimo di 3 su 6 a causa delle regole di tetto dell'ai_score. Quando le milestone della roadmap vengono realizzate e compaiono artefatti verificabili, la scheda viene aggiornata e possono essere impostati flag più alti.
Un progetto può mostrare più anti-pattern e avere comunque un AI component reale?
Sì. Gli anti-pattern indicano che specifici artefatti non costituiscono evidenza — non dimostrano l'assenza di tecnologia. Un progetto potrebbe avere pratiche di marketing scadenti e affermazioni metriche vaghe operando allo stesso tempo un sistema AI legittimo non ben documentato pubblicamente. DecAIHub valuta ciò che è verificabile al momento della revisione. Se la tecnologia sottostante esiste ma non è ispezionabile dall'esterno, non può essere valutata — e il progetto è incoraggiato a pubblicare gli artefatti necessari per aggiornare la sua scheda.
Riferimenti esterni
- OECD AI Policy Observatory — AI classification framework — una risorsa internazionale per capire come i sistemi AI vengono definiti, classificati e governati nelle diverse giurisdizioni.
- Papers With Code — state-of-the-art benchmarks — una risorsa comunitaria che traccia i risultati dei benchmark AI con codice e metodologia collegati; utile per capire come appaiono in pratica le "metriche con metodologia".
- Stanford HAI — AI Index Report — un rapporto annuale che traccia le tendenze nella ricerca, nello sviluppo e nella distribuzione dell'AI; fornisce contesto per valutare le affermazioni sull'AI rispetto al panorama più ampio.
No comments to display
No comments to display