Trust Center
le risposte prima delle domande

Del cliente, al 100%. È una politica no vendor lock-in applicata sempre: tecnologie standard e documentate, consegna degli accessi, della documentazione API in Swagger/OAS e del repository. Tutto viene definito dalle milestone, ogni milestone di pagamento corrisponde a una parte di progetto.

No. Si scelgono servizi Cloud Enterprise che garantiscono contrattualmente il contrario, in conformità a GDPR e SOC 2. Quando i dati sono particolarmente sensibili o il settore lo impone, si valuta un'infrastruttura AI privata, europea, nazionale, anche on-premise, così che nulla esca dal perimetro del cliente.

Dove serve che risiedano. Non siamo legati a un solo cloud: lavoriamo abitualmente con OVH, AWS, Hetzner, DigitalOcean, Seeweb, Aruba e Azure, e altrettanto spesso su infrastruttura del cliente, con Kubernetes, container o macchine Linux (Debian e Ubuntu). La scelta viene fatta all'inizio in base ai vostri vincoli normativi, contrattuali e di budget, non alla nostra comodità: se il requisito è che i dati restino su vostri server, si progetta per quello.

Si sceglie in base al contesto: autenticazione con credenziali, Single Sign-On con l'identity provider aziendale, autenticazione a più fattori (MFA) e codici OTP monouso inviati sull'email aziendale. Sulle web app Enterprise i token di sessione stanno in cookie HttpOnly e non in localStorage, così un attacco XSS non riesce a leggerli.

Il modello è che gli account li crea il committente. Non ci creiamo utenze autonome sui vostri ambienti: chiediamo di essere autorizzati sugli account che già esistono, oppure ci facciamo aggiungere al vostro team di lavoro con utenze nominali. La conseguenza è quella che conta per voi: potete rivedere o revocare i nostri accessi in qualsiasi momento, senza passare da noi e senza che il sistema smetta di funzionare. Vale per l'infrastruttura, per i backup e per le pipeline di DevOps.

Un LLM non viene mai collegato direttamente a un database. Si costruiscono sistemi agentici con guardrail e validazione rigida degli schemi dati, e per le operazioni in scrittura o ad alto rischio si adottano flussi human-in-the-loop (HITL), dove un essere umano approva prima che l'azione abbia effetto. L'automazione arriva fin dove il costo di un errore resta accettabile.

Con strumenti di AI observability: per ogni operazione di un agente resta una traccia immutabile del contesto analizzato, dei dati estratti, dei passaggi logici seguiti e del costo in token. Serve a ricostruire cosa è successo mesi dopo, che è poi la richiesta di qualsiasi audit.

Il codice è già vostro e già consegnato, non c'è niente da recuperare. Gira su tecnologie diffuse che un altro team può riprendere, i dati stanno in database standard esportabili senza passare da noi e la logica di business non è legata a un singolo fornitore di modelli. La continuità è una conseguenza dell'architettura, non una promessa contrattuale.

Backup, RTO e RPO non hanno un valore standard: si dimensionano sul danno che un fermo produrrebbe nel vostro caso, e si concordano prima di andare in produzione. Insieme al backup consegniamo le procedure di ripristino documentate e i metodi per ottenere copie dei backup e portarle sui vostri server o sulle vostre macchine. Un backup che solo il fornitore sa ripristinare non è un backup, è un altro punto di dipendenza.

Sì, ma non su ogni progetto: ha senso sulle iniziative di larga scala, dove l'investimento economico e l'impatto operativo rendono la continuità un rischio da presidiare formalmente. In quei casi termini, depositario e condizioni di rilascio si definiscono in sede contrattuale.

Va detto però che l'escrow serve soprattutto a chi non consegna il codice: noi ragioniamo nel modo opposto, il sorgente è vostro milestone dopo mielstone, quindi l'escrow copre un rischio residuo, non il rischio principale.

