Den här sidan visas på engelska medan en granskad översättning för ditt språk förbereds.
Varför vi behandlar agentavsikt som ett styrningskontrakt, inte ett humör
Ett enkelt formulerat Perspectis AI-perspektiv: var agentavsikt hör hemma i företags-AI (policy, identitet, verktyg, observerbarhet) – inte bara i prompts – och hur vi tänker kring risknivåer och promptinjektion.
En enkel notis för ledare, riskägare och kundteam (april 2026)
Det korta svaret
"Agentiska" system är i rubrikerna: assistenter som planerar, anropar verktyg och agerar med mindre handhavande. Vi anser att idéerna bakom den förändringen är värda att publicera som ett branschperspektiv – eftersom den svåra frågan inte är om modeller kan låta självsäkra; det är om en organisation kan försvara vem som fick göra vad, och varför, när något går fel eller när en tillsynsmyndighet frågar.
Perspectis AI är byggd så att avsikt (vilket arbete som begärs och under vems auktoritet) utförs på styrningsvänliga platser – identitet, policy, verktygsgränser och observerbarhet – inte bara i en modells prompt. Det är så vi anpassar "hjälpsam assistent"-energi med vårdplikt i professionella miljöer.
Vad vi menar med ”avsikt” i klartext
I vardagligt språk är avsikt helt enkelt målet med en begäran: ”sammanfatta detta ärende”, ”utkasta ett e-postmeddelande”, ”skapa en faktura”, ”köra en efterlevnadskontroll”.
I en seriös plattform är avsikt också strukturell:
- Vem initierade arbete (en person, en roll, en tjänst).
- Vilken funktion får köras (till exempel sökvägen Personlig agentrepresentant kontra ett bakgrundsjobb).
- Vilken åtgärdsklass är involverad (läsa poster kontra ändra dem kontra pengarörelser kontra oåterkallelig administration).
Inget av detta bör antydas endast genom smart formulering i en chattruta. Vi behandlar det som information som plattformen måste förstå och tillämpa – så modellen är inte den enda platsen där ”avsikt” finns.
Varför avsikt inte bara kan leva inuti modellen
En stor språkmodell kan tolka språk; Det kan inte i sig självt vara registreringssystemet för tillstånd, sekretess eller faktureringspolicy.
Vi designar kring en enkel princip: styrning hör hemma i applikations- och dataplanet, inte bara i instruktioner till en modell.
Det betyder:
- Policykontroller (funktioner, roller, organisationsgränser) avgör om en åtgärd kan fortsätta – även om modellen "överensstämmer" med en skadlig eller förvirrande begäran.
- Verktygs- och åtgärdsregister avgör vilka funktioner som finns och hur riskabel var och en är; modellen får inte uppfinna nya privilegierade slutpunkter genom övertygande text.
- Informationsbarriärer och liknande kontroller gäller fortfarande när en assistent hämtar eller sammanfattar känsligt material – eftersom åtkomstregler inte är förhandlingsbara i naturligt språk.
Denna hållning är hur vi reducerar en hel klass av fellägen där ett flytande svar ser auktoriserat ut men inte är det.
Hur vi tänker på risk utan att dränka någon i jargong
Olika handlingar medför olika verkliga risker. Vi grupperar den idén i en praktisk stege som många team redan känner igen:
| Enkel idé | Vad det tenderar att betyda i verksamheten |
|---|---|
| Läs | Slå upp saker; behöver fortfarande korrekta åtkomst- och sekretessregler, men ingen varaktig förändring i sig. |
| Agera (ändra data) | Skapa eller uppdatera register; förtjänar tydlig ansvarsskyldighet och ofta ett bekräftelsesteg i kanaler med högre risk. |
| Transakera (pengar eller fakturering) | Finansiellt eller fakturanslutet arbete; förtjänar uttrycklig bekräftelse och starka tillstånd – eftersom misstag blir kommersiella och ryktesmässiga händelser. |
| Irreversibla eller destruktiva | Administrativa eller svåråtkomliga operationer; förtjänar de strängaste kontrollerna – och i vår designriktning, inte den typ av arbete vi vill ha tyst drivna från de mest riskfyllda handsfree-kanalerna som röst utan extra skyddsåtgärder. |
Utöver risken per handling bryr vi oss också om människor i loopen-mönster på produktnivå: där en människa måste godkänna, där en människa övervakar och kan ingripa, och där autonomin avsiktligt begränsas. Det är inte byråkrati för dess egen skull; det är hur reglerade och rykteskänsliga organisationer arbetar med bevis.
--
Snabb injektion och "emergent" beteende: vad som faktiskt gäller
Snabb injektion (försök att kapa eller förvirra en assistent med kontradiktoriskt text) är ett känt branschproblem. Vi tar det på allvar – och vi är ärliga om att inget textfilter är en trollstav.
Det vi betonar för kunder är berättelsen om djupförsvar:
-
Mitigering vid modellgränsen (detektering, sanering, loggning) minskar hur mycket fientlig text som når modellen oförändrad.
-
Hårda grindar i programvara avgör fortfarande om verktyg körs, pengar flyttas eller begränsad data returneras – så en manipulerad modell blir inte en tyst åsidosättning för företagspolicy.
Den kombinationen är hur vi pratar om säkerhet utan att låtsas att modellen är ofelbar.
Jämförelse i korthet (strukturell, inte en veckovis funktionspoäng)
Vi avser denna tabell för intressentdiskussioner –positionering, inte en kryssrute-utmaning. Produkter förändras snabbt; arkitekturens avsikt förändras långsammare.
| Ämne | Perspectis AI (hur vi bygger) | Typiska konsumentchattupplevelser | Organisationsbyggda modeller och verktygsstackar |
|---|---|---|---|
| Där avsikten måste finnas | Identitet, policy, register, strukturerade förfrågningar, observerbarhet | Mestadels i konversationen | Vad varje team implementerar |
| Vem äger verkställigheten | Plattformslagret vi levererar och utvecklar | Leverantörens produkt + hyresgästens administratörsval | Den antagande organisationens teknik- och säkerhetsteam |
| Pengarflyttande och oåterkalleligt arbete | Explicit riskramning, bekräftelser, kanalbegränsningar i vår riktning | Ofta utanför omfattningen eller generisk | Helt anpassad – kraftfull och ansvarsfull |
| Modellkontextprotokoll och verktyg | Vi behandlar verktyg som styrda funktioner, inte tysta superkrafter | Varierar beroende på produkt | Beror helt på implementeringskvalitet |
| Revisionsberättelse | Utformad för "vem godkände vad och varför" som en plattformsfråga | Varierar; ofta lättare | Helt anpassad |
| Bästa mentala enradsmodellen | Styrd assistent inom en operativ plattform | Hjälpsam konversationsyta | Anpassad agentstack |
Varför vi publicerar den här typen av perspektiv
Våra kunder köper inte bara ”en AI-funktion”. Det verkliga åtagandet är försvarbar drift: kontinuitet, separation av arbetsuppgifter och en berättelse som håller när något misslyckas. Vi investerar i offentlig, tydlig formulering – tillsammans med djupare tekniskt material för säkerhets- och arkitekturkollegor – eftersom våra kunder förtjänar tydlighet om vad som är marknadsföring kontra vad som är strukturellt.
Perspectis AI-demomiljö finns delvis för att göra den skillnaden konkret: inte en enda smidig demotråd, utan en bred katalog av realistiska scenarier där avsikt, policy och arbetsflöde framstår som förstklassiga angelägenheter.
Källor (externa, för allmän branschkontext)
- OWASP: OWASP Top 10 for Large Language Model Applications
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
Detta dokument är skrivet för externa, icke-tekniska läsare. Djupare tekniska bedömningar av kontroller, implementeringsstatus och bevis finns i vår säkerhets- och arkitekturdokumentation för kunder och revisorer.