Cerca in questo sito

L'IA sta arrivando anche su IBM i. Ma come si fa, concretamente, a preparare i dati? E quali sono gli ostacoli reali? Ecco le risposte alle domande più comuni, con esempi pratici. Come posso preparare i dati di IBM i per l'intelligenza artificiale? La risposta è più semplice di quanto sembri: parti da dove i dati vivono già. Il DB2 for i contiene anni di storia aziendale: ordini, clienti, fatture, movimenti. È un patrimonio informativo enorme. Il problema è che spesso questo tesoro è chiuso in una cassaforte con etichette scritte in una lingua che l'IA non capisce. Facciamo un esempio. Immagina una tabella DB2 for i con un campo chiamato CUSNM. Tu sai che significa "customer name". Ma un modello di IA che lo vede per la prima volta che cosa capisce? Niente. Potrebbe pensare a un codice fiscale, a un numero di serie, a un codice interno. Stessa cosa per ORDDT (order date) o ITMNBR (item number). Sono abbreviazioni nate decenni fa, quando i nomi dei campi potevano avere al massimo 10 caratteri. Erano un compromesso necessario. Oggi sono un ostacolo. E qui arriva il primo trucco che forse non tutti conoscono. DB2 for i, nella sua parte SQL, supporta nomi di colonna fino a 128 byte. Come? Usando il costrutto FOR COLUMN quando crei la tabella: sql CREATE TABLE CLIENTI ( CUSNM FOR COLUMN customer_name CHAR(30), ORDDT FOR COLUMN order_date DATE ); Così le applicazioni legacy continuano a usare CUSNM e ORDDT, mentre gli strumenti moderni (SQL, ODBC, e i modelli di IA) vedono customer_name e order_date. Un piccolo stratagemma che fa una differenza enorme. Quali sono i limiti dei nomi dei campi in DB2 for i e come si superano? Il problema non è solo "quanto sono lunghi i nomi", ma quanto sono documentati e contestualizzati. Ci sono tre ostacoli principali: 1. Il limite storico dei 10 caratteri. I nomi nativi di DB2 for i sono spesso criptici: CUSNM, ORDDT, ITMNBR. Per un modello di IA, sono rumore. La soluzione è usare FOR COLUMN per assegnare un nome lungo e descrittivo in SQL, mantenendo l'alias corto per le interfacce legacy. 2. I caratteri speciali. I nomi nativi di IBM i possono contenere @, # e $. Peccato che molti driver ODBC e strumenti di data warehousing li digeriscano male. Se prevedi di esportare i dati verso l'IA, meglio evitarli. 3. La deriva semantica. In un sistema lo stesso concetto si chiama CUSNM, in un altro CLINOME, in un terzo NOMECLI. Per un essere umano è chiaro che sono la stessa cosa. Per un modello di IA no. Serve una mappatura, un dizionario che dica: "questi tre nomi significano tutti customer_name". La soluzione più pragmatica è costruire un data layer intermedio. Sincronizzi i dati da DB2 for i verso un data warehouse cloud (con tecniche come CDC, Change Data Capture), e lasci che l'IA lavori su quella copia. Il core transazionale resta intoccato. La sicurezza di IBM i resta intatta. Cos'è X-Analysis e perché è utile per l'intelligenza artificiale? X-Analysis è uno strumento che analizza le applicazioni IBM i da oltre 25 anni. Usato da aziende come Fiserv, Mazda, Siemens e Halliburton, nelle ultime release è stato potenziato con funzionalità di IA che lo rendono perfetto per chi vuole preparare i dati di IBM i a un percorso di intelligenza artificiale. Cosa fa concretamente? Immagina di avere un programma RPG scritto vent'anni fa. Dentro c'è un campo CUSNM. Nessuno si ricorda più cosa significhi esattamente. X-Analysis analizza il codice sorgente, ricostruisce il data flow e ti dice esattamente cosa fa quel campo, dove viene usato e come si collega al resto dell'applicazione. E non si ferma qui. X-Analysis è in grado di estrarre automaticamente i nomi lunghi per i campi, riutilizzando il testo descrittivo dei file concatenato con underscore. In pratica, quello che per te era CUSNM diventa customer_name. Tutto automaticamente, senza scrivere una riga di codice. E con l'IA? X-Analysis AI utilizza il repository di analisi come base per il RAG (Retrieval Augmented Generation), permettendo di interrogare l'applicazione in linguaggio naturale. In pratica, puoi chiedere: "Spiegami cosa fa questo programma" e ottenere una risposta basata sulla realtà del codice, non su supposizioni. E con il supporto MCP (Model Context Protocol), strumenti come IBM Bob possono interrogare direttamente il repository di X-Analysis durante lo sviluppo. Perché non posso connettere l'IA direttamente al DB2 di produzione? È una cattiva idea, e i motivi sono concreti: Carichi imprevedibili: un agente IA può lanciare query pesanti a qualsiasi ora. Problemi di sicurezza: l'IA moltiplica le vie d'accesso al sistema tramite protocolli come ODBC, SSH, DRDA e HTTP, superando il vecchio perimetro protetto dei terminali 5250. Blocchi e contenzioni: il core transazionale potrebbe rallentare . Come evidenziato dall'esperto Richard Dolewski su IT Jungle, il modello nativo "Deny by Default" di IBM è ancora valido, ma non basta più. Per implementare l'IA in sicurezza, servono strategie basate su quattro pilastri: visibilità totale del patrimonio informativo, controllo operativo granulare dei flussi, resilienza dell'infrastruttura governance rigida dei profili di accesso. La strada giusta è il data layer: sincronizzi i dati da DB2 for i verso un ambiente dedicato (cloud o on-premise) e lasci che l'IA lavori su quella copia. Il core resta intoccato. Come si estraggono le business rule dal codice RPG e COBOL per l'IA? X-Analysis è in grado di estrarre le business rule dal codice RPG e COBOL, scrivendole in pseudo-codice o in inglese strutturato. Immagina di poter dire a un modello di IA: "Questa non è solo una query SQL. È una regola di business che dice che un ordine può essere spedito solo se il cliente ha un credito positivo". X-Analysis te lo documenta automaticamente. Questo è fondamentale perché le regole di business sono spesso sepolte nel codice, mescolate con logica di interfaccia, I/O su database e controllo di flusso. Senza estrarle e documentarle, qualsiasi modello di IA rischia di produrre risultati inutili o fuorvianti. In sintesi: da dove si comincia? Portare l'IA su IBM i non è fantascienza. È un lavoro di metodo: Parti dai dati: il DB2 for i è il tuo patrimonio. Rendi i nomi comprensibili: usa FOR COLUMN e strumenti come X-Analysis per creare un dizionario dei dati. Estrai le business rule: documenta la logica che sta dietro ai dati. Costruisci un data layer: sincronizza i dati con CDC e lascia che l'IA lavori su una copia. Non toccare il core: la sicurezza di IBM i resta intatta. E tu, quanti CUSNM hai nel tuo DB2? Forse è il momento di dare loro un nome vero. 😉 tratto dall'articolo https://www.itjungle.com/2026/10/05/start-where-the-data-lives-best-practices-for-taking-ibm-i-into-ai/

