Question 1

Vi har prøvd AI før, og det festet seg ikke. Hva er annerledes her?

Accepted Answer

De fleste AI-piloter strander på én av tre måter: systemet fungerte i demo, men kom aldri i produksjon; produksjonssystemet fungerte, men ingen på innsiden eide det etter lansering; eller det løste feil arbeidsflyt på feil skala. Vi jobber motsatt vei. Hvert oppdrag scopes rundt en arbeidsflyt dere allerede kjører, med et 37,5-timers pilotløp som leveres inne i deres miljø og en dokumentert overlevering slik at teamet deres kan drifte systemet etter at vi er ferdige. Infrastrukturen blir værende hos dere. Revisjonsloggen er reell. Ingen demoteater.

Question 2

Hvordan ser et første pilotløp ut for et fond, et hotell eller et byrå som vårt?

Accepted Answer

Hver vertikal har et eget mønster for første pilot. Vi scoper den faktiske arbeidsflyten i Oppdagelses-fasen, men utgangspunktet ser vanligvis ut som ett av disse: Kapitalforvaltning og finans: automatisert syntese av analytiker-memoer fra interne dokumenter, eller sammenstilling av compliance-bevis på tvers av MiFID II- og PSD2-rapporteringssykluser. Revisjonslogger og menneskelig kontroll på hver konsekvensvurdert utdata. Hotell og restaurant: GM-rapportering som trekker fragmenterte PMS-, POS- og kanaldata inn i én ukentlig lesning, eller et internt kunnskapslag slik at service-team finner svar på policy og prosedyrer på sekunder. Markedsføringsbyråer: kampanjebrief-omløp komprimert via en agentic arbeidsflyt, eller repeterbare klient-leveransemaler som skalerer uten proporsjonal headcount. Utenfor disse tre: vi leverer fortsatt der scope passer, inkludert non-profit-operasjoner. Oppdagelses-fasen er den samme. Vi scoper det som faktisk taper tid, ikke det som er enklest å demo'e.

Question 3

Hvor passer ikke AI, og vil dere si fra?

Accepted Answer

Ja, direkte. Arbeidsflyter vi takker nei til eller styrer i en annen retning: alt som avhenger av skjønn over et fåtall høyrisiko-beslutninger per år (modellen har ingenting å lære av), arbeidsflyter der dataene vi trenger ikke samles inn eller er for støyete til å bli rene, arbeidsflyter der en regelbasert automatisering eller et regneark allerede løser problemet billigere, og alt EU AI Act eksplisitt forbyr eller behandler som høyrisiko uten at deployeren har infrastrukturen til å støtte det. Det operative prinsippet vårt er at feil verktøy oppskalert er feilmoduset vi eksisterer for å forhindre.

Question 4

Hvordan unngår dere proof-of-concept-pilotene som aldri når produksjon?

Accepted Answer

Pilotløpet styres etter tre kriterier uansett scope, ikke etter om demoen var imponerende. For det første scopes arbeidsflyten smalt nok til at produksjonsversjonen er et endelig ingeniørprosjekt, ikke et forskningsprogram. For det andre kartlegges datastien ende-til-ende i Oppdagelses-fasen, slik at integrasjon ikke blir overraskelsen som dreper leveransen senere. For det tredje dokumenteres produksjonsplanen før pilotløpet er ferdig, inkludert hvem på deres side som eier systemet etter lansering. Hvis de tre ikke er på plass når pilotløpet avsluttes, sier vi det. Poenget med pilotløpet er å finne ut, ikke å selge et oppfølgingsoppdrag.

Question 5

Hvor lang tid tar det før en pilot er i produksjon?

Accepted Answer

Pilotløpet scopes etter fokuset dere velger. For en definert smal arbeidsflyt er 37,5 konsulenttimer over 2-3 uker det typiske utgangspunktet, og dekker Oppdagelse (skoping av arbeidsflyt, kartlegging av data, omforente suksesskriterier) pluss starten på Implementering (en fungerende versjon i deres miljø). Bredere regulatorisk, compliance- eller strategisk scope skaleres opp derfra. Vi anbefaler alltid å gå dypt på ett definert område først, levert med den kvaliteten og det ROI-potensialet en kjøper faktisk kan handle på, fremfor å gå bredt og kutte hjørner. Fra pilot til produksjon lander vanligvis på 8-14 uker når scope er fastsatt.

