L'architettura di Sophron

Premessa: Sophron è uno scaffold, non un'AI

Il primo malinteso da chiarire è di vocabolario. Quando si dice «Sophron», si intende un sistema che fa cose — analizza richieste, esegue change request, vigila log, risponde in italiano a domande di business. Ognuna di queste cose, presa da sola, oggi è alla portata di qualunque sistema basato su un modello di linguaggio moderno con accesso ai dati aziendali. Non è dal cosa che Sophron prende il suo significato.

Sophron è il perché e il come di quelle cose: il modello dati condiviso che descrive la conoscenza aziendale, il meccanismo di routing che decide quale conoscenza serve a un certo task, le regole operative che il router applica a ogni risposta, e la disciplina di lavoro condivisa che il team accetta per produrre informazione in modo riusabile dagli altri membri. Sopra a tutto questo scaffold gira un modello LLM, che lo scaffold usa come substrate cognitivo. L'LLM è il motore. Lo scaffold è quello che lo rende utile a un'azienda invece che a un singolo utente.

Una precisazione, prima di proseguire: lo scaffold in sé è agnostico rispetto al modello. In linea di principio Sophron può funzionare con qualunque LLM moderno dotato di capacità di tool use, accesso al filesystem e ampiezza del contesto sufficiente. La scelta concreta è arrivata dopo una valutazione sul tipo d'uso (interazione da CLI, esecuzione di tool, dialoghi lunghi che richiedono finestre di contesto ampie) e sulle performance osservate sul campo nei mesi successivi. Oggi in Sophron usiamo principalmente Claude Code (di Anthropic) come ambiente di esecuzione, con la famiglia di modelli Claude 4.x come motore cognitivo — in particolare Opus 4.7, Sonnet 4.6 e Haiku 4.5, scelti caso per caso a seconda del task. Il discorso che segue descrive lo scaffold; il fatto che oggi sotto giri Claude è una conseguenza della valutazione, non una premessa di architettura.

Le parti principali dello scaffold sono quattro: i 4 assi di classificazione della conoscenza, il router cognitivo, le 16 discipline R-* che il router applica, e l'architettura multi-dominio che permette al sistema di operare contemporaneamente su contesti diversi. Le descriviamo nell'ordine.

I quattro assi: il modello dati della conoscenza

Ogni artefatto di conoscenza dentro Sophron — un concept, una skill, una convenzione, una procedura, un manifesto di dominio, una riga di documentazione — è classificato su quattro assi ortogonali. Sono il minimo set di dimensioni con cui si può descrivere un pezzo di conoscenza aziendale in modo che un router sappia se è rilevante per un task. Toglierne uno significa perdere capacità di filtrare; aggiungerne un quinto risulta ridondante.

Domain — di che cosa parliamo

Il primo asse risponde alla domanda «questa conoscenza vive dentro quale perimetro funzionale?». I valori sono i domini istanziati nel sistema: crm, sap-integration, pbi-analytics, documental, it-infra, eam, hub, mmc-intranet, solarlog, unafinestrasuivalori, sql-platform, utility-services, più il meta-dominio cross-domain.

Il Domain non è un'etichetta cosmetica: è un confine reale di esistenza dell'informazione. Un ticket aperto dal cliente nel CRM, per esempio, vive solo dentro il database del CRM e non viene mai replicato in SAP. Se il router non sa che un ticket è dominio crm, può andare a cercare informazioni in SAP che non sono lì.

Layer — il tipo di conoscenza

Il secondo asse risponde alla domanda «di che natura è questa conoscenza?». I valori sono: concepts (le regole astratte), databases (le strutture dati), applications (i programmi vivi), infrastructure (i server e la rete), conventions (i pattern di lavoro), skills (le procedure operative riusabili), channels (i canali di comunicazione), users (i profili e i ruoli).

Lo stesso oggetto reale può essere descritto su layer diversi: il ticket dell'esempio è un concept (cos'è un ticket, qual è il suo ciclo di vita, chi può cambiarne lo stato), è un database (in quali tabelle è scritto), è un'application (quale interfaccia del CRM lo manipola). Il Layer dice di quale aspetto stiamo parlando.

Env — l'ambiente di applicabilità

Il terzo asse risponde alla domanda «questa informazione vale in che ambiente?». I valori sono base, dev, tst, prd. L'Env è rilevante in particolare per i layer databases e applications: una procedura testata in tst non è la stessa procedura in prd, e dare una raccomandazione su tst applicata a prd è il modo più rapido per produrre un incidente.

L'Env è la dimensione che pesa la gravità di una risposta, non solo la sua correttezza. Sophron deve sapere a quale ambiente si riferisce prima di proporre un'azione.

Status — l'asse composito dell'affidabilità

Il quarto asse non è una scalare singola: è composito di tre sotto-dimensioni che insieme descrivono quanto ti puoi fidare di un pezzo di conoscenza in un certo momento.

