Slik designer du en avgrenset KI-assistent med verktøy, tilganger og kontekstgrenser

En avgrenset KI-assistent er en kontrollert forretningstjeneste, ikke en modell som har fått en høflig liste over ting den ikke skal gjøre. Assistenten kan instrueres om aldri å sende en melding, men forbudet har liten verdi dersom den samtidig har et sendeverktøy og en konto med vide rettigheter. Den reelle grensen ligger i den kjørbare tjenestekontrakten rundt modellen: hvilke oppgaver, data, identiteter, verktøy og handlinger hvert enkelt brukerbehov faktisk får utløse.

Hva skal assistenten få lov til å gjøre?

Teamet bør først skrive et tjenestemandat på én setning og deretter dele det opp i konkrete, synlige kapabiliteter. En nyttig form er: «For [berettigede brukere] kan assistenten [tillatt oppgavefamilie] med [godkjent informasjonsomfang] for å produsere [tillatt resultat], men den kan ikke [uttrykkelige ikke-mål eller konsekvensfulle beslutninger].» Mandatet tvinger frem valg om målgruppe, brukssituasjon, kunnskapsgrenser, menneskelig kontroll og risikoeier før verktøy kobles til.

Ord som «hjelpe», «behandle» og «administrere» er for brede til å fungere som tilgangsbeskrivelser. Del dem i søk, oppsummering, anbefaling, utkast, oppdatering, sending, sletting og godkjenning. To operasjoner kan ligge i samme samtalevindu, men skal likevel ha ulike data, identiteter og grenser. NIST beskriver dokumentasjon av formål, oppgaver, anvendelsesområde og kontroll, mens OWASP anbefaler minst mulig verktøyfunksjonalitet. Selve kapabilitetsmetoden er en praktisk redaksjonell syntese, ikke et krav fra noen av dem.

• Navngi berettigede brukere og hvordan identiteten etableres.
• Beskriv den tillatte oppgaven og hva som teller som et vellykket resultat.
• Angi hvilke utfall som bare kan foreslås eller opprettes som utkast.
• Før opp forbudte beslutninger, ansvarlig tjenesteeier og nødvendig menneskelig overlevering.

Hvilken informasjon kan hver kapabilitet bruke?

Hver kapabilitet trenger en informasjonsramme som definerer berettigede data og tillitsgrenser; et tokenbudsjett er bare én teknisk detalj. Beskriv godkjente systemer, dokument- og posttyper, klassifisering, objektfiltre, datoer, aktualitetskrav og brukerens eksisterende rettigheter. Før også opp hva som uttrykkelig er forbudt. Hvis en supportmedarbeider bare kan se egne kundesaker, skal ikke assistenten gjøre nabokontoer synlige ved å hente dem inn i samtalen.

Dokumenter, vedlegg, eksterne meldinger, API-svar og søkeresultater må behandles som upålitelige data, ikke som nye tjenesteinstruksjoner. En tekst som ber assistenten ignorere reglene, får dermed ingen myndighet bare fordi den ble funnet i en godkjent mappe. Skill også mellom økthistorikk og vedvarende minne. For minnet må teamet fastsette berettigelse, validering før lagring, isolasjon mellom brukere og økter, utløp, størrelse, sletting og informasjon som aldri skal lagres.

• Kilde og posttype: hvilke systemer og objekter er berettiget?
• Omfang og aktualitet: hvilke filtre og tidsgrenser gjelder?
• Tillit: er innholdet styrende instruksjon eller upålitelige data?
• Minne: hva kan vedvare, hvor er det isolert, og hva skal slettes?

Når nødvendig dokumentasjon er utilgjengelig, mangler eller er foreldet, skal assistenten kvalifisere svaret, be om manglende informasjon eller avslå. Et større kontekstvindu gir verken utvidet tilgang eller bedre bevis. Det kan bare romme mer innhold, også mer irrelevant eller manipulerende innhold. Grensen må derfor håndheves under uthenting og før resultatet brukes, ikke først etter at modellen har formulert et overbevisende svar.

Hvordan håndhever identitet, verktøy og tilganger grensen?

Autentisering, autorisasjon og godkjenning må behandles som tre separate beslutninger. Autentisering fastslår hvem brukeren, klienten eller arbeidsidentiteten er. Autorisasjon avgjør om denne aktøren kan utføre en bestemt operasjon mot en beskyttet ressurs. Godkjenning aksepterer én konkret foreslått handling. En innlogget bruker er derfor ikke automatisk autorisert til å endre en post, og et trykk på «godkjenn» kan ikke tilføre en rettighet brukeren mangler.

Velg uttrykkelig om verktøyet skal opptre med delegert brukerautoritet eller en kontrollert arbeidsidentitet. Det må aldri ubemerket arve en privilegert operatørkonto. Verktøyporten og systemet som eier ressursen, skal håndheve verb, objekter, felt, destinasjoner, tokenmål og varighet på den handlende identiteten. Ledetekster og språklige rekkverk kan påvirke modellens forslag, men er ikke autorisasjonskontroller. For beskyttede MCP-integrasjoner gir ressursbundne token og minst mulige omfang et relevant mønster, ikke et universelt krav.

