NÄR AI-VERKTYGET FÅR EN NY FUNKTION – TESTA INNAN DEN SLÄPPS TILL HELA JOBBET
Att tjänsten redan är godkänd betyder inte att varje ny funktion är det. En uppdatering kan öppna en ny datakälla, få rätt att skapa eller skicka något, spara annat innehåll än tidigare eller ändra vilka medarbetare som kan använda verktyget. Här är en liten förändringsrutin som leder till ett synligt beslut: stoppa, begränsa, köra pilot eller släppa brett.
Det gamla godkännandet gäller sina gamla förutsättningar
En verksamhet kan ha godkänt en chattfunktion för textutkast med okänsligt material. När samma tjänst senare får en mötesassistent, en koppling till dokumentlagret eller möjlighet att utföra åtgärder är leverantörsnamnet detsamma, men förutsättningarna är nya. Då behöver ni inte börja om från noll. Ni behöver kontrollera exakt vad som har ändrats och om det träffar gränserna i det tidigare beslutet.
Gör ett prov: lägg det gamla godkännandet bredvid leverantörens beskrivning av den nya funktionen. Markera varje mening som beskriver tillåtna data, användare, kopplingar och åtgärder. Om den nya funktionen inte ryms innanför alla fyra markeringarna ska den få ett eget beslut före bred användning.
Det här är också avgränsningen mot ett regressionstest av AI-resultatet. Regressionstestet frågar om ett befintligt arbetsflöde fortfarande ger godtagbara svar. Den här rutinen börjar tidigare och frågar om den nya funktionen alls ska aktiveras, för vilka och med vilken åtkomst. Ett regressionstest kan vara ett av proven i piloten, men ersätter inte beslutet.
Registrera förändringen innan någon provar skarpt
Skapa en kort förändringspost när ni ser en ny funktion i administratörsmeddelandet, produktens versionsinformation eller användargränssnitt. Den ska inte vara en teknisk roman. Skriv funktionens namn, vad leverantören säger att den gör, vilka användare som kan få den, planerat startdatum och en namngiven beslutsägare.
Lägg sedan till en mening om varför ändringen kan spela roll. Exempel: ”Funktionen kan läsa kalender och mejl för att föreslå mötesunderlag” är användbarare än ”ny AI-assistent”. Den första formuleringen pekar ut två dataflöden som går att kontrollera.
Microsoft beskriver Targeted release som en väg för utvalda användare att få funktioner tidigt, bland annat för att förbereda dokumentation, support samt efterlevnads- och säkerhetsgranskning. Microsoft varnar samtidigt för att releasevalen är en riktad best effort-mekanism och inte gäller varje uppdatering. Google skriver på motsvarande sätt att de flesta Workspace-funktioner visas automatiskt och att vissa typer av lanseringar inte brukar följa valda releasekanaler. En releasekanal är alltså en möjlighet att skapa framförhållning – inte en garanti för att varje ändring väntar på ert godkännande.
Rita den nya åtkomsten och det nya dataflödet
Besvara sex frågor tillsammans med systemägaren och den verksamhet som vill använda funktionen:
- Indata: vad kan användaren lämna in, och kan funktionen själv hämta mejl, filer, möten eller andra uppgifter?
- Utdata: var visas, sparas eller skickas resultatet?
- Åtgärder: kan funktionen bara föreslå, eller även boka, publicera, skicka, ändra och radera?
- Behörighet: använder den användarens rättigheter, ett gemensamt konto eller en administratörskoppling?
- Leverantörsgräns: lämnar uppgifter den miljö eller de underbiträden som det gamla beslutet omfattade?
- Spårbarhet: går det i efterhand att se vem som aktiverade funktionen, vilka källor den använde och vilka åtgärder den utförde?
Gör ett prov med syntetiska data: skapa en påhittad mötesinbjudan, en påhittad kundfil och en mapp som pilotanvändaren inte ska komma åt. Aktivera funktionen för testkontot. Kontrollera vilka objekt den hittar, vilka behörighetsfrågor som visas, var resultatet hamnar och vad loggen faktiskt berättar. Godkänt betyder inte bara att den rätta filen hittades; den förbjudna mappen ska också förbli osynlig.
Kör piloten med stoppregler, inte med nyfikenhet som plan
Välj den minsta grupp som ändå täcker de roller och arbetsfall funktionen är tänkt för. Pilotgruppen bör innehålla en verklig användare, en person som kan bedöma sakresultatet och någon som kan hantera åtkomst eller support. Den ska inte använda verkliga känsliga uppgifter bara för att testet ska kännas realistiskt. Börja med syntetiskt eller uttryckligen godkänt material.
Skriv före starten vad piloten ska visa. Ett enkelt protokoll kan innehålla fem krav:
- funktionen kommer bara åt de källor som står i förändringsposten,
- förbjuden information går inte att hämta genom ett normalt arbetsflöde,
- en människa godkänner åtgärder med verklig konsekvens,
- sakresultatet klarar era representativa testfall,
- supporten kan identifiera pilotanvändare och återställa den valda begränsningen.
Bestäm också stoppregler. Felaktig åtkomst, en utförd åtgärd utan avsett godkännande, avsaknad av nödvändig logg eller ett kritiskt fel i ett stoppfall ska pausa piloten. Ett genomsnittsbetyg får inte väga upp ett sådant fel.
Välj mellan fyra beslut och skriv varför
| Beslut | När det passar | Vad som måste dokumenteras |
|---|---|---|
| Stoppa | Ett kritiskt krav faller eller nödvändig begränsning saknas | Felet, konsekvensen, vem som kontaktar leverantören och villkor för nytt prov |
| Begränsa | Funktionen fungerar för ett smalare användningsfall eller utan en viss koppling | Tillåtna roller, data, källor och åtgärder |
| Fortsätt pilot | Resultatet är lovande men underlaget är för litet eller en risk återstår | Vilket nytt bevis som behövs, ansvarig och slutdatum |
| Släpp brett | Kraven är uppfyllda och support, information och återställning är klara | Beslutsägare, datum, omfattning och datum för uppföljning |
Undvik beslutet ”godkänd med försiktighet”. Det säger varken vem som ska vara försiktig eller vad personen ska göra. Översätt varje kvarvarande osäkerhet till en synlig begränsning, en kontroll eller ett nytt testdatum.
Förbered information, support och en verklig återställningsväg
Innan bred utrullning behöver användarna få veta tre saker: vad funktionen är avsedd för, vilka uppgifter den inte ska få och när en människa måste kontrollera resultatet eller åtgärden. Supporten behöver samtidigt kunna se om en fråga kommer från den gamla eller nya funktionen. Ta därför med funktionsnamn, pilot- eller releasegrupp och datum i felanmälan.
En återställningsväg är inte alltid en knapp som heter ”stäng av”. Den kan vara att ta bort en datakoppling, återkalla en behörighet, flytta användare ur en releasegrupp, blockera ett arbetsflöde eller pausa tjänsten. Prova vägen före bred utrullning. Om den inte går att prova, dokumentera varför och vem som får fatta stoppbeslutet ändå.
Microsoft rekommenderar att de flesta användare ligger kvar i standardrelease medan IT-personer och vana användare provar tidigt; för en större testgrupp föreslås en testmiljö. Google rekommenderar Scheduled Release i produktionskontot och ett separat konto under en annan domän med Rapid Release för stora organisationer som vill prova tidigare. Google påpekar dessutom att byte från Rapid till Scheduled kan göra att användare tillfälligt förlorar funktioner som ännu inte nått den senare kanalen. Det är ett konkret skäl att beskriva vad pilotgruppen gör om funktionen försvinner – inte bara vad den gör när funktionen fungerar.
En förändringspost som går att fatta beslut på
Vanliga frågor om att prova nya AI-funktioner
Måste varje liten AI-uppdatering få ett nytt godkännande?
Nej. Gör först en kort förändringsbedömning. Ett nytt beslut behövs när funktionen ändrar åtkomst, dataflöde, användningsområde, målgrupp, möjlighet att utföra åtgärder eller andra villkor som det tidigare godkännandet vilade på. En språkjustering utan sådan påverkan kan dokumenteras utan en ny pilot.
Hur stor ska pilotgruppen vara?
Det finns inget universellt antal. Välj den minsta grupp som täcker berörda roller och realistiska arbetsfall, men håll konsekvensen av ett fel begränsad. Skriv i förväg vilka resultat som krävs för bredare utrullning. En pilot med tjugo personer utan godkännandekrav ger sämre beslutsunderlag än en pilot med fem rätt valda personer och tydliga stoppregler.
Vad gör vi om leverantören inte låter oss stänga av funktionen?
Dokumentera begränsningen innan piloten. Återställningsvägen kan då vara att ta bort en koppling eller behörighet, flytta användare ur pilotgruppen, blockera användningsfallet eller pausa tjänsten. Om ingen rimlig begränsning finns ska det påverka beslutet att aktivera funktionen.