TECHNICAL ARCHITECTURE / SECURITY

Architettura e sicurezza Artiplane

Cinque livelli di Artiplane: microservizi, Control Plane, integrazioni applicative, identità, orchestrazione AI e sicurezza enterprise.

01Knowledge Integration
02Business Semantic
03Agent & Orchestration
04Application Integration
05Experience · Worker App

Specifica architetturale enterprise Artiplane · 11 ottobre 2026. Il documento definisce responsabilità e contratti del prodotto; servizi attivati, integrazioni, SLA e controlli applicati sono descritti nella configurazione di ciascuna installazione. Non costituisce un’attestazione di certificazione.

01 · PERIMETRO E DEPLOYMENT

Azure e infrastruttura privata: un modello operativo, più ambienti.

Ocra Group identifica Azure come ambiente della soluzione enterprise Artiplane e il deployment privato come opzione di prodotto. Il perimetro tecnico comprende servizi applicativi, dati, identità, connettori e operatività; la topologia viene definita per installazione.

Topologia Azure

La specifica separa ingresso API, servizi del Control Plane, worker di esecuzione, bus eventi, database transazionale, indice di ricerca e object storage. Un deployment Azure può associare questi ruoli ad API Management, AKS o Container Apps, Service Bus, database gestito, ricerca e Blob Storage. La scelta dei servizi non è implicita: regione, SKU, isolamento, disponibilità e dipendenze risultano dal dossier di installazione. Control Plane e runtime applicano autorizzazioni distinte.

Deployment nell’infrastruttura del cliente

Il profilo privato mantiene i contratti applicativi e sostituisce le dipendenze infrastrutturali con servizi compatibili: container runtime, database, coda, indice, storage, IdP e secret manager. Artefatti versionati, configurazione separata dai segreti, migrazioni controllate e procedure di restore delimitano il rilascio. Connettori in rete cliente usano percorsi autorizzati VPN/private networking o un integration worker dedicato; non richiedono di esporre l’ERP pubblicamente. Compatibilità e responsabilità operative si collaudano per ambiente.

Confine dei dati e chiamate esterne

Installazione privata e inferenza locale sono scelte differenti. Le route verso Claude, OpenAI o Bedrock sono abilitate solo se consentite dalla classificazione e dal contratto del cliente. Isolamento completo richiede modelli e dipendenze locali approvati oppure disabilitazione dell’inferenza esterna. Endpoint privati riducono l’esposizione di rete ma non cambiano da soli il luogo o le condizioni del trattamento.

02 · CINQUE LIVELLI

Confini logici, contratti espliciti, responsabilità separate.

I cinque livelli descrivono responsabilità software. Un livello può contenere più servizi; un modulo non è automaticamente un microservizio indipendente.

Knowledge Integration Layer

Acquisisce contenuti e record autorizzati, conserva chiavi e versioni sorgente, metadati ACL, classificazione e timestamp. Una pipeline produttiva separa parsing, indicizzazione e retrieval: il modello riceve solo evidenze già filtrate per identità e scopo.

Business Semantic Layer

Collega gli oggetti canonici Fashion — SKU, collezione, ordine, reso, negozio e mercato — ai campi degli applicativi. Versiona mapping, unità, valute, definizioni KPI e lineage. Un binding semantico descrive il dato, ma non concede accesso alla sorgente.

Agent & Orchestration · Process Engine

Il Process Engine descrive processi, ruoli, dipendenze e gate. L’Orchestrator traduce un obiettivo delimitato in missioni e task del Process Engine. Seleziona capacità e workflow registrati, propone azioni e richiede i gate umani. Il modello non possiede credenziali e non può decidere la propria autorità.

Application Integration · Adapters

L’orchestrazione collega capacità AI, workflow e applicativi. Gli adapter separano protocollo vendor, autenticazione tecnica, mapping e operazioni consentite. REST/OData, webhook o middleware dipendono dal sistema effettivo. Le letture producono evidenze; le scritture richiedono autorizzazione, controllo di versione e riconciliazione.

Experience · Worker App

Chat, Admin e Worker App presentano stato, proposte e decisioni. Il browser non è un confine di autorizzazione: un pulsante nascosto non protegge un’API. Il server rivalida identità, oggetto, tenant e operazione per ogni richiesta sensibile.

03 · COMUNICAZIONE TRA SERVIZI

Sincrono per leggere; asincrono per lavoro lungo e riconciliabile.

Contratto di riferimento: request → policy → evidenza → proposta → approvazione → comando → verifica dell’esito. Non tutte le richieste attraversano tutti i livelli.