• Freshness — quanto è recente l'ultima verifica della conoscenza. Una freshness vecchia non significa errata, ma significa da riverificare.
• Authority — da quale fonte arriva la conoscenza, e quale priorità ha rispetto ad altre. L'ordine canonico è: code > observed > docs > teams > inferred. Il codice attivo vince sulla documentazione; la documentazione vince su una chat di team; una chat vince su un'inferenza.
• Lifecycle status — in che fase del ciclo di vita si trova: draft, active, deprecated, archived.

Status è il garante dell'affidabilità: il pezzo che dice se ti puoi fidare adesso o se devi prima riverificare.

Combinazione e proiezione

Insieme, i quattro assi definiscono un punto in uno spazio di classificazione che il router può interrogare con query sintetiche del tipo «caricami tutti i concepts di dominio crm, in env=prd, con status=active e freshness non oltre sei mesi». Il vantaggio operativo è che il router non porta in contesto al modello LLM tutta la knowledge base — porta solo la proiezione rilevante per il task. È quello che separa Sophron da un sistema che fa load-all.

Il router cognitivo

Il router cognitivo è il componente che, a ogni messaggio in ingresso, esegue una sequenza fissa di passi e decide cosa fornire al modello LLM come contesto. La sequenza è deterministica: niente euristica nascosta, niente «load-all» di sicurezza. È documentata in .ai-docs/cross-domain/skills/sophron-router.md.

I passi, semplificati, sono i seguenti:

1. Identifica utente — chi sta chiedendo, a quale ruolo appartiene, con quali skill ortogonali è abilitato.
2. Focus + briefing + inbox check — su quale progetto sta lavorando, c'è una nota di apertura giornata, ci sono messaggi inter-utente da consegnare prima di rispondere.
3. Classifica dominio — derivato da CWD, path nel prompt, project context, o domanda esplicita all'utente.
4. Classifica env — l'ambiente di applicabilità della risposta.
5. Classifica intent — analisi, modifica, esecuzione, lettura, ecc.
6. Carica solo i layer rilevanti — proietta la knowledge base sui 4 assi filtrati per quel task.
7. Applica le 16 discipline R-* — controllo ad ogni risposta, prima della consegna.
8. Risponde, aggiorna lo state — la risposta entra nel solco di conoscenza del sistema, pesata dal ruolo dell'utente.

Quello che il router non fa è altrettanto importante: non improvvisa, non sceglie silenziosamente quando è ambiguo, non carica «al ribasso» quando è incerto. La sua disciplina di base è: se non sai, fermati e chiedi.

Le sedici discipline R-*

Le R-* sono le regole concrete che il router applica a ogni risposta. Sedici regole può sembrare un numero alto; raggruppate per famiglia operativa, diventano sei principi di buonsenso, ciascuno con il suo scopo. La documentazione canonica è in .ai-docs/cross-domain/skills/sophron-discipline.md; qui le presentiamo per gruppi.

4.1 Posizionamento — dove sta una conoscenza

R-DOMAIN impone che ogni task sia associato a uno o più domini dichiarati esplicitamente. Sorgenti in priorità decrescente: CWD dentro un repo Gitea noto, path citati nel prompt, prompt esplicito, project context. Default se ambiguo: chiedi all'utente, mai defaultare silenziosamente.

R-ENV-1 impone che ogni risposta tecnica dichiari l'env di applicabilità (dev/tst/prd/base), anche quando implicito. R-ENV-2 richiede menzione esplicita quando un'informazione vive solo in alcuni env: evita la deriva fra ambienti, in cui una raccomandazione su tst finisce applicata in prd per disattenzione.

R-LAYER impone che non si mescolino layer (DB/BE/FE) senza separarli esplicitamente. Una risposta che tocca più layer deve etichettarli e mantenerli distinti.

4.2 Affidabilità — quanto si può credere

R-AUTH stabilisce l'ordine di autorità in caso di conflitto fra fonti: code > observed > docs > teams > inferred. Se la documentazione dice una cosa e il codice ne dice un'altra, il codice vince — e Sophron dichiara il conflitto.

R-FRESH impone una soglia di freschezza: informazioni più vecchie di sei mesi senza re-verifica vengono marcate come forse stale, e Sophron lo dichiara prima di restituire la risposta.

4.3 Comportamento per utente — chi sta chiedendo

R-ROLE impone che la risposta sia filtrata dal ruolo dell'utente: verbosity, permessi, tono. Un sysadmin riceve dettaglio tecnico; un key user di vendita riceve concetti di business; un visitatore riceve formulazioni introduttive.

R-SKILL aggiunge un livello di sicurezza operativa: certe azioni — rebuild della knowledge, modifica di concept, scrittura su ERP — sono gated da skill specifiche dichiarate in users.json. Se l'utente non possiede la skill richiesta, l'azione viene bloccata hard, senza override silenzioso.

