- Lokal kunstig intelligens er ikke sikker som standard: den krever nettverkssegmentering, herding og tilgangskontroll.
- Det er viktig å begrense trafikk med VLAN-er og brannmurer, logge interaksjoner og bruke DLP-policyer.
- Det er spesifikke trusler fra lokale modeller som sovende agenter og fellemodeller.
- En lagdelt tilnærming, i samsvar med GDPR og god praksis for cybersikkerhet, reduserer risikoen drastisk.
Adopsjonen av modeller av lokal kunstig intelligens Bruken har skutt i været i bedrifter og blant fagfolk som håndterer sensitiv informasjon: personopplysninger, medisinske journaler, juridisk dokumentasjon, åndsverk ... Mange tror at det å kjøre AI på sine egne servere eller enheter garanterer personvern. Realiteten er langt mer kompleks: en dårlig utformet implementering kan bli en inngangsport for cyberangrep eller en datalekkasjemaskin uten at noen merker det.
Hvis du vil få mest mulig ut av AI uten å sette bedriften din i fare, er det viktig å forstå at sikkerhet ved bruk av AI lokalt Det handler ikke bare om å «fjerne internettilgang» fra modellen. Vi må tenke på nettverksarkitektur. herding av systemerTilgangskontroll, samsvar med regelverk (som GDPR), kontinuerlig overvåking og forsvar mot svært spesifikke trusler mot modellene, fra sovende agenter til fellemodeller som er trent til å stramme inn informasjon.
Hvorfor lokal AI ikke automatisk er sikker
AI som kjører på dine egne servere gir klare fordeler: Mer kontroll, mer personalisering og i teorien mer personvernMen disse fordelene kommer med tilhørende risikoer som ofte overses, spesielt når skript eller containere brukes på nytt uten å sjekke containersikkerheten eller deres faktiske oppførsel på nettverket.
En språkmodell eller AI-assistent kan ha tilgang til intern dokumentasjon, databaser som inneholder personlig informasjon, kodelagre eller strategiske rapporter. Hvis systemet som kjører den er dårlig segmentert, hvis brannmuren er for åpen, eller hvis selve modellen har skjult atferd, kan den AI-en du trodde var «offline» ende opp med å sende sensitive data eksternt eller eksponere dem for uautoriserte brukere.
Videre er lokale modeller avhengige av et økosystem av inferensprogramvare, biblioteker og applikasjonsservere (FastAPI, Uvicorn, webrammeverk, GPU-kjøretider osv.) som, i likhet med all annen programvare, krever evaluere programvaresikkerhet Den har også sårbarheter, feil og konfigurasjonsproblemer. Hvis disse komponentene ikke oppdateres, eller hvis den ikke bruker riktig herding, blir den et perfekt mål for angripere.
For å gjøre vondt verre, er det i dag teknisk mulig å modifisere en modell for å introdusere ondsinnet oppførsel Disse funksjonene aktiveres bare under visse betingelser: spesifikke ledetekster, prosjektnavn, datoer eller til og med trafikkmønstre. Derfor er det svært risikabelt å bare "laste ned en modell fra internett og sette den opp lokalt" uten ytterligere kontroller.
Sikker arkitektur for en AI-chatbot på bedriftsnettverket
Et typisk tilfelle er at en AI-chatbot distribuert i selskapet For å kunne konsultere intern dokumentasjon, administrere et dokumenthåndteringssystem eller hjelpe ansatte, må dette systemet være utformet for å forhindre at det blir en datasil. En nettverks- og sikkerhetsarkitektur som er spesielt utformet for å isolere det fra omverdenen og kontrollere hvem som kobler seg til og hva de kan gjøre, er avgjørende.
Tenk deg et selskap som setter opp en chatbot basert på en modell som Llama 3 eller DeepSeek på en lokal server. Denne serveren behandler kontrakter, kundedata, interne retningslinjer og ansattdata. Hvis trafikken ikke er segmentert eller filtrert, er alt som skal til én infisert intern datamaskin eller en feilkonfigurert brannmur for at boten skal eksponere kritisk informasjon.
Det mest robuste forslaget innebærer å plassere AI-serveren i en Spesifikt og isolert VLANuten direkte internettilgang, og kontrollere all innkommende og utgående kommunikasjon innenfor det VLAN-et via en sentral brannmur. Videre må brukertilgang alltid autentiseres mot et Active Directory (AD/LDAP) eller tilsvarende system for å opprettholde sporbarheten av brukeraktivitet.
Denne «AI i en boble»-tilnærmingen lar chatboten kun kommunisere med de strengt nødvendige interne systemene: databasen som indekserer dokumentasjonen, autentiseringsserveren og arbeidsstasjonene som ansatte kobler seg til fra. Alt annet, inkludert all internettilgang, må blokkeres som standard.
Nettverkssegmentering og VLAN-er: fysiske barrierer for AI
Nettverkssegmentering ved bruk av VLAN-er er et av de mest effektive tiltakene for begrense angrepsflatenI stedet for å ha hele selskapet på et flatt nettverk, er kritiske funksjoner delt inn i ulike segmenter med svært presise tilgangsregler.
Et eksempel på et design kan være følgende: a Bruker-VLAN-er hvor de vanlige arbeidsteamene befinner seg; AI-server- og database-VLAN-er uten internettforbindelse; en administrasjons-VLAN hvorfra bare teknisk personell kan administrere infrastrukturen; og om nødvendig en Gjeste-VLAN uten tilgang til chatboten eller sensitive interne ressurser.
Når det gjelder IP-adressering, opererer hvert VLAN innenfor et distinkt område (for eksempel 192.168.10.0/24 for brukere, 192.168.20.0/24 for AI-servere, 192.168.30.0/24 for administrasjon og 192.168.40.0/24 for gjester). Chatbot-serveren kan befinne seg på en adresse som 192.168.20.10Databasen ligger på 192.168.20.20 og domenekontrolleren på 192.168.30.10, mens interne brukere befinner seg i segmentet 192.168.10.0/24.
Med denne segmenteringen vil for eksempel ikke en infisert bærbar datamaskin som er koblet til gjestenettverket kunne nå AI-serveren selv om den kjenner IP-adressen. Og en intern bruker må være på riktig VLAN og autentisere med legitimasjonen sin for å få tilgang. På denne måten, selv om en maskin blir kompromittert, vil angriperen støte på flere lag med isolasjon før vi kommer til AI og dataene den håndterer.
Porter, brannmurer og trafikkregler: hva som er tillatt og hva som er blokkert
Når segmenteringen er definert, er neste trinn å spesifisere hva TCP/IP-porter De vil tillate tilgang mellom hver komponent og blokkere alt annet. Prinsippet er enkelt: bare det som er essensielt for at løsningen skal fungere, åpnes.
For eksempel kan brukere på VLAN 10 få tilgang til chatboten på VLAN 20 via port 5000, der et API (som FastAPI, Uvicorn eller lignende teknologi) vanligvis er eksponert. AI-serveren kommuniserer med databasen sin på samme VLAN ved hjelp av port 5432, en vanlig port for PostgreSQL. For å autentisere brukere kobler chatboten seg til Active Directory på VLAN 30 ved hjelp av port 389 (LDAP).
Administratorer, kun fra VLAN 30, kan åpne SSH-økter til IA-serveren via port 22, men denne tilgangen må være begrenset av opprinnelse og autentisert med sterke nøkler. All annen type trafikk mellom VLAN-er blir nektet, og spesielt all utgående trafikk fra AI-serveren til internett blir blokkert, slik at selv om modellen eller et verktøy prøvde å "ringe hjem", ville brannmuren forhindre det.
De grunnleggende reglene som skal gjelde ville være: nekt som standard alle innkommende tilkoblinger utenfra til det interne nettverket; forhindre at chatbot-serveren oppretter utgående tilkoblinger til internett; tillat kun strengt nødvendig intern kommunikasjon mellom VLAN-er; og registrere alle relevante tilganger i brannmuren eller i en SIEM-løsning for å kunne revidere hendelser.
Tilgangskontroll: Active Directory, roller og sterk autentisering
Nettverksisolasjon kompletteres av streng kontroll over hvem som kan samhandle med AI-en og hvilken type informasjon den kan be om. Det er her Active Directory eller en LDAP-tjeneste lignende, som sentraliserer autentisering og autorisasjon.
Tanken er at hver ansatt logger seg på chatboten med bedriftens påloggingsinformasjon, og systemet sender en forespørsel til katalogen for å finne ut hvilke grupper de tilhører. Basert på disse gruppene (for eksempel HR, Support, Management, Guests), vil chatboten begrense hvilke forespørsler og handlinger som er tillatt, slik at en kundeserviceansatt ikke kan få tilgang til lønnsdata eller interne økonomiske rapporter.
Videre anbefales det på det sterkeste å bruke en multifaktorautentisering (MFA) Dette gjelder i det minste profiler med flest rettigheter og de som kan håndtere svært sensitiv informasjon. Det er også lurt å implementere retningslinjer for færrest rettigheter: gi hver bruker bare det tilgangsnivået som er nødvendig for rollen deres.
Parallelt kan spesifikke roller defineres i selve AI-applikasjonen, slik at modellen vet hva slags svar den kan tilby hver gruppe. For eksempel kan HR-teamet spørre om interne ferieregler eller ansettelsesprosedyrer; det tekniske teamet om manualer og systemdokumentasjon; ledelsen om aggregerte interne dashbord; og inviterte brukere nektes rett og slett tilgang til chatboten.
Overvåking, logging og respons på mistenkelig aktivitet
Uansett hvor godt utformet miljøet er, er det alltid en mulighet for at noen kan prøve å misbruke systemet eller at unormal oppførsel kan oppstå. Derfor er det viktig å ha en kontinuerlig overvåking av interaksjoner med AI og en automatisert responsmekanisme.
Ideelt sett bør hver samtale eller forespørsel logges i detalj: hvem som foretok den (autentisert bruker), fra hvilken enhet eller IP-adresse, hva de spurte om, hva modellen svarte og når. Disse loggene sendes deretter til en SIEM-plattform som Splunk, ELK Stack, Wazuh eller Graylog, som muliggjør analyse av store mengder logger og deteksjon av mistenkelige mønstre.
Atferd å være oppmerksom på inkluderer: gjentatte spørsmål om ekstremt sensitive emner over korte perioder; gjentatte forsøk på å be om spesifikke personopplysninger (kontonumre, ID-kort, passord…); tilgang utenom arbeidstid fra uvanlige enheter; eller plutselige endringer i typen spørsmål fra en bruker som tidligere hadde normal bruk.
Når et avvik oppdages, skal systemet umiddelbart generere et varsel til sikkerhetspersonell og, avhengig av alvorlighetsgraden, utløse automatiske handlinger: vise advarselsmeldinger til brukeren, be om ekstra autentisering, midlertidig blokkere tilgang eller eskalere hendelsen til HR eller den juridiske avdelingen hvis det ser ut til å være et bevisst forsøk på utpressing.
Forebygging av datatap (DLP) brukt på AI-modeller
En av de største bekymringene med lokal AI er at selve modellen kan ende opp med å returnere data i svarene sine som aldri skal forlate visse systemer: økonomiske data, personlig identifiserbar informasjon eller forretningshemmeligheterFor å unngå dette kan policyer for forebygging av datatap (DLP) brukes direkte på modellutgangene.
Disse retningslinjene innebærer å analysere AI-genererte svar før de vises til brukeren. Hvis sensitive mønstre oppdages (for eksempel typiske formater for kredittkort, ID-kort, bankkontoer, fullstendige postadresser, passord eller tokener), kan svaret blokkeres, avkortes eller desensibiliseres ved å erstatte de faktiske verdiene med generiske markører.
Det er også nyttig å forhåndsklassifisere intern informasjon etter sensitivitetsnivåer og Bruk viktige sikkerhetsregler for delte mapper og merke dokumentene som mates inn i modellen. På denne måten vil AI-systemet vite hvilket innhold det fritt kan manipulere og hvilket som krever ytterligere tillatelsesverifisering før det vises. Dette reduserer sannsynligheten for at assistenten oppgir informasjon som den forespurte brukeren ikke har tillatelse til å se, selv om det teknisk sett ligger i kunnskapsbasen.
En annen komplementær tilnærming er å utforme chatbotens svarmaler slik at AI-en, som svar på visse forespørsler (for eksempel «gi meg X sitt kontonummer» eller «fortell meg passordet til server Y»), har klare instruksjoner om å svare med «Jeg kan ikke gi deg den informasjonen» eller med forhåndsdefinerte meldinger som forsterker den interne databeskyttelsespolicyen.
Spesifikke trusler mot lokale modeller: sovende agenter og fellemodeller
Utover infrastrukturen må vi anta at selve modellen kan være en kilde til risiko i seg selvDet har allerede blitt vist at LLM-er med skjult atferd som bare aktiveres av visse stimuli kan lages. Disse såkalte «sleeper agents» kan for eksempel generere kode med diskrete sårbarheter når de oppdager bestemte prosjektnavn, eller myke opp visse varsler slik at de går ubemerket hen.
Hvis du trener eller finjusterer en modell ved hjelp av interne data, er det også en risiko for at den opprinnelige modellen, hvis den ble manipulert, kan bruke den prosessen til å memorere fragmenter av sensitiv informasjon og reprodusere dem senere når den blir stilt de riktige spørsmålene. Det finnes forskning på dette. Fellemodeller designet for å gjenopprette noen av finjusteringsdataene eller fra kildene som brukes i RAG-systemer (Retrieval Augmented Generation).
I miljøer der RAG brukes, er det spesielt viktig å bekrefte at modellen ikke bokstavelig talt kan rekonstruere og trekke ut hele dokumenter eller ekstremt sensitive data fra de lagrede innebygde elementene. Noen angrepsteknikker tar spesifikt sikte på å trekke ut store tekstblokker fra bedriftens kunnskapsbase ved hjelp av sofistikerte ledetekster.
Derfor, når man distribuerer AI lokalt, er det lurt å revidere modellene som skal brukes, gjennomgå deres opprinnelse, studere hvordan de ble trent og, om mulig, analysere atferden deres i kontrollerte scenarier for å oppdage avvik. Noen ganger kan det være å foretrekke å bruke modeller med åpen kildekode som er godt revidert av fellesskapet, i stedet for ugjennomsiktige binærfiler av tvilsom opprinnelse.
Risikoer ved verktøy og evnen til å kjøre kode
En annen kilde til risiko kommer fra tendensen til å utstyre språkmodeller med ekstra muligheter gjennom verktøy: tilgang til databaser, utførelse av Python-kodeHTTP-kall, filbehandling osv. Disse funksjonene er svært kraftige for å automatisere oppgaver, men de kan også være et tveegget sverd.
Hvis modellen kan kjøre kode eller påkalle API-er uten klare restriksjoner, er det ingenting som hindrer den i å bruke denne muligheten, under visse betingelser, til å sende informasjon eksternt, åpne uautoriserte tilkoblinger, laste ned skadelige skript eller endre systemkonfigurasjoner. Og hvis vi legger til muligheten for sovende agenter, blir scenariet enda mer komplekst.
Reduksjon av kode innebærer å definere nøyaktig hvilke verktøy AI kan bruke, i hvilke kontekster og med hvilke parametere. Kodeutførelsesmiljøer må være isolert (sandkasse)med begrensede tillatelser på filsystemet og ingen direkte internettilgang. Videre bør alle anrop til kritiske verktøy logges og i mange tilfeller kreve eksplisitt menneskelig bekreftelse.
I tillegg er det lurt å sjekke for «uventet» nettverkstrafikk fra serveren som kjører AI-en: hvis en angivelig lokal modell begynner å generere utgående forespørsler som ikke var forventet, kan det være et tydelig tegn på at noe er galt, enten det er tradisjonell skadelig programvare eller skjult logikk i selve assistenten.
Personvern, GDPR og samsvar med regelverk med lokal AI
En av de store fordelene med lokal AI er at den legger til rette for overholdelse av GDPR og andre personvernloverForutsatt at den er riktig utformet. Ved å holde all informasjon og behandling innenfor din egen infrastruktur eliminerer du mye av risikoen forbundet med internasjonale overføringer, eksterne underleverandører og skytjenester.
Likevel fritar ikke dette deg fra å overholde prinsipper som dataminimering, formålsbegrensning, personvern gjennom innebygd design og sikkerhet gjennom innebygd design, eller retten til tilgang, retting og sletting. Det faktum at AI er lokal, forenkler bare kontroll, men det fritar deg ikke fra ansvar.
Tiltak som anonymisering eller pseudonymisering av opplæringspakker, kryptering av data i ro og under overføring, bruk av sterke passord, MFA, bevissthet fra ansatte og periodiske sikkerhetsrevisjoner De er like obligatoriske i lokale miljøer som i skyen. Faktisk stammer mange sårbarheter mer fra dårlig intern praksis enn fra leverandørfeil.
Det er også viktig å bekrefte at hele forsyningskjeden (produsenter, integratorer, konsulenter, maskinvareleverandører) opprettholder sammenlignbare sikkerhets- og personvernstandarder. En feil på noen av disse leddene kan i siste instans påvirke din lokale AI-distribusjon, både teknisk og med tanke på juridisk samsvar.
AI for å forsvare seg selv: lagdelt sikkerhet
Cybertrussellandskapet blir stadig mer komplekst, med angrepsflater som strekker seg til skyen, hybridmiljøer og nå til og med lokal AI-infrastruktur. Angripere bruker allerede kunstig intelligens-verktøy for å oppdage sårbarheter, automatisere phishing-kampanjer og forbedre angrepene sine.
I denne sammenhengen er det også fornuftig å stole på Defensiv AI For å beskytte systemer kan spesialiserte cybersikkerhetsmodeller bidra til å identifisere unormal atferd i sanntid, klassifisere hendelser, prioritere varsler og foreslå automatiserte responser. Dette er spesielt nyttig i organisasjoner som opplever mangel på sikkerhetspersonell.
Kombinasjonen av kontinuerlig overvåking, avansert logganalyse og automatiserte responssystemer reduserer hendelsesdeteksjon og inneslutningstid betydelig. Flere studier har vist at selskaper som ikke investerer i AI-basert sikkerhet, lider av mer kostbare sikkerhetsbrudd enn de som gjør det, selv ved lokale implementeringer.
AI for cybersikkerhet er imidlertid ikke en magisk løsning. Den må integreres i en strategi for dyptgående forsvar: nettverkssegmentering, systemherding, tilgangspolicyer, kryptering, opplæring av ansatte og regelmessige evalueringer. Bare på denne måten kan et sikkert miljø bygges. lokal AI virkelig pansret står overfor eksterne og interne trusler.
Til syvende og sist innebærer sikker bruk av AI lokalt mye mer enn bare å installere en modell på en server uten internettforbindelse: det krever design av en lukket og segmentert arkitektur, kontroll av hvem som går inn og hva de kan se, kontinuerlig overvåking av hva systemet gjør, anvendelse av strenge retningslinjer for databeskyttelse, og ikke glem at modellene i seg selv kan være en angrepsvektor hvis de ikke revideres og administreres på riktig måte. Ved å kombinere forebygging, deteksjon og proaktiv respons kan du utnytte det fulle potensialet til kunstig intelligens uten å sette personvernet eller omdømmet til organisasjonen i fare.
Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.