Home Nieuws Uw ontwikkelaars gebruiken AI al lokaal: waarom gevolgtrekkingen op apparaten de nieuwe...

Uw ontwikkelaars gebruiken AI al lokaal: waarom gevolgtrekkingen op apparaten de nieuwe blinde vlek van de CISO zijn

13
0
Uw ontwikkelaars gebruiken AI al lokaal: waarom gevolgtrekkingen op apparaten de nieuwe blinde vlek van de CISO zijn

De afgelopen achttien maanden was het CISO-playbook voor generatieve AI relatief eenvoudig: beheer de browser.

Beveiligingsteams het CASB-beleid (Cloud Access Security Broker) aangescherpt, het verkeer naar bekende AI-eindpunten geblokkeerd of gemonitord, en het gebruik via gesanctioneerde gateways geleid. Het bedrijfsmodel was duidelijk: als gevoelige gegevens het netwerk verlaten voor een externe API-aanroep, kunnen we deze observeren, loggen en tegenhouden. Maar dat model begint te breken.

Een stille hardwareverschuiving duwt het gebruik van grote taalmodellen (LLM) van het netwerk naar het eindpunt. Noem het Shadow AI 2.0, of het ‘bring your own model’ (BYOM)-tijdperk: werknemers draaien capabele modellen lokaal op laptops, offline, zonder API-oproepen en zonder duidelijke netwerkhandtekening. Het gesprek over governance wordt nog steeds geframed als ‘data-exfiltratie naar de cloud’, maar het meer directe bedrijfsrisico is steeds vaker ‘niet-doorgelichte gevolgtrekking binnen het apparaat’.

Wanneer gevolgtrekking lokaal plaatsvindt, ziet traditionele preventie van gegevensverlies (DLP) de interactie niet. En als de beveiliging het niet kan zien, kan het het ook niet beheren.

Waarom lokale gevolgtrekking ineens praktisch is

Twee jaar geleden was het runnen van een nuttige LLM op een werklaptop een nichestunt. Tegenwoordig is het routine voor technische teams.

Drie dingen kwamen samen:

  • Versnellers van consumentenkwaliteit werden serieus: Op een MacBook Pro met 64 GB uniform geheugen kunnen gekwantiseerde modellen uit de 70B-klasse vaak met bruikbare snelheden worden uitgevoerd (met praktische beperkingen wat betreft de contextlengte). Wat ooit multi-GPU-servers vereiste, is nu haalbaar op een high-end laptop voor veel echte workflows.

  • Kwantisering werd mainstream: Het is nu eenvoudig om modellen te comprimeren naar kleinere, snellere formaten die in het laptopgeheugen passen, vaak met acceptabele kwaliteitsafwegingen voor veel taken.

  • Distributie is wrijvingsloos: Open-weight-modellen zijn slechts één commando verwijderd, en het tooling-ecosysteem maakt “downloaden → uitvoeren → chatten” triviaal.

Het resultaat: Een ingenieur kan een modelartefact van meerdere GB ophalen, Wi-Fi uitschakelen en gevoelige workflows lokaal uitvoeren, broncode beoordelen, documenten samenvatten, klantcommunicatie opstellen en zelfs verkennende analyses uitvoeren op gereguleerde datasets. Geen uitgaande pakketten, geen proxylogboeken, geen cloudaudittrail.

Van een netwerkbeveiligingsperspectiefkan die activiteit niet te onderscheiden zijn van ‘er is niets gebeurd’.

Het risico is niet alleen dat gegevens het bedrijf verlaten

Als de gegevens de laptop niet verlaten, waarom zou een CISO zich er dan druk over maken?

Omdat de dominante risico’s verschuiven van exfiltratie naar integriteit, herkomst en compliance. In de praktijk creëert lokale gevolgtrekking drie soorten blinde vlekken die de meeste ondernemingen niet hebben geoperationaliseerd.

1. Contaminatie van codes en besluiten (integriteitsrisico)

Lokale modellen worden vaak overgenomen omdat ze snel en privé zijn en ‘geen goedkeuring vereist’. Het nadeel is dat ze vaak niet zijn goedgekeurd voor de bedrijfsomgeving.