4.4 Rischio cross-domain — quando una richiesta tocca più aree

R-CROSS-SAFETY richiede che prima di modificare una risorsa condivisa si verifichi l'impatto su tutti i domini che la usano. Un cambio nelle conventions cross-domain, per esempio, non si esegue senza prima aver controllato cosa cambia per ciascun dominio.

R-CROSS-ROUTE richiede che se l'intento dichiarato appartiene a un dominio diverso da quello attivo, il router reindirizzi esplicitamente, dichiarando il salto.

R-CROSS-SKILL permette di caricare skill autorevole di un altro dominio quando la conoscenza serve, ma sempre dichiarandolo: niente import silenzioso.

4.5 Igiene di sistema — i segreti

R-SECRETS impone che tutte le credenziali del sistema vivano in un solo file centrale (.sophron-secrets.json, gitignored). Nessun file di auth sparso, nessuna credenziale hard-coded altrove. È una regola apparentemente banale, ma è quella che permette al sistema di non avere fughe di segreti per accumulazione.

4.6 Coordinamento di team — Sophron come piattaforma multi-utente

Le ultime quattro discipline sono quelle che trasformano Sophron da assistente individuale a piattaforma di team. Sono attivate al primo prompt del giorno di ciascun utente, oppure ad ogni messaggio.

R-MORNING impone un briefing automatico al primo prompt della giornata (o dopo un gap superiore a otto ore): cosa è successo nel team, su quali progetti, quali decisioni.

R-INBOX impone che i messaggi inter-utente vengano consegnati prima di processare la richiesta dell'utente: niente messaggi persi, niente attese.

R-FOCUS tiene un auto-tracking silenzioso del progetto su cui l'utente sta lavorando, in modo che il contesto delle risposte successive sia coerente.

R-TASK-INGEST disambigua l'intent di un task richiesto con frasi naturali («segnati questa cosa», «ricordami X», «fatto Y»): personale o di progetto? Mai silent default — chiede.

Tabella sommaria delle sedici

Quello che le tiene insieme non è il numero ma il principio: il router non improvvisa mai. Ogni decisione — quale knowledge caricare, come parlare all'utente, se eseguire o bloccare un'azione — passa attraverso una di queste regole. Sedici occasioni di farsi fermare prima di rispondere.

Multi-dominio: cinque tipi, dodici istanze

Sophron è progettato fin dall'inizio per essere multi-dominio. I domini istanziati oggi sono dodici, raggruppati in cinque tipi di dominio, ciascuno con il suo ciclo di vita e la sua sorgente di authority.

La distinzione fra tipi è importante perché definisce dove vive la verità di un dato: in un dominio development la verità è nel codice del repository; in un dominio infrastructure la verità è nello stato osservato del sistema; in un dominio data-only è nel dataset vivo. Sophron sa interrogare la fonte giusta per il tipo giusto.

Vale la pena notare che la struttura multi-dominio non è stata un disegno esplicito fin dall'inizio. Sophron 1.0 era mono-dominio (solo CRM). L'architettura multi-dominio descritta sopra è frutto di una riprogettazione mirata che ha definito la versione 2.0. Si vede dai nomi: il software si chiama Sophron 2.0 perché c'è stato un Sophron 1.0 prima.

Sophron 2.0 (client) e Sophron 3.0 (client-server)

Lo stato attuale dello scaffold è Sophron 2.0: architettura puramente client. Ogni utente del team esegue il proprio Sophron sul proprio client (un agente AI con accesso ai sistemi via MCP), e ogni programma di Sophron — il rebuilder, le sentinelle, i discovery — viene triggerato a mano dal client. Non c'è un demone server-side che gira in background.

Questo è un vincolo architetturale, non un limite di implementazione. È stato scelto per ragioni operative — semplicità di deploy, controllo dell'esposizione, allineamento con il modo in cui oggi vengono distribuiti gli agenti AI. Funziona, ma impone tre limiti chiari:

• Niente vigilanza continua: la sentinella va lanciata, non gira in background.
• Niente vero multi-utente sincrono: ogni client lavora su uno snapshot della knowledge base, e l'integrazione fra clienti passa attraverso commit Git.
• Niente trigger event-driven: il sistema reagisce quando l'utente fa una richiesta, non quando un evento esterno (un CVE, un ordine inevaso, una scadenza certificati) lo richiederebbe.

L'evoluzione prevista è Sophron 3.0, oggi in fase di progettazione (workstream E, paused in attesa di chiusura della 2.0). 3.0 introduce un'architettura client-server: un server sempre attivo, schedulazione dei programmi (le sentinelle girano ogni notte, il rebuild ogni mattina, il db-distributed agent in continuo), trigger event-driven (un push su Gitea attiva la Skill Sentinel sui file toccati), multi-utente sincrono reale (asincronicità senza conflitti), e orchestrazione multi-LLM (più modelli che lavorano in parallelo su task diversi).

