Hvordan bygge systemer som lærer, organisasjoner som tilpasser seg, og styring som holder under press

Jobben endret seg mens du leste forrige notat. «Teknologi» i teknologidirektør betyr ikke lenger bare skyer, kode og kontrakter; det betyr nå modeller—deres data, atferd, ansvar og strømforbruk. Det betyr å drive et selskap gjennom en levende stack som lærer.

I 2025 dreier en CTOs tyngdepunkt seg rundt tre akser:

  1. Verdifangst fra grensemodeller uten å oppgi handlefrihet (bygg/kjøp/samarbeid).
  2. Styring sterk nok til å tilfredsstille regulatorer, revisorer og ditt eget etiske råd.
  3. Effektivitet i skala—fra GPU-økonomi til utviklerproduktivitet—slik at AI ikke blir din mest elegante kostnadsoverskridelse.

Det som følger er en pragmatisk plan—like deler feltmanual og seminarpresentasjon—for CTO-rollen i AI-æraen. Den lener seg på gjeldende standarder og evidens, ikke magefølelse.

---

1) Hva som faktisk endret seg

  • Regulatorisk virkelighet dukket opp.
EU AI Act er nå lov, ikke et rykte. Den trådte i kraft 1. august 2024, med forbud mot «uakseptabel risiko»-praksis og generelle bestemmelser som gjelder fra tidlig 2025, forpliktelser for generelle AI-modeller fra 2. august 2025, og fasede høyrisikosystemregler som strekker seg inn i 2026–2027 (med en foreslått ett års utsettelse for noen Annex III-systemer på bordet). Harmoniserte standarder utarbeides gjennom CEN/CENELEC, som vil bli den praktiske sjekklisten revisorene dine bryr seg om.
  • Risikostyring ble kodifisert praksis.
NISTs AI Risk Management Framework (AI RMF 1.0) er den globale referansehåndboken; 2024 Generative AI Profile legger til konkrete kontrollmønstre for GenAI-systemer. Hvis du allerede mapper sikkerhet og personvern til NIST eller ISO 27001/31000, plugger AI RMF inn som det AI-spesifikke laget i stedet for et parallelt univers.
  • AI-styring ble en navngitt rolle.
I amerikansk offentlig sektor krever OMB at føderale etater utpeker Chief AI Officers, etablerer AI-styringsråd og vedlikeholder offentlige AI-registre. Det mønsteret—CAIO + register + risikokontroller—sprer seg nå inn i private organisasjonskart innen finans, helse og kritisk infrastruktur.
  • Tilbud, kraft og prisbegrensninger betyr noe.
IEA anslår at global datasenterstrømetterspørsel vil mer enn dobles til omtrent 945 TWh innen 2030, med AI-intensive arbeidsbelastninger som den dominerende driveren. GPU-markeder har modnet men ikke blitt myke: på store skyer kan H100-klasse GPUer fås i lave enkeltsifrede dollar per GPU-time i konkurransedyktige regioner, men kapasitet, lokalisering og bærekraftsbegrensninger betyr at dette ikke lenger bare er «infra»-beslutninger—de er ressursallokeringsbeslutninger på styrenivå.
  • Utviklervirkeligheten slo hypen.
Kontrollerte studier av verktøy som GitHub Copilot viser at utviklere fullfører spesifikke oppgaver ~55% raskere, med statistisk signifikante gevinster i hastighet og subjektiv flyt. Studier på systemnivå tegner et mer beskjedent bilde—10–15% akselerasjon i leveranse når du inkluderer gjennomgang, integrasjon og omarbeid. Din jobb er å absorbere oppsiden samtidig som du forhindrer stille akkumulering av kvalitets- og sikkerhetsgjeld.

---

2) CTOens nye mandat (2025-utgaven)

Tenk i fem løkker. Hver løkke har et målresultat, en metrikk og et styringsankerfeste.

1. Strategi og portefølje

  • Resultat: Et lite antall AI-initiativer knyttet direkte til resultat og kundeverdi.
  • Metrikk: Prosentandel av AI-funksjoner som sendes til produksjon med målt løft (konvertering, løsningstid, NPS, bruttomargin) versus en kontrafaktisk.
  • Styringsankerfeste: AI-brukssaksinventar + risikotiering mappet til AI RMFs MAP → MEASURE → MANAGE → GOVERN-funksjoner.

