Design en afgrænset AI-assistent med værktøjer, rettigheder og kontekstgrænser

En AI-assistent er først reelt afgrænset, når dens tjenestekontrakt kan håndhæves uden for sprogmodellen. En prompt kan sige, at assistenten ikke må sende en besked, men forbuddet er svagt, hvis den stadig har et sendeværktøj og en gyldig legitimationsoplysning. Den praktiske grænse består derfor af dataadgang, identitet, smalle operationer, godkendelser, stopregler og revisionsspor. De skal udformes for hver brugersynlig kapabilitet, før assistenten får forbindelse til forretningssystemer.

Hvad skal assistenten have lov til at gøre?

Teamet bør begynde med et charter på én sætning og derefter opdele løftet i konkrete kapabiliteter. En brugbar form er: For bestemte, berettigede brugere må assistenten udføre en afgrænset opgavefamilie med godkendte oplysninger for at levere et tilladt resultat, men den må ikke udføre navngivne konsekvensfulde eller fagligt regulerede beslutninger. Formuleringen tvinger teamet til at angive målgruppe, driftsmiljø, tilsyn og ejer, før brede ambitioner bliver til teknisk adgang.

• Erstat “hjælp med kundeservice” med særskilte operationer som at finde en sag, opsummere den, skrive en kladde og sende et godkendt svar.
• Angiv hvilke medarbejdergrupper og arbejdssituationer der er berettigede.
• Beskriv de understøttede opgaver og de vidensgrænser, som svarene skal respektere.
• Navngiv menneskeligt tilsyn, risikoejer og modtager af en overdragelse.
• Gør forbudte resultater eksplicitte, herunder beslutninger som kræver en kvalificeret specialist.

Kapabiliteten er den praktiske kontrolenhed, fordi verberne kræver forskellig myndighed. At læse en sag er ikke det samme som at ændre den, og en kladde er ikke en afsendelse. NIST beskriver dokumentation af formål, understøttede opgaver, anvendelsesområde, vidensgrænser og menneskeligt tilsyn, mens OWASP anbefaler mindst mulig værktøjsfunktionalitet. Selve kapabilitetsmetoden er en redaktionel syntese af disse principper, ikke et bindende krav eller en certificeringsmodel.

Hvilke oplysninger må hver kapabilitet bruge?

Hver kapabilitet skal have en informationsramme, som fastlægger berettigede data og tillidsgrænser; en teknisk tokenramme er ikke nok. Beskriv de godkendte systemer, posttyper, klassifikationer, objekter, felter, datoer og aktualitetskrav. Anvend desuden brugerens aktuelle rettigheder som filter. Hvis en medarbejder kun må se sager for bestemte konti, må assistentens søgning ikke udvide dette udsnit, blot fordi et indeks rummer flere poster.

• Godkendte systemer, dataklasser og posttyper.
• Filtre for konto, objekt, felt, periode og forretningsenhed.
• Krav til aktualitet og håndtering af modstridende kilder.
• Brugerens rettigheder på forespørgselstidspunktet.
• Tillidsklasse for dokumenter, beskeder, vedhæftninger og API-svar.
• Sessionshistorik, som må genbruges i den aktuelle samtale.
• Vedvarende hukommelse, udløb, sletning og data, der aldrig må gemmes.

Dokumenter, eksterne beskeder, vedhæftninger, hentede websider og API-svar bør behandles som ubetroet indhold, ikke som skjulte instruktioner til tjenesten. Vedvarende hukommelse kræver særskilt validering, isolation mellem brugere og sessioner, integritetskontrol samt tjenestespecifikke grænser for størrelse og levetid. Mangler nødvendig dokumentation, er den utilgængelig eller for gammel, skal svaret afvises eller tydeligt kvalificeres. Mere kontekst skaber hverken ny adgangsret eller sandhed.

Hvordan skal identitet, værktøjer og rettigheder håndhæve grænsen?

