← Tillbaka till Aktuellt

Hur LLM-integration förändrar nordiska företags arbetsflöden

Under det senaste året har vi sett en tydlig förändring hos nordiska organisationer: LLMs har gått från att vara ett experiment i en sandlåda till att faktiskt driva affärskritiska flöden. Kundtjänst, juridisk granskning, teknisk dokumentation, komponentklassificering — verkliga processer som tidigare krävde välutbildad personal körs nu delvis av modeller som GPT-4 eller interna finjusterade varianter.

Det som separerar de organisationer som lyckas från dem som fastnar är inte tekniken i sig — det är integrationskvaliteten. En LLM som svarar bra på fristående frågor presterar ofta dåligt när den kopplas mot levande system med inkonsekventa dataformat, trasiga API-svar och affärslogik byggd på tio år av workarounds. Prompt engineering löser en del, men den verkliga utmaningen är systemdesign.

Vi har sett tre mönster fungera konsekvent: tydliga kontraktsgränser mot bakendtjänster (LLM:en ska aldrig direkt skriva till databaser), mänskliga kontrollpunkter för låg-tillit beslut, och ett dedikerat observability-lager som loggar varje anrop och utfall. Utan det sista är det omöjligt att debugga när något går fel i produktion.

Den goda nyheten: en välintegrerad LLM kan reducera handläggningstid med 40–70% på strukturerade processer. Den dåliga: de flesta organisationer underskattar integrationskomplexiteten med en faktor tre. Om ni planerar att ta en LLM-lösning till produktion under 2026 — prata med oss innan ni börjar.

← Tillbaka till Aktuellt

Från proof-of-concept till produktion: Vanliga fallgropar i AI-projekt

Så gott som alla AI-projekt börjar lovande. En demo som imponerar på ledningsgruppen, en PoC som levererar exakta svar på testdata, en entusiastisk intern champion som driver frågan uppåt. Sedan händer något på vägen mot produktion — projektet stagnerar, kostnaderna skenar, eller lösningen levereras men används aldrig.

Den vanligaste fallgropen är data. PoC:er byggs på kurerat, rent testdata. Produktionsmiljöer har legacy-format, saknade fält, dubbletter och undantag som ingen dokumenterade. När modellen träffar verklig data faller precision ihop. En riktig dataanalys tidigt i projektet — inte som efterhandskontroll — är inte valfri.

Den näst vanligaste fallgropen är infrastruktur. En ML-modell som svarar på 200ms i ett Jupyter notebook kan svara på 4000ms i produktion om man inte designat för latens, batching och caching från start. Infrastruktur är inte en efterhandsdetalj i AI-projekt.

Den tredje fallgropen är kompetensöverföring. Projektet levereras av externa konsulter eller ett dedikerat internt team — och sen lämnas över till en driftsorganisation som aldrig förstod modellen. Utan ägare som kan vidareutveckla och felsöka är lösningen dömd att bli en skuld. Planera för ägarskap från dag ett, inte vid leverans.

← Tillbaka till Aktuellt

GDPR och AI: Vad ni måste tänka på innan ni lanserar era AI-tjänster

GDPR och AI är en kombination som fortfarande skapar huvudvärk hos de flesta dataskyddsombud. Den grundläggande utmaningen: AI-system bygger på att lära sig mönster från data, ofta persondata — och GDPR ställer strikta krav på ändamålsbegränsning, lagringsminimering och transparens som är svåra att förena med hur moderna ML-modeller faktiskt fungerar.

Det viktigaste att förstå är principen om ändamålsbegränsning. Om ni samlar in kunddata för att leverera en tjänst kan ni inte utan vidare använda samma data för att träna en modell, även om ni tänkt er att modellen ska förbättra just den tjänsten. Syftet med insamlingen måste vara tydligt formulerat i integritetspolicyn, och användningen av data för ML-träning kräver ofta en ny rättslig grund.

Transparens är en annan utmaning. GDPR ger individer rätt att få förklaringar till automatiserade beslut som påverkar dem. En black-box-modell som fattar kreditbeslut, medicinska rekommendationer eller personalurval uppfyller troligtvis inte detta krav utan ett förklaringslager ovanpå.

