Domande frequenti

Entrambe le cose: una software house di Torino che progetta e sviluppa software su misura, e un partner che affianca le aziende nelle scelte tecnologiche.

Seguiamo un prodotto digitale dalla strategia di design al rilascio e alla manutenzione evolutiva, e facciamo anche auditing e tutoring tecnico. Lavoriamo su piattaforme SaaS, gestionali, applicazioni web e mobile e sistemi di intelligenza artificiale integrati nei processi.

Partner non è un modo di dire: vuol dire capire obiettivi e vincoli prima di proporre qualcosa, e dirti quando una scelta rischia di costare cara.

La società è nata a Torino nel settembre 2022; l'esperienza delle persone è molto più lunga.

Il fondatore lavora nel software da oltre vent'anni, e tutti i collaboratori sono senior con almeno dieci anni di mestiere. Volcanic Minds nasce da quegli anni passati con grandi aziende, startup e PMI, e da un'osservazione ricorrente: alle aziende non mancavano i fornitori, mancava un partner tecnologico su cui contare.

Teniamo distinte di proposito l'età della società e l'esperienza di chi ci lavora. È la stessa ragione per cui dichiariamo di non avere ancora certificazioni ISO.

Industria, grandi aziende e aziende di servizi, sanità, banca e finanza, evoluzione digitale, green e mobilità, pubblicità.

I clienti tipo sono PMI, startup e gruppi industriali. I case study pubblicati vanno dagli audit con agenti AI alla sanità digitale, dalle officine meccaniche al telesoccorso, dalla supply chain ESG alla pianificazione del lavoro.

È la nostra divisione dedicata all'AI, perché oggi integrare flussi e processi agentici è una scelta di business e di strategia prima che tecnologica.

Per questo dedica tempo alla formazione continua da trasmettere ai nostri partner, come chiamiamo i clienti con cui costruiamo i prodotti. Si occupa anche di valutazione della maturità AI in ambito industriale, aziendale e di processo, di architetture multi-agente e di governance secondo l'EU AI Act, ed è il passo più recente della nostra strategia di crescita.

Perché la trasparenza si verifica meglio di quanto si dichiari.

Il Playbook descrive in inglese come lavoriamo: storia e cultura, gestione dei progetti, preventivi e pagamenti, crescita delle persone e limiti che ci diamo. Chi valuta di lavorare con noi può leggere a cosa ci impegniamo prima di firmare, e chiedercene conto dopo.

È un documento vivo: ogni sezione si rivede almeno una volta l'anno e riporta in fondo la data dell'ultima revisione. Non è un documento commerciale, e dove una pratica è ancora imperfetta lo dice.

Sul piano degli impegni lo affianca il Trust Center, che raccoglie in una pagina garanzie, consegna e condizioni di uscita.

Cinque linee di servizio, che si usano insieme o separatamente.

• Design Strategy: ricerca, UX e UI e definizione del prodotto, prima di scrivere codice.
• Digital Factory: progettazione e sviluppo end-to-end, web e mobile, backend, cloud, DevOps e integrazioni.
• Project Leading: analisi, coaching agile, product ownership e guida tecnica, per chi ha bisogno del metodo più che delle mani.
• AI Orchestration: workflow in cui agenti AI svolgono compiti complessi, integrati con dati e sistemi reali.
• AI Enablement: percorsi pratici sull'AI per i team tecnici e per chi decide.

Perché il software su misura si adatta ai tuoi processi, mentre quello standard chiede ai processi di adattarsi.

Conviene quando il modo in cui lavori è un vantaggio da proteggere, o quando lo standard ti costringe a doppi inserimenti e a fogli di calcolo a margine. Un gommista gestisce depositi stagionali, un'officina di biciclette componenti e cicli di manutenzione: flussi diversi chiedono software diversi.

Non è sempre la risposta giusta. Molti processi hanno bisogno di un modulo fatto bene e di un database pulito, non di un sistema nuovo, e in quel caso te lo diciamo. Si può anche partire da un solo modulo.

Con una call conoscitiva, gratuita e senza impegno.

Ci racconti il progetto, noi facciamo le domande che servono a capire se è un lavoro che sappiamo fare bene. Se richiede competenze che non abbiamo lo diciamo e, dove possiamo, indichiamo a chi rivolgersi. Se dall'analisi emerge che la richiesta non risolve il problema, lo diciamo prima del preventivo, non dopo la firma e tanto meno dopo la consegna.

