AI i praktiken - inte som strategi, utan som verktyg

Jag är nörd i grunden. Det innebär att jag inte kan nöja mig med att lära mig de fina orden.

När AI började dyka upp överallt i min vardag, på jobbet, i diskussioner, i strategidokument, fick jag samma känsla som alltid: jag behöver förstå hur det faktiskt fungerar. Inte läsa om det. Bygga med det.

Det skrivs mycket om AI just nu. Strategier, ramverk, positioneringsdokument. Betydligt mindre om hur det faktiskt ser ut när någon satt upp något och kört det ett tag. Utan agenda. Utan något att sälja.

Det här är ett försök att bidra med det. Hemlabbet är mitt laboratorium, ett ställe där jag kan experimentera, misslyckas och lära mig utan att det kostar någon organisation något. Det har lett till att jag idag har ett fungerande AI-stöd inbakat i min vardag. Inte som en chatbot jag öppnar ibland. Som en aktiv del av hur infrastrukturen fungerar.

Terrängen: vad är det egentligen jag "förvaltar"?

Innan jag beskriver hur AI används är det värt att ge en bild av vad det används på, för utan det blir resonemanget abstrakt.

Hemlabbet är ett system av servrar, virtuella maskiner och tjänster som körs hemma hos mig (och delvis på en VPS i Tyskland). Det är inte en Raspberry Pi med ett enkelt skript. Det är en miljö med ett dussintal aktiva tjänster: e-post, fillagring, fotohantering, kalender, dokumenthantering, övervakning, backup, sociala medier på egna domäner och ett antal andra saker. Allt kör på egenägd hårdvara, med egna domännamn, med redundans och backup.

Det är med andra ord ett system med många rörliga delar som förändras kontinuerligt. Tjänster uppdateras. Konfigurationer justeras. Nya saker sätts upp. Gamla saker tas ner.

Det skapar ett problem som alla som förvaltar komplex infrastruktur känner igen: dokumentationen halkar alltid efter verkligheten. Man vet hur systemet ser ut i huvudet, men det man skrivit ner för tre månader sedan stämmer inte längre. Och minnet är en opålitlig datakälla.

Det är precis där AI kommer in.

Lager 1: Claude som bollplank och dokumentationsmotor

Det vardagligaste och mest konkreta sättet jag använder AI är i samtal med Claude.

Men inte som en sökmotor. Det är en viktig distinktion.

När jag ska sätta upp något nytt, en ny tjänst, en ny integrationslösning, en ny nätverkskonfiguration, börjar jag ofta med att förklara problemet för Claude. Vad jag vill uppnå, vad jag redan har, vilka begränsningar som finns. Claude ställer motfrågor, pekar på saker jag missat, föreslår alternativa lösningar och hjälper mig tänka igenom konsekvenser innan jag börjar bygga.

Det påminner mer om att ha en teknisk kollega att bolla med än att googla efter svar.

Det andra sättet är dokumentation. Inte att Claude skriver dokumentationen för mig från ingenstans, utan att vi skapar den tillsammans, löpande, utifrån det jag faktiskt byggt. Jag beskriver vad jag gjort och varför. Claude strukturerar, kompletterar och ställer frågor om sådant som är oklart. Resultatet är dokumentation som faktiskt håller, eftersom den är förankrad i vad som verkligen gjordes.

Dokumentationen sparas lokalt i ett Obsidian-vault på mina egna servrar. Egentligen helt vanliga .md-filer som kan öppnas i vilken texteditor som helst. Inte hos någon AI-leverantör. Det är ett medvetet val som jag återkommer till.

Lager 2: Hermes, agenten som jobbar när jag sover

Det andra lagret är det som för mig är det mest intressanta: en AI-agent som arbetar autonomt.

Jag kallar den Hermes. (Agentramverket heter så, och jag har inte fantasi nog att kalla den något annat...)

Varje natt kör Hermes ett schema. Den läser igenom dokumentationen om hur systemet ska se ut, och jämför sedan med hur det faktiskt ser ut. Diskutrymme på varje maskin. Tjänster som är uppe eller nere. Konfigurationer som avvikit från det dokumenterade. Certifikat som snart löper ut.

Sedan rapporterar den till mig.

Rapporten landar som ett meddelande på morgonen. Vanligtvis är det lugnt. Men ibland dyker det upp saker: en disk som börjar bli full på en maskin jag inte ens tänkt på den senaste månaden. En tjänst som startat om fler gånger än normalt. En avvikelse mellan vad dokumentationen säger och vad som faktiskt kör.

Det är inte magi. Det är systematisk uppmärksamhet, den typ av uppmärksamhet som ett mänskligt sinne har svårt att upprätthålla konsekvent, men som ett autonomt program kan hålla dygnet runt.

Hermes är inte en produkt man köper. Det är en agent jag byggt ovanpå befintliga verktyg och modeller. Den körs på en dedikerad virtuell maskin i hemlabbet och har vaulten monterad som ett filsystem, så den kan läsa dokumentationen precis som ett program läser en fil.