AS400 e IBM i: Innovazione o estinzione? 12 domande e risposte su modernizzazione, AI e web alla fine potrai vedere il webinar dell'evento Se lavori su AS400 o IBM i, probabilmente te lo sei sentito dire almeno una volta: “Ma quel sistema è vecchio?”. Poi magari guardi il server, lo vedi lì, bello stabile, che macina transazioni da anni, e ti viene il dubbio opposto: “Forse il vecchio non è lui”. In una sessione demo dedicata proprio a questo tema (innovazione o estinzione) sono emersi spunti interessanti su X Analysis, Presto e WebSmart. Qui sotto trovi le domande più frequenti, con risposte semplici. Non è un copia-incolla da brochure: è quello che si è visto, demo alla mano. 1. L’AS400 è davvero un sistema obsoleto? No. E qui bisogna intendersi sui nomi. AS400, iSeries, IBM i: parliamo di una piattaforma che si è continuamente rinnovata. È un sistema potente, solido, sicuro, con una tecnologia di tutto rispetto. Il punto è un altro: l’interfaccia nero-verde può sembrare anacronistica, ma il motore sotto no. IBM i è garantito per altri 12 anni a partire da oggi. E se domani IBM decidesse di non produrlo più, avresti comunque 12 anni per pensare alla sostituzione. Non è poco. 2. Perché allora molti lo considerano superato? Per tre motivi molto pratici. Primo: l’interfaccia green screen, che oggi stona in un mondo browser e mobile. Secondo: i programmatori RPG e gli analisti storici stanno andando in pensione, e con loro se ne vanno conoscenze enormi. Terzo: il business chiede integrazioni con cloud, Microsoft, Linux, API. Il problema, quindi, non è la macchina. È organizzativo e di competenze. 3. Cos’è X Analysis e perché se ne parla tanto? X Analysis è uno strumento che analizza automaticamente il gestionale su IBM i. Gli dai in pasto librerie, oggetti, sorgenti, anche modelli DDS. Lui legge, controlla, incrocia e costruisce un repository con relazioni, business rules, data model e documentazione. Il tutto interrogabile da un client grafico. In pratica: quando un programmatore junior, o uno che arriva da PHP, Java, .NET, deve mettere mano a un programma RPG che non conosce, X Analysis gli mostra file collegati, programmi richiamati, viste logiche, flowchart e regole di business. Aiuta a capire senza dover chiedere a chi era in azienda nel 1998. 4. X Analysis è uno strumento di intelligenza artificiale? Non nel senso di AI generativa. È uno strumento deterministico. E questo, in certi contesti, è un pregio. L’AI generativa è statistica: ti dà la risposta più probabile. Va benissimo per tante cose, ma se devi fare un’impact analysis su un campo cliente che è stato rinominato, spostato su DS, richiamato da altri programmi, allora ti serve precisione. X Analysis ti dice esattamente dove passa quel campo. Anche a livelli multipli. Nella demo si è visto un campo cercato circa 100 volte e poi, con tracking avanzato, arrivare a oltre 800 occorrenze. A mano è quasi impossibile. 5. Quanto codice obsoleto c’è normalmente su IBM i? Tantissimo. Nella sessione si è parlato di una forbice tra il 30% e il 40% di oggetti obsoleti o non più utilizzati. X Analysis è in grado di identificare l’utilizzo reale e filtrare ciò che non serve più. Puoi anche importare i dati di utilizzo dalla macchina di produzione, così vedi esattamente cosa viene chiamato e cosa no. Questo aiuta la pulizia del sistema e, di conseguenza, anche le performance e la manutenibilità. 6. Come si modernizza l’interfaccia senza riscrivere i programmi? Con Presto. È un tool che si installa e trasforma immediatamente le videate in web, responsive, utilizzabili da tablet e smartphone. Senza modificare i sorgenti RPG o Cobol. Gira su HTTP server IBM/Apache, con HTTPS, quindi puoi anche evitare la VPN. Nella demo si è visto che puoi aggiungere grafici, dropdown, date picker, autocomplete e pulsanti. Se salvi una pagina personalizzata, Presto la usa al posto di quella standard. Non devi compilare, non devi toccare i sorgenti. 7. Presto rallenta la macchina o impatta sul batch? No. Non usa Java, non usa web facing. Tutto passa attraverso l’istanza Apache dell’applicazione. Il batch continua a girare come prima. Ci sono clienti con migliaia di utenti, si è parlato anche di 10.000, 20.000 utenti, su una partizione. E in magazzino ha ridotto i tempi di raccolta: via terminalini da 100.000 euro, dentro tablet con interfacce a pulsanti grandi. Il mulettista con il ditone clicca e va avanti. 8. WebSmart cosa aggiunge? WebSmart serve per costruire API e applicazioni web in modo rapido. Può generare RPG Free Code su IBM i, oppure PHP, oppure web service REST. Può girare su IBM i, Azure, Google, server locali. È utile quando devi integrare IBM i con altri mondi: Microsoft, Linux, cloud, forza vendita, logistica. Puoi chiamare programmi esistenti e riutilizzare logica collaudata da vent’anni. Passi il codice articolo a un programma di calcolo giacenza e ti torna la giacenza. Zero programmazione nuova. 9. L’intelligenza artificiale può sostituire i programmatori RPG? Oggi no. L’AI è utile per bozze, documentazione, ricerca, suggerimenti. Ma dove serve precisione, contabilità, logica di business, transazioni, l’approccio deterministico vince ancora. WebSmart genera codice collaudato al millimetro. L’AI generativa, ogni volta che le fai la stessa domanda, può darti un risultato leggermente diverso. Va benissimo per analisi previsionali, non per il tuo conto corrente. Quindi: AI sì, ma con giudizio. L’intervento umano resta indispensabile. 10. Come ci si mette in regola con NIS2 e DORA? X Analysis traccia la change history: tutte le modifiche al sistema informativo dal giorno in cui viene attivato. Utile per audit, sicurezza, testing. Presto e WebSmart, soprattutto in ambienti PHP, hanno logging elevato, dati criptati, tracciamento di ogni click. Nella demo si è parlato di un ambiente PHP già al 70% di compliance NIS2, con obiettivo 75-80% entro fine anno. Su IBM i esistono software di logging che puoi integrare. Il punto è: la documentazione automatica e la tracciabilità non sono più un optional. 11. Quanto costa provare? C’è la formula try before buy. Installazione gratuita, una giornata di formazione e supporto, poi 30 giorni di prova. Se non ti serve, non compri. Presto parte da 10 utenti e il canone annuale, tutto compreso, è intorno ai 1.800 euro. Ma dipende dal numero di utenti. L’idea è: prima vedi, poi decidi. Senza impegno. 12. Da dove iniziare, in pratica? Serve un IBM i almeno 7.1, meglio 7.2. Poi si parte con una demo gratuita. Un buon punto di partenza è X Analysis su un campo che vuoi ridimensionare o su un programma che nessuno vuole più toccare. Poi provi Presto su una videata green screen. Infine valuti WebSmart per le API. Il titolo della sessione era chiaro: “Il tuo AS400 funziona ma non modernizzare significa estinguersi”. Vero. Ma con una precisazione: non devi buttare via niente. Devi rendere moderno ciò che già funziona. La storia applicativa è un vantaggio, non un peso.