Dipende da quanto è definito il lavoro: a corpo se perimetro e tempi sono chiari, a capacity se non lo sono ancora.

Il progetto a corpo ha perimetro, tempi e consegne fissati nel preventivo, ed è il modello per le iniziative che hanno già una forma. Con la capacity riservi in anticipo tempo del team: serve per i picchi di lavoro o quando le specifiche sono ancora in movimento, così la disponibilità non diventa il collo di bottiglia.

La garanzia di un mese dopo il rilascio è prevista sui progetti a corpo.

Sì: coinvolgiamo i fornitori giusti della nostra rete e gestiamo quelli che hai già scelto.

Negli anni abbiamo costruito una rete di aziende e professionisti specializzati, e coordinarli dentro un unico progetto riduce attriti e rallentamenti. Se una parte del lavoro è affidata a collaboratori esterni lo sai prima dell'avvio, e la responsabilità del risultato resta nostra.

Conosci nomi e ruoli del team prima dell'avvio, e le persone non ruotano per nostra comodità.

Il team è fatto di professionisti senior, e la continuità vale più dell'ottimizzazione delle risorse: se qualcuno deve cambiare lo sai da noi, prima, con un passaggio di consegne. Hai un unico referente, e se qualcosa nel rapporto non funziona puoi dirlo a lui o a chi sta sopra di lui. Meglio una call scomoda alla terza settimana che una cortese alla fine.

Di persona quando conta, da remoto per scelta nel lavoro operativo.

Un rapporto non si costruisce solo attraverso uno schermo: all'avvio incontriamo le persone, ci stringiamo la mano e fissiamo insieme obiettivi e impegni. Il lavoro operativo procede poi da remoto, con incontri mirati intorno alle milestone chiave e le cerimonie che il progetto richiede. Organizzare il lavoro in modo agile ci permette di collaborare con i migliori professionisti, ovunque siano, con costi più bassi ed equilibrio. La sede è a Torino, in Corso Vinzaglio 24.

Entrambe le cose: di norma progettiamo l'intero ecosistema, ma prendiamo anche solo una parte.

Nei case study ci sono tutti e tre i casi: un progetto end-to-end, dall'analisi al database fino a licenze e pagamenti; un frontend costruito sui wireframe del partner mentre un altro fornitore completava il backend; analisi, UX e dashboard sopra un backend solido che il cliente aveva già.

Sì, e dirlo prima protegge il progetto più di qualunque clausola, oltre alla nostra reputazione.

Non prendiamo lavori fuori dal nostro dominio, che non ci interessano o che non sappiamo fare bene. Non accettiamo scadenze che riteniamo impossibili: proponiamo un perimetro che stia nella data o una data che regga il perimetro. Non costruiamo prima di aver validato il problema, non vendiamo AI dove l'AI non è la risposta e non creiamo dipendenze: niente lock-in, infrastruttura non documentata o codice leggibile solo da noi.

Questi limiti li ricontrolliamo per tutta la durata del progetto, non solo all'inizio.

Sì, anche senza progetto, e a tenerla sono le stesse persone che quei sistemi li progettano e li mettono in produzione.

È la ragione per sceglierci al posto di una società di formazione: chi spiega un costo in token o un controllo umano lo ha dovuto progettare davvero. Niente teoria fine a sé stessa: quella la lasciamo ad altri. Se cerchi certificazioni o crediti formativi ti indirizziamo ai due enti di formazione con cui collaboriamo da vicino. Un percorso che conclude che l'AI non conviene è un percorso riuscito.

Mezza giornata per chi decide, più incontri distanziati nel tempo per i team commerciali e tecnici.

Saper programmare serve solo nei percorsi tecnici; quelli su decisioni e governance sono pensati per direzione, ufficio legale e compliance. Gli obiettivi si fissano prima di iniziare, per esempio saper valutare un caso d'uso, leggere il costo di un'operazione o riconoscere quando serve un controllo umano, così alla fine si verifica se il percorso è servito. I casi d'uso sono i tuoi: compiti reali che il tuo team affronta ogni giorno.

Con un'analisi dei requisiti reali, da cui esce un preventivo dettagliato: niente prezzi al volo né di comodo.

