Dots possono inviare email? Permessi, approvazioni e Custom Rules

Dots può compiere azioni attraverso gli strumenti disponibili, ma chiedere una bozza non autorizza l'invio di un'email. Accessi, istruzioni, Custom Rules e controlli di sicurezza definiscono il percorso; l'auto-review valuta le azioni rispetto a questi elementi. Una delega utile indica destinatari, contenuto e condizioni, invece di affidarsi a «occupati tu della posta». Controlli ufficiali Dots.

Per una PMI il punto è separare preparazione e conseguenza esterna. Una bozza si può rivedere; un messaggio inviato raggiunge persone e può creare impegni. Il processo deve permettere al responsabile di capire che cosa sta approvando, con testo, destinatario e allegati visibili. Il collegamento di Gmail non risolve da solo questa decisione.

La guida usa la documentazione verificata il 9 ottobre 2026. Non descrive azioni eseguite su un account né garantisce che una regola elimini ogni errore. Per i concetti generali parti da Dots OpenAI: cosa sono; per l'accesso al prodotto in Italia verifica piani e disponibilità Dots.

Quando una richiesta autorizza soltanto una bozza?

Se chiedi «prepara una risposta», il risultato atteso è una proposta. Non deve essere interpretato come permesso di inviarla. La documentazione distingue questo caso dalle autorizzazioni per azioni specifiche e dalle eventuali condizioni future. Controls. Nel brief puoi rendere il confine ancora più chiaro: «la risposta resta da revisionare; mostrami destinatario, testo e allegati previsti».

Il revisore deve vedere l'intera azione proposta. Il testo può essere corretto ma destinato alla persona sbagliata. Un allegato può contenere una versione vecchia del listino. Una frase può promettere una data che il documento descrive soltanto come indicativa. L'approvazione utile riguarda questi elementi insieme, non il semplice fatto che l'email suoni professionale.

Quando manca un'informazione, il dot dovrebbe renderla visibile nel risultato. «Prezzo da confermare nella fonte approvata» è più utile di un valore ricavato da un messaggio non pertinente. Specifica quale documento prevale e chiedi di distinguere dati confermati e domande aperte. La guida su AI per rispondere alle email aziendali applica la stessa logica al processo di comunicazione, indipendentemente dal prodotto scelto.

La tabella è una guida di progettazione, non un elenco di permessi del tuo account. Le azioni disponibili dipendono dalle connessioni e dal workspace. Prima di assegnare un invio, controlla quindi anche la guida a Gmail, Drive e Slack con Dots: un canale e un accesso all'app non sono la stessa cosa.

Che cosa fa l'auto-review e quali limiti ha?

L'auto-review valuta se un'azione rientra nelle istruzioni, nei permessi, nelle Custom Rules e nelle regole di sicurezza. Non sostituisce la revisione del contenuto aziendale. Un'azione può avere un'autorizzazione circoscritta e richiedere comunque il controllo di un prezzo, di un nome o di una promessa. Documentazione Controls.

Per costruire un flusso leggibile separa dunque due domande: «questa azione è autorizzata?» e «questo risultato è corretto?». La prima riguarda il confine della delega. La seconda riguarda le fonti e il giudizio del responsabile. Se tratti l'autorizzazione come prova di qualità, rischi di saltare proprio il controllo che conosce il contesto commerciale o professionale.

Quando il prodotto chiede una conferma, leggi l'azione concreta proposta. Se il testo è cambiato rispetto alla bozza approvata, la revisione deve riguardare quella versione. Se il destinatario è diverso, il perimetro è cambiato. Una conferma chiara dovrebbe permettere di ricostruire la decisione: che cosa, a chi e in quali condizioni. Non usare frasi di consenso generiche per coprire una serie indefinita di azioni future.

Per eventuali autorizzazioni continuative, circoscrivi i casi ammessi e quelli esclusi. Se un caso non rientra nella regola, deve diventare una nuova decisione. Non è necessario partire subito da questo livello: per il primo progetto, bozza e revisione manuale aiutano a capire le variabili reali. Il percorso su come creare il primo dot parte da risultati interni proprio per rendere visibili gli errori prima delle conseguenze esterne.

Come scrivere Custom Rules controllabili?