Vår rekommendation: genomför en Data Protection Impact Assessment (DPIA) tidigt i projektet — inte som dokumentationsövning utan som ett genuint designverktyg. De flesta compliance-problem vi ser hade kunnat undvikas med en halvdags workshop med rätt personer i rummet.

← Tillbaka till Aktuellt

ISO 27001 och AI-säkerhet: Vad standarden inte täcker

ISO 27001 är idag närmast obligatorisk för nordiska tech-bolag som säljer till enterprise-kunder. Standarden täcker informationssäkerhet brett: åtkomstkontroll, riskhantering, incident response, fysisk säkerhet. Men den designades i en era innan AI var en produktionskritisk komponent i de flesta system — och det syns.

En av de största luckorna är supply chain-risker kopplade till ML-modeller. Ni certifierar era egna processer, men vad vet ni om säkerhetsegenskaperna hos den foundation model ni bygger på? En modell tränad på poisonad data kan producera systematiskt felaktiga eller manipulerade utfall — ett hot som ISO 27001 inte explicit adresserar.

En annan lucka är adversarial attacks. En välutbildad angripare kan via specifikt konstruerad input manipulera en AI-modells beteende på sätt som inte liknar traditionella cyberhot. Prompt injection mot LLM-baserade system är ett aktuellt exempel — och det finns ännu ingen vedertagen kontroll i 27001-ramverket för det.

Vår rekommendation: komplettera er 27001-implementation med explicita kontroller för AI-specifika hot. Det handlar om modellproveniens (vet ni vad modellen tränades på?), input/output-validering, och regelbunden adversarial testning. Vi hjälper er att bygga det lagret utan att röra er befintliga certifieringsstruktur.

← Tillbaka till Aktuellt

Build Your Own Team: Hur vi sätter ihop ett dedikerat team på 5–7 dagar

Traditionell rekrytering för ingenjörsroller i Norden tar i snitt 3–5 månader. Att skriva kravprofil, annonsera, screena, intervjua, referenstaka och onboarda är en process som dränerar tid från både HR och den tekniska ledningen. Under den tiden hinner projektet halka efter, befintliga ingenjörer ta på sig för mycket, eller — värst av allt — ni tar in fel person av tidsbrist.

Vår Build Your Own Team-modell fungerar annorlunda. Vi har ett nätverk av vetted ingenjörer i Sverige, Sri Lanka och Bulgarien med verifierad erfarenhet inom specifika teknologidomäner. När ni kommer till oss med ett behov — säg, tre backend-ingenjörer med Go-erfarenhet och förståelse för finansiella system — börjar vi matcha mot det nätverket direkt, inte mot en inkommande ansökningsström.

Inom 5–7 dagar har vi presenterat kandidater ni faktiskt vill träffa. Inte femton CV:n att sortera igenom — tre till fem noggrant utvalda profiler med relevant bakgrund. Onboarding sker i ert befintliga system: era verktyg, era processer, er kod. Teamet är operativt inom två veckor.

Det som gör modellen hållbar på sikt är att vi inte levererar konsulter som försvinner när projektet är slut. Vi bygger team som kan växa med er organisation, med tydliga eskalationsvägar och kvalitetssäkring från vår sida under hela engagemanget.

← Tillbaka till Aktuellt

Infrastruktur för AI: Vad ni behöver ha på plats innan ni skalerar

De flesta AI-projekt startar på en laptop eller i en Jupyter notebook i en molnmiljö. Det är ett utmärkt sätt att utforska och validera idéer. Problemet uppstår när lösningen ska ut i produktion och man inser att notebook-arkitekturen inte håller under last, inte är övervakbar och inte kan skalas utan att kostnaderna exploderar.

Den första frågan att besvara är compute-strategi. GPU-accelererat compute är dyrt men nödvändigt för många inference-arbetsbelastningar — men inte alla. En del modeller körs utmärkt på CPU med rätt optimering (kvantisering, ONNX-runtime). Att betala för GPU-instanser dygnet runt för ett system som har traffic spikes ett par gånger om dagen är vanlig kostnadsslöseri vi ser hos kunder.