En detalj som är värd att nämna: inte alla uppgifter kräver en kraftfull molnbaserad modell. Enklare kontroller, som om en tjänst är uppe eller hur mycket diskutrymme som finns kvar, kör jag mot en lokal LLM som körs direkt i min miljö via Ollama. Det är snabbare, kostar ingenting per anrop och skickar ingen data någonstans. De mer resonerande uppgifterna, som att jämföra dokumentation mot verklighet och formulera en begriplig rapport, hanteras av en starkare modell via OpenRouter. Just nu mistralai/mistral-small-4, delvis för att den fungerar tillräckligt bra och delvis i någon form av gräsrotsförsök att stötta Europeiska alternativ..

Varför det spelar roll: AI-agnostisk design

Det leder mig till något jag tror är underskattat i de flesta AI-diskussioner: vad händer om leverantören försvinner, ändrar villkoren eller plötsligt kostar dubbelt?

Jag har gjort ett aktivt val att inte låsa in mig.

Dokumentationen, systemets minne och sanningskälla, bor i en Obsidian-vault på mina egna maskiner. Den är läsbar för vilket verktyg som helst, nu och om tio år. Inget proprietärt format, ingen leverantörsberoende databas.

Hermes är kopplad till LLM-modeller via OpenRouter, en tjänst som fungerar som ett abstraktionslager ovanpå ett tiotal olika AI-leverantörer. Det innebär att om den jag för stunden använder i morgon blir otillgänglig, för dyr eller börjar leverera sämre resultat för just den här uppgiften, kan jag byta modell utan att behöva bygga om något. Det är en konfigurationsändring, inte ett arkitekturprojekt.

Principen är densamma som den som driver hela det digitala hemflyttsprojektet: kontroll och portabilitet är designval, inte eftertankar. Man bestämmer sig för det i förväg, eller så har man det inte alls.

Vad jag faktiskt har lärt mig

Jag har lärt mig att AI är bra på saker jag är dålig på, och tvärtom.

AI är bra på att hålla struktur i komplex information. Att aldrig glömma något, aldrig bli trött, alltid läsa hela dokumentet innan den svarar. Hermes missar inte diskvarningen för att den hade en dålig dag.

AI är dålig, eller åtminstone opålitlig, på att avgöra vad som faktiskt är viktigt i ett specifikt sammanhang. Hermes kan rapportera att en disk är 73 procent full. Huruvida det är ett problem just nu beror på kontext som kräver mänsklig bedömning: Vad kör på den maskinen? Vad är tillväxttakten? Har jag planerade åtgärder? Den bedömningen gör jag.

Det är en bra arbetsfördelning. Agenten flaggar. Människan bedömer och agerar.

Hade jag helt kunnat lämna över ansvaret för mitt homelab till en AI att sätta upp och strukturera? Ja, rent tekniskt hade det gått bra, men i praktiken blir svaret ett nja. Jag ser AI som ett fantastiskt bollplank men att helt lämna över kontrollen hade inneburit att jag ganska fort tappat kontrollen över centrala delar som arkitektur, redundans osv. Med nuvarande approach är jag involverad i alla viktiga beslut och samtidigt som AI tjänsterna accelererar utförandet.

Jag har också lärt mig att friktionen i att använda AI minskar dramatiskt när man slutar behandla det som ett nytt verktyg man ska lära sig och i stället integrerar det i det befintliga sättet att arbeta. Claude sitter inte i en separat app jag öppnar för att "testa AI". Den är en del av hur jag dokumenterar och designar system. Hermes är inte ett experiment. Den är en del av hur infrastrukturen vaktas.

Varför det spelar roll bortom hemlabbet

Det jag beskriver i det här inlägget är ett hemlabb. En hobbyinfrastruktur. Men principerna är desamma oavsett skala.

I mitt arbete i offentlig sektor märker jag att vi befinner oss i ett tidigt skede där många organisationer rör sig snabbt. Vi köper in verktyg, sätter ihop strategier och tar höjd för ett teknikskifte som ingen riktigt vet hur det landar. Det är rimligt. Det är så det brukar se ut när ny teknik slår igenom.

Det jag saknar i den bilden är den praktiska erfarenheten av vad som faktiskt fungerar och inte. För mig byggs den erfarenheten inte i konferensrum, utan genom att sätta upp saker, se vad som går fel och förstå varför. Jag är övertygad om att det hjälper mig att ta bättre och klokare beslut.

Det är skälet till att jag bygger. Inte för att hemlabbet i sig är ett mål, utan för att hands-on-erfarenhet är den enda genvägen för mig till faktisk förståelse. Och jag är ödmjuk inför att jag är långt ifrån en expert på området, och har stor respekt för de med både djupare och mer omfattande kunskap. Men för mig är det viktigt, för både min egen självkänsla och min trovärdighet, att se vad som finns bakom alla dessa buzzwords.

Så jag hoppas att denna text både kan ge dig som läsare lite inspiration kring vad man rent praktiskt kan göra, och även i någon utsträckning bidra till att avmystifiera AI och gå från strategier och planer till praktiska tillämpningar.