Dette er en meningsartikkel, ikke et oppslagsverk. Den er skrevet av DOPS, som bygger systemer for å leve av det — så les den med det i bakhodet. Registrene våre holder seg til fakta; her sier vi hva vi faktisk mener.
Standpunktet
Seriøse systemer bør bygges på åpne standarder — JavaScript, HTML, CSS, SQL, åpne protokoller og formater — ikke låses inne i en proprietær plattform. Vi kaller det «yes code», i motsetning til no-code.
Ikke fordi kode er en verdi i seg selv. Fordi åpne standarder er det eneste som gir deg eierskap, portabilitet og levetid: retten til å flytte, til å bytte leverandør, og til å la hvem som helst videreutvikle systemet ditt.
No-code er utmerket til prototyper, interne småverktøy og å teste en idé fort. Det er når løsningen blir forretningskritisk at spørsmålet melder seg: hvem eier dette egentlig?
Testen: ti år fram i tid
Still ett spørsmål om enhver plattform du vurderer: hva skal til for at noen andre enn dagens leverandør kan drifte og videreutvikle dette?
Er svaret kort og konkret, er lock-in lav. Er svaret vagt, har du målt den. Det er hele testen.
Bubble sier det rett ut i sin egen dokumentasjon: applikasjoner kan bare kjøres på Bubble-plattformen. Det er ærlig, og det er greit — så lenge du vet det før du bygger, ikke etter. OutSystems' variant er mer krevende å gjennomskue: det genereres standard .NET, sies det, altså ingen innlåsing. Men å faktisk koble ut koden krever en supportsak, den inneholder deres egne kjøretidsbiblioteker, den er enveis, alt-eller-ingenting, og løsningen er uten støtte etterpå. Du eier applikasjonen juridisk. Du kan bare ikke bruke den uten dem.
Det er forskjellen på eierskap på papiret og eierskap i praksis. Se kravet om eierskap til kode og data for formuleringer du kan ta rett inn i en kravspek.
Norsk datasenter er ikke norsk jurisdiksjon
Dette er den enkeltmisforståelsen som koster norske virksomheter mest, og den er lett å forstå: Azure har regioner i Oslo og Stavanger, altså ligger dataene i Norge, altså er vi trygge.
Første ledd er sant. Konklusjonen er det ikke.
CLOUD Act følger selskapet, ikke serveren. Microsoft, Amazon og Google er amerikanske selskaper, og amerikanske myndigheter kan kreve utlevering av data selskapet kontrollerer — uavhengig av hvilket land maskinen står i. En norsk region løser latens og et datalokasjonskrav. Den løser ikke jurisdiksjon.
Dette er ikke en påstand om at hyperscalerne er dårlige. De er teknisk fremragende, og for svært mange formål er dette en risiko man kan akseptere med åpne øyne. Poenget er nettopp at valget skal tas med åpne øyne — ikke fordi noen antok at «Oslo-region» betydde noe det ikke betyr.
Hva EU Data Boundary faktisk er
Microsoft svarer på dette med EU Data Boundary, og det er et reelt og seriøst tiltak. Men les hva de selv skriver: EUDB er en kontraktuell forpliktelse fra Microsoft — ikke det samme som en juridisk grense som EØS- eller GDPR-perimeteren.
Det er en vesentlig forskjell. En kontrakt er et løfte fra en part. En jurisdiksjon er hvilken rett som gjelder når noen med makt spør.
Og tallene finnes: i Microsofts egen åpenhetsrapport for andre halvår 2025 er det 115 kjennelser for innhold lagret utenfor USA. Dokumenterte unntak fra EUDB omfatter dessuten fjerntilgang for drift utenfor EU, sikkerhetsoperasjoner som kan overføre til «hvilken som helst Azure-region globalt», profesjonelle tjenester i amerikanske datasentre, og AI-ruting utenfor EUDB som er på som standard for nye leietakere.
Ingenting av dette er skjult. Det står i Microsofts egne kilder. Det er bare nesten ingen i Norge som leser dem.
AI gjorde koden billig — og resten dyrere
Argumentet mot skreddersøm har alltid vært kostnaden. Det argumentet er i ferd med å forvitre: AI-assistert utvikling gjør det å skrive kode dramatisk billigere, og grensen for når egen løsning lønner seg flytter seg nedover.
Men gevinsten er ujevn, og det er dét folk bommer på. AI gjør det billige billigere og rører nesten ikke det dyre. En listevisning skrives på minutter. Å sende e-post som faktisk kommer fram — DNS, SPF, DKIM, leveringsgrad — tar omtrent like lang tid som før. Integrasjon mot Maskinporten med ekte sertifikater og hjemler: uendret. Avklaringer, prioritering og verifisering: uendret, eller mer.
Konsekvensen er at andelen av et prosjekt som er avklaring, integrasjon og verifisering går opp, fordi koden rundt ble billig. Og når en modell kan produsere hundre skjermbilder på en ettermiddag, er det ikke lenger produksjonsevnen som er knapp — det er evnen til å bestemme hva som skal bygges, og til å vite om det faktisk stemmer.
Det er også derfor åpne standarder betyr mer nå, ikke mindre: en prototype er nesten gratis, men det er detaljene, eierskapet og standardene som avgjør om noe holder i produksjon.
Der vi ikke har rett
Et standpunkt uten forbehold er en brosjyre. Så her er det vi ikke får til å stemme:
- Åpen kildekode er ikke bare bra. Forsyningskjedeangrep som xz-bakdøren, uvedlikeholdte avhengigheter, lisenser som ikke passer kommersiell bruk, ingen SLA og ingen å ringe. Og en liten leverandør som åpner koden får angripernes oppmerksomhet uten forsvarernes — «many eyes» virker for Linux-kjernen, ikke for et produkt med ett lite team bak.
- Docly er ikke åpen kildekode. Vår egen plattform har lukket kjerne. Det er et bevisst valg, og det koster oss på portabilitet. Vi kompenserer med at prosjektene er åpne filer og JavaScript, at løsningen kan selvhostes, og med et løfte om å frigi kildekoden hvis Docly legges ned. Men et løfte er en kontinuitetsgaranti, ikke åpen kildekode — og ikke det samme som en byggeverifisert escrow. Bubble gir for øvrig samme løfte.
- Vi drifter selv i Azure. Hovedsiden og skypålogging for Docly ligger i Azures norske region. Da gjelder alt vi skrev ovenfor om CLOUD Act — også for oss. Vi har også egne servere på Røa i Oslo, og Docly kan selvhostes. Men vi kan ikke påstå å stå utenfor et problem vi selv står i.
- Vi har ikke ISO 27001. Azure, AWS og Elastx har det. Vi ikke.
- Hyperscalerne er gode. Bredden, modenheten og økosystemet er reelt. For mange er det riktig valg, og vi ville sagt det samme til en kunde.
Vi skriver dette fordi et standpunkt bare er verdt noe hvis det tåler å bli holdt opp mot den som fremmer det. Registrene våre holder seg til fakta du kan etterprøve. Denne artikkelen er der vi mener noe — og du skal vite forskjellen.
Trenger dere hjelp med dette i praksis? DOPS har ledet systemutviklingsprosjekter for norske virksomheter i over 20 år.
Snakk med et fagmiljøOfte stilte spørsmål
Betyr «yes code» at man aldri skal bruke no-code?
Nei. No-code er utmerket for prototyper, interne småverktøy og å teste en idé raskt. Poenget er at når løsningen blir forretningskritisk, bør du vite hva som skal til for å flytte den — og for de fleste no-code-plattformer er svaret: den kan ikke flyttes.
Er ikke data i Azures norske region trygt nok?
Det avhenger av hva du beskytter mot. En norsk region løser latens og krav om datalokasjon. Den løser ikke jurisdiksjon: CLOUD Act følger selskapet, ikke serveren, og Microsoft er amerikansk. Har du et hardt krav om at data ikke skal kunne nås under amerikansk rett, må du velge en leverandør som ikke er underlagt den.
Er ikke EU Data Boundary nok?
EUDB er et reelt tiltak, men Microsoft skriver selv at det er en kontraktuell forpliktelse — ikke det samme som en juridisk grense som EØS. Det finnes dokumenterte unntak, blant annet fjerntilgang for drift utenfor EU og sikkerhetsoverføringer til Azure-regioner globalt.
DOPS selger jo systemutvikling. Hvorfor skal jeg tro på dette?
Det skal du ikke uten videre. Vi er en markedsaktør og har åpenbar egeninteresse. Derfor holder registrene våre seg til fakta du kan etterprøve selv, og derfor står forbeholdene våre i denne artikkelen — inkludert at vår egen plattform ikke er åpen kildekode, at vi selv drifter i Azure, og at vi ikke har ISO 27001.