ChatGPT Work får Data-plugin – fem frågor innan ni kopplar verksamhetsdata

Vad Data-pluginet gör – och inte avgör åt er

I produktinlägget om Data (öppnas i ny flik) beskriver OpenAI en Data agent i ChatGPT Work. Den kan ansluta till godkända datakällor, använda verksamhetens måttdefinitioner och andra affärssammanhang, undersöka vad som har förändrats och skapa dashboards som går att redigera, dela och uppdatera. Bland exemplen på källor finns BigQuery, Databricks, Snowflake, Google Drive och SharePoint. Det är exempel, inte en fullständig lista.

I versionsanteckningen den 10 september (öppnas i ny flik) heter nyheten "Data plugin in ChatGPT Work and Codex". Administratörer kan styra installationspolicyn och aktivera de datakälleplugin och appar som teamet behöver. När Data finns i arbetsytan kan medlemmen starta med @Data. Därifrån kommer artikelns benämning Data-plugin; OpenAI använder alltså både Data agent och Data plugin i de två källorna.

Den viktiga behörighetsuppgiften är precis: administratörer väljer vilka dataanslutningar som är tillgängliga och vilka roller som får använda dem. Frågor följer det anslutna kontots befintliga begränsningar på tabell-, rad- och kolumnnivå, och arbetsytans åtkomstkontroller gäller. Men "befintliga" betyder inte automatiskt "rätt". Om ett konto redan ser för många rader kan ett korrekt genomfört pluginanrop fortfarande ge ett för brett svar. På samma sätt kan en tekniskt korrekt summering bli verksamhetsmässigt fel om två team menar olika saker med samma mått.

Det är därför ni bör behandla installationen som ett införandebeslut, inte som en genväg förbi datastyrningen. Har ni ännu inte gjort den bredare inventeringen av användare, risker och ansvar, börja med checklistan innan ni inför AI i teamet. Om frågan i stället är vilket grundverktyg arbetsplatsen ska välja ägs den jämförelsen av ChatGPT kontra Microsoft 365 Copilot för jobbet.

Fem frågor som ska vara ifyllda före anslutningen

Fyll i ett kort per datakälla och pilotfråga. Ett svar som bara säger "IT ansvarar" eller "samma som i BI" är inte färdigt; skriv ett systemnamn, en roll, ett mått eller en kontroll som går att prova.

1. Vilken datakälla kopplas in? Skriv källa, miljö och avgränsning: exempelvis "försäljningslagret i testmiljö, ordertabellen för Sverige, de senaste 30 dagarna". Notera om Data också ska få använda dokument eller en semantisk modell. En källa per första prov gör ett fel lättare att lokalisera.
2. Vilka behörigheter ska de två testkontona ha? Konto A får se den valda datamängden. Konto B ska avsiktligt sakna en tabell, en region eller en känslig kolumn. Skriv det förväntade utfallet i förväg: vad ska A kunna se, och vad ska B nekas eller få bortfiltrerat? Testet mäter då samma sak som frågan beställer.
3. Vilken måttdefinition gäller? Skriv täljare, nämnare, tidsperiod, valuta eller enhet och viktiga undantag. "Aktiv kund" behöver till exempel ett tidsfönster och en händelse som räknas. Peka på samma semantiska lager, dashboard eller dokument som den befintliga rapporten använder.
4. Hur kontrolleras resultatet? Namnge rapporten, rapportägaren, filterläget och ett accepterat avvikelsemått. Jämför minst totalsiffra, uppdelning och tidsperiod. OpenAI skriver att användaren kan granska underlaget bakom resultaten; vårt kontrollförslag lägger dessutom till en fristående jämförelse mot en redan betrodd rapport.
5. Vem ansvarar för beslut och fel? Ange en dataägare som godkänner källan och måttet, en systemägare som kan ändra eller stänga anslutningen samt en pilotansvarig som dokumenterar utfallet. Bestäm också vem som pausar piloten om konto B ser sådant det inte ska se eller om rapportjämförelsen faller.

Kortet ska sluta med ett val: redo för avgränsat prov, behöver kompletteras eller anslut inte. Den sista statusen är rimlig när datakällan saknar ägare, behörigheterna inte går att särskilja eller det inte finns någon rapport eller annan facitliknande kontroll att jämföra mot.

