Salta al contenuto principale
TRAFFICO UMANO VS AGENTI

Distinguere tra traffico umano, assistito da AI e da agenti

Attribuisci a ogni interazione una classe chiara e una base chiara, così la tua applicazione può servire persone, persone che lavorano con l'AI e agenti autonomi nel modo che ciascuno merita.

Richiedi accesso anticipatoEsplora come funziona
Toshendra Sharma

Di Toshendra SharmaFondatore e CEO, AgentCredia · Updated November 13, 2026

Due categorie non sono più sufficienti

Per anni, il traffico è stato suddiviso in due gruppi: umani e bot. Gli umani ricevevano il prodotto. I bot venivano bloccati, limitati o ignorati.

Questa distinzione non regge più. Alcuni visitatori automatizzati sono agenti che agiscono per conto di clienti reali: un assistente che confronta i piani, un agente che recupera dati tramite la tua API, uno strumento che chiama il tuo MCP server per completare un'attività. I fornitori di AI ora documentano loro stessi questo tipo di accesso avviato dall'utente: OpenAI afferma che il suo agente ChatGPT-User visita le pagine quando un utente pone una domanda a ChatGPT (OpenAI crawler documentation), e Anthropic elenca Claude-User per lo stesso scopo (Anthropic crawler documentation). Allo stesso tempo, alcune persone lavorano fianco a fianco con l'AI, scrivendo messaggi, compilando moduli e navigando nei prodotti con un assistente al loro fianco. Forzare tutto questo dentro le categorie umano o bot produce decisioni sbagliate in entrambe le direzioni. Gli agenti legittimi vengono bloccati, e le persone reali vengono sottoposte a verifiche perché il loro comportamento sembra insolito.

Per distinguere il traffico umano da quello degli agenti AI in un modo che porti a buone decisioni, servono più categorie e serve sapere quanto si può fidare di ciascun risultato. Il post di blog su come capire se il traffico di un sito web proviene da agenti AI illustra i segnali che rendono possibile questo approccio, e il caso d'uso per le SaaS app mostra dove questa distinzione cambia le decisioni di prodotto.

Quattro classi, ciascuna con un significato preciso

Proof of Actor classifica le interazioni in quattro classi. Ognuna ha una definizione e un limite esplicito, così nessuno nel tuo team legge più del dovuto in un risultato rispetto a quanto le evidenze consentono. Per il razionale dietro questa tassonomia, leggi Human, AI-assisted or agent: a taxonomy for app traffic.

Human

I segnali osservabili supportati indicano un'interazione diretta dall'essere umano. Questa classe riguarda chi sta dirigendo l'interazione, non l'identità. Un risultato Human non verifica chi sia la persona e non afferma che non sia stata usata alcuna AI in nessun punto.

Human + AI

L'assistenza AI è stata dichiarata, oppure osservata tramite un'integrazione supportata che può realmente vederla. Esempi includono un utente che marca contenuti come redatti con AI tramite il tuo controllo di disclosure, oppure la tua applicazione che segnala che il suo assistente integrato ha eseguito un'azione per un utente autenticato. Per saperne di più, consulta la voce del glossario AI-assisted interaction.

Agent

Interazione automatizzata o originata da un agente, supportata da un'identità verificabile, come una firma valida della richiesta da una chiave pubblicata, oppure da un'inferenza attentamente qualificata. Un risultato Agent descrive chi sta agendo. Non significa che l'agente sia autorizzato, sicuro o che stia agendo con una delega valida da parte di una persona. Per saperne di più, leggi di autonomous agents.

Unknown

Le evidenze disponibili non supportano una determinazione affidabile. Unknown è un risultato onesto e utile: mostra dove finisce la tua copertura e consente alle tue policy di gestire i casi incerti in modo intenzionale, invece che per accidente.

Ogni classe ha una base

