Slik utvikler virksomheter i Drammen sikre interne KI-verktøy for sine ansatte

Interne KI-verktøy kan gjøre det enklere for ansatte å finne informasjon, utarbeide dokumenter, behandle henvendelser og følge etablerte arbeidsprosesser. Samtidig kan en løsning som er koblet til interne dokumenter, kundedata eller operative systemer skape nye sikkerhets- og personvernrisikoer dersom tilgangen ikke er tydelig avgrenset.

For logistikk- og tjenestebedrifter i Drammen er utfordringen særlig praktisk. Ansatte arbeider ofte på tvers av ordredata, transportdokumentasjon, kundeavtaler, avvik, prosedyrer og økonomisystemer. Et generelt KI-verktøy uten tilpasset tilgangsstyring kan gi brukere mer informasjon enn de trenger, sende konfidensielt innhold til feil tjeneste eller produsere svar som blir brukt uten tilstrekkelig kontroll.

Et sikkert internt KI-verktøy bør derfor utvikles som et kontrollert forretningssystem, ikke som en åpen chatbot med tilgang til alt.

Hvordan skreddersydd programvareutvikling støtter Drammen-bedrifter

Skreddersydd programvareutvikling gjør det mulig å bygge KI-funksjoner rundt virksomhetens egne roller, datakilder og arbeidsoppgaver. I stedet for at alle ansatte får den samme brede tilgangen, kan løsningen tilpasses avdeling, ansvarsnivå og tjenstlig behov.

En transportkoordinator kan for eksempel få hjelp til å oppsummere leveringsavvik og finne relevante prosedyrer, mens en kundebehandler kan bruke verktøyet til å utarbeide svar basert på godkjente avtaler og kunnskapsartikler. En økonomimedarbeider kan få støtte til dokumentklassifisering uten at modellen får tilgang til andre personal- eller kundedata.

Dette gir virksomheten kontroll over:

• hvilke brukere som kan logge inn;

• hvilke dokumenter og systemer hver rolle kan søke i;

• hvilke handlinger verktøyet kan utføre;

• hvilke svar som krever menneskelig godkjenning;

• hva som logges for revisjon og forbedring.

Sikkerheten blir sterkere når tilgangsreglene følger arbeidsprosessen fremfor selve KI-modellen.

Start med en tydelig avgrenset arbeidsoppgave

Den vanligste feilen er å begynne med et bredt mål om å lage en intern KI-assistent som kan «hjelpe med alt». En slik formulering gjør det vanskelig å avgrense data, måle verdi og definere hvem som er ansvarlig dersom svaret er feil.

Et bedre utgangspunkt er én konkret oppgave, for eksempel:

1. finne riktig prosedyre for håndtering av et leveringsavvik;

2. oppsummere informasjon fra et godkjent dokumentsett;

3. foreslå et kundesvar basert på kvalitetssikrede maler;

4. klassifisere innkommende saker før manuell behandling;

5. hente status fra bestemte systemer gjennom kontrollerte API-er.

For hver oppgave bør virksomheten definere forventet resultat, tillatte datakilder, ansvarlig prosesseier og situasjoner der verktøyet ikke skal brukes.

Jo tydeligere oppgaven er, desto enklere blir det å bygge presise sikkerhetsgrenser.

Når verktøyet skal arbeide med norsk fagspråk, lokale prosedyrer eller komplekse interne dokumenter, kan prinsippene bak pålitelige norskspråklige LLM-applikasjoner være relevante. Språkkvalitet må imidlertid vurderes sammen med kildekontroll og tilgang, ikke som et isolert modellproblem.

Begrens brukere, datakilder og handlinger

Et sikkert internt KI-verktøy trenger flere kontrollnivåer. Det første er identitet: brukeren må autentiseres gjennom virksomhetens eksisterende innloggingsløsning. Det andre er autorisasjon: systemet må vite hvilke data og funksjoner denne personen faktisk har lov til å bruke.

Rollebasert tilgang kan kombineres med mer detaljerte regler basert på avdeling, kunde, prosjekt, lokasjon eller dokumentklassifisering. En ansatt i kundeservice bør ikke automatisk kunne søke i personalmapper, og en ekstern konsulent bør ikke få samme datatilgang som en fast systemeier.

Datakildene bør også godkjennes eksplisitt. I stedet for at verktøyet søker i hele virksomhetens filområde, kan det kobles til et kuratert kunnskapsgrunnlag med versjonskontroll, eiere og utløpsdatoer. God dataforvaltning er relevant også utenfor maritime miljøer, fordi pålitelige KI-svar avhenger av at kildene er korrekte, oppdaterte og forståelige.

Handlinger krever enda strengere grenser. Et verktøy som bare foreslår tekst har en annen risikoprofil enn en KI-agent som kan opprette ordre, sende meldinger, endre kundedata eller starte automatiserte arbeidsflyter.

Lesetilgang, anbefalinger og utførende handlinger bør behandles som tre separate sikkerhetsnivåer.

Bygg personvern og sikkerhet inn i arkitekturen

Personvern og informasjonssikkerhet bør påvirke arkitekturen fra starten. Det er ikke tilstrekkelig å legge til en brukervilkårstekst når løsningen er ferdig.

Virksomheten bør avklare:

• hvilke personopplysninger som behandles;

• hvilket formål behandlingen har;

• hvor data og logger lagres;

• om innhold brukes til å trene eksterne modeller;

• hvor lenge samtaler og forespørsler beholdes;

• hvordan ansatte får informasjon om behandlingen;

• hvordan tilgang fjernes når roller endres;

• hvordan sikkerhetshendelser oppdages og håndteres.

