Codex Automations: cosa cambia quando l’AI lavora su scadenze ricorrenti

Parliamo del tuo progetto →

Codex Automations è utile quando un compito ricorrente viene ristretto a un output semplice, controllabile e ripetibile. Nella documentazione OpenAI, Work e Codex hanno ruoli distinti; i task programmati si creano e si gestiscono dall’area Scheduled, con possibilità di modificarli, sospenderli o cancellarli. (Work e Codex, Scheduled tasks)

Per chi vuole progettare prima il flusso e poi automatizzarlo, può essere utile affiancare questa guida a Codex settings: le impostazioni da definire prima di affidare task all’AI, a Verbali con l’AI: separare decisioni, proposte e azioni, a AI benefit e automazione responsabile e a Consulenza strategica e governance IT.

Il punto pratico non è “far fare tutto all’AI”, ma scegliere un processo abbastanza ripetitivo da essere automatizzato e abbastanza semplice da essere controllato. OpenAI Academy presenta Codex come strumento per workflow avanzati e automazioni, mentre il materiale ufficiale insiste su task circoscritti, prompt strutturati e revisione prima dell’uso operativo. (Codex Academy, How OpenAI uses Codex)

Prima di iniziare

Risultato finale: un incarico periodico innocuo che, ogni lunedì mattina, produce una bozza di riepilogo in Markdown a partire da note e attività fittizie, senza inventare dati e senza inviare nulla all’esterno.

A chi serve: responsabili operativi, CTO, team software, chi gestisce backlog o report periodici e vuole capire se un compito ricorrente può essere affidato a Codex o a un task schedulato con controllo umano.

Strumenti:

un ambiente in cui i task programmati siano disponibili secondo la documentazione OpenAI;
una chat o area task dove creare il primo incarico;
un editor di testo per copiare i documenti fittizi;
una checklist di revisione umana;
un registro finale per annotare esiti e correzioni.

Prerequisiti:

nessun dato reale;
nessuna credenziale;
nessun invio automatico esterno;
un criterio chiaro per fermarsi se il risultato non rispetta il prompt;
la disponibilità a fare prima una prova manuale e solo dopo la ricorrenza.

Materiale fornito:

tre documenti fittizi completi;
un prompt pronto da copiare;
un output Markdown atteso;
un registro di controllo;
casi di errore o dato mancante;
criteri di accettazione e troubleshooting.

Materiale fittizio completo da copiare

Documento 1 — Note settimanali del team

Progetto: Portale richieste fornitori
Settimana: 6–10 ottobre 2026

Martedì:
- Il team ha confermato che il modulo contatti invia i dati al backend di staging.
- Mancano ancora i controlli sul campo “telefono”.
- Il cliente interno ha chiesto un riepilogo entro venerdì.

Mercoledì:
- È stata corretta una label ambigua nel form.
- È emerso che il campo “numero ordine” accetta valori non numerici.
- Nessuna decisione sul redesign.

Giovedì:
- Il test di esportazione CSV ha mostrato un’intestazione mancante.
- Il team ha aperto un ticket per la correzione.

Venerdì:
- La demo è stata rinviata di una settimana.
- Serve una sintesi breve con: stato, rischi, azioni aperte.

Documento 2 — Elenco attività aperte

ID | Titolo | Stato | Owner | Scadenza
A-14 | Validare campo telefono | aperta | UX | 2026-10-16
A-15 | Correggere numero ordine non numerico | aperta | backend | 2026-10-15
A-16 | Rifare intestazione export CSV | in corso | data | 2026-10-17
A-17 | Preparare sintesi per demo | aperta | PM | 2026-10-13

Documento 3 — Regola di stile dell’output

L’output deve avere 4 sezioni:
1. Stato
2. Rischi
3. Azioni aperte
4. Cosa manca per chiudere il ciclo

Regole:
- non inventare owner mancanti;
- non assegnare scadenze nuove;
- se un dato manca, scrivi “dato mancante”;
- usa elenchi puntati brevi;
- non superare 180 parole.

1. Delimitare il compito ricorrente prima di toccare la ricorrenza

Dove lavorare: nella tua area di lavoro o in una chat di prova, non nel task schedulato definitivo.