2. Data og evaluering

  • Resultat: Data du kan forsvare og modeller du kan karaktersette.
  • Metrikk: Deknings- og drift-dashboards; evalueringsskjemaer per modell og per kritisk promptflyt.
  • Styringsankerfeste: Datasheets for Datasets og Model Cards som levende dokumenter; evalueringsrammeverk for RAG/LLM (f.eks. RAGAS, OpenAI-stil eval-pipelines).

3. Sikkerhet og trygghet

  • Resultat: Ingen «ukjente ukjente» i modellatferd eller AI-forsyningskjede.
  • Metrikk: Lukketid på LLM Top-10-klasse sårbarheter; modellproveniens-dekning; red-team-kadens og lukkede funn.
  • Styringsankerfeste: OWASP Top-10 for LLM Apps, MITRE ATLAS som fiendtlig taktikk-katalog, og NISTs Generative AI Profile for kontrollmapping.

4. Kostnad og ytelse

  • Resultat: Beregningsøkonomi du kan justere, ikke bare tolerere.
  • Metrikk: $/spørring, $/vellykket oppgave, GPU-utnyttelse, cache-treffrate, og kostnad per FinOps «Scope» (Sky, AI, SaaS, Datasenter, Lisensiering).
  • Styringsankerfeste: FinOps Framework-faser (Inform → Optimize → Operate) utvidet med 2025 Scopes slik at AI er et førsteklasses utgiftsdomene i stedet for en avrundingsfeil på «sky».

5. Samsvar og ansvarlighet

  • Resultat: Du kan vise hvordan AI tok en beslutning og hvorfor den fikk lov.
  • Metrikk: AI-risikovurderinger fullført per brukssak; revisjonspassrate; tid-til-svar for «hvorfor gjorde systemet X?»
  • Styringsankerfeste: ISO/IEC 42001 (AI-styringssystemer) + ISO/IEC 23894 (AI-risikostyring) mappet til EU AI Acts risikokategorier og milepæler.

---

3) Organisasjonsdesign: Hvor passer en CAIO?

Du har tre brukbare modeller:

  • CTO-sentrert.
CTO eier AI-plattformen og AI-policyen, med et dedikert AI Governance Office (juridisk, sikkerhet, personvern, anvendt forskning). Fungerer godt i mellomstore firmaer som trenger tett kobling mellom arkitektur og risiko, men ikke har råd til en utstrakt C-suite.
  • CTO + CAIO.
CAIO er forvalter av policy, registre og risiko—spesielt i regulerte bransjer—mens CTO eier plattformer og engineering. Dette speiler amerikansk føderal veiledning, som nå eksplisitt pålegger CAIOer, registre og styringsråd, og det mønsteret sprer seg til tungt regulerte private sektorer.
  • Produktledet.
For produktselskaper som sender AI-funksjoner hver sprint, bygg inn AI-produktingeniører i forretningslinjer, med et sentralt AI Platform-team under CTOen for å unngå en dyrehage av inkompatible stacks.

Uansett hva du velger, gjør eksplisitt hvordan CAIO/CTO/CIO/CISO deler eierskap av arkitektur vs. samsvar vs. drift. Tvetydighet her er hvordan du ender opp med tre konkurrerende AI-policyer og ingen klar beslutning når noe går galt.

---

4) Arkitekturmønstre CTOen bør standardisere

A. RAG først, finjuster senere

Retrieval-augmented generation holder data nær din sannhetskilde, forbedrer forklarbarhet og er billigere å iterere på. Men test det som kode: bygg en evalueringsløkke (RAGAS, prompt-enhetstester, regressjonssett) og behandle evalueringsdrift som en hendelse, ikke en kuriositet.

B. Sikkerhetssperrer og input

De fleste høyalvorlighets-feil kommer fra input: prompt injection, dataeksfiltrering, usikker plugin- eller verktøydesign. Mønstermatch mot OWASPs LLM Top-10 og kjør fiendtlige spillbøker fra MITRE ATLAS som del av kontinuerlig sikkerhetstesting.

C. Proveniens overalt

Signer modeller, spor datasett, og krev noe som en SBOM-for-modeller. OpenSSFs modellsigneringsarbeid og lignende initiativer er tidlige, men nyttige signaler. Knytt proveniensssjekker til deployment-godkjenninger slik at «hvem trente denne?» er et knappeklikk, ikke en arkeologisk utgraving.

D. Ytelsesknotter

Definer et ytelsesbudsjett per brukssak: mål-latens, kaldstart-sti og maks tokenkostnad per forespørsel. Cache aggressivt (embeddings, svar, metadata) og rut til billigere modeller når intensjon tillater det—små modeller for rutineoppgaver, grensemodeller for sjeldent, høyverdi-arbeid.