For interne verktøy bør dataminimering være et praktisk designprinsipp. Modellen trenger ikke alltid hele dokumentet, hele kundehistorikken eller alle profilopplysninger for å løse oppgaven. Løsningen kan hente bare relevante avsnitt, maskere identifikatorer eller bruke metadata til å filtrere bort innhold før det sendes videre.

Minst mulig nødvendig data bør være standardinnstillingen.

I tillegg bør virksomheten skille mellom utviklings-, test- og produksjonsmiljøer. Reelle kunde- eller ansattdata bør ikke kopieres til testmiljøer uten vurdering og beskyttelse. Sikkerhetstesting bør dekke både tradisjonelle svakheter og KI-spesifikke scenarioer, som manipulerende instrukser i dokumenter, forsøk på å hente skjult informasjon og omgåelse av rollebaserte regler.

Sørg for pålitelige svar, testing og menneskelig kontroll

Et internt KI-verktøy kan gi feil svar selv når datatilgangen er riktig. Derfor må løsningen vise hvor informasjonen kommer fra og hvor sikker den er.

For kunnskapsbaserte verktøy bør svar normalt være knyttet til godkjente kilder. Brukeren bør kunne åpne dokumentet, se dato og eier, og vurdere om innholdet fortsatt gjelder. Dersom systemet ikke finner tilstrekkelig grunnlag, bør det si dette tydelig fremfor å fylle gapet med en plausibel formulering.

Instruksjoner og systemregler må også testes. Prompt-utforming for interne KI-assistenter kan bidra til konsistente svar, men prompten kan ikke erstatte tekniske tilgangskontroller, kildefiltrering eller menneskelig godkjenning.

Menneskelig kontroll bør tilpasses konsekvensen av feil:

• Lavrisikooppgaver kan gi automatiske forslag.

• Kundekommunikasjon kan kreve godkjenning før utsendelse.

• Endringer i ordre, pris eller avtale bør ha tydelige kontrollpunkter.

• Personalrelaterte eller juridiske vurderinger bør ikke overlates til modellen alene.

KI-verktøyet bør støtte ansvarlige beslutninger, ikke skjule hvem som har ansvaret.

Test virkelige scenarioer før bred lansering

En teknisk demonstrasjon viser sjelden hvordan verktøyet oppfører seg i en travel arbeidshverdag. Før bred lansering bør løsningen testes med representative brukere, realistiske dokumenter og situasjoner der informasjonen er mangelfull, motstridende eller sensitiv.

Testplanen bør omfatte korrekte og ukorrekte brukerroller, forespørsler om begrenset informasjon, utdaterte dokumenter, tvetydig fagspråk, manipulerende instrukser, integrasjonsfeil og situasjoner der menneskelig godkjenning skal utløses.

Rask utvikling kan redusere tiden frem til pilot, men ansvarlig utvikling med høy hastighet viser hvorfor arkitektur, kodekvalitet og sikkerhetskontroller fortsatt må være på plass.

En pilot bør bevise kontroll og nytte, ikke bare at modellen kan produsere tekst.

Planlegg drift, logging og kontinuerlig forbedring

Et internt KI-verktøy må forvaltes etter lansering. Dokumenter endres, ansatte bytter roller, leverandører oppdaterer modeller, og nye typer misbruk kan oppstå. Uten tydelig driftseierskap kan kvalitet og sikkerhet svekkes over tid.

Virksomheten bør overvåke:

• hvilke funksjoner som brukes;

• hvor ofte svar blir avvist eller korrigert;

• hvilke datakilder som skaper feil;

• kostnader per avdeling eller arbeidsprosess;

• uautoriserte tilgangsforsøk;

• endringer i modellens svar og ytelse;

• hendelser som krever oppfølging.

Logger må samtidig utformes med hensyn til personvern. Det er ikke nødvendig å lagre alt for alltid. Formål, tilgang og lagringstid bør være definert, og sensitive forespørsler bør håndteres med særskilte regler.

Et tverrfaglig forvaltningsteam med representanter fra drift, IT, sikkerhet, personvern og den aktuelle forretningsfunksjonen kan prioritere forbedringer og godkjenne nye bruksområder.

Produksjonssetting er starten på styringen, ikke slutten på utviklingen.

Hvordan Dev House Norway støtter sikre interne KI-verktøy i Drammen

Dev House Norway kan støtte virksomheter i Drammen med å definere, utvikle og integrere interne KI-verktøy gjennom Skreddersydd programvareutvikling. Arbeidet kan omfatte behovskartlegging, tilgangsmodell, sikker arkitektur, brukeropplevelse, datakoblinger, API-integrasjoner, testplan og produksjonssetting.

En strukturert utviklingsprosess gjør det mulig å begynne med én avgrenset arbeidsoppgave og utvide løsningen når kontrollene, datagrunnlaget og den operative nytten er validert. Dette er særlig viktig for logistikk- og tjenestebedrifter som må gi ansatte rask tilgang til informasjon uten å åpne hele organisasjonens data for alle brukere eller modeller.

Konklusjon

Virksomheter i Drammen kan skape betydelig praktisk verdi med interne KI-verktøy, men nytten avhenger av tydelige grenser. Godkjente brukere, kuraterte datakilder, avgrensede oppgaver, menneskelig kontroll og sikker logging må utformes som deler av den samme løsningen.

Skreddersydd programvareutvikling gir virksomheten mulighet til å tilpasse verktøyet til reelle roller og arbeidsprosesser fremfor å akseptere en generell KI-tjenestes standardoppsett. Det beste neste steget er å velge én arbeidsoppgave og kartlegge brukere, data, handlinger og risiko før teknologien bestemmes.