Contratti e contesto

Un contratto versionato dichiara input/output JSON Schema, errori, timeout e limiti. L’envelope porta correlationId, tenantId, subjectId, operation, purpose, schemaVersion e deadline; il server ricava l’identità dalla sessione verificata, mai da un tenantId arbitrario inviato dal browser. Gli ID di tracciamento non sono token di accesso.

Eventi e consistenza

Per code ed eventi produttivi: eventId, aggregateId, sourceVersion e occurredAt, consumer idempotenti, gestione duplicati e messaggi fuori ordine, outbox transazionale ove necessaria e dead-letter con replay autorizzato. Non si promette exactly-once end-to-end: si riconciliano gli effetti sul sistema di record.

Guasti e scritture

Retry limitati solo per letture o operazioni documentate idempotenti; rispettare Retry-After, deadline e circuit breaker. Prima di riprovare una scrittura con esito incerto, leggerne lo stato. Una saga usa compensazioni definite, non un rollback globale inventato; per azioni irreversibili serve una procedura di eccezione.

04 · APPLICATIVI MAPPATI NELL’ADMIN

Control Plane: dal contratto applicativo all’operazione autorizzata.

Il catalogo Admin è il registro delle capacità: applicativo, ambiente, oggetti, operazioni e owner. La configurazione di una capacità è distinta dalla sua abilitazione operativa.

Contratto del connettore

Ogni capacità collega applicationId, connectionId, ambiente, versione API, oggetto vendor, chiave primaria, campo, trasformazione e semanticObjectId. Read, propose e write sono scope distinti; propose non concede write. SAP usa API REST/OData o middleware supportati dall’edizione installata; Salesforce applica scope OAuth e permessi su oggetti/campi del tenant; Centric PLM richiede interfacce e condizioni confermate dal vendor. Mapping a catalogo non implica licenza, certificazione o connessione attiva.

Registro server e ciclo di abilitazione

La specifica colloca endpoint, scope e riferimenti ai segreti in un registro server separato dal browser. Un integration worker risolve i segreti e valida destinazione, TLS, schema e autorizzazioni. La messa in servizio richiede test di lettura e ACL, owner e data di verifica; scadenza credenziali, drift di schema o verifica scaduta devono sospendere le capacità interessate. Health check ed esito delle operazioni sono evidenze differenti: un endpoint raggiungibile non prova una scrittura corretta.

Lineage verificabile nel campo

Il valore diretto conserva applicativo, oggetto/campo, chiave record, versione ed extractedAt. Un dato derivato aggiunge input, formula o trasformazione e versione; un risultato AI aggiunge runId, agente, workflow, provider/modello e riferimenti alle evidenze. Le restrizioni indicate derivano dalla policy effettivamente applicata, non dal filtro visivo. Schema, paginazione, delta, duplicati, ACL negative e totali riconciliati fanno parte del collaudo.

05 · LOGIN E AUTORIZZAZIONI

Autenticare una persona non autorizza ogni azione.

Identità utente, identità del servizio e autorizzazione sull’oggetto sono tre controlli distinti.

Federazione dell’identità

Il contratto SSO supporta federazione con l’IdP aziendale: OIDC Authorization Code con PKCE, verifica issuer, audience, firma, scadenza, state e nonce dove applicabile; SAML è un profilo alternativo da configurare. MFA e Conditional Access sono policy dell’IdP. Il provisioning collega l’identità stabile al tenant e ai ruoli amministrati; SCIM, se abilitato, gestisce il ciclo di vita senza trasformare attributi editabili dall’utente in privilegi.

Ruolo, organizzazione e scope

Organizzazione rappresenta funzioni centrali, Country, brand, mercato e appartenenze multiple; non è da sola una concessione di accesso. Il permesso effettivo interseca ruolo fidato, tenant, perimetro organizzativo autorizzato, processo, classificazione, scope del tool e ACL sorgente. Policy server e filtri di riga negano per default e filtrano anche indici e retrieval. Nessun orchestratore può ampliare il perimetro dell’utente; l’Admin opera solo entro le deleghe assegnate.

Sessioni, revoca e identità di servizio

La specifica prevede sessioni con scadenza e revoca; cookie HttpOnly, Secure e SameSite secondo il flusso scelto e difesa CSRF per operazioni autenticate da cookie. I servizi usano identità workload limitate, con token a breve durata ove supportato e audience dedicata. La disabilitazione dell’utente o la revoca di un ruolo deve raggiungere sessioni, cache autorizzative e job in attesa. Prima di un’azione differita si ricalcola il permesso, senza riusare una decisione ormai obsoleta.

