Integrationer

Under Organisation → Integrationer forbinder du AgentBase til eksterne systemer med organisationens egne adgangsoplysninger. Integrationerne er Datafordeler — Danmarks offentlige registre — og egne AI-nøgler til OpenAI, Azure OpenAI, Mistral og jeres egen LLM-server (LiteLLM/vLLM). Med organisationens egen Datafordeler-adgang kan AgentBase også hente adgangsbegrænsede data, fx Ejere (EJF), som platformens standardadgang aldrig kan nå; med egne AI-nøgler afregnes organisationens AI-kald direkte hos leverandøren.

Adgang

Rolle	Rettighed
Udvikler	Kan bruge integrationen i flows (fx vælge adgangsbegrænsede registre i Datafordeler-byggeklodsen)
Organisationsadministrator	Kan se siden og konfigurere, teste og fjerne integrationer

Sådan hænger det sammen

Datafordeler skelner mellem åbne registre (Bygninger/BBR, Matrikel, Adresser/DAR, Ejendomsvurdering/VUR, Ejendomsbeliggenhed/EBR, DAGI) og adgangsbegrænsede registre (Ejere/EJF, Personer/CPR og SE-numre/SVR). De åbne virker med platformens standardadgang uden opsætning. De adgangsbegrænsede kræver, at jeres organisation selv har fået adgang hos Datafordeler — det er den offentlige myndighed, der ejer IT-systemet og adgangen, og AgentBase kalder på jeres vegne med jeres adgangsoplysninger.

Når integrationen er sat op, vælger I selv hvilke registre der skal bruge organisationens egen adgang. Adgangsbegrænsede registre er slået til fra start (de virker kun den vej); åbne registre er slået fra fra start og bliver ved med at bruge platformens standardadgang, medmindre I slår dem til.

Opsætning af Datafordeler

Forudsætning: jeres organisation har et IT-system i Datafordeler Administration med systemadgangen OAuth Shared Secret, og har søgt om adgang til de registre, I skal bruge — ansøgningen behandles af registrets myndighed: for Ejere/EJF er det Geodatastyrelsen, for Personer/CPR søges via virk.dk hos CPR-kontoret.

1. Log ind i Datafordeler Administration som organisationens administrator.
2. Opret eller åbn jeres IT-system, og vælg systemadgangen OAuth Shared Secret. Notér ClientId, og opret en adgangskode.
3. Tilføj AgentBase-platformens IP-adresse (vises på Integrationer-siden) på IT-systemets IP-liste. Datafordeler afviser alle kald til adgangsbegrænsede registre fra adresser uden for listen.
4. Ansøg om adgang til de registre, I skal bruge, og afvent Datafordelers godkendelse.
5. I AgentBase: Organisation → Integrationer → Konfigurer. Indtast ClientId og adgangskoden, vælg registre, og gem.
6. Kør Test forbindelse.

Adgangskoden gemmes krypteret og vises aldrig igen. Ved senere redigering lader du feltet stå tomt for at beholde den gemte adgangskode.

Når oplysningerne er gemt, viser kortet status Konfigureret – ikke testet sammen med ClientId og de valgte registre:

Test forbindelse

Test forbindelse henter et rigtigt adgangstoken hos Datafordeler med de gemte oplysninger og gemmer resultatet som en kvittering på kortet ("Senest testet …"). Resultaterne betyder:

Status	Betydning	Næste skridt
Forbundet	Datafordeler udstedte et adgangstoken	Ingen — integrationen virker
Adgang afvist	ClientId eller adgangskoden blev afvist	Kontrollér begge dele, eller opret en ny adgangskode i Datafordeler Administration
IP ikke godkendt	Platformens IP-adresse mangler på IT-systemets IP-liste	Tilføj IP-adressen fra opsætningsguiden på IP-listen
Fejl ved seneste test	Netværksfejl eller uventet svar	Prøv igen; kontakt support hvis fejlen fortsætter
Konfigureret – ikke testet	Oplysninger gemt, men endnu ikke testet (vises også efter skift af adgangskode)	Kør Test forbindelse
Ikke konfigureret	Der er endnu ikke gemt oplysninger	Tryk Konfigurer. Knappen Test forbindelse er slået fra, indtil oplysningerne er gemt — kortet viser i stedet hintet "Udfyld ClientId og adgangskode først."

Bemærk: en grøn test bekræfter, at login virker. Adgangen til det enkelte register afhænger derudover af registrets godkendelse af jeres IT-system — mangler den, får flowet en forklarende fejl ved kørsel.