• Eksponer «hent berettiget sak» fremfor generell database- eller nettlesertilgang.
• Valider tillatte parametere før et verktøykall sendes videre.
• Begrens ressurs, operasjon, felt, mål, varighet og identiteten som utfører handlingen.
• Fastsett tjenestespesifikke grenser for hastighet, forsøk, kjedelengde, kostnad og kjøretid.

Samtalen kan være sammenhengende, men myndigheten skal være delt i små kapabiliteter som håndheves hver for seg.

Hvor mye handling skal en kapabilitet kunne utføre?

Hver kapabilitet trenger et uttrykkelig handlingstak, med sterkere og mer uavhengige kontroller jo nærmere den kommer en ekstern tilstandsendring. En praktisk stige går fra å svare eller oppsummere, via anbefaling og forslag, til utkast, avgrenset reversibel skriving og en konsekvensfull ekstern handling. Øverst ligger beslutninger tjenesten ikke får ta. Stigen er en redaksjonell designmodell støttet av prinsippene om minste funksjonalitet, handlingsbegrensning og ekstern håndheving.

1. Svar eller oppsummer fra berettiget informasjon uten å endre ekstern tilstand.
2. Anbefal eller bygg et kontrollerbart forslag uten å utføre det.
3. Opprett et redigerbart utkast på et ikke-endelig arbeidsområde.
4. Skriv godkjente felt i en avgrenset, reversibel arbeidsflyt.
5. Utfør en konsekvensfull ekstern handling bare med gyldig autorisasjon og handlingsbundet godkjenning.
6. Avslå en beslutning som tjenesten aldri skal ta.

Skill alltid et meldingsutkast fra sending, et endringsforslag fra oppdatering og en reversibel rettelse fra sletting. Før en konsekvensfull handling skal brukeren få en kontrollerbar forhåndsvisning. Godkjenningen bør bindes til aktør, verktøy, målressurs, normaliserte parametere, tidspunkt og utløp og valideres på nytt ved utførelse. Endres mottaker, beløp, innhold eller mål, gjelder ikke den tidligere godkjenningen for den nye handlingen.

Godkjenning kan ikke erstatte autorisasjon, utvide en stående tilgang eller gjøre et forbudt utfall tillatt. Betalinger, tilgangstildelinger, destruktive operasjoner, produksjonsendringer, vesentlige eksterne forpliktelser og faglige høyrisikobeslutninger må ligge under egnede deterministiske regler og ansvarlige, kvalifiserte mennesker. Sett i tillegg grenser for gjentakelser, batcher, ressursbruk, idempotens, tilbakerulling og brytere ut fra den aktuelle tjenesten, uten å importere tilfeldige standardtall.

Hva skal skje når assistenten når en grense?

Avslag, avgrenset hjelp, menneskelig overlevering og sikkerhetseskalering må utformes som egne tjenesteutfall med reelle stoppvilkår. Assistenten bør kjenne forskjell på en oppgave utenfor mandatet, ikke-berettiget informasjon, manglende autorisasjon, nødvendig godkjenning, manglende eller foreldet dokumentasjon, påkrevd faglig skjønn, utilgjengelig avhengighet, nådd driftsgrense og et sikkerhetssignal. Kategoriene gir bedre ruting og måling enn en generell feilmelding.

• Forklar grensen enkelt uten å røpe sensitive policy- eller sikkerhetsdetaljer.
• Påstå aldri at et søk, verktøykall, en godkjenning eller skriving lyktes når det ikke skjedde.
• Tilby bare den trygge delen, for eksempel et utkast, en sjekkliste eller en forespørsel om informasjon.
• Stans ventende utførelse til riktig menneske eller hendelsesprosess har behandlet saken.

En nyttig overlevering pakker det opprinnelige målet, relevant ikke-sensitiv kontekst, forsøkt kapabilitet, årsak, tilgjengelig eller manglende dokumentasjon, foreslått neste steg og sporingsidentifikator. Mottakeren må være navngitt på forhånd. Ordinær brukerstøtte, forretningsgodkjenning og sikkerhetshendelser kan bruke noe av samme bevismateriale, men har forskjellige eiere og ulik hastegrad. Dersom handlingen endres mens den venter, kreves ny validering fremfor automatisk gjenopptakelse.

Kontrollutformingen bør ta høyde for blant annet omgåelse av godkjenning, privilegieeskalering, dataeksfiltrasjon, minneforgiftning og rekursive verktøykjeder. Et avslag fra modellen er ikke nok dersom verktøyet likevel fortsetter. Stoppvilkåret må også avbryte kjøringen, sperre nye kall og bevare et passende revisjonsspor. Ved et sikkerhetssignal går saken til hendelsesprosessen, ikke bare til en kollega som kan trykke «godkjenn».