06 · SICUREZZA DI RETE E DATI

Protezione per confini, non per slogan.

La baseline enterprise deve essere applicata all’ambiente reale e verificata con configurazioni, log e prove di attacco.

Ingresso, uscita e isolamento

TLS per il trasporto; WAF e limiti all’ingresso secondo l’ambiente, allowlist e controlli anti-SSRF in uscita, segmentazione e database non esposti pubblicamente dove previsto. Per tenant condivisi, i test devono coprire API, cache, indici, file e job. Una rete privata non elimina il controllo di identità.

Gestione chiavi e cifratura

La baseline distingue chiavi di sessione, credenziali connettori e chiavi dati; le credenziali restano nel secret manager o sono protette mediante envelope encryption, mai in prompt, browser o log. Su Azure il profilo può usare Key Vault e managed identity; il profilo privato richiede un servizio equivalente. AES-GCM richiede nonce unico per chiave e verifica del tag; cifratura at-rest, rotazione, versioni delle chiavi e restore dei backup sono controlli separati da configurare e collaudare. TLS protegge il trasporto, non sostituisce la cifratura dello storage.

Hash, audit e retention

SHA-256 è un hash, non cifratura né anonimizzazione. Da solo non prova autore, data o immutabilità e può rivelare uguaglianze. Evidenza antimanomissione richiede storage append-only/WORM o firma/HMAC con chiavi protette e timestamp affidabile. Retention configurabile deve coprire contenuti, indici, log e backup, con legal hold e tempi di cancellazione dichiarati.

07 · CLAUDE, OPENAI, AMAZON BEDROCK

La route del modello è anche una decisione di trattamento dati.

La configurazione di inferenza identifica provider, modello, regione, credenziale di servizio e condizioni contrattuali. La selezione dal catalogo abilita una route solo dopo validazione nel tenant.

Claude e OpenAI

Claude può essere invocato tramite API Anthropic o, per modelli disponibili, Bedrock; le API e i contratti non sono intercambiabili. OpenAI usa adapter per API supportate, output strutturati e tool/function calling. Il modello restituisce una proposta di chiamata: il server valida schema, policy e parametri prima di eseguire. Non si importano pesi, sessioni o stato proprietario di agenti.

Bedrock e confini AWS

L’adapter Bedrock richiede account, regione, disponibilità del modello e autorizzazioni IAM; eventuali InvokeModel/Converse, agenti e Knowledge Bases sono capacità distinte. Guardrails e private endpoint si configurano separatamente. Profili di inferenza cross-region possono cambiare il trattamento geografico: verificarli, non dedurre residenza dal nome della regione.

Model Gateway e policy di routing

Il contratto Model Gateway applica classificazione, minimizzazione e redazione PII, regione ammessa, tool consentiti, token budget, timeout e qualità prima della chiamata. Un agentId risolve una versione di capacità e workflow; il provider adapter traduce il contratto comune nell’API selezionata senza presumere equivalenza delle funzioni. Il run registra provider/model ID, policyVersion, consumi, evidenze e risultati validati. Fallback solo fra route già autorizzate: una quota esaurita non permette di aggirare residenza o riservatezza. Training, retention e logging dipendono dal servizio e dall’accordo attivato.

08 · N8N E WORKFLOW ESTERNI

n8n esegue workflow; non concede autorità all’AI.

Un workflow importato è configurazione. Diventa capacità operativa solo dopo validazione di nodi, credenziali, trigger e permessi.

Import ed esecuzione

L’export JSON trasferisce definizioni compatibili, non automaticamente segreti, licenze, stato o esecuzioni. L’integrazione seleziona endpoint e workflow versionati, autentica webhook/callback, registra executionId e correlationId e limita le operazioni ammesse. Per webhook: firma o token protetto, verifica replay e timestamp quando supportati.

Worker isolati e callback verificate

La specifica separa editor, worker, code e credenziali n8n secondo il deployment. Input/output, egress, sub-workflow e codice dei nodi hanno regole di validazione e un owner operativo. Il comando autorizzato contiene oggetto, scope, versione, approvazione e scadenza; il worker non può ampliarlo. Callback autenticate e deduplicate aggiornano lo stato Artiplane tramite executionId/correlationId. Timeout o esito incerto aprono riconciliazione; non autorizzano una seconda azione irreversibile.

09 · PROCESS ENGINE E CONTROLLO UMANO

La proposta e l’esecuzione hanno stati diversi.

Un task AI, un’approvazione e una scrittura applicativa non sono la stessa operazione.

Gate resistente ai cambiamenti