E. Energi og lokalisering

Planlegg for lokaliseringsbegrensninger (EU-data forblir i EU; regulerte arbeidsbelastninger forblir i spesifikke skyer) og eksplisitte strømbudsjetter konsistent med dine bærekraftsrapporteringer og hva IEAs prognoser antyder at styret vil spørre om neste år.

---

5) Data du kan forsvare

For kritiske datasett og modeller er «vi tror det er greit» ikke et svar.

  • Datasheets for Datasets: proveniens, sammensetning, tiltenkt bruk, merkingsprosesser, kjente mangler, vedlikeholdsplan.
  • Model Cards: evalueringsbetingelser, kjente begrensninger, tiltenkt og utenfor-scope-bruk, og lenker til datasettene og promptene som betyr noe.

Disse ser akademiske ut til din første regulator, store kunde eller interne etiske råd stiller et spissformulert spørsmål. Da er de oksygen.

---

6) Sikkerhet du kan sove på

Behandle AI som ethvert annet kraftfullt system: anta at motstandere studerer det.

  • Bruk OWASP LLM Top-10 som en grunnlinje og automatiser sjekker i CI.
  • Bygg et AI red team informert av MITRE ATLAS: forgiftning, prompt injection, modellekstraksjon, jailbreak-kjeder.
  • Mapp avbøtende tiltak til NISTs Generative AI Profile og din bredere AI RMF-holdning slik at sikkerhetsfunn ruller inn i et enkelt risikospråk.

For ML-forsyningskjeden, krev:

  • Signerte modellartefakter,
  • Datasettstamtre med sporbarhetskjede, og
  • Revisjon av treningskode og avhengigheter (SLSA-stil for ML-stacken).

---

7) Kostnad og kapasitet: AI FinOps for voksne

Din nordstjerne er enhetsøkonomi for intelligens: kroner per vellykket utfall, ikke per token.

Sett på plass:

  • Arbeidsbelastningsruting på tvers av modeller og nivåer (hurtigbane små modeller, langsom bane grensemodeller).
  • GPU-utnyttelses-SLOer og policyer for on-demand vs. reservert vs. spot/preemptible kapasitet.
  • Budsjettøvelser som behandler H100-er og deres etterfølgere som varer du sikrer, ikke hellige objekter du hamstrer.
  • FinOps Scopes som gjør AI til et navngitt scope ved siden av offentlig sky, SaaS, datasenter og lisensiering, slik at finans og engineering snakker om det samme utgiftsuniverset.

---

8) Mennesker og kultur: Produktivitet uten ny gjeld

Bevisene er klare på mikrooppgaver: AI-parprogrammeringsverktøy kan gjøre utviklere ~55% raskere på velspesifiserte kodingsoppgaver, og brukere rapporterer høyere tilfredshet. På systemnivåarbeid antyder studier og felterfaring mer beskjedne—men fortsatt reelle—gevinster når du teller integrasjon, kodegjennomgang og feilsøking.

Design kulturen deretter:

  • Oppmuntre AI-bruk; forby uverifiserte commits.
  • Krev tester og sporbar evaluering for AI-assistert kode i kritiske baner.
  • Mål innvirkning på teamnivå, ikke per-utvikler-overvåkning.
  • Lær evalueringskunnskap slik at «modellen sa det» aldri aksepteres som en begrunnelse.

Forvent at tillit henger etter bruk. Det er greit; skepsis er en funksjon, ikke en feil.

---

9) Samsvar: Fra sjekklister til systemer

Mapp forpliktelser til levende systemer:

  • EU AI Act. Spor om hver brukssak er forbudt, høyrisiko eller begrenset risiko, og om GPAI-leverandørforpliktelser gjelder. Juster dine interne standarder med fremvoksende harmoniserte standarder.
  • NIST AI RMF + Generative AI Profile. Bruk dem som ryggraden for policy og risikoregistre, og som oversetter mellom sikkerhet, produkt og juridisk.
  • ISO/IEC 42001 + 23894. Hvis du allerede kjører ISO 27001 eller 9001, utvid styringssystemet ditt til AI med 42001, og bruk 23894 som den AI-spesifikke risikohåndboken.
  • Offentlig sektor-mønstre. Selv om du er privat, er det føderale CAIO + inventar + «rettighetsimpakt»-flaggmønsteret en nyttig mal for din egen styring.

---

10) En 90-dagers plan for en CTO som tar AI seriøst

