In traditional CMS platforms, AI is usually added through plugins or external tools. In an AI CMS, artificial intelligence is built into the workflow and assists users throughout the entire content lifecycle.

What a Traditional CMS Is

A traditional CMS is used to:

• create and edit pages
• publish blog posts
• manage media files
• organize content structures
• control permissions and workflows

Examples include platforms like WordPress, Drupal, and Contentful.

These systems are primarily designed for manual content management.

What Makes an AI CMS Different

An AI CMS integrates machine learning and language models to assist with content creation, management, and optimization.

Typical AI capabilities include:

1. AI Content Generation

AI can help create content such as:

• blog posts
• product descriptions
• marketing copy
• summaries
• translations

This allows teams to produce content faster and experiment with different formats.

2. Intelligent Content Structuring

AI can help automatically:

• categorize articles
• generate tags
• build metadata
• organize content hierarchies

This improves searchability and content reuse.

3. SEO Optimization

AI systems can analyze content and suggest improvements such as:

• keyword optimization
• headline improvements
• readability adjustments
• internal linking suggestions

Some systems can even generate SEO metadata automatically.

4. Content Personalization

AI can help deliver different content to different users based on:

• behavior
• location
• preferences
• browsing history

This is often used in marketing and e-commerce platforms.

5. Knowledge Management

Some AI CMS platforms are designed to work as knowledge hubs, where AI can:

• search across documents
• summarize internal knowledge
• answer questions about company content

This is often implemented using RAG (Retrieval Augmented Generation).

Examples of AI CMS Platforms

Some platforms that integrate AI capabilities include:

• WordPress with AI plugins
• Notion AI
• HubSpot CMS
• Storyblok
• Contentful with AI integrations

Some newer platforms are designed specifically around AI workflows.

AI CMS vs Traditional CMS

When an AI CMS Is Useful

An AI CMS is especially useful when:

• a lot of content needs to be created regularly
• teams want to automate parts of the editorial workflow
• content needs to be reused across channels
• organizations want to build AI-powered knowledge systems

In Simple Terms

A traditional CMS helps you manage content.

An AI CMS helps you create, organize, and understand content using artificial intelligence.

The post AI CMS appeared first on [x]olsen.

Artificial intelligence is currently available in several different forms. Most people first encounter AI through ready-made services such as chatbots or productivity assistants, but under the surface there are several different ways to work with AI.

Broadly speaking, AI can today be used in three different ways:

1. AI Applications (ready-made tools)
2. Cloud AI Platforms (API-based AI services)
3. Local AI (running models on your own hardware)

Understanding the differences between these approaches helps explain why local AI has recently become so interesting.

AI Applications

The most common way people interact with AI today is through ready-made applications.

Examples include:

ChatGPT
Claude
Microsoft Copilot
Perplexity
Notion AI

European alternatives include:

Mistral Le Chat (France)
Aleph Alpha AI Assistant (Germany)

These tools are extremely easy to use. You simply open a website or application and start interacting with the model.

Advantages:

• extremely easy to use
• always running the newest models
• no installation required

Disadvantages:

• your data is processed in external systems
• limited customization
• usage costs may increase over time
• dependent on external providers

For many users these tools are perfectly sufficient, especially for everyday productivity tasks.

Cloud AI Platforms

A second category is AI platforms that provide models through APIs.

These are typically used by developers building applications.

Examples include:

OpenAI
Anthropic
Google AI Studio
Azure OpenAI

European alternatives include:

Mistral AI API (France)
Aleph Alpha API (Germany)

Advantages:

• access to powerful models
• scalable infrastructure
• easy integration into applications

Disadvantages:

• ongoing usage costs
• dependency on external providers
• potential compliance considerations depending on how data is processed

Many companies currently build AI products on top of these platforms.

Local AI

The third category is local AI, where models run directly on your own computer or servers.

In this approach you download the model and run it locally using specialized runtime software.

In other words, the AI runs inside your own environment.

This approach has become increasingly viable because:

• models have become more efficient
• open models are widely available
• local runtimes have become easier to use

Advantages:

• full data privacy
• no API costs
• complete control over infrastructure
• high flexibility for experimentation

Disadvantages:

• requires local hardware resources
• setup is slightly more technical
• models may not always match the largest cloud models

Despite these limitations, local AI is becoming increasingly attractive for developers, researchers, and organizations that want more control over how AI is used.

Choosing the Right Approach

Each of these approaches has its place.

AI applications are ideal for everyday productivity.

Cloud platforms are powerful for building scalable products.

Local AI is particularly useful when:

• data privacy matters
• you want full control over infrastructure
• you want to experiment with different models
• you want to avoid API costs

Because of this, many developers and organizations today combine several approaches.

For example:

• using ChatGPT for general tasks
• cloud APIs for production systems
• local models for experimentation and private workflows

The rest of this article focuses on how to run AI locally, and how to approach it from an EU-first perspective.

Running AI Locally: How to Install and Use Pre-Trained Language Models on Your Own Computer

For a long time, working with advanced AI models meant sending your data to cloud services. That is rapidly changing. Today it is entirely possible to run powerful language models directly on your own computer using open-source tools and pre-trained models that are publicly available.

This approach has several advantages: privacy, lower operating costs, full control of your data, and the ability to experiment freely without depending on external APIs.

In this article, we will walk through the basic ecosystem that makes local AI possible and explain how you can get started running large language models (LLMs) on your own machine.

The Model Libraries: Where the AI Comes From

The first thing you need is a trained model. Training large language models from scratch is extremely expensive, but thousands of high-quality models are already available.

The largest open repository of models is maintained by Hugging Face. It hosts hundreds of thousands of models for natural language processing, computer vision, speech recognition, and more.

Popular language models available today include:

• Llama
• Mistral
• Mixtral
• Phi
• Gemma

These models vary in size and capability. Some are small enough to run on a laptop, while others require more powerful hardware.

The Hugging Face model hub makes it easy to search, download, and experiment with these models.

(EU-first alternatives include the open-source model catalog maintained by LAION and models distributed through Aleph Alpha or Mistral AI.)

Running Models Locally

Once you have chosen a model, you need a runtime environment that can load and execute it on your computer.

One of the most popular tools for this today is Ollama.

Ollama acts as a local runtime for language models. It downloads the model, manages its dependencies, and exposes a simple command interface for running and interacting with the AI.

A typical command might look like this:

ollama run llama3

This command downloads the model and launches a local chat session directly on your machine.

Ollama supports many well-known models such as:

• Llama
• Mistral
• Mixtral
• Phi

Because everything runs locally, no data leaves your computer.

(EU-first alternatives include LocalAI (Italy), Text Generation WebUI (international open-source community), and Jan.ai (open-source desktop runtime developed outside major US cloud ecosystems).)

A User Interface for Local AI

While command-line tools are powerful, many users prefer a graphical interface.

LM Studio is one of the most user-friendly desktop applications for working with local language models.

It provides:

• A model browser
• One-click downloads
• A chat interface
• Local API endpoints compatible with OpenAI-style integrations

With LM Studio, you can browse thousands of models and start experimenting with them without writing any code.

