Retroillustration av en kvinna som lämnar över ett kort till en man som granskar det med ett förstoringsglas vid en disk.
Förstoringsglaset gestaltar en kontroll av åtkomsten innan supporten ändrar några inställningar.

NYHET // CHATGPT BUSINESS // SUPPORT // MODELLÅTKOMST

Saknas en modell i ChatGPT? Testa åtkomsten innan ni ändrar något

När en medarbetare saknar en väntad modell är det frestande att börja slå av och på behörigheter. OpenAI har nu lagt till Model Test för administratörer. Funktionen visar medlemmens effektiva modellåtkomst och de sparade inställningar som bidrar till resultatet – utan att testet i sig ändrar åtkomst, behörigheter eller användningsgränser. Så gör ni kontrollen reproducerbar och lämnar ett supportunderlag som skiljer administrationsläget från det användaren faktiskt ser.

Publicerad: 2026-09-16 // Lästid: ca 6 min

Model Test är diagnostik, inte en behörighetsändring

I versionsanteckningen den 11 september 2026 (öppnas i ny flik) beskriver OpenAI Model Test för ChatGPT Business. En administratör kan använda testet för att förstå vilka modeller en medlem kan använda och vilka inställningar som bidrar till åtkomsten.

Den viktigaste gränsen för ett supportärende är vad provet inte gör. Enligt OpenAI ger testet inte medlemmen tillgång till en modell, ändrar inte inställningar eller användningsgränser och åsidosätter inte sätestyp, plan eller behörighet för modellen. Det gör funktionen lämplig som första kontroll: ni kan dokumentera nuläget före en eventuell ändring.

OpenAI uppger att Model Test finns för administratörer i ChatGPT Business, Enterprise, Healthcare och Edu. Den här guiden gäller Business. Vad som syns i Admin Console beror samtidigt på produkt, plan och administratörsroll. Om menyn saknas ska ni därför först kontrollera vald arbetsyta och den inloggade administratörens roll, inte dra slutsatsen att medlemmens åtkomst är fel.

Avgränsa också ärendet rätt. Model Test svarar på modellåtkomst för en medlem. Det ersätter inte en bredare pilot före utrullning av en ny AI-funktion och inte heller en granskning av vilka mejl eller filer en AI-agent får komma åt.

Samla tre uppgifter innan administratören testar

Ett ärende som bara säger ”jag ser inte den nya modellen” är svårt att återupprepa. Be medlemmen skicka tre precisa uppgifter utan att dela känsligt innehåll:

  1. Identitet: namn eller e-postadress som är kopplad till arbetsytan. Det är den uppgiften administratören söker på i Model Test.
  2. Förväntat och observerat: modellens exakta namn, var medlemmen väntade sig att se den och vad som faktiskt visades. En skärmbild av modellväljaren kan hjälpa, men maskera chattnamn och annat innehåll som inte hör till ärendet.
  3. Tid och klient: klockslag med tidszon samt om observationen gjordes på webben, i mobilappen eller i skrivbordsappen. Model Test visar sparade inställningar; klientuppgiften behövs för att skilja ett administrationsresultat från ett problem i den vy medlemmen använder.

Skriv förväntningen före provet: ”Medlemmen ska kunna använda modell X” eller ”vi vet ännu inte om modell X ska vara tillgänglig”. Den senare formuleringen är bättre än att bygga felsökningen på ett antagande. Kontrollera också att ärendet gäller rätt arbetsyta. Samma person kan arbeta i flera arbetsytor, medan testet görs mot den ChatGPT-arbetsyta administratören har valt.

Kör Model Test i fyra steg

OpenAI anger följande väg i guiden till Admin Console (öppnas i ny flik):

  1. Öppna Admin Console och välj den ChatGPT-arbetsyta som ska undersökas.
  2. Öppna Models och välj Test.
  3. Sök efter medlemmen med namn eller e-postadress.
  4. Granska effektiv modellåtkomst, arbetsytans standardval, modellbehörigheter, roller och preferenser.

Spara resultatet som text i ärendet i stället för att nöja er med ”ser rätt ut”. För varje fält skriver ni vad testet visade och vad ni hade väntat er. Exempel: ”Effektiv åtkomst: modell X saknas. Arbetsytans standard: Y. Modellbehörighet: X tillåts inte. Roll: Support. Preferens: Y.” Då går det att se vilken uppgift som faktiskt avviker.