Dag 1–30: Inventar, sikkerhetssperrer, grunnlinjer

  • Publiser en enkelt side «AI hos [Selskap]»: brukssaker, forbudte saker, datagrenser, godkjenningssti.
  • Etabler et AI-register: modeller, prompter, datasett, eiere, risikonivå.
  • Adoper OWASP LLM Top-10-sjekker i CI; start ATLAS-informerte red-team-øvelser.
  • Kick off Datasheets og Model Cards for dine tre viktigste brukssaker.
  • Definer 3–5 evalueringsmetrikker og ship et minimalt evalueringsrammeverk.

Dag 31–60: Plattformiser

  • Rull ut en intern AI-plattform: henting, promptmaling, sikkerhetssperrer, evalueringer, observerbarhet.
  • Implementer arbeidsbelastningsruting (intensjonsklassifiserer → billig modell vs. grensemodell).
  • Knytt GPU-utgifter til enhetsutfall; koble FinOps-dashboards og SLOer til eksisterende rapportering.

Dag 61–90: Bevis ROI, styrk styring

  • Ship to AI-funksjoner til produksjon med evalueringsmetrikker og forretnings-KPIer i samme dashboard.
  • Kjør en styrings-tabletop: simuler en høyrisikohendelse og en ekstern revisjon ved bruk av AI RMF + ISO 42001-sjekklister.
  • Presenter et AI-beredskapskart til styret: risikoholdning, ROI, beregningsplan og regulatorisk tidslinje (spesielt EU AI Act-milepæler for relevante markeder).

---

11) Beslutningsrammeverk du vil gjenbruke ukentlig

Bygg vs. kjøp vs. samarbeid

  • Kjøp når en leverandør møter dine latens-, kostnads- og datagrensebegrensninger og kan treffe dine KPIer med deres veikart.
  • Samarbeid når dine domenedata trygt kan differensiere en leverandørmodell (f.eks. RAG på proprietære korpuser) og du trenger portabilitet.
  • Bygg når dine begrensninger (latens, personvern, edge, kostnad) eller din konkurransefordel rettferdiggjør det—og kun hvis du kan bemanne kontinuerlig evaluering og sikkerhet.

RAG vs. finjustering

  • Foretrekk RAG for dynamisk kunnskap, forklarbarhet og styringstilpasning.
  • Gå til finjustering for å redusere inferenskostnad/latens i skala etter at du har stabile evalueringer, klare sikkerhetssperrer og en reell brukskurve.

Sentralisering vs. føderering

  • Sentraliser plattformprimitiver: vektorhenting, sikkerhetssperrer, evalueringsrammeverk, observerbarhet.
  • Federer domeneprompter, datasett og evalueringskriterier under dokumenterte datakontrakter og datasheets.

---

12) Måle det som betyr noe

Et moderne CTO-dashboard bør inkludere:

  • Produkt: Løft per AI-funksjon (konvertering, løsningstid, CSAT), pluss kontrafaktiske.
  • Kvalitet: Grounding/troverdighetspoeng, avslagsrate der det er passende, sikkerhetshendelsestelling.
  • Drift: Latenspersentiler, cache-treffrate, fallback-rate mellom modeller.
  • Sikkerhet: Prompt-injection-blokkeringer, jailbreak-forsøk oppdaget, modellintegritetssjekker.
  • Kostnad og bærekraft: $/vellykket oppgave, GPU-utnyttelse og estimert energi per 1000 forespørsler, med trendlinjer justert til datasenterenergiprognoser.

---

13) Styresamtaler (som lander)

  • Hvor er ROIen?
Bruk kontrollerte eksperimenter og vis EBIT-innvirkning. Referer til eksterne benchmarks—for eksempel McKinseys analyse av hvor AI faktisk skaper verdi—uten å importere forfengelighetsmål.
  • Er vi trygge og i samsvar?
Pek på AI RMF-kontrolldekning, ISO 42001-beredskap og din EU AI Act-tidslinje.
  • Hva med kraft, chips og kostnadsvolatilitet?
Vis kapasitetssikringer, enhetsøkonomi-sikkerhetssperrer og datasenterenergiprognoser i et FinOps-rammeverk.
  • Organisasjonsdesign—trenger vi en CAIO?
Referer til offentlig sektor-mønsteret og hva jevnaldrende gjør; hvis du ikke utnevner en, forklar hvordan styring fungerer og hvem som tar avgjørelsen under en hendelse.

---

14) Tankeskiftet

Gartner sier GenAI har sprintet inn i «desillusioneringens dal». Det er sunt. Det gir rom for håndverk: færre men bedre systemer; færre modeller, sterkere evaluering; en kultur som lærer.