(EU-first alternatives include GPT4All by Nomic (open-source community) and Jan.ai, which focuses on privacy-first local AI workflows.)

Creating a ChatGPT-Style Interface

Once you are running models locally, the next step is often to create a richer interface for interacting with them.

Open WebUI is an open-source project that provides a full ChatGPT-style experience for local models.

It supports features such as:

• Multiple models
• Document uploads
• Retrieval-augmented generation (RAG)
• Prompt templates
• Agents and workflows

This allows you to turn a local model into a private AI assistant or internal knowledge system.

(EU-first alternatives include LibreChat (open-source project with contributors across Europe) and Flowise (community-driven visual LLM orchestration framework).)

A Typical Local AI Stack

A common setup for running AI locally today looks something like this:

Application Interface
→ Open WebUI or LM Studio

Model Runtime
→ Ollama or LocalAI

Language Model
→ Llama / Mistral / Phi

Hardware
→ Your local CPU or GPU

Optionally, you can add a vector database for document search and retrieval:

• Chroma
• Weaviate (EU-first alternative – Netherlands)
• Qdrant (EU-first alternative – Germany)

This architecture enables advanced capabilities such as:

• Private knowledge bases
• AI-assisted documentation
• Software development assistants
• Internal copilots for organizations

All running entirely on your own infrastructure.

Hardware Requirements

Running AI locally does not necessarily require a powerful server.

Many modern models can run on:

• A modern laptop
• Apple Silicon machines
• Workstations with consumer GPUs

For example:

• 7–8B parameter models often run well on laptops
• Larger models benefit from GPUs and more RAM

Quantized models make it possible to run surprisingly capable AI systems even on modest hardware.

Why Local AI Matters

Running AI locally is not only a technical curiosity. It represents a broader shift in how organizations and individuals can use artificial intelligence.

Local models provide:

• Data sovereignty
• Lower long-term cost
• Full customization
• Independence from external cloud providers

For experimentation, prototyping, and internal tooling, local AI has become an increasingly attractive option.

It allows developers, researchers, and curious technologists to explore the capabilities of modern AI systems while keeping full control of their infrastructure.

Final Thoughts

The barrier to experimenting with AI has never been lower. With tools such as Ollama, LM Studio, and open model repositories, anyone can run sophisticated language models locally.

Whether your goal is to build a personal AI assistant, experiment with new ideas, or create internal tools for your organization, the local AI ecosystem now provides everything you need to get started.

And perhaps most importantly: it allows you to explore AI on your own terms.

Running AI Locally: An EU-First Guide to Installing and Using Language Models on Your Own Computer

For years, most AI systems required sending data to cloud services operated by large technology providers. That model is now changing. Today it is increasingly possible to run powerful language models directly on your own computer.

Running AI locally provides several advantages:

• stronger data control
• improved privacy
• lower long-term operating costs
• independence from cloud vendors
• the ability to experiment freely

In this article we will explore how to run large language models (LLMs) locally using an EU-first approach. That means prioritizing tools and models from Europe or open ecosystems that support European compliance requirements such as local hosting, transparency, and portability. When no strong EU option exists, we consider global open-source tools. US solutions are treated as a last option, unless they are open, portable, and easy to replace.

The Model Libraries: Where the AI Comes From

The first thing you need is a trained language model.

Training large models requires enormous compute resources, but fortunately thousands of high-quality models are already available. These can be downloaded and executed locally.

A widely used model library is Hugging Face, which hosts hundreds of thousands of models across many AI domains.

(US-based platform, but widely used in Europe and fully compatible with local execution and EU-compliant hosting workflows.)

However, if we take an EU-first perspective, several European ecosystems are becoming increasingly important.

EU-first model ecosystems

Mistral AI (France)
One of the strongest European players developing open and semi-open language models.

Examples:

• Mistral 7B
• Mixtral
• Codestral

These models are widely used and designed to run locally or in private infrastructure.

Aleph Alpha (Germany)
Provides European LLMs designed specifically with European governance and compliance frameworks in mind.

These models are often used in regulated sectors such as government and finance.

LAION (Germany)
A non-profit research organization responsible for large open datasets and open AI initiatives.

They help maintain parts of the open AI ecosystem that make independent AI development possible.

US-based but portable model ecosystems (US-last fallback)

Some models come from US organizations but are still compatible with EU-first architecture because they can be:

• run locally
• hosted privately
• replaced easily

Examples include:

• Llama (Meta)
• Phi (Microsoft)
• Gemma (Google)

Because these models can run locally without sending data to external services, they remain viable within an EU-compliant architecture.

Running Models Locally

Once you have a model, you need a runtime engine capable of executing it on your computer.

Several tools exist for this.

EU-first runtime options

LocalAI (Italy)
A fully open-source AI runtime designed as a drop-in replacement for OpenAI APIs. It allows you to run models locally or on private servers without relying on external cloud services.

Text Generation WebUI (global open-source project)
A flexible interface widely used for running open models locally. It supports multiple backends and model formats.

Global open-source runtimes

Jan.ai
A privacy-focused desktop AI assistant designed to run models locally.

The application provides a user interface for downloading models and running them without external dependencies.

US-origin but widely used runtimes (US-last fallback)

Ollama
A very popular runtime for running language models locally.

It simplifies model downloads and execution and works well for development and experimentation.

Because Ollama runs models locally and does not require cloud APIs, it can still be used within EU-compliant environments.

A Graphical Interface for Local AI

Many users prefer a graphical interface rather than command-line tools.

A popular tool for this purpose is LM Studio, which allows users to browse models, download them, and interact with them locally.

Features include:

• graphical model management
• local chat interface
• OpenAI-compatible API
• simple model switching

(US-developed but locally executed and easily replaceable.)

EU-friendly alternatives

GPT4All
An open project designed to make local AI easy to use. It focuses on running models privately on personal computers.

Jan.ai
Also functions as a desktop AI assistant and provides a privacy-first user interface for interacting with local models.

Creating a ChatGPT-Style Interface

Once a model is running locally, many users want a richer interface that can interact with documents and internal knowledge sources.

One of the most popular tools for this is Open WebUI.

It provides:

• multi-model chat
• document ingestion
• retrieval-augmented generation (RAG)
• prompt templates
• workflow automation

This makes it possible to build a private AI assistant or internal knowledge platform.

EU-first alternatives

Flowise (open-source)
A visual builder for AI workflows that allows organizations to build AI pipelines and RAG systems.

LibreChat
An open-source interface that supports multiple LLM providers and local deployments.

Building an EU-Friendly Local AI Stack

A typical architecture for local AI might look like this:

Interface Layer
→ Open WebUI / Flowise / Jan.ai

Model Runtime
→ LocalAI / Ollama

Language Models
→ Mistral / Mixtral / Aleph Alpha models

Hardware
→ Local GPU or CPU

Optional components:

Vector database for document search:

• Weaviate (Netherlands)
• Qdrant (Germany)
• Chroma (US open-source but easily replaceable)

This architecture supports:

• private knowledge bases
• internal AI assistants
• document analysis
• software development copilots

All without relying on external AI services.

Hardware Requirements

Running AI locally does not necessarily require expensive infrastructure.

Many modern language models can run on:

