Una storia di uno che si è trasferito per utilizzare legalmente un LLM in una PMI di 12 uomini e, se possibile, anche per certificare secondo ISO 41001. Questa è, per così dire, la raccolta di idee del piano di progetto e il brainstorming della struttura entry-level.
Nota sull'uso del presente documento
Questo piano di progetto è stato creato come base di lavoro strutturata e classifica le fasi tecniche, organizzative e legali per l'introduzione di Open WebUI + Ollama come soluzione AI on-premise, nonché la strada per una possibile certificazione ISO / IEC 42001.
REDDIT IANAL (non sono un avvocato) Disclaimer: Le valutazioni giuridiche sul GDPR, NIS2/BSIG-neu e la legge dell'UE sull'IA si basano sullo status giuridico accessibile al pubblico dell'agosto 2026 e non sostituiscono la consulenza legale nei singoli casi. Per le dichiarazioni giuridicamente vincolanti (in particolare sulla nomina di un responsabile della protezione dei dati, sulla necessità di una valutazione d'impatto sulla protezione dei dati e sull'applicabilità della NIS2), si raccomanda di consultare uno studio legale specializzato in diritto della protezione dei dati e della sicurezza informatica o un consulente esterno adeguatamente qualificato.
contenuto
1. Sintesi
2. Situazione iniziale e obiettivi
3. Quadro giuridico generale
4. Analisi dettagliata: Protezione dei dati (GDPR / BDSG)
5. Analisi dettagliata: NIS2 / BSIG-nuovo
6. Analisi dettagliata: Normativa dell'UE sull'IA
7. ISO/IEC 42001 – Percorso verso la certificazione
8. Architettura tecnica e implementazione
9. Organizzazione e ruoli del progetto
Piano di fase e tappe fondamentali
11. Gestione del rischio
12. Pianificazione dei costi e delle risorse
13. Criteri di successo
14. Prossime tappe (primi 30 giorni)
15. Allegato 18
1. Sintesi
L'azienda prevede di introdurre Open WebUI come interfaccia self-hosted basata su browser per i modelli di lingua AI locali (basata su: Ollama) per fornire ai 12 dipendenti un assistente AI conforme alla protezione dei dati per il lavoro di testo, la ricerca delle conoscenze nella documentazione tecnica (RAG) e ulteriori casi d'uso (completamente sulla propria infrastruttura) senza trasferire i dati aziendali o dei clienti a fornitori cloud esterni.
Il presente piano di progetto ha tre obiettivi paralleli:
- Introduzione tecnica: stack AI on-premise robusto, ad alte prestazioni e gestito in modo sicuro (Open WebUI, Ollama, database delle conoscenze RAG, controllo degli accessi).
- Conformità giuridica fin dall'inizio: Considerazione del GDPR/BDSG, della legge dell'UE sull'IA e di una valutazione fondata e specifica per l'azienda dell'applicabilità della NIS2 (nuova BSIG).
- Capacità di certificare: Sviluppo di un sistema di gestione dell'IA (AIMS) che soddisfi i requisiti della norma ISO/IEC 42001 e possa essere certificato esternamente.
Principali risultati in anticipo:
- Il funzionamento on-premise è il vantaggio principale ai sensi della normativa sulla protezione dei dati: Finché nessun flusso di dati verso API modello esterne, plug-in di ricerca web o servizi cloud, non si verifica alcun trattamento degli ordini ai sensi dell'articolo 28 GDPR nei confronti di un fornitore di IA. Questo vantaggio deve essere garantito dal punto di vista tecnico e organizzativo (cfr. capitoli 4 e 8).
- Allo stato attuale delle cose, NIS2 non dovrebbe essere direttamente obbligatorio: Con 12 dipendenti, la società dovrebbe essere al di sotto delle soglie per le "entità importanti" o "particolarmente importanti". Si raccomanda tuttavia di fornire orientamenti volontari sulle misure di riferimento della NIS2, tra l'altro a causa di eventuali esigenze della catena di approvvigionamento dei clienti più grandi (cfr. capitolo 5).
- La legge dell'UE sull'IA riguarda già in parte l'impresa: in particolare, l'obbligo di impartire competenze in materia di IA (articolo 4 del regolamento sull'IA), che è applicabile dal febbraio 2025, indipendentemente dalle dimensioni dell'impresa. Gli obblighi ad alto rischio non sono pertinenti per il caso d'uso previsto (cfr. capitolo 6).
- La norma ISO/IEC 42001 è volontaria ma strategica: Come prova per i clienti della catena di approvvigionamento delle tecnologie di misurazione e produzione e come base strutturale per una governance dell'IA conforme alla legge (cfr. capitolo 7).
Il periodo totale previsto fino alla scadenza della certificazione è di circa 10-12 mesi, suddivisi in otto fasi di progetto (capitolo 10). Una prima stima approssimativa dei costi è contenuta nel capitolo 12.
2. Situazione iniziale e obiettivi
2.1 Situazione iniziale
L'azienda è una PMI con 12 dipendenti nel campo della tecnologia di misurazione industriale. Tipiche categorie di dati in tale stabilimento includono disegni tecnici e dati di progettazione, registri di misurazione e dati di calibrazione, documentazione del cliente (in parte nell'ambito di NDA), documentazione interna di processo e qualità (ad esempio nel contesto della ISO 9001) e dati personali di dipendenti, clienti e fornitori. Questi dati sono regolarmente classificati come segreti commerciali e commerciali ai sensi della legge sui segreti commerciali (GeschGehG) e sono spesso soggetti a ulteriori obblighi contrattuali di riservatezza nei confronti dei clienti dell'industria manifatturiera.
Gli strumenti di chat di IA basati sul cloud (ad esempio ChatGPT, Copilot, Gemini nella configurazione standard) significherebbero un trasferimento a fornitori non europei o esterni in questa situazione di dati, che è rischiosa sia ai sensi della legge sulla protezione dei dati che contrattualmente in un ambiente B2B sensibile con obblighi di riservatezza. Una soluzione self-hosted e on-premise come Open WebUI in combinazione con Ollama evita sostanzialmente questo deflusso di dati, poiché il modello e i dati rimangono completamente sulla propria infrastruttura.
2.2 Obiettivi del progetto
- Fornitura di una procedura guidata AI interna e conforme al GDPR per tutti i 12 dipendenti (bozze di testo, sintesi, ricerca nella documentazione interna, supporto prospettico per i testi di offerta e report).
- Sviluppo di una base di conoscenze supportata da RAG basata su documentazione tecnica interna, manuali e standard, senza che questo contenuto lasci l'azienda.
- Istituzione di una base operativa giuridicamente conforme (protezione dei dati, politica di utilizzo dell'IA, concetto di ruolo e diritti).
- Istituire un sistema di gestione dell'IA (AIMS) e ottenere la certificazione secondo ISO/IEC 42001 entro circa 12 mesi dall'inizio del progetto.
- Creazione di un punto di riferimento per le richieste dei clienti e le gare d'appalto, che richiedono sempre più prove di un uso responsabile dell'IA e della sicurezza delle informazioni.
2.3 Delimitazione (non-obiettivi)
- Nessun utilizzo dell'IA per il processo decisionale automatizzato nei confronti di clienti o richiedenti (nessuna profilazione, nessuna decisione individuale automatizzata ai sensi dell'articolo 22 GDPR).
- Nessuna integrazione della componente di IA nei prodotti di misurazione fisica o nel controllo della produzione nell'ambito del presente progetto (ciò richiederebbe la riclassificazione come sistema di IA ad alto rischio a norma dell'allegato I del regolamento dell'UE sull'IA, cfr. capitolo 6.3).
- Nessun uso produttivo di funzioni di IA aggiuntive basate sul cloud (ricerca web esterna, generazione di immagini esterne, API linguistiche esterne) nella configurazione di base, in quanto sarebbero contrarie all'approccio on-premise (cfr. capitolo 8.6).
- Nessuna decisione del personale o valutazione delle prestazioni basata su valutazioni AI dei dati dei dipendenti.
3. Panoramica del quadro giuridico
La tabella seguente riassume quali regolamenti sono rilevanti per il progetto, se sono vincolanti per un'azienda di queste dimensioni e cosa segue specificamente per il progetto. L'analisi dettagliata è effettuata nei capitoli da 4 a 7.
| Norme e regolamenti | legante | Obbligo fondamentale | Correlati al progetto |
| GDPR / BDSG | Rilegatura (sempre) | Trattamento legale e sicuro dei dati personali | Directory di elaborazione, TOM, DSFA se applicabile, Responsabile della protezione dei dati se applicabile |
| NIS2 / BSIG-nuovo | Probabilmente non direttamente obbligatorio | Gestione dei rischi per la cibersicurezza, obblighi di segnalazione | orientamento volontario raccomandato; Verificare la rilevanza della supply chain per i clienti più grandi |
| Normativa dell'UE sull'IA | Parzialmente vincolante | Competenza in materia di IA (articolo 4), divieti (articolo 5), trasparenza (articolo 50) | l'obbligo di impartire una formazione a norma dell'articolo 4; Obblighi ad alto rischio non pertinenti |
| ISO/IEC 42001 | Volontariato | Sviluppo di un sistema di gestione dell'IA (AIMS) | Obiettivo di certificazione dell'azienda è strutturato l'intero progetto |
| GeschGehG | Obbligatorio | Adeguate misure di riservatezza | Concetto di accesso e registrazione dei dati di progettazione/misura |
| BetrVG (se esiste un comitato aziendale) | Condizionatamente vincolante | Codeterminazione in sistemi con potenziale di monitoraggio (articolo 87, paragrafo 1, punto 6) | Coinvolgimento precoce, politica di utilizzo dell'IA, se del caso, come accordo operativo |
Nota: La presente panoramica non sostituisce una valutazione giuridica caso per caso. In particolare, la classificazione NIS2 dipende non solo dal numero di dipendenti, ma anche dal fatturato annuo e dal totale di bilancio dell'impresa, che non sono ancora noti (cfr. capitolo 5.2).
4. Analisi dettagliata: Protezione dei dati (GDPR / BDSG)
4.1 Responsabilità e basi giuridiche
In qualità di gestore del sistema on-premise, la società è «titolare del trattamento» ai sensi del diritto in materia di protezione dei dati ai sensi dell’articolo 4, paragrafo 7, RGPD per tutti i dati personali trattati tramite Open WebUI. Possono essere considerate basi giuridiche:
- Articolo 6, paragrafo 1, lettera f), RGPD (legittimo interesse) per uso generale come strumento di efficienza e ricerca, purché sia documentato un equilibrio di interessi.
- § 26 BDSG in combinato disposto con l'art. 88 GDPR per il trattamento dei dati dei dipendenti nel contesto dell'uso (ad esempio registri di utilizzo, cronologia tempestiva dei singoli dipendenti).
- Articolo 6, paragrafo 1, lettera b), RGPD , nella misura in cui i dati dei clienti sono trattati nel contesto dell'esecuzione del contratto (ad esempio, preparazione di rapporti di prova).
Raccomandazione: La base giuridica specifica dovrebbe essere documentata nel repertorio di trattamento per ciascun caso d'uso (cfr. 4.5).
4.2 L'elaborazione degli ordini è il vantaggio centrale dell'operazione on-premise
Finché Open WebUI e i modelli linguistici connessi sono gestiti esclusivamente localmente sulla propria infrastruttura e non vengono inviate richieste a API di modelli esterni (ad esempio OpenAI, Anthropic, Google), non sorge alcun trattamento degli ordini ai sensi dell'articolo 28 GDPR nei confronti di un fornitore di IA. In linea di principio, pertanto, non deve essere effettuato alcun contratto di trattamento degli ordini (DPA) e nessun esame di un trasferimento di un paese terzo conformemente al capo V GDPR per le operazioni di IA di base.
Nota: Questo vantaggio si applica solo a condizione che la configurazione sia costantemente rispettata. Non appena vengono attivate funzioni cloud opzionali in Open WebUI (fornitori di ricerca web esterni, generazione di immagini/lingua esterna o un modello cloud aggiuntivo come riserva), i dati vengono nuovamente trasmessi a terzi per tali funzioni, il che richiede un AVV e, se necessario, una valutazione dell'impatto del trasferimento (cfr. capitolo 8.6). Questo dovrebbe essere tecnicamente (disattivazione nella configurazione di amministrazione) e organizzativamente (politica di utilizzo AI).
4.3 Valutazione d'impatto sulla protezione dei dati (DSFA, art. 35 GDPR)
L'obbligatorietà di un DSFA dipende dal rischio specifico del trattamento. Esistono diverse indicazioni per l'uso di un'applicazione di IA per un obbligo DSFA o per un'attuazione volontaria raccomandata:
- Uso delle nuove tecnologie (articolo 35, paragrafo 1, GDPR) I modelli linguistici dell'IA sono regolarmente considerati tali secondo la diffusa prassi di vigilanza.
- Possibile valutazione sistematica e completa degli aspetti personali, a condizione che l'IA sia applicata anche ai documenti o alle applicazioni del personale in futuro (escluso nell'ambito di applicazione attuale, cfr. 2.3).
- Nelle loro linee guida sulle applicazioni di IA, le autorità di controllo tedesche (Conferenza sulla protezione dei dati, DSK) raccomandano regolarmente l'attuazione di un DSFA, anche al di sotto della soglia legale obbligatoria, come prova di responsabilità (articolo 5, paragrafo 2, GDPR).
Raccomandazione: Una DSFA dovrebbe essere effettuata nell'ambito della fase 1 del progetto, indipendentemente dalla classificazione giuridica finale del suo obbligo. Fornisce inoltre un elemento essenziale per la successiva certificazione ISO/IEC 42001 (valutazione dei rischi, cfr. capitolo 7.5) e per qualsiasi gestione dei rischi NIS2 (capitolo 5).
4.4 Obbligo di nominare un responsabile della protezione dei dati (§ 38 BDSG)
Ai sensi dell’articolo 38, paragrafo 1, prima frase, del BDSG, un obbligo di ordine sussiste di norma solo se almeno 20 persone partecipano in modo permanente al trattamento automatizzato di dati personali. Con 12 dipendenti, questa soglia non dovrebbe generalmente essere raggiunta.
Eccezione importante: Ai sensi dell’articolo 38, paragrafo 1, seconda frase, del BDSG, l’obbligo di effettuare un ordine si applica indipendentemente dal numero di dipendenti non appena viene effettuato un trattamento soggetto a una valutazione d’impatto sulla protezione dei dati ai sensi dell’articolo 35 del RGPD. Se viene affermato un obbligo DSFA per il progetto di IA come raccomandato al punto 4.3, ciò può anche comportare l'obbligo di nominare un responsabile della protezione dei dati indipendentemente dalle dimensioni dell'azienda.
- Questa domanda dovrebbe essere chiarita in una fase iniziale durante il pre-esame DSFA con uno specialista.
- Indipendentemente da un obbligo giuridico, la designazione volontaria di una persona di contatto responsabile (responsabile interno o esterno della protezione dei dati) è raccomandata per una PMI di tali dimensioni nel contesto dell'IA ed è comunque raccomandata dalla norma ISO/IEC 42001 nel senso di ruoli e responsabilità chiari (cfr. capitolo 9).
Nota: A livello federale, si sta discutendo del fatto che l'articolo 38, paragrafo 1, BDSG dovrebbe essere soppresso senza sostituzione e che l'obbligo di effettuare ordini dovrebbe basarsi esclusivamente sull'approccio basato sul rischio di cui all'articolo 37 GDPR (annuncio nel contesto dell'"Agenda federale di modernizzazione" del 4 aprile 2018). dicembre 2025, attuazione annunciata entro la fine del 2026, ad agosto 2026 non ancora in vigore). L'attuale situazione giuridica dovrebbe essere riesaminata al momento dell'attuazione.
4.5 Elenco delle attività di trattamento (Art. 30 GDPR)
Per ciascun caso d'uso basato sull'IA (ad esempio "assistente di chat interno", "documentazione tecnica di ricerca delle conoscenze RAG", "bozze di testo per la comunicazione con i clienti"), deve essere creata una voce separata nel repertorio del trattamento, con informazioni sulla finalità , sui gruppi di persone interessate, sulle categorie di dati, sulla base giuridica, sul periodo di conservazione, sulle misure tecniche e organizzative e, se del caso, sui destinatari.
4.6 Misure tecniche e organizzative (Art. 32 GDPR)
In particolare, per le operazioni in loco devono essere attuate e documentate le seguenti misure:
- Crittografia dei dati a riposo (database, archiviazione vettoriale, file system) e in transito (TLS/SSL tramite il proxy inverso, cfr. capitolo 8.5).
- Concetto di ruolo e diritti in Open WebUI (admin vs. ruoli utente, restrizione di accesso alle basi di conoscenza come richiesto).
- Registrazione di eventi rilevanti per la sicurezza (accesso, modifiche amministrative) tenendo conto della limitazione delle finalità . Inoltre, nessun controllo comportamentale o delle prestazioni dei singoli dipendenti.
- Backup regolari e crittografati con un concetto di ripristino definito.
- Segmentazione della rete: Il server AI deve essere isolato nella rete interna, nessun accesso diretto da Internet senza VPN o proxy inverso protetto.
- Gestione di patch e versioni per Open WebUI, Ollama e la base del sistema operativo.
4.7 Diritti degli interessati e concetto di cancellazione
Poiché le banche dati di conoscenza degli orientamenti possono anche contenere dati personali (ad esempio persone di contatto nei documenti dei clienti, nomi negli allegati di posta elettronica), è necessario un concetto di cancellazione che specifichi in che modo le richieste di informazioni, correzione e cancellazione (articoli 15-17 GDPR) possono essere tecnicamente attuate nella banca dati dei vettori. Raccomandazione: prevedere lo screening/l'anonimizzazione di contenuti ovviamente personali ma non richiesti prima di introdurre documenti nella base di conoscenze.
4.8 Protezione e codeterminazione dei dati dei dipendenti
L'introduzione di un sistema di IA, che in linea di principio può essere registrato e valutato, può essere soggetta a codeterminazione ai sensi dell'articolo 87, paragrafo 1, punto 6, BetrVG, a condizione che vi sia un comitato aziendale in azienda (non necessariamente disponibile per 12 dipendenti, ma possibile). Se esiste un comitato aziendale, dovrebbe essere coinvolto in una fase iniziale e dovrebbe essere concluso un accordo operativo sull'uso dell'IA. Se non esiste un comitato aziendale, si raccomanda comunque di creare una politica scritta di utilizzo dell'IA che regoli in modo trasparente ciò che è registrato e perché (cfr. capitolo 4.9).
4.9 Politica di utilizzo dell'IA per i dipendenti
È opportuno istituire una direttiva sull'utilizzo dell'IA come documento interno vincolante che comprenda, tra l'altro:
- Casi d'uso ammissibili e inammissibili (ad esempio, nessun accesso a segreti commerciali strategici di terzi senza rilascio, anche se rimangono in loco).
- Divieto di elusione delle misure tecniche di protezione (ad esempio uso privato di strumenti di IA esterni per contenuti aziendali soggetti a riservatezza).
- Gestione dei contenuti generati dall'IA (obblighi di etichettatura, obbligo di effettuare controlli tecnici prima del riutilizzo, in particolare per i dati di misurazione e di prova).
- Informazioni sulla trasparenza in materia di registrazione e valutazione ai sensi dell'articolo 13/14 del GDPR.
5. Analisi dettagliata: NIS2 / BSIG-nuovo
5.1 Contesto giuridico
La direttiva (UE) 2022/2555 (NIS2) è stata recepita in Germania con notevole ritardo dalla "legge sull'attuazione della direttiva NIS 2 e sulla regolamentazione dei principi essenziali della gestione della sicurezza delle informazioni nell'amministrazione federale" (NIS2UmsuCG). La legge è stata approvata il 5. È stato promulgato nella Gazzetta ufficiale federale il 6 dicembre 2025. è entrato in vigore il 1o dicembre 2025 senza un periodo transitorio; modifica fondamentalmente la legge BSI (nuova BSI). In tutta la Germania, si stima che circa 29 500 imprese siano direttamente interessate; l'obbligo di registrazione al portale BSI (attivato il 6 gennaio 2026) è scaduto il 6 marzo 2026 per i soggetti interessati.
5.2 Test di applicabilità per l'azienda
Gli obblighi NIS2 si applicano ai "soggetti importanti" e ai "soggetti particolarmente importanti". La classificazione viene effettuata in due fasi: prima sull'affiliazione settoriale (allegato I/II della direttiva), poi sulle classi dimensionali.
Fase 1 – Affiliazione settoriale
La fabbricazione di strumenti di misura, controllo, navigazione e simili rientra nel gruppo C26 della NACE («Fabbricazione di apparecchiature per l’elaborazione dei dati, prodotti elettronici e ottici»), che è esplicitamente elencato nell’allegato II della direttiva NIS2 come sottosettore dell’«industria manifatturiera» in quanto altro settore critico («soggetto importante»). Un'impresa di metrologia industriale rientra quindi generalmente nell'ambito di applicazione della NIS2 in termini di ambito settoriale, ma l'applicabilità finale dipende dalla classe dimensionale (fase 2).
Fase 2 – Classe di dimensione
La direttiva NIS2 esclude generalmente dal suo campo di applicazione le microimprese e le piccole imprese. La definizione di PMI dell'UE è pertinente:
| categoria | Dipendenti | Fatturato annuo | o totale dello stato patrimoniale | Stato NIS2 |
| micro | < 10 | ≤ 2 milioni di EUR | ≤ 2 milioni di EUR | Regolarmente escluso |
| Piccole imprese | < 50 | ≤ 10 milioni di EUR | ≤ 10 milioni di EUR | Regolarmente escluso |
| Media impresa | < 250 | ≤ 50 milioni di EUR | ≤ 43 milioni di EUR | «Important facility» possibile |
Classificazione: Con 12 dipendenti, la società è al di sotto della soglia di 50 persone per le "piccole imprese". Se, inoltre, il fatturato annuo o il totale di bilancio non supera i 10 milioni di euro (che è probabilmente la regola per questa dimensione dell'attività , ma deve essere confermata su base specifica dell'impresa), è improbabile che gli obblighi NIS2 diretti si applichino in base alle conoscenze attuali.
Indipendentemente dall'esenzione per dimensioni, la NIS2 si applica tuttavia a determinati tipi di entità , indipendentemente dalle loro dimensioni (compresi gli operatori di reti pubbliche di telecomunicazioni, i prestatori di servizi fiduciari qualificati, i fornitori di servizi DNS/registratori di TLD, le pubbliche amministrazioni, i soggetti classificati come critici ai sensi della legge sul tetto KRITIS e i soggetti che sono gli unici fornitori di un servizio in Germania importante per il mantenimento di attività sociali o economiche critiche). Nessuna di queste eccezioni dovrebbe in genere applicarsi a una PMI che effettua misurazioni di tali dimensioni; Si raccomanda tuttavia una breve valutazione nella fase 1 del progetto (cfr. allegato A).
5.3 Pertinenza indiretta: Sicurezza della catena di approvvigionamento
Anche in assenza di un proprio obbligo NIS2, la società può essere indirettamente interessata: I clienti obbligati NIS2 (ad esempio i principali fornitori di ingegneria meccanica o automobili che sono a loro volta considerati "importanti" o "soggetti particolarmente importanti") devono valutare la sicurezza della loro catena di approvvigionamento (articolo 21 della direttiva NIS2) e trasmettono sempre più contrattualmente i requisiti di sicurezza ai fornitori, compresi i partner più piccoli come una PMI di misurazione. La sicurezza delle informazioni documentate e la gestione dei rischi dell'IA stanno diventando sempre più un fattore competitivo e di gara, indipendentemente dal proprio obbligo NIS2.
5.4 Raccomandazione per il progetto
- Non effettuare una registrazione NIS2 formale fino a quando le soglie non sono raggiunte (sforzo burocratico non necessario).
- Utilizzare volontariamente le misure di base NIS2 ai sensi del § 30 BSIG-neu (compresi la gestione del rischio, i processi di rilevamento e segnalazione degli incidenti, la gestione del backup e delle emergenze, la crittografia e i concetti di crittografia, il controllo degli accessi, la formazione, la sicurezza della catena di approvvigionamento) come orientamento per la protezione tecnica del sistema di IA. Questi sono in gran parte in linea con i controlli richiesti comunque per ISO/IEC 42001 e l'articolo 32 GDPR (cfr. capitolo 4.6, 7.5, 8.5).
- La possibilità di registrazione volontaria con il BSI (per le società non obbligate ai sensi del nuovo BSIG) può essere facoltativamente verificata se l'azienda vuole pubblicizzare attivamente con una maggiore resilienza informatica ai clienti.
- La classificazione dimensionale dovrebbe essere rivalutata in caso di crescita futura (superiore a 50 dipendenti o 10 milioni di euro di fatturato/totale di bilancio), in quanto ciò potrebbe comportare un obbligo NIS2.
6. Analisi dettagliata: Normativa dell'UE sull'IA
6.1 Ruolo dell'azienda
Nell'uso previsto di Open WebUI con modelli linguistici aperti pre-formati (ad esempio tramite Ollama), la società agisce ai sensi del diritto in materia di protezione dei dati e di prodotti come "operatore" (datore di lavoro) ai sensi dell'articolo 3, paragrafo 4, del regolamento sull'IA, non come "fornitore" (fornitore). Gli obblighi del fornitore (valutazione della conformità , documentazione tecnica del modello) si applicano ai fabbricanti di modelli e non alla PMI richiedente, a meno che la società non adatti i propri modelli in modo così fondamentale o li trasmetta a proprio nome da diventare il fornitore stesso (non previsto nell'ambito di applicazione previsto).
6.2 Pratiche vietate (articolo 5 del regolamento sull'IA)
I divieti relativi a determinate pratiche di IA (tra cui il punteggio sociale, determinate forme di categorizzazione biometrica e sistemi manipolativi) sono applicabili dal 2 febbraio 2025. Per il caso d'uso previsto per l'assistenza interna e la ricerca di conoscenze, non è evidente alcun contatto con tali divieti.
6.3 Classificazione come sistema di IA ad alto rischio (allegato III)
Un assistente interno all'IA per il lavoro di testo e la ricerca delle conoscenze tecniche non rientra nei casi d'uso ad alto rischio elencati nell'allegato III del regolamento sull'IA (compresa la selezione del personale, la valutazione del merito di credito, l'identificazione biometrica e la gestione delle infrastrutture critiche). Finché è rispettata la delimitazione di cui al capitolo 2.3, il caso d'uso non è ad alto rischio.
Nota: Indipendentemente da ciò, il cosiddetto "omnibus digitale sull'IA", un accordo politico raggiunto dal Consiglio e dal Parlamento europeo il 7 maggio 2026, ha comunque tutti gli obblighi per i sistemi di IA ad alto rischio autonomi di cui all'allegato III dall'agosto 2026 al 2°. dicembre 2027 rinviato (prodotti dell'allegato I: 2 agosto 2028). L'adozione formale di tale documento nella Gazzetta ufficiale dell'UE era in sospeso (agosto 2026); Fino alla pubblicazione finale, il programma originale continuerà ad applicarsi formalmente. Per il caso d'uso qui descritto, questo è comunque secondario, in quanto non esiste una classificazione ad alto rischio.
6.4 Obblighi già in vigore
Articolo 4 del regolamento sull'IA – alfabetizzazione in materia di IA: Dal 2 febbraio 2025 i fornitori e gli operatori di sistemi di IA sono tenuti a garantire una competenza sufficiente in materia di IA nel loro personale e in altre persone coinvolte nella gestione e nell'uso dei sistemi di IA per loro conto. Tale obbligo si applica indipendentemente dalle dimensioni dell'impresa ed è sancito nel piano di progetto come compito obbligatorio (formazione di tutti gli utenti prima dell'avvio della produzione) – cfr. capitolo 10, fase 4.
Articolo 53 del regolamento sull'IA – Obblighi in materia di GPAI: I requisiti di trasparenza e documentazione per i modelli di IA per finalità generali sono applicabili dall'agosto 2025 e l'applicazione inizierà nell'agosto 2026. Tali obblighi sono imposti principalmente ai fornitori di modelli (ad esempio gli sviluppatori dei modelli aperti utilizzati), non alla PMI utilizzatrice in quanto operatore.
Articolo 50 del regolamento sull'IA – Obblighi di trasparenza: A decorrere dal 2 agosto 2026 si applica l'obbligo di identificare i contenuti generati o modificati dall'IA, a condizione che siano utilizzati esternamente (ad esempio nei confronti dei clienti). Ciò è pertinente una volta che l'assistente per l'IA è utilizzato per preparare testi rivolti ai clienti e dovrebbe essere disciplinato nella direttiva sull'utilizzo dell'IA (capitolo 4.9).
6.5 Conclusione
Gli obblighi giuridici diretti ai sensi della normativa dell'UE sull'IA sono gestibili per il caso d'uso previsto. Il compito concreto più importante consiste nel garantire la competenza in materia di IA conformemente all'articolo 4 del regolamento sull'IA mediante la formazione. Gli elementi di governance che hanno comunque senso per la legge sull'IA (ruoli, valutazione del rischio, documentazione, trasparenza) sono in gran parte in linea con i requisiti della norma ISO/IEC 42001 (capitolo 7) e dovrebbero essere costruiti in modo sinergico.
7. ISO/IEC 42001 – Percorso verso la certificazione
7.1 Cos'è la ISO/IEC 42001?
ISO/IEC 42001:2023 è il primo standard internazionale per un sistema di gestione dell'intelligenza artificiale (AIMS). Segue ISO 9001 (qualità ) e ISO/IEC 27001 (sicurezza delle informazioni) della struttura di alto livello (HLS) degli standard del sistema di gestione ISO ed è strutturato secondo il ciclo PDCA (Plan-Do-Check-Act). Lo standard è applicabile in tutti i settori ed è progettato per le organizzazioni di tutte le dimensioni che sviluppano, gestiscono o utilizzano sistemi di IA.
7.2 Vantaggi per l'azienda
- Prove strutturate di un uso responsabile e controllato dell'IA nei confronti dei clienti, in particolare nei confronti dei partner fornitori e delle amministrazioni aggiudicatrici di maggiori dimensioni, dove la norma ISO 42001 è sempre più richiesta come criterio di gara o segnale di fiducia.
- Preparazione sistematica dei futuri obblighi previsti dalla normativa dell'UE sull'IA: La documentazione AIMS (valutazione del rischio, ruoli, controlli) può essere riutilizzata per la prova di conformità .
- Sinergie con i sistemi di gestione esistenti: Le aziende di tecnologia di misura spesso hanno già un sistema di gestione della qualità secondo ISO 9001 o / e ISO / IEC 17025 (laboratori di calibrazione), la struttura HLS consente un'ampia integrazione invece di un sistema parallelo.
- Impatto interno: Responsabilità chiare e processi documentati riducono il rischio di uso improprio, violazioni dei dati e perdita di conoscenze in una PMI di queste dimensioni.
7.3 Definire l'ambito di applicazione (ambito di applicazione)
Raccomandazione per l'ambito di applicazione della certificazione: "Fornitura e gestione di un sistema interno di assistenza all'IA ospitato in loco basato su Open WebUI e modelli linguistici gestiti a livello locale, compresa la ricerca delle conoscenze basata sul recupero (RAG) per i dipendenti dell'azienda in loco [ubicazione]". Un ambito ristretto e realistico accelera in modo significativo la certificazione su un AIMS a livello di impresa per tutte le applicazioni di IA immaginabili.
7.4 Tabella di marcia per la certificazione
Per una PMI di queste dimensioni dovrebbe essere preso in considerazione un lasso di tempo realistico di circa 9-12 mesi fino alla scadenza della certificazione (i riferimenti indicano 6-18 mesi a seconda del punto di partenza). La tabella di marcia è suddivisa in cinque fasi chiave sancite nel piano di fase (capitolo 10):
| passo | contenuto | risultato |
| 1. Analisi del divario | Confronto tra lo stato effettivo e i capitoli 4-10 e l'allegato A della norma ISO/IEC 42001 | Elenco delle misure con priorità |
| 2. Team di progetto & Governance | Nomina del titolare del trattamento AIMS, adozione della politica in materia di IA | Politica in materia di IA, matrice dei ruoli |
| 3. Valutazione del rischio | Valutazione del rischio e dell'impatto specifica per l'IA per caso d'uso | Registro dei rischi (capitolo 11) |
| 4. documentazione | Manuale AIMS, istruzioni procedurali, prove (formazione, audit) | Documentazione completa AIMS |
| 5. Revisione degli audit interni & | Audit interno, riesame della direzione, azioni correttive | Relazione di audit, approvazione per la certificazione |
7.5 Requisiti chiave a colpo d'occhio
Come per la ISO 9001/27001, la norma è suddivisa in sette capitoli principali:
- Contesto dell'organizzazione (capitolo 4): Parti interessate, definizione dell'ambito di applicazione.
- Leadership (capitolo 5): Politica, ruoli e responsabilità in materia di IA, spesso con ruoli doppi per 12 dipendenti (cfr. capitolo 9).
- Pianificazione (capitolo 6): Rischi e opportunità , obiettivi dell'IA, valutazione dell'impatto dell'IA per sistema.
- Sostegno (capitolo 7): Risorse, competenze (interfaccia con l'articolo 4 del regolamento sull'IA), sensibilizzazione, comunicazione, informazioni documentate.
- Operazione (capitolo 8): pianificazione operativa e gestione del ciclo di vita dell'IA, gestione di fornitori/terzi.
- Valutazione delle prestazioni (capitolo 9): Monitoraggio, audit interno, revisione della gestione.
- Miglioramento (capitolo 10): Affrontare le non conformità , il miglioramento continuo.
Inoltre, l'allegato A definisce controlli specifici (ad esempio sulla direttiva sull'IA, sulla gestione delle risorse, sui dati per i sistemi di IA, sulla trasparenza nei confronti dei portatori di interessi, sull'uso di componenti di terze parti/open source come i modelli Ollama e sulla valutazione degli impatti sociali). Questi controlli devono essere mappati 1:1 all'architettura tecnica descritta nel capitolo 8.
7.6 Processo di certificazione
- Audit della fase 1: Esame dei documenti da parte dell'organismo di certificazione (audit del manuale AIMS, della politica in materia di IA, del registro dei rischi, delle istruzioni procedurali).
- Audit della fase 2: Prove di efficacia in loco o a distanza (interviste, campionamento, verifica tecnica dei controlli effettuati).
- Rilascio di certificati in caso di esito positivo dell'audit, validità normalmente di 3 anni.
- Audit annuali di sorveglianza per il mantenimento del certificato.
- Audit di ricertificazione al termine del ciclo triennale.
7.7 Scelta dell'organismo di certificazione
Si raccomanda di commissionare solo un organismo di certificazione accreditato dall'organismo di accreditamento tedesco (DAkkS) o un organismo di accreditamento europeo equivalente (ad esempio società TÜV, DNV, DEKRA o fornitori comparabili). La selezione concreta dovrebbe essere effettuata attraverso almeno due o tre offerte comparative, compresa l'esperienza con le PMI e le imprese manifatturiere).
8. Architettura tecnica e implementazione
La base tecnica segue l'approccio proposto dall'azienda (Open WebUI + Ollama, Docker-based) ed è integrata dalle garanzie necessarie per una configurazione sicura e certificata delle PMI.
8.1 Architettura di destinazione
Si consiglia una distribuzione Docker Compose su un server dedicato fisicamente nell'azienda (in alternativa: Mini Server/Mac Mini Class per l'ingresso, con possibilità di aggiornamento). Il backend LLM non richiede una connessione Internet in uscita per l'operazione di base. Un'operazione in gran parte netzisolierte ("air-gap-close") è possibile e raccomandata anche dal punto di vista della protezione dei dati e della sicurezza.
8.2 Panoramica dei componenti
| componente | funzione | Raccomandazione per il progetto |
| Apri WebUI | Frontend, gestione utenti/diritti, interfaccia RAG | Eseguire versione-pinned (nessun tag «:main»), aggiornamenti controllati regolari |
| Ollama | runtime del modello locale | Selezione del modello secondo il Capitolo 8.4, nessuna connessione cloud automatica |
| Database vettoriale (RAG) | Stoccaggio/ricerca nella base di conoscenze | Inizia con ChromaDB integrato; Considerare Qdrant come lo stock di documenti cresce |
| Proxy inverso (nginx/Caddy) | Accesso crittografato e controllato nella rete aziendale | Certificato TLS, accesso solo da rete interna/VPN |
| Gestione degli utenti | autenticazione | Se possibile, connessione alla directory esistente (ad esempio tramite SSO/LDAP), altrimenti conti individuali per dipendente |
8.3 Pianificazione hardware
Per 12 utenti con uso prevalentemente sequenziale (nessuna operazione di massa ad alto carico), un server con una GPU consumer-prosumer (ad esempio classe RTX 4000/4060 Ti 16 GB o comparabile) è solitamente sufficiente per modelli nell'intervallo di 7-14 miliardi di parametri in forma quantificata. Per requisiti di qualità più elevati o un uso più simultaneo, una GPU con più VRAM (24 GB +) dovrebbe essere preventivata. Il funzionamento puro della CPU è possibile, ma notevolmente più lento per l'uso produttivo con più utenti simultanei e non è raccomandato. Il dimensionamento del calcestruzzo dovrebbe essere convalidato dopo una breve fase pilota (fase 3) sulla base del carico effettivo all'uso.
8.4 Selezione del modello - Criteri
La selezione concreta del modello è una decisione tecnica nel corso del progetto, ma dovrebbe essere effettuata e documentata sulla base dei seguenti criteri (rilevanti anche per l'allegato A della norma ISO 42001, "Dati per i sistemi di IA"):
- Pesi modello aperti e chiaramente autorizzati (controllare i termini di licenza per uso commerciale).
- Qualità in tedesco e in contesti tecnico-tecnici (terminologia tecnica di misurazione).
- Requisiti di risorse per abbinare l'hardware disponibile (vedere 8.3).
- Origine rintracciabile e storia di aggiornamento/supporto del fornitore del modello (l'obbligo di documentazione di cui all'articolo 53 del regolamento sull'IA si applica al fornitore, ma dovrebbe fungere da criterio di selezione per l'operatore).
- Nessuna telemetria automatica o contatto con server esterni in funzionamento regolare.
8.5 Concetto di sicurezza
- Segmentazione della rete (propria VLAN per il server AI), nessun accesso diretto a Internet al backend.
- Accesso solo tramite proxy inverso protetto con certificato TLS, idealmente accessibile solo dalla rete interna o tramite VPN aziendale.
- Concetto di ruolo/diritti: Ruolo di amministratore limitato ai responsabili IT, utenti standard senza accesso alla configurazione del sistema.
- Registrazione di eventi rilevanti per la sicurezza con un periodo di conservazione definito e conforme alla protezione dei dati.
- Backup regolari e controllati (principio 3-2-1 raccomandato) e processo di ripristino documentato.
- Processo di patch e aggiornamento definito per tutti i componenti (Open WebUI, Ollama, sistema operativo, immagini di base del contenitore).
- Tali misure sono sostanzialmente in linea con le misure volontarie di base della NIS2 (capitolo 5.4) e con i requisiti di cui all'articolo 32 GDPR (capitolo 4.6).
8.6 Controllo e disattivazione delle funzionalità critiche del cloud
Open WebUI offre numerose estensioni opzionali (fornitori di ricerca web esterni, generazione di immagini esterne, servizi voce / trascrizione esterni, modelli cloud come opzione aggiuntiva). Queste funzioni sono efficienti, ma contraddicono il concetto di protezione on-premise e dei dati di questo progetto non appena trasmettono dati personali o riservati a terzi.
Nota: Raccomandazione: Disabilita tutte le estensioni esterne / basate su cloud nell'interfaccia di amministrazione per impostazione predefinita. Se le singole funzioni cloud devono comunque essere utilizzate in futuro (ad esempio una ricerca web esterna per ricerche non riservate), ciò deve essere valutato in anticipo ai sensi del diritto in materia di protezione dei dati (contratto di trattamento dei contratti, valutazione d'impatto del trasferimento, se applicabile in relazione a paesi terzi) ed esplicitamente disciplinato dalla direttiva sull'utilizzo dell'IA.
9. Organizzazione e ruoli del progetto
In un'azienda con 12 dipendenti, una separazione completa di tutti i ruoli tra persone diverse non è realistica. Tuttavia, ISO / IEC 42001 richiede responsabilità chiaramente documentate, anche se una persona svolge più ruoli nell'unione personale. Il fattore decisivo è la fissazione scritta, non il numero di teste.
| ruolo | responsabilità | Raccomandazione per la nomina (12-MA-SME) |
| Gestione / gestione del progetto | Responsabilità generale, politica di rilascio dell'IA, bilancio | gestione |
| Gestore/i di AIMS/AI | Impostazione e manutenzione del sistema di gestione dell'IA, referente per gli audit | Dirigente o dirigente nominato, se necessario con supporto esterno |
| Amministrazione informatica | Funzionamento tecnico, configurazione di sicurezza, gestione delle patch | Responsabilità IT interna o fornitore esterno di servizi IT |
| Persona di contatto per la protezione dei dati / DSB | DSFA, directory di elaborazione, richieste dell'interessato | Raccomandato il responsabile della protezione dei dati nominato esternamente (cfr. capitolo 4.4) |
| Utenti chiave/moltiplicatori | Feedback tecnico da parte dei reparti, supporto alla formazione | 1–2 professionisti esperti |
| Consulenza esterna ISO 42001 (opzionale) | Analisi delle lacune, preparazione dell'audit | Partecipare caso per caso, in particolare prima dell'audit della fase 1 |
Piano di fase e tappe fondamentali
Il periodo totale fino alla scadenza della certificazione è di circa 10-12 mesi. Diverse fasi sono deliberatamente in corso in parallelo al fine di rappresentare realisticamente le limitate capacità del personale di un'operazione di 12 persone. Lo sviluppo dell'AIMS (fase 5) inizia già durante l'attuazione tecnica e giunge fino alla maturità dell'audit interno.
| # | Fase | mese | Principali risultati |
| 0 | Iniziazione del progetto & scoping | 1 | Ordine del progetto, definizione dell'obiettivo, definizione dell'ambito ISO 42001, approvazione del bilancio |
| 1 | Lavoro giuridico di base | 1–2 | DSFA, chiarimento dell'obbligo DSB, directory di elaborazione, controllo breve NIS2, politica di utilizzo dell'IA (progetto) |
| 2 | Concetto tecnico & Appalti | 2–3 | Selezione hardware, concetto di rete/sicurezza, selezione del modello, approvvigionamento |
| 3 | Attuazione dell'operazione pilota & | 3-4 | Aprire WebUI/Ollama, configurazione RAG, operazione di test con il gruppo principale |
| 4 | Formazione su Rollout & | 4-5 | Formazione di tutti i dipendenti (compreso l'articolo 4 del regolamento sull'IA), diffusione produttiva, direttiva sull'utilizzo dell'IA finale |
| 5 | Struttura AIMS secondo ISO 42001 | 3-8 | Politica in materia di IA, matrice dei ruoli, registro dei rischi, documentazione (corre in parallelo dall'inizio del progetto pilota) |
| 6 | Revisione interna della gestione di & | 8-9 | Audit interno, azioni correttive, approvazione da parte della direzione |
| 7 | Audit di certificazione (fase 1 + 2) | 9-11 | Selezione dell'organismo di certificazione, esame dei documenti, audit in loco/a distanza |
| 8 | Emissione del certificato & Operazione | da 11 a 12 | Certificato, funzionamento continuo, audit di monitoraggio annuale, miglioramento continuo |
11. Gestione del rischio
Il seguente registro dei rischi costituisce anche una componente della valutazione dei rischi richiesta dalla norma ISO/IEC 42001, capitolo 6, e dovrebbe essere costantemente aggiornato nel corso del progetto.
| rischio | categoria | E' vero. | impatto | misura |
| Attivazione accidentale di plugin cloud (ricerca web, API esterna) | privacy | appropriazione | Alto | Configurazione dell'amministratore del blocco, politica di utilizzo dell'IA, controllo regolare della configurazione |
| Scarsa accettazione da parte dei dipendenti | Organizzazione | appropriazione | appropriazione | Coinvolgimento precoce, formazione comprensibile, utenti chiave come moltiplicatori |
| Prestazioni hardware insufficienti nella pratica | tecnica | appropriazione | appropriazione | Fase pilota per la convalida del carico prima dell'espansione completa, pianificazione hardware scalabile |
| Know-how / deflusso segreto tramite input rapidi nella futura espansione del cloud | Protezione dei dati / GeschGehG | Basso (conformemente al punto 8.6) | Alto | Disattivazione tecnica, politica chiara, formazione sugli obblighi di riservatezza |
| Uscite di IA errate nell'interpretazione tecnica dei dati di misurazione (allucinazioni) | Tecnico/qualità | appropriazione | Alto | Obbligo obbligatorio per le prove tecniche prima del riutilizzo, nessun rilascio automatizzato di testi di IA nelle relazioni di prova |
| Ritardo dovuto alla limitata capacità interna (operazione 12-MA) | progetto | Alto | appropriazione | Programmazione realistica, supporto esterno ad hoc per la protezione dei dati e ISO 42001 |
| Deprecazione del modello / interruzione della licenza di un modello aperto usato | tecnica | basso | appropriazione | Selezione del modello di documento, prevedere la modifica del modello alternativo come piano di emergenza |
| Mancato raggiungimento della maturità della certificazione nel periodo previsto | Progetto / certificazione | appropriazione | appropriazione | Analisi precoce del gap, audit interni iterativi invece del big bang prima della fase 1 |
12. Pianificazione dei costi e delle risorse
Le seguenti informazioni sono una linea guida approssimativa basata su larghezze di banda standard di mercato per la consulenza, l'hardware e la certificazione in Germania (a partire dal 2026) e non sostituiscono offerte specifiche. Si raccomanda di ottenere almeno due o tre offerte comparative per le posizioni costose (consultazione, certificazione) prima dell'approvazione del bilancio.
| posizione | digita | Stima approssimativa | osservazione |
| Hardware (server/GPU, componenti di rete) | Unico | circa 3.000 – 12.000 € | a seconda delle dimensioni del modello e del carico dell'utente; Il software stesso è open source (gratuito) |
| Supporto esterno per la configurazione/configurazione informatica (facoltativo) | Unico | circa 1 500 – 5 000 EUR | Configurazione Docker, backup, configurazione RAG, se non coperta internamente |
| Responsabile esterno della protezione dei dati (se non interno) | In corso, annuale | circa 2 000 – 6 000 EUR/anno | a seconda delle dimensioni e del fornitore, per una PMI di tali dimensioni |
| Consulenza esterna ISO 42001 (analisi Gap, preparazione audit) | Unico | circa 4 000 – 15 000 EUR | fortemente dipendente dalle conoscenze pregresse interne e dai sistemi di gestione esistenti (ad esempio ISO 9001) |
| Audit di certificazione (fase 1 + 2) | Una tantum, poi annualmente (monitoraggio) | circa 4 000 – 10 000 EUR | a seconda dell'organismo di certificazione e dell'ambito di applicazione; Gli audit annuali di monitoraggio sono meno costosi |
| Formazione dei dipendenti (competenza in materia di IA, utilizzo) | Unico + in corso | circa 1.000 – 3.000 € | Può essere effettuata in parte internamente. |
| Tempo interno del personale (gestione del progetto, IT, dipartimenti) | Continuamente per tutta la durata del progetto | Non quantificato in euro | Fattore significativo per 12 dipendenti - è necessaria una pianificazione realistica della capacità |
13. Criteri di successo
- Tutti i 12 dipendenti sono formati e utilizzano attivamente l'assistente AI per almeno un caso d'uso documentato.
- Non sono stati segnalati incidenti relativi alla protezione dei dati o alla segretezza connessi all'uso dell'IA.
- La directory di elaborazione, la DSFA e la politica di utilizzo dell'IA sono completamente documentate e aggiornate.
- Completamento con successo degli audit delle fasi 1 e 2 e rilascio del certificato ISO/IEC 42001 entro i tempi previsti.
- Feedback positivo dei dipendenti sull'usabilità (ad esempio tramite una breve indagine interna dopo 1 e 3 mesi di attività produttiva).
- Risparmio di tempo dimostrabile in almeno un caso d'uso definito (ad esempio ricerca documentale, bozze di testi, casi di supporto standard).
14. Prossime tappe (primi 30 giorni)
- Approvare formalmente l'ordine del progetto da parte della direzione, definire approssimativamente il budget.
- Nominare manager AIMS/AI (possibile anche in unione personale con il management).
- Contattare consulenti legali o consulenti esterni per la protezione dei dati per l'esame preliminare DSFA e il chiarimento dell'obbligo DSB.
- Effettuare e documentare il controllo breve NIS2 (allegato A) internamente, in particolare verificare il fatturato annuo/totale di bilancio rispetto alle soglie.
- Catturare i requisiti tecnici iniziali (numero di utenti, casi d'uso desiderati, hardware esistente) e ottenere offerte per l'hardware del server.
- Avviare un'approfondita indagine di mercato presso gli organismi di certificazione ISO/IEC 42001 e, se necessario, le società di consulenza (confronto delle offerte).
- Incontro iniziale con tutti i dipendenti per l'annuncio del progetto e il chiarimento delle aspettative.
15. appendice
Allegato A – Controllo di applicabilità NIS2
- L'azienda di solito impiega 50 o più persone? (In caso contrario, continuare a controllare)
- Il fatturato annuo supera i 10 milioni di euro o il totale di bilancio supera i 10 milioni di euro? (Se no → NIS2 non è generalmente applicabile)
- La società è l'unico fornitore di un servizio critico per la Germania, fornitore di servizi fiduciari qualificati, fornitore di TLD/DNS, fornitore di telecomunicazioni o classificato come critico ai sensi della legge KRITIS Roofing? (Se no → nessun obbligo speciale indipendente dalle dimensioni)
- Un cliente significativo richiede contrattualmente prove di sicurezza relative a NIS2 nella catena di approvvigionamento? (In caso affermativo → Raccomandazione di orientamenti volontari sulle misure di base della NIS2, indipendentemente dal proprio obbligo)
Allegato B – Preesame DSFA (breve controllo ai sensi dell’articolo 35, paragrafo 3, RGPD/criteri DSK)
- I dati comportamentali o di performance dei singoli dipendenti vengono valutati sistematicamente?
- Le categorie particolari di dati personali (articolo 9 GDPR) sono trattate o conservate nella base di conoscenze?
- È utilizzata una nuova tecnologia con una valutazione del rischio poco chiara (i modelli linguistici di IA sono regolarmente considerati tali)?
- I dati sono trattati o consultabili su larga scala (molti documenti/persone) automaticamente?
- Se più risposte "sì" comportano un aumento del rischio, deve essere effettuato un DSFA o almeno documentato il motivo per cui non è necessario.
Allegato C – Principali basi giuridiche (panoramica)
- Regolamento (UE) 2016/679 (Regolamento generale sulla protezione dei dati, GDPR)
- Legge federale sulla protezione dei dati (BDSG), in particolare §§ 26, 38
- Direttiva (UE) 2022/2555 (direttiva NIS2) e atto di recepimento tedesco NIS2UmsuCG (nuova legge BSI, BSIG-neu), in vigore dal 6. dicembre 2025
- Regolamento (UE) 2024/1689 (regolamento sull'IA/normativa dell'UE sull'IA), in particolare articoli 4, 5, 50 e 53
- Digital Omnibus on AI → accordo politico del 7 maggio 2026 sul rinvio del termine per gli obblighi ad alto rischio (in attesa di adozione formale a partire dall'agosto 2026)
- ISO/IEC 42001:2023 → Sistema di gestione dell'intelligenza artificiale
- Legge per la protezione dei segreti commerciali (GeschGehG)
- Legge sulla costituzione dei lavori (BetrVG), in particolare articolo 87, paragrafo 1, punto 6 (se esiste un comitato aziendale)