Tutti gli articoli

    Nota di architettura

    3 maggio 2026di Gustavo Teixeira Cuco4 min di lettura

    Profili di Compliance

    Contesto architetturale

    Metodo riutilizzabile

    Fiducia e conformità

    Applicato a

    Agents & SkillsQ-LIRILusiberiaStaysTHE iCON
    Profili di Compliance
    Vedi su LinkedIn

    Costruisco i miei prodotti con strumenti di IA — Claude Code, Lovable, GitHub. La leva è reale. Il raggio d'impatto, di cui si parla meno.

    Continuavo ad aggiungere la compliance alla fine di ogni progetto. Informativa sulla privacy? Aggiungerla prima del lancio. Registro di audit? Decidere chi ne è responsabile dopo il primo incidente. Classificazione dei dati? Risolverla quando un partner la richiede.

    È lo schema che segue la maggior parte dei team. Ed è anche per questo che gli audit fanno male.

    Ho aggiunto un nuovo livello al template di governance che uso in questi prodotti. Affronta la parte che nessuno vuole progettare in anticipo: la compliance.

    Il primo istinto è stato incorporare ogni framework nel template base. ISO 27001, GDPR, EU AI Act, IATI, HIPAA, ISO 13485. Renderlo esaustivo.

    Sbagliato. Una landing page non ha bisogno di ISO 27001. Un blog non ha bisogno di ISO 42001. Un pitch deck non ha bisogno di IATI XML. La maggior parte dei miei prodotti non ne ha bisogno di nessuno. I pochi che ne hanno bisogno richiedono combinazioni diverse.

    Quello che ho aggiunto al suo posto sono i profili. Il template base resta piccolo. Un flag nelle ground rules attiva gli obblighi.

    compliance_profiles: security, ai-governance

    Ogni profilo punta a una directory di obblighi e ai controlli che li soddisfano. Quattro livelli.

    Livello 1 — Universale. Sempre attivo. Formati dei dati (ISO 8601, 4217, 639-1, 3166), accessibilità (WCAG 2.2 AA), modello di qualità del software (ISO/IEC 25010). Ciò che ogni prodotto eredita senza doverci pensare.

    Livello 2 — Governance dell'IA. Attivo quando il prodotto usa l'IA. EU AI Act (in vigore da agosto 2024, applicazione graduale fino al 2027), ISO/IEC 42001:2023 (lo standard di sistema di gestione dell'IA pubblicato a dicembre 2023), NIST AI RMF + GenAI Profile. Una checklist di classificazione del rischio viene eseguita prima del lancio di qualsiasi prodotto di IA — proibito / alto rischio / limitato / minimo.

    Livello 3 — Sicurezza e Privacy. Attivo quando il workload è regolamentato, B2B enterprise, o rivolto al settore pubblico. ISO 27001, SOC 2, GDPR, ISO 27701. Con una distinzione chiara tra allineato (controlli implementati), pronto per la certificazione (gap assessment + audit trail), e certificato (l'organizzazione detiene il certificato).

    Livello 4 — Dominio. Sanità (ISO 13485, IEC 62304, MDR, EHDS). Finanza (ISO 20022, PCI DSS, PSD2). Clima (IATI, GHG Protocol, TCFD). Pubblica amministrazione (eIDAS, NIS2). Attivare solo quello pertinente.

    Quello che questo mi ha chiarito: ISO 27001 non è una funzionalità software. È un sistema di gestione. Dei suoi 93 controlli, forse un terzo può davvero vivere nel codice. Il resto sono politiche, formazione, gestione dei fornitori, audit interno — lavoro che fa l'organizzazione, non la piattaforma.

    Il PaaS usato dalla maggior parte di chi costruisce con strumenti di IA probabilmente ha già un SOC 2 Type II che copre ~40 di quei controlli. Il lavoro che mi resta da fare sono gli altri 30 — e anche lì, la maggior parte consiste nell'identificare quali controlli si applicano, non nell'inventarli. L'IA fa l'implementazione. Io faccio la disciplina.

    Continuo a reimparare la stessa lezione con questo template. Il generico non sopravvive al contatto con lo specifico. L'esaustivo non sopravvive al contatto con i workload reali. Quello che sopravvive è piccolo + attivabile.

    Compliance come configurazione, non come fork.

    La parte onesta: questo non rende compliant nessun prodotto. Rende visibile il lavoro di compliance. Che i controlli vengano davvero implementati, che le policy vengano scritte, che le persone vengano formate — resta comunque il lavoro da fare. Il template garantisce solo che nessuno dimentichi quale lavoro si applica, e a quale prodotto.

    L'audit-readiness è architettura. L'architettura è il template di governance, non il codebase. Costruita a livello di template, la disciplina si propaga. Aggiunta alla fine di ogni prodotto, ogni trimestre diventa un'esercitazione antincendio.

    Qual è oggi la vostra postura di compliance predefinita — ed è quella di cui il vostro prossimo workload regolamentato avrà davvero bisogno?

    Il template è open source — link nei commenti.

    Fonti