Een veelvoorkomend scenario: Een senior ontwikkelaar downloadt een door de community afgestemd codeermodel omdat het goed scoort. Ze plakken er interne auth-logica, betalingsstromen of infrastructuurscripts in om het ‘op te schonen’. Het model retourneert uitvoer die er competent uitziet, compileert en doorstaat unit-tests, maar verslechtert op subtiele wijze de beveiligingsstatus (zwakke invoervalidatie, onveilige standaardinstellingen, broze gelijktijdigheidsveranderingen, afhankelijkheidskeuzes die intern niet zijn toegestaan). De ingenieur voert de wijziging door.

Als die interactie offline plaatsvond, heb je misschien helemaal geen bewijs dat AI het codepad heeft beïnvloed. En als u later incidentrespons doet, onderzoekt u het symptoom (een kwetsbaarheid) zonder inzicht in de hoofdoorzaak (ongecontroleerd modelgebruik).

2. Licentie- en IP-blootstelling (compliancerisico)

Veel goed presterende modellen worden geleverd met licenties inclusief beperkingen op commercieel gebruikattributievereisten, gebruikslimieten of verplichtingen die onverenigbaar kunnen zijn met de ontwikkeling van eigen producten. Wanneer werknemers modellen lokaal uitvoeren, kan dat gebruik het normale inkoop- en juridische beoordelingsproces van de organisatie omzeilen.

Als een team een ​​niet-commercieel model gebruikt om productiecode, documentatie of productgedrag te genereren, kan het bedrijf risico’s erven die later aan het licht komen tijdens fusies en overnames, klantveiligheidsbeoordelingen of rechtszaken. Het moeilijkste deel zijn niet alleen de licentievoorwaarden, maar ook het gebrek aan inventaris en traceerbaarheid. Zonder een beheerde modelhub of gebruiksrecord kunt u mogelijk niet bewijzen wat waar is gebruikt.

3. Modelleer blootstelling aan de toeleveringsketen (herkomstrisico)

Lokale gevolgtrekkingen veranderen ook het probleem van de softwaretoeleveringsketen. Eindpunten beginnen grote modelartefacten en de toolchains eromheen te verzamelen: ownloaders, converters, runtimes, plug-ins, UI-shells en Python-pakketten.

Er is hier een kritische technische nuance: het bestandsformaat is belangrijk. Terwijl nieuwere formaten zoals Beveiligingen zijn ontworpen om het uitvoeren van willekeurige code te voorkomen, ouder Op basis van augurken PyTorch-bestanden kan eenvoudigweg kwaadaardige ladingen uitvoeren wanneer ze worden geladen. Als uw ontwikkelaars niet-doorgelichte controlepunten uit Hugging Face of andere opslagplaatsen halen, downloaden ze niet alleen gegevens, maar downloaden ze mogelijk ook een exploit.

Beveiligingsteams hebben decennialang geleerd onbekende uitvoerbare bestanden als vijandig te behandelen. BYOM vereist dat die mentaliteit wordt uitgebreid naar het modelleren van artefacten en de omringende runtime-stack. De grootste organisatorische kloof van vandaag is dat de meeste bedrijven geen equivalent hebben van een softwarestuklijst voor modellen: Herkomst, hashes, toegestane bronnen, scannen en levenscyclusbeheer.

BYOM beperken: behandel modelgewichten als softwareartefacten

U kunt lokale gevolgtrekkingen niet oplossen door URL’s te blokkeren. Je hebt eindpuntbewuste controles nodig en een ontwikkelaarservaring die van het veilige pad het gemakkelijke pad maakt.

Hier zijn drie praktische manieren:

1. Verplaats het beheer naar het eindpunt