• modern laptops
• Apple Silicon computers
• workstations with GPUs

Typical guidelines:

• 7B–8B models run well on laptops
• larger models benefit from GPUs and more RAM

Quantized versions of models allow surprisingly capable systems to run even on modest hardware.

Why an EU-First Approach Matters

As AI becomes embedded in everyday tools, questions about data sovereignty, compliance, and technological independence become increasingly important.

An EU-first architecture helps ensure that:

• data stays under your control
• infrastructure can be hosted locally
• components can be replaced easily
• systems remain compliant with European regulations

By prioritizing open models and locally hosted tools, organizations can experiment with AI while maintaining flexibility and independence.

Final Thoughts

Running AI locally is no longer limited to researchers or large companies. With the growing ecosystem of open models and lightweight runtimes, anyone can experiment with advanced language models on their own machine.

By combining:

• European AI initiatives
• open-source infrastructure
• portable runtimes

it is possible to build powerful AI systems that remain transparent, compliant, and under your control.

In many ways, local AI represents a shift toward a more decentralized and open AI ecosystem—one where innovation does not depend on a handful of centralized providers.

The Model Libraries: Where the AI Comes From

All components can be run locally or on private infrastructure.

Hardware Requirements

Typical local setups:

Laptop / MacBook (16-32GB RAM)
→ small models (3B–8B)

Workstation with GPU
→ medium models (7B–30B)

Server GPUs
→ large models (70B+)

Running locally usually means no API costs, only electricity and hardware resources.

The post Local AI appeared first on [x]olsen.

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.

One of those completely ordinary grey Tuesdays happened.

You know the kind.

You wake up.
You look outside.
The sky is grey.
You open your laptop.
The news feed is full of two things:

• companies rolling back remote work in the name of “culture” and “innovation”
• AI supposedly replacing half the workforce within the next five minutes.

At that exact moment I had to go to the office.

And I had a very practical question.

Where should I sit today?

Normally the answer is simple:

• sit where you always sit
• grab the nearest free desk
• or walk around awkwardly pretending to look for someone.

Instead, a slightly absurd idea appeared in my head:

What if an AI agent decided where I should sit every day?

Not randomly.

Not habitually.

But based on rules, fairness, social dynamics, and a little bit of chaos.

Using amazing Technology to solve a Ridiculous Problem

Right now we live in a time where AI is often presented as:

• the ultimate productivity tool
• the solution to every business problem
• the replacement for knowledge workers

Meanwhile companies want employees back in the office to “rebuild culture”.

So I thought:

What if I used AI to do something that actually contributes to culture?

Not automation.

Not efficiency.

Just something playful.

Something that makes people laugh a bit when they arrive.

Something that makes people talk.

The Idea: An AI Seating Agent

The idea became a small experiment.

I created an AI agent (LLM-based agent) that would recommend which desk I should sit at every day.

But it shouldn’t just be random.

The agent should consider things like:

• fairness
• seat quality
• colleague preferences
• social dynamics

And most importantly:

it should explain its reasoning.

This is actually one of the things modern LLM agents are very good at:

transparent reasoning (chain-of-thought style reasoning / explainability)

The agent would therefore act as:

• a decision system
• a game
• a social experiment

Version 1 – Just Rotation

The first version was extremely simple.

The agent just calculated a deterministic seat based on the date.

Why?

Because fairness requires some kind of baseline rule.

So the agent calculates Day Of Year (DOY).

Example:

4 March → Day 63 of the year

Then it maps the day to a seat number:

BaseSeat = ((DOY - 1) mod 12) + 1

This is just modular arithmetic (modulo distribution).

If there are 12 desks, the rotation will cycle through them across the year.

So every day starts with a base seat recommendation.

This is the deterministic baseline (deterministic rule system).

Version 2 – The Agent Becomes Opinionated

Rotation alone is boring.

So I added scoring rules (heuristic scoring model).

Each seat would receive a score based on different factors.

Example factors:

Rotation score

How close the seat is to the base rotation.

Window score

Some desks are simply better.

Window seats in our office:

1, 3, 7, 9, 11

Premium seats

Corner desks.

1 and 11

Colleague preferences

Some colleagues love specific desks.

For example:

• Henrik loves seat 11
• Rohan prefers 12
• Jens prefers 3
• Sus prefers 1

So if the agent gives someone their preferred seat, it increases something I called:

Team Harmony Score (social optimization heuristic).

Version 3 – Logging Everything

At this point the agent started to become more interesting.

Because it logs every decision.

Whenever I sit down I confirm with a small command:

4=ok

The agent logs:

This creates a history dataset (interaction log).

From this data the agent can calculate different indicators.

Version 4 – Social Metrics

Now things started getting fun.

Instead of only optimizing seats, the agent started tracking social indicators.

For example:

Seat Coverage Score

How many different seats someone actually uses.

SCS = unique seats used / 12

This prevents people from claiming territory.

Window Hogging Index

Measures how often someone takes attractive window seats.

WHI = window seats last 10 days / 10

Corner Premium Index

Tracks usage of the best desks.

CPI = premium seats last 10 days / 10

Neighbor Disruption Score

This one was slightly more mischievous.

If you sit in the same area repeatedly, you might annoy the same colleagues.

So the agent calculates seat zones:

{seat-1, seat, seat+1}

If you sit in the same zone repeatedly, your Neighbor Disruption Score increases.

Version 5 – The Cake Algorithm

This is where things became slightly ridiculous.

The agent calculates an Irritation Risk Score.

IRS = 3*CPI + 2*WHI + NDS + (1 - SCS)

Which roughly means:

• hog premium seats
• sit near the same colleagues
• don’t rotate enough

…and your irritation score increases.

If the score becomes too high the agent suggests:

Cake Due

Meaning:

You should bring cake.

Or snacks.

Or coffee.

This introduces something I call:

Goodwill Balance (social credit / reciprocity metric)

Certain actions increase goodwill:

cake=ok
snacks=ok
coffee=ok

These restore the balance.

Version 6 – Gamification

At this point the experiment started drifting into game design territory.

Ideas started appearing:

• bribing a colleague for a seat
• coolness points
• department leaderboards
• wellbeing rewards
• team events

Imagine:

If the whole department participates, the system becomes a tiny social game.

For example:

• points for sitting on unpopular desks
• bonus points for coming early
• bonus points for sitting during quiet hours
• bonus points for helping someone else

This is essentially lightweight gamification (behavioral incentive design).

Version 7 – Sensor Integration

Then I had another thought.

Many modern offices already know which desks are occupied.

Desk booking systems.

Seat sensors.

Badge data.

Imagine feeding that data into the agent.

Now the system could detect:

• which desks are usually free
• peak hours
• collaboration patterns

Meaning the seat agent could become a real optimization system (agentic decision system).

Prompts vs Instructions vs Agents

Along the way I learned something interesting about working with LLMs.

There are actually several layers involved.

Prompt

A single instruction you send to the model.

Example:

“Recommend a desk for today.”

System instruction

A persistent rule set describing how the model should behave.

Example:

“You are DeskRota, an office seating agent.”

Agent

A system where the model:

• maintains memory
• logs actions
• applies rules
• evolves over time