Separare il traffico umano da quello degli agenti è solo metà del lavoro. L'altra metà consiste nel sapere quanto è solida ciascuna conclusione. Ecco perché ogni risultato di Proof of Actor include una base:

  • Verified: un'affermazione verificabile convalidata, per esempio una firma della richiesta controllata rispetto a una chiave pubblicata.
  • Declared: il client o la tua applicazione lo ha dichiarato, per esempio un agente che si identifica o un utente che dichiara l'assistenza AI.
  • Inferred: una conclusione ricavata da segnali comportamentali o contestuali, sempre etichettata come inferenza.
  • Unknown: evidenze insufficienti per una determinazione.

La combinazione di classe e base è ciò che ti permette di costruire regole precise. Un agente Verified e un agente Inferred sono entrambi agenti, ma potresti voler dare al primo una structured API e trattare il secondo con un rate limit standard. Una submission dichiarata come assistita da AI e una sessione Human possono entrambe procedere normalmente, con un'etichetta che aiuta il tuo team di supporto. Puoi trovare la tassonomia completa in Detection & Limitations.

Come avviene la classificazione

Proof of Actor segue lo stesso percorso evidence-first per ogni interazione. La spiegazione completa si trova in How It Works.

I segnali che la tua integrazione può vedere

  • Request signatures da client automatizzati che pubblicano le proprie chiavi, usando HTTP Message Signatures come definito in RFC 9421. Il gruppo di lavoro IETF Web Bot Auth working group ha il mandato di standardizzare il modo in cui i client automatizzati si autenticano in questo modo.
  • Declarations da client che si identificano, come i user agent documentati dei crawler e fetcher AI, e dalla tua applicazione quando sa che è coinvolta un'assistenza AI.
  • Request context disponibile per un'integrazione lato server, come header e dettagli di protocollo.
  • Interaction signals da un'integrazione browser approvata nelle pagine in cui viene eseguita.

Dai segnali al risultato

I segnali vengono verificati, etichettati per base e combinati. Evidenze forti e verificate producono un risultato sicuro. Evidenze deboli o in conflitto producono un'inferenza qualificata o Unknown. Un timeout o un segnale mancante non diventano mai un risultato Human. L'output è una classe, una base e un riepilogo delle evidenze che chiunque nel tuo team può leggere.

Cosa puoi fare una volta separato il traffico

Proof of Actor si articola intorno a tre capacità: Detect, Understand e Route.

Detect l'attore dietro ogni interazione

Raccogli i segnali disponibili in ogni contesto e separa le affermazioni verificate dalle inferenze. Mantieni visibile Unknown.

Understand come ogni attore usa il tuo prodotto

Vedi il mix di attività umane, assistite da AI, da agenti e sconosciute per route e nel tempo. Apri qualsiasi risultato per vedere cosa è noto e cosa non lo è. Individua le route in cui gli agenti si concentrano e i workflow in cui l'assistenza AI è comune.

Route ogni attore verso l'esperienza giusta

Applica le tue policy quando le evidenze le supportano. Su un sito web pubblico, il caso d'uso websites mostra come queste scelte si mappano sulle route reali:

  • Servire agli agenti verificati una risposta strutturata o una API invece di pagine modellate per gli esseri umani.
  • Mantenere l'esperienza standard per le sessioni dirette da persone.
  • Etichettare le submission assistite da AI così che il team giusto le gestisca.
  • Richiedere credenziali più forti per le azioni sensibili quando le tue condizioni lo richiedono.
  • Scegliere un fallback esplicito per Unknown su ogni route, per esempio consentendo le pagine pubbliche e mantenendo i controlli esistenti sulle modifiche dell'account.

La guida su rollout sicuro delle policy aware dell'attore spiega come passare dall'osservazione all'enforcement una route alla volta.

Perché questo è importante per i tuoi utenti

Fare la scelta giusta è utile per chiunque usi la tua applicazione.

Le persone ottengono un'esperienza più fluida perché non vengono sottoposte a verifiche sulla base di un punteggio vago. Le persone che lavorano con l'AI ricevono supporto per l'assistenza dichiarata nei workflow in cui è appropriata. Gli agenti legittimi ottengono un modo affidabile e strutturato di svolgere il proprio lavoro, il che riduce lo scraping e il carico sulla tua interfaccia. Il tuo team ottiene decisioni spiegabili, così le conversazioni con il supporto, le revisioni degli incidenti e le modifiche alle policy si basano sulle evidenze invece che sulle ipotesi.

