Vad DevDay betyder
OpenAI DevDay 2025 kommer sannolikt att bli ihågkommet mindre för en enskild ”wow”-funktion och mer för ett mönster: modeller som blir mer kapabla i arbete med flera steg, verktyg som blir enklare att integrera i vardagliga arbetsflöden och säkerhetskontroller som blir mer konfigurerbara. För skolor är möjligheten inte ”AI i varje klassrum till fredag”. Det är ett disciplinerat arbetssätt för att avgöra vad som är användbart, vad som är riskfyllt och vad som bara är brus.
Det mest användbara sättet att läsa DevDay är genom tre linser: förmåga, kontroll och kostnad. Förmåga spelar roll eftersom den förändrar vilka uppgifter AI kan göra tillförlitligt (till exempel att utforma en sammanhängande lektionsserie utifrån en planeringsöversikt). Kontroll spelar roll eftersom den påverkar er möjlighet att hålla personalen inom säkra ramar (till exempel att förhindra användning av elevdata eller att kräva transparensmeddelanden). Kostnad spelar roll eftersom piloter som ser billiga ut i liten skala kan bli dyra när de används brett, särskilt om personal börjar använda AI för uppgifter med hög volym.
Vad ska man ignorera? Allt som ramas in som ”ersätt undervisning”, allt som kräver elevkonton som utgångspunkt och allt som förutsätter att du kan ladda upp känsliga dokument för att ”göra det smartare”. Om du behöver ett snabbt och lugnt sätt att informera kollegor kan du låna strukturen från vår skolbriefing på GPT-5-lanseringsdagen och protokoll för snabb utvärdering och helt enkelt byta ut DevDays största förändringar.
Måndagens triagefrågor
Till måndag morgon vill du ha en snabb sorteringsmekanism: inför, pilota eller parkera. Använd sex frågor i ett 20-minuters SLT/IT-möte, och håll sedan fast vid utfallet i en vecka.
För det första: vilket problem löser vi — arbetsbelastning, kvalitet, likvärdighet eller hastighet? Om det enda svaret är ”för att det är nytt”, parkera det. För det andra: kan vi testa det utan elevdata? Om inte, parkera det tills ni har en starkare styrningsplan. För det tredje: förändrar det en högriskprocess (bedömningsbeslut, skydd/trygghet, SEND-dokumentation)? Om ja, pilota endast med strikta begränsningar och mänsklig granskning.
För det fjärde: vilken minsta evidens behöver vi för att besluta? Kom överens om detta i förväg, annars glider veckan över i anekdoter. För det femte: hur ser ”tillräckligt bra” ut i vår kontext — färre mejl, snabbare planering, tydligare kommunikation till vårdnadshavare, färre fel? För det sjätte: vad är felmoden — hallucinerade fakta, tonproblem, partiska utdata, att personal blir för beroende eller oavsiktlig datadelning? Om du inte kan namnge felmoden är du inte redo att köra piloten.
Om ni redan har gjort liknande triage för andra leverantörer kan ni samordna språk och trösklar med vår WWDC-utbildningsbriefing om AI: vad skolor bör göra nästa vecka, så att personalen ser ett konsekvent angreppssätt över olika verktyg.
En sprint på en vecka
Målet med sprinten är inte att ”implementera AI”. Det är att samla tillräckligt med lokal evidens för att fatta ett försvarbart beslut, utan att röra elevdata. Håll teamet litet: en SLT-sponsor, en IT-/dataskyddsansvarig och två till fyra volontärer från olika roller (en klasslärare, en pastoralansvarig och en administrativ kollega är en stark mix). Sätt en enda regel: inga personuppgifter, inget elevarbete och inga skärmbilder från skarpa system.
Förberedelser
På måndag skapar ni en delad mapp med tre mallar: en uppgiftslogg, ett evidensblad och ett riskregister. Bestäm vilken AI-miljö personalen ska använda och lås standardinställningar: ingen delning av chatthistorik, inga plug-ins eller externa kopplingar och ingen uppladdning av dokument utöver syntetiska exempel som ni själva skapar. Om du är osäker på hur ”bra standardinställningar” ser ut kan du synka med er årscykel via vår checklista för uppdatering av AI-policy för acceptabel användning 2025–26.
Kom också överens om en basnivå för ”prompt-hygien”. Till exempel: ”Använd anonymiserade platshållare (Elev A), ta bort identifierare och behandla AI-utdata som ett utkast.” Det handlar inte om att vara petig; det handlar om att säkerställa att er evidens inte förorenas av osäkra arbetssätt.
Testuppgifter
Välj uppgifter som representerar verkligt arbete men som kan simuleras. En ämnesansvarig kan klistra in en generell ämneslista och be om en lektionsserie med återkallningsövningar. En mentor kan skriva ett meddelande till vårdnadshavare om närvaro utifrån ett fiktivt scenario. En skoladministrativ chef kan be om en mötesagenda och en mall för protokoll.
Håll varje uppgift kort och repeterbar. Du vill jämföra utdata mellan medarbetare, inte skapa ett perfekt artefakt. Om ni vill mäta påverkan på arbetsbelastning, tidsbegränsa varje uppgift till tio minuter och registrera före- och eftertid, plus antalet redigeringar som krävs.
Insamling av evidens
Evidens ska vara enkel och konsekvent. För varje uppgift, fånga: prompten, utdatat, redigeringstiden och en kvalitetsbedömning mot en rubric som ni definierar (korrekthet, ton, användbarhet och risk). Lägg till en ja/nej-fråga: ”Skulle du använda detta i morgon?”, eftersom den ofta avslöjar mer än en 1–5-poängskala.
Sätt stop/go-trösklar i förväg. Ett praktiskt exempel: om mer än var femte utdata innehåller faktafel som en stressad kollega kan missa, är det arbetsflödet ”parkera” tills det finns motåtgärder. Om den genomsnittliga redigeringstiden inte är minst 20% lägre än nuvarande arbetssätt är det ”endast pilota” snarare än ”inför”. Om någon uppgift frestar personal att använda elevdata för att få det att fungera, misslyckas den med sprinten per design.
För ett strukturerat sätt att besluta behåll/stoppa/skala kan du spegla vårt evidenspaket för AI-revision vid läsårets slut, även om du kör detta i september.
Tre säkra piloter
Dessa piloter är utformade för att kunna köras nästa vecka utan elevdata. De är inte ”AI i lektioner”; de är personalinriktade arbetsflöden som minskar friktion och skapar konsekventa utdata.
Pilot för planering
Kör en pilot med en ”planeringsco-pilot” för en ämnesgrupp eller ett årskursteam. Personal anger en ämnestitel, lärandemål och begränsningar (tid, resurser, missuppfattningar). AI tar fram ett utkast till lektionsupplägg, återkallningsfrågor och en kort hinge question. Läraren redigerar sedan och undervisar som vanligt.
Er go-tröskel är enkel: personalen rapporterar minst en planeringskomponent de skulle återanvända, och den redigerade planen stämmer med er läroplansintention. Er stop-tröskel är lika tydlig: AI introducerar missuppfattningar, olämpliga exempel eller innehållsmisspassning som tar längre tid att rätta än att skriva från grunden. Om du vill ha en arbetsbelastningsfokuserad inramning som personalen känner igen, koppla piloten till uppgiftsgränserna i vår AI-uppgiftskarta för lärarnas arbetsbelastningskris.
Pilot för förberedelse av återkoppling
Det här är inte automatiserad rättning. Det är att förbereda återkopplingsmaterial som lärarna kontrollerar. Använd anonymiserade, syntetiska exempel (eller lärarskapade ”typiska svar”) och be AI att ta fram bedömningskriterier, vanliga missuppfattningar och en bank av återkopplingskommentarer kopplade till dessa missuppfattningar. Lärarna väljer sedan, redigerar och ger återkoppling på sitt vanliga sätt.
Go om banken förbättrar likvärdigheten i ett team och minskar tiden för att komma igång från ”tom sida”. Stop om kommentarer blir generiska, alltför dömande eller för långa för att vara användbara i praktiken. En användbar skyddsregel är att kräva att varje kommentar innehåller ett ”nästa steg” och att undvika att hänvisa till någon specifik elev.
Pilot för administrativ kommunikation
Välj en typ av kommunikation med hög volym: påminnelser om utflykter, påminnelser om ordningsregler, information om klädpolicy eller schemaändringar. Ange en husstil (ton, läsnivå, längd) och be AI att skriva meddelanden på enkel engelska, plus en kortare SMS-liknande version.
Go om meddelanden behöver färre revideringar och minskar frågor fram och tillbaka. Stop om tonen blir kort, juridisk eller inkonsekvent med skolans värderingar. Den här piloten ger ofta snabba vinster eftersom den är mätbar: färre redigeringar, färre följdmejl och färre klagomål på otydlighet.
Upptäck kraften i Automatiserad Utbildning genom att gå med i vårt community av lärare som tar tillbaka sin tid samtidigt som de berikar sina klassrum. Med vår intuitiva plattform kan du automatisera administrativa uppgifter, personifiera elevinlärning, och engagera dig med din klass som aldrig förr.
Låt inte administrativa uppgifter överskugga din passion för att undervisa. Registrera dig idag och förvandla din utbildningsmiljö med Automatiserad Utbildning.
🎓 Registrera dig GRATIS!
Policy och styrning
DevDay-till-måndag fungerar bara om ni skärper styrningen i samma takt som experimenterandet. Ni behöver ingen total omskrivning; ni behöver ett kort tillägg som klargör vad som är tillåtet under sprinten och vad som inte är det. Håll det till en sida: tillåtna användningar (utkast, sammanfatta, omformulera), förbjudna användningar (elevdata, skydds-/trygghetsdetaljer, bedömningsbeslut) och obligatorisk praxis (mänsklig granskning, transparens och loggning).
För dataskyddsstandarder: börja med ”ingen elevdata” som baslinje och definiera sedan vad som måste vara sant för att gå bortom den: ett undertecknat avtal, tydliga villkor för personuppgiftsbehandling, kontroller för lagringstid och personalutbildning. För upphandlingsfrågor: be leverantörer ange var data behandlas, om prompts används för träning, vilka admin-kontroller som finns och hur granskningsloggar kan nås. Om du kopplar detta till samtal om läroplan och regelefterlevnad kan implementeringspaketet för nationella läroplanen och AI hjälpa dig att hålla språket konsekvent mellan dokument.
Klassrumsgränser
Även när era piloter är personalinriktade kommer elever att höra om dem. Konsekvens spelar roll. Förbered ett kort ”integritetsskript” som personal kan använda när elever frågar: ”Skrev AI det här?” En enkel, sanningsenlig formulering fungerar: ”AI hjälpte mig att skriva ett första utkast, och jag kontrollerade och förbättrade det. Du behöver fortfarande visa ditt eget tänkande.”
Transparens ska inte bli en uppvisning. Målet är att normalisera ansvarsfull användning utan att glamorisera genvägar. Kom överens om en gemensam gräns för personalen: AI kan stödja lärarförberedelser och kommunikation, men elevers arbete måste förbli elevers arbete om inte en specifik, övervakad aktivitet planeras och kommuniceras.
Personalkonsekvens är ofta den dolda risken. Om en lärare förbjuder all AI-omnämning och en annan uppmuntrar det utan skyddsregler får eleverna blandade budskap. En kort INSET-mikrorutin kan hjälpa: ett gemensamt manus, en gemensam uppsättning dos and don’ts och en gemensam eskaleringsväg när något känns fel. Vår AI-workshop för INSET-dag: tre mikrorutiner ger en struktur du kan lyfta rakt av.
Checklista och mallar
Er IT/SLT-checklista ska få plats på en sida: bekräfta säkra inställningar, bekräfta regeln ”ingen elevdata”, utse pilotansvariga, sätt evidenströsklar och schemalägg en 30-minuters fredagsavstämning. Fredagsmötet ska avslutas med ett av tre beslut för varje pilot: stoppa, fortsätt eller skala till ett andra team.
För personalkommunikation: skicka en kort notis som ramar in sprinten som utvärdering, inte utrullning. Inkludera de tre tillåtna piloterna, tidslinjen på en vecka och regeln att AI-utdata alltid är ett utkast. För vårdnadshavare fungerar ett kort meddelande bäst: ni testar verktyg för att minska personalens arbetsbelastning och förbättra tydligheten i kommunikationen; ingen elevdata används; och lärare är fortsatt ansvariga för alla beslut och allt material.
Om du vill ha en sista hållpunkt för veckan: avsluta fredagen med att uppdatera ert AUP-tillägg och logga er beslutskedja. Den dokumentationen är det som förvandlar ”vi testade det” till ”vi utvärderade det ansvarsfullt”.
Må er DevDay-entusiasm bli lugna, evidensledda beslut till fredag.
The Automated Education Team