For many years, organizations have relied on large documentation platforms to manage internal knowledge. Tools such as Confluence became the default location for everything from architecture documentation and operational runbooks to meeting notes and project knowledge.

However, as documentation grows, organizations often encounter the same challenges: information becomes fragmented, documents become difficult to locate, and valuable knowledge ends up scattered across multiple systems.

At the same time, advances in artificial intelligence have opened a new possibility: AI-assisted knowledge discovery.

Rather than storing everything in a single platform, many teams are now exploring how multiple specialized systems can be connected and made searchable through AI.

This approach creates a modular knowledge architecture where documentation, code, and files remain in their natural environments while AI provides a unified search interface.

The Core Idea

Instead of relying on one monolithic documentation system, knowledge can be distributed across several tools that each serve a specific purpose.

For example:

• a knowledge base for structured documentation
• a code repository for technical material
• a collaboration platform for files and documents

An AI assistant can then search across all of these sources using Retrieval Augmented Generation (RAG) and present relevant answers to users.

Conceptually, the architecture looks like this:

Users interact with an AI assistant, which retrieves information from multiple systems and generates responses based on internal documentation.

Typical components might include:

• BookStack for structured documentation (European alternative: XWiki, developed by a French company; strong enterprise wiki option)
• GitHub for code and technical documentation (European/self-hosted alternative: Gitea or GitLab CE; using GitHub is typically not a major concern if repositories are public documentation or contain non-sensitive material)
• Nextcloud for file storage and collaboration (European project headquartered in Germany, making it a strong option for organizations concerned about data sovereignty)
• AI models and vector search to enable semantic search across documentation

Together, these systems form a flexible knowledge ecosystem.

Structured Knowledge: The Documentation Layer

Structured documentation works best in a dedicated knowledge platform.

Tools such as BookStack provide a clear hierarchy for organizing knowledge:

Shelf → Book → Chapter → Page

For example:

Shelf: AI Strategy
Book: AI Governance
Chapters: Risk, Compliance, Model Lifecycle

Shelf: Application Management
Book: Robotics
Book: Incident Management
Book: Operational Runbooks

This structure makes it easy to maintain documentation such as:

• architecture overviews
• governance frameworks
• operational procedures
• onboarding documentation
• internal standards

BookStack is lightweight and easy to maintain. However, if an organization prefers a clearly European vendor ecosystem, XWiki is a strong alternative with enterprise-grade capabilities.

Technical Documentation and Code

Technical documentation often evolves alongside the codebase.

For this reason, many teams keep technical documentation directly in their code repositories.

A typical repository structure might look like:

/docs
architecture.md
ai-agent-architecture.md
sdlc-process.md

/src
/scripts
/config

This approach, often referred to as “documentation as code”, offers several benefits:

• version control
• transparent change history
• collaboration via pull requests
• easy automation through CI/CD pipelines

Many organizations use GitHub for this purpose (European/self-hosted alternatives include Gitea or GitLab CE; GitHub is often considered acceptable if repositories do not contain sensitive operational data and the organization values its ecosystem and developer tooling).

Files and Collaboration

Not all knowledge belongs in documentation pages.

Presentations, diagrams, spreadsheets, datasets, and reports still play an important role in everyday work.

A file collaboration platform such as Nextcloud works well for storing and sharing this type of content.

Typical folders might include:

AI
presentations
diagrams
datasets

Projects
project documents
meeting notes

Nextcloud is particularly interesting because it is an open-source platform developed in Europe and can be self-hosted, allowing organizations to maintain full control over their data.

For document editing within Nextcloud, tools such as Collabora Online (European alternative: ONLYOFFICE, developed by a company based in Latvia; Collabora itself is UK-based but widely used in sovereignty-focused deployments) can be integrated.

The AI Layer: Retrieval Augmented Generation

The key component that ties everything together is the AI search layer.

Using Retrieval Augmented Generation (RAG), an AI assistant can index content from multiple sources such as:

• documentation pages
• repository documentation
• file storage systems

When a user asks a question, the process typically works as follows:

1. The question is converted into a vector representation.
2. A vector database retrieves relevant documents.
3. These documents are provided as context to a language model.
4. The AI generates a response based on the retrieved information.

This approach allows the AI to answer questions using internal knowledge rather than general internet content.

A typical vector database might be Qdrant (European company based in Germany) or Weaviate (European alternative founded in the Netherlands).

Language Models

The language model itself can be chosen depending on organizational requirements.

Some organizations use OpenAI models (European alternatives include Mistral AI, based in France, or open models such as Llama; OpenAI is often acceptable for experimentation or non-sensitive use cases due to its maturity and ecosystem).

In environments with stronger sovereignty requirements, models can also be self-hosted.

Identity and Access

In larger environments, it is common to integrate identity and authentication services.

Typical solutions include:

• Keycloak (open-source identity platform originally developed in Europe)
• ZITADEL (Swiss identity platform with strong focus on modern identity architecture)

These systems support standard protocols such as OIDC and SAML, enabling secure integration across all components in the architecture.

The Result: A Unified Knowledge Interface

The result of this architecture is a knowledge environment where AI acts as the primary interface.

Instead of manually navigating different systems, users can simply ask questions.

The AI assistant retrieves relevant information from documentation, repositories, and file systems and presents the answer in context.

This approach offers several advantages:

• modular architecture
• flexibility in tool selection
• strong data ownership
• easier knowledge discovery
• reduced dependency on single-vendor platforms

Knowledge Management in the Age of AI

We are still early in the transition toward AI-assisted knowledge systems.

However, a clear pattern is emerging.

Modern knowledge architectures increasingly combine:

Knowledge Bases
+
Documentation as Code
+
AI-Powered Search

Traditional documentation platforms are not disappearing, but they are being complemented by a new layer: AI that helps people find and understand knowledge across systems.

In the long run, the way we interact with documentation may change significantly.

Instead of browsing through pages and folders, we will increasingly ask questions and let AI guide us to the answers.

The post Building an AI-Searchable Knowledge Platform appeared first on [x]olsen.

“Kunne man bruge avanceret teknologi til noget helt absurd?”

Det var sådan idéen til en AI-baseret undskyldningsgenerator opstod.

Inspirationen: Chris & Chokoladefabrikken

Hvis man er vokset op med dansk radiohumor, kender man måske sketch-universet omkring Chris & Chokoladefabrikken. Her ringer folk til deres chef med de mest vanvittige forklaringer på, hvorfor de ikke kan komme på arbejde.

En klassiker lyder nogenlunde sådan:

“Chef, jeg kan desværre ikke komme i dag, fordi der står et to meter højt ringbind uden for min dør.”

Forklaringen giver selvfølgelig ingen mening – men den bliver leveret med en seriøsitet, som næsten gør den troværdig.

Og det var netop dér min hjerne begyndte at arbejde.

Hvad hvis man kunne bygge en AI-agent, der genererer den perfekte undskyldning?

Ikke bare en tilfældig undskyldning – men en, der:

• virker plausibel
• er baseret på fakta
• passer til dagens situation
• aldrig gentager sig

Og nogle gange… er helt absurd.

Den tekniske udfordring

Selvom problemet er latterligt, er løsningen faktisk ret interessant.

En virkelig god undskyldning kræver kontekst. Den skal passe til virkeligheden.

Derfor forestillede jeg mig et system, der samler information fra forskellige kilder:

• vejrdata (DMI)
• trafikdata
• kalender og helligdage
• sygdomsstatistikker
• kulturelle begivenheder
• årstid og sæson

På den måde kan undskyldningen være både kreativ og plausibel.

For eksempel:

“Jeg kan desværre ikke komme ind på kontoret i dag.
DMI har udsendt varsel om kraftig sidevind i hovedstadsområdet, og statistisk set sker en stor del af cykelulykker netop i morgentrafikken under sådanne forhold.”