Question 6

Hva bør vi budsjettere for et pilotløp, og hva endres mot produksjon?

Accepted Answer

Pilotløpet er der den økonomiske forpliktelsen er begrenset til dere har sett systemet kjøre på deres data: Pilot: scopes etter arbeidsflyten dere velger. For et definert smalt scope er 37,5 konsulenttimer over 2-3 uker det typiske utgangspunktet; bredere regulatorisk, compliance- eller strategisk dybde skaleres opp derfra. Uansett låser pilotløpet prisbåndet før dere forplikter dere til noe ut over det. Produksjon (bygge-vei): scope-priset, pluss en vedlikeholdsavtale. Pilotutgangen navngir integrasjonsflate og modellbruk, slik at produksjonsbeløpet er konkret, ikke en plassholder. Produksjon (per-bruker-vei): de første vertikaltilpassede plattformene lanseres Q3 2026 med offentlig prising ved lansering, for organisasjoner som foretrekker en per-bruker-modell fremfor en bygging. Opplæring: kurs og workshops priset per økt eller program, scoped rundt teamet deres.

Question 7

Kan systemet integreres med det vi allerede kjører?

Accepted Answer

Ja, og integrasjon er der de fleste AI-pilotene stille dør når de skal i produksjon. Vi kobler til CRM, ERP, dokumentlagre, e-post- og ticket-systemer, interne databaser og spesialbygde verktøy via API, fil-koblinger eller direkte databaselesing der det passer. Kartlegging av integrasjonsflaten er en del av de 37,5 Oppdagelses-timene, ikke en ettertanke, slik at produksjonssystemet glir inn i det dere allerede kjører i stedet for å vente på et integrasjonsprosjekt som aldri blir bemannet.

Question 8

Er deres AI-løsninger compliant med EU AI Act?

Accepted Answer

Ja. Hvert system klassifiseres etter risikoklasse i EU AI Act og dokumenteres deretter. Vi oppgir AI-bruk overfor sluttbrukere der Artikkel 50 om transparens gjelder, holder menneskelig kontroll på konsekvensvurderte utdata, og fører den tekniske dokumentasjonen en deployer eller distributør forventer ved forespørsel. Leie-vertikalene er dokumentert på plattformnivå; Eid-leveranser arver tenantens egne kontroller pluss vår referansepakke for compliance.

Question 9

Er deres AI-løsninger GDPR-compliant?

Accepted Answer

Ja. Lovlig grunnlag etableres før behandling, dataminimering er standard, og personopplysninger håndteres under dokumentert tilgangskontroll med oppbevaring knyttet til formålet. Vi tilpasser databehandleravtaler og ROPA-oppføringer til deres tenant-rammeverk, og systemdokumentasjonen reflekterer det som faktisk er i produksjon. For full detalj, se Personvernerklæringen.

Question 10

Lagrer dere data innenfor EU/EØS?

Accepted Answer

Ja. Produksjons-workloads kjører i europe-west1 (Belgia) eller europe-west4 (Nederland) på Google Cloud Vertex AI som standard. Der en klient krever en spesifikk leverandør (Azure, AWS eller on-premises), konfigurerer vi leveransen mot den regionen i stedet. Inferens mot Claude og andre modell-leverandører er kontraktsmessig begrenset til EU-regioner der leverandøren støtter det. Dataminimering er standard på hvert lag.

Question 11

Bruker eller lagrer dere personopplysninger i AI-prosjekter?

Accepted Answer

Vi unngår personopplysninger der arbeidsflyten ikke trenger dem. Der det er nødvendig (en kundeservice-agent, en CRM-berikelse), bruker vi pseudonymisering, scoped tilgang og formålsbegrenset behandling. Samtykke eller annet lovlig grunnlag etableres på forhånd, oppbevaring knyttes til det oppgitte formålet, og sporbarheten logges slik at en sletting- eller innsynsforespørsel kan besvares konkret.

