| Organizzazione Aziendale - Antiriciclaggio (D.Lgs. 231/07) |
Le nuove soglie per assegni e contanti in seguito alle modifiche della normativa antiriciclaggio.
Il decreto legge n. 78 del 31 maggio 2010 (convertito in legge con modifiche dalla legge n. 122 del 30 luglio 2010) fissa delle nuove soglie in materia di antiriciclaggio. Al fine di una più agevole consultazione, anche in riferimento alla circolare interpretativa, ne viene riportato un riassunto schematico. Nello schema non vengono riportate le sanzioni aggiornate. Si rimanda, comunque, al testo aggiornato del D.Lgs. 231/2007 per i dettagli.
Il trasferimento di contanti e/o titoli al portatore tra soggetti diversi è consentito solo quando il valore del trasferimento è inferiore a 5.000 euro. Non è consentito il frazionamento artificioso.
Assegni bancari, postali, circolari ecc. possono essere emessi in forma libera per importi inferiori a 5.000 euro. Rimane inalterata l'imposta di bollo 1,50 euro e la richiesta in forma scritta per avere la forma libera.
La soglia fissata è da intendersi per il singolo assegno. Non è previsto il cumulo di assegni (anche se nella stessa transazione) al fine di calcolare l'importo totale del trasferimento.
| Organizzazione Aziendale - Trattamento dati personali |
L'allegato B) al decreto legislativo del 30 giugno 2003 n. 196 consiste in un disciplinare tecnico che detta le misure minime di sicurezza in materia di trattamento dei dati personali.
Il disciplinare tecnico è suddiviso in due parti fondamentali: la prima è relativa ai trattamenti che avvengono con l'utilizzo di strumenti elettronici mentre la seconda riguarda il caso complementare, ossia quei trattamenti che avvengono, invece, senza l'ausilio di strumenti elettronici.
Le misure descritte nel disciplinare sono le misure minime richieste ed è opportuno che non vengano violate se non si vuole incorrere nel rischio di una sanzione da parte del Garante per la protezione dei dati personali.
Tutte le misure descritte nel disciplinare tecnico hanno un'applicabilità generale ma possono essere soggette a delle semplificazioni a seguito di provvedimenti del Garante stesso. Si cita, in particolare, il provvedimento del 27 novembre 2008 "Semplificazione delle misure di sicurezza contenute nel disciplinare tecnico di cui all'allegato B) al codice in materia di protezione dei dati personali". In questo provvedimento il Garante individua due tipologie di soggetti che possono ricorrere a misure semplificate. Tale provvedimento sarà oggetto di un successivo articolo, in quanto il presente si focalizza sulle misure minime valide in generale.
Trattamenti con strumenti elettronici
Nei casi in cui il trattamento dei dati personali avviene con l'utilizzo di strumenti elettronici è necessario che siano tenute in considerazione una serie di misure atte a prevenire violazioni della sicurezza dei dati trattati. In particolare è necessario che venga redatto un Documento Programmatico sulla Sicurezza (DPS) e che vengano prese determinate misure relativamente ai sistemi di autenticazione informatica e al sistema di autorizzazione.
Il sistema di autenticazione informatica
Il trattamento dei dati personali con sistemi informatici è consentito solo ad operatori dotati di specifiche credenziali di autenticazione. Tali credenziali devono consistere in un codice identificativo dell'operatore e in una parola chiave conosciuta solamente dall'incaricato. Tale parola chiave può essere, eventualmente, sostituita dall'utilizzo di un dispositivo di autenticazione che sia in possesso o in uso esclusivo all'incaricato, così come da uno o più caratteristiche biometriche dell'operatore stesso. Queste misure possono essere tra loro combinate (ossia, ad esempio, caratteristica biometrica e parola chiave).
Ogni incaricato può avere una o più credenziali per l'autenticazione e deve prestare particolare attenzione a mantenere segreta la componente riservata di tali credenziali e custodire i dispositivi di autenticazione. Di tale aspetto dovranno tenere conto le istruzioni che devono essere impartite agli incaricati, in modo che le misure assunte da ciascun operatore siano più che sufficienti per evitare utilizzi non autorizzati delle credenziali di un operatore.
Il disciplinare tecnico descrive dettagliatamente le misure minime relative alla parola chiave, quando prevista: deve essere composta da almeno otto caratteri oppure, nel caso in cui vi sia una limitazione del sistema utilizzato che impedisca tale lunghezza, deve essere pari alla lunghezza massima gestibile dal sistema. La parola chiave non deve essere facilmente riconducibile all'incaricato e deve essere modificata da quest'ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi. Quest'ultimo periodo, nel caso di trattamento di dati sensibili o di dati giudiziari, è ridotto a tre mesi.
Il codice identificativo dell'incaricato, ove utilizzato, non potrà essere assegnato ad altri incaricati neanche in tempi diversi. Di conseguenza ogni codice identificativo dovrà essere gestito in modo che ad operatori diversi siano sempre associati codici identificativi diversi.
Le credenziali di autenticazione devono essere disattivate immediatamente se non sono utilizzate per almeno sei mesi o nel caso in cui l'operatore perda la qualità che gli consente l'accesso ai dati personali (ad esempio per un cambio di mansione). In alcuni casi è consentito il mantenimento attivo di credenziali oltre i sei mesi di inattività se utilizzate per soli scopi di gestione tecnica e previa specifica autorizzazione. Sebbene il disciplinare non preveda nulla di specifico in merito, è opportuno che tali credenziali siano ridotte al minimo e, possibilmente, non utilizzate del tutto, mantenendole comunque sotto uno strettissimo controllo per evitare abusi e rischi di varia natura per la sicurezza.
Gli incaricati devono essere opportunamente edotti sulla necessità di non lasciare incustodito e accessibile lo strumento elettronico utilizzato per il trattamento dei dati. Il disciplinare, su questo tema, regolamenta il solo caso di una sessione di trattamento dati in corso. E comunque opportuno, in generale, a prescindere dalla disponibilità di una sessione per il trattamento dati o meno, che i sistemi non siano lasciati incustoditi né resi accessibili (in particolare ciò vale per i dispositivi portatili).
Un altro aspetto molto importante è quello di garantire l'accesso ai dati nel caso di indisponibilità dell'operatore. Tale indisponibilità può derivare sia da una prolungata assenza sia da un impedimento dell'incaricato e viene affrontata mediante la definizione di credenziali di riserva. Il disciplinare prevede che la gestione di tali credenziali avvenga con un'organizzazione tale da garantirne la sicurezza e mediante l'identificazione per iscritto dei soggetti incaricati della loro custodia che, tra l'altro, dovranno informare tempestivamente l'incaricato dell'eventuale intervento effettuato.
Tutte le disposizioni in tema di autenticazione (e anche quelle relative all'autorizzazione) non si applicano a trattamenti dati personali che prevedano la diffusione dei dati stessi.
Il sistema di autorizzazione
Il disciplinare affronta in una sezione apposita la problematica di gestire le autorizzazioni che gli incaricati del trattamento dovranno avere nel caso in cui esse possano differire da un incaricato all'altro. In pratica, se esiste un'unica tipologia di incaricato, anche se applicata a numerosi operatori, non è necessario definire un sistema di autorizzazione. Nel caso in cui, invece, vengano definiti dei profili di autorizzazione differenti è necessario un sistema di autorizzazione.
Il sistema di autorizzazione porterà ad individuare e configurare i profili di autorizzazione anteriormente all'inizio del trattamento, con l'obiettivo di limitare l'accesso ai soli dati necessari per effettuare le operazioni di trattamento.
Il sistema di autorizzazione garantirà, inoltre, almeno con cadenza annuale, la verifica della sussistenza delle condizioni per la conservazione dei profili di autorizzazione.
Ulteriori misure di sicurezza
Il disciplinare prevede che, nell'ambito dell'aggiornamento periodico con frequenza minima annuale, finalizzato all'individuazione dell'ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici, la lista degli incaricati può essere redatta anche per classi omogenee di incarico e dei relativi profili di autorizzazione.
I dati personali devono essere protetti contro il rischio d’intrusione e dall'azione di malware (nel senso dettato dall'articolo 615-quinquies del codice penale, ossia “[omissis] programma informatico [omissis] avente per scopo o per effetto il danneggiamento di un sistema informatico o telematico, dei dati o dei programmi in esso contenuti o ad esso pertinenti, ovvero l'interruzione, totale o parziale, o l'alterazione del suo funzionamento [omissis]”). Ciò viene realizzato mediante l'utilizzo di idonei strumenti elettronici (ad esempio software antivirus) da mantenersi aggiornati con frequenza almeno semestrale. La frequenza indicata nel disciplinare è, in generale, da ritenersi troppo bassa e il suggerimento è quello di aumentarla ad una frequenza settimanale o, ancor meglio, giornaliera, nella maggior parte dei casi.
Anche l'aggiornamento periodico dei programmi per elaboratore finalizzato a prevenire la vulnerabilità degli strumenti elettronici e a correggerne i difetti deve essere effettuato con frequenza almeno annuale (semestrale nel caso di trattamento di dati sensibili al giudiziari). Anche in questo caso è ritenuto troppo lungo il lasso di tempo fissato dal disciplinare e si ritiene opportuno consigliarne la riduzione portandolo, come minimo, su base mensile o settimanale. Nei casi di sistemi esposti su rete pubblica (Internet) l'aggiornamento può essere effettuato anche più volte al giorno. In ogni caso è però necessario tenere in considerazione i rischi legati a tale aggiornamento e valutarne la frequenza più opportuna, oltre alle modalità di recupero della configurazione precedente nel caso in cui un aggiornamento introducesse delle regressioni tali da rendere il sistema al rischio sicurezza o instabile.
Il disciplinare prevede, infine, che vengano impartite dalle istruzioni organizzative tecniche in grado di consentire il salvataggio dei dati con una frequenza almeno settimanale. Anche in questo caso il suggerimento è di utilizzare frequenze più stringenti che di norma consistono nell'effettuare un backup incrementali giornaliero e uno integrale settimanale, raggiungendo un eccellente compromesso tra l'impiego di risorse per il backup, la sua frequenza e il rispetto della normativa.
Documento programmatico sulla sicurezza
Il disciplinare tecnico prevede la redazione, con riesame annuale entro il 31 marzo di ogni anno, di un documento detto "Documento Programmatico sulla Sicurezza" o DPS. Questo documento deve essere redatto dal Titolare del trattamento di dati sensibili o giudiziari e può avvenire anche attraverso il Responsabile del trattamento nel caso in cui sia stato designato.
| Ingegneria Logistica - Analisi Logistiche |
Il processo di acquisizione secondo la MIL-HDBK-502
In questo articolo viene iniziata la trattazione del rapporto che esiste tra il processo di acquisizione e l'ingegneria di sistema secondo quanto indicato nella norma MIL-HDBK-502 “Acquisition Logistics”.
La logistica dell'acquisizione viene definita come una disciplina tecnico gestionale multifunzionale associata con la progettazione, lo sviluppo, il test, la produzione, il passaggio operativo, il mantenimento e le modifiche migliorative relative ad un sistema economicamente sostenibile in grado di soddisfare i requisiti di prontezza dell'utente, sia in tempo di pace sia in tempo di guerra.
Sebbene la norma sia una norma militare e tratti di aspetti legati comunque ad un contesto bellico, è importante sottolineare che i principi, molti dei processi e i risultati ottenibili seguendo quanto indicato nella MIL-HDBK-502 possono essere facilmente, e con grande vantaggio, applicati ad altre realtà che abbiano le seguenti caratteristiche:
- significativa complessità del sistema
- alternanza di periodi operativi con requisiti molto più performanti e di periodi di riposo con requisiti più permissivi
- vita attesa del sistema significativamente lunga
- rapporto costo prestazioni desiderato il più ottimale possibile
In sistemi con queste caratteristiche è molto proficuo applicare la norma suddetta, mutatis mutandis, in particolare se ciò avviene nel settore aerospaziale così come in quello navale o in quello degli impianti industriali.
I principali obiettivi della logistica dell'acquisizione sono garantire che:
- i requisiti del supporto divengano parte dei requisiti di progettazione del sistema
- il costo del supporto del sistema attraverso il suo ciclo di vita sia sostenibile dal punto di vista economico
- tutti gli elementi di infrastruttura necessari, sia per le prime attività sul campo sia per il supporto operativo del sistema, vengano identificati, sviluppati e acquisiti per tempo
Come si può notare questi obiettivi sono comuni a praticamente tutti i sistemi complessi o critici e questo rende la norma un'utile fonte di informazioni e di riflessioni in moltissimi casi, soprattutto se si considera che la frazione più significativa del costo del ciclo di vita di un sistema è in genere relativa ai costi operativi e di supporto una volta che il sistema è stato dispiegato sul campo. Poiché tali costi sono fortemente determinati già nelle prime fasi di sviluppo del sistema è indispensabile che gli sviluppatori siano in grado di valutarli il più anticipatamente possibile, esaminando anche i costi operativi di supporto di differenti soluzioni progettuali.
La logistica dell'acquisizione è molto più efficace se le attività relative vengono svolte coinvolgendo sia il Cliente (nella norma riferito come il Governo) sia il Fornitore in tutti i processi gestionali e tecnici dell'ingegneria di sistema. La ragione di questo vantaggio è insita nella possibilità di trovare rapidamente i migliori compromessi possibili che necessariamente andranno definiti per poter soddisfare tutti i vincoli operativi e gli obiettivi del processo di acquisizione.
Il processo di acquisizione dei sistemi per la Difesa (secondo il DoD)
Il processo di acquisizione di un sistema secondo la norma deve innanzitutto tenere in considerazione il ciclo di vita di un sistema. Esso deve inoltre prendere in considerazione il fatto che la sua natura è intrinsecamente ciclica in quanto, molto spesso, l'acquisizione di un nuovo sistema deriva dall'incapacità del suo predecessore di soddisfare determinati requisiti operativi, economici o di altra natura. Di conseguenza è opportuno immaginare il processo dell'acquisizione come una serie di iterazioni in cui un sistema viene sostanzialmente migliorato nelle proprie capacità o sostituito da uno o più performante.
In quest'ottica tutte le informazioni acquisite nel ciclo di vita del sistema precedente possono essere molto utili per lo sviluppo del nuovo sistema.
Oltre ad essere ciclico, il processo di acquisizione deve essere sufficientemente flessibile da poter affrontare l'ampia gamma di potenziali soluzioni a fronte di evidenti necessità, opportunità o carenze emerse durante il ciclo di vita.
Ai fini della Logistica dell'Acquisizione, nel processo di acquisizione le analisi di supportabilità diventano un aspetto importantissimo e dovranno essere condotte con due obiettivi fondamentali:
- garantire che la supportabilità sia a tutti gli effetti un requisito prestazionale del sistema
- assicurare la definizione di un'infrastruttura e di un progetto del sistema ottimali dal punto di vista del supporto
Le analisi di supportabilità che dovranno essere eseguite saranno ovviamente molto diverse da caso a caso e da fase a fase.
Allo scopo di governare il processo di acquisizione è necessario che sia definito un processo di gestione dell'acquisizione. Grazie al processo di acquisition management, il processo di acquisizione verrà suddiviso, come anticipato, in fasi di logiche sequenziali, ciascuna con specifici obiettivi e specifiche questioni da affrontare, in genere correlate con uno degli stati ingegneristici di progettazione. Una fase potrà dirsi conclusa quando avrà fornito una risposta a tutte le questioni in essa previste e avrà raggiunto tutti gli obiettivi desiderati. Completata una fase si potrà passare alla successiva.
Il passaggio da una fase all'altra è però sottoposto a dei punti decisionali in cui vengono effettuati dei riesami a livello di intero sistema che valuteranno se la fase precedente è stata completata con successo o meno e permetteranno di stabilire se passare alla fase successiva o ritornare su quella che si pensava appena completata.
Come può essere facilmente intuibile, il numero e le caratteristiche delle fasi varieranno da programma a programma e la loro definizione è uno dei primi obiettivi del processo di management.
Le tipologie di acquisizione
In genere le acquisizioni vengono classificate in base alla complessità dell'attività progettuale che richiedono per completare un sistema. Molto spesso si usano quattro tipologie base che sono, in ordine crescente di preferenza (per il DoD):
- di un sistema esistente
- acquisizione di un componente commerciale
- acquisizione di un componente non-developmental (NDI o non-developmental item), ossia di un oggetto già sviluppato in precedenza
- sviluppo ex novo
Stabilire il tipo corretto di programma di acquisizione da implementare è il primo e il più importante passo nella determinazione dei quali attività dell'ingegneria di sistema dovranno essere incluse nella strategia di un programma di acquisizione.
Per effettuare tale scelta la norma propone un processo decisionale (acquisition decision process) così fatto:
- vengono identificati i requisiti operativi
- ci si chiede se tali requisiti richiedano un qualche equipaggiamento o una qualche fornitura (nel gergo militare e in quello logistico ciò viene indicato come “Materiel”). Se la risposta è no significa che non è necessario un processo di acquisizione e quindi il processo decisionale termina
- se invece necessario acquisire un materiel si verifica se già esiste un sistema che soddisfi o possa soddisfare i requisiti richiesti. In caso affermativo l'acquisizione procede come un'acquisizione d'uso o modifica di un sistema esistente
- in caso contrario viene fatta un'analisi di quanto offre il mercato e si valuta se esiste un componente commerciale in grado di soddisfare i requisiti. Se la risposta è positiva si procede con un iter di acquisto
- in caso contrario si valuta se è disponibile un NDI. In caso affermativo si procede, anche qui, con un processo di acquisto
- in caso contrario si procede con il processo di sviluppo di un sistema ex novo
La preferenza accordata dal DoD ai componenti commerciali rispetto a quelli NDI risiede fondamentalmente sull'aspetto economico che, per molteplici ragioni, è molto più appetibile nel caso dei componenti commerciali. Ovviamente qualora il requisito economico fosse secondario l'ordine di preferenza potrebbe essere differente.
Nel caso in cui il processo decisionale di acquisizione portasse alla scelta di sviluppare un nuovo sistema è comunque opportuno ripetere lo stesso processo decisionale per tutti i componenti dei sottosistemi del nuovo sistema (e via ricorsivamente).
La strategia di acquisizione
A prescindere dalla tipologia di programma di acquisizione identificata, è indispensabile definire una strategia di acquisizione che dettagli i requisiti, l'approccio e gli obiettivi del programma. Lo sviluppo di tale strategia dovrà iniziare immediatamente dopo la definizione della tipologia di acquisizione, ossia al termine del processo decisionale di acquisizione.
Non si vuole, in questo articolo, entrare nel merito di un'eventuale responsabilità penale dell'Organismo di Vigilanza (per omesso impedimento di reato ...), soprattutto in relazione alla normativa in materia di antiriciclaggio che la prevede esplicitamente. Lo scopo di questo testo è la definizione delle modalità operative affinché tale potere di iniziativa abbia la possibilità di essere esercitato con le tre qualità anzidette. Il primo passo è quello di definire quali eventi fungono da trigger dell'iniziativa dell'OdV. Questi eventi possono essere di tre tipologie: notizie generiche, notizie relative a violazioni del modello e notizie di schemi sospetti. Nella categoria delle notizie generiche rientrano:
Si noti la distinzione effettuata tra i mezzi di comunicazione di massa e la Rete in quanto quest'ultima consente una notevole automazione del processo di selezione e filtraggio delle notizie di interesse (si pensi alle potenzialità del servizio Alert di Google, ad esempio). Nelle notizie relative violazioni del modello dovranno essere considerate:
Salvo la disponibilità di fatti oggettivi, è sottinteso che dovranno essere prese in considerazione solo denunce non anonime. Per quanto riguarda le notizie di schemi sospetti si sta qui ipotizzando l'esistenza di un sistema informativo a servizio dell'Organismo di Vigilanza in cui sia possibile, mediante funzioni di data mining o sulla base dell'esperienza, definire degli schemi il cui presentarsi può indicare un sospetto di violazione del modello o di commissione di reati presupposto o ad essi preliminari. Ovviamente l'esistenza di tale sistema informativo non è né obbligatoria né diffusa (anzi, al contrario, è piuttosto rara) sebbene se ne possono trarre enormi vantaggi grazie all'elevata capacità di analisi automatica di tali sistemi. A prescindere da quale notizia si sia acquisita, è necessario che l'Organismo di Vigilanza garantisca sia la corretta analisi sia l'attivazione delle eventuali azioni necessarie. A questo punto l'OdV, ricevuta la notizia, ne effettuerà un'analisi che, in primis, porterà ad un esame dettagliato dei fatti riportati nella notizia, eventualmente eseguendo ispezioni, interviste o altro ancora con i personaggi coinvolti o informati dei fatti. Acquisite tutte queste informazioni aggiuntive, sarà possibile valutare la notizia e stabilire le eventuali azioni da intraprendere. L'ultimo passo sarà quello di archiviare la notizia per tenerne comunque futura memoria, possibilmente in modo da renderla fruibile anche a futuri membri dell'Organismo diversi da quelli attuali. In pratica per ogni notizia si apre un'istruttoria che, come tutte le istruttorie, approfondisce i fatti, ne valuta la validità, definisce le azioni da intraprendere e quindi registra il tutto perché non se ne perda memoria.
La normativa cosiddetta sulla "privacy" è un argomento in cui ci si imbatte molto frequentemente ma, data la complessità della materia, risulta incomprensibile ai più. Ad aggravare la situazione vi sono le numerose raccomandazioni del Garante e le quasi infinite casistiche possibili. Scopo di questo articolo, inizio di una serie sull'argomento, è cercare di dare una prima risposta ai quesiti fondamentali, partendo da una descrizione schematica della legge. Il D.Lgs. 196/03 è conosciuto come "legge sulla privacy". In realtà si tratta di una normativa sulla protezione dei dati personali. Il decreto legislativo 196/03 vede, sostanzialmente, coinvolte quattro tipologie di persone: il Titolare del trattamento dati, il Responsabile del trattamento dati, l'Incaricato del trattamento dati, l'Interessato dal trattamento dati. Queste quattro figure, che discuteremo più nel dettaglio nelle sezioni seguenti, vengono "monitorate" da una quinta figura che è quella del Garante. Il decreto legislativo 196 del 2003 prevede, nel cosiddetto allegato B, un disciplinare tecnico indicante le misure minime di sicurezza da adottarsi. I Dati PersonaliPrima di entrare nel merito del testo è necessario che venga definito il concetto di "dato personale". I dati personali vengono definiti come tutte le informazioni che sono relative a persone, siano esse fisiche o giuridiche, enti o associazioni, che consentano l'identificazione per via diretta o indiretta, di tali soggetti. Questa definizione è fornita dall'art. 4 del decreto, comma 1, lettera b) che recita: “b) "dato personale", qualunque informazione relativa a persona fisica, persona giuridica, ente od associazione, identificati o identificabili, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi compreso un numero di identificazione personale;” Un sottoinsieme molto importante dei dati personali sono i cosiddetti "dati sensibili" che vengono definiti, sempre all'articolo 4 comma 1, come: "d) "dati sensibili", i dati personali idonei a rivelare l'origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l'adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale, nonche' i dati personali idonei a rivelare lo stato di salute e la vita sessuale" Per questi dati anticipiamo sin d'ora che le condizioni per il loro trattamento (con l'esclusione degli enti pubblici che seguono modalità differenti) sono tre:
Un'altra categoria che costituisce un sottoinsieme dei dati personali è quella comunemente nota come "dati giudiziari" che viene definita, sempre all'articolo quattro comma numero uno: “e) "dati giudiziari", i dati personali idonei a rivelare provvedimenti di cui all'articolo 3, comma 1, lettere da a) a o) e da r) a u), del D.P.R. 14 novembre 2002, n. 313, in materia di casellario giudiziale, di anagrafe delle sanzioni amministrative dipendenti da reato e dei relativi carichi pendenti, o la qualita' di imputato o di indagato ai sensi degli articoli 60 e 61 del codice di procedura penale” In pratica si tratta dei dati relativi a:
Il trattamento dei dati personaliLa normativa stabilisce che il trattamento dei dati personali debba avvenire secondo il principio della "necessità del trattamento". L'articolo 3 del decreto esplicita infatti questo principio specificando che tutte le informazioni personali ed identificative che vengono utilizzate devono avere un valido motivo che ne giustifichi il trattamento. Inoltre, una qualunque organizzazione non solo dovrà avere valide ragioni per trattare determinati dati personali ma dovrà anche dimostrare che il trattamento in forma anonima non può essere accettabile. Gli attori del trattamentoNel momento in cui si avvia un trattamento di dati personali è necessario identificare il cosiddetto "interessato". Il decreto definisce come interessato "la persona fisica, la persona giuridica, l'ente o l'associazione cui si riferiscono i dati personali". È importante sottolineare che il trattamento dei dati personali da parte di privati o di enti pubblici economici è ammesso soltanto con il consenso dell'interessato, espresso liberamente (art. 23 comma 1). Tale consenso può essere anche in forma orale se si sta trattando di dati personali comuni mentre nel caso dei dati sensibili deve avvenire per iscritto (articolo 23 comma 4, con la suddetta eccezione dell'autorizzazione n.4/2008). Il trattamento dati avviene secondo le direttive impartite dal cosiddetto "Titolare del trattamento" che, secondo la definizione del decreto, è "la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro ente, associazione od organismo cui competono, anche unitamente ad altro titolare, le decisioni in ordine alle finalita', alle modalita' del trattamento di dati personali e agli strumenti utilizzati, ivi compreso il profilo della sicurezza". Oltre al titolare del trattamento dati è di importanza un'altra figura nota come "Responsabile del trattamento" che è "la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro ente, associazione od organismo preposto dal titolare al trattamento dei dati personali". Ove sia ritenuto indispensabile, per necessità organizzative, è possibile designare come Responsabili del trattamento più soggetti, anche ripartendo tra di loro i vari compiti da svolgere. Mentre il Titolare del trattamento dati definisce le modalità del trattamento e risponde, quindi, della loro correttezza, il Responsabile del trattamento dati garantisce che tali modalità vengano attuate e riporta al titolare tutte le anomalie e le osservazioni opportune affinché le modalità del trattamento rimangano a norma di legge. I Responsabili possono essere sia interni che esterni all'azienda. La nomina di un Responsabile esterno garantisce il Titolare in quanto questo può attestare la conformità delle attività di trattamento dati rispetto al disciplinare tecnico presentato nell'allegato B del decreto. Ultimo anello della catena del trattamento è colui che fisicamente lo esegue. Questa persona, denominata" Incaricato del trattamento", è necessariamente una persona fisica e deve essere autorizzata dal Titolare del trattamento o dal Responsabile. In particolare, in tema di Incaricati, il decreto riporta la seguente norme (art. 30):
È quindi evidente che gli unici autorizzati al trattamento dati sono gli Incaricati e che possono eseguire tali trattamenti solo in base alle istruzioni impartite dal Titolare o dal Responsabile. Gli Incaricati devono essere designati per iscritto con specifica descrizione dei trattamenti a cui sono autorizzati. In particolare è opportuno evidenziare che nessuna persona fisica può trattare dati personali se non ha ricevuto in precedenza un'apposita lettera d'incarico nominativa in cui vengono definite le modalità specifiche di comportamento nel trattamento dei dati e, in particolare, il vincolo di assoluta riservatezza su tutti dati con cui essa viene a contatto. Tale lettera d'incarico deve essere consegnata con attestazione di ricevimento a ciascun incaricato e dovrà essere mantenuta sia una copia dell'incarico stesso che un elenco di nominativi (con data di consegna della lettera d'incarico). L'autorità che la legge pone alla tutela della riservatezza dei dati personali è il cosiddetto "Garante" (art. 153), un organo collegiale costituito da quattro componenti: di cui due eletti dalla Camera dei Deputati e due dal Senato della Repubblica. I principali (ma non tutti) compiti del Garante possono essere sintetizzati nei punti seguenti (art. 154):
Il garante mantiene, inoltre, aggiornato un registro dei trattamenti dei dati (art. 37) che contiene l'elenco delle notifiche ricevute dai Titolari, notifiche obbligatorie a fronte di determinate tipologie di trattamento dati tra le quali, principalmente:
Essendo il settore ontologico in piena espansione ci si focalizzerà su due casi particolari da cui potranno essere estrapolate delle considerazioni di carattere generale. Il primo progetto è quello della Open Biological and Biomedical Ontologies, meglio noto come OBO Foundry. Il secondo è il progetto GALEN. Entrambi i progetti hanno l'obiettivo di mettere a disposizione delle ontologie biomediche, anche se con delle differenze che saranno più chiare nel seguito. Open Biological and Biomedical OntologiesIl progetto OBO Foundry consiste nella collaborazione di numerosi sviluppatori di ontologie con il fine di stabilire un insieme di principi per la loro costruzione con l'obiettivo di creare un insieme (libreria) di ontologie tra loro ortogonali e interoperabili in campo biologico e biomedico. Al momento le ontologie che fanno parte della OBO Foundry sono le seguenti:processi biologici, componenti cellulari, entità chimiche di interesse biologico, funzioni molecolari, qualità fenotipica, proteine, anatomia e sviluppo di Xenopus e Zebrafish.Oltre a queste ontologie ve ne sono altre che potrebbero in futuro essere inserite nel progetto o, comunque, di interesse. Tutte le ontologie sono in un formato specifico denominato OBO. Si tratta di un flat file in formato testuale, la cui versione attuale è la 1.2. Il formato di un documento OBO prevede un'intestazione e una o più "stanza" (ossia in una o più strofe, traducendo il termine dall'inglese). Ogni stanza è una sequenza (identificata da un'apposita etichetta) di coppie di tag. Essendo un formato destinato alla rappresentazione di ontologie prevede, ad esempio, dei meccanismi di definizione di sottoinsiemi, di sinonimi, di tipi di dati, operazioni di algebra relazionale e molto altro ancora. Il formato è molto ricco e può essere convertito in OWL. Allo scopo di agevolare la conversione bidirezionale tra i due linguaggi per la rappresentazione di ontologie è nato un progetto specifico che permette la traduzione di ontologie scritte per uno nell'altro senza alcuna perdita. Grazie a questa conversione è possibile utilizzare le ontologie espresse in OBO per implementare "semplicemente" un Web semantico biomedico. I dettagli possono essere trovati in Syed Hamid Tirmizi, Stuart Aitken, Dilvan Moreira, Chris Mungall, Juan Sequeda, Nigam H. Shah and Daniel P. Miranker. OBO & OWL: Roundtrip Ontology Transformations. In Proceedings of Semantic Web Applications and Tools for Life Sciences Workshop, Amsterdam, The Netherlands, November 20, 2009. In conclusione OBO Foundry può essere ritenuto un progetto che da esperimento si è trasformato in un framework per lo sviluppo di ontologie. Di conseguenza il risultato non è soltanto un "vocabolario controllato" di termini tecnici ma anche una metodologia per la creazione di ontologie. GALENIl progetto GALEN, che ha dato vita al meglio noto Open GALEN, nasce in ambito europeo e punta alla realizzazione di un modello di conoscenza relativo a termini medici. Il progetto GALEN ha sviluppato un cospicuo insieme di concetti che sono stati organizzati mediante l'utilizzo del linguaggio (definito in GALEN) GRAIL. Oggi è possibile tradurre le ontologie GRAIL in ontologie OWL-RDF (OWL 2.0). L'obiettivo di GALEN è quello di rendere il più possibile machine-friendly lo scibile e le informazioni in campo (bio)medico. Il risultato è un sistema computerizzato di codifica multilingue per l'utilizzo in campo medico. Tale obiettivo punta a risolvere alcune questioni chiave quali il problema di avere sistemi multilingue che però siano in grado di preservare e condividere la conoscenza sottostante allo specifico linguaggio oppure la necessità di superare la barriera tra l'elevato livello di dettaglio informativo (prossimo al linguaggio naturale) necessario per la gestione dei dati clinici di un paziente e quello aggregato utile a fini statistici. I fronti su cui GALEN si propone sono molteplici e riguardano il superamento dei vincoli informativi legati alla semantica del dato. Un primo risultato è il GALEN Common Reference Model, un insieme di concetti medici riutilizzabile e indipendente dal linguaggio impiegato. Il Common Reference Model è strutturato secondo quattro parti:
L'ontologia di alto livello di GALEN è indipendente dalla lingua utilizzata ed è uno schema di alto livello che consente di stabilire le regole fondamentali per la collaborazione e la condivisione dell'informazione. GALEN si basa su un principio fondamentale che è quello della separazione tassonomica. In pratica, i concetti vengono descritti in termini di loro componenti che vengono raggruppati secondo gerarchie pure. Questi elementi di gerarchie pure vengono quindi ricombinati a formare tutti i concetti necessari. La classificazione di tali composizioni può essere completamente automatizzata.
In questo articolo verrà analizzata una parte delle linee guida: la parte relativa all'analisi del rischio. L'individuazione dei rischi e la definizione dei protocolliL'articolo 6, comma 2, del decreto legislativo 231 del 2001, enumera le caratteristiche che un modello di organizzazione, gestione e controllo deve avere. Già ad un'analisi superficiale risulta evidente (in particolare per le lettere a e b) che il modello descritto è un tipico sistema di gestione dei rischi (aziendali). Sono infatti evidenziate due fasi: l'identificazione dei rischi e la progettazione di un sistema per la loro gestione (descritti nel testo normativo come "protocolli per la programmazione della formazione ed attuazione delle decisioni dell'ente"). Partiamo da questo secondo punto: è evidente che il sistema che si vuole costruire deve essere in grado di contrastare il verificarsi dei rischi identificati nella prima fase. In particolare ciò viene focalizzato sulla formazione delle decisioni (quindi sul processo decisionale) e poi sulla loro attuazione (ossia sul processo operativo che mette in pratica la decisione presa). La formazione delle decisioni è uno dei processi chiave che devono essere presidiati in quanto è da decisioni rischiose che possono concretizzarsi i reati presupposto previsti dal decreto. Avendo però messo sotto controllo il processo con cui vengono prese le decisioni è necessario che ne sia verificata la corretta attuazione, secondo punto debole della catena. Tornando alla prima delle due fasi sopra indicate, è quindi importante che vengano identificate le aree a rischio, descrivendo le modalità con cui si possono verificare gli eventi che portano alla commissione dei reati presupposto. Su tale identificazione verrà costruito un insieme di protocolli che sia in grado di ridurre ad un livello accettabile il rischio agendo sulla formazione e sull'attuazione delle decisioni. Il primo problema da affrontare è la definizione quantitativa (o anche solo qualitativa) di rischio. Di norma la valutazione del rischio avviene secondo due fattori: la probabilità che accada l'evento rischioso e l'impatto che l'accadimento dell'evento comporterebbe sulla realtà aziendale. Di estrema importanza è la comprensione che l'evento rilevante ai fini del decreto legislativo 231 non deve essere solo quello che contenga una fattispecie di reato presupposto ma anche qualsiasi comportamento che possa essere preliminare alla commissione del reato stesso e che costituisca una violazione delle procedure di controllo interno. Particolare attenzione va posta anche ai rischi legati a comportamenti illeciti in materia di salute e sicurezza sul lavoro in quanto la normativa prevede come reati presupposto quelli colposi e quindi l'ente dovrà essere estremamente consapevole dell'importanza di prevenire lesioni gravi e gravissime o, addirittura, l'omicidio colposo mediante una scrupolosa osservazione di tutte le norme. Anche in questo caso si interverrà sia sui processi decisionali sia su quelli attuativi. Ai fini della valutazione del rischio si dovrà tenere conto sia della probabilità che l'evento delittuoso o (un evento adesso preliminare) si verifichi, combinando la probabilità dell'evento preliminare con quella necessaria per condurre fino a compimento il reato presupposto, sia dell'eventuale impatto che tale reato possa avere sull'ente. Molto temute dagli enti sono non tanto le sanzioni pecuniarie quanto quelle interdittive e poiché i differenti reati presupposto prevedono sanzioni anche molto diversificate è necessario che l'ente valuti, caso per caso, l'impatto sia delle sanzioni di natura economica sia delle sanzioni di altra natura. Il rischio accettabileA questo punto è possibile ragionare in termini di "rischio accettabile". Le linee guida di Assobiomedica ne forniscono una definizione molto semplice e comprensibile: definito il valore del rischio come la combinazione della perdita potenziale che si avrebbe al verificarsi dell'evento con la probabilità che la perdita debba essere effettivamente sostenuta, si può affermare che il rischio sia ritenuto accettabile quando i controlli aggiuntivi hanno un costo maggiore della risorsa da proteggere. Le linee guida di Assobiomedica fanno anche un esempio esplicativo in cui si fa notare come in una comune automobile sia spesso presente un antifurto ma mai un vigilante armato (che avrebbe un costo superiore al valore dell'autovettura stessa). La riflessione però prosegue osservando che, come già anticipato, non devono essere considerati solo i costi di natura economica ma anche di altra natura, quali ad esempio quelli organizzativi (in termini di aumento di complessità dei processi), di verifica (in termini di controlli, manuali o automatici, introdotti nel sistema) e via dicendo, per evitare che si debba introdurre una miriade di controlli. A tal fine deve essere introdotta una soglia sotto la quale non è necessario introdurre un sistema di prevenzione del rischio in quanto, in sintesi estrema, "nessuno è tenuto a fare l'impossibile". L'elusione fraudolentaIl sistema di prevenzione del rischio dovrà essere quindi progettato e realizzato in modo tale da non poter essere aggirato se non fraudolentemente, come la legge stessa richiede. Al riguardo è importante la considerazione che viene fatta nelle linee guida relativamente ai casi di omicidio in lesioni colpose derivanti da inosservanza in materia antinfortunistica (aspetto molto importante in ambito biomedico): in tali casi la soglia concettuale di accettabilità, ai fini esimenti per la legge 231, è rappresentata dalla realizzazione di una condotta (non intenzionale) in violazione del modello di prevenzione e della normativa vigente nonostante sia stata svolta in maniera inappuntabile l'attività di vigilanza in materia. E' evidente che in questi casi l'elusione fraudolenta dei modelli organizzativi è praticamente incompatibile con l'elemento soggettivo di un delitto colposo in quanto qui si parla, appunto, "di colpa". Di conseguenza, in sintesi, per tutti i reati di natura dolosa il modello organizzativo dovrà essere tale da non poter essere eluso se non in maniera fraudolenta mentre negli altri casi (ossia nei casi colposi, ad oggi limitati alle sole norme antinfortunistiche) il modello dovrà garantire la necessaria consapevolezza di chi è a rischio di infortunio e l'indispensabile vigilanza di chi è preposto a tale funzione. Questo aspetto non è sempre ben considerato nei modelli organizzativi (a meno che non vengano applicati sistemi quali OHSAS 18001 e/o UNI-INAIL 2001) ed è importante che sia stato sottolineato nelle linee guida diretti al sistema biomedico, ambito di estremo interesse per questo tipo di reati. La costruzione di un sistema di gestione del rischioIntroduzioneIl primo passo nella costruzione di un sistema di gestione del rischio consiste nell’individuare le attività o le aree che comportano il rischio di commissione di reati presupposto. Il secondo passo è quello di eliminare (rendere accettabile) tale rischio. Una volta effettuati i due passi suddetti non si può ignorare, comunque, il fatto che gli stessi reati possono essere commessi eludendo fraudolentemente le contromisure messe in atto dall’azienda: in questo caso, però, il D.Lgs. 231 limita la responsabilità al solo soggetto reo, esimendo così l’ente.
Gli agenti sono dei componenti software che possiedono determinate proprietà quali, l'autonomia, la capacità di cooperazione ed altre ancora. In questo documento ci concentreremo solo sugli aspetti di comunicazione, utilizzando una delle numerose piattaforme disponibili per sviluppare sistemi basati su agenti: JADE. Nell'esempio che andremo ad esaminare avremo due agenti che, comunicando tra di loro, giocheranno al noto gioco "indovina il numero". Le regole del gioco sono molto semplici: il primo giocatore pensa un numero intero tra uno e un valore massimo prefissato (nell'esempio tale valore è 10.000), il secondo tenta di indovinare qual è il numero e riceve in risposta dal primo se il suo tentativo è superiore al numero "misterioso", oppure se è uguale o se ha indovinato. L'algoritmo per risolvere questo problema è molto semplice ed è la classica ricerca dicotomica: si va a metà dell'intervallo di incertezza e, in base alla risposta (maggiore o minore) si restringe ulteriormente l'intervallo, andando di nuovo alla sua metà e via dicendo. Si dimostra facilmente che il numero massimo di tentativi cresce con l'intero superiore del logaritmo in base 2 del valore più alto possibile (nel nostro caso è quindi pari a 14). L'implementazione effettuata sulla piattaforma JADE è molto semplice e consiste in due agenti (che sono dei semplici contenitori) a ciascuno dei quali è assegnato un behaviour che al suo interno contiene un automa stati finiti che gli consente di gestire le varie situazioni di gioco. Il diagramma degli stati è uguale per entrambi i giocatori: si parte da uno stato iniziale che corrisponde al primo tentativo, si passa ad uno stato in cui si permane per tutti tentativi sbagliati successivi al primo e poi si passa in uno stadio finale in cui due giocatori esultano e terminano il gioco. Lo stato "primo tentativo"In questo stato il primo giocatore genera casualmente il numero da indovinare e comunica al secondo giocatore qual è il valore massimo ammissibile per tale numero (valore che nell'esempio è prefissato a 10.000). Il codice che genera il numero casuale, comunica il massimo possibile e passa allo stato successivo, per il giocatore numero uno, ossia quello che estrae il numero da indovinare, è il seguente (classe QuizB.java):
public QuizB(Agent a, long max) { super(a); this.max = max; this.mystery = (long) (Math.floor(Math.random() * max)) + 1; this.state = PRIMO_TENTATIVO; } public void action() { switch (state) { case PRIMO_TENTATIVO: ACLMessage msg = new ACLMessage(ACLMessage.INFORM); msg.setContent(Long.toString(max)); msg.addReceiver(new AID("con", AID.ISLOCALNAME)); myAgent.send(msg); state = ATTESA_RISPOSTA; System.out.println(" - " + myAgent.getLocalName() + " sent: " + msg.getContent()); block(); break; [...] Come è semplice notare, nel costruttore viene generato il numero casuale mentre nel metodo action(), grazie ad un'istruzione switch che viene utilizzata per far funzionare la macchina a stati finiti che permette all'agente di evolvere, viene impacchettato il messaggio e spedito al destinatario (a cui, per semplicità, è stato assegnato il nome di "con" abbreviazione di concorrente). Dopo aver spedito il messaggio il sistema cambia di stato, passa lo stato in cui si attende un tentativo dall'altro giocatore e quindi blocca l'agente in attesa di un evento. Per semplicità sono state omesse le righe di codice successive relative agli altri stati. Il codice relativo al secondo giocatore è invece reperibile nella classe AnswB.java ed è molto simile al precedente: public AnswB(Agent a) { super(a); this.low = 1; this.state = PRIMO_TENTATIVO; }
public void action() { switch (state) { case PRIMO_TENTATIVO: ACLMessage msg = myAgent.receive(); if (msg != null) { System.out.println(" - " + myAgent.getLocalName() + " received: " + msg.getContent()); String res = msg.getContent(); long max = Long.parseLong(res); this.max = max; this.high = max; lastGuess = (long) Math.floor(((high - low) / 2) + low); msg = new ACLMessage(ACLMessage.INFORM); msg.setContent(Long.toString(lastGuess)); msg.addReceiver(new AID("quiz", AID.ISLOCALNAME)); myAgent.send(msg); state = TENTATIVI_SUCCESSIVI; System.out.println(" - " + myAgent.getLocalName() + " sent: " + msg.getContent()); block(); } break; [...] Anche in questo caso nel costruttore vengono eseguite delle operazioni di inizializzazione e poi si passa al metodo action() che si occupa di ricevere un messaggio, leggerne il valore e memorizzarlo come il numero massimo (variabili che, in quest'esempio, non sarà più utilizzata). Viene quindi eseguito il primo tentativo prendendo il valore centrale dell'intervallo tra uno e il massimo appena letto. Questo valore viene comunicato al primo giocatore che, per comodità, viene identificato come "quiz". Dopo l'invio del messaggio il secondo giocatore (il secondo agente) passa nello stato relativo ai tentativi successivi.
In primo luogo è opportuno chiarire che non si tratta di numeri completamente casuali ma pseudocasuali, ossia numeri generati da un apposito algoritmo che opera in maniera deterministica (cioè fornendo sempre lo stesso output a fronte di un identico input) ma che permette di generare una sequenza di numeri che ha caratteristiche statistiche analoghe a quelle di una sequenza estratta casualmente. L'input di cui si parla è il cosiddetto seme (seed in inglese), ossia un parametro che indica il punto di partenza della sequenza. Se il seme è estratto in maniera casuale, essendo utilizzato una sola volta, si ottiene una sequenza a priori non prevedibile. Spesso il seme viene generato prendendo un numero ricavato dall'orologio di sistema: in questo modo, in due esecuzioni distinte del programma, eseguite manualmente, si ha una sua buona "casualità". E' opportuno prestare attenzione al caso in cui il software si avvii automaticamente perché potrebbero nascere dei meccanismi di sincronizzazione che, a fronte di esecuzioni differenti, potrebbero portare alla generazione della stessa sequenza perché si è generato lo stesso seme. E' utile osservare che, in alcuni casi, è molto comodo poter ripetere la sequenza pseudocasuale più volte, ossia avviare il software con gli stessi numeri. Per farlo è in genere sufficiente utilizzare lo stesso seme. Nel linguaggio Java si può utilizzare la classe java.lang.Math che fornisce il metodo random(). Quando viene invocato la prima volta genera un nuovo generatore (ossia genera il seme) e ritorna un numero pseudocasuale double tra 0 e 1. Le successive chiamate consentono di ottenere altri numeri pseudocasuali, sempre double compresi tra 0 e 1. Un'altra maniera è quella di utilizzare la classe java.util.Random. Come nella maggior parte dei generatori di numeri pseudocasuali, la classe Random ha due costruttori: uno privo di argomenti e uno che accetta un seme long. Il primo si comporta come il metodo random() di Math, il secondo accetta il seme long (ottenuto, ad esempio, dall'orologio di sistema) e lo utilizza per inizializzare il generatore pseudocasuale. In quest'ultima maniera è possibile riottenere la stessa sequenza in successive esecuzioni del codice fornendo lo stesso seme. Inoltre con Random è possibile generare numeri casuali con distribuzione uniforme o gaussiana. Vediamo ora un esempio di generazione di numeri casuali con le due classi:
Le notizie di interesseQuali notizie interessano l’organismo di vigilanza? Una prima tipologia è quella della variazione dei reati presupposto: è necessario che l'organismo di vigilanza sia in grado di acquisire tempestivamente l'informazione in merito a variazioni, tipicamente normative, che portino all’aggiunta, alla rimozione o alla modifica dei reati presupposto previsti dal D.Lgs. 231/01 o dalla normativa che rende tale decreto applicabile in taluni casi (come accaduto, ad esempio, nel caso del D.Lgs. 152/2006 all’art. 192 comma 4). Una seconda tipologia è quella relativa alla variazione della struttura organizzativa: alterazioni della macrostruttura o della microstruttura devono essere tempestivamente segnalate all'organismo di vigilanza e gestite in modo da poter ottenere un'immediata valutazione di eventuali incrementi di rischio, ossia una misura dell'adeguatezza del modello a fronte della situazione aggiornata. Ovviamente tale comunicazione potrà portare anche ad un efficientamento del modello a seguito dell’eliminazione di punti di controllo divenuti superflui ma questo è da considerarsi solo un obiettivo secondario. Una terza tipologia riguarda la variazione delle attività svolte dall'organizzazione: l'aggiunta di una nuova attività, anche senza cambiamenti organizzativi o normativi, può esporre in maniera intollerabile a rischi prima ritenuti accettabili. Anche in questo caso si può avere come “effetto collaterale” un efficientamento. Purtroppo, in alcuni casi, come accaduto anche in un recente convegno sul tema della responsabilità amministrativa organizzato da un importante ente, si scopre che i flussi informativi verso l'organismo di vigilanza sono delle mere attestazioni di assenza di problemi da parte dei, ad esempio, responsabili di funzione. Questo modo di inviare informazioni è completamente inadeguato in quanto priva l'organismo di vigilanza di un canale sensoriale essenziale, riducendone la percezione di quanto avviene nell'azienda alle sole verifiche, periodiche o casuali, che l'organismo effettua. Viene quindi meno l'unico canale in grado di garantire la tempestività delle informazioni che, sebbene non richiesta esplicitamente dalla legge è implicita in essa e, comunque, di sicuro nell’interesse dell’ente stesso. La perdita di questo flusso comunicativo ha un altro gravissimo svantaggio: il mancato utilizzo delle professionalità dei componenti dell'organismo di vigilanza, lasciando l'onere di valutare se le informazioni in proprio possesso possano avere un impatto meno sul modello organizzativo ai singoli responsabili di funzione che non hanno né la visione di insieme necessaria né, spesso, la competenza tecnica per farlo (e spesso, neanche l'assegnazione esplicita per tale mansione). Un altro aspetto che si trova talvolta sottovalutato nelle aziende è la comunicazione tra organismo di vigilanza e i vertici aziendali, siano essi amministrativi o di controllo. Molto importante è infatti sia l'aggiornamento continuo dell'organo amministrativo sia il confronto e lo scambio informativo con le varie funzioni preposte ad attività di controllo (ad esempio il collegio sindacale o l’internal auditing). Un terzo tipo di flusso informativo andrebbe inoltre mantenuto nei confronti di quelle funzioni aziendali che operano per la realizzazione e la manutenzione di sistemi di gestione quali, ad esempio, le normative sulla qualità (ISO 9000, AS 9100, …), quelle sull'ambiente (ISO 14000), sulla salute (OHSAS 18001) e molte altre ancora: la relazione tra le norme legate alla responsabilità amministrativa delle persone giuridiche e tali standard è sempre maggiore e, tra l'altro, permette di costruire un sistema "integrato" in cui non domini la burocrazia ma l'efficienza, garantendo il raggiungimento (sebbene siano spesso necessari dei compromessi) di tutti gli obiettivi che tali standard a si prefiggono (e che l'ente si prefigge con la loro adozione) e quelli che sono i dettami del decreto legislativo 231/2001. Ciò premesso è evidente che una carenza di flussi informativi può portare, nella migliore delle ipotesi, ad inefficienze non tollerabili ma, di norma, porta al rischio di non individuare per tempo problemi che possano avere un impatto in termini di commissione dei reati presupposto a discapito anche dell’esenzione dell’ente dalla responsabilità amministrativa, dopo aver tra l’altro investito notevoli risorse nel modello e nell’organismo di vigilanza.
Si tratta chiaramente di una prima versione che potrà essere soggetta a modifiche anche a fronte di segnalazioni da parte degli utenti, previa valutazione ed approvazione da parte del Comitato Tecnico-Scientifico. Eventuali nuove versioni saranno distinguibili dalla data di aggiornamento. La versione attuale è identificata come "Versione di Test 1.0" e porta la data del 2 agosto 2010.
|
L'organismo di Vigilanza, recita il decreto legislativo 231 del 2001 in tema di responsabilità amministrativa delle persone giuridiche, deve essere dotato di "autonomi poteri di iniziativa". E evidente che, con una citazione cinefila, "da un grande potere derivano grandi responsabilità" e che, quindi, è sottinteso che l'Organismo di Vigilanza abbia il dovere di attivarsi in maniera tempestiva, efficace ed efficiente.
In questo breve articolo vengono presentate alcune ontologie in campo biomedico allo scopo di fornire un semplice schema descrittivo di cosa è oggi disponibile.
Le linee guida di Assobiomedica in tema di responsabilità amministrativa per la costruzione dei modelli di organizzazione, gestione e controllo ai sensi del decreto legislativo 231 del 2001 (aggiornate a marzo 2009) sono un buon risultato dal punto di vista della chiarezza e della sintesi. Inoltre presentano degli aspetti che le rendono molto interessanti in quanto vanno a completare quanto previsto nelle linee guida di Confindustria, presentando argomenti di interesse generale e non solo limitatamente al comparto biomedico.
Iniziamo, con questo articolo, una nuova serie di pubblicazioni relative agli agenti.
Spesso è necessario generare dei numeri "casuali" durante l'esecuzione di un programma. Questo articolo tratta di come farlo in Java.
La normativa sulla responsabilità amministrativa delle persone giuridiche prevede l'obbligo di informazione nei confronti dell'organismo deputato a vigilare sul funzionamento e sull'osservanza dei modelli. E’ evidente che idonei strumenti informativi devono essere previsti dall'organo amministrativo per consentire all'organismo di vigilanza di venire a conoscenza tempestivamente delle notizie che interessano la sua funzione.
E' stato pubblicato sul sito del Sistema di Controllo della Tracciabilità dei Rifiuti il manuale utente del SISTRI in modo da poter essere utilizzato nella fase di sperimentazione (in corso), a fronte del previsto avvio operativo dal 1 ottobre 2010.