Eller – hvis systemet er i mere kreativt humør:

“Jeg kan ikke komme i dag, fordi der står et to meter højt ringbind uden for min dør.
Jeg har forsøgt at flytte det, men ringbindets masse og tyngdepunkt gør det til en logistisk opgave, som realistisk kræver mindst tre projektledere og en workshop.”

Når AI møder menneskelig kreativitet

Det interessante er, at en sådan generator faktisk illustrerer nogle centrale principper i moderne AI:

• kontekstbevidst generering
• data-integration
• memory og variation
• prompt engineering

Systemet skal nemlig også huske, hvilke undskyldninger der allerede er blevet brugt. Ellers bliver det hurtigt mistænkeligt.

Hvis man har brugt “trafikproblemer” fire gange på en uge, begynder selv den mest tålmodige chef at undre sig.

Derfor skal generatoren føre log over tidligere undskyldninger og aktivt variere sine forklaringer.

Den skjulte feature

Og her blev idéen endnu sjovere.

Hvad hvis arbejdsgiveren også kunne få adgang til systemet?

Ikke for at se medarbejdernes undskyldninger – men for at justere generatoren.

Forestil dig, at chefen kan skrue op for parameteren:

“Embarrassment level”

Så kunne en undskyldning pludselig blive:

“René kan desværre ikke komme på arbejde i dag.
Hans kalenderstyring kolliderede igen med virkeligheden.”

Eller:

“Forsinkelsen skyldes sandsynligvis en kombination af snooze-knappen og en optimistisk vurdering af morgenlogistik.”

Et seriøst eksperiment forklædt som humor

Det hele er selvfølgelig tænkt som humor.

Men faktisk illustrerer projektet noget ret interessant.

AI bliver ofte diskuteret i forhold til produktivitet, automatisering og effektivisering.

Men nogle gange kan man lære mindst lige så meget ved at bruge teknologien til noget helt absurd.

Fordi det tvinger os til at forstå:

• hvordan kontekst påvirker AI
• hvordan data kan berige generative modeller
• hvordan man designer agent-systemer

Og måske vigtigst:

Hvor langt vi egentlig er kommet med teknologien.

Konklusion

Jeg ved endnu ikke, om verden mangler en avanceret undskyldningsgenerator.

Men jeg er ret sikker på, at hvis man kan bygge den – så har man lært noget om AI undervejs.

Og hvis ikke andet, så har man i det mindste altid en god forklaring klar til sin chef.

Selv hvis der pludselig står et to meter højt ringbind uden for døren.

Undskyldningsgeneratoren – del 2

Hvordan man faktisk kunne bygge den

I første del beskrev jeg idéen om en AI-baseret undskyldningsgenerator inspireret af dansk radiohumor. En teknologi der kan generere alt fra plausible forklaringer til fuldstændig absurde historier om ringbind foran hoveddøren.

Men selv om idéen er humoristisk, er den tekniske udfordring faktisk ret interessant.

Hvis man skulle bygge en sådan løsning rigtigt, ville den i virkeligheden ligne en lille AI-platform, der kombinerer data, kontekst og generativ AI.

Den grundlæggende arkitektur

En simpel version kunne se sådan ud:

User request
      ↓
Context Collector
      ↓
Excuse Scenario Builder
      ↓
LLM Generator
      ↓
Excuse Log & Variation Engine

Systemet fungerer i fire trin.

1. Context Collector

Før AI-modellen genererer en undskyldning, indsamler systemet kontekstdata.

Det kan for eksempel være:

• vejret
• trafik
• kalender
• sæson
• sygdomsudbredelse
• aktuelle begivenheder

Pointen er, at undskyldningen ikke bare opfindes – den forankres i virkeligheden.

2. Scenario Builder

Derefter vælger systemet en forklaringskategori.

Eksempler kunne være:

Transport

• trafikuheld
• vejarbejde
• togforsinkelser

