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 fra en fejl ses, til rodårsagen er fundet og fikset?
- 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 en kendt sårbarhed i et forældet plugin er den hyppigste indgangsdør.
I min drift kører sårbarhedsscanninger ved hver eneste ændring, ikke én gang om året. Et konkret eksempel fra min egen side: En rutinemæssig scanning fandt for nylig to alvorlige sårbarheder i afhængighederne. De blev laplet samme dag — længe før nogen kunne udnytte dem, og længe før de ville være dukket op ved et manuelt tjek.
Og når store opgraderinger skal gøres, læses ændringsnoterne igennem først, så vi ved, hvad der bryder — 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: Afsendelses-biblioteket 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 sjove, fordi de er avancerede. De er farlige, fordi intet signalerer, at der er noget galt. Formularen virker, siden virker, ingen klager — leadsene bare kommer aldrig frem.
Forskellen i min model er tempoet: Symptom opdages (gerne automatisk), rodårsag findes ved at gennemgå koden og loggene, fejlen rettes, og retningen verificeres — typisk samme dag. I traditionel model er vejen: du opdager måske selv noget, sender en mail, udvikleren ser på det mellem andre projekter, der kommer et estimat, og tre uger senere er der booket tid. Det dyre er sjældent tastearbejdet. Det er ventetiden.
Konkret 3: Udgivelser verificeres i indholdet — ikke i 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 — cache 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, retningen. "At det bygger" og "at det virker" er to forskellige ting, og kun den sidste tæller for din forretning.
Det lyder som en lille ting. Det er det ikke, når 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 koster få minutter pr. ændring. Tilbagevenden fra en ødelagt produktion koster dage og tillid.
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, ingen synlig belønning følger med — 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 sideværk, 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 — hvad der er vigtigt for lige din virksomhed — sidder stadig hos mennesket.
Pointen er ikke, at AI erstatter en teknisk partner. Pointen er, at AI gør udførelsen så billig, at én persons dømmekraft kan dække hele stakken — i stedet for at blive fortyndet ud over et bureau med koordinering, møder og minimumsopgaver imellem.
Regnestykket
Traditionel model: En projektleder koordinerer mellem frontend-udvikler, backend-udvikler, DevOps og sikkerhedsguru. Hver håndtering 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. Resultatet er samme dækning til markant færre timer, og en afstand fra problem til løsning, der måles i timer frem for uger.
Konkret i priserne:
- Drift Light (vedligeholdelse): 5.000 kr./md — basalen 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 med: strategi, arkitektur, prioritering, hele stakken.
Vil du se, hvad det ville betyde for jeres setup?
Kig på vedligeholdelsespakkerne, hvis kernen er drift og tryghed — eller teknisk partner-modellen, hvis I vil have én person, der ejer det tekniske hele vejen. Skriv to linjer, så siger jeg ærligt, hvilket niveau jeres situation kalder på.