Una cifra al volo sapremmo darla, ma sarebbe gonfiata o sbagliata, e non è il modo giusto di iniziare a conoscerci. Il preventivo contiene sempre una forchetta di spesa invece di una cifra che finge di essere certa, i termini di pagamento con le milestone, il dettaglio di cosa verrà consegnato e i costi ricorrenti. Il budget comprende sviluppo, test, rilascio e passaggio di consegne.

Con il preventivo in mano decidi se procedere con il progetto intero o per gradi.

Un MVP parte da 15.000 €, una piattaforma Enterprise da 50.000 €.

Sono soglie d'ingresso, non un listino: servono a capire subito se il progetto sta nel tuo ordine di grandezza. Un gestionale su misura per un'officina, per esempio, parte da circa 15.000 € nelle versioni essenziali e arriva a cifre più alte nei sistemi più evoluti.

L'analisi misura quello che fa variare la cifra: le integrazioni con i sistemi esistenti, i componenti di intelligenza artificiale, i requisiti di sicurezza e conformità, il numero di ruoli e di flussi. Nel preventivo ogni voce che alza la cifra è motivata, non sommata a forfait, e il valore esatto arriva nella sua forchetta.

Non succede: se i requisiti iniziali non cambiano, il prezzo si ferma al massimo della forchetta, già scritto nel contratto, e l'eccedenza la assorbiamo noi.

Se invece cambiano perimetro o tempi, l'impatto su budget e scadenze te lo comunichiamo subito, prima di procedere, insieme a una proposta di ripianificazione. Nulla viene sviluppato, e nulla viene fatturato, senza la tua approvazione.

Hosting, licenze di terze parti e uso dei modelli AI, tutti dichiarati nel preventivo e resi visibili durante l'esercizio.

Sono costi tuoi, quindi è giusto conoscerli prima: li esplicitiamo subito, così hai chiaro il costo totale di possesso (TCO). Un investimento non ha senso se i costi dei servizi esterni lo rendono insostenibile nell'uso di tutti i giorni: per questo li progettiamo visibili fin dall'inizio. Sul software che sviluppiamo per te non c'è nessun canone di licenza. La manutenzione correttiva ed evolutiva, se la vuoi, è un contratto a parte con SLA espliciti.

A milestone: un acconto, pagamenti legati all'avanzamento e un saldo a fine lavori.

La struttura si calibra sulla complessità del progetto e sulla chiarezza dei requisiti, e si concorda prima dell'avvio. Per un progetto tipico, che dura in media circa quattro mesi:

• acconto dal 25%, per i clienti con cui lavoriamo da anni, al 35%, per progetti ad alta complessità o con requisiti molto evolutivi;
• milestone intermedie legate alle fasi, con sempre una milestone alla fine dello sviluppo, prima di controllo qualità e test;
• saldo fatturato qualche giorno dopo la sessione di accettazione, per lasciarti il tempo di valutare il rilascio: niente formula «visto e piaciuto», perché consegniamo sistemi complessi, non prodotti da banco.

Ogni milestone pagata trasferisce a te la proprietà della parte di progetto che copre: quello che paghi è tuo da subito, ben prima della fine dei lavori.

Sui progetti a corpo, un mese di garanzia per i bug bloccanti e le attività minori.

La distinzione è netta: i bug sono coperti dalla garanzia, le nuove funzionalità si quotano. Passaggio di consegne e sessioni di accettazione sono già inclusi ed esplicitati nel contratto. Finito il mese, la manutenzione continua solo se la vuoi, con un contratto e SLA dedicati, e senza alcun obbligo di sceglierci anche dopo.

Sì, a entrambe le richieste, subito dopo la prima call conoscitiva.

Ti mostriamo un contratto di esempio, con un testo che si adatta alle esigenze giustificate del progetto. Per la riservatezza abbiamo un nostro modello di NDA bilaterale; valutiamo e firmiamo volentieri quello del tuo ufficio legale, purché sia equo e non crei asimmetrie fra le parti.

Sì, con una polizza di responsabilità civile professionale e una copertura cyber.

La copertura cyber interviene sui danni e sugli attacchi informatici. Gli estremi delle polizze li forniamo su richiesta in fase contrattuale: di solito li chiedono l'ufficio acquisti o il legale.

A volte sì, ma resta un'eccezione: il nostro lavoro è realizzare progetti.

Valutiamo di entrare nel capitale di progetti ambiziosi, di solito già in crescita o in manutenzione, come forma di finanziamento alternativa per chi la cerca. Ogni proposta si valuta sull'allineamento degli obiettivi, e la maggior parte la declinamo.

