01
Generativ AI i virksomheder: hvor giver det værdi?
Generativ AI skaber værdi i opgaver med meget tekst, billeder, kode eller ustruktureret information. Det kan være første udkast til kampagnevarianter, klassificering af henvendelser, opsummering af kundesamtaler, søgning i interne vejledninger eller forslag til kode. Opgaven skal have et tydeligt input, et kontrollerbart output og en modtager, der kan vurdere kvaliteten. En imponerende demo uden en reel arbejdsgang sparer ingen tid.
Prioritér efter volumen, tidsforbrug, fejlkonsekvens og datatilgængelighed. En hyppig opgave med lav risiko er ofte bedre som første projekt end en sjælden ledelsesbeslutning. Beregn gevinsten som frigivet arbejdstid, kortere svartid, højere kvalitet eller flere korrekt behandlede sager. Medregn licenser, integration, kontrol og løbende evaluering. ROI bør sammenlignes med en enklere regelbaseret automatisering, som nogle gange løser problemet bedre.
Start med et afgrænset forløb og et manuelt sikkerhedsnet. Test på repræsentative eksempler, herunder vanskelige og tvetydige sager. Definér hvad et acceptabelt svar er, hvornår systemet skal afvise, og hvem der godkender. Når kvaliteten er stabil, kan flere datakilder eller handlinger tilføjes. Den rækkefølge gør læringen billig og holder risikoen synlig.
02
AI-agenter forklaret
En chatbot svarer normalt på en brugers besked i én samtale. En automation følger et på forhånd defineret flow, eksempelvis når en formular opretter en opgave i CRM. En AI-agent kan fortolke et mål, planlægge flere trin, vælge mellem tilladte værktøjer og tilpasse næste handling til resultatet. Agenten kan eksempelvis læse en henvendelse, slå virksomheden op, foreslå en kategori og sende sagen til den rette kø.
Fleksibiliteten øger også risikoen. Værktøjer skal have mindst mulige rettigheder, og kritiske handlinger som offentliggørelse, budgetændringer eller udsendelse bør kræve menneskelig godkendelse. Agenten skal kende stopregler, datagrænser og et maksimum for antal trin. Loggen bør vise input, valgte værktøjer og resultat, så en fejl kan forklares uden at gemme flere personoplysninger end nødvendigt.
Vælg chatbot til vejledning og spørgsmål, automation til stabile gentagelser og agent til opgaver, hvor rækkefølgen afhænger af indholdet. Kombinér dem gerne: chatbotten indsamler behovet, agenten undersøger, en regel kontrollerer adgang, og et menneske godkender udfaldet. Arkitekturen bør være så enkel som opgaven tillader, fordi hver ekstra beslutning gør test og ansvar vanskeligere.
| Løsning | Styrke | Bedst til | Kontrol |
|---|---|---|---|
| Chatbot | Samtale | Spørgsmål og vejledning | Svarregler |
| Automation | Forudsigelighed | Faste arbejdsgange | Definerede trin |
| AI-agent | Tilpasning | Mål med varierende trin | Værktøjsgrænser og godkendelse |
03
MCP og A2A: sådan bliver din virksomhed synlig for AI-assistenter
Model Context Protocol, MCP, blev introduceret af Anthropic i 2024 som en åben standard for at forbinde AI-systemer med værktøjer og datakilder gennem en ensartet grænseflade. En MCP-server kan beskrive læsbare ressourcer og sikre handlinger, så en assistent ikke skal have en specialbygget integration til hvert system. Virksomheden bestemmer fortsat, hvilke data og funktioner der er offentlige, kræver login eller slet ikke må eksponeres.
Agent2Agent, A2A, blev introduceret af Google som en åben protokol for samarbejde mellem agenter. Et agentkort beskriver kompetencer og endpoint, mens opgaver kan sendes og følges i et standardiseret format. A2A handler om agenters samarbejde, mens MCP især handler om adgang til kontekst og værktøjer. Standarderne supplerer derfor hinanden, men løser ikke identitet, tilladelse og forretningsregler automatisk.
Synlighed kræver præcise beskrivelser, stabile URL'er og svar, der kan spores til godkendt indhold. Offentlige funktioner bør begrænses til ufarlige opslag og kontrollerede henvendelser, mens persondata og handlinger beskyttes med samtykke, autentifikation og rate limits. Test hvordan andre klienter læser beskrivelserne, og returnér strukturerede fejl. Se V7's egen AI-agent i drift på /agents for et konkret eksempel med A2A og MCP.
04
Governance, data og ansvar
Kortlæg først hvilke data løsningen læser, hvor de sendes, hvor længe de gemmes, og hvem der kan se loggen. Personoplysninger kræver et behandlingsgrundlag, dataminimering og relevante databehandleraftaler. Følsomme oplysninger bør som udgangspunkt holdes ude af prompts, medmindre behov, leverandør og sikkerhed er vurderet. Adgang til CRM, annoncekonti og interne dokumenter gives efter mindst mulige rettigheder. Leverandørens indstillinger for træning, geografisk behandling og sletning skal kontrolleres konkret. Anonymisering er kun reel, hvis oplysninger ikke kan føres tilbage til en person gennem andre felter. Lav også en fast procedure for adgangsændringer, hændelser og sletningsanmodninger, så driften følger de aftalte regler efter lanceringen.
Human-in-the-loop betyder mere end en knap mærket godkend. Den ansvarlige skal have den nødvendige kontekst, kunne ændre forslaget og forstå konsekvensen. Lavrisiko-udkast kan stikprøvekontrolleres, mens kundesvar, publicering eller økonomiske handlinger kan kræve godkendelse hver gang. Log beslutning, modelversion, værktøj og udfald, men undgå at gøre loggen til en ny kopi af alle persondata.
EU's AI-forordning indfases i disse år, og krav afhænger blandt andet af anvendelse og risiko. Virksomheden bør holde et register over løsninger, formål, leverandører og ansvarlige samt have en vej til at rapportere fejl. Juridisk vurdering skal komme fra relevante rådgivere. Den tekniske opgave er at gøre dataflow, kontrol og ændringer synlige nok til, at organisationen faktisk kan føre tilsyn.
05
Sådan kommer I i gang med AI
Trin ét er at samle konkrete opgaver fra medarbejdere, ikke generelle ønsker om at bruge AI. Beskriv start, slut, hyppighed, tidsforbrug, systemer og kendte fejl. Trin to er prioritering efter værdi, gennemførlighed og risiko. Vælg en opgave, hvor input findes digitalt, kvalitet kan vurderes, og en fejl kan fanges, før den rammer en kunde eller økonomien.
Trin tre er en prototype med få repræsentative data og uden brede systemrettigheder. Sammenlign output med en menneskelig baseline og registrér fejltyper som manglende fakta, forkert tone eller ubegrundede antagelser. Trin fire er integration og sikkerhedsdesign: adgang, godkendelser, logning, timeout, rate limits og håndtering af nedbrud. Test også hvad der sker, når data mangler eller værktøjet svarer uventet.
Trin fem er kontrolleret drift. Uddan brugerne i styrker, begrænsninger og rapportering af fejl. Følg kvalitet, behandlingstid, afvisninger og menneskelige rettelser frem for kun antal genererede svar. Udvid først til flere handlinger, når den oprindelige opgave har stabil kvalitet og en tydelig ejer. Så bliver køreplanen en række dokumenterede forbedringer frem for ét stort transformationsprojekt.
- 01Beskriv konkrete gentagne opgaver
- 02Prioritér værdi, data og risiko
- 03Prototype med få rettigheder
- 04Test kvalitet og fejltyper
- 05Byg kontrol, logning og fallback
- 06Mål drift før næste udvidelse
