- La IA local no és segura per defecte: requereix segmentació de xarxa, hardening i control d'accessos.
- És clau limitar el trànsit amb VLANs i tallafocs, registrar interaccions i aplicar polítiques DLP.
- Hi ha amenaces específiques de models locals com agents dorments i models trampa.
- Un enfocament en capes, alineat amb RGPD i bones pràctiques de ciberseguretat, redueix dràsticament el risc.
L'adopció de models de intel·ligència artificial en local s'ha disparat en empreses i professionals que manegen informació delicada: dades personals, expedients mèdics, documentació legal, propietat intel·lectual… Molts pensen que, pel simple fet d'executar la IA als seus propis servidors o equips, la privadesa està garantida. La realitat és força més complexa: un desplegament mal dissenyat es pot convertir en una porta d'entrada a ciberatacs o en una màquina de filtrar dades sense que ningú se n'adoni.
Si vols aprofitar al màxim la IA sense posar en risc el teu negoci, és clau entendre que la seguretat en utilitzar IA en local no consisteix només a “treure internet” al model. Cal pensar en arquitectura de xarxa, hardening de sistemes, control d'accessos, compliment normatiu (com RGPD), monitorització contínua i defensa davant d'amenaces molt específiques dels models, des d'agents dorments fins a models trampa entrenats per exfiltrar informació.
Per què la IA en local no és automàticament segura
La IA executada en servidors propis ofereix avantatges clars: més control, més personalització i, en teoria, més privadesa. Però aquests beneficis porten associats riscos que moltes vegades es passen per alt, sobretot quan es reutilitzen scripts o contenidors sense revisar la seguretat de contenidors ni el seu comportament real a la xarxa.
Un model de llenguatge o un assistent de IA pot tenir accés a documentació interna, bases de dades amb informació personal, repositoris de codi o informes estratègics. Si el sistema que l'executa està mal segmentat, si el tallafoc està obert de més o si el model té comportaments ocults, aquesta IA que creies “offline” pot acabar enviant dades sensibles a l'exterior o exposant-les a usuaris no autoritzats.
A més, els models locals depenen d'un ecosistema de programari d'inferència, llibreries i servidors d'aplicació (FastAPI, Uvicorn, frameworks web, runtimes de GPU, etc.) que, com qualsevol altre programari, requereix avaluar la seguretat del programari i té vulnerabilitats, bugs i problemes de configuració. No actualitzar aquests components, o no aplicar un maquinari adequat, deixa un blanc perfecte per a atacants.
Per si no n'hi hagués prou, avui dia és tècnicament possible que un model hagi estat modificat per introduir comportaments maliciosos que només s'activen sota certes condicions: prompts concrets, noms de projectes, dates o fins i tot patrons de trànsit. Per això, “abaixar un model d'internet i muntar-lo a local” sense més controls és una aposta molt arriscada.
Arquitectura segura per a un chatbot d'IA a la xarxa corporativa
Un cas típic és un chatbot d'IA desplegat a la pròpia empresa per consultar documentació interna, gestionar un gestor documental o assistir empleats. Perquè aquest sistema no es converteixi en colador de dades, cal dissenyar una arquitectura de xarxa i seguretat específicament pensada per aïllar-lo de l'exterior i controlar qui es connecta i què pot fer.
Imagina una empresa que munta un chatbot basat en un model com a Truca 3 o DeepSeek en un servidor local. Aquest servidor processa contractes, expedients de clients, polítiques internes i dades dels empleats. Si el vostre trànsit no es segmenta ni es filtra, n'hi ha prou amb un equip intern infectat o una mala configuració de tallafocs perquè aquest bot acabi exposant informació crítica.
La proposta més robusta passa per ubicar el servidor d'IA en una VLAN específica i aïllada, sense accés directe a internet, i controlar totes les comunicacions que entrin i surtin d'aquesta VLAN mitjançant un tallafoc central. A més, l'accés d'usuaris sempre ha d'anar autenticat contra un Directori Actiu (AD/LDAP) o sistema equivalent, per tenir traçabilitat de qui fa què.
Aquest enfocament d'“IA en una bombolla” permet que el chatbot només parli amb els sistemes interns estrictament necessaris: la base de dades que indexa la documentació, el servidor d'autenticació i les estacions de treball des de les quals es connecten els empleats. Tota la resta, inclosa qualsevol sortida cap a internet, ha d'estar bloquejada per defecte.
Segmentació de xarxa i VLANs: posar barreres físiques a la IA
La segmentació de xarxa mitjançant VLANs és una de les mesures més efectives per limitar la superfície d'atac. En comptes de tenir tota l'empresa en una xarxa plana, se separen les funcions crítiques a diferents segments amb regles d'accés molt precises.
Un disseny d'exemple podria ser el següent: una VLAN d'usuaris on s'ubiquen els equips de treball habituals; una VLAN de servidors d'IA i bases de dades sense connectivitat a internet; una VLAN d'administració des d'on només el personal tècnic pot gestionar la infraestructura; i, si cal, una VLAN de convidats sense accés al chatbot ni a recursos interns sensibles.
En termes d'adreçament IP, cada VLAN opera amb un rang diferent (per exemple, 192.168.10.0/24 per a usuaris, 192.168.20.0/24 per a servidors d'IA, 192.168.30.0/24 per a administració i 192.162.40.00) El servidor del xatbot podria residir en una adreça com 192.168.20.10, la base de dades a 192.168.20.20 i el controlador de domini a 192.168.30.10, mentre que els usuaris interns se situen en el segment 192.168.10.0/24.
Amb aquesta segmentació, un portàtil infectat connectat a la xarxa de convidats, per exemple, no podrà arribar al servidor dIA ni encara que conegui la seva IP. I un usuari intern necessitarà tant estar a la VLAN correcta com autenticar-se amb les seves credencials per obtenir accés. D'aquesta manera, fins i tot si un equip és compromès, l'atacant es trobarà amb múltiples capes d'aïllament abans darribar a la IA ia les dades que maneja.
Ports, tallafocs i regles de trànsit: què es permet i què es bloqueja
Un cop definida la segmentació, el següent pas és concretar què ports TCP/IP es permetran entre cada component i bloquejaran tota la resta. El principi és senzill: només s'obre allò imprescindible perquè la solució funcioni.
Per exemple, els usuaris a la VLAN 10 poden accedir al chatbot a la VLAN 20 a través del port 5000, on sol exposar-se una API (FastAPI, Uvicorn o una altra tecnologia similar). El servidor d'IA es comunica amb la base de dades a la mateixa VLAN mitjançant el port 5432, típic de PostgreSQL. Per autenticar usuaris, el chatbot es connecta amb el Directori Actiu a la VLAN 30 usant el port 389 (LDAP).
Els administradors, només des de la VLAN 30, poden obrir sessions SSH al servidor d'IA a través del port 22, però aquest accés ha d'estar restringit per origen i autenticat amb claus robustes. Qualsevol altre tipus de trànsit entre VLANs es denega, i especialment es bloqueja tota sortida del servidor d'IA cap a internet, de manera que, encara que el model o alguna eina intentés “trucar a casa”, el tallafocs ho impediria.
Les regles bàsiques que cal aplicar serien: negar per defecte totes les connexions entrants des de l'exterior cap a la xarxa interna; impedir que el servidor del chatbot estableixi connexions de sortida a Internet; permetre només les comunicacions internes estrictament necessàries entre VLANs; i registrar tots els accessos rellevants al tallafocs o en una solució SIEM per poder auditar incidents.
Control d'accessos: Directori actiu, rols i autenticació robusta
L'aïllament de xarxa es complementa amb un estricte control de qui pot interactuar amb la IA i quin tipus d'informació pot sol·licitar. Aquí entra en joc el Directori actiu o un servei LDAP similar, que centralitza l'autenticació i l'autorització.
La idea és que cada empleat s'identifiqui al chatbot amb les seves credencials corporatives, i que el sistema consulti el directori per comprovar a quins grups pertany. Segons aquests grups (per exemple, Recursos Humans, Suport, Direcció, Convidats), el chatbot limitarà les consultes i accions permeses, de manera que un empleat d'atenció al client no pugui accedir a dades de nòmines o reports financers interns.
A més, resulta molt recomanable aplicar-ne una autenticació multifactor (MFA) almenys per als perfils amb més privilegis i per a aquells que puguin manejar informació molt sensible. També cal aplicar polítiques de mínim privilegi: donar a cada usuari només el nivell d'accés imprescindible per al seu rol.
Paral·lelament, es poden definir rols específics dins de la pròpia aplicació d'IA, de manera que el model sàpiga quin tipus de respostes pot oferir a cada grup. Un exemple: el grup de recursos humans pot preguntar per polítiques internes de vacances o per procediments de contractació; l'equip tècnic per manuals i documentació de sistemes; la gerència per panells dindicadors interns agregats; i els usuaris convidats queden simplement sense accés al chatbot.
Monitorització, registres i resposta davant d'activitat sospitosa
Per molt ben dissenyat que estigui l'entorn, sempre hi ha la possibilitat que algú intenti abusar del sistema o que aparegui un comportament anòmal. Per això és imprescindible comptar amb una monitorització contínua de les interaccions amb la IA i amb un mecanisme de resposta automatitzada.
L'ideal és registrar detalladament cada conversa o consulta: qui l'ha fet (usuari autenticat), des de quin dispositiu o IP, què ha preguntat, què ha respost el model i en quin moment. Aquests registres s'envien a una plataforma SIEM com Splunk, ELK Stack, Wazuh o Graylog, que permet analitzar grans volums de logs i detectar patrons sospitosos.
Entre els comportaments que cal vigilar destaquen: consultes repetitives sobre temes extremadament sensibles en curts períodes; intents reiterats de demanar dades personals concretes (números de compte, DNIs, contrasenyes…); accessos fora dhorari laboral des dequips poc habituals; o canvis sobtats al tipus de preguntes d'un usuari que abans tenia un ús normal.
Quan es detecta una anomalia, el sistema hauria de generar immediatament una alerta als responsables de seguretat i, en funció de la gravetat, desencadenar accions automàtiques: mostrar missatges d'advertiment a l'usuari, sol·licitar una autenticació extra, bloquejar temporalment l'accés o escalar l'incident a RH o al departament legal si sembla un intent deliberat d'exfiltració.
Prevenció de fugida de dades (DLP) aplicada a models d'IA
Una de les preocupacions més grans amb la IA en local és que el mateix model acabi tornant en les seves respostes dades que mai haurien de sortir de certs sistemes: dades financeres, informació personal identificable o secrets de negoci. Per evitar-ho, es poden aplicar polítiques de Data Loss Prevention (DLP) directament sobre les sortides del model.
Aquestes polítiques consisteixen a analitzar les respostes generades per l'IA abans de mostrar-les a l'usuari. Si es detecten patrons sensibles (per exemple, formats típics de targetes de crèdit, DNIs, comptes bancaris, adreces postals completes, contrasenyes o tokens), la resposta es pot bloquejar, retallar o desensibilitzar, substituint els valors reals per marcadors genèrics.
També és útil classificar prèviament la informació interna per nivells de sensibilitat i aplicar regles de seguretat essencials per a carpetes compartides i etiquetar els documents que alimenten el model. Així, el sistema d'IA sabrà quins continguts pot manipular lliurement i quins requereixen una verificació addicional de permisos abans de ser mostrats. Això redueix les probabilitats que l'assistent proporcioni una informació que, encara que tècnicament tingui a la base de coneixement, l'usuari que pregunta no està autoritzat a veure.
Un altre enfocament complementari és dissenyar les plantilles de resposta del chatbot de manera que, davant de certes peticions (per exemple, “dóna'm el número de compte de X” o “digues-me la contrasenya del servidor Y”), la IA tingui instruccions clares de contestar amb un “no puc proporcionar-te aquesta informació” o amb missatges predefinits que reforcin la política interna de protecció.
Amenaces específiques dels models locals: agents dorments i models trampa
Més enllà de la infraestructura, cal assumir que el propi model pot ser una font de risc en si mateix. Ja s'ha demostrat la possibilitat de crear LLM amb comportaments ocults que s'activen només davant de certs estímuls. Aquests anomenats “agents dorments” poden, per exemple, generar codi amb vulnerabilitats discretes quan detecten noms de projectes concrets, o suavitzar determinades alertes perquè passin desapercebudes.
Si entrenes o ajustes un model amb dades internes (fine-tuning), existeix a més el risc que, si el model original va ser manipulat, pugui aprofitar aquest procés per memoritzar fragments d'informació sensible i reproduir-los després quan se li fan preguntes adequades. Hi ha investigacions sobre models trampa dissenyats per recuperar part de les dades del fine-tuning o de les fonts utilitzades en sistemes de RAG (Retrieval Augmented Generation).
En entorns on s'utilitza RAG, és especialment important comprovar que el model no pugui reconstruir i deixar anar literalment documents complets o dades extremadament delicades a partir dels embeddings emmagatzemats. Algunes tècniques d'atac busquen precisament extreure, a base de prompts elaborats, grans blocs de text que pertanyen a la base de coneixement de l'empresa.
Per això, en desplegar IA en local, convé auditar els models que es faran servir, revisar-ne la procedència, estudiar com han estat entrenats i, si és possible, analitzar-ne el comportament en escenaris controlats per detectar anomalies. De vegades, pot ser preferible utilitzar models de codi obert ben auditats per la comunitat abans que binaris opacs d'origen dubtós.
Riscos d'eines i capacitat d'executar codi
Una altra font de risc ve de la tendència a dotar els models de llenguatge de capacitats extra mitjançant eines: accés a bases de dades, execució de codi Python, anomenades HTTP, gestió de fitxers, etc. Aquestes funcions són molt potents per automatitzar tasques, però també poden ser una arma de doble tall.
Si el model pot executar codi o invocar APIs sense restriccions clares, res no impedeix que, sota certes condicions, utilitzeu aquesta capacitat per enviar informació a l'exterior, obrir connexions no autoritzades, descarregar scripts maliciosos o modificar configuracions del sistema. I si hi afegim la possibilitat d'agents dorments, l'escenari es complica encara més.
La mitigació passa per definir amb molta precisió quines eines pot fer servir la IA, en quins contextos i amb quins paràmetres. Els entorns d'execució de codi han d'estar aïllats (sandbox), amb permisos limitats sobre el sistema de fitxers i sense accés directe a internet. A més, totes les trucades a eines crítiques haurien de quedar enregistrades i, en molts casos, requerir confirmació explícita d'un humà.
A més, convé revisar el trànsit de xarxa “inesperat” del servidor que executa la IA: si un model suposadament local comença a generar peticions sortints que no estaven contemplades, pot ser un senyal clar que alguna cosa no va bé, ja sigui un codi maliciós tradicional o una lògica oculta dins del mateix assistent.
Privadesa, RGPD i compliment normatiu amb IA en local
Un dels grans avantatges de la IA en local és que facilita el compliment del RGPD i altres lleis de protecció de dades, sempre que es dissenyi correctament. En mantenir tota la informació i el processament dins de la teva pròpia infraestructura, elimines gran part del risc associat a transferències internacionals, subencarregats externs i serveis al núvol.
Tot i així, això no us eximeix de complir amb principis com la minimització de dades, la limitació de la finalitat, la seguretat des del disseny (privacy by design i security by design) o els drets d'accés, rectificació i supressió. El fet que la IA sigui local només en facilita el control, però no et lliura de responsabilitats.
Mesures com la anonimització o pseudonimització dels conjunts d'entrenament, el xifratge de dades en repòs i trànsit, l'ús de contrasenyes robustes, MFA, conscienciació del personal i auditories periòdiques de seguretat són igual d'obligatòries en entorns locals que al núvol. De fet, moltes bretxes vénen més de males pràctiques internes que de fallades del proveïdor.
També és important verificar que tota la cadena de subministrament (fabricants, integradors, consultores, proveïdors de maquinari) manté estàndards de seguretat i privadesa comparables. Un error en qualsevol d'aquestes baules pot acabar afectant el teu desplegament local d'IA, tant a nivell tècnic com de compliment legal.
IA per defensar la pròpia IA: seguretat en capes
El panorama de ciberamenaces cada vegada és més complex, amb superfícies d'atac que s'estenen al núvol, entorns híbrids i ara també a infraestructures d'IA locals. Els atacants, a més, ja utilitzen eines d'intel·ligència artificial per descobrir vulnerabilitats, automatitzar campanyes de pesca i millorar els seus atacs.
En aquest context, resulta lògic recolzar-se també en IA defensiva per protegir els sistemes. Models especialitzats en ciberseguretat poden ajudar a identificar comportaments anòmals en temps real, classificar esdeveniments, prioritzar alertes i proposar respostes automàtiques. Això és especialment útil en organitzacions que pateixen escassetat de personal de seguretat.
La combinació de monitorització contínua, anàlisi avançada de logs i sistemes de resposta automàtica permet reduir de manera notable el temps de detecció i contenció d'incidents. Diversos estudis han mostrat que les empreses que no inverteixen en seguretat basada en IA pateixen bretxes més costoses que aquelles que sí que ho fan, fins i tot quan es tracta de desplegaments locals.
Això sí, la IA per a ciberseguretat no és una vareta màgica. Cal integrar-la en una estratègia de defensa en profunditat: segmentació de xarxa, hardening de sistemes, polítiques daccés, xifrat, formació dempleats i revisions periòdiques. Només així es pot construir un entorn de IA local realment blindat davant d'amenaces externes i internes.
En última instància, fer servir IA en local de manera segura implica anar molt més enllà d'instal·lar un model en un servidor sense connexió a internet: exigeix dissenyar una arquitectura tancada i segmentada, controlar qui entra i què pot veure, vigilar constantment el que fa el sistema, aplicar polítiques estrictes de protecció de dades i no oblidar que els models mateixos poden ser un vector d'atac si no s'auditen i gestiona; combinant prevenció, detecció i resposta proactiva és com s'aconsegueix aprofitar tot el potencial de la intel·ligència artificial sense posar en joc la privadesa ni la reputació de l'organització.
Redactor apassionat del món dels bytes i la tecnologia en general. M'encanta compartir els meus coneixements a través de l'escriptura, i això és el que faré en aquest bloc, mostrar tot el més interessant sobre gadgets, programari, maquinari, tendències tecnològiques, i més. El meu objectiu és ajudar-te a navegar pel món digital de forma senzilla i entretinguda.