Per il lettore tecnico vale la pena chiarire: 3.0 non è una promessa di marketing, è un design dichiarato nel documento 008-sophron-server-build-brainstorming.html dentro il workstream E. Quello che lì è ancora ipotesi (es. quale tecnologia di scheduling, quale broker per gli eventi) è scritto come ipotesi; quello che è invece architettura decisa (la separazione client/server, lo schema di sincronizzazione, il modello multi-LLM) è dichiarato.

I programmi che fanno funzionare lo scaffold

Lo scaffold non è solo teoria. Vive grazie a un insieme di programmi che operano nella cartella .devtools/ del repository, ciascuno con un compito preciso e una storia di sviluppo che spesso parte da una necessità contingente del team. Li raggruppiamo in tre famiglie, raccontandole nell'ordine in cui sono nate.

7.1 Discovery — i programmi che leggono il mondo

Il primo gruppo è quello dei programmi di discovery. Il loro compito è leggere le fonti reali del business per conto del sistema, e tradurle nella rappresentazione classificata che la knowledge base di Sophron sa interrogare. Sono gli «esploratori autonomi» che alimentano il modello del mondo su cui poi lavora il router.

I due programmi più importanti del gruppo sono due indexer paralleli, uno per il codice e uno per i database. Sono volutamente separati (decisione architetturale interna D009: responsabilità distinte, nessun wrapper comune), perché parlare al codice e parlare a un database sono problemi tecnici diversi e mescolarli produce strumenti fragili. Insieme, però, costruiscono il quadro completo che permette al sistema di rispondere ad analisi cross-modulo.

Il repo-indexer è l'indexer del codice. Si occupa dei repository Gitea — applicazioni, servizi, frontend — ed è un parser multi-linguaggio: PHP CodeIgniter 4 per le applicazioni storiche, TypeScript con Node per i servizi nuovi, Vue per i frontend recenti, con estensioni in corso a C#/.NET e Python. Attraversa il codice ed estrae gli indici semantici: classi, endpoint HTTP, chiamate a stored procedure, dipendenze fra componenti. Sul versante delle SP la sua mappa è lato codice: dice quale endpoint invoca quale procedura, non cosa quella procedura faccia all'interno del database — quello è il compito del secondo indexer. Ha un sotto-tool, enumerate-subprojects, che lavora a un livello di astrazione superiore: quando un repository contiene più sotto-progetti — cosa frequente nei monorepo aziendali — li riconosce e li mappa singolarmente.

Speculare a repo-indexer, sul fronte dei database, c'è il rebuild. Mentre repo-indexer legge il codice, rebuild legge i database vivi: si connette a MSSQL e MySQL (è multi-engine) e ne estrae l'inventario strutturale completo — tabelle, colonne, foreign key, stored procedure con il loro corpo, viste, indici. Su questa estrazione costruisce la knowledge base .ai-docs/ di Sophron: file di descrizione per ciascun oggetto del DB, mappe di foreign key, mappe di SP usage (chi chiama chi, lato DB). Quando un oggetto del DB non ha commento, un layer LLM (Haiku per il triage, Opus per i casi difficili) genera una descrizione propose-only a partire dal corpo della SP o dal nome della tabella. È un programma pesante, che ricostruisce in pochi minuti la rappresentazione completa di sei DB di produzione; la sua esecuzione è gated dalla skill Rebuilder — R-SKILL hard, perché un rebuild fuori controllo può sovrascrivere descrizioni scritte a mano nei concept.

Quando un'analisi cross-modulo chiede al sistema «se modifico questo endpoint, quali stored procedure chiamerà, e su quali tabelle quelle SP agiscono», la risposta nasce dalla composizione delle due mappe: repo-indexer fornisce il primo salto (endpoint → SP), rebuild fornisce il secondo (SP → tabelle, via SP usage e FK). Nessuno dei due, da solo, può rispondere.

Il document-classifier lavora su un dominio molto diverso: la manualistica. Schüco ha accumulato negli anni terabyte di documenti tecnici — manuali, istruzioni utente, materiale formativo — e il problema lì non è leggere, è capire cosa è ancora valido. Document-classifier usa un sistema a due velocità: il triage rapido con un modello veloce (Claude Haiku) per la maggioranza dei documenti, l'analisi più profonda con il modello migliore (Claude Opus) solo per i casi che il triage segna a bassa confidenza. Tutto in pattern propose-only — propone le etichette di lifecycle e di topic, non le applica senza conferma umana. È stato uno dei primi programmi a essere costruito con la coscienza che la quantità di documenti era ingestibile per un essere umano in tempi ragionevoli, ma che un'AI senza un protocollo di triage avrebbe consumato risorse inutilmente.

