AI i driften er ikke en chatbot — det er dette
Når man nævner "AI i driften" over for en virksomhedsejer, tænker de fleste på en chatbot i hjørnet af hjemmesiden eller tekster skrevet af en robot. Det er også derfor, ordet er blevet så slidt: Det er blevet brugt om alt og intet.
Men den reelle værdi af AI i drift og udvikling ligger ikke i synlige features på siden. Den ligger i alt det usynlige rutinearbejde bagved: scanning, lapning, test, verificering, dokumentation. Netop det arbejde var tidligere grunden til, at løbende drift var dyr. Her er, hvad det konkret betyder i min hverdag, opgave for opgave.
Chatbotten er den mindst interessante del af historien
Lad os få myten på plads først. En chatbot på hjemmesiden ændrer ikke jeres risiko, jeres sikkerhed eller jeres hastighed, når noget går i stykker. Det gør derimod de processer, der kører bag siden:
- Hvornår opdager I en sårbarhed: samme dag eller ved det årlige tjek?
- Hvor lang tid går der, fra en fejl ses, til rodårsagen er fundet og rettet?
- Ved I overhovedet, om sidste udgivelse rent faktisk kom live?
Det er dér, forskellen på gammel og ny drift ligger. Og det er dér, AI har ændret regnestykket.
Konkret 1: Sårbarheder opdages samme dag, ikke ved årstjekket
De fleste SMV'er får tjekket deres platform for sårbarheder, når der er problemer, eller når en leverandør kommer forbi. Automatiserede angreb venter ikke på det. Robotterne scanner hele tiden, og forældede plugins er en velkendt indgangsdør: WordPress' egen dokumentation advarer om, at et plugin, der ikke er opdateret siden den seneste WordPress-version, kan være inkompatibelt, og at kun den seneste WordPress-version understøttes officielt. Se kilder nederst.
I min drift kører sårbarhedsscanninger ved hver eneste ændring, ikke én gang om året. Et konkret eksempel fra min egen side: da jeg scannede denne hjemmesides afhængigheder 23. september 2026, fandt værktøjet tre kendte sårbarheder, fordelt på ét billedbibliotek og to YAML-fortolkere i byggeværktøjet. De blev lappet samme dag, og en ny scanning 26. september 2026 gav nul kendte sårbarheder. Det er ikke et stort tal, men det er præcis sådan et fund, der ellers ville have ligget og ventet til næste årstjek.
Og når store opgraderinger skal laves, læses ændringsnoterne igennem først, så vi ved, hvad der går i stykker, i stedet for at opdage det i produktion. Det er det arbejde, der før krævede en dedikeret driftsafdeling. Nu kræver det én, der har sat systemet op.
Konkret 2: Fra symptom til rodårsag på minutter, ikke uger
Jeg har tidligere skrevet om en kontaktformular, der tabte henvendelser i måneder, uden at nogen opdagede det. Rodårsagen er lærerig: Afsendelsesbiblioteket returnerer fejl som en returværdi i stedet for at kaste en fejl, og koden tjekkede den ikke. Resultatet? Brugeren fik en pæn "Tak for din besked", mens henvendelsen forsvandt i det stille.
Den slags fejl er ikke farlige, fordi de er avancerede. De er farlige, fordi intet signalerer, at der er noget galt. Formularen virker, siden virker, ingen klager. Leadsene kommer bare aldrig frem.
Forskellen i min model er tempoet: Symptom opdages (gerne automatisk), rodårsag findes ved at gennemgå koden og loggene, fejlen rettes, og rettelsen verificeres, typisk samme dag. I den klassiske model er vejen: du opdager måske selv noget, sender en mail, udvikleren ser på det mellem andre projekter, der kommer et estimat, og der bookes tid senere. Det dyre er sjældent tastearbejdet. Det er ventetiden.
Konkret 3: Udgivelser verificeres på indholdet, ikke på statuskoden
Her er en fælde, selv professionelle falder i: En side kan svare med statuskode 200 og alligevel vise gammel kode i flere dage. Serveren svarer pænt, men indholdet er forældet, fordi cachen eller deploy-processen har spist ændringen.
Derfor verificerer jeg efter hver udgivelse ikke bare, at sitet svarer, men at indholdet faktisk er det nye: teksten, funktionen, rettelsen. "At det bygger" og "at det virker" er to forskellige ting, og kun det sidste tæller for din forretning.
Det lyder som en lille ting. Det er det ikke, når det næste gang handler om en kampagneside, der skulle have været live mandag morgen.
Konkret 4: Kvalitetsgate ved hver eneste ændring
Hver ændring, også småting, passerer samme gate: kodeanalyse, format-tjek og en fuld bygning af produktionsversionen. Er gaten rød, lander ændringen ikke. Punktum.
Konsekvensen er, at fejl opdages før, de når ud til kunderne, og at hver ændring kan rulles tilbage præcist, hvis noget alligevel snubler. Sammenlign med den klassiske situation: "Vi opdaterede lidt her og lidt der, og nu ved ingen, hvad der gik i stykker."
Gaten tager tid. Det er den ærlige regning. Det er ikke gratis, og det er heller ikke pointen. Pointen er, at den er deterministisk: samme tjek hver gang i stedet for en vurdering, der afhænger af, hvor travlt der er. Og at det koster dage og tillid at komme tilbage fra en ødelagt produktion.
Konkret 5: Det kedelige arbejde bliver faktisk lavet
Intern linkning mellem sider. Metadata, der matcher indholdet. Hastighedstjek. Dokumentation af, hvordan tingene hænger sammen. Det er alt sammen opgaver, der ikke giver nogen synlig belønning, og som derfor aldrig bliver gjort, når regningen skal kunne forklares time for time.
Men det er netop dét arbejde, der over tid adskiller et website, der trives, fra et, der langsomt rådner op indefra. Med AI i processen er prisen på det kedelige faldet så meget, at det er blevet en naturlig del af hverdagen i stedet for noget, man "kommer til, når der er tid".
Hvad AI ikke kan, og hvorfor det er vigtigt
For fuldstændighedens skyld: AI kan ikke tage beslutninger på dine vegne, sige nej til dårlige idéer, kende din forretnings historik eller bære ansvaret, når noget skal prioriteres væk. Dømmekraften, altså hvad der er vigtigt for lige netop din virksomhed, sidder stadig hos mennesket.
Pointen er ikke, at AI erstatter en teknisk partner. Pointen er, at AI gør udførelsen billig nok til, at ét menneskes dømmekraft kan dække hele stakken i stedet for at blive spredt tyndt ud over et bureau med koordinering, møder og minimumsopgaver imellem. Det er en erfaring, ikke et gennemsnitstal: jeg kan ikke dokumentere et generelt timetal, fordi udgangspunktet varierer for meget med jeres setup.
Regnestykket
Den klassiske model: en projektleder koordinerer mellem frontend-udvikler, backend-udvikler, DevOps og sikkerhedsguru. Hver opgave har en minimumsstørrelse, og kommunikationen imellem dem er med på fakturaen.
Min model: én kontaktperson med fuldt overblik, hvor AI klarer det rutineprægede (scanninger, test, fejlfinding, verificering), og mennesket bruger sin tid på det, der kræver dømmekraft. Det er samme dækning, og forskellen ligger i, at der ikke er en koordinationspost mellem hver eneste opgave.
Konkrete priser fra min egen prisstruktur. De er offentlige, så du kan regne på dem:
- Light (vedligeholdelse): 5.000 kr./md. Det basale holdes kørende: opdateringer, backups, overvågning.
- Drift+: 10.000 kr./md. Mere omfang, kvartalsrapport, løbende forbedringer.
- Teknisk partner: 15.000 kr./md. CTO-arbejdet er med: strategi, arkitektur, prioritering, hele stakken.
Hele arkitekturen, fra Micro til Totalløsning, står på pris- og pakkesiden.
Én teknisk ejer, når opgaverne er spredt overalt
Teknisk partner fra 15.000 kr/md: prioritering, arkitektur og hele stakken hos én person, så du ikke koordinerer mellem fire leverandører.
Kilder
De konkrete påstande om WordPress-sikkerhed i denne artikel er hentet fra WordPress' egen dokumentation og kontrolleret 26. september 2026:
- Manage Plugins — kompatibilitet, når et plugin ikke er opdateret siden seneste WordPress-version; tag backup før opdatering; slet ubrugte plugins
- WordPress Security — kun den seneste WordPress-version understøttes officielt; rettelser til ældre versioner leveres som en service
Sikkerhedstalet i artiklen kommer fra min egen afhængighedsscanning af denne side den 23. og 26. september 2026, ikke fra en kundecase. Priserne er Mahopes egne, offentlige priser: Light 5.000, Drift+ 10.000 og Teknisk partner 15.000 kr./md, med hele arkitekturen på pris- og pakkesiden.