Autentifikation, autorisation og godkendelse skal behandles som tre selvstændige beslutninger, og den faktiske grænse skal håndhæves i værktøjsgatewayen og det modtagende system. Autentifikation fastslår, hvem brugeren, klienten eller arbejdsidentiteten er. Autorisation afgør, om denne identitet må udføre en bestemt operation på en beskyttet ressource. Godkendelse accepterer én foreslået handling. Ingen af beslutningerne bør overlades alene til modellens formulering eller vurdering.

• Hvem eller hvad er autentificeret, og hvordan er identiteten etableret?
• Hvilket verbum på hvilken ressource er den handlende identitet autoriseret til?
• Er netop dette forslag med disse parametre blevet godkendt og stadig uændret?

Vælg bevidst mellem delegeret brugeradgang og en kontrolleret arbejdsidentitet; assistenten må ikke stiltiende arve en privilegeret operatørkonto. Udstil en snæver operation med validerede parametre i stedet for generel adgang til postkasse, database, browser eller kommandoskal. Begræns verber, ressourcer, felter, destinationer, legitimationsoplysningers levetid og tokenets tiltænkte modtager. MCP-specifikationen illustrerer denne opdeling for beskyttede MCP-integrationer, men dens protokolkrav gælder ikke automatisk for alle værktøjsarkitekturer.

Samtalen må gerne være sammenhængende; myndigheden skal være opdelt i små, selvstændigt håndhævede kapabiliteter.

Hvor meget handling må en kapabilitet kunne udføre?

Hver kapabilitet skal have et udtrykkeligt handlingsloft, og uafhængige kontroller skal blive stærkere, når assistenten går fra at svare til at ændre ekstern tilstand. Den følgende trappe er en praktisk redaktionel model, ikke en universel risikoklassifikation. Den hjælper teamet med at adskille et informativt svar fra en kladde, en reversibel ændring og en handling, som binder organisationen over for kunder, medarbejdere eller leverandører.

1. Svar eller opsummer: brug kun berettigede kilder, og ændr ingen ekstern tilstand.
2. Anbefal eller foreslå: vis grundlag og usikkerhed, men udfør ikke forslaget.
3. Opret kladde: skriv til et ikke-endeligt arbejdsområde med en navngiven kontrollant.
4. Udfør en afgrænset, reversibel skrivning: valider objekt og felter, og understøt idempotens eller tilbagerulning.
5. Udfør en konsekvensfuld ekstern handling: kræv gyldig autorisation, præcis forhåndsvisning, handlingsbundet godkendelse og en uafhængig udførelsespolitik.
6. Mød en forbudt beslutning: undlad kapabiliteten, afvis downstream, og send opgaven til en kvalificeret person eller særskilt styret proces.

Ved en konsekvensfuld handling bør godkendelsen bindes til aktør, værktøj, målressource, normaliserede parametre, tidspunkt og udløb og derefter kontrolleres umiddelbart før udførelse. Ændres modtageren eller indholdet, kræves en ny vurdering. Godkendelsen kan aldrig tilføre manglende autorisation, udvide en stående rettighed eller gøre en forbudt beslutning tilladt. Betalinger, adgangstildelinger, destruktive operationer, produktionsændringer, væsentlige eksterne løfter og faglige højrisikobeslutninger kræver passende menneskelig og deterministisk kontrol.

Hvad skal ske, når assistenten rammer en grænse?

Afvisning, sikker delvis hjælp, menneskelig overdragelse og sikkerhedseskalering skal designes som egentlige serviceresultater med en reel stoptilstand. Assistenten bør angive grænsen i almindeligt sprog uden at afsløre følsomme politikdetaljer. Den må aldrig hævde, at en kilde blev kontrolleret, et værktøj kaldt, en godkendelse modtaget eller en ændring gennemført, hvis det ikke skete. Et afslag skal gøre næste ansvarlige skridt tydeligt.

• Opgaven ligger uden for tjenestens formål.
• Oplysningerne er ikke berettigede.
• Autorisation mangler.
• Godkendelse er påkrævet.
• Dokumentation mangler eller er forældet.
• Specialistvurdering er nødvendig.
• Et værktøj eller en afhængighed er utilgængelig.
• En driftsgrænse er nået.
• Et sikkerhedssignal er registreret.

