How Anthropic enables self-service data analytics with Claude
Approfondimento tecnico del team Data Science & Data Engineering di Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) pubblicato il 3 giugno 2026 sul blog Anthropic (categoria Enterprise AI, incentrato su Claude Code). Risultato principale: "il 95% delle query di business analytics viene automatizzato da Claude, con un'accuratezza aggregata del ~95%" (fino al ~99% in alcuni ambiti). Problema di fondo: l'analytics non è codice — "spesso esiste un'unica risposta corretta a partire da un'unica fonte corretta" — richiede di mappare la domanda dell'utente su entità precise e aggiornate nel modello dei dati.
Pubblicato il 3 giugno 2026 sul blog Anthropic, questo approfondimento del team Data Science & Data Engineering (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) descrive come Anthropic ha reso il proprio analytics self-service con Claude: 95% delle query di business automatizzate, ~95% di accuratezza in aggregato (fino al ~99% in alcuni ambiti).
Il punto di partenza è che l'analytics non è codice: "spesso esiste un'unica risposta corretta a partire da un'unica fonte corretta". La difficoltà non risiede nella creatività generativa ma nella capacità di mappare una domanda su entità precise e aggiornate nel modello dei dati. Tre modalità di fallimento minacciano questo processo: ambiguità concetto↔entità (cosa conta come "utenti attivi"? i truffatori vengono esclusi? quale finestra temporale?), obsolescenza degli asset e della conoscenza dell'agente, e fallimento del retrieval — l'80% delle query fallite aveva comunque l'informazione presente nel corpus. Il caso peggiore è il fallimento silenzioso: una risposta sbagliata ma plausibile, usata senza obiezioni.
La risposta è uno "stack di analytics agentico" a quattro livelli. (1) Fondamenta dei dati: modellazione dimensionale, dataset canonici"fonte unica di verità", metadati trattati "come prodotto di prima classe", integrità tramite CI/CD. (2) Fonti di verità in ordine decrescente di affidabilità: un semantic layer che l'agente è "strutturalmente obbligato (per istruzione della skill) a utilizzare per primo", poi il lineage, un corpus di query distillato in documenti (non retrieval grezzo), e un grafo di conoscenza di business (roadmap, decision log, organizzazione). (3) Skills — la leva decisiva: "senza skill … non si superava il 21% … Aggiungendo le skill questi numeri salgono stabilmente oltre il 95%". Sono organizzate in coppie: una Knowledge skill router (~30 file di riferimento) e una Unbook skill che codifica il workflow dell'analista senior (chiarire, trovare le fonti, eseguire, revisione avversariale). La manutenzione è colocata: un hook di revisione segnala qualsiasi modifica al modello senza una corrispondente modifica alla skill — ~90% delle PR sui dati ora include una skill nello stesso diff. (4) Validazione: eval offline basate su soglia (~90% per autorizzare un agente), ablation testing, e guardrail online (revisione avversariale +6% di accuratezza ma +32% di token e +72% di latenza; footer di provenienza; raccolta di correzioni da parte di agenti pianificati).
Due risultati negativi plasmano la dottrina: dare accesso a grep grezzo su migliaia di file SQL sposta l'accuratezza "meno di un punto" (il collo di bottiglia è la struttura, non l'accesso), e lasciare che l'LLM definisca le metriche si è rivelato "netamente negativo" — da qui la regola: documentazione generata, definizioni possedute dagli esseri umani. Per iniziare: una manciata di dataset canonici, qualche decina di eval, una knowledge skill leggera.
Punti chiave
Data / fonte.3 giugno 2026, blog Anthropic (claude.com/blog, Enterprise AI). Autori: il team Data Science & Data Engineering di Anthropic (Chang, Peng, Leder, Jiao, Cherry).
Risultato principale.95% delle query di business analytics automatizzate, ~95% di accuratezza in aggregato (fino al ~99% in alcuni ambiti).
Tesi. analytics ≠ codice — "un'unica risposta corretta a partire da un'unica fonte corretta" → la difficoltà è mappare la domanda sulle entità giuste e aggiornate, non generare. ### 3 modalità di fallimento 1. Ambiguità concetto↔entità — centinaia di opzioni; es. "utenti attivi" (quali azioni? escludere i truffatori? quale finestra di lookback?). 2. Obsolescenza (staleness) — gli asset e la conoscenza dell'agente diventano "sottilmente errati" (schemi/definizioni cambiano continuamente). 3. Fallimento del retrieval — l'80% delle query fallite aveva comunque l'informazione presente nel corpus.
Pericolo ultimo = fallimento silenzioso: "la risposta è sbagliata, ma sembra plausibile e viene usata senza obiezioni". ### Stack agentico a 4 livelli
L1 — Fondamenta dei dati. modellazione dimensionale, dataset canonici (fonte unica di verità, con proprietario, pronti al consumo), metadati come "prodotto di prima classe", integrità cross-layer tramite CI/CD.
L2 — Fonti di verità. (affidabilità ↓): semantic layer (obbligatorio per primo) → grafo di lineage/trasformazione → corpus di query (distillato in documenti, non retrieval grezzo) → contesto di business (grafo di conoscenza: roadmap, decision log, organizzazione).
L3 — Skills. (la leva): 21% → 95%+. Coppie: Knowledge skill (router → ~30 file di riferimento) + Unbook skill (workflow da analista senior: chiarire → fonti → eseguire → revisione avversariale; pattern riutilizzabili: curve di retention, scomposizione dei tassi, funnel). Scheletro tipico della doc: Quick reference / Dimensioni & tabelle chiave / Gotchas / Best practice & pattern di query / Riferimenti cross-domain.
L4 — Validazione. eval offline (soglia ~90% per autorizzare un agente, obiettivo ~100%, ground truth fissato su uno snapshot, "conservare i risultati come telemetria"), ablation testing, online (revisione avversariale, footer di provenienza, controlli di qualità dei dati, raccolta di correzioni da agenti pianificati). ### Risultati notevoli (numeri e ablation)
Senza skill ≤ 21%. ; con skill > 95% (≈99% in alcuni ambiti).
Revisione avversariale.+6% di accuratezza, ma +32% di token e +72% di latenza (un compromesso da accettare).
Ablation con grep grezzo. (migliaia di file SQL accessibili): l'accuratezza si muove "meno di un punto" → il collo di bottiglia è la struttura, non l'accesso.
Definizioni generate dall'LLM. = "netamente negativo" (codificano proprio le ambiguità che si voleva eliminare) → definizioni possedute dagli esseri umani.
Retrieval non strutturato. su migliaia di query: guadagno < 1 punto → il corpus va distillato, non cercato grezzo.
Manutenzione. hook di code review → ~90% delle PR sui dati tocca un file di skill nello stesso diff. ### Da usare in engagement / presentazioni
Blueprint di agente analytics in produzione. trasferibile altrove: governance dei dati + semantic layer obbligatorio + skills + eval a soglia.
Punto di partenza minimo. (riutilizzabile così com'è): "una manciata di dataset canonici, qualche decina di eval offline e una knowledge skill leggera" catturano "la maggior parte del vantaggio".
Argomenti anti-naive-RAG. i due risultati negativi (grep grezzo, retrieval non strutturato) sono munizioni contro "basta dare tutto all'agente".
Metrica di governance vivente."il 90% delle PR include una skill" = prova che doc e codice evolvono insieme (anti-obsolescenza).
Si collega a: skills (Shihipar/Anthropic), semantic layer/ontologia (Talisman, Seale), context engineering (Debois/Tessl), sistemi attorno al modello (Dropbox), knowledge graph dei dati (Netflix UDA).
Dati chiave
il 95% delle richieste analytics aziendali automatizzate tramite Claude