Vad behöver ni veta före köpet?

Servicedesken vill ha hjälp med åtkomstärenden. Föreställ er en agent som läser begäran och föreslår vilka grupper en medarbetare ska tillhöra. Det låter avgränsat, tills någon frågar om agenten också får lägga till personen i gruppen. Börja där. Beskriv vad den får läsa, föreslå och ändra, och vilka ändringar som måste vänta på en människa. Att köpa en ”AI-assistent” lämnar för många av dessa beslut öppna.

Låt verksamhetsägaren och säkerhetsfunktionen skriva beskrivningen tillsammans. Ta med ett vanligt ärende och ett som ska avslås: någon ber om ett dokument hen inte får läsa. Ska agenten också läsa bifogade filer eller följa instruktioner i ärendet? Skriv ut det. Då kan leverantören svara på ert arbete och de kontroller det kräver, i stället för att återvända till samma allmänna presentation.

Rita vart informationen tar vägen. Håll isär verksamhetsdata, modellbehandling, körningsspår och säkerhetsloggar; de behöver egna destinationer i bilden. Lägg bredvid en lista över vem som bygger, publicerar, använder, godkänner och utreder. För varje anslutning behövs kontotyp, rättigheter och ett sätt att ta bort åtkomsten. Be sedan leverantören fylla i driftregion, underleverantörer och vilka rapporter som täcker tjänsten ni erbjuds.

Dify Enterprise beskriver drift i eget VPC, lokalt eller i isolerat nät. Langdock anger EU-drift för applikationen och de flesta modeller, beroende på inställningar.^1,2

Koppla sådana driftbesked till den offert och de modeller ni faktiskt väljer. För åtkomstagenten kan skissen börja med ett ärende, följt av läsning av tillåtna kataloguppgifter, ett mänskligt beslut och en ändring genom en begränsad anslutning. Skriv också vart spåren från varje steg skickas. Be leverantören korrigera skissen där den är fel. Den är ett förslag att diskutera, inte en beskrivning av hur en viss produkt redan fungerar.

En lista räcker för att hålla reda på svaren: krav, källa, vad den täcker, vad som återstår, ansvarig och beslut. Ett offentligt dokument berättar vad leverantören beskriver. Avtalet anger vad leverantören åtar sig. En demonstration visar hur just den visade lösningen beter sig. En revisionsrapport behöver läsas för att förstå dess omfattning. Skriv vilken sorts underlag ni har, så att ett löfte inte råkar bli ett godkänt prov.

Nexus har separat bekräftat att en SOC 2 Type 2-rapport finns. Vi har inte läst rapporten, och länken till hemsidan verifierar inte bolagets uppgift.³

För åtkomstagenten kan en rad se ut så här: ”Krav: ett obehörigt ärende får inte ändra katalogen. Källa: rollbeskrivning. Återstår: visa en nekad begäran och en oförändrad katalog i testmiljön. Ansvarig: katalogförvaltaren. Beslut: öppet.” Nästa granskare ser då exakt vad som saknas. Det öppna svaret säger inget om huruvida leverantören kan bygga funktionen; det säger att ni ännu inte har det belägg ni behöver.

Avsluta med ett kort beslutsblad: vad ni accepterar, vad som måste bli klart före drift och vad som fortfarande hindrar köpet. Ett inbokat möte är inget svar på ett obligatoriskt krav. För varje villkor behövs ett visst underlag, en person som bedömer det och ett besked om vad ett nej innebär. Frågor om helt andra, framtida användningar kan stå utanför den första beställningen.

I vårt exempel kan ni gå vidare med läsning och förslag medan skrivåtkomsten till katalogen förblir stängd. Den öppnas först när kontrollerna har visats och godkänts. Men bara om den begränsade agenten faktiskt fyller verksamhetens behov: behövs ändringen från start är den olösta frågan fortfarande ett inköpshinder. Låt säkerhets- och juridikfunktionen bedöma regelkraven separat. Listan hjälper dem att fatta beslut; den är inget besked om att ni uppfyller NIS2.