Una regola utile contiene un comportamento, un ambito e una condizione di revisione. «Sii prudente» è difficile da verificare. «Per le risposte commerciali prepara bozze basate sul listino approvato; se prezzo, destinatario o allegato sono incerti, evidenzia il punto prima di qualunque invio» rende invece riconoscibile il confine.

Le Custom Rules non collegano gli account, non concedono accesso al computer e non rimuovono la sicurezza obbligatoria. Questa distinzione è esplicita nei controlli Dots. Una frase come «puoi leggere tutto» non sostituisce gli accessi disponibili né una scelta appropriata delle fonti. La regola deve stare dentro il progetto, non tentare di allargarlo senza una decisione.

Esempio di regola per bozze commerciali

Prepara soltanto proposte basate sul listino e sui materiali approvati indicati. Mostra destinatario, contenuto, allegati e questioni aperte. Non trasformare una disponibilità indicativa in una promessa. Richiedi una revisione prima di inviare o modificare documenti ufficiali. Se una richiesta esce da questo ambito, presenta il nuovo caso con le informazioni necessarie per decidere.

Questo esempio non è una protezione assoluta. Va verificato osservando i risultati e il percorso delle azioni. Se una regola produce domande su ogni dettaglio irrilevante, può rendere il lavoro poco utile. Se è troppo ampia, può non chiarire i casi che contano. Correggila a partire dagli errori reali del compito, lasciando esplicite le decisioni con conseguenze esterne.

Per un team conserva le regole operative nel luogo in cui sono gestite le responsabilità aziendali. Il dot può avere istruzioni proprie, ma una procedura non dovrebbe esistere soltanto nel contesto personale di un dipendente. La guida alla policy aziendale sull'uso dell'AI aiuta a dare un proprietario alle regole e alla loro revisione.

La ricerca proattiva può agire sulle app?

OpenAI descrive la ricerca proattiva con strumenti limitati alla lettura: non invia messaggi, non modifica app e non controlla browser o computer. Le azioni successive seguono le normali regole di autorizzazione. È quindi sbagliato descrivere la proattività come libertà di intervenire ovunque. Blog ufficiale su sicurezza e privacy Dots.

Per il lavoro aziendale, una proposta proattiva può essere un input da valutare. Se suggerisce di cambiare una presentazione, prima confronta la fonte e la conseguenza. Se suggerisce di contattare qualcuno, decidi destinatario e contenuto. Il fatto che il dot abbia individuato una possibilità utile non sostituisce la scelta di agire.

Le azioni sensibili hanno inoltre confini propri. Gli acquisti con carte già salvate richiedono approvazione; cambio password e trasferimenti finanziari vengono consegnati all'utente. La stessa fonte spiega i flussi di login privati, che tengono le credenziali fuori dal modello. Non incollare segreti in conversazioni o documenti: un testo fornito al dot può essere letto. Sicurezza Dots.

Come fermare il lavoro senza dimenticare delegati e ricorrenze?

Pause non va trattato come un interruttore universale. La pausa del task principale, le attività delegate in Activity e le ricorrenze in Scheduled sono percorsi distinti. La guida Controls indica di controllarli separatamente. Le etichette possono variare fra superfici, ma il confine operativo resta essenziale. Controlli ufficiali.

Quando un progetto viene sospeso, prepara una breve lista del lavoro attivo. Controlla il task principale, i delegati pertinenti e le programmazioni. Se cambia l'incarico, verifica quale parte deve fermarsi e quale output già prodotto resta da revisionare. Una pausa non cancella automaticamente file o contesto, tema approfondito in memoria e privacy Dots.

Una ricorrenza può continuare a richiedere una fonte o preparare risultati anche se tu hai smesso di pensarci. Per questo il termine dovrebbe essere definito fin dall'inizio e riesaminato quando cambia il progetto. La guida ai task programmati Dots spiega come controllare frequenza, fuso e condizioni di notifica senza presumere che siano impliciti.

Due scenari per distribuire preparazione e decisione

Una PMI manifatturiera risponde a una richiesta di offerta

Immagina un produttore piemontese che riceve una richiesta di offerta. Il dot prepara una risposta basata su schede e listino approvati. Mostra il destinatario previsto, i dati usati, gli allegati proposti e i punti da chiarire. Il commerciale verifica disponibilità e condizioni prima di decidere l'invio.