Hvad sker der i flows?

• Byggeklodserne Datafordeler og Ejendomsoverblik bruger automatisk organisationens adgang til de registre, der er slået til på integrationen — der skal ikke ændres noget i flowet.
• Vælger en bygger et adgangsbegrænset register (fx Ejere/EJF) uden at integrationen er sat op, får kørslen en klar fejl, der peger på Integrationer-siden — der sendes intet kald til Datafordeler.
• Er integrationen sat op, men registret ikke krydset af under Registre, fejler kørslen med: "Datakilden '<navn>' er ikke slået til for organisationens Datafordeler-adgang. Bed en administrator slå den til under Integrationer." Ret det ved at åbne kortets Rediger og sætte flueben ved registret.
• Fjernes integrationen, holder flows med adgangsbegrænsede registre op med at virke, indtil den sættes op igen. Åbne registre falder tilbage til platformens standardadgang.

Egne AI-nøgler: OpenAI, Azure OpenAI og Mistral

AgentBase' AI-byggeklodser (fx Sprogmodel, Strukturér output, Anonymisér) kører som standard på platformens adgang. Under Organisation → Integrationer kan organisationen i stedet indtaste sin egen API-nøgle til OpenAI og/eller Mistral — eller køre GPT-kald gennem organisationens egen Azure OpenAI-ressource (se nedenfor) — så afregnes organisationens AI-kald direkte på jeres egen konto hos leverandøren.

1. Opret en API-nøgle hos leverandøren (OpenAI: platform.openai.com → 'API keys'; Mistral: console.mistral.ai → 'API Keys'; Azure OpenAI: se nedenfor).
2. I AgentBase: Organisation → Integrationer → Konfigurer på OpenAI- eller Mistral-kortet. Indsæt nøglen, og gem.
3. Kør Test forbindelse — AgentBase kalder leverandørens modeloversigt med nøglen og gemmer resultatet som kvittering på kortet.

Status	Betydning	Næste skridt
Forbundet	Leverandøren accepterede API-nøglen	Ingen
Adgang afvist	Nøglen blev afvist eller mangler adgang til modeller	Kontrollér nøglen, eller opret en ny hos leverandøren
Fejl ved seneste test	Netværksfejl eller uventet svar	Prøv igen; kontakt support hvis fejlen fortsætter
Ikke konfigureret	Der er endnu ikke gemt en nøgle	Tryk Konfigurer. Knappen Test forbindelse er slået fra, indtil nøglen er gemt — kortet viser i stedet hintet "Udfyld API-nøglen først." (Azure OpenAI og Egen LLM-server nævner også endpointet)

Bemærk:

• Fjernes nøglen, falder organisationens flows tilbage til platformens standardadgang.
• Nøglen gælder sprogmodel-kaldene (byggeklodserne Sprogmodel, Strukturér output og Anonymisér) i alle kørsler af organisationens flows og apps — også webhooks, planlagte kørsler og indlejrede apps. AI-hjælpefunktioner på konfigurationssider (fx AI-genereret kode og dokumentstil) bruger fortsat platformens adgang.
• Dokument-OCR kører derimod altid på platformens adgang — også når organisationen har sin egen Mistral-nøgle.
• AgentBase genbruger cachede resultater for identiske kald; nye kald afregnes på organisationens egen nøgle.
• OpenAI: brug en standardnøgle — 'Admin'-nøgler (sk-admin-...) kan ikke kalde modeller. Mistral: nøglen skal være til api.mistral.ai (Codestral-nøgler virker ikke).
• Nøglen gemmes krypteret, kan aldrig hentes ud igen, og indgår aldrig i logs eller kørselshistorik. Skiftes nøglen — eller Azure-endpointet — nulstilles testkvitteringen.

Azure OpenAI

Med Azure OpenAI-integrationen sender AgentBase organisationens GPT-kald gennem jeres egen Azure OpenAI-ressource, så forbruget afregnes på jeres Azure-aftale.

Forudsætning: en Azure OpenAI-ressource i Azure-portalen. Endpointet står under Resource Management → Keys and Endpoint og har formen https://<ressource>.openai.azure.com (adresser på …cognitiveservices.azure.com accepteres også; Foundry-adresser på services.ai.azure.com understøttes ikke i denne version).

Deployment-navne: Azure kalder modeller gennem deployments, og AgentBase kalder deploymentet med præcis det modelnavn, byggeren har valgt. Opret derfor et deployment for hver GPT-model, I vil bruge, med navnet identisk med modelnavnet i AgentBase:

Modelnavn i AgentBase = deployment-navn i Azure
gpt-5.6-terra
gpt-5.6-luna

Udfasede modeller

gpt-5-mini, gpt-5.4-mini, gpt-4.1, gpt-5.2 og gpt-5.4 kan ikke længere vælges, og flows der stadig står med dem kører nu på gpt-5.6-luna. Har I tidligere kun oprettet deployments med de gamle navne, skal I oprette et gpt-5.6-luna-deployment, før de flows kan køre.

Konfigurer: Indtast endpointet uden sti (et indsat /openai/v1 eller en afsluttende skråstreg fjernes automatisk) samt KEY 1 eller KEY 2 fra samme side i Azure-portalen. Test forbindelse kalder …/openai/v1/models på jeres endpoint og bekræfter endpoint og nøgle — ikke at jeres deployments findes; et manglende deployment giver først en fejl, når modellen kaldes.

Forrang: er både Azure OpenAI og OpenAI konfigureret, har Azure forrang for GPT-kald; findes ingen af delene, bruges platformens standardadgang (egen LLM-server → Azure OpenAI → OpenAI-nøgle → platformens standardadgang). Mistral-kald påvirkes ikke.

Websøgning: Sprogmodel-kald med websøgning slået til kører via OpenAI (organisationens OpenAI-nøgle hvis sat, ellers platformens adgang) — Azure understøtter ikke AgentBase' websøgning.

Egen LLM-server (LiteLLM/vLLM)

Med Egen LLM-server sender AgentBase organisationens GPT-kald til en OpenAI-kompatibel server, I selv hoster — fx en LiteLLM-proxy eller vLLM. Det giver fuld kontrol over, hvilke modeller der faktisk svarer: serveren mapper selv AgentBase-modelnavnene til det, I kører bag den.

Forudsætninger:

• Serveren skal være tilgængelig på en offentlig https-adresse (AgentBase kalder den fra platformens servere). Interne og private adresser afvises ved opsætning.
• De servede modelnavne skal matche AgentBase-modellisten (gpt-5.6-terra, gpt-5.6-luna) — i LiteLLM via model_name i konfigurationen, i vLLM via --served-model-name. I vælger selv, hvilke modeller der ligger bag navnene.
• En API-nøgle til serveren (LiteLLM: en virtual key; vLLM: værdien fra --api-key).

Konfigurer: Indtast server-endpointet uden sti (fx https://llm.jeresdomæne.dk; en port som :8443 er tilladt, og et indsat /v1 fjernes automatisk) samt API-nøglen. Test forbindelse kalder serverens /v1/models med nøglen.

Forrang: egen LLM-server er det mest eksplicitte valg og har forrang over både Azure OpenAI og OpenAI for GPT-kald. Mistral-kald og websøgning kører ikke via egen server.

Én integration, flere teams

Har jeres organisation flere teams, kan et enkelt team køre på sin egen adgang, mens resten deler organisationens. Det gælder alle integrationerne på siden.

• Den nøgle, du gemmer på selve kortet, står under mærkatet Alle teams og bruges af alle teams.
• Vil ét eller flere teams have deres egen nøgle, trykker du Tilføj team-specifik adgang i blokken Teams med egen adgang (blokken vises kun, når organisationen har teams), sætter flueben ved de teams, det gælder, og indtaster oplysningerne. Hvert valgt team får sin egen adgang.
• Et team uden egen adgang arver automatisk organisationens fælles adgang.

Hvert team med egen adgang får sin egen række med Rediger, Test forbindelse og Fjern. Fjernelse falder tilbage i den rigtige retning:

• Fjerner du et teams egen adgang (Fjern i teamrækken), bruger teamet derefter organisationens fælles adgang. Øvrige teams er upåvirkede.
• Fjerner du organisationens fælles adgang (Fjern integration på kortet), beholder de teams, der har deres egen nøgle, deres.

To ting, der er lette at gå galt af

Det er flowets team, der afgør, hvilken nøgle en kørsel bruger — ikke den bruger, der starter den. Og en teamrække, der er gemt uden adgangskode, tæller ikke som egen adgang: det team bliver på organisationens fælles adgang.

Sikkerhed

• Adgangskoden opbevares krypteret og kan aldrig hentes ud igen via hverken brugerfladen eller API'et — den kan kun udskiftes eller slettes.
• Adgangskoden indgår aldrig i kørselslogs, hændelser eller kørselshistorik.
• Skiftes adgangskoden, nulstilles testkvitteringen, så status aldrig påstår noget om en adgangskode, der ikke findes længere.