This is what DeskRota became.

A small agent-based decision system.

Which Tools Would You Use for Something Like This?

One of the slightly amusing aspects of this little experiment is that it uses very powerful technology to solve a completely trivial problem.

And that’s actually part of the point.

Most people meet AI through grand narratives:

• enterprise transformation
• massive productivity gains
• autonomous systems
• replacing entire job categories

But the best way to understand these tools is often to play with small, harmless problems.

Like deciding where to sit in the office.

So if you look at something like the DeskRota example, it’s actually a nice mental model for understanding what different AI tools are good at.

Not academically.

But practically.

ChatGPT / OpenAI

In my case the entire experiment was built using the paid version of ChatGPT with a Custom GPT.

That means:

• I created a persistent system instruction (system prompt)
• The model keeps a memory of the conversation (session context)
• It behaves like a small agent with rules

This is probably the simplest way to experiment with AI agents today.

You don’t need infrastructure.

You don’t need APIs.

You don’t need code.

Just a good instruction.

And curiosity.

If you wanted to extend this in the OpenAI ecosystem you could imagine:

• OpenAI Assistants / Agents API
  (for building a persistent agent with structured memory)
• Function calling / tool use
  (for connecting the agent to systems like desk booking)
• RAG (Retrieval Augmented Generation)
  (for letting the agent read company policies or seating maps)

But for experimentation, a Custom GPT is perfectly sufficient.

Which is exactly what I used.

Microsoft AI Ecosystem

If you look at the same idea from the Microsoft ecosystem, different tools would play different roles.

Copilot Studio

Copilot Studio is essentially designed for building conversational agents (low-code AI agents).

A DeskRota agent could easily live here.

Typical uses would be:

• creating a chat-based office assistant
• integrating with Microsoft Teams
• connecting to Power Platform data
• retrieving desk availability from internal systems

In other words:

Copilot Studio is perfect when you want to turn an idea like this into a real workplace tool.

GitHub Copilot

GitHub Copilot is something very different.

It’s primarily a coding assistant (AI pair programmer).

So in the DeskRota example it would be useful if you wanted to:

• write the backend service
• build a seat allocation API
• connect to sensor systems
• integrate with desk booking systems

In short:

Copilot helps you build the system, not run it.

Copilot for Tasks / Automation

Another interesting direction would be task agents (AI task automation).

For example:

An agent that:

• checks desk availability
• assigns seats
• sends a Teams message
• updates a log

This is the kind of scenario where tools like Copilot for automation workflows or Power Automate with AI become useful.

Here the AI is not just answering questions.

It is triggering actions across systems.

Why Playing With Small Ideas Matters

The interesting thing about AI is that the learning curve is often backwards.

People think they need a big idea.

A big project.

A big transformation.

But in reality the best way to learn is to start with something slightly ridiculous.

Something small.

Something playful.

Because once you understand how these tools behave in a small system, you can suddenly see:

• where Copilot Studio fits
• where GitHub Copilot fits
• where automation agents make sense
• where LLM agents like ChatGPT are sufficient

And you begin to think differently.

Not just about what AI can replace.

But about what AI can make slightly more interesting.

Even something as simple as:

deciding where to sit on a grey Tuesday morning.

The Unexpected Insight

What started as a joke actually revealed something interesting.

We talk a lot about AI replacing workers.

But many of the things that make workplaces work are deeply human:

• humor
• fairness
• shared rituals
• small acts of generosity

Ironically, AI can help facilitate those things.

Not by replacing us.

But by creating small structures around social interaction.

The Final Agent

The current version of DeskRota now:

• calculates a daily seat
• logs every seating decision
• tracks multiple social indicators
• detects overuse of premium desks
• recommends social initiatives
• supports multiple participants
• evolves through prompts and rules

And most importantly:

It makes a completely ordinary office morning slightly more interesting.

Try It Yourself

If you want to try building your own seating agent, I’ve published the full instruction set here:

Copy it into any AI agent system and start experimenting.

Who knows.

Maybe the next time someone asks you:

“Where should I sit?”

The answer will be:

“Let’s ask the agent.”

The post The AI That Decided Where I Should Sit appeared first on [x]olsen.

Indledning – præmissen

AI er ikke længere et eksperiment.
Low-code, no-code og agentbaserede løsninger gør det muligt at automatisere processer, bygge beslutningsstøtte og orkestrere arbejdsgange – uden klassisk softwareudvikling.

ROI’en er tydelig. Hastigheden er reel.

Men i takt med at vi demokratiserer udvikling, opstår et nyt spørgsmål:
Hvordan sikrer vi, at innovation ikke løber fra governance?

For at udfordre mine egne antagelser har jeg haft en faglig samtale med min AI Navigator Agent. Ikke for at få simple svar – men for at teste kompleksiteten i det, vi er i gang med at bygge.

Det, der følger, er en dialog om low-code AI, agentarkitektur og organisatorisk ansvar.

1. Demokratisering eller forskydning af kompleksitet?

Jeg:
Low-code AI lover jo en enorm ROI. Vi kan bygge løsninger i fx Microsoft Copilot Studio eller orkestrere flows via LangChain uden at skrive traditionel kode. Er det ikke bare en sund demokratisering?

AI Navigator:
Jo – men demokratisering fjerner ikke kompleksitet. Den flytter den.

Da Ward Cunningham introducerede begrebet teknisk gæld, beskrev han, hvordan hurtige løsninger skaber fremtidig kompleksitet. Low-code AI reducerer initial kode, men øger systemisk kompleksitet:

• Logik ligger i prompts
• Data afhænger af eksterne modeller
• Adfærd kan ændre sig ved modelopdateringer
• Integrationer er skjulte i workflows

Vi kan kalde det model debt eller agent debt.

Det er ikke et argument mod innovation – men for arkitektonisk bevidsthed.

Litteratur & referencer:

• Ward Cunningham – Technical Debt
• Microsoft Copilot Studio
• LangChain

2. Shadow IT eller noget mere?

Jeg:
Er det her ikke bare en gentagelse af det, Gartner kaldte Shadow IT? Forretningen bygger selv løsninger.

AI Navigator:
Shadow IT var ofte passive systemer – regneark, SaaS-værktøjer, lokale databaser.

AI-agenter handler.
De træffer beslutninger.
De ændrer processer dynamisk.

Når citizen developers bygger agenter uden central registrering, opstår det, vi kunne kalde Agent Sprawl:

• Uregistreret automatisering
• Uformelle datakilder
• Manglende versionering
• Uklart procesansvar

Forskellen er, at vi går fra “skygge-systemer” til “skygge-beslutningssystemer”.

Det ændrer risikoprofilen markant.

Litteratur & referencer:

• Gartner – Citizen Development & Shadow IT
• Citizen Developer-begrebet

3. Governance i en verden af black-box agenter

Jeg:
Hvis modellen bag en agent opdateres uden vores kontrol, mister vi så ikke determinismen i vores processer?

AI Navigator:
Det er netop governance-udfordringen.

I klassisk software kan man fryse en version.
I AI-systemer kan adfærden ændre sig, selv uden kodeændring.

Derfor har organisationer brug for:

• Model version pinning
• Prompt versionering
• Audit logging
• Human-in-the-loop

Det er også her, rammer som National Institute of Standards and Technology AI Risk Management Framework bliver relevante. Frameworket arbejder med dimensionerne:

• Govern
• Map
• Measure
• Manage

Tilsvarende stiller EU AI Act krav om dokumentation, risikoklassificering og menneskelig kontrol.

Spørgsmålet er ikke, om vi skal bruge agenter – men om vi kan dokumentere dem.

Litteratur & referencer:

• National Institute of Standards and Technology – AI RMF
• EU AI Act

4. Når agenter overvåger agenter

Jeg:
Vi taler allerede om validator-agenter og policy-agenter. Men risikerer vi ikke bare at bygge lag på lag af kompleksitet?

AI Navigator:
Multi-agent-arkitektur er allerede en realitet i frameworks som AutoGen og CrewAI.

Strukturen kan se sådan ud:

• Operativ agent
• Validator-agent
• Compliance-agent
• Audit-agent

Det øger robustheden – men også kompleksiteten.

Organisationer skal derfor tænke i:

• Klar ansvarsfordeling
• Central registrering af agenter
• Fallback-mekanismer
• Kill-switch princip

Ellers bevæger vi os fra innovation til systemisk sårbarhed.

Litteratur & referencer:

• AutoGen
• CrewAI
• Multi-agent system theory

5. Geopolitik og AI supply chain risk

Jeg:
Hvis vores kritiske processer kører på amerikanske API’er og proprietære modeller, har vi så i praksis outsourcet beslutningskraft?

AI Navigator:
Det er en strategisk dimension, der ofte overses.

Afhængighed af:

• Cloud-infrastruktur
• Proprietære modeller
• Eksterne API’er

skaber det, man kunne kalde AI Supply Chain Risk.

Det handler ikke om at være anti-cloud.
Det handler om:

• Exit-strategier
• Reproducerbarhed
• Dokumenterede data foundations
• Arkitektonisk modularitet

Robust innovation kræver valgmuligheder.

Litteratur & referencer:

• AI supply chain security research
• Vendor lock-in teori
• Cloud governance best practices

6. Innovation uden naivitet

Jeg:
Så vi skal altså ikke bremse innovationen – men professionalisere den?

AI Navigator:
Præcis.

Low-code AI er ikke problemet.
Manglende governance er.

Organisationer bør arbejde med:

• Central agent registry
• Versioneret prompt repository
• Databaser med klar datamodel
• Regelmotorer, der supplerer LLM’er
• Compliance tagging (#GDPR #Finance #HR #HighRisk)
• Arkitektur-review før produktion

Det er ikke innovationshæmmende.
Det er innovationsmodnende.

Afsluttende refleksion

Jeg er ikke skeptisk over for AI.

Tværtimod.

Jeg ser low-code og agentbaserede løsninger som en enorm mulighed for organisatorisk acceleration.

Men jeg ser også, at vi står midt i en arkitektonisk overgang:

Fra applikationer
til beslutningssystemer.

Fra kode
til orkestreret intelligens.

Spørgsmålet er ikke, om vi skal slippe AI-agenter løs.
Spørgsmålet er, om vi kan gøre det med samme professionalisme, som vi forventer af klassisk softwarearkitektur.

Måske er den vigtigste AI-kompetence ikke at bygge agenter.
Måske er det at kunne styre dem.

Referencer og links

I nedenstående lidt inspiration til nogle af ovenstående emner.

1⃣ Klassisk litteratur om Shadow IT

Haag & Eckhardt (2017) – The Emergence of Shadow IT

Haag, S., & Eckhardt, A. (2017).
“Shadow IT: A literature review and research agenda.”
Business & Information Systems Engineering.

Denne artikel er en af de mest citerede akademiske gennemgange af Shadow IT.
Den analyserer:

• Hvorfor medarbejdere omgår IT-afdelingen
• Innovation vs. governance
• Kontroltab
• IT consumerization

Behrens (2009) – Shadow Systems

Behrens, S. (2009).
“Shadow systems: The good, the bad and the ugly.”
Communications of the ACM.

En klassisk artikel om uofficielle systemer i organisationer.

Gartner – Citizen Development & Shadow IT

Gartner har gennem mange år analyseret:

• Citizen Developer-bevægelsen
• Shadow IT
• IT consumerization

Relevante rapporter:

• “Create a Governance Framework for Citizen Development”
• “How to Control Shadow IT”

(Adgang kræver ofte abonnement, men bruges bredt i enterprise-sammenhæng.)

2⃣ Shadow AI – nyere forskning og analyser

Begrebet Shadow AI er nyere og endnu ikke fuldt akademisk konsolideret, men anerkendte institutioner har publiceret analyser.

MIT Sloan Management Review – Generative AI Governance

MIT Sloan Management Review

Flere artikler fra 2023–2024 om:

• Generative AI governance
• Uautoriseret brug af ChatGPT i virksomheder
• Policy design

Harvard Business Review – Shadow AI

Harvard Business Review

Artikler om:

• Employee use of generative AI without approval
• Governance challenges
• Responsible AI implementation

Søg på:
“Shadow AI in the enterprise”

IBM Institute for Business Value – AI Governance Reports

IBM

Har publiceret analyser om:

• Enterprise AI risk
• AI governance maturity
• Trust & transparency

3⃣ AI Governance Frameworks (relevant til Shadow AI)

NIST AI Risk Management Framework

National Institute of Standards and Technology

Den mest citerede offentlige governance-ramme for AI.

Direkte link:
https://www.nist.gov/itl/ai-risk-management-framework

EU AI Act

EU AI Act

Relevant ift. dokumentation, risikoklassificering og human oversight.

Officiel side:
https://artificialintelligenceact.eu/

ISO/IEC 42001 – AI Management Systems

ISO

Standard for AI management systems.
Relevant ift. formaliseret governance.
https://www.iso.org/standard/81230.html

4⃣ Socioteknisk teori & organisatorisk kompleksitet

Hvis du vil løfte dit indlæg teoretisk:

Conway’s Law

Melvin Conway

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

Principal–Agent Theory

Klassisk økonomisk teori (Jensen & Meckling, 1976).
Relevans:
Ledelse vs. medarbejder-incitamenter i Shadow IT / AI.

Sociotechnical Systems Theory

Trist & Emery (1960’erne).
Vigtigt perspektiv på:

• Samspillet mellem teknologi og organisation
• Utilsigtede effekter ved teknologisk acceleration

5⃣ Multi-Agent Systems (relevant til agent-lag)

Wooldridge, M. (2009)

“An Introduction to MultiAgent Systems”

En klassiker i agent-teori.

Frameworks

• AutoGen
• CrewAI
• LangChain

The post En samtale om AI appeared first on [x]olsen.

I lang tid vidste jeg godt, at mit digitale setup var blevet fragmenteret. Filer ét sted. Backups et andet. Kommunikation et tredje. Clouds hist og her.
Ikke fordi det var gennemtænkt – men fordi det var nemt. Og netop nemhed er ofte den største fjende af overblik.

Alligevel gik der lang tid, før jeg tog fat i en reel konsolideringsproces. Ikke fordi jeg manglede viden – men fordi processen føltes uoverskuelig. Det virkede jo. Tingene var tilgængelige. Intet brændte. Indtil jeg begyndte at stille nogle andre spørgsmål.

Et økosystem, der var større, end jeg egentlig havde overblik over

Ud over de klassiske cloud-tjenester brugte jeg også en række værktøjer, der hver især håndterer data på mere indirekte – og ofte mindre synlige – måder:

• Kreative platforme inden for video, billeder, musik eks. logic pro, adobe og diverse video og ai tools
• Planlægnings- og samarbejdsværktøjer Office, Design, Miro og Trello (idéer, flows, kundedata, strategi)
• Et voksende antal AI-tjenester, hvor input, output og kontekst ofte gemmes, genbruges eller trænes videre på

Det var her, det gik op for mig, at konsolidering ikke kun handler om filer – men om kontrol over data, kontekst og fremtidig anvendelse.

Når “det virker” ikke længere er godt nok

Det sværeste var ikke teknikken. Det var at erkende, at “det fungerer” ikke nødvendigvis betyder “det er fornuftigt”.

Jeg sad med:

• Services spredt på tværs af jurisdiktioner
• Afhængighed af leverandører, jeg reelt ikke havde kontrol over
• En voksende mængde data, som betød mere for mig, end jeg havde lyst til at indrømme

Og samtidig en verden, der ikke længere føltes stabil nok til bare at ignorere det.

Geopolitik, compliance og ubehagelige erkendelser

Geopolitiske spændinger, ændrede lovgivninger, cloud acts, sanktioner, leverandørlukninger – alt sammen noget, der tidligere føltes abstrakt, men som pludselig blev meget konkret.

Jeg begyndte at tænke i:

• Datasuverænitet
• GDPR og compliance – ikke som buzzwords, men som praksis
• Hvad der sker, hvis en tjeneste forsvinder, ændrer vilkår eller bliver utilgængelig

Ikke af paranoia – men af ansvar.

Økonomi og features: det skjulte regnestykke

Noget af det mest overraskende var økonomien.

Små månedlige abonnementer løber. Ekstra storage her. Premium der. Backup ovenpå backup.

Samtidig opdagede jeg, at mange nyere løsninger – især europæiske og open source-baserede – havde:

• Funktioner, jeg manglede i de gamle
• Bedre integrationsmuligheder
• Mere gennemsigtige prismodeller

Konsolidering viste sig ikke kun at være et sikkerhedsprojekt – men også et økonomisk oprydningsprojekt.

Genvinding af kontrollen: NAS, hardware og arkitektur

Et afgørende skridt blev at genoverveje lokal infrastruktur.

At tage NAS-servere alvorligt igen.
Ikke som nostalgisk on-prem romantik – men som en del af en hybrid arkitektur:

• Lokalt, hvor det giver mening
• Cloud, hvor det giver fleksibilitet
• Backups, der faktisk kan gendannes

Pludselig handlede det ikke om enten/eller – men om kontrol og transparens.

Nørderiet: analyse, hardware og sikkerhed

Her begyndte den del, jeg egentlig holder mest af.

At analysere markedet. Sammenligne hardware.
Vurdere:

• Kryptering
• Backup-strategier
• Failover
• Integrationsmuligheder
• Reelle sikkerhedsniveauer – ikke marketing

Det var nørderi i ordets bedste forstand: Langsomt, grundigt og med respekt for kompleksiteten.

Realiteten: når data faktisk betyder noget

Det her handler ikke om et par dokumenter.

Det handler om:

• 100.000+ billeder i RAW, som ikke kan genskabes
• Musikprojekter med årtiers samples, plugins og sessions
• Private og professionelle filer, der skal være:
  • Tilgængelige
  • Hurtige
  • Sikkert opbevaret
  • Fremtidssikrede

Alt sammen uden at workflowet kollapser.

Hvad konsolidering gav mig

Resultatet blev ikke et perfekt setup.

Men det blev:

• Mere ro
• Bedre overblik
• Mindre afhængighed
• Større bevidsthed om valg

Og vigtigst: En følelse af, at mit digitale liv arbejder for mig – ikke omvendt.

Afslutning: det handler ikke om kontrol – men om retning

Konsolidering er ikke et endemål. Det er en proces.

Men i en verden, hvor teknologi, politik og økonomi smelter sammen, føles det vigtigere end nogensinde at:

• Tage stilling
• Vælge bevidst
• Og acceptere, at komfort nogle gange skal udfordres

Ikke for at være ekstrem – men for at være ansvarlig.

Overgang fra teaser til “det konkrete”

Hvis det her rammer noget, du selv har gået og tænkt over, så er resten af indlægget mere praktisk anlagt.
Nedenfor gennemgår jeg, hvordan jeg greb konsolideringen an i praksis – trin for trin – og hvilke valg jeg traf undervejs.

Før jeg købte nye abonnementer eller flyttede rundt på software, brugte jeg tid på at afklare, hvad det egentlig var, jeg ville – og måske endnu vigtigere: hvad jeg ikke længere ville acceptere.

Mit primære mål var at konsolidere mine data til så få steder som muligt, reducere antallet af leverandører og samtidig skabe en model, hvor mine største datamængder lå lokalt, mens de mest kritiske data var sikret via cloud-backup.

Samtidig ville jeg se, hvor meget af mit eksisterende setup – både kreative værktøjer og office-løsninger – der kunne erstattes med billigere eller mere åbne alternativer, uden at mit workflow led under det.

Som et første, meget konkret skridt købte jeg derfor rigeligt med eksterne harddiske og en ny Sonology NAS som jeg satte op, før jeg havde alle svarene og begyndte systematisk at tage backup af mine største eksisterende tjenester – Google, Hotmail og Dropbox – direkte til NAS’en.

Det var ikke den endelige løsning.
Det var starten.

Analysefasen: struktur før handling

Inden jeg begyndte at flytte data eller opsige abonnementer, var det vigtigt for mig at få overblik før momentum. Jeg vidste, at mængden af tjenester, data og afhængigheder var så stor, at jeg ikke kunne holde det hele i hovedet – og slet ikke vurdere konsekvenserne af ændringer uden hjælp.

Som en del af analysefasen valgte jeg derfor at opsætte en dedikeret ChatGPT-agent. Jeg brugte tid på at formulere en grundig instruktion og uploadede et relativt fyldestgørende katalog over mine eksisterende tjenester samt mulige alternativer. Kataloget indeholdt blandt andet oplysninger om:

• Datatyper og datamængder
• Dataoprindelse og jurisdiktion
• Primært formål (kreativt, administrativt, samarbejde, arkiv osv.)
• Produktfeatures og integrationer
• Prisstruktur og bindingsgrad

Det gav mig et arbejdsredskab, hvor jeg kunne gå applikation for applikation og stille de samme spørgsmål hver gang:
Hvad bruges tjenesten reelt til? Hvilke data ligger der? Hvor kritisk er den? Og hvad vil et alternativ betyde i praksis?

Ud fra agenten fik jeg også hjælp til at udarbejde en overordnet plan: hvad der kunne gøres hurtigt, hvad der krævede forberedelse, og hvad der måtte vente. Ikke som et fastlåst projektstyringsdokument, men som en levende prioritering.

Valget af cloud storage: et bevidst test-skridt

Et af de første konkrete skridt blev at finde en online storage-leverandør, som både kunne fungere som midlertidigt samlingspunkt og som potentiel langsigtet komponent i en hybrid arkitektur.

Jeg endte med at identificere tre forskellige kandidater, som alle tilbød:

• EU-hosting
• Et bredt katalog af cloud-tjenester
• Rimelige priser
• Mulighed for at skalere op og ned

I stedet for at analysere mig frem til “det perfekte valg” besluttede jeg at begynde praktisk. Jeg valgte at starte med Nextcloud – både på baggrund af anbefalinger, dens funktionalitet og en prismodel, der gjorde det muligt at eksperimentere uden stor økonomisk binding.

Jeg tegnede et mindre abonnement på 1 TB til under 100 kr. om måneden og brugte det bevidst som en test.

Testen: fra teori til hverdag

Formålet var ikke at flytte alt med det samme, men at afprøve nogle helt konkrete spørgsmål i praksis:

• Hvor nem er løsningen at konfigurere?
• Hvor hurtigt er man i gang?
• Hvordan føles den i daglig brug?
• Hvor stabil er synkronisering på tværs af enheder?
• Hvordan håndteres versionshistorik og konflikter?
• Er brugeroplevelsen “god nok” til, at den ikke bliver en barriere?
• Hvor gennemsigtig er administration, rettigheder og struktur?

Jeg begyndte derfor at flytte data fra nogle af mine eksisterende cloud-tjenester – ikke nødvendigvis de mest kritiske først, men dem der var repræsentative: dokumenter, mapper, arkiver og arbejdsmateriale.

Det gav mig hurtigt en fornemmelse af, om Nextcloud kunne fungere som mere end bare endnu en mappe i rækken – nemlig som et egentligt ankerpunkt i et mere konsolideret setup.

For at gøre arbejdet mere håndgribeligt samlede jeg samtidig mine eksisterende værktøjer og tjenester ét sted og grupperede dem i nogle relativt simple kategorier. Ikke for at lave en endelig sandhed, men for at kunne se mønstre, overlap og afhængigheder.

Jeg har samlet det overblik her:

https://xolsen.com/links/
(gå til sektionen “Tech”)

Her har jeg kategoriseret de værktøjer, jeg bruger – fra kreative applikationer og samarbejdsværktøjer til cloud-tjenester, AI-services og infrastruktur – netop for at kunne arbejde mere systematisk med dem én for én.

Det viste sig hurtigt, at mange af de mest kritiske data ikke nødvendigvis lå i klassiske filsystemer, men i applikationer, boards, projekter og workflows, som sjældent indgår i traditionelle backup- eller compliance-overvejelser.

Med det overblik på plads kunne jeg begynde at stille de svære spørgsmål:
Hvilke af disse tjenester ejer jeg reelt mine data i? Hvilke kan kobles på sikker storage? Og hvilke ville være problematiske, hvis jeg på sigt vil arbejde med AI-agenter under klare GDPR-rammer?

(Fortsættelse følger)

The post Den helt store applikations- og dataoprydning. appeared first on [x]olsen.

Jeg er i gang med et nyt musikprojekt sammen med en dygtig sangerinde, og som et eksperiment prøver jeg at skabe en musikvideo før nummeret egentlig er færdigt. Ideen er at lade billeder, stemninger og visuelle fortællinger være med til at forme selve musikken – ikke kun omvendt.

Processen består af tre trin:

1. Analyse af tekst
   Jeg starter med at analysere sangteksten i ChatGPT for at finde frem til stemningen: dystopisk, ubestemmeligt årstal, støvet æstetik, let gysereffekt og måske et kunstigt animeret præg.
2. Visuelle prompts og AI-billeder
   Ud fra analysen beder jeg ChatGPT om at lave 20 video-/billedeprompts, som jeg bruger i MidJourney. Når MidJourney giver mig fire billedforslag, vælger jeg ét og får det animeret – igen med fire nye varianter. Dem gemmer jeg som små videoklip.
3. Redigering og musikproduktion
   Klippene importeres i Final Cut Pro, hvor jeg begynder at bygge musikvideoen op. Samtidig arbejder jeg videre i Logic Pro med nummeret: analoge synths, effekter, e-trommer og måske guitar og bas. Det bliver et spændende miks af lyd og billede, der påvirker hinanden i processen.

Herunder har jeg samlet nogle eksempler på prompts, billeder og videoer fra processen.

Det er super fedt – og også ret tidskrævende.
Jeg vender tilbage, når videoen tager mere form

ChatGPT Promt: Shadow Talking Prompt: Woman walking across a retro kitchen floor, her shadow on the wall moving its mouth independently, surreal mismatch, photorealistic, wide shot, vintage teal wallpaper

Midjourney: pictures in four different versions.

Mijjourney: Video-examples – four different versions (only showing one)

Final Cut: Example

The post Musikvideo eksperiment med AI appeared first on [x]olsen.

For at skabe gode billeder hurtigt arbejder jeg ofte efter faste metoder: user-story-formatet (“som designer vil jeg … for at …”), at lade assistenten forklare ting i rollen som en ekspert (“forklar det som en art director”) eller at forsimple idéen (“forklar det som til en 5-årig”). Det gør processen mere tydelig og gør det nemmere at ramme den ønskede retning.

10 huskeregler til bedre AI-billeder

1. Start med formålet – hvad skal billedet bruges til?
2. Beskriv stemning og stil – realistisk, tegnet, retro, futuristisk osv.
3. Vælg få, klare detaljer – undgå unødvendige ord.
4. Sig tydeligt, hvad der ikke skal med – det gør ofte forskellen.
5. Vær specifik om farver – især hvis du skal matche eksisterende materiale.
6. Undgå tekst i billedet, hvis muligt – eller styr det meget præcist.
7. Giv ét eksempelbillede, hvis du kan – reference er guld værd.
8. Test flere variationer – små ændringer giver ofte store forbedringer.
9. Tænk i roller – få AI’en til at agere designer, fotograf eller kunstner.
10. Rens prompten mellem forsøgene – fjern støj, hold kun det nødvendige.

AI Modediller

Der kommer løbende sjove idéer til hvordan man kan bruge egnebilleder til enten at simulere en situation, et produkt eller særlig billedemæsig stilart. Her er nogle eksempler. Hvis du ønsker en prompt til selv at kunne lave et tilsvarende billede tager du bare en kopi og laver reverse-engineering – altså beder chatgpt om at lave en generisk promt du kan bruge.

The post Leg med billeder i ChatGPT appeared first on [x]olsen.

I dette indlæg gennemgår jeg en længere og konkret teknisk afklaringsproces, som jeg har haft med en AI Assistent i forbindelse med planlægningen af et effektivt setup til liveoptagelser i et øvelokale.
Målet var at kunne optage hele bandet samtidigt og få et resultat, der både er musikalsk brugbart og teknisk rent — uden unødvendigt udstyr, uden fejlforbindelser og uden at gøre opsætningen mere avanceret end nødvendigt.

For at gøre processen tilgængelig og fagligt nyttig for andre, gengiver jeg forløbet som en dialog mellem mig selv (Musikeren) og en AI Assistent. Dialogformen afspejler den faktiske arbejdsproces, hvor spørgsmål, misforståelser og tekniske valg gradvist blev afklaret og omsat til en samlet løsning.

Dialogen: Musikeren & AI Assistent

1. Udgangspunktet

Musikeren:
Jeg vil gerne lave gode liveoptagelser i øvelokalet. Ikke bare referencer — men noget man faktisk kan bruge og lytte til.
Jeg har et Apollo X6 lydkort og overvejer at tilføje en Behringer ADA8200 for at få flere indgange. Hvordan griber jeg det an?

AI Assistent:
Først skal vi se på, hvilke mikrofoner og signaltyper du arbejder med, og hvilke indgange Apollo X6 faktisk har. Derfra bygger vi et samlet setup.

2. Mikrofonvalg og eksisterende udstyr

Musikeren:
Jeg er lidt i tvivl om, hvordan jeg bedst bruger det udstyr, jeg allerede har — og hvor jeg bør udvide, hvis jeg vil have mere fleksibilitet.

AI Assistent:
Lad os starte med dit eksisterende setup. Du har allerede en rigtig god grundpakke:

• TLM 104 (stor-membran kondensator)
• 2 × SM58 (dynamiske vokal-/instrumentmikrofoner)
• Helicon dynamisk vokalmikrofon
• Apollo X6 lydkort (2 mic-preamps + 2 Hi-Z, men kun 2 samtidige mic-kanaler)

Det betyder, at du allerede kan lave et funktionelt 3–4 mikrofoners tromme- og bandsetup, hvis du vælger dine mikrofoner strategisk.

– Sådan bruger du dit nuværende udstyr optimalt

• TLM 104 som overhead
  Din 104’er er faktisk en stærk kandidat som enten mono-overhead eller rum-mikrofon. Den har høj opløsning, lav egenstøj og giver et nuanceret billede af trommesættet og rummet.
• SM58 på trommer
  Selvom SM58 normalt er en vokalmikrofon, fungerer den overraskende godt på snare, toms eller som en “close mic” på dele af sættet. Den er robust og håndterer højt lydtryk uden problemer.
• Helicon-mikrofon til vokal
  Din Helicon er en dynamisk live-vokalmikrofon, som klarer øvelokale-situationer langt bedre end en kondensator-vokalmikrofon ville gøre.

Med denne kombination kan du lave et effektivt basis-setup i øvelokalet:

• Overhead: TLM 104
• Trommer nærmike: 2 × SM58
• Vokal: Helicon
• Bas og guitar direkte fra forstærker-output

Dette giver dig allerede en fuldt brugbar liveoptagelse.

– Hvorfor du måske vil udvide — og med hvad

Udvidelse 1: Behringer ADA8200 (8 ekstra indgange)

Dette er den mest værdifulde og afgørende opgradering for dig.

Hvad den giver dig:

• 8 ekstra mikrofon-/line-indgange via ADAT
• Solid preamp-kvalitet til prisen
• Perfekt match til Apollo X6, som mangler indgange til trommer
• Mulighed for at mikrofonføre hele trommesættet, vokal og rum på én gang

Med ADA8200 kan du lave et rigtigt multikanal live-setup:

Hvis du vil tage skridtet videre og optage hele bandet samtidigt med større fleksibilitet og bedre separation, er der to oplagte udvidelser:

Udvidelse 2: Ekstra overheads eller rum-mikrofoner

Hvis du vil løfte kvaliteten yderligere, er småmembran kondensatorer som Røde NT5 eller sE8 en oplagt udvidelse.

Fordelene:

• Bedre stereobillede af trommer
• Mere præcis transientgengivelse (cymbaler/hi-hats)
• Kan kombineres med din TLM 104 som center/room

Det giver dig et stort og åbent trommelydbillede, som ellers er svært at skabe i et øvelokale.

3. Det konkrete setup begynder at tage form

Musikeren:
Så et muligt setup kunne være:
– Helicon til vokal
– To SM58 på trommer
– En TLM 104 som overhead
– Evt. en kondensator mere
– Bas og guitar direkte fra forstærker-output?

AI Assistent:
Det er et solidt udgangspunkt. Men for at optage alt samtidigt får du brug for ADA8200, da Apollo X6 kun har 2 mic-inputs.

4. Kabler: TS, TRS, XLR — og hvornår man bruger hvad

Musikeren:
Jeg bliver i tvivl om kabler. Hvornår bruger jeg TS, TRS og XLR?

AI Assistent:
Her er den helt enkle og korrekte regel:

5. Forskellen på instrument-signal og line-signal

Musikeren:
Er keyboard-output ikke det samme som bas/guitar-output?

AI Assistent:
Nej.
Guitar/bas = instrumentniveau, høj impedans (Hi-Z) → TS + Hi-Z-input
Keyboard/synth = line-niveau, lav impedans → TRS + line-input

De kan ligne hinanden i kabler — men elektronisk er de fundamentalt forskellige.

6. Placering af mikrofoner og fordeling på inputs

Musikeren:
Så mine SM58 og Helicon skal i ADA8200 med XLR og uden phantom?

AI Assistent:
Korrekt. Alle tre er dynamiske mikrofoner.
Phantom power (48 V) skal være slukket på de kanaler.

TLM 104 skal i Apollo X6 med XLR og phatom power (48 V) tændt.

7. Det samlede setup

Mikrofoner i ADA8200

• SM58 (snare eller tom)
• SM58 (tromme/rum)
• Helicon (vokal)

Alle via XLR, 48 V OFF

Mikrofoner i Apollo X6

• TLM 104 overhead (XLR, 48 V ON)
• Evt. ekstra kondensator overhead/rum (XLR, 48 V ON)

Instrumenter i Apollo

• Bas → TS → Hi-Z (front)
• Guitar → TS → Hi-Z (front)

Line-kilder i Apollo

• Synth/keyboard → TRS → Line input (bag)

Digital forbindelse

• ADA8200 ADAT OUT → Apollo ADAT IN
• Apollo ADAT OUT → ADA8200 ADAT IN
  (Apollo er master clock, ADA8200 slave)

8. Konklusion: Setup’et du kan stole på

Efter en række spørgsmål og tekniske afklaringer står der nu et fuldstændigt og realistisk live-setup:

• Dynamiske mikrofoner til trommer og vokal for at minimere rumstøj
• En eller to kondensatorer som overhead for at give luft
• Instrumenter og synths korrekt koblet ind via Hi-Z og line-inputs
• ADA8200 til at udvide Apollo X6, så du kan optage hele bandet samtidigt
• Korrekte kabler hele vejen rundt: XLR, TS, TRS og ADAT

Resultatet er en opsætning, der både er teknisk korrekt, musikalsk brugbar og hurtig at sætte op, hver gang I mødes i øvelokalet.

The post Optagelse af live-lyd i øvelokalet: En teknisk dialog mellem Musikeren og en AI Assistent appeared first on [x]olsen.