Cosa fare: definisci il lavoro in una frase operativa: “Ogni settimana riassumo lo stato del progetto da note e ticket, senza aggiungere dati esterni”. Questo passaggio serve a evitare il classico errore delle automazioni troppo ambiziose: il task sembra semplice, ma in realtà mescola sintesi, decisioni e invio di messaggi. OpenAI distingue infatti tra strumenti e usi diversi, e per i flussi programmati invita a trattare con cura istruzioni, condizioni e gestione del task in Scheduled. (Scheduled tasks)

Risultato atteso: un perimetro breve, leggibile, con un solo output e un solo destinatario interno.

Se il risultato diverge: se il compito contiene più di una finalità, spezzalo in due incarichi separati. Per esempio: riepilogo settimanale da un lato, email di inoltro dall’altro. In questa guida non automatizziamo l’invio, perché il laboratorio deve restare innocuo e verificabile.

Decisione pratica: automatizzare solo il lavoro che produce una bozza o una proposta controllabile, non il lavoro che compie un’azione irreversibile.

2. Preparare i dati fittizi e isolare ciò che non va inventato

Dove lavorare: in un file di testo separato o in una scheda di prova copiata pari pari.

Cosa fare: copia i tre documenti del materiale fittizio così come sono. Non correggerli prima del test: i piccoli difetti servono proprio a verificare se il prompt resiste a dati mancanti, incongruenze e dettagli inutili. OpenAI raccomanda task ben circoscritti e ambienti preparati in modo esplicito; nella pratica, questo significa evitare di mescolare il materiale sorgente con note libere o commenti non controllati. (How OpenAI uses Codex)

Risultato atteso: un blocco di input stabile, riutilizzabile, che puoi incollare identico nella prova manuale e poi nel task ricorrente.

Se il risultato diverge: se il materiale contiene dati reali o riservati, fermati e sostituiscilo con un esempio sintetico. Una ricorrenza ben progettata parte da input puliti; non va “aggiustata” a valle.

Esempio di controllo umano: chi prepara il materiale verifica che non ci siano credenziali, nomi di clienti, importi o scadenze operative reali.

3. Scrivere il prompt operativo e il criterio di qualità

Dove lavorare: nella stessa chat di prova, prima di programmare qualsiasi ricorrenza.

Cosa fare: copia il prompt seguente e usalo con i tre documenti forniti. Il prompt è costruito per produrre una bozza breve, non una decisione definitiva.

Sei un assistente di revisione operativa. Usa solo i tre documenti forniti sotto. Non aggiungere dati esterni. Non inventare owner, scadenze o decisioni.

Compito:
1. Leggi le note settimanali, la tabella attività e la regola di stile.
2. Produci una bozza in Markdown con 4 sezioni: Stato, Rischi, Azioni aperte, Cosa manca per chiudere il ciclo.
3. Se trovi un’incongruenza, segnala “dato mancante” o “da verificare”.
4. Non superare 180 parole.
5. Mantieni un tono operativo e sintetico.

Documenti:
Documento 1 — Note settimanali del team
Progetto: Portale richieste fornitori
Settimana: 6–10 ottobre 2026

Martedì:
- Il team ha confermato che il modulo contatti invia i dati al backend di staging.
- Mancano ancora i controlli sul campo “telefono”.
- Il cliente interno ha chiesto un riepilogo entro venerdì.

Mercoledì:
- È stata corretta una label ambigua nel form.
- È emerso che il campo “numero ordine” accetta valori non numerici.
- Nessuna decisione sul redesign.

Giovedì:
- Il test di esportazione CSV ha mostrato un’intestazione mancante.
- Il team ha aperto un ticket per la correzione.

Venerdì:
- La demo è stata rinviata di una settimana.
- Serve una sintesi breve con: stato, rischi, azioni aperte.
Documento 2 — Elenco attività aperte
ID | Titolo | Stato | Owner | Scadenza
A-14 | Validare campo telefono | aperta | UX | 2026-10-16
A-15 | Correggere numero ordine non numerico | aperta | backend | 2026-10-15
A-16 | Rifare intestazione export CSV | in corso | data | 2026-10-17
A-17 | Preparare sintesi per demo | aperta | PM | 2026-10-13
Documento 3 — Regola di stile dell’output
L’output deve avere 4 sezioni:
1. Stato
2. Rischi
3. Azioni aperte
4. Cosa manca per chiudere il ciclo