Question 12

Tilbyr dere tilpasning for regulerte bransjer (f.eks. finans, helsevesen)?

Accepted Answer

Ja, og de regulerte vertikalene er der mest av live-arbeidet vårt sitter. For kapitalforvaltning og finans kartlegger vi mot MiFID II, PSD2, EU AI Act og tenantens egne risikoretningslinjer. For hotell og byråer fokuserer vi på GDPR-egnethet, databehandleravtaler og revisjonsklar dokumentasjon. Compliance-pakken i pilotløpet er dimensjonert etter faktisk risikoklasse, ikke en generisk sjekkliste.

Question 13

Hvor kan deres AI-systemer distribueres?

Accepted Answer

I deres eksisterende sky-tenant — GCP, Azure eller AWS — eller on-premises hvis datasensitivitet eller latens rettferdiggjør det. Sky-valget styres av hvor team og data allerede befinner seg, og hvilken leverandørs regioner og DPA-er som matcher deres regulatoriske kravnivå, ikke av en standard vi sender ut til alle. Applikasjonshosting, vektorlagring og modellinferens kan hver rute gjennom forskjellige leverandører når arbeidsflyten krever det. On-premises er riktig når arbeidsflyten kjører lokalt eller data ikke kan forlate deres perimeter.

Question 14

Hvilke AI-modeller bruker dere, og hvordan velger dere mellom dem?

Accepted Answer

Vi velger modell mot arbeidsflyten, ikke etter leverandørpreferanse. Vi vil ikke deployere Claude der Gemini leser oppgaven bedre, eller ChatGPT der Claude leser den bedre. De fleste agentiske og resonnerende workloads leveres på Anthropic Claude (Sonnet eller Opus); noen retrieval-, klassifiserings- og strukturert-utvinning-flyt lander bedre på Google Gemini eller mindre open-weights-modeller; transkripsjon og stemme bruker OpenAI Whisper. Der det regulatoriske kravnivået eller datasensitivitet utelukker et hostet API, deployerer vi en lokal open-weights-modell i deres egen infrastruktur. Uansett hvilken modell vi velger, er den dokumentert sammen med datastien den ser, slik at compliance-historien er konkret.

Question 15

Hvordan sikrer dere transparens i AI-beslutningsprosesser?

Accepted Answer

For hver AI-drevet beslutning holder vi tre ting synlige: input systemet så, resonnementet eller oppslagsstien det brukte, og det menneskelige godkjenningstrinnet på konsekvensvurderte utdata. Revisjonslogger skrives på arbeidsflyt-nivå, ikke bare modell-nivå, slik at en revisor kan rekonstruere hva som skjedde og hvorfor. Der EU AI Act Artikkel 50 om transparens gjelder (brukeren snakker med AI), oppgir vi det på interaksjonsflaten.

Question 16

Hvilke sikkerhetstiltak implementerer dere?

Accepted Answer

Sikkerhet dimensjoneres etter systemets risikoklasse, ikke en fast sjekkliste. Det grunnleggende som hver leveranse har: Rollebasert tilgangskontroll med revisjonslogger på arbeidsflyt-nivå, ikke bare modell Kryptering under overføring (TLS) og ved lagring (CMEK der skyen støtter det) Workload-isolasjon per tenant, der delte plattform-tenanter er logisk adskilt Hemmeligheter lagret i skyleverandørens KMS, aldri i kode eller miljødump Vertex AI, Azure eller AWS som basislag, hver ISO 27001- og SOC 2-sertifisert

Question 17

Hva skjer hvis vi ikke finner svaret vi leter etter?

Accepted Answer

Send e-post til stefan@nordicai.net eller bruk skjemaet under. Vi svarer i klart språk og trekker dere ikke inn i en salgsprosess før dere har det dere trenger for å bestemme dere.

De spørsmålene du lurer på (men kanskje ikke tør å spørre)

Pilot-scope, pris og leveransetid