Il sap-reader è probabilmente quello dal valore più immediatamente percepibile in un'azienda che usa SAP. Si occupa di leggere SAP via RFC, attraverso i moduli funzione standard (le BAPI). L'MVP è stato chiuso il 24 aprile 2026, e produce in autonomia documentazione strutturata su un perimetro SAP — è il responsabile dell'HTML di Y_PROFILE che il reportage «L'AI è il motore, non il cuore» descrive nella scena d'apertura. Le fasi successive (F2 e F3) ne estenderanno la copertura ad altre aree del sistema gestionale.

Accanto a questi tre tool principali ci sono altri due, più orientati al governo del sistema che alla produzione di conoscenza. Il teams-channels-bridge mantiene allineata in modo automatico la mappa fra i canali di Microsoft Teams su cui il team discute e i domini Sophron a cui i discorsi si riferiscono — un edit surgical che preserva i commenti e che evita la deriva fra come parliamo in chat e come è strutturata la nostra knowledge base. Il domain-init è invece il programma di bootstrap: quando il team decide di aggiungere un nuovo dominio al sistema — è successo, per esempio, con documental e it-infra — domain-init costruisce la struttura iniziale del dominio in modo guidato, posa le convenzioni, e si occupa del primo manifesto.

Chiudono il gruppo i due server MCP — mcp/mssql-mcp-python e mcp/teams-mcp-python. Sono l'interfaccia che il modello LLM usa per accedere live alle fonti: il primo dà accesso a sei database MSSQL (CRM, MMC Intranet, PBI Analytics, SAP, SQL Server, Utility); il secondo ai canali Teams whitelisted nella configurazione. Sono volutamente read-only di default, una scelta esplicita che si lega alla disciplina R-CROSS-SAFETY discussa al §4.

7.2 Sentinella — i programmi che vigilano

Il secondo gruppo è quello delle sentinelle. Mentre i programmi di discovery costruiscono la rappresentazione del mondo, le sentinelle vigilano sullo stato di qualcosa di già costruito — che sia la knowledge base stessa, l'integrità dei sistemi, o l'uso dei dati. Tutte in pattern propose-only: generano patch in formato diff, non le applicano direttamente.

La privacy-sentinel è stata la prima del gruppo a essere costruita. Vive come sotto-tool del rebuilder, in .devtools/rebuild/src/privacy_sentinel.py. Il suo compito è l'audit GDPR degli accessi AI ai database: controlla le query che le sessioni AI hanno fatto sui DB e segnala potenziali violazioni — query su campi sensibili senza autorizzazione, pattern di estrazione massiva, accessi a dati personali senza giustificazione. Non blocca, segnala. È stata la più semplice da implementare perché ha confini netti e un riferimento normativo chiaro.

La Skill Sentinel è la grande dichiarazione architetturale di Sophron 2.0, costruita in dieci sotto-task (D9.1–D9.10). Il suo compito è custodire la qualità della knowledge base — verificare la consistenza fra le skill, controllare che ogni cosa sia posizionata nel posto giusto secondo le convenzioni dichiarate, riconoscere quando un'analisi è abbastanza matura da meritare di diventare skill riusabile, e fermare la deriva di formato. Quattro funzioni distinte — Consistency, Placement, Extraction, Format — operate su cinque famiglie di file. Anche qui pattern propose-only: genera la patch in formato diff, non la applica mai.