Din jobb er å erstatte show med forvaltning—ikke langsommere, bare mer bevisst. Du slutter å behandle AI som et demoteater og begynner å behandle det som en del av firmaets kontrollplan.

I denne æraen ser den eksemplariske CTOen litt ut som en romanforfatter og litt som en forskningsleder: oppmerksom på konsekvensene av hver karakter (datasett, modell, metrikk) og deres interaksjoner; disiplinert om hypoteser og tester; skeptisk nok til å kreve bevis; fantasifull nok til å forme det som kommer.

På gode netter summer stacken stille—logger som driver forbi som gatelykter sett fra et seintogsvindu. På dårlige netter skjærer alarmer gjennom stillheten. I begge tilfeller er oppgaven din den samme: hold systemet lærende uten å miste tråden.

Stacken lever nå. Behandle den slik.

---

15) Feilmodi den AI-native CTOen betales for å unngå

En erfaren CTO optimerer ikke bare for suksess; de utvikler en følelse for hvordan AI-programmer feiler. Tre mønstre gjentar seg:

1. Pilotgravplasser

Team kjører et dusin piloter uten delt evalueringsprotokoll, ingen kontrafaktiske og ingen plan for produksjonssetting. Seks måneder senere sier presentasjonen «vi testet AI på tvers av virksomheten», men ingen kan fortelle deg hvilke ideer som faktisk fungerte. Dette er en evalueringsfeil, ikke en innovasjonsfeil: løsningen er et felles eksperimentdesign, standardmetrikker og en klar uteksaminering fra sandbox → begrenset utrulling → produksjon.

2. Styringsdrift

Policy skrives én gang og overlates til fossilisering mens stacken utvikler seg under. En ny grensemodellintegrasjon omgår stille tidligere kontroller. Skygge-RAG-systemer dukker opp i forretningsenheter fordi «sentralt» var for sakte. Innen risiko oppdager dette, mangler logger og dataflytdiagrammer er fantasi. Motgiften er kjedelig og kraftfull: et levende AI-register, endrings-kontrollerte referansearkitekturer og plattform-først-tenkning slik at «skygge-AI» rett og slett ikke har noe sted å plugge inn bortsett fra gjennom styrte primitiver.

3. Metrikkteater

Dashboards gløder med tokentellinger, promptlatenser og «adopsjons»-kurver, men ingen kan svare på det enkle spørsmålet: hjalp det kunden, og hjalp det virksomheten? En AI-funksjon som reduserer håndteringstid mens den stille tanker NPS er ikke en suksess; det er en forsinket hendelse. Behandle produktnivå A/B-tester og brukernivåinnvirkning (på både ansatte og kunder) som førsteklasses borgere i din observerbarhethistorie, ikke som ettertanker.

4. Menneskelig ferdighetstap

Overavhengighet av assistenter tærer på kjernekompetanse: analytikere slutter å utfordre modelloutput; juniorutviklere lærer aldri å feilsøke uten autofullføring; anmeldere skummer i stedet for å lese. Feilen viser seg sakte: en subtil økning i gjennomsnittlig løsningstid for driftsstans, en nedgang i kodebasekoherens, et snikende tap av domenevurdering. Motvirk dette med bevisst praksis: «AI-av»-øvelser, kodegjennomganger som eksplisitt undersøker AI-genererte segmenter, og progresjonskriterier som fortsatt krever menneskelig forståelse.

Dette er ikke eksotiske kanttilfeller; de er standardbanen når AI-adopsjon er rask men ustrukturert. Den AI-native CTOens fordel er ikke hemmelige algoritmer—det er viljen til å designe mot disse feilmodiene på forhånd.

---

Hurtigreferanse (standarder og signaler)

  • NIST AI RMF 1.0 og Generative AI Profile – risiko- og kontrollryggrad.
  • EU AI Act-milepæler (2025–2027) – forbudte, høyrisiko og GPAI-forpliktelser pluss harmoniserte standarder.
  • ISO/IEC 42001 og 23894 – AI-styringssystem og AI-risikoveiledning.
  • OWASP LLM Top-10 og MITRE ATLAS – sikkerhetsgrunnlinjer og fiendtlig taktikk.
  • FinOps Framework 2025 + Scopes – Sky + AI + SaaS + Datasenter kostnadsdisiplin.
  • IEA og relatert analyse om datasenterstrømetterspørsel – kontekst for styrenivåkapasitets- og bærekraftsamtaler.