Un gate produttivo lega approvatore autorizzato, input, importo, oggetto, versione e scadenza. Qualsiasi modifica rilevante invalida l’approvazione. Prima della scrittura si rivalidano permessi e versione sorgente, riducendo il rischio time-of-check/time-of-use; niente auto-approvazione per azioni soggette a segregazione dei compiti.

Esempio: reso e-commerce

Il CRM raccoglie il caso, commerce/ERP validano ordine e pagamento, WMS registra ricezione e qualità. La semantica collega ID reso, SKU e mercato; l’AI può sintetizzare evidenze e proporre l’esito. Finance o Quality autorizzano le eccezioni; l’adapter esegue solo l’operazione concessa e riconcilia rimborso/stock. Soglie e applicativi sono quelli confermati dal cliente, non numeri inventati.

Dal Designer all’esecuzione governata

La specifica separa draft, validazione, versione pubblicata e istanza di processo. Il Designer produce task tipizzati, gateway, corsie, binding semantici e gate; la pubblicazione richiede owner, capacità autorizzate, policy e collaudo. L’Orchestrator governa obiettivi e missioni dall’alto, mentre agenti e workflow registrati operano sui singoli task. Il runtime mantiene stato durevole, timer, tentativi ed eventi per caseId e processVersion. Analisi di performance, conformance e root cause derivano dagli event log validati; scenari previsionali e stime economiche restano separati dai consuntivi.

10 · MINACCE SPECIFICHE AI

Documenti e risposte del modello sono input non fidati.

Le istruzioni contenute in mail, documenti o output di un tool non possono cambiare policy o autorizzazioni.

Prompt injection ed esfiltrazione

Separare istruzioni di sistema e contenuto recuperato; applicare allowlist dei tool, validazione parametri, filtri ACL prima del retrieval e controllo egress. Non inserire segreti nel contesto. Un detector o un system prompt da soli non fermano tutte le injection: i confini di esecuzione server sono essenziali.

Output e azioni

Validare JSON Schema e vincoli business; sanificare HTML e link, trattare codice/SQL generati come non fidati, vietare esecuzione arbitraria. Le citazioni aiutano la verificabilità, non garantiscono correttezza. Testare evidenza insufficiente, conflitti, dati obsoleti, costi eccessivi e tentativi cross-tenant.

11 · COMPLIANCE E RESPONSABILITÀ

Controlli compatibili con la governance; conformità da dimostrare.

Nessuna architettura, hash o certificazione del cloud rende automaticamente conforme tutta l’applicazione.

Privacy e AI Act

Per GDPR documentare titolare/responsabili, base giuridica, finalità, minimizzazione, DPA, sub-responsabili, trasferimenti, diritti e DPIA quando necessaria. Per AI Act valutare ruolo e classe di rischio dello specifico uso, obblighi applicabili e supervisione umana. La presenza di gate non equivale a certificazione legale.

Responsabilità condivisa

Ocra Group presidia codice e componenti forniti; il cliente governa identità, dati, policy e configurazioni concordate; cloud e provider AI coprono i propri servizi secondo contratto. La ripartizione concreta va formalizzata in RACI, SLA e DPA. ISO 27001/SOC 2 del fornitore non si trasferiscono automaticamente ad Artiplane.

12 · CHALLENGE TECNICO E ACCETTAZIONE

Le domande difficili diventano prove di rilascio.

La revisione collega ogni criticità a un criterio di accettazione e a un’evidenza richiesta. Non sostituisce un audit indipendente dell’installazione.

Identità, tenant, dati

Provare token scaduto, issuer/audience errati, ruolo revocato, accesso a oggetto altrui, cache condivisa e ACL eliminate dall’indice. Il risultato atteso è il rifiuto prima di restituire dati o invocare un tool. La revoca deve raggiungere anche job e sessioni differite.

AI, approval, connettori

Iniettare istruzioni malevole nei documenti; cambiare importo dopo approvazione; simulare callback duplicate, timeout dopo scrittura, quota esaurita e provider non consentito. Atteso: nessuna escalation di privilegi, nessuna doppia scrittura, nessun fallback vietato e stato di eccezione riconciliabile.

Pacchetto di evidenze

Prima della produzione richiedere diagramma as-built e inventario servizi, threat model, matrice accessi, SBOM, scansioni e penetration test con remediation, evidenze cifratura/rotazione, restore test, RPO/RTO misurati, log audit, DPA e configurazione provider. Senza queste prove il controllo resta un requisito o una dichiarazione, non una garanzia verificata.

Standard e documentazione dei fornitori

Artiplane / Resources