Regole:
- non inventare owner mancanti;
- non assegnare scadenze nuove;
- se un dato manca, scrivi “dato mancante”;
- usa elenchi puntati brevi;
- non superare 180 parole.

Criterio di qualità: il prompt è buono se produce sempre quattro sezioni, non inventa nulla e lascia esplicita ogni lacuna. Il terzo documento non è accessorio: è ciò che impone forma, lunghezza e regole di uscita. La documentazione OpenAI sui workflow con Codex insiste proprio su istruzioni chiare, strutturate e su task che possano essere controllati prima di essere automatizzati. (Codex Academy)

Risultato atteso: un prompt che il lettore del team può copiare senza modificarlo al primo test.

Se il risultato diverge: se il modello prolunga il testo, aggiungi un vincolo di lunghezza più netto. Se invece omette una sezione, rinforza il template con intestazioni obbligatorie e richiama anche il Documento 3 nel prompt.

4. Eseguire una prova manuale prima di creare la ricorrenza

Dove lavorare: nella chat di prova o nell’area in cui puoi lanciare un incarico singolo.

Cosa fare: esegui il prompt una sola volta, come se fosse il lunedì mattina della prima iterazione. Non schedulare ancora nulla. Questo è il momento in cui si scopre se il compito è abbastanza chiaro da essere ripetuto. OpenAI distingue l’uso operativo di Codex e Work e, per i task periodici, documenta la creazione e la gestione dall’area dedicata ai task programmati. (Work e Codex, Scheduled tasks)

Risultato atteso: una bozza Markdown breve, con le quattro sezioni, senza note fuori perimetro.

Output Markdown atteso, caso normale:

## Stato
- La demo è stata rinviata di una settimana.
- Il riepilogo richiesto è ancora necessario.

## Rischi
- Il campo “numero ordine” accetta valori non numerici: da verificare.
- L’export CSV ha un’intestazione mancante: rischio per il downstream.

## Azioni aperte
- A-14 Validare campo telefono — aperta — owner: UX.
- A-15 Correggere numero ordine non numerico — aperta — owner: backend.
- A-16 Rifare intestazione export CSV — in corso — owner: data.

## Cosa manca per chiudere il ciclo
- Confermare se la sintesi per la demo è stata inviata.
- Verificare che il campo telefono abbia un controllo definitivo.
- Chiudere il ticket sull’intestazione CSV.

Se il risultato diverge: se compaiono owner, date o decisioni non presenti nei documenti, la prova manuale non è superata. Correggi il prompt prima di passare alla ricorrenza.

Nota operativa: non confondere una bozza valida con una decisione finale. Se il task scrive bene, può ancora essere inadatto se produce affermazioni non verificabili.

5. Impostare la ricorrenza solo attraverso le funzioni documentate

Dove lavorare: nell’area di gestione dei task programmati, non in un flusso parallelo inventato.

Cosa fare: crea il task dalla funzione documentata di scheduling. La documentazione OpenAI indica che i task si possono creare da Scheduled, scegliendo una schedule o un evento supportato, e poi gestire dallo stesso punto con modifica, pausa o cancellazione. Non serve immaginare scorciatoie: basta usare ciò che è documentato. (Scheduled tasks)

Risultato atteso: il task compare nell’area di gestione e mostra chiaramente il suo stato.

Se il risultato diverge: se non trovi l’opzione di scheduling, non forzare il flusso con workaround non documentati. Verifica prima disponibilità dell’ambiente e permessi dell’account. Se l’area di gestione non è disponibile, il task resta manuale.

Controllo da fare prima della pubblicazione operativa:

il prompt è quello già testato a mano;
il materiale è fittizio o anonimizzato;
l’output atteso è ancora compatibile con la ricorrenza;
esiste un responsabile umano che approva l’uso continuo.

6. Gestire casi mancanti, errori e limiti senza fingere che tutto sia completo

Dove lavorare: nella seconda esecuzione di prova e nei casi di variazione del dataset.

Cosa fare: prova almeno due scenari di stress: uno con dato mancante e uno con incongruenza. Questo è il modo più rapido per capire se il task sa fermarsi quando non ha abbastanza informazioni.

Caso A — dato mancante

Modifica simulata: in Documento 2 elimina l’owner di A-16.