Välj en låg-riskfråga med ett känt svar

Första frågan ska vara användbar men odramatisk. Undvik personärenden, lön, rekrytering, juridiska bedömningar och kundlöften. Välj hellre en aggregerad historisk fråga där ni redan känner svaret, till exempel: "Hur många avslutade supportärenden hade produkt A per vecka under de senaste fyra hela veckorna? Visa antal och förändring i procent från föregående vecka."

Den frågan har fyra egenskaper som hjälper kontrollen: ett tydligt objekt, en tidsperiod, en enhet och en jämförelse. Lägg till den fastställda definitionen av "avslutat ärende" och exkluderingar, men ändra inte definitionen mellan Data och den befintliga rapporten. Om rapporten använder stängningsdatum medan prompten använder skapandedatum testar ni två olika mått och kan inte tolka skillnaden.

Skriv också förväntan före körningen. Exempel: konto A ska få fyra veckotal för alla svenska team; konto B ska bara få sitt eget team och får inte visa kundnamn. Den förhandsnoteringen hindrar att ni i efterhand förklarar varje oväntat svar som acceptabelt.

Provet: två konton, samma fråga, en betrodd rapport

Det här är AI på svenskas kontrollupplägg, inte en funktion som OpenAI lovar. Använd syntetiska data eller en godkänd låg-riskmängd och dokumentera fem observationer.

1. Lås underlaget. Notera datum, datakälla, anslutning, måttdefinition, rapportversion och de två kontonas roller. Ändra inget mellan körningarna.
2. Kör konto A. Ställ den valda frågan med @Data. Spara svaret, de visade källorna eller underlagen och dashboardens filter. Ställ en följdfråga om varför den största förändringen uppstod.
3. Kör konto B. Använd exakt samma fråga. Kontrollera att den avsiktligt spärrade tabellen, regionen eller kolumnen inte blir synlig i svar, underlag, filter, export eller följdfråga. Ett annorlunda totalsvar kan vara korrekt om B har snävare radåtkomst; det ska då motsvara er förhandsnotering.
4. Jämför mot rapporten. Använd samma tidsperiod, statusfilter, valuta och avrundning. Kontrollera totalsiffra, minst en delsumma och en enskild period. Vid avvikelse: avgör först om orsaken är datans uppdateringstid, filter eller måttdefinition innan ni bedömer själva analysen.
5. Ta pilotbeslutet. Gå vidare bara om B:s begränsning höll, måttet tolkades enligt kortet och avvikelsen låg inom er förutbestämda gräns. Annars pausar pilotansvarig och lämnar frågan till data- eller systemägaren.

Gör inte ett lyckat konto A-test till bevis för att behörigheterna fungerar. Det avgörande provet är att konto B inte kan få fram den avgränsade informationen, inte ens genom följdfrågor eller en ny dashboard. Behöver ni en bredare modell för agentåtkomst finns den i guiden om AI-agenters behörigheter till mejl och filer.

Beslutsrutan efter provet

• Gå vidare med en liten pilot när källa och mått har namngivna ägare, de två kontona ger förväntat olika åtkomst och svaret kan stämmas av mot rapporten inom er beslutade gräns.
• Komplettera och kör om när skillnaden går att spåra till filter, uppdateringstid eller en oklar måttdefinition. Ändra kortet först och upprepa sedan båda kontona.
• Anslut inte ännu när konto B ser förbjuden data, när ingen kan godkänna måttet eller när resultatet inte går att jämföra mot ett oberoende underlag.

En dashboard som ser övertygande ut är alltså inte slutpunkten. Slutpunkten för det första provet är ett dokumenterat beslut där datakälla, åtkomst, mått, kontroll och ansvar går att följa tillbaka till fem ifyllda svar.

Källor

• OpenAI: Now everyone can put data to work (10 september 2026) (öppnas i ny flik) – Data agent, datakällor, verksamhetskontext, adminstyrning, befintliga behörigheter, granskning och dashboards.
• OpenAI Help Center: ChatGPT Business release notes, Data plugin in ChatGPT Work and Codex (10 september 2026) (öppnas i ny flik) – installation, datakälleplugin, åtkomstkontroller och start med @Data.

KÄLLOR KONTROLLERADE: 2026-09-15