Netwerk-DLP en CASB zijn nog steeds van belang voor cloudgebruik, maar zijn niet voldoende voor BYOM. Begin met het behandelen van lokaal modelgebruik als een endpoint governance-probleem door te zoeken naar specifieke signalen:

  • Inventarisatie en detectie: Scannen op hifi-indicatoren zoals .gguf-bestanden die groter zijn dan 2 GB, processen zoals bel.cpp of Ollama, en lokale luisteraars op Common standaardpoort 11434.

  • Proces- en runtime-bewustzijn: Controleer op herhaald hoog GPU/NPU-gebruik (neurale verwerkingseenheid) van niet-goedgekeurde runtimes of onbekende lokale inferentieservers.

  • Apparaatbeleid: Gebruik beheer van mobiele apparaten (MDM) en eindpuntdetectie en -respons (EDR) beleid om de installatie van niet-goedgekeurde runtimes te controleren en basisverharding op technische apparaten af ​​te dwingen. Het gaat er niet om experimenten te bestraffen. Het is om de zichtbaarheid te herwinnen.

2. Zorg voor een verharde weg: een interne, samengestelde modelhub

Schaduw-AI is vaak het resultaat van wrijving. Goedgekeurde tools zijn te beperkend, te algemeen of te traag om goed te keuren. Een betere aanpak is het aanbieden van een samengestelde interne catalogus met:

  • Goedgekeurde modellen voor algemene taken (codering, samenvatting, classificatie)

  • Geverifieerde licenties en gebruiksrichtlijnen

  • Vastgezette versies met hashes (voorrang aan veiligere formaten zoals Safetensors)

  • Duidelijke documentatie voor veilig lokaal gebruik, inclusief waar gevoelige gegevens wel en niet zijn toegestaan. Als je wilt dat ontwikkelaars stoppen met het opruimen, geef ze dan iets beters.

3. Update de beleidstaal: “Cloudservices” is niet meer voldoende

Het meest acceptabele gebruiksbeleid gaat over SaaS- en cloudtools. BYOM vereist beleid dat expliciet betrekking heeft op:

  • Modelartefacten downloaden en uitvoeren op bedrijfseindpunten

  • Aanvaardbare bronnen

  • Vereisten voor naleving van licenties

  • Regels voor het gebruik van modellen met gevoelige gegevens

  • Retentie- en registratieverwachtingen voor lokale inferentietools Dit hoeft niet hardhandig te zijn. Het moet ondubbelzinnig zijn.

De perimeter verschuift terug naar het apparaat

Tien jaar lang hebben we de beveiligingscontroles “omhoog” naar de cloud verplaatst. Lokale gevolgtrekkingen trekken een betekenisvol deel van de AI-activiteit terug naar het eindpunt.

5 signalen dat schaduw-AI naar eindpunten is verplaatst:

  • Grote modelartefacten: Onverklaarbaar opslagverbruik door .gguf- of .pt-bestanden.

  • Lokale inferentieservers: Processen die luisteren op poorten zoals 11434 (Ollama).

  • GPU-gebruikspatronen: Pieken in GPU-gebruik terwijl u offline bent of wanneer de verbinding met VPN is verbroken.

  • Gebrek aan modelinventaris: Onvermogen om code-uitvoer toe te wijzen aan specifieke modelversies.

  • Onduidelijkheid over licenties: Aanwezigheid van “niet-commerciële” modelgewichten in productiebuilds.

Shadow AI 2.0 is geen hypothetische toekomst, het is een voorspelbaar gevolg van snelle hardware, gemakkelijke distributie en de vraag van ontwikkelaars. CISO’s die zich alleen op netwerkcontroles concentreren, zullen missen wat er gebeurt op het silicium dat op de bureaus van werknemers ligt.

De volgende fase van AI-beheer gaat minder over het blokkeren van websites en meer over het controleren van artefacten, herkomst en beleid op het eindpunt, zonder de productiviteit te ondermijnen.

Jayachander Reddy Kandakatla is een senior MLOps-ingenieur.

Welkom bij de VentureBeat-community!

In ons gastpostprogramma delen technische experts inzichten en bieden ze neutrale, niet-gevestigde diepgaande inzichten over AI, data-infrastructuur, cyberbeveiliging en andere geavanceerde technologieën die de toekomst van het bedrijfsleven vormgeven.

Lees meer uit ons gastpostprogramma — en bekijk ons richtlijnen als u geïnteresseerd bent om een ​​eigen artikel bij te dragen!

Nieuwsbron

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in