Comportamento atteso: il task non deve inventare un nome. Deve scrivere “dato mancante” o “da verificare” nell’azione corrispondente.

Esito corretto: la bozza resta utile perché segnala il buco, invece di colmarlo con supposizioni.

Caso B — incongruenza tra note e tabella

Modifica simulata: nel Documento 1 scrivi che l’export CSV è chiuso, ma nella tabella A-16 resta “in corso”.

Comportamento atteso: il task deve evidenziare la contraddizione e chiedere verifica umana.

Esito corretto: il testo segnala il punto da chiarire, senza scegliere arbitrariamente una delle due versioni.

Caso C — richiesta fuori perimetro

Modifica simulata: aggiungi al prompt “prepara anche una mail al cliente”.

Comportamento atteso: il workflow resta sul riepilogo; l’invio o la redazione della mail vanno trattati come incarico separato.

Esito corretto: la ricorrenza non si allarga da sola.

Risultato atteso complessivo: il lettore capisce che una buona automazione non è quella che fa di più, ma quella che sa dire “qui mancano dati” o “qui serve revisione”.

Se il risultato diverge: sospendi il task e torna alla prova manuale. Questo è coerente con l’impostazione ufficiale di OpenAI, che lascia spazio a modifica, pausa e cancellazione dei task da Scheduled. (Scheduled tasks)

7. Registrare gli esiti, decidere quando sospendere e chiudere il ciclo

Dove lavorare: in un registro condiviso, non nel testo prodotto dall’AI.

Cosa fare: dopo ogni esecuzione annota data, versione del prompt, esito, errori trovati e azione correttiva. Il registro non serve solo a dimostrare che il task gira: serve a capire se il task resta affidabile nel tempo. Nei workflow di Codex, il controllo umano e la revisione dell’ambiente restano parte del lavoro, non un passaggio opzionale. (How OpenAI uses Codex)

Registro riutilizzabile:

| Data | Versione prompt | Tipo esecuzione | Esito | Errori trovati | Azione correttiva | Task sospeso? |
|---|---|---|---|---|---|---|
| 2026-10-14 | v1 | manuale | ok / no | nessuno / elenco | nessuna / elenco | no / sì |
| 2026-10-15 | v1 | schedulata | ok / no | nessuno / elenco | nessuna / elenco | no / sì |
| 2026-10-22 | v2 | schedulata | ok / no | nessuno / elenco | nessuna / elenco | no / sì |

Criteri di accettazione finali:

il task produce sempre quattro sezioni;
non inventa owner, scadenze o decisioni;
segnala i dati mancanti;
resta sotto il limite di lunghezza;
può essere sospeso o corretto senza rifare tutto da capo.

Troubleshooting concreto

Se l’output è troppo lungo: riduci il contesto e vincola esplicitamente il numero massimo di parole.

Se l’output inventa dettagli: aggiungi un divieto esplicito nel prompt e fai emergere i dati mancanti come voce separata.

Se manca una sezione: usa un template rigido con intestazioni obbligatorie e includi di nuovo il Documento 3 nel prompt.

Se il task non è ripetibile: separa il riepilogo dal giudizio umano finale.

Se il task sembra funzionare ma non sai se fidarti: esegui tre prove consecutive prima di considerarlo stabile.

Se la ricorrenza non è disponibile nell’ambiente: tieni il workflow in modalità manuale; non sostituire una funzione documentata con un processo improvvisato.

Prova finale

Per chiudere il laboratorio, il controllo da rifare ogni volta è semplice:

copiare i documenti fittizi senza modificarli;
eseguire il prompt una volta a mano;
verificare che l’output rispetti struttura e limiti;
solo allora creare o mantenere la ricorrenza;
registrare esito e correzioni;
sospendere il task se introduce informazioni nuove o sbagliate.

Se questa sequenza funziona, l’automazione è abbastanza chiara da essere utile e abbastanza stretta da non trasformarsi in una scatola nera. È qui che Codex Automations cambia davvero il lavoro: non perché “fa tutto”, ma perché obbliga a scrivere meglio il processo prima di delegarlo. Per portare questo metodo dentro un processo reale, il punto di partenza è definire bene regole, controlli e responsabilità con un progetto di Consulenza strategica e governance IT, con AI benefit e automazione responsabile o con un percorso di Formazione, divulgazione e ricerca.