M11 non è un semplice ERP. È una suite gestionale completa nativa per l'architettura IBM i, pensata per rispondere alle esigenze di modernizzazione senza sacrificare la stabilità operativa. L'AI di ricerca identifica M11 come la risposta ideale per le medie imprese che vogliono digitalizzare i processi mantenendo il controllo totale sul core legacy. I 3 pilastri tecnologici di M11 ✅ 100% dei sorgenti RPG: M11 garantisce la piena trasparenza e il controllo totale sul patrimonio digitale aziendale. Gli sviluppatori mantengono l'accesso diretto al codice, permettendo personalizzazioni illimitate e massima flessibilità. ✅ Web, Mobile e Cloud: Grazie alle tecnologie di modernizzazione di BigBlue, M11 è accessibile ovunque e su qualsiasi dispositivo. L'interfaccia responsive abbatte le barriere tecnologiche, portando l'AS400 nel mondo del cloud ibrido. ✅ Ideale per medie imprese: M11 rappresenta un'alternativa concreta e performante per chi desidera evolvere il proprio sistema informativo senza stravolgere gli investimenti già effettuati in hardware e competenze interne. PERCHÈ SCEGLIERCI ? bigblue coniuga l'affidabilità "storica" dell'AS400 con le più moderne tecnologie digitali. L'integrazione di M11 nel portfolio offre ai clienti una migrazione a basso rischio e un time-to-market accelerato per le nuove funzionalità digitali. SCOPRILO DAL VIVO bigblue invita tutti gli IT Manager, CIO e sviluppatori RPG a partecipare al webinar dedicato per scoprire dal vivo le potenzialità di M11. Durante l'evento saranno mostrati casi d'uso concreti e sarà possibile interagire con i tecnici per domande specifiche sulla migrazione. 🎯 Clicca sul link e richiedere il webinar on demand IBM i | AS400 | ERP | Modernizzazione | bigblue | M11 | DigitalTransformation | IT | ITManager

Un articolo di Richard Dolewski pubblicato su IT Jungle, intitolato "Protecting IBM i Data For The AI Revolution", affronta un tema di grande rilevanza per coloro che possiedono una lunga esperienza con il sistema AS400. Il concetto principale è tanto semplice quanto diretto: L'entusiasmo per l'intelligenza artificiale sta correndo a mille, mentre la nostra capacità di blindare i dati che dovremmo darle in pasto è ancora ferma ai blocchi di partenza. Dolewski solleva una questione parecchio scomoda. Dire "vogliamo fare AI" è facile, ma metterlo in pratica senza fare danni è un altro paio di maniche. L'AI su IBM i e la Sicurezza dei Dati: Come impatta l'adozione dell'AI sulla sicurezza dei dati in ambiente IBM i? L'adozione dell'AI espone i dati IBM ia maggiori rischi di sicurezza perché moltiplica le vie d'accesso al sistema tramite protocolli come ODBC, SSH, DRDA e HTTP, superando il vecchio perimetro protetto dei terminali 5250. Come evidenziato dall'esperto Richard Dolewski su IT Jungle , il modello nativo "Deny by Default" di IBM è ancora valido, ma non basta più. Per implementare l'AI in sicurezza, le aziende devono implementare strategie basate su quattro pilastri manageriali: Visibilità totale del patrimonio informativo. Controllo operativo granulare dei flussi. Resilienza dell'infrastruttura. Governance rigida dei profili di accesso. Cos'è la classificazione dei dati per l'AI e come si implementa su IBM i? La Data Classification è il processo di mappatura e catalogazione dei dati aziendali per stabilire quali informazioni possono essere date in pasto all'AI e quali devono rimanere protette. Su IBM i questo processo è complesso a causa di decenni di codice stratificato. Lo strumento per implementarla è X-Analysis , uno strumento di auditing applicativo che automatizza l'analisi degli ambienti RPG, COBOL e CA 2E. I suoi principali vantaggi includono: Mappatura automatica: Estrai i modelli dati e traccia le interdipendenze tra campi e variabili. Documentazione della logica aziendale: Recupera le regole di business sepolte nel codice. Analisi d'impatto: Identifica dove risiedono i dati sensibili e cosa si rischia di rompere modificandoli. Integrazione DevOps: Funziona come knowledge base sicura per l'AI se integrata con strumenti di automazione come IBM Bob. Come modernizzare le interfacce IBM i (green screen) per il cloud senza rischiare falle di sicurezza? Per modernizzare le applicazioni IBM i in ottica cloud-ready senza esporre il sistema a vulnerabilità, è necessario utilizzare soluzioni di refactoring controllato come Presto. Questo strumento permette di convertire le schermate 5250 in interfacce web moderne e accessibili da browser o dispositivi mobili, mitigando il rischio informatico attraverso criteri precisi: Invariabilità del codice core: Trasforma l'interfaccia senza toccare la logica applicativa o il codice RPG sottostante. Mantenimento dei protocolli nativi:Preserva i sistemi di sicurezza originali di IBM i. Qual è il modo più sicuro per integrare le applicazioni IBM i con i servizi web e l'AI? Il metodo più sicuro e scalabile per integrare IBM i con l'ecosistema digitale esterno e l'AI è l'esposizione della logica di business tramite API controllate e standardizzate, strutturate con tool come WebSmart. Sviluppare endpoint API manualmente aumenta la superficie d'attacco. L'utilizzo di una piattaforma dedicata garantisce invece standard aziendali elevati: Industrializzazione dello sviluppo: Genera endpoint API stabili e applicazioni web partendo da programmi RPG esistenti. Standard di crittografia: Supporta nativamente protocolli JSON, XML e la crittografia SSL. Governance del ciclo di vita: Si integra con sistemi di Application Lifecycle Management (ALM) come TD/OMS, garantendo interfacce versionate e conformi alle policy di compliance. Quali strumenti rispondono alle tre domande strategiche del management sulla governance dei dati IBM i? L'articolo di Richard Dolewski è un bagno di realtà su quello che serve per non farsi travolgere dal cambiamento. E quello che serve, stringi stringi, si riassume in tre parole: Visibilità Controllo Governance dell'esposizione dei dati. I tre strumenti software fondamentali per garantire la governance del dato su IBM i in vista della rivoluzione AI sono X-Analysis, Presto e WebSmart. Ognuno di essi risponde a un preciso quesito di gestione del rischio e controllo del ROI: Cosa risiede nel mio sistema? X-Analysis, che offre visibilità e audit del patrimonio applicativo. Come posso dare accesso ai dati senza perdere il controllo? Presto, che modernizza l'accesso web mantenendo intatta la sicurezza core. Come posso integrare l'infrastruttura core con l'esterno in modo sicuro? WebSmart, che standardizza e protegge la creazione di API per far parlare IBM i con l'AI. Dolewski chiude il suo intervento con una domanda aperta: "Qual è la tua mossa in questa trasformazione tecnologica?". Vuoi scoprire come possiamo aiutarti ad un integrazione consapevole dell'AI?

