For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/web/ai.md (or send Accept: text/markdown).
Funzionalità AI
Chat, task, policy dei modelli e bring-your-own-key.
Prova l'intelligenza artificiale falsa, quindi scegli un vero fornitore
Per il primo risultato, segui l'attività /dashboard del tutorial Web: avvia il flusso locale, accoda un prompt, eseguilo e visualizza il risultato. AI_PROVIDER=fake restituisce una risposta dimostrativa ripetibile senza inviare dati a un modello esterno o utilizzare una chiave API a pagamento.
Per la generazione reale, configura prima gli account persistenti, scegli un provider AI e segui la configurazione AI di seguito. Aggiungi un modello e il relativo prezzo al catalogo del database, scegli i modelli consentiti per ciascun alias e concedi allo spazio di lavoro l'accesso richiesto. Un alias come fast è una scelta amichevole mostrata all'utente; non è esso stesso l'ID modello di un provider esterno.
Anche uno sfondo AI task necessita del servizio lavori configurato. Se non viene visualizzata alcuna scelta del modello, controlla il catalogo e la policy di alias prima di riprovare. Se l'accesso viene negato, controlla i diritti dell'area di lavoro attiva. Conserva tutte le chiavi API del provider nella configurazione del server Web, non nel browser, nell'app mobile o nella finestra del desktop.
Segui il ciclo di vita dell'attività
L'API delle attività di produzione valida il workspace autenticato e il permesso prima di persistere un'attività e dispatchare il workflow ai.generate di Trigger.dev. Il router applica i requisiti di capacità e la policy dei modelli configurata.
POST /api/ai/tasks
→ authenticated workspace + entitlement
→ durable task record
→ Trigger.dev ai.generate
→ model routing + generation
→ usage record + result
→ transactional completion deliveryConfigura alias e budget
L'utente sceglie un alias abilitato: cheap, fast o smart. Il server controlla gli ID dei modelli sottostanti, le credenziali dei provider, la policy del workspace e l'applicazione dei budget. Il supporto cifrato delle chiavi proprie deve preservare la stessa frontiera server.
Mantieni esplicita la semantica del workflow
JobRunner promette solo enqueue, status e cancel. La semantica di workflow di Trigger.dev è esplicita, incluso il comportamento di esecuzione durevole. Non dedurre retry né garanzie di scheduling dal contratto generico.
Il percorso di submission di produzione usa idempotenza e ripristino dell'attività salvata per gestire il dispatch ambiguo. Il completamento della generazione è separato dalla consegna dell'email di completamento.
Installazione e configurazione
AI_PROVIDER=fake mantiene lo sviluppo deterministico. I provider di produzione si configurano lato server (OpenAI, Anthropic o un endpoint compatibile OpenAI) con chiavi che non entrano mai nei bundle client. AI_MODEL_POLICY mappa gli alias rivolti all'utente — cheap, fast, smart — a id di modello del catalogo; un alias vuoto rimuove la scelta dall'interfaccia.
Il catalogo dei modelli (ai-model-catalog) porta metadati di capability e prezzi immutabili così i record di utilizzo restano spiegabili dopo i cambi di prezzo.
POST /api/ai/tasks → durable task + Trigger.dev dispatch
GET /api/ai/tasks/{taskId} → status + result
/chat → streaming assistant surfaceFlusso di implementazione
La superficie di chat mantiene i thread per membro del workspace e streamma i token tramite chat-stream-runtime. Le generazioni più lunghe girano come task: autorizzate al confine API, eseguite dal workflow ai.generate e recuperabili tramite lo store di submission idempotente.
La modalità bring-your-own-key archivia le chiavi provider come envelope AES-GCM (CREDENTIAL_ENCRYPTION_KEY, byok-key-vault.ts); la decrittazione avviene solo dentro il percorso di esecuzione server. Utilizzo e costo stimato sono registrati per richiesta per i budget del workspace.
Verifica e risoluzione dei problemi
Verifica che un alias disabilitato sia assente dall'interfaccia, che i dinieghi di entitlement e budget avvengano prima del dispatch, che una submission ritentata riutilizzi il suo task e che una chiave BYOK archiviata non torni mai al client. Mantieni l'accettazione con modelli reali sul percorso smoke provider documentato.