Un progetto tipico dura in media circa quattro mesi, ma la stima vera esce dall'analisi.

Quattro mesi sono una media storica, non una promessa: i tempi dipendono dal perimetro, e non diamo scadenze preconfezionate. Due esempi dai case study: una piattaforma di audit con agenti AI completata in circa quattro mesi, con un primo MVP funzionante fra sei e otto settimane; una piattaforma di pianificazione del lavoro, che richiede tipicamente fra tre e sei mesi con un team dedicato.

In ogni caso non aspetti mesi al buio: le consegne sono incrementali e vedi software funzionante lungo tutto il percorso, perché sono il tuo feedback e la tua visione del prodotto a farci andare veloci.

Fissando milestone realistiche, non attraenti, e dicendovi subito se una data è a rischio.

Le date nascono da un'analisi rigorosa di perimetro, tempi e figure necessarie. Preferiamo perdere una trattativa in fase di stima che mancare una scadenza inventata per vincerla. Se un ritardo diventa probabile lo sai subito, con una proposta di ripianificazione, non il giorno della consegna. E se una scadenza ci sembra impossibile, proponiamo un perimetro più piccolo o una data diversa.

Si apre una richiesta di modifica: valutiamo insieme l'impatto e decidi tu.

Il cambiamento fa parte di ogni progetto vero. Per ogni nuova esigenza stimiamo l'effetto su tempi e costi, e insieme si decide se integrarla subito, cambiare le priorità o rimandarla. Se la modifica resta nel perimetro concordato il costo non cambia; se lo supera, lo sai prima di decidere.

Nulla viene sviluppato, e nulla viene fatturato, senza la tua approvazione.

In Scrum, con incontri regolari: il tuo coinvolgimento per tutto il progetto è una condizione, non un optional.

Il percorso ha quattro fasi: si definiscono obiettivi, perimetro e tempi; si confermano design e funzioni con prototipi e feedback precoci; si sviluppa per incrementi; si rilascia e si fa evolvere la soluzione. Dentro, le cerimonie di Scrum: pianificazione dello sprint, brevi allineamenti quotidiani, revisione con dimostrazione del lavoro fatto e retrospettiva.

Ci vediamo con te indicativamente una volta a settimana, per avanzamento, criticità ed esigenze di entrambe le parti. L'obiettivo è che tu possa sempre guardare software che funziona, non un report.

Con una fase di test fatta insieme prima del rilascio, e una sessione finale che verifica tutto il sistema.

Il controllo qualità prima del rilascio coinvolge entrambe le parti, con verifiche e segnalazioni: è la fase che evita le sorprese. Al rilascio si fa un giro completo su tutto il sistema. La fattura di fine lavori non parte subito: lasciamo qualche giorno per le tue valutazioni a porte chiuse. Nel mese successivo, sui progetti a corpo, restiamo presenti per i problemi bloccanti e le attività minori.

Sì, ed è spesso l'approccio che consigliamo.

Si rilascia per primo il punto che fa più male, e le priorità successive le decide l'uso reale invece di un'ipotesi fatta a tavolino. Il preventivo è pensato anche per procedere per gradi, e la fase di prototipo serve a confermare design e funzioni prima di investire nello sviluppo. Nella piattaforma di audit con agenti AI, un primo MVP funzionante è arrivato fra sei e otto settimane.

Con indicatori concordati all'inizio, legati al valore per il business e non al fatto che il software funzioni.

L'assenza di bug è un requisito, non un risultato. Prima di partire definiamo insieme i KPI che vuoi ottenere: processi automatizzati, errori ridotti, tempo di lavoro recuperato, prestazioni, capacità di crescere. È su quelli che si misura se la spesa tecnologica è diventata un investimento.

Sì: progettiamo secondo le WCAG 2.2 di livello AA, e fino al livello AAA quando il progetto lo richiede.

Contrasto, navigazione completa da tastiera, ruoli e stati esposti alle tecnologie assistive. L'accessibilità entra nei requisiti dall'inizio, perché aggiunta alla fine costa molto di più e rende meno. E non serve solo a chi ha una disabilità: su una console usata per un turno intero, un'interfaccia accessibile migliora il lavoro di tutti. Puoi iniziare a valutarci da questo sito: la dichiarazione di accessibilità riporta cosa rispetta, cosa manca e come lo abbiamo verificato.