Un login non è l'attore

Una delle fonti di confusione più comuni è l'account stesso. Una sessione autenticata ti dice quale account è in uso. Non ti dice chi sta dirigendo l'interazione corrente. Lo stesso account può essere usato dal suo proprietario mentre naviga tra le impostazioni al mattino, da un assistente che il proprietario ha chiesto di esportare un report a mezzogiorno, e da un agente che lavora tramite una chiave API alla sera.

Trattare tutti e tre allo stesso modo crea problemi in entrambe le direzioni. Se ogni richiesta sull'account viene considerata come se fosse del proprietario, un agente può raggiungere workflow progettati per una persona. Se ogni richiesta insolita viene considerata un attacco, gli strumenti del proprietario vengono bloccati. Separare l'attore dall'account consente alla tua applicazione di mantenere autenticazione e autorizzazione esattamente come sono, aggiungendo il contesto mancante su chi sta agendo in questo momento. Quel contesto è ciò che rende possibile offrire agli agenti un accesso strutturato senza aprire loro i workflow riservati agli esseri umani.

Inizia in modalità di osservazione

Ogni deployment inizia in modalità di osservazione. Proof of Actor registra i risultati mentre la tua applicazione risponde esattamente come prima. Il tuo team costruisce una baseline delle attività umane, assistite da AI, da agenti e sconosciute, la confronta con i risultati che già conosci e rivede eventuali falsi positivi prima che cambi una sola regola. Quando una policy è pronta, la abiliti per un workflow e poi espandi da lì.

Unisciti al founding developer program

Proof of Actor è in private beta con un piccolo gruppo di team applicativi. I founding developer selezionati possono ricevere fino a 12 months di accesso gratuito, entro limiti di utilizzo concordati, in cambio di feedback pratico. Ottieni supporto diretto all'integrazione dai nostri engineer, accesso anticipato alle capability e influenza sulle priorità.

Se devi distinguere il traffico umano da quello degli agenti AI nella tua applicazione, richiedi l'accesso anticipato e raccontaci l'interazione che vuoi capire meglio.

Esplora Proof of Actor, leggi how it works o vedi esattamente what the evidence can establish.

Fonti

PER GLI SVILUPPATORI

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent o Unknown.
basis
Quanto sono forti le evidenze: Verified, Declared, Inferred o Unknown.
evidence
I segnali dietro il risultato, così il tuo team può vedere il perché.

Inizia in modalità di osservazione: registra i risultati accanto ai tuoi log e non cambiare nulla finché non scegli una policy. Leggi la guida di integrazione Node.js

Domande frequenti

Come distingui il traffico umano da quello degli agenti AI?

Proof of Actor combina i segnali che la tua integrazione può osservare, come firme delle richieste, dichiarazioni del client, contesto della richiesta e segnali di interazione del browser, e restituisce una classe con una base esplicita.

Perché esiste la classe Human + AI?

Alcune persone lavorano con un assistente AI al loro fianco. Trattarle come completamente umane o completamente automatizzate fa perdere un contesto importante. Human + AI copre un'assistenza dichiarata oppure osservabile tramite un'integrazione supportata.

Un risultato Agent è la stessa cosa di un bad bot?

No. Molti agenti sono partecipanti legittimi. Un risultato Agent descrive chi sta agendo, non se l'azione è consentita. Le tue policy decidono come servire ciascun agente.

Cosa succede se il traffico non può essere classificato?

Viene segnalato come Unknown, un risultato di primo livello. Unknown non viene mai convertito in Human e non viene trattato come malevolo per impostazione predefinita.

Devo bloccare qualcosa?

No. Inizi in modalità di osservazione, esamini i risultati e abiliti le policy solo dove il tuo team è sicuro che siano adatte.

Scopri chi sta usando la tua app.

Private beta per un piccolo gruppo di founding developer.

Richiedi accesso anticipatoVisualizza i prezzi

Preferisci parlare prima? Parla con i fondatori