Il db-distributed-agent è il fratello della Skill Sentinel con scope disgiunto: custodisce la parità strutturale dei DB con topologia distributed — oggi utility e sql_server, due basi dati che per scelta architetturale devono restare strutturalmente identiche fra ambienti. Pipeline a quattro stadi: inventory (cosa c'è dove), diff (cosa è cambiato), classify (la gravità della deriva — blocker, schema-drift, code-drift, cosmetic), report (cosa farne). Otto sotto-task pianificati, non ancora implementato.

7.3 Quality Gate e infrastruttura di base

Il terzo gruppo è più eterogeneo, ma utile da nominare perché mostra che Sophron non è solo «la AI che fa le cose»: ha intorno un'infrastruttura tecnica che lo abita, e che è essa stessa parte del valore.

Il Sophron Quality Gate è il programma di controllo sui pull request di Gitea Actions, parte del workstream C, owner James. Cataloga regole base R1–R13 — convenzioni sul naming delle stored procedure, divieto di SQL inline nei sorgenti, divieto di segreti hardcoded, autenticazione obbligatoria sui nuovi endpoint, coerenza fra project ID e dominio, rebase coherence, controllo migrazioni DB — e le applica sui PR. La modalità di rilascio è warning-only: non blocca il merge ma segnala, in modo da non interrompere il flusso del team durante il rollout; una label di override consente all'IT di forzare il merge in caso di emergenza, e gli override vengono loggati per l'audit successivo. Sophron Quality Gate è, fra le altre cose, la prima cavia di sé stesso — le sue regole vengono testate per primi sui PR di Sophron.

Il presenter è uno strumento di Text-to-Speech cross-platform, basato su un browser Chromium controllato via Playwright, per la lettura ad alta voce di documenti HTML. Nato per ascoltare in macchina i reportage prima di committarli — un'abitudine pratica del team — è diventato un piccolo classico interno.

I diagrams sono il generatore di diagrammi via Graphviz, usato nei documenti di analisi per produrre le mappe di architettura senza dover passare da uno strumento esterno.

Infine il common è l'helper centrale, e — a guardarlo bene — è uno dei tool più importanti dell'intero stack, anche se non «fa» niente di visibile. Contiene il secrets-reader unico (il riferimento operativo di R-SECRETS), gli helper LLM condivisi, le utility shell. È l'infrastruttura di base che tutti i tool sopra riusano per non duplicare codice e per garantire che la disciplina dei segreti centralizzati sia rispettata in modo trasparente. Quando si dice che lo scaffold di Sophron è ben costruito, si dice in buona parte questo: che common esiste, e che gli altri programmi lo usano davvero.

Sicurezza: la condizione perché la delega all'AI sia possibile

Un capitolo che chiude i precedenti, e che dichiara una cosa che fino a qui è rimasta sotto traccia.

La sicurezza, in Sophron, non è una feature aggiunta sopra un sistema preesistente. Non è un firewall messo a valle, un audit log attivato in produzione, un controllo di accesso negoziato dopo l'incidente. È la condizione perché tutto il resto possa esistere: senza la sicurezza, l'AI non si delega nulla. E se non si delega, il moltiplicatore di cui parla il reportage «L'AI è il motore, non il cuore» non si attiva. Sophron senza sicurezza non è una versione meno protetta di Sophron — è un'altra cosa, che non riesce nemmeno a partire.

I pezzi di sicurezza sono distribuiti su tutto lo scaffold descritto nei capitoli precedenti. Vale la pena rivederli insieme, perché letti come catena hanno una logica che, presi separatamente, non si vede.

8.1 Il perimetro chiuso: whitelist sulla struttura del repository

Il primo strato di sicurezza è strutturale, non operativo. La root del repository ha una whitelist tassativa: si possono creare solo cartelle e file dichiarati esplicitamente. Lo stesso vale per .ai-docs/, la cartella della knowledge base, che ammette solo i domini dichiarati e i meta-percorsi previsti (.generated/, .docs/, .teams/). Nessuna superficie d'attacco accidentale per file di configurazione lasciati in posti imprevisti, nessuna deriva strutturale silenziosa nel tempo. Se serve una cartella nuova, va aggiunta esplicitamente alla whitelist con un commit dedicato — e la modifica della whitelist è essa stessa un atto controllato.

8.2 I segreti in un solo posto: R-SECRETS

Tutti i segreti — chiavi API, password, token, certificati — vivono in un solo file gitignored (.sophron-secrets.json) letto attraverso un solo modulo (common.secrets). Nessuna credenziale hard-coded altrove, nessun file di auth sparso fra i diversi tool. È una regola apparentemente burocratica ma che ha un effetto concreto: a sei mesi dalla messa in opera del sistema, l'inventario dei segreti è dove dovrebbe essere e nessun segreto è scappato in posti dove non doveva. La privacy-sentinel descritta al §7 lavora sopra a questa disciplina, controllando che gli accessi AI ai database rispettino i confini dichiarati dalle chiavi gestite centralmente.

8.3 Le azioni elevate gated da skill: R-SKILL

Certe azioni — un rebuild della knowledge base, la modifica di un concept, la scrittura su SAP — sono gated da skill specifiche dichiarate nel file users.json. Se l'utente che invoca l'azione non possiede la skill richiesta, l'azione viene bloccata hard, nel codice del tool stesso, prima ancora che il modello LLM possa accettare di eseguirla. Non c'è override silenzioso, non c'è bypass per emergenza implicito. Se serve davvero un'eccezione, va creata esplicitamente da chi ha il ruolo per farlo, e l'evento viene loggato. È la differenza fra un sistema in cui «in teoria nessuno tocca questa cosa» e un sistema in cui nel codice nessuno la tocca davvero.

8.4 La verifica prima della modifica: R-CROSS-SAFETY

Le risorse condivise — un concept usato da più domini, una skill che vive in cross-domain, una procedura toccata da più applicazioni — non si modificano senza prima aver verificato l'impatto su tutti i consumatori. La regola R-CROSS-SAFETY rende obbligatoria questa verifica: il router non lascia partire una modifica su risorsa condivisa senza che il modello LLM abbia esplicitato il perimetro di chi viene impattato. È quello che impedisce a Sophron di rompere il flusso di un dominio mentre risponde correttamente a una richiesta su un altro.

8.5 L'ordine di autorità: R-AUTH

Quando due fonti dicono cose diverse — il codice dice X, la documentazione dice Y, una chat di Teams dice Z, il modello dell'AI suggerisce W — Sophron sceglie deterministicamente, secondo l'ordine: code > observed > docs > teams > inferred. Il codice vivo vince sempre, perché è quello che effettivamente gira. È una regola di sicurezza nel senso pieno del termine: garantisce che la risposta del sistema non si basi mai su un'inferenza dell'AI quando esiste una fonte autorevole. Sopra a questa regola si appoggia la disciplina di freshness (R-FRESH): se l'autorità citata non è stata riverificata da troppo tempo, Sophron lo dichiara prima di restituire la risposta.

8.6 Le sentinelle sui sistemi reali

Sul perimetro più tradizionalmente percepito come «sicurezza» — l'infrastruttura IT — Sophron applica la disciplina della sentinella di sicurezza descritta nel reportage. È quella che fa la rassegna mattutina dei CVE pubblicati nel weekend, segnala accessi SSH inusuali a server in produzione, monitora le scadenze dei certificati TLS. Funziona oggi nel modo trigger-based imposto dall'architettura 2.0 (lanciata a mano dal client del responsabile infrastrutture, ogni giorno); diventerà event-driven in 3.0 — un CVE pubblicato attiverà automaticamente la rassegna, senza bisogno di un click.

8.7 Il principio sotto tutto: le regole come prezzo della delega

I sei strati sopra — whitelist strutturali, segreti centralizzati, gating delle azioni elevate, verifica cross-domain, ordine di autorità, sentinelle sui sistemi — possono sembrare, presi separatamente, ognuno una regola burocratica. Letti insieme, sono qualcos'altro.

Sophron permette al team di lasciare che l'AI faccia, in autonomia, lavoro che fino a ieri richiedeva sei persone di tre uffici diversi. Quella autonomia ha senso solo se chi delega può voltare le spalle al sistema sapendo che farà bene il suo lavoro. Senza i guardrail, nessuno si fida; senza fiducia, l'autonomia non si attiva; senza autonomia, il moltiplicatore non parte. Le regole non sono il prodotto. Sono il prezzo che si paga per poter usare il prodotto seriamente.

È il motivo per cui — in un'azienda che voglia usare un'AI come sostituto di lavoro umano vero, non come assistente di lusso — la sicurezza non si può aggiungere dopo. Va costruita prima dell'AI, sotto l'AI, sopra l'AI. Sophron è il tentativo di farlo in modo che sia trasparente all'utente: non si vede mentre funziona, si vedrebbe solo se mancasse.

Il provider esterno: fidarsi di un LLM che vede i nostri dati

Tutto quello che abbiamo descritto fino a qui — gli assi, il router, le discipline, i tool, le sentinelle — riguarda la sicurezza interna dello scaffold. Ma c'è una domanda che, in un'azienda seria, viene posta prima ancora: come ci si fida di far leggere a un LLM, ospitato fuori dal nostro perimetro, tutta la conoscenza aziendale? Codice, schemi DB, configurazioni, dati di processo, conversazioni di team. Un'AI utile, per essere utile, deve vedere. E vedere, per un servizio cloud, vuol dire che i dati transitano da un provider esterno.

Non è una domanda che si scaccia con due righe in un'appendice di compliance. Va affrontata, perché senza una risposta solida la delega di cui parla il §8 non parte. È una domanda che il team di Sophron si è posta esplicitamente, e a cui ha risposto con una valutazione formale — opzioni, costi reali di adozione, mitigazioni, direzione di lungo termine. Ne riassumiamo qui l'esito.

9.1 La valutazione e la scelta

Il team ha confrontato in modo strutturato diverse strade: l'abbonamento Anthropic ufficiale (Team Premium per il lavoro interattivo, API per i workflow programmatici), Claude erogato attraverso cloud intermedi con residenza dati EU (AWS Bedrock, GCP Vertex AI), e una famiglia di alternative europee non-Anthropic (Mistral, Aleph Alpha, Azure OpenAI, OVHcloud).

La scelta operativa è caduta su Anthropic Team Premium per il lavoro quotidiano nell'IDE, con l'API Anthropic tenuta come complemento previsto per quando Sophron servirà chiamate AI programmatiche. I cloud intermedi sono stati scartati per un costo operativo sproporzionato a un team della nostra dimensione, considerando che eroghino in fondo lo stesso Claude di Anthropic con le stesse clausole contrattuali. Le alternative europee non-Anthropic sono state scartate per un gap qualitativo ancora significativo sul nostro use case di agentic coding, e perché lo strumento che il team usa ogni giorno — Claude Code — è una CLI proprietaria inseparabile dal modello: cambiare modello vorrebbe dire perdere lo strumento.

Resta quindi il punto materiale: con Team Premium o API Anthropic, i dati passano per server statunitensi. Non si finge che non sia un tema. Si chiede invece — onestamente — che rischio è, esattamente, e come si tampona?

9.2 Come si mitiga il rischio «dati in USA»

Sul piano contrattuale, i Commercial Terms di Anthropic applicati ai piani for Work (Team Premium e API) escludono esplicitamente l'uso dei dati per il training dei modelli. È il punto cruciale: non stiamo cedendo il know-how Schüco al modello pubblico Claude. I dati passano i server Anthropic per essere processati e restituiti, senza ritenzione oltre la sessione e senza riutilizzo per addestramento.

Sul piano delle certificazioni, Anthropic è SOC 2 Type II e ISO 27001, con DPA (Data Processing Agreement) disponibile per clienti europei. Il transito è TLS 1.2+, e in caso di data breach c'è l'impegno contrattuale alla notifica entro 72 ore, in linea con l'articolo 33 del GDPR. Sono le stesse certificazioni che hanno i provider EU comparabili.

Sul piano della natura dei dati: è importante essere precisi. Sophron lavora su codice, schemi di database, documentazione tecnica, conversazioni di processo. Non lavora sulle anagrafiche dei clienti finali — e questo non per autoregolamentazione editoriale, ma per costruzione tecnica. Oltre alle protezioni applicative descritte al §7 (la privacy-sentinel che audita gli accessi AI ai DB) e al §8 (segreti centralizzati, gating per skill, ordine di autorità), l'utente database con cui Sophron si autentica ai sistemi gestionali ha DENY espliciti, lato server, sulle tabelle di anagrafica. Anche se il modello volesse leggere un campo personale, il database glielo nega prima ancora che la richiesta diventi un risultato. L'esposizione che viene effettivamente passata al provider esterno è quindi di natura industriale (proprietà intellettuale, know-how di processo), non di natura GDPR-stretta come per i dati personali. Il vettore «richieste governative statunitensi via CLOUD Act» è teorico ma proporzionale: parliamo di codice di applicazioni interne, non del database delle persone fisiche — che da Sophron, semplicemente, non è raggiungibile.

Sintesi: la policy di residenza EU di Schüco resta l'obiettivo strategico, non viene abbandonata. L'eccezione di breve termine è documentata, motivata dall'assenza di alternative equivalenti, e bilanciata da garanzie contrattuali sostanziali sul non-training, da certificazioni di settore, e — sul piano interno — da un perimetro di accesso al dato volutamente stretto. Non è la condizione di arrivo: è il compromesso pragmatico mentre la condizione di arrivo matura.

9.3 La direzione di lungo termine: server interno o VPS EU con open-source frontier

La direzione strategica del team è chiara: auto-hosting. Un server interno (datacenter Schüco) o un VPS in regione EU che ospiti un modello AI open-source frontier eseguito localmente. Questo eliminerebbe la dipendenza dal provider USA e darebbe piena conformità alla policy aziendale.

Il vincolo, oggi, è tecnico più che organizzativo: nessun modello open-source pubblico raggiunge ancora la qualità di Claude sul nostro use case specifico (sviluppo full-stack, agentic coding multi-step). La famiglia Llama, DeepSeek-Coder, Qwen2.5-Coder, Codestral sono in test e migliorano rapidamente — la stima realistica è che il gap si chiuda nei prossimi dodici-diciotto mesi. Quando un modello open raggiungerà la soglia di qualità richiesta, il team avrà già costruito le competenze AI-ops necessarie (orchestrazione vLLM/Ollama, tuning hardware GPU, serving API compatibile) e potrà migrare. L'integrazione con Sophron è progettata fin d'ora per non rompersi: lo scaffold parla all'LLM via interfaccia, non via dipendenza di vendor.

9.4 Perché questo importa, oltre al dettaglio tecnico

La domanda di apertura del capitolo — «come ci si fida di un LLM che vede tutti i nostri dati?» — non si risponde con una rassicurazione. Si risponde con una postura: la fiducia non è un assoluto, è una funzione del rischio reale, delle mitigazioni esistenti, della reversibilità della scelta e dell'esistenza di una traiettoria credibile verso un punto migliore.

Il team ha esplicitato tutte e quattro le componenti: ha misurato il rischio (training escluso, certificazioni note, natura industriale dei dati), ha valutato le mitigazioni (Commercial Terms, DPA, TLS, audit log), ha confermato la reversibilità (la conoscenza aziendale vive nei repository git interni, non sui server Anthropic — il giorno della migrazione, i dati non vanno recuperati: sono già qui), ed esiste una roadmap dichiarata verso la piena residenza EU.

Questo è ciò che si intende, in pratica, per fidarsi consapevolmente: non smettere di porsi la domanda, ma averla istruita per intero. Sophron — come scaffold — è agnostico rispetto al modello sotto, e ai server su cui quel modello gira. Il giorno in cui il modello e i server saranno interni, lo scaffold non se ne accorgerà. Nel frattempo, il compromesso è esplicito, ed è il compromesso che permette di lavorare oggi a una versione di Sophron in cui domani il provider potrà cambiare senza dover ricostruire nulla.