Åtkomstkontroll för AI i konsultbolag: vad som ska följa med

Ett bolag lägger år på att bygga upp sina åtkomstregler: vem som får öppna vilken kundmapp, vem som får se vilken finansiell modell, vem som mister åtkomsten sin sista arbetsdag. Ansluter ni ett AI-verktyg utan att ta med de reglerna kan verktyget i det tysta gå förbi dem allihop. Åtkomstkontroll för AI handlar om att tillämpa de regler bolaget redan har på en ny användare av er data, inte om att utforma nya behörigheter från grunden.

Vad åtkomstkontroll betyder när AI kommer in i bilden

Ett AI-verktyg ska aldrig se mer än vad personen som använder det redan har behörighet att se. Kan en junior analytiker inte öppna en partners prismodell ska analytikerns assistent inte heller kunna hämta något ur den, hur praktisk en gemensam kunskapsbas än vore.

Här gör många bolag samma misstag: de ansluter ett AI-verktyg till ”bolagets kunskap” som en enda samlad pool, eftersom ett gemensamt källbibliotek känns som hela poängen med att koppla AI till intern data. Men när poolen saknar gränser slutar alla behörigheter som bolaget någonsin har satt att gälla, och alla som kan använda assistenten kommer åt allt i den.

Där gränsen faktiskt brister

Det ser sällan ut som ett intrång. Oftast börjar det med ett vanligt beslut när verktyget sätts upp.

En gemensam assistent som når längre än någon enskild användare. Någon konfigurerar en assistent mot ”allt i Drive” eller ”hela kundarbetsytan” eftersom det kändes som extra arbete att avgränsa den. Nu kan alla som kan prata med assistenten hämta dokument som de aldrig har fått direkt åtkomst till.
En integration som autentiserar en gång, på administratörsnivå, för alla. Kopplingen till bolagets dokumentlager sätts upp med en administratörs inloggningsuppgifter, och därefter ärver varje användare av AI-verktyget administratörens räckvidd i stället för sin egen.
En tidigare anställd som behåller åtkomsten efter att ha slutat. Checklistorna för offboarding täcker e-post och CRM. Ett AI-verktyg med en stående koppling till kundmappar är lätt att glömma, och kopplingen fortsätter att fungera när personen har gått.
Kundmaterial som hamnar i en allmän arbetsyta. Ett dokument som en kund delade för ett uppdrag används för att besvara en fråga i ett helt annat uppdrag, eftersom inget i verktyget skiljer på vilken kund materialet tillhör.

Inget av detta kräver att någon gör fel med avsikt. Det är vad som händer när ett verktyg är enklare att sätta upp brett än avgränsat och ingen ser över uppsättningen när den väl fungerar.

Vad som ska följa med, regel för regel

De behörigheter ett bolag redan har ska gälla på samma sätt i ett AI-verktyg som överallt annars. Gör den här kontrollen på varje verktyg innan kunddata kommer i närheten av det.

Befintlig åtkomstregel	Vad som ska hända i AI-verktyget
En användare kan bara öppna dokument i sin egen arbetsyta	AI-verktyget respekterar den avgränsningen när det hämtar källor, inte ”alla anslutna dokument”
En kunds material är begränsat till uppdragsteamet	AI-genererade utkast för kunden hämtar bara från material som hör till det uppdraget
En roll har bara läsbehörighet i ett system	AI-åtkomst via den kopplingen är också skrivskyddad och utökas inte av integrationen
En anställds åtkomst dras in sista arbetsdagen	AI-verktygets åtkomst till personens sessioner, nycklar och anslutna källor dras in samma dag
Åtgärder i kärnsystemen loggas	AI-användning mot samma system loggas lika detaljerat

Kan en leverantör inte koppla sitt verktyg till en rad i tabellen ska ni notera luckan som en brist i sig, inte som en detalj att reda ut senare.

Frågor att ställa innan ni kopplar AI till era system

Ställ dem innan en integration tas i drift, inte efter att en kund har frågat vem som kunde se deras material.

Ärver AI-verktyget behörigheterna från personen som använder det, eller från den som satte upp kopplingen?
Kan åtkomsten avgränsas per kund, per uppdrag eller per dokument, eller är kopplingen allt eller inget?
När någons åtkomst till ett källsystem dras in, försvinner då AI-verktygets åtkomst till samma källa automatiskt, eller måste någon komma ihåg att göra det separat?
Loggas det vad AI-verktyget hämtade och när, tillräckligt detaljerat för att besvara en kunds fråga om sitt eget material?

Svarar en leverantör konkret på alla fyra har den en åtkomstmodell. Svarar den ”det är flexibelt” har den troligen ingen.

Åtkomstgränser och offboarding

Luckan vid offboarding förtjänar ett eget avsnitt, eftersom det är här en designfråga blir en verklig risk. En person slutar, datorn samlas in, e-posten stängs av och åtkomsten till CRM-systemet dras in. En AI-assistent som personen kopplade till en kundarbetsyta ett halvår tidigare fortsätter däremot ofta att köra på en token som ingen minns att någon har utfärdat. Som vi tar upp i AI-säkerhet och förtroende i kundarbete behöver den kopplingen samma steg i offboardingen som allt annat på checklistan: en namngiven ansvarig som kontrollerar den samma dag som någon slutar, så att ingen hittar den först vid en säkerhetsgranskning.

Så hänger det ihop med ansluten kunskap

Åtkomstkontroll är den andra halvan av ansluten kunskap, alltså att koppla bolagets system till AI. När ni ansluter källor blir utkasten bättre, eftersom de bygger på verkligt och aktuellt material i stället för det en assistent redan kan. Det är också i kopplingen som åtkomstgränserna antingen fortsätter att gälla eller i det tysta slutar göra det. Ni behöver fatta två beslut samtidigt: vad som ska anslutas och vad som fortfarande ska vara avstängt när det väl är anslutet. Skjuter ni det andra beslutet på framtiden kan ett produktivitetsprojekt sluta som en åtkomstincident.

Hebno är byggt för att behålla de gränserna: kopplingar ärver de behörigheter som bolaget redan har, aktiviteten loggas tillräckligt detaljerat för att besvara en kunds fråga om den, och när någons åtkomst dras in stängs AI-kopplingen tillsammans med allt annat. Se säkerhetssidan för alla detaljer, eller boka en demo för att gå igenom hur åtkomstgränserna passar ert bolags uppsättning.