Hvordan gjøres grensene om til et operativt design?

Teamet bør fylle ut én rad i et kapabilitetsark for hver synlige operasjon og knytte raden til kontroller, bevis, tester, driftsmålinger og en ansvarlig eier. Ikke skriv «assistenten har CRM-tilgang». Skriv «hent og oppsummer en berettiget supportsak». Da kan teamet avgrense aktør, autentisering, informasjon, økthistorikk, minne, verktøy, handlende identitet, ressurs, handlingstak, godkjenning, stoppvilkår, avslag og eskalering uten at ett bredt produktnavn skjuler forskjellene.

• Brukeroppgave, berettiget aktør og autentiseringsmåte.
• Informasjonsramme, økthistorikk og regler for vedvarende minne.
• Smal verktøyoperasjon, handlende identitet og ressursomfang.
• Handlingstak, godkjenning, driftsgrenser og stoppvilkår.
• Avslagsatferd, trygg delhjelp og ansvarlig eskaleringsmål.
• Revisjonsspor, evalueringsscenarioer, produksjonsmålinger og eier.

Et internt supportverktøy viser hvorfor denne oppdelingen er nyttig. Saksoppsummering, svarutkast og godkjent sending kan dele samtaleflate, men skal ikke dele alle rettigheter. Lesekapabiliteten trenger delegert innsyn i saker medarbeideren allerede kan se. Utkastskapabiliteten kan skrive til et ikke-endelig arbeidsområde. Sendingen trenger en egen smal operasjon, gyldig avsenderautorisasjon og en godkjenning som fortsatt samsvarer med mottaker og godkjent innhold.

Revisjonssporet skal gjøre det mulig å rekonstruere hvem som ba om hva, hvilken kapabilitet og policy som gjaldt, hvilke kilde- og verktøyklasser som ble brukt, hvilke autorisasjons- og godkjenningsutfall som forelå, og hva som faktisk skjedde. Samtidig skal hemmeligheter og unødvendig sensitivt innhold skjermes. Målingene må være nyttige for den aktuelle raden: grenseavslag for lesing, markører for udokumenterte påstander i utkast og parameteravvik ved sending.

Hvilke bevis kreves før lansering og videre drift?

Lansering krever bevis for at både den tillatte tjenesten og de forventede avslagene fungerer under produksjonslignende forhold. Test vanlige oppgaver sammen med tilgang på tvers av kontoer, uautoriserte verktøy, foreldet dokumentasjon, manipulerende hentet innhold, forbudte data, omgåelse av godkjenning, endrede parametere, gjentatte forsøk, avhengighetsfeil, dataeksfiltrasjon og løpske kjeder. Et grønt resultat for en nyttig oppgave sier ellers lite om hvor godt grensen holder.

• Kan berettigede brukere fullføre den lovede oppgaven med riktig grunnlag?
• Avslås feil bruker, ressurs, verktøy, mottaker eller parameter på riktig sted?
• Stopper kjøringen ved manglende bevis, utløpt godkjenning, avhengighetsfeil og driftsgrense?
• Kan et utvalg hendelser rekonstrueres uten at logger lagrer hemmeligheter eller ubegrenset sensitiv kontekst?
• Har tjeneste-, tilgangs-, forretnings- og sikkerhetseiere myndighet til å pause eller trekke tilbake kapabiliteten?

I drift bør teamet følge kapabilitetsspesifikke utfall som uventet verktøybruk, gjentatte avslag, autorisasjonsfeil, endrede godkjenninger, avvikende handlingssekvenser, treghet, ressursbruk og gradvis endret atferd. Overvåkingen må utformes etter virksomhetens risiko-, personvern- og arkivkrav; den er ikke en begrunnelse for å beholde alle rå ledetekster. Kjente begrensninger og feilmodi må være forståelige for brukere og operatører som skal handle på dem.

Vesentlige endringer i modell, ledetekst, gjenfinning, minne, verktøy, rettigheter, policy, data, leverandør eller driftskontekst skal åpne de berørte testene og lanseringsbevisene på nytt. Endringsvurderingen bør identifisere hvilke kapabiliteter, identiteter, logger og eskaleringsløp som påvirkes. Et tidligere godkjent system er ikke automatisk godkjent når handlingsbanen er endret, selv om samtalegrensesnittet ser likt ut for brukeren.

Begynn med den minste kapabiliteten som gir reell nytte, og utvid myndigheten gjennom vurderte endringer fremfor en ny formulering i ledeteksten. Når tjenesten berører sensitive data, vedvarende minne, privilegert tilgang, eksterne forpliktelser, destruktive endringer eller hendelseshåndtering, må relevante eiere for sikkerhet, identitet, personvern, arkiv, risiko og drift delta. Juridiske, regulatoriske og andre faglige høyrisikovurderinger skal gå til kvalifiserte spesialister i en separat styrt prosess.