Se manca la conferma di una variante, il risultato deve lasciare il punto aperto. La proposta non diventa un'offerta ufficiale perché è scritta bene. Il commerciale può approvare una versione precisa o chiedere una correzione. L'esempio mostra perché la revisione della comunicazione deve includere le fonti, non soltanto grammatica e tono.

Un negozio prepara una richiesta a un fornitore

Immagina un negozio italiano che vuole raccogliere le informazioni necessarie prima di un riassortimento. Il dot prepara una bozza di richiesta al fornitore partendo dall'elenco concordato. Il titolare controlla articoli, quantità e destinatario. La richiesta iniziale riguarda la preparazione, senza ordini o acquisti automatici.

Se il lavoro passa a un'azione di acquisto, cambia la conseguenza e vanno rispettati i controlli appropriati. Il collegamento dell'account non è un budget aperto. Una regola aziendale dovrebbe rendere visibile questo cambio di fase, così chi approva sa se sta rivedendo una semplice domanda o un impegno economico. Nessuno dei due scenari è un caso cliente o una prova di funzionamento su siti specifici.

Come mantenere riconoscibile la versione approvata?

Una revisione deve riguardare una proposta precisa. Prima di decidere, identifica testo, destinatario, allegati e scopo. Se il dot modifica uno di questi elementi dopo il confronto, controlla la nuova proposta nel percorso disponibile. Non presumere che un consenso su una bozza valga per qualsiasi versione successiva. È una regola di organizzazione del lavoro che rende la delega leggibile anche a un collega.

Per i materiali commerciali, aggiungi la fonte dei dati che possono creare impegni: prezzo, disponibilità, caratteristiche e condizioni. Il revisore dovrebbe poter confermare questi punti senza ricostruire tutta la conversazione. Quando una fonte manca, la proposta deve restare aperta su quel dato. Riempire il vuoto con una formula generica può rendere il messaggio elegante ma meno controllabile.

Se sono previste azioni ripetute, descrivi i casi ammessi in termini osservabili. Il destinatario deve rientrare nel perimetro, il contenuto deve avere una fonte e le eccezioni devono produrre una nuova decisione. Questo articolo non invita ad attivare autorizzazioni continuative prima della prova: il primo percorso può restare interamente basato su bozze e revisione.

Un criterio utile è chiedersi se il responsabile riuscirebbe a spiegare a un'altra persona ciò che ha approvato. Se la risposta è «ho detto al dot di pensarci», il confine è ancora poco chiaro. Se è «ho revisionato quella risposta, con quel destinatario e quegli allegati», la decisione è più concreta. Il processo deve poi rispettare i controlli del prodotto e dell'organizzazione, senza considerare questa chiarezza una garanzia assoluta.

Infine, registra fuori dal contesto personale le decisioni aziendali che devono durare. Le istruzioni del dot aiutano il lavoro, ma non dovrebbero essere l'unica sede di una procedura che coinvolge più persone. Un documento approvato rende visibile anche quando una regola cambia e chi deve riesaminarla.

Quali errori evitare prima di delegare azioni?

Il primo errore è usare «gestisci le email» come autorizzazione indistinta. Il secondo è verificare solo il testo e ignorare destinatari e allegati. Il terzo è supporre che le Custom Rules concedano accessi. Il quarto è considerare la pausa del task principale sufficiente per qualunque attività. Sono errori diversi, ma hanno la stessa origine: un confine non rappresentato nel processo.

Un ulteriore errore è promettere che l'auto-review impedisca ogni sbaglio. Il controllo di autorizzazione aiuta a valutare l'azione; la revisione umana deve ancora conoscere le fonti e le conseguenze. Se il processo riguarda condizioni commerciali, comunicazioni delicate o materiali ufficiali, attribuisci la decisione a una persona riconoscibile.

Per iniziare scegli una bozza interna, una fonte approvata e un criterio di revisione. Quando il flusso è leggibile, valuta eventuali azioni più ampie. Se vuoi costruire una delega operativa con confini, fonti e passaggi esterni ben definiti, la progettazione di agenti AI di Giallo può partire da una tua email tipo e trasformarla in un processo controllabile. Il quadro degli agenti AI per aziende aiuta a scegliere dove la decisione deve restare umana.