Observability är det område som oftast nedprioriteras. I traditionell mjukvara loggar ni API-anrop och fel. I AI-system behöver ni dessutom logga modell-inputs, outputs och konfidenspoäng — dels för felsökning, dels för att kunna detektera distribution shift när världens data förändras och er modell börjar prestera sämre utan att krascha.

Slutligen: planera för modellversionshantering från dag ett. Ni kommer att vilja rulla ut nya versioner utan driftstopp, kunna gå tillbaka till föregående version om något är fel, och A/B-testa varianter mot varandra. Det kräver infrastruktur — och det är mycket enklare att bygga rätt från start än att retrofita i efterhand.

← Tillbaka till Aktuellt

Varför traditionell IT-upphandling inte funkar för AI-transformation

Svensk offentlig sektor och många stora enterprise-bolag köper IT genom ramavtal och upphandlingsprocesser designade för att köpa licenser och drifttjänster. Processen är tung men rättvis: kravspecifikation, annonsering, anbudsperiod, utvärdering, kontrakt. För stabil infrastruktur och standardiserade system fungerar det.

AI-transformation fungerar inte så. Skälet är fundamentalt: AI-projekt är iterativa och kräver ett tätt samarbete mellan beställare och leverantör under hela processen. Kravspecifikationen kan inte skrivas i förväg eftersom ni inte vet exakt vad ni behöver förrän ni börjat — och det ni trodde ni behövde i månad ett är ofta inte vad ni faktiskt bygger i månad sex.

Den upphandlingsprocess som väljer leverantör baserat på priset på ett hypotetiskt scope sex månader in i framtiden skapar fel incitament. Leverantören optimerar för att vinna upphandlingen, inte för att leverera värde. Ni optimerar för att dokumentera krav ni inte kan specificera. Resultatet är kontrakt som antingen är för rigida för att hantera verkligheten eller har ändringshantering som kostar mer än projektet ursprungligen budgeterades för.

Det bättre alternativet är ett partnerskap baserat på kapacitet och förtroende: ni köper in kompetens och kapacitet, ni äger vad som byggs, och ni styr riktningen löpande. Det är så vi strukturerar alla våra engagemang — och det är modellen som faktiskt levererar transformation.

← Tillbaka till Aktuellt

Sju frågor att ställa till en AI-partner innan ni skriver kontrakt

Intresset för AI-transformation har lockat in en mängd nya aktörer på marknaden — allt från genuint kompetenta specialister till generalister som lagt till “AI” i sin PowerPoint. Att välja fel partner är kostsamt, inte bara ekonomiskt utan i form av förlorad tid och förtroendekapital internt. Här är sju frågor som hjälper er att skilja på dem.

1. Kan ni visa ett referenscase med liknande komplexitet? Inte en demo eller ett PoC — ett system i produktion, med faktiska användare och mätbara affärsresultat. Fråga specifikt om utmaningarna under vägen och hur de hanterades.

2. Hur ser ert team ut — CV:n för de faktiska personerna som arbetar med oss? Bolagets seniorkompetens och den kompetens ni faktiskt får tillgång till är ofta inte samma sak.

3. Hur hanterar ni vår data? Lagras den hos er? Används den för modellträning? Vad händer med den om engagemanget avslutas? Otydliga svar här är ett varningssignal.

4. Vad är er exit-strategi för oss? En seriös partner designar för att ni ska bli självständiga. Om svaret är vagt bör ni fundera på om ni bygger ett beroende.

5. Hur mäter ni framgång — och vem definierar det? Tekniska KPI:er (precision, latens) utan koppling till affärsmål är inte tillräckliga. Fråga hur de historiskt kopplat teknisk leverans till affärsnytta.

6. Hur ser er incidenthantering ut i produktion? Alla system går sönder. Fråga om SLA, eskaleringsvägar och hur de kommunicerat under incidenter hos tidigare kunder.

7. Vad händer om vi inte är nöjda efter tre månader? Kontraktsstrukturen bör ge er handlingsfrihet. Långa bindningstider utan utvärderingspunkter gynnar bara leverantören.