Tilbyd kun den sikre del, eksempelvis en kladde, en tjekliste eller en anmodning om manglende information. En overdragelsespakke bør indeholde det oprindelige mål, relevant ikke-følsom kontekst, forsøgt kapabilitet, årsag, tilgængelig eller manglende dokumentation, foreslået næste skridt og sporings-id. Hold almindelig brugersupport, forretningsgodkendelse og sikkerhedshændelser adskilt, da de har forskellige ejere og hast. Ventende udførelse skal forblive stoppet, indtil den rette ejer har handlet og forslaget er valideret igen.

Hvordan omsættes grænserne til et operationelt design?

Teamet bør udfylde én designrække for hver brugersynlig operation og forbinde hvert felt med håndhævelse, bevis, test, driftsmåling og en ansvarlig ejer. Rækken skal angive berettiget aktør, autentifikation, informationsramme, sessions- og hukommelsesregler, smalt værktøj, handlende identitet, ressourcer, handlingsloft, godkendelse, driftsgrænser, afvisning og eskalering. En række med teksten “assistenten har adgang til CRM” er for bred til at kunne styres eller evalueres.

De tre operationer kan dele samtalevindue uden at dele dataadgang, legitimationsoplysninger eller handlingsloft. Logningen skal kunne rekonstruere forespørgsel, kapabilitet, politik, kildeklasse, værktøj, autorisation, godkendelse, resultat og aktive versioner, men bør ikke opsamle hemmeligheder eller ubegrænset følsomt indhold. Driftsmålinger skal knyttes til beslutninger: gentagne grænseafvisninger kan vise et uklart servicecharter, mens en uventet værktøjssekvens kan kræve teknisk stop og sikkerhedsundersøgelse.

Hvilket bevis kræves før og efter frigivelse?

Frigivelse kræver bevis for, at både den tilladte service og de forventede afvisninger virker under forhold, der ligner den faktiske drift. Positive eksempler alene viser ikke, om adgangsgrænser, stopregler og godkendelser holder. Test hver kapabilitet med realistiske identiteter, dataklasser, afhængigheder og fejltilstande. Kendte begrænsninger skal være synlige for brugere og drift, og ejerne skal have myndighed til at sætte kapabiliteten på pause, ændre den eller tage den ud af brug.

• Gyldig opgave med berettigede og aktuelle kilder.
• Adgangsforsøg på tværs af konti eller brugergrupper.
• Uautoriseret værktøj eller ressource.
• Forældet, manglende eller modstridende dokumentation.
• Ondsindede instruktioner i hentet indhold.
• Forbudte eller følsomme data.
• Forsøg på at omgå godkendelse.
• Ændrede parametre efter godkendelsen.
• Dubletforsøg, afhængighedsfejl og udløste stopmekanismer.
• Forsøg på dataudtræk eller løbske værktøjskæder.

Overvåg derefter kapabilitetens faktiske resultater: uventet værktøjsbrug, gentagne afvisninger, autorisationsfejl, ændrede godkendelser, usædvanlige handlingssekvenser, drift, svartid, ressourceforbrug og fejl. Målingerne skal udformes efter organisationens risiko-, privatlivs- og journaliseringskrav. Materielle ændringer i model, prompt, retrieval, hukommelse, værktøj, rettighed, politik, data, leverandør eller driftskontekst bør genåbne de berørte test og frigivelsesbeviser; en tidligere bestået evaluering er ikke en permanent garanti.

Begynd med den mindste kapabilitet, der skaber reel nytte, og udvid kun myndigheden gennem en gennemgået ændring. Inddrag sikkerhed, identitetsforvaltning, privatliv, journalisering, risiko og serviceejere, når løsningen berører følsomme oplysninger, vedvarende hukommelse, privilegeret adgang, eksterne forpligtelser, destruktive ændringer eller hændelseshåndtering. Juridiske, regulatoriske og andre faglige højrisikovurderinger skal føres til kvalificerede specialister og en særskilt styret proces, ikke blot til en ekstra prompt eller godkendelsesknap.