Verktyg som används på riktigt behöver en väg till drift

Det går numera att bygga en fungerande applikation genom att beskriva den med vanliga ord. En säljare gör en prisberäknare och en controller ett verktyg som jämför fakturor mot avtal, och det kan ske utan att IT är inblandad. Problemet uppstår den dag något av det som byggts börjar användas på riktigt.

Bygget är en sak, driftsättningen en annan

Så länge ett verktyg är en prototyp som bara skaparen använder är riskerna små. Går något fel är det lätt att börja om. När kollegor börjar förlita sig på verktyget, när det kopplas mot bolagets affärssystem eller när det får hantera kunduppgifter är det i praktiken ett system.

Då behövs svar på frågor som ingen ställde när det byggdes. Vem ansvarar för verktyget när skaparen byter jobb, och vad händer om det slutar fungera?

Det som avgör granskningen är vad verktyget får göra

Den enklaste skiljelinjen går mellan att läsa och att ändra. Ett verktyg som hämtar uppgifter ur ett system och visar dem kan som mest visa fel siffror. Ett verktyg som också får skriva tillbaka till systemet eller godkänna betalningar kan göra skada i stor skala innan någon märker det.

Ett närliggande resonemang finns i OWASP:s förteckning över risker med generativ AI, under rubriken Excessive Agency. Den gäller system som använder AI för att anropa funktioner i andra system, men tanken går att låna. Orsakerna som anges är att ett system har fler funktioner än det behöver, bredare behörigheter än det behöver eller kan utföra åtgärder med stor påverkan utan att någon verifierar eller godkänner dem. OWASP rekommenderar att funktioner och behörigheter begränsas till det som behövs och att åtgärder med stor påverkan kräver ett mänskligt godkännande. Uppdelningen mellan att läsa och att ändra är här författarens egen förenkling.

Reglerna kan hållas enkla. Verktyg som bara läser får en lätt väg till drift. Verktyg som skriver, eller som hanterar personuppgifter och ekonomi, passerar först en granskning av någon utanför byggarbetet, som tittar på behörigheterna innan något släpps.

En avgränsad miljö gör det billigt att misslyckas

Microsofts vägledning för Power Platform beskriver principen väl. Den som bygger arbetar i en egen utvecklingsmiljö, och lösningen sparas så att den går att återskapa. När den är redo att delas flyttas den till en produktionsmiljö, där användarna kan köra den utan att störas av pågående ändringar. Standardmiljön som följer med Microsofts tjänst är enligt Microsoft inte avsedd för långvarigt eller permanent arbete utöver personliga produktivitetsscenarier.

Principen gäller oavsett verktyg, och flytten till drift bör vara ett eget beslut som någon fattar.

Drift kräver en ägare och ett datum

När ett verktyg har flyttats till drift behöver det en namngiven ägare i verksamheten, en kort beskrivning av vad det gör och vilka data det rör, och ett datum då användningen följs upp. Vid det tillfället avgörs om det ska fortsätta, ändras eller stängas. Resonemanget är detsamma som för en pilot, och det finns utvecklat i Piloten som aldrig tog slut.

Börja med att ta reda på vilka egenbyggda verktyg som redan används av fler än sin skapare. Hur man hittar dem beskrivs i Hitta alla AI-initiativ. Det är de verktygen som borde ha passerat en granskning, och det är där behörigheterna ska kontrolleras först.