Helbred

• influenza
• migræne
• pollenallergi

Praktiske problemer

• håndværkere
• internetnedbrud
• tekniske problemer

Absurd kategori

• gigantiske ringbind
• printere i oprør
• logistiske paradokser

Scenario Builder bestemmer også et plausibility-niveau.

3. LLM Generator

Når konteksten er samlet, genererer en sprogmodel selve undskyldningen.

Prompten kan fx indeholde:

• brugerens navn
• relation (arbejde / familie / venner)
• kontekstdata
• plausibility-niveau
• tidligere brugte undskyldninger

Det sikrer variation.

4. Variation Engine

Et vigtigt element er historik.

Hvis man bruger samme forklaring flere gange, mister den troværdighed.

Systemet kan derfor logge hver undskyldning:

Excuse ID: E-2026-03-05-TRAFFIC-01
Category: Traffic
Plausibility: 82%
Target: Work

Generatoren undgår derefter at gentage lignende scenarier.

Datakilder og integrationer

For at gøre generatoren mere realistisk kan man integrere forskellige datakilder.

Vejr

Mulige API’er:

• DMI
• OpenWeather
• Meteostat

Eksempel:

DMI har udsendt varsel om kraftig vind i hovedstadsområdet.

Trafik

Mulige kilder:

• Google Maps Traffic
• TomTom Traffic
• Waze

Eksempel:

Trafikken på Motorring 3 er ifølge trafikdata tættere end normalt.

Kalender og helligdage

Eksempler på datakilder:

• Google Calendar
• Microsoft Graph
• Calendarific

Dette gør systemet opmærksom på:

• helligdage
• ferieperioder
• særlige begivenheder

Epidemiologi

Sygdomsdata kan hentes fra:

• Statens Serum Institut
• WHO
• CDC

Eksempel:

Influenzaaktiviteten i uge 10 er moderat ifølge SSI.

Kultur og begivenheder

Systemet kan også kende til:

• sportsbegivenheder
• festivaler
• strejker
• demonstrationer

Det giver undskyldninger, der føles realistiske.

Multi-agent idéen

Hvis man ville gøre systemet mere avanceret, kunne man opdele det i små specialiserede agenter.

For eksempel:

Weather Agent
Traffic Agent
Calendar Agent
Health Agent
Culture Agent
        ↓
Excuse Composer

Hver agent leverer kontekst til den centrale generator.

Det minder faktisk om arkitekturen i mange moderne AI-systemer.

Plausibility score

En sjov funktion er en realism score.

Eksempel:

Output kunne derfor se sådan ud:

Plausibility score: 73%

Den hemmelige arbejdsgiverfunktion

En af de mere satiriske funktioner er en skjult employer mode.

Her kan en chef justere systemets parametre.

For eksempel:

• maksimal plausibilitet
• variationskrav
• pinlighedsniveau

Hvis pinlighedsniveauet sættes højt, kunne generatoren producere noget i stil med:

René kan ikke komme på arbejde i dag, fordi hans tidsplan kolliderede med virkeligheden.

Hvorfor bygge noget så absurd?

Fordi sådanne projekter faktisk er gode til at demonstrere, hvordan moderne AI fungerer.

Selv en humoristisk undskyldningsgenerator illustrerer:

• kontekstberiget AI
• data-integration
• prompt engineering
• memory-systemer
• agent-arkitektur

Med andre ord: mange af de samme principper som i seriøse AI-projekter.

Konklusion

Det er muligt, at verden ikke har akut brug for en avanceret undskyldningsgenerator.

Men hvis man kan bygge en, har man sandsynligvis også forstået en del om moderne AI-systemer.

Og i værste fald har man altid en forklaring klar, næste gang man ikke kan komme på arbejde.

Selv hvis årsagen er et to meter højt ringbind foran døren.

The post Undskyld !!! – når avanceret AI løser et fuldstændig latterligt problem appeared first on [x]olsen.