TAG non deve “aggiungere FDE”: deve costruire il proprio sistema operativo di AI Transformation
La call ha spostato il punto. La domanda non è più solo quale profilo tecnico assumere o se comprare un piccolo team. La domanda vera è che cosa deve diventare TAG nei prossimi due anni: un partner che forma sull'AI, o un soggetto che sa progettare il modo in cui persone, agenti, governance e tecnologie già presenti in azienda lavorano nello stesso sistema.
La sintesi dopo la call
"FDE è ancora una parola utile, ma rischia già di essere troppo stretta. Il profilo chiave è un AI operating architect: entra in discovery, capisce processo e vincoli, ispira use case credibili, regge il confronto con IT/compliance e lascia dietro asset riusabili. TAG non deve vendere agenti. Deve vendere una filosofia applicata: Human Intelligence e Artificial Intelligence nello stesso org chart."
Cosa è diventato più chiaro
- Il team ha talento, ma manca ancora un'identità vendibile. Sui primi progetti si vede capacità di analisi; il gap è trasformare quell'analisi in architettura di soluzione, con una narrativa consistente davanti al cliente.
- BNL e SNAI sono la palestra giusta. Non servono come casi isolati, ma come base per capire che cosa qualcuno compra davvero e trasformarlo in offering entro settembre-ottobre.
- L'architect deve entrare in discovery. Se arriva dopo, consegna. Se entra prima, qualifica il bisogno, vende una visione pragmatica e impedisce che TAG sembri solo un erogatore di formazione.
- Il differenziale TAG è governance embedded. Quando arrivano DPO, CISO, IT e policy, TAG deve saper dire: architettiamo dentro i vostri vincoli, non li aggiungiamo alla fine.
- Il sistema deve partire da TAG stessa. La trasformazione interna di TAG deve essere laboratorio visibile: non per mostrare lo stack, ma per mostrare metodo, ruoli, processi e layer di orchestrazione.
Cosa va maneggiato con più attenzione
- Build vs buy non è una scorciatoia. Comprare capacity tecnica può servire, ma se porta legacy, abitudini da system integrator o identità troppo radicate rischia di rallentare la traiettoria.
- Ci sono due business diversi da non confondere. Da una parte l'offering trasformativo, basato su contenuto, metodo e architettura. Dall'altra l'accreditamento tecnico/vendor per tavoli più B2G o di formazione massiva. Vanno serviti entrambi, ma non con lo stesso modello.
- Il mercato premierà chi dà un nome alla categoria. Giuseppe lo ha detto bene: forse non esiste ancora una definizione chiara. Il lavoro non è solo costruire capability, ma nominare il business case.
- Il ruolo di Claudio deve essere perimetrato. Ha senso se riguarda architettura, positioning e sistema nei primi progetti. Non ha senso come “quello che supervisiona tutto” senza un campo chiaro.
- L'hackathon del 9 luglio diventa uno spartiacque. Serve per osservare vettori, forze in campo e maturità del team prima di chiudere un modello di ingaggio.
Il nuovo centro: non FDE, ma AI operating architecture
Nel documento iniziale FDE era il nome della capability mancante. Dopo la call lo terrei come una parte del discorso, non come il titolo. Il titolo corretto è più vicino a AI operating architecture: la capacità di progettare come un'azienda prende decisioni, usa dati, governa rischi e fa lavorare agenti dentro processi reali.
Questo profilo non è un engineering manager e non è un trainer evoluto. Deve fare connecting dots: leggere processi, capire organizzazione e change management, parlare con IT e compliance, costruire o far costruire un prototipo, e allo stesso tempo dire al cliente quando la richiesta “voglio un agente verticale” non risolve il problema vero.
Qui TAG può distinguersi dagli operatori IT-oriented. Il cliente avrà già Copilot, Foundry, Bedrock, Gemini o altri pezzi di stack. TAG non deve essere proprietaria dello stack. Deve essere proprietaria dell'interpretazione: come quei pezzi diventano intelligenza utile dentro l'organizzazione.
Le sei domande, aggiornate con la call
1Profilo del Lead: non “builder senior”, ma architect operativo
Il profilo da cercare è founder-type con capacità architect hands-on, ma la call aggiunge un punto: deve saper stare già nel pre-sales e nella discovery. Deve ispirare use case concreti, non fare supercazzola da startup AI; deve alzare la barra abbastanza da far venire voglia al cliente, ma senza vendere qualcosa che TAG non può consegnare. In Italia ne servono pochi e forti: 2-3 figure vere valgono più di 10 builder medi. Se non si trovano subito, il ruolo può essere spezzato temporaneamente tra Claudio per architettura/positioning, un referente tecnico interno e capacity esterna mirata.
2Build vs buy: comprare solo ciò che accelera senza contaminare l'identità
La call rende più netto il criterio. Se le capability tecniche sono core per ciò che TAG vuole diventare, costruirle internamente è un asset di valore aziendale, non un costo. Il buy ha senso in modo opportunistico: per accelerare, per coprire picchi, per entrare in tavoli vendor/accreditamento, o per progetti molto custom. Ma non deve portare dentro una legacy culturale o un “noi sappiamo già come si fa l'AI” che sposti TAG verso system integration. La due diligence non è solo tecnica: bisogna capire se quel team rende TAG più veloce o più entropica.
3Fasaggio: Fase 1 deve produrre insieme identità, demo e pipeline
Resto dell'idea che il Solution Engineer/pre-sales vada anticipato, ma dopo la call lo direi meglio: in Fase 1 servono tre cose insieme. Primo, un architect che entra in discovery. Secondo, 2-3 demo e pattern nati da BNL/SNAI. Terzo, una narrativa commerciale unica, così il team non dà al cliente la sensazione di un'offerta ancora mobile. Il Mid e il Junior possono arrivare dopo; la consistenza del messaggio no.
4Modello: evitare il loop delle agenzie che vendono agenti verticali
Il rischio principale è diventare uno dei tanti player che nei prossimi due anni venderanno agenti in giro per l'Italia. Per evitarlo, TAG deve dire no a tre cose: delivery custom che non lascia apprendimento, pilot veloci che fanno fare male le cose più velocemente, e formazione separata dal ridisegno operativo. L'offerta deve partire da un problema reale, tradurlo in architettura, incorporare governance/compliance e lasciare asset riusabili.
5Asset riusabili: non repository, ma sistema di istituzionalizzazione
Giuseppe ha usato la parola giusta: istituzionalizzare. L'obiettivo non è archiviare codice, ma trasformare ogni progetto in normalità dell'offering. Da BNL e SNAI devono uscire pattern: rubriche di discovery, template di business case, componenti di context layer, playbook per DPO/CISO, demo, prompt library, metriche di adozione, criteri per costi token e AI Act. Se un elemento non aiuta il progetto successivo, resta delivery. Se aiuta, entra nel sistema.
6Infrastruttura: plain vanilla interno, partner esterni per il super custom
Il minimo non è avere un'infrastruttura enterprise proprietaria. È avere un plain vanilla dimostrabile: sandbox, dati sintetici realistici, context layer, demo su 2-3 use case, e capacità di spiegare come si integra con Copilot, Foundry, Bedrock, Gemini o lo stack del cliente. Per il deploy super custom si può portare al tavolo il partner migliore di volta in volta. La parte che TAG deve possedere è l'orchestrazione: connettori ricorrenti, governance, agent builder architetturale e metodo.
La mappa operativa che porterei avanti
| Decisione | Perché conta adesso |
|---|---|
| Dare un nome al ruolo e alla categoria. | “FDE” è utile internamente, ma il mercato capisce meglio una promessa: AI operating architecture, AI transformation system, o un nome TAG equivalente. Serve prima di settembre. |
| Usare BNL e SNAI come fabbrica dell'offering. | Non sono solo clienti: sono i primi due casi da cui estrarre metodo, demo, governance, business case e pattern di vendita. |
| Separare core interno e capacity esterna. | Core interno: architettura, orchestration layer, governance, discovery e asset. Esterno: picchi, custom verticale, accreditamento vendor quando serve. |
| Fare di TAG il primo caso di trasformazione. | Il team clienti deve vedere e governare anche la trasformazione interna: è la prova che TAG sa applicare a sé il modello che vende. |
| Definire il perimetro di Claudio dopo l'hackathon. | Prima osservare team, vettori e priorità; poi proporre un ingaggio su architettura, positioning e primi asset. Non una supervisione generica. |
| Arrivare a fine agosto con una tesi chiara. | Settembre-ottobre deve servire a chiudere offering e macchina operativa, non a discutere ancora che cosa sia il business. |
Come pesare l'architect
Non sono metriche quantitative: sono i pesi qualitativi emersi dalla call.
La raccomandazione secca
TAG deve costruire una capability tecnica interna, ma non deve definirsi come tech shop. Deve definirsi come il partner che rende l'AI operativa dentro l'azienda.
- Architect in discovery, non dopo il deal.
- Offering formalizzato da BNL/SNAI, non disegnato in astratto.
- Buy solo se riduce tempo e rischio senza importare legacy.
- Governance, compliance e context layer come parte della proposta, non appendice.
Frase da usare nel prossimo confronto
"Secondo me il tema non è assumere FDE o comprare un team tecnico. Il tema è decidere se TAG vuole diventare il soggetto che porta l'AI dentro l'operating model delle aziende. Se sì, le capability tecniche sono core, ma il prodotto non è la tecnologia: è il modo TAG di mettere insieme persone, agenti, contesto e governance. Quello va costruito su BNL e SNAI, reso ripetibile entro settembre, e poi scalato."