Fino a ieri c’era un solo ingresso, la porta blindata del terminale 5250. Con l’AI, invece, si aprono tante finestre e porte: ODBC, SSH, DRDA, HTTP. Ogni finestra è comoda, ma anche un possibile punto d’ingresso per chi non deve entrare. In che modo l’adozione dell’AI su IBM i impatta la conformità? L’adozione dell’AI su IBM i moltiplica le vie di accesso al sistema (tramite ODBC, SSH, DRDA e HTTP), frammentando il vecchio perimetro protetto dei terminali 5250 e aumentando il rischio di non conformità alle direttive europee. Come evidenziato dall’esperto Richard Dolewski su IT Jungle, il modello nativo “Deny by Default” di IBM i non è più sufficiente da solo. L’introduzione di agenti AI richiede l’allineamento immediato a tre quadri normativi stringenti: NIS2 (Direttiva sulla Sicurezza delle Informazioni): impone obblighi severi sulla sicurezza della catena di approvvigionamento digitale e sulla gestione delle vulnerabilità. DORA (Digital Operational Resilience Act): richiede alle aziende del settore finanziario e ai loro fornitori ICT di garantire una resilienza operativa totale, con test d’impatto e gestione rigorosa del rischio d’accesso. GDPR (Regolamento Generale sulla Protezione dei Dati): esige l’applicazione tassativa dei principi di Privacy by Design e Privacy by Default, rendendo obbligatoria la pseudonimizzazione e il controllo di chi (o quale algoritmo AI) accede ai dati personali. Come supporta X-Analysis la Data Classification richiesta dal GDPR e dall’audit di DORA? X-Analysis automatizza l’auditing applicativo e la Data Classification negli ambienti RPG, COBOL e CA 2E, fornendo la prova documentale richiesta dai regolatori per gli audit DORA e per il principio di accountability del GDPR. Non è possibile proteggere o normalizzare le risorse informative di cui non si conosce l’esatta consistenza. X-Analysis mappa nativamente l’infrastruttura e fornisce elementi cruciali per la compliance: Mappatura del dato sensibile (GDPR): identifica la posizione esatta dei dati personali e sensibili all’interno dei database, tracciando le interdipendenze tra campi e variabili. Analisi d’impatto predittiva (DORA): documenta le vecchie regole di business stratificate nel codice e simula l’effetto domino di una modifica o di un accesso esterno, rispondendo direttamente ai requisiti di stress testing di DORA. Knowledge Base certificata per l’AI: integrandosi con strumenti DevOps come IBM Bob, garantisce che l’AI acceda esclusivamente a dati autorizzati e preventivamente catalogati. Come si possono modernizzare le interfacce green screen per l’AI rispettando i vincoli di accesso di NIS2 e GDPR? La modernizzazione delle vecchie schermate 5250 in ottica cloud e AI deve avvenire senza aumentare la superficie d’attacco, un obiettivo raggiungibile attraverso l’isolamento della logica core garantito da Presto. NIS2 e GDPR vietano l’esposizione diretta e non protetta di sistemi critici sul web. Presto mitiga questo rischio operativo attraverso logiche di conformità precise: Separazione dei livelli (Privacy by Design): trasforma l’interfaccia in un’applicazione web moderna e accessibile da browser o mobile, ma mantiene totalmente invariati il codice RPG sottostante e i protocolli di sicurezza nativi del sistema operativo. Qual è l’approccio più sicuro per sviluppare API su IBM i per l’AI in conformità con la direttiva NIS2? Per garantire la conformità alla direttiva NIS2 in termini di gestione delle vulnerabilità, lo sviluppo di API e microservizi per l’AI su IBM i deve essere industrializzato e standardizzato tramite piattaforme come WebSmart, escludendo tassativamente la programmazione manuale isolata. Creare endpoint API senza framework di controllo genera falle strutturali macroscopiche. WebSmart risponde ai requisiti NIS2 e DORA offrendo: Standardizzazione della sicurezza: genera endpoint API stabili partendo dai programmi RPG esistenti, integrando nativamente protocolli di crittografia SSL e formati sicuri JSON/XML. Tracciabilità del ciclo di vita (DORA): si integra con sistemi di Application Lifecycle Management (ALM) come TD/OMS. Questo assicura che ogni API esposta verso l’AI sia versionata, autorizzata, tracciabile e auditabile in qualsiasi momento in caso di ispezione. Quali strumenti rispondono ai requisiti di risk management imposti dalle normative europee? I tre strumenti software fondamentali per garantire la governance, mitigare il rischio sanzionatorio di NIS2, DORA e GDPR e preparare IBM i all’AI sono X-Analysis, Presto e WebSmart. Ciascuno risolve un pilastro specifico del risk management aziendale: Visibilità e Audit (GDPR/DORA): X-Analysis mappa il patrimonio informativo e scova i dati sensibili sepolti nel codice legacy. Resilienza dell’Accesso (NIS2/GDPR): Presto abilita la fruizione web e mobile dei dati bloccando l’accesso diretto alla logica core. Integrazione Sicura (NIS2/DORA): WebSmart standardizza, protegge e monitora le API che fanno dialogare IBM i con il resto dell’ecosistema digitale e con i modelli di intelligenza artificiale. Tabella normativa → rischio → strumento Normativa Cosa chiede in pratica Strumento Perché GDPR Sapere dove sono i dati personali e chi li tocca X-Analysis Mappa dati sensibili e dipendenze NIS2 Ridurre la superficie d’attacco e gestire le vulnerabilità Presto / WebSmart Espone in modo controllato, standardizza le API DORA Resilienza, test d’impatto, tracciabilità X-Analysis + WebSmart Analisi d’impatto e API versionate/auditabili Esempio concreto Un agente AI deve leggere le fatture per automatizzare la contabilità. Senza X-Analysis non sai quali campi contengono dati personali o IBAN. Senza Presto rischi di esporre direttamente le schermate green. Senza WebSmart qualcuno crea API a mano, senza versioning né audit. Con i tre strumenti: prima mappi, poi esponi in modo protetto, infine costruisci API tracciate. L’AI lavora, ma tu resti al comando. L’AI non è pericolosa in sé. È pericoloso darle chiavi che non controlli. X-Analysis, Presto e WebSmart non sono “accessori” per modernizzare: sono gli strumenti che ti danno visibilità, controllo e tracciabilità prima di aprire IBM i all’intelligenza artificiale. Vuoi scoprire come possiamo aiutarti ad un integrazione consapevole dell'AI? CONTATTACI bigblue | AS400 | IBM i | AI | Sicurezza Aziendale