Solo se lo chiedi tu o se lo prevede il contratto.

Internamente lavoriamo per obiettivi con scadenza, ci fidiamo delle persone e non chiediamo timesheet. Quando lavoriamo con strumenti di intelligenza artificiale, le ore che quegli strumenti ci fanno risparmiare non te le fatturiamo.

Tua, al 100%, senza canoni di licenza né vendor lock-in, scritto nero su bianco nel contratto.

La proprietà passa milestone per milestone: ogni milestone pagata trasferisce a te la parte di progetto che copre. È il presupposto del contratto, non una concessione a fine lavori.

Per non legarti a noi usiamo tecnologie standard e documentate, e consegniamo accessi, repository e documentazione delle API in formato Swagger/OAS.

Sì, i componenti di terze parti, che restano sotto la loro licenza.

Librerie e prodotti con licenza aperta o chiusa non possiamo cederli, perché non sono nostri. Te li nominiamo prima che ti impegni, e gli eventuali costi di licenza ricorrenti compaiono nel preventivo.

Tutto quello che serve per mantenere ed evolvere il software senza di noi.

Il repository con l'intera cronologia, la documentazione delle API in formato Swagger/OAS, gli accessi ai servizi e ai sistemi, quando non li hai creati tu fin dall'inizio come ti consigliamo, la documentazione dei processi, la configurazione dell'infrastruttura DevOps, le procedure di ripristino dei backup e sessioni di formazione per il tuo team o per chi ne prenderà il posto.

Se continui a lavorare con noi dev'essere perché lo vuoi, non perché non puoi farne a meno.

Niente di bloccante: il codice è già tuo e il resto è progettato per essere ripreso da altri.

Il software gira su tecnologie diffuse che qualsiasi team competente conosce. I dati stanno in database standard che si esportano senza passare da noi e senza formati chiusi. La logica di business non dipende da un singolo fornitore di modelli AI, quindi anche quella parte resta sostituibile.

La continuità è una conseguenza dell'architettura, non una promessa contrattuale.

Sì, sulle iniziative di larga scala, con termini definiti nel contratto.

Ha senso dove investimento e impatto operativo rendono la continuità un rischio da presidiare formalmente; depositario e condizioni di rilascio si stabiliscono caso per caso. L'escrow però serve soprattutto con chi non consegna il codice: da noi il sorgente diventa tuo milestone dopo milestone, quindi copre un rischio residuo, non quello principale.

Li dimensioniamo sul danno che un fermo produrrebbe alla tua azienda, e li concordiamo prima di andare in produzione.

Non esiste un valore standard di RTO e RPO: dipende da quanto ti costa un'ora di sistema fermo o di dati persi. Insieme ai backup consegniamo le procedure di ripristino documentate e i metodi per portarne una copia sui tuoi server. Un backup che solo il fornitore sa ripristinare non è un backup, è un'altra dipendenza.

Solo chi autorizzi tu, con utenze nominali che puoi revocare in qualsiasi momento.

Gli account li crea il committente: non ci creiamo utenze autonome sui tuoi ambienti, chiediamo di essere autorizzati su quelli esistenti o di essere aggiunti al tuo team. Puoi rivedere o revocare i nostri accessi senza passare da noi e senza che il sistema smetta di funzionare, per infrastruttura, backup e pipeline DevOps. A fine progetto chiediamo comunque che vengano revocati.

Il rilascio è l'inizio: se lo vuoi, proseguiamo con manutenzione, SLA espliciti e formazione.

Proponiamo contratti di manutenzione correttiva ed evolutiva con livelli di servizio chiari sui tempi di intervento, e contratti di controllo qualità e assistenza tagliati sul progetto. I bug restano distinti dalle nuove funzionalità: i primi sono in garanzia, le seconde si quotano. Formazione e passaggio di consegne servono a rendere il tuo team autonomo nell'uso quotidiano.

In base al problema e agli obiettivi di business, mai per moda o per nostra comodità.

Cloud native, microservizi o CMS headless sono risposte diverse a domande diverse: quella giusta è cosa ti darà vantaggio. Scegliamo tecnologie standard, diffuse e documentate, perché un altro team deve poter subentrare senza riscrivere. Nei progetti recenti ricorrono Node.js, TypeScript, React, React Native, PostgreSQL e container Docker, con architetture mobile-first pronte a crescere.

Sì, è una parte centrale del nostro lavoro.

Ci colleghiamo a ERP, CRM, MES, MRP, APS e sistemi legacy tramite REST API, batch, WebSocket, MQTT, AMQP e altri canali sicuri. Progettiamo architetture API-first, così anche servizi esterni o sistemi datati possono entrare nell'ecosistema. Il gestionale contabile resta dov'è: i dati passano da un sistema all'altro senza doppi inserimenti.

Sì, partendo da quello che ogni apparato espone e senza toccare l'hardware in campo.

Analizziamo API, porte seriali, file e servizi del produttore, e ci colleghiamo con REST API, WebSocket, MQTT, AMQP o batch. Per i protocolli proprietari scriviamo un adattatore dedicato. In un progetto di telesoccorso, per esempio, i nuovi dispositivi si aggiungono via Bluetooth con una procedura guidata dall'app mobile.

Di solito no, almeno non subito.

Costruiamo prima la parte che oggi è gestita peggio e la colleghiamo via API agli strumenti che hai. Se sostituire qualcosa conviene, lo si decide dopo, con i dati d'uso alla mano. Anche i servizi esterni che integriamo li progettiamo sostituibili, non come fondamenta.

Sì, con un approccio decoupled: un'interfaccia nuova collegata via API al sistema che hai già.

Molte aziende hanno backend solidi e interfacce che rallentano il lavoro. Rifare solo il frontend abbatte i costi di una ricostruzione totale, riduce il rischio e allunga la vita del software. Si concordano i contratti delle API con chi gestisce il backend, si lavora con risposte simulate finché il collegamento non è pronto e si tipizza tutto con TypeScript. Lo abbiamo fatto, per esempio, per una dashboard di assistenza sul campo e per una di telesoccorso.

Sì: le web app sono responsive, e quando serve realizziamo app native cross-platform.

Progettiamo mobile-first, che non vuol dire schiacciare la versione desktop su uno schermo piccolo: sul telefono le informazioni hanno una gerarchia propria, pensata per chi le usa lì. Quando il caso d'uso lo richiede sviluppiamo app native cross-platform, per esempio in React Native, come nella piattaforma di sanità digitale.

Sì, se l'architettura lo prevede dall'inizio, ed è così che li progettiamo.

Le piattaforme SaaS containerizzate scalano le risorse con richieste e utenti, e le operazioni pesanti vanno su microservizi dedicati. Nelle architetture multi-azienda una nuova società è una configurazione, non una riscrittura; quelle multi-tenant tengono separati workspace e dati di clienti diversi. Costi e prestazioni restano calibrabili.

Dove serve che risiedano: sul cloud scelto insieme o sulla tua infrastruttura.

Non siamo legati a un solo fornitore: lavoriamo abitualmente con OVH, AWS, Hetzner, DigitalOcean, Seeweb, Aruba e Azure, e spesso sull'infrastruttura del cliente, con Kubernetes, container o macchine Linux Debian e Ubuntu. Cloud europeo, cloud sovrano nazionale, il tuo account cloud o on-premise: la scelta si fa all'inizio sui vincoli normativi, contrattuali e di budget, non sulla nostra comodità.

In base al contesto: credenziali, Single Sign-On aziendale, autenticazione a più fattori o codici monouso.

Ci integriamo con l'identity provider aziendale per il Single Sign-On, attiviamo l'autenticazione a più fattori, anche con app TOTP, e per chi accede di rado usiamo codici OTP monouso via email. Sulle web app i token di sessione stanno in cookie HttpOnly e non nel localStorage, così un attacco XSS non riesce a leggerli.

Con la sicurezza progettata dall'inizio: accessi per ruolo, minimo privilegio e servizi isolati.

Le misure tipiche sono HTTPS obbligatorio, autenticazione a più fattori, permessi per ruolo con il principio del minimo privilegio, isolamento dei servizi in container e protezione dei dati personali anche dentro i sistemi agentici. Le decisioni rilevanti restano tracciabili. Non abbiamo una certificazione ISO 27001 aziendale, e lo diciamo.

Quando i requisiti lo chiedono, sono progettati per non perdere nulla: la disconnessione si vede, e i dati si riallineano quando la rete torna.

La perdita di collegamento è un evento visibile, non un silenzio. Gli eventi si accodano e vengono riallineati alla riconnessione. Dove la rete è lenta o perde pacchetti, come in molte officine, si studia la topologia e si progettano chiamate e dati scambiati per reggerla.

Sì: una suite TypeScript e Node.js che usiamo nei nostri progetti, più alcuni progetti sperimentali pubblici.

La suite comprende un framework backend basato su Fastify, strumenti per autenticazione a più fattori e invio di email e un pannello di amministrazione; pubblichiamo anche esperimenti su Mastra e sulla governance dell'AI. La suite gestisce già la multi-tenancy e offre embedding e ricerca vettoriale (pgvector) per il RAG. Il fatto che sia open source è ciò che rende un framework nostro compatibile con l'impegno a non usare tecnologie proprietarie: il codice è pubblico e chiunque può mantenerlo.

Entrambe le cose.

Nei sistemi nuovi la conformità è un requisito non funzionale dell'architettura, dalla prima riga di codice. Per quelli in esercizio partiamo da un'analisi dei gap rispetto agli obblighi del Regolamento (UE) 2024/1689, così da pianificare solo gli interventi necessari, senza riscritture superflue.

No: gli obblighi vanno tradotti in controlli dentro il software.

Un PDF o la licenza di una dashboard possono segnalare un rischio, ma non impediscono a un agente di violare una policy o di scrivere su un database senza supervisione. Per questo servono controlli ingegnerizzati nel sistema. Lavoriamo accanto ai consulenti legali, non al loro posto: loro interpretano gli obblighi, noi li mettiamo a terra.

No, non ancora, e non dichiariamo certificazioni che non abbiamo.

Volcanic Minds è nata nel settembre 2022. Seguiamo pratiche riconosciute e ci appoggiamo a fornitori cloud che quelle certificazioni le hanno, ma è una cosa diversa e va detta. Siamo disponibili ad avviare un percorso di certificazione per i progetti e i clienti che ne hanno reale necessità: se il tuo processo d'acquisto la richiede, conviene dirlo alla prima call.

Sì, perché il modello dei controlli lo costruiamo sul tuo framework.

ISO 27001, NIS2, EU AI Act o un modello interno di gestione del rischio, anche combinati. Ogni evidenza viene legata al controllo e al periodo a cui si riferisce nel momento in cui viene prodotta, con traccia di chi la carica e di chi la approva, e gli audit ricorrenti si pianificano. Una distinzione da tenere presente: costruiamo strumenti di compliance, non siamo noi a essere certificati.

Probabilmente sì: i case study coprono di proposito settori e problemi molto diversi, per mostrare quanto sappiamo adattarci.

Abbiamo pubblicato progetti di audit con agenti AI, formazione e compliance aziendale, sanità digitale, assistenza sul campo, officine meccaniche, dati per prediction market, supply chain ESG, telesoccorso e pianificazione del lavoro. Per alcuni ambiti, come i sistemi di allarme, il risk management e le officine, trovi anche pagine dedicate.

Sì, ed è proprio il motivo per cui si sceglie il su misura.

Dentro lo stesso settore i flussi cambiano: un gommista gestisce depositi stagionali di pneumatici, un'officina di biciclette componenti e cicli di manutenzione. Un software su misura segue queste differenze invece di appiattirle.

Sì, anche quando ci sono regole fiscali o modelli di accesso particolari.

In una piattaforma di sanità digitale il backend riconosce il regime fiscale di ogni professionista ed è integrato con Stripe e Fatture in Cloud. In una piattaforma ESG i clienti scelgono e cambiano piano in autonomia, pagando con carta o addebito bancario. In un contesto Web3 l'accesso in abbonamento passa da Sign-In with Ethereum e NFT a tempo.

Sì, integrate nella piattaforma e senza strumenti esterni.

Per una piattaforma di sanità digitale abbiamo realizzato videochiamata con chat in tempo reale, email transazionali e promemoria a fine consulto, insieme a un'app React Native con cui i professionisti ricevono avvisi, accettano visite e gestiscono fatture e compensi.

La competenza di dominio resta tua o di un tuo consulente; renderla automatica, ripetibile e verificabile è compito nostro.

Nella piattaforma ESG, per esempio, le procedure di calcolo delle emissioni secondo GHG Protocol e ISO 14064 le ha fornite un partner esperto del settore: noi le abbiamo trasformate in software, tracciando per ogni dato il momento, l'unità di origine e lo stato di validazione. È lo stesso principio con cui lavoriamo sull'AI Act accanto ai legali.