Ändra inget under kontrollen. Om ni byter roll, sätestyp eller modellbehörighet mitt i provet försvinner det ursprungliga läget och nästa person kan inte återupprepa samma diagnos. Behöver ni senare göra en ändring, dokumentera den som ett eget steg med tidpunkt, beslutsfattare och avsett utfall.

Jämför testresultatet med användarens vy

Resultatet i Model Test speglar enligt OpenAI sparade inställningar. Det betyder att ni ska jämföra två observationer, inte blanda ihop dem:

ObservationFrågaNästa steg
Model Test nekar, medlemmen saknar modellenVilken visad inställning bidrar till den effektiva åtkomsten?Granska rätt inställningsägare innan någon ändring beställs.
Model Test tillåter, medlemmen saknar modellenGäller skärmbilden samma konto, arbetsyta, klient och tid?Gör om klientkontrollen och eskalera glappet om det består.
Model Test tillåter, medlemmen ser modellenÄr det ursprungliga felet borta eller tidsbundet?Dokumentera tidpunkterna och avsluta först när medlemmen bekräftat.
Test eller medlem kan inte hittasÄr rätt arbetsyta vald och har administratören rätt roll?Kontrollera kontext och administratörsåtkomst före modellfrågan.

Tabellen är AI på svenskas felsökningsmetod, inte ett löfte från OpenAI om orsaken i varje rad. Poängen är att hålla isär vad administrationsverktyget rapporterar och vad medlemmen observerar. Ett tillåtet resultat bevisar inte ensamt varför en viss klientvy avviker, men det gör eskaleringen betydligt mer avgränsad.

Eskalera med ett underlag som går att återupprepa

När glappet består behöver supporten ett kompakt paket. Undvik fullständiga skärmdumpar av hela Admin Console om de röjer andra medlemmar eller inställningar. Ta bara med det som behövs:

  • arbetsytans namn eller interna identifierare, men inga hemligheter,
  • berörd medlem och exakt modellnamn,
  • datum, klockslag och tidszon för både Model Test och medlemskontrollen,
  • klient och version om den är synlig,
  • effektiv åtkomst samt de arbetsytestandarder, modellbehörigheter, roller och preferenser som testet visade,
  • förväntat utfall, observerat utfall och om problemet kan upprepas,
  • bekräftelse på att inga behörigheter ändrades mellan observationerna.

Har någon redan ändrat en inställning ska även före- och efterläget finnas med. Då är ärendet inte längre ett rent nulägestest, men tidslinjen gör det fortfarande möjligt att bedöma vad som hände. Vid större incidenter kan ni använda strukturen i första timmens AI-incidentrutin för ansvar, tidslinje och bevarande av underlag.

Avsluta inte med ”behörigheten är fel”. Skriv vilken kontroll som avvek: exempelvis ”Model Test visar att modell X ingår i effektiv åtkomst, men medlemmen ser inte X på webben i arbetsyta Y klockan 10.15 CEST”. Den meningen ger nästa supportnivå ett avgränsat problem utan att ni först har förändrat det som skulle undersökas.

Kopiera: mall för modellåtkomstärendet

MODELLÅTKOMST – DIAGNOSTIK Arbetsyta: [namn eller intern identifierare] Medlem: [namn eller e-post] Förväntad modell: [exakt namn] Observerad vy: [vad medlemmen ser] Klient och version: [webb/mobil/skrivbord] Tid och tidszon: [YYYY-MM-DD HH:MM TZ] MODEL TEST Effektiv modellåtkomst: [resultat] Arbetsytans standardval: [resultat] Modellbehörigheter: [resultat] Roller: [resultat] Preferenser: [resultat] JÄMFÖRELSE Förväntat: [konkret] Observerat: [konkret] Går att upprepa: [ja/nej/inte prövat] Ändringar under provet: [inga / beskriv med tid] Nästa steg: [avsluta / granska inställningsägare / eskalera] Bilagor: [minimerade skärmbilder eller loggreferenser]

MALLEN ÄR AI PÅ SVENSKAS ARBETSSÄTT. FYLL DEN MED FAKTISKA TESTRESULTAT OCH DELA INTE MER ADMINISTRATÖRSDATA ÄN ÄRENDET KRÄVER.

Källor

KÄLLOR KONTROLLERADE: 2026-09-16

FLER ARTIKLAR

ARKIV // FÖRDJUPNING // SÖKBART