Sì. Volcanic Minds ha una polizza di responsabilità civile professionale e una copertura cyber, che interviene sui danni e sugli attacchi informatici. È una domanda che arriva quasi sempre dall'ufficio acquisti o dal legale: gli estremi delle polizze si forniscono su richiesta in fase contrattuale.

Il rilascio è l'inizio, non la consegna finale. Se da voi richiesto, si lavora con contratti di manutenzione correttiva ed evolutiva con SLA espliciti, e con una distinzione netta fra bug (in garanzia) e nuove funzionalità. Sono previsti formazione e passaggio di consegne al team del cliente.

Va detto, che ogni progetto a corpo ha già una sua garanzia inclusa di un mese post rilascio per bugfix bloccanti e attività minori e che il passaggio di consegna e le varie cerimonie sono già incluse ed esplicitate nel contratto.

Con un processo di Change Request trasparente: si valuta insieme l'impatto su tempi e costi e si decide se integrare subito, ripianificare o rimandare. Nulla viene implementato senza approvazione del cliente, e nulla viene fatturato a sorpresa.

Se i requisiti restano nel perimetro anche il costo non varia, se invece ha impatto sulel tempistiche e ne modifica il budget necessario ve lo diciamo subito così che ne possiamo discutere. Vinciamo insieme se condividiamo gli obiettivi, i rischi e i problemi di progetto.

Sì, progettiamo secondo le WCAG 2.2 livello AA: contrasto adeguato, navigazione completa da tastiera, ruoli e stati esposti alle tecnologie assistive. L'accessibilità entra nei requisiti all'inizio, perché aggiungerla a fine progetto costa molto di più e rende meno.

Dove necessario possiamo inalzare il livello allo standard WCAG 2.2 AAA.

La suddivisione dei pagamenti è flessibile e viene calibrata sulla base della complessità del progetto e della chiarezza dei requisiti.

Generalmente, per un progetto standard, con una durata media di circa 4 mesi, applichiamo una struttura a milestone simile:

• Acconto: Richiediamo una quota iniziale che va dal 25% (per i clienti storici con cui collaboriamo da anni) fino al 35% (per progetti particolari, ad alta complessità o con requisiti fortemente evolutivi).
• Milestone intermedie: I pagamenti successivi vengono distribuiti in base alle fasi di avanzamento del progetto. Inseriamo sempre una milestone chiave alla fine dello sviluppo, subito prima dell'inizio della fase di QA (Quality Assurance) e dei test.
• Saldo: Corrisposto alla chiusura del progetto e al rilascio finale.

Richiediamo la vostra presenza durante l'intero progetto, con appuntamenti cadenzati (indicativamente una volta a settimana) dove viene discusso il progetto, il SAL e vengono evidenziati criticità o esigenze da parte di entrambe le parti.

Poi c'è una fase pre rilascio di QA che coinvolgerà attivamente entrambe le parti per le verifiche e segnalazioni, questa fase è davvero importante e va fatta insieme.

Questo serve a mitigare la sorpresa del rilascio, durante la quale avviene un giro esaustivo su tutto il sistema. Finita la cerimonia, non inviamo subito la fattura di chiusura ma lasciamo qualche giorno per farvi fare tutte le considerazioni a porte chiuse e dopodiché emettiamo la fattura di fine lavori.

Nel mese che segue, è inclusa la nostra presenza per correzioni di problemi bloccanti e attività minori.

Certo, possiamo accontentare entrambe le richieste.

Siamo disponibili e felici di mostrarvi un contratto di esempio per farvi toccare con mano la nostra trasparenza e l'attenzione ai dettagli. Il testo è flessibile e siamo aperti a modifiche giustificate dalle specificità del progetto.

Per quanto riguarda la tutela delle informazioni (NDA), disponiamo di un nostro modello completamente bilaterale e bilanciato. Siamo comunque aperti a valutare e firmare il documento proposto dal vostro team legale, a patto che rispetti i principi di equità, trasparenza e non crei asimmetrie tra le parti.

Trattandosi di materiale legale e riservato, condividiamo questi documenti subito dopo una prima call conoscitiva.