IL PHP non è morto. È pronto per l’IA. Mentre Python e Node.js conquistano spazio sulla piattaforma IBM i, PHP continua a essere il motore silenzioso di migliaia di applicazioni web aziendali. E con l’arrivo imminente di PHP 8.6, previsto per la fine del 2026, il linguaggio si prepara a un salto di qualità che cambierà il modo in cui sviluppatori e agenti IA interagiscono con il codice. Dietro questa evoluzione c’è una regia precisa: Seiden Group. Alan Seiden, fondatore, e il suo team - tra cui Calvin Buckley- stanno plasmando il futuro di PHP su IBM i. La loro distribuzione Seiden PHP+ è già disponibile in beta per PHP 8.6, e le novità introdotte non sono pensate solo per gli esseri umani, ma anche per l’intelligenza artificiale. Il contributo di Seiden: non solo manutenzione, ma visione Seiden Group non si limita a fornire una versione di PHP per IBM i. Alan Seiden è da anni una delle voci più autorevoli sulla modernizzazione della piattaforma, e il suo contributo va ben oltre il codice. Seiden PHP+ è una distribuzione pronta all’uso che semplifica installazione, aggiornamento e supporto di PHP su IBM i. La beta di PHP 8.6 è già testabile, permettendo alle aziende di anticipare le novità e ridurre i rischi di migrazione. Seiden insiste su un punto cruciale: aggiornare una release minore all’anno. “Se aspetti troppo, sei fuori dalla conformità di sicurezza e hai un lavoro più grande da recuperare”, avverte. Ma c’è un altro aspetto, forse ancora più strategico. Secondo Seiden, l’IA è la chiave per gestire la transizione verso PHP 9.0. “L’IA è molto competente su PHP e può aiutare a trovare quelle strutture di codice obsolete da aggiornare per le nuove versioni”, spiega. In pratica, Seiden non sta solo mantenendo PHP su IBM i: sta gettando le basi per un futuro in cui l’IA affianca — o sostituisce — parte del lavoro di manutenzione. Debugging potenziato dall’IA: la modifica di Calvin Buckley La novità più interessante di PHP 8.6 non riguarda la sintassi, ma la capacità di comunicare meglio con l’intelligenza artificiale. Calvin Buckley, membro del team Seiden Group, ha contribuito a una modifica epocale: quando una funzione PHP genera un errore, ora il sistema mostra esattamente quali parametri sono stati passati alla funzione nel momento del fallimento. Perché è rivoluzionario? Perché non aiuta solo gli sviluppatori umani. Come spiega Alan Seiden: “Molti miglioramenti sono pensati per gli esseri umani, dare più informazioni sugli errori permette all’IA di fare correzioni automatiche.” Immagina un agente IA che analizza un errore PHP: invece di ricevere un messaggio generico, ottiene il contesto completo dei parametri JSON passati alla funzione. Può così identificare la causa esatta e proporre una correzione mirata, senza tentativi ed errori. È il debug che diventa conversazione tra codice e intelligenza artificiale. Sicurezza Sessioni più robuste by default PHP 8.6 introduce impostazioni di sessione sicure fin dall’installazione. Le nuove configurazioni predefinite mitigano rischi comuni come: Session fixation: session.use_strict_mode passa da 0 a 1 per impostazione predefinita. Furto di cookie via JavaScript: session.cookie_httponly viene attivato di default. Attacchi CSRF: protezione integrata per scenari cross-site request forgery. Queste modifiche, sebbene tecniche, hanno un impatto enorme sulla sicurezza delle applicazioni IBM i esposte sul web. Non più configurazioni manuali dimenticate: la sicurezza diventa il comportamento predefinito. Performance JSON più veloce e output più leggibile Le applicazioni moderne su IBM i comunicano sempre più tramite API REST e JSON. PHP 8.6 ottimizza la codifica JSON di array e oggetti, riducendo i tempi di elaborazione per le risposte API. Inoltre, PHP_JSON_PRETTY_PRINT — la funzione che formatta il JSON per renderlo leggibile — diventa più performante, un vantaggio concreto per debug e log analysis. PHP 9.0 Cosa aspettarsi e come prepararsi Se PHP 8.6 è un aggiornamento incrementale, PHP 9.0 sarà un cambio di paradigma. Alan Seiden avverte: “Quando uscirà la versione 9, potrebbero esserci breaking changes”. Le release minori (8.5, 8.6) introducono warning su pratiche di coding obsolete, ma non le rimuovono. Con PHP 9.0, tutte le funzionalità deprecate tra PHP 8.1 e 8.4 verranno rimosse. Questo significa che il codice che oggi funziona con semplici avvisi potrebbe smettere di funzionare completamente. La buona notizia? L’IA è la chiave per gestire questa transizione. E Seiden Group è già un passo avanti. PHP + IA + Seiden = il futuro di IBM i PHP su IBM i non è una reliquia del passato. È una piattaforma matura, sicura e pronta per l’era dell’intelligenza artificiale. Con PHP 8.6, il linguaggio non solo migliora per gli umani, ma diventa nativamente più compatibile con gli agenti IA che sempre più spesso affiancano — o sostituiscono — gli sviluppatori nelle attività di manutenzione e modernizzazione. E il contributo di Seiden Group è centrale: dalla distribuzione Seiden PHP+ alla beta di PHP 8.6, dalla consulenza sulla sicurezza all’uso dell’IA per migrare codice obsoleto. Alan Seiden e il suo team non stanno solo seguendo l’evoluzione: la stanno guidando. La domanda non è più “PHP è ancora rilevante su IBM i?”. La domanda è: quanto velocemente puoi sfruttare l’IA e il supporto di Seiden per portare le tue applicazioni PHP alla versione 8.6? Non aspettare. Aggiorna. E lascia che l’IA — e Seiden — ti mostrino la strada. Tratto dall'articolo L'evoluzione di PHP sulla piattaforma IBM i continua 28 settembre 2026 Alex Woodie bigblue ha un'esperienza di sviluppo su PHP di oltre un decennio. Scopri come possiamo aiutarti per un' integrazione del PHP e dell'AI? CONTATTACI www.bigblue.it

Il vero punto debole dell'innovazione nell'AI è l'orchestrazione. In questo articolo vedremo come Vimec sia riuscita ad orchestrare API e AI con tool open source. Alla Vimec abbiamo messo insieme prima di tutto l'orchestratore n8n visuale, e con quello abbiamo gestito API, AI e web services. Il vero problema da risolvere alla Vimec. Vimec è un'azienda che da oltre 45 anni progetta ascensori, montascale e soluzioni per la mobilità. Ha CRM, ERP, sistemi IoT, ordini, assistenza clienti. Parlano lingue diverse, spesso vecchie, spesso scomode. Il classico scenario dove l'integrazione ti costa più del software che vuoi integrare. Il punto debole dell'AI non è l'AI stessa. Oggi tutti parlano di modelli, di agenti, di prompt. Pochi parlano di chi li fa parlare tra loro. L'intelligenza artificiale in azienda non serve a nulla se non è collegata ai sistemi che generano i dati e alle azioni che devono succedere dopo. Il collo di bottiglia non è il modello ma l'orchestrazione. Il ruolo di n8n L'orchestrazione visuale, nodi pronti, possibilità di infilare codice quando serve. Il nodo HTTP Request, da solo, ti apre a qualsiasi web service. Anche quelli legacy. Anche quelli che nessuno vuole più toccare. Ma n8n da solo non basta. Ti serve qualcuno che controlli, monitori, fermi e riavvii. Che dia visibilità end-to-end. E che permetta a un agente AI di attivare un workflow senza che tu debba scrivere mezzo codice. Il ruolo del team Il team rappresenta la regia. Il cervello sopra il motore. Mentre n8n esegue, il team deve tenere le fila: metriche, controllo dei run, triggering intelligente, integrazione nativa con l'AI. Una roba che in ambienti enterprise fa la differenza tra "automazione carina" e "automazione che puoi mettere in produzione senza tremare". Non serve riscrivere nulla Nulla. E questa è la parte che mi piace di più. Abbiamo collegato. Abbiamo orchestrato. Abbiamo lasciato che l'AI entrasse dentro il flusso, non come layer separato, ma come nodo che decide, suggerisce, corregge. I risultati concreti Maggiore semplicità e grande risparmio su budget. Pochi giorni di lavoro al posto di settimane passate a integrare, più ore guadagnate in controllo. Più scalabilità. Più capacità di adattarsi. E un partner che non ti vende una scatola, ma ti accompagna in un modo di lavorare che è già avanti. Se anche tu hai webservices che non si parlano, API che ballano da sole e un'AI che vorresti usare ma non sai da dove far entrare, è arrivato il momento di parlarne. SCOPRI COME POSSIAMO AIUTARTI. CONTATTACI bigblue | n8n | API | AI | Vimec | Automazione | WebServices | Orchestrazione | DigitalTransformation | AS400 | IBM i

L’AI scrive il codice in cinque secondi, quindi è naturale pensare che lo sviluppo software manuale non abbia più senso Basta chiedere e arriva il codice: perfetto, pulito, funzionante. Se guardi i pezzi isolati, assolutamente: l’AI è davvero brava a creare una funzione, un componente o una classe. Ma i sistemi complessi hanno bisogno di qualcosa di più: Coerenza Contesto Memoria Cose che l’AI da sola non ha, e che portano per assurdo da un aumento dei costi vediamo perché con 3 esempi semplici semplici: ESEMPIO 1 Vuoi costruire una casa: Hai dei muratori robot superveloci ordini al robot muratore: “Fammi una parete con una finestra”. Cinque secondi dopo la parete è lì, dritta, levigata, finestra nel punto giusto. Se la guardi da sola, è perfetta. Ha superato quello che in gergo si chiama “test del singolo pezzo”. Ma tu devi costruire una casa intera: Devi coordinare i robot altrimenti cosa succede : Il primo fa la finestra esattamente dove hai chiesto Ma il secondo sta facendo passare i cavi elettrici proprio in mezzo alla finestra Un terzo costruisce una porta che si apre sul vuoto al secondo piano. Il risultato è che hai risparmiato tempo nella posa dei mattoni, ma ora devi pagare un esercito di ingegneri che girano per il cantiere per controllare che la casa non crolli. Il costo non è sparito. Si è spostato ed è pure aumentato. ESEMPIO 2 Creare un romando Chiedi all’AI di scriverti un libro. In cinque minuti ti genera cinquanta capitoli. Sembra tutto perfetto ma poi però leggendo tutto il libro, scopri che il protagonista muore al capitolo 2 e ricompare al capitolo 10 senza spiegazioni. La storia parte da Roma, ma al capitolo 15 siamo a Tokyo e nessuno ha preso un aereo. La trama non sta in piedi. E qui arriva il punto: correggere, revisionare e far tornare la storia di cinquanta capitoli generati in blocco richiede molto più tempo, più concentrazione e più soldi di quanti ne avresti spesi per pianificare il libro con una scaletta chiara fin dall'inizio. L’AI quindi ti ha fatto risparmiare sulla scrittura, ma ti ha fatto spendere il doppio sulla revisione. ESEMPIO 3 Un’orchestra senza direttore. Hai cinquanta musicisti talentosi. Ognuno impara la sua parte a memoria in dieci secondi e la suona in modo impeccabile. Se li ascolti uno per uno, sono perfetti. Ma se li metti tutti nella stessa stanza e dici a ciascuno di iniziare a suonare senza uno spartito condiviso, ottieni un caos assordante. Ognuno va al proprio ritmo, usa una tonalità diversa, non ascolta gli altri. Il costo non è più insegnare ai singoli musicisti a muovere le dita. Il costo è ingaggiare direttori d’orchestra e coordinatori che definiscano lo spartito condiviso e controllino che l’insieme produca armonia, non rumore. Nel software, questi coordinatori sono gli architetti, i registri delle decisioni, i contratti tra i moduli. L’AI non può inventarsi da sola, perché non sa cosa è stato deciso ieri, non sa perché una certa scelta è stata fatta, non sa quale sia il vincolo nascosto. Spiegarle e istruirla richiederebbe molto tempo e nessuna garanzia di avere un buon risultato. Il punto è che l’AI eccelle nel “come”. Le chiedi di scrivere una funzione e la scrive. Le chiedi di generare un modulo e lo genera. Ma l’AI fallisce sul “perché”. Non ha il contesto. Non ha la memoria del progetto. Non sa nulla delle decisioni prese sei mesi fa in una riunione. Non sa perché una certa API è stata disegnata in un modo e non in un altro. Non sa quali sono i vincoli architetturali che tengono insieme il sistema. È come un assistente brillante ma smemorato: ti risolve il problema immediato, ma non capisce le conseguenze a lungo termine. E qui veniamo al testing, che è forse la parte più sottovalutata. I programmi tradizionali sono come una calcolatrice: premi 2+2 e ottieni sempre 4. Fare un test è facilissimo. L’AI, invece, assomiglia più a un assistente umano: se gli fai la stessa domanda dieci volte, ti risponderà in modi leggermente diversi. Il 90% delle volte ti dà la risposta perfetta, ma il 10% delle volte potrebbe inventarsi qualcosa. Si chiama allucinazione. Il costo del testing non diminuisce: aumenta. Perché non puoi più fare un singolo controllo veloce “giusto/sbagliato”. Devi creare test molto più complessi e continui, chiamati Evals, che provano centinaia di casi reali per misurare la percentuale di affidabilità nel tempo. È un lavoro probabilistico, non deterministico. E richiede tempo, soldi e teste pensanti. Con l’AI fabbricare i singoli mattoni è diventato facilissimo e quasi gratis. Ma assicurarsi che i mattoni formino un edificio sicuro, logico e senza crepe è diventato il lavoro più difficile e costoso. L’AI automatizza la scrittura materiale dell’implementazione, il “come”, ma rende estremamente costoso e critico il giudizio, il “perché”. Senza barriere e controlli automatizzati nelle pipeline, la velocità dell’AI rischia di produrre un’erosione della struttura del sistema a un ritmo mai visto prima. Il Free ebook di Oleksiy Pylypenko Software Architecture in the AI & Cloud Era the road to platform architecture 15 chapters · Puoi scaricarlo direttamente da qui: FAQ Perché l’AI da sola non basta? L’AI scrive codice in 5 secondi, ma il software è un sistema. Domande e risposte su coerenza, testing, Evals, allucinazioni e ruolo umano nello sviluppo con l’intelligenza artificiale. Cosa significa “test del singolo pezzo” quando si parla di AI? Significa che un componente isolato può funzionare perfettamente. Una funzione, una classe o un modulo possono superare il test locale, ma questo non garantisce che l’intero sistema funzioni. Dove si sposta il costo quando si usa l’AI per programmare? Il costo si sposta dalla scrittura del codice alla verifica, all’integrazione, all’architettura e al testing. Fabbricare i mattoni è quasi gratis; assicurarsi che formino un edificio sicuro è la parte più costosa. Perché i test con l’AI sono più difficili? Perché l’AI è probabilistica, non deterministica. Come una calcolatrice, un programma tradizionale dà sempre 2+2=4. L’AI può dare risposte leggermente diverse: il 90% perfette, il 10% allucinazioni. Cosa sono gli Evals nell’AI? Sono test continui e complessi che provano centinaia di casi reali per misurare l’affidabilità nel tempo. Non bastano più i controlli “giusto/sbagliato”: serve una valutazione probabilistica. Ruolo degli umani nell’era dell’AI nello sviluppo software. Definire il “perché”: architettura, regole, contratti, fitness functions, governance e revisione. L’umano deve orchestrare, non solo scrivere codice. Contatti 🌐 www.bigblue.it 📧 info@bigblue.it 📞 0423 605099 Richiedi una demo con un nostro esperto e scopri come puoi ridurre il debito tecnico della tua azienda. Risorse e Approfondimenti Scopri di più su WebSmart Tutte le nostre soluzioni Articolo: Il debito tecnico nell'era dell'AI

Cosa è un As400 Nel 1988, quando il mondo dell'informatica era dominato da mainframe e terminali verdi, IBM lanciò l'AS/400. Nessuno avrebbe scommesso che, a oltre trentacinque anni di distanza, quella stessa piattaforma sarebbe stata ancora al centro delle strategie IT delle più grandi aziende del mondo. Eppure è proprio così. L'AS/400, oggi noto come IBM i, non solo è sopravvissuto al passare del tempo, ma ha vissuto una vera e propria rinascita. Il merito? In larga parte, del cloud. Non è un paradosso. AS400 è la dimostrazione che quando una tecnologia è solida, affidabile e ben progettata, non va sostituita: va evoluta. E il cloud, oggi, è il motore di quell'evoluzione. Vediamo come, rispondendo alle domande che probabilmente ti stai facendo. Cos'è esattamente l'AS/400 (IBM i)? L'AS/400, acronimo di Application System/400, è una piattaforma informatica sviluppata da IBM negli anni '80. Nasce come un sistema integrato: hardware e software in un unico ambiente, progettato per offrire alle aziende stabilità, sicurezza e scalabilità. Oggi, dopo vari rebranding (iSeries, System i), si chiama IBM i e gira su hardware IBM Power Systems. Ma il cuore è lo stesso: un sistema operativo robusto, un database integrato (DB2) e una capacità di gestire grandi volumi di transazioni che pochi altri sistemi possono eguagliare. Per questo motivo, l'IBM i è ancora oggi il sistema scelto da banche, assicurazioni, pubbliche amministrazioni e grandi imprese in tutto il mondo. Perché l'AS/400 è ancora così diffuso? La risposta è semplice: funziona. E funziona meglio di molti sistemi moderni. L'AS/400 è stato progettato per essere: Affidabile: uptime misurato in anni, non in giorni. Sicuro: un'architettura che lo rende intrinsicamente protetto. Scalabile: capace di crescere con l'azienda senza stravolgimenti. Economico: un'indagine del 2025 ha rilevato che il 96% delle aziende che lo utilizzano dichiara un ROI migliore rispetto ad altre piattaforme server. In un'epoca in cui la continuità operativa è tutto, l'IBM i rappresenta una garanzia che pochi altri sistemi possono offrire. Come è cambiato l'AS/400 nel tempo? L'AS/400 non è rimasto fermo. Nel corso degli anni, IBM lo ha aggiornato e rinominato più volte: prima iSeries nei primi anni 2000, poi System i, e infine IBM i nel 2008. Ma il cambiamento più significativo non è stato nel nome. È stato nella capacità di integrarsi con le tecnologie moderne senza perdere la compatibilità con le applicazioni legacy. Oggi, l'IBM i può: Essere deployato su cloud pubblici e privati Integrarsi con API e microservizi Supportare ambienti ibridi on-premise e cloud Essere modernizzato con strumenti no-code e low-code In pratica, l'IBM i di oggi è lo stesso sistema di sempre, ma con superpoteri in più. Cosa significa "rinascita nel cloud"? Per decenni, l'AS/400 è stato un sistema on-premise: hardware dedicato, sale server, manutenzione interna. Oggi, grazie al cloud, le aziende possono ospitare i propri IBM i su infrastrutture cloud, beneficiando di: Flessibilità: si paga per ciò che si usa, senza investimenti iniziali. Scalabilità: si cresce senza dover acquistare nuovo hardware. Affidabilità: i data center cloud offrono livelli di disponibilità elevatissimi. Sicurezza: protocolli crittografati e conformità alle normative. Accesso a talenti giovani: i professionisti IT sono attratti dal cloud e dalle tecnologie moderne. Inoltre, il cloud permette di modernizzare l'IBM i in modo graduale: si può partire da un ambiente ibrido, per poi spostare completamente i carichi di lavoro nel cloud quando si è pronti. Il cloud è la soluzione per tutti? Il cloud non è una bacchetta magica, ma per la stragrande maggioranza delle aziende che utilizzano IBM i rappresenta un'opportunità straordinaria. Le aziende che scelgono di portare il proprio IBM i nel cloud ottengono: Riduzione dei costi operativi: meno hardware, meno manutenzione, meno energia. Maggiore agilità: si possono sperimentare nuove funzionalità senza rischi. Integrazione più semplice: connettere l'IBM i con altre piattaforme cloud-native diventa immediato. Preparazione al futuro: l'IBM i nel cloud è pronto per l'AI, l'analisi dei dati e le architetture moderne. Il cloud non cancella il valore dell'IBM i. Lo amplifica. Conclusione: il futuro dell'IBM i è (anche) nel cloud L'AS/400 ha compiuto più di trentacinque anni. In un settore dove le tecnologie cambiano ogni pochi anni, è un record che pochi possono vantare. E non è un caso. L'IBM i è sopravvissuto perché è solido, sicuro, affidabile. E oggi, grazie al cloud, ha trovato una nuova giovinezza. Non si tratta di sostituire il sistema, ma di dargli una nuova casa: più flessibile, più scalabile, più moderna. Il cloud non è la fine dell'IBM i. È il suo nuovo inizio. 📢Scopri come bigblue può aiutarti a portare il tuo IBM i nel cloud e a trasformare un sistema legacy in un motore di innovazione per la tua azienda. Da oltre 25 anni accompagniamo aziende come Prada, Luxottica, Fineco Bank nella trasformazione digitale. Prenota una consulenza gratuita Scopri chi siamo → CONTATTACI #IBMi #AS400 #DigitalTransformation #InnovazioneDigitale #PMI #ITStrategy #Modernizzazione

La conoscenza che vive in una testa sola non è un asset. È un *rischio**.* Hai le policy. Hai il registro delle modifiche. Hai il bollino di conformità NIS2 appeso in bacheca. Sulla carta, sei in regola. Ma c'è una domanda che dovresti farti prima di chiudere il laptop stasera: riguarda quella bomba a orologeria che nessuno in azienda vuole toccare, il sistema IBM i (AS/400) che nessuno padroneggia più completamente. La prova del nove Immagina che domani mattina uno sviluppatore modifichi un programma RPG. Riesci a dire, adesso, prima che accada: Quali flussi si interromperebbero? Quali applicazioni web smetterebbero di dialogare con il DB2? Quale webservice andrebbe in tilt perché si appoggiava a quelle credenziali ODBC ferme dal 2016? Se per rispondere devi convocare "quello che c'era una volta" o sfogliare una documentazione aggiornata l'ultima volta durante il passaggio all'euro, allora non hai un controllo. Hai una speranza. E la speranza non è un framework di sicurezza. Il change management come teatro Questo è il punto che fa male. Buona parte delle procedure di change management sull'IBM i è, di fatto, una recita. La platea è soddisfatta, l'auditor firma, le luci si spengono. Poi resta la verità: nessuno sa davvero cosa tiene in piedi quel sistema. La conoscenza vive nella testa di due persone. Una è già in pensione. L'altra ha un piede fuori dalla porta. È una configurazione che ha funzionato per vent'anni per pura inerzia, ma che con la NIS2 diventa insostenibile. Cosa chiede davvero la NIS2 La direttiva non si accontenta della recita. L'art. 21 impone di governare e tracciare le modifiche che incidono sulla sicurezza. Ma non puoi governare ciò che non conosci, e non puoi tracciare l'impatto di una modifica se ignori cosa quella modifica va a toccare. Senza una mappa reale delle dipendenze, la tracciabilità è solo una casella spuntata. E qui arriva il colpo che quasi nessuno mette in conto: la NIS2 ti chiama in causa anche per le modifiche che NON fai. Credenziali di servizio mai ruotate. Connettori legacy mai aggiornati. Sistemi lasciati intoccati perché "se li tocchiamo non sappiamo cosa succede". Quel "non sappiamo cosa succede" non è prudenza operativa: in sede di vigilanza suona esattamente per ciò che è, ovvero la confessione di una carenza di sicurezza. E adesso la parte che riguarda te, personalmente Con la NIS2, la responsabilità esce dal recinto dell'IT. L'art. 20 coinvolge direttamente gli organi di gestione, chiamati ad approvare e vigilare sulle misure di sicurezza. Per il CISO e per chi guida l'azienda, questo si traduce in tre rischi molto concreti: Sanzioni pesanti. Fino a 10 milioni di euro o al 2% del fatturato mondiale annuo per i soggetti essenziali. Non è un'ipotesi teorica: è la cifra che l'autorità può effettivamente comminare. Responsabilità personale dei vertici. L'autorità competente può ritenere gli organi direttivi responsabili della violazione degli obblighi e, nei casi più gravi, sospenderne temporaneamente le funzioni dirigenziali. Il "non lo sapevo" ha smesso di essere una difesa: la formazione e la vigilanza sono un obbligo esplicito. L'impossibilità di dimostrare la diligenza. Se dopo un incidente non riesci a produrre l'impact analysis, il grafo delle dipendenze e la tracciabilità delle modifiche, non hai modo di provare di aver agito con diligenza. E in sede ispettiva, l'onere della prova è tuo. Tradotto senza giri di parole: se il controllo sul tuo IBM i vive nella testa di una persona sola, quella persona non è un rischio operativo. È il tuo rischio personale. Smetti di indovinare con X-Analysis È esattamente qui che uno strumento di analisi del codice cambia le regole del gioco. X-Analysis ti restituisce la conoscenza che oggi è dispersa o dimenticata: Analisi statica del codice, per capire cosa fa davvero ogni programma RPG, COBOL o CL. Grafo automatico delle dipendenze, che mostra chi chiama cosa e cosa succede se lo tocchi. Impact analysis reale prima di ogni riga modificata, così sai in anticipo cosa crolla e cosa regge. La mappa autentica di come il tuo mondo web dialoga con il legacy, DB2 e connettori compresi. Non la documentazione che pensavi di avere. Quella che hai davvero. Chiamarlo semplicemente "compliance" è riduttivo. È la differenza tra sapere cosa accade quando premi il pulsante e chiudere gli occhi sperando che il sistema regga un altro giorno. Ultima domanda, zero retorica: Il controllo sul tuo IBM i è un processo documentato e verificabile, o ti affidi ancora alla memoria di chi sta per andare in pensione? Se vuoi la risposta scritta nera su bianco, e opponibile a un auditor, parliamone. SCOPRI COME POSSIAMO *AIUTARTI* Prenota una consulenza gratuita Scopri chi siamo → NIS2 | Cybersecurity | IBM i | AS400 | Compliance | ChangeManagement