Terms from our articles, briefly explained

Agentic AI describes AI systems that not only formulate answers but, given a task, autonomously plan steps, call tools, and evaluate intermediate results. Instead of a one-shot question-and-answer exchange, you get a loop: plan, act, observe, next step.

What makes a system agentic

• Tool use: the model can call APIs, databases, or other tools (often via MCP).
• Intermediate checks: results are reviewed before the next step is taken.
• Memory: the agent keeps context across at least the current task.
• Stop criteria: clear conditions for when the task is done - or has to be escalated.

Why it matters

In day-to-day operations, agentic AI handles tasks that are too large for a single prompt: research across several sources, drafting documents, processing inbound mail. Quality depends on tool descriptions, clean permissions, and clear stopping behaviour when the agent is uncertain.

What it is not

A coding agent is one specific shape of agentic AI for software development. A plain chatbot is not - as soon as there are no tools or steps in play, the agentic part is missing.

The GDPR (General Data Protection Regulation, German: DSGVO) is the EU-wide framework for handling personal data. It covers every process that involves names, contact details, files, customer information, or similar data - regardless of whether it lives in a cloud service, on local servers, or in a spreadsheet.

What it aims at

• Purpose limitation: data is processed only for the purpose for which it was collected.
• Data minimisation: collect what is actually needed, no more.
• Transparency: data subjects know who uses their data and why.
• Data subject rights: access, rectification, erasure, portability.

Connection to IT

In software projects, the central topics are processor agreements, technical and organisational measures, third-country transfers, and a clean separation of test and production data. AI features add concerns around training data, logging, and the role of the model operator.

Where the practical leverage is

GDPR readiness rarely comes from a single tool. It comes from clear responsibilities, data flow diagrams, and controlled interfaces. Local AI and an in-house RAG index are often the means by which clear data sovereignty becomes possible in the first place.

Intelligent Document Processing (IDP) refers to the automated handling of documents with the help of AI. Unlike plain OCR, it goes beyond reading text from a scan: the content is understood, classified, and turned into structured fields.

Not to be confused with IdP (Identity Provider)

The acronym IDP shows up in two very different worlds. Here we mean document processing. Identity Providers (usually written as IdP) are systems used for authentication and single sign-on.

Typical steps

• Classification: which type of document is this (invoice, contract, official notice, letter)?
• Extraction: which fields should be read out (amounts, dates, counterparties, reference numbers)?
• Validation: plausibility checks, four-eyes review, and fallbacks for low-confidence results.
• Handover: delivering the results to a DMS, ERP, line-of-business application, or workflow engine.

What sets a good solution apart

A reliable IDP setup stands or falls with data quality and handling of edge cases. A clean intake channel, good training data, clear stop criteria, and a human review step for uncertain cases matter more than the choice of model.

Local AI refers to language models and tools that run in your own data centre, on your own server, or on a workstation - not in a vendor's cloud. Data therefore does not have to leave your network, which is often the decisive criterion for law firms, medical practices, and advisory businesses.

When local AI makes sense

• Confidential data: client files, patient records, financial documents.
• Regulatory requirements: professional rules of conduct, customer contracts, industry regulation.
• Latency: recurring queries without a cloud round-trip.

What local AI looks like in practice

For many tasks today a mid-sized open-source model on a dedicated GPU or capable server is enough. Frameworks like Ollama, vLLM, or llama.cpp serve the model, your own RAG index keeps the knowledge base ready, and an MCP server exposes tools.

What to keep in mind

Local AI does not run itself: model upkeep, GPU utilisation, and scaling have to be supervised. In return, data sovereignty remains clear - and over time, costs are easier to plan than open-ended API tariffs.

The Model Context Protocol (MCP) is an open standard that describes how a language model or agent can talk to external tools and data sources in a structured way. Instead of coding every integration by hand, an MCP server advertises its capabilities, and a client - Claude or your own agent - can use them right away.

What MCP is aiming at

Language models only become useful at work when they can read your own data and trigger actions: look into a DMS, search a knowledge base, book a slot in a calendar. MCP provides a standardized interface for that, independent of the specific model.

What an MCP server offers

• Tools: clearly described actions the agent can invoke.
• Resources: data the agent is allowed to read, such as documents or records.
• Prompts: prepared building blocks the agent can use as templates.

Why it matters in practice

For mid-sized companies, MCP reduces the integration effort between AI systems and existing applications. An MCP server in front of an existing API is often shorter and more stable than a hand-built adapter per AI tool.

OPA (Open Policy Agent) is an engine that pulls decisions about access and application behaviour out of the application itself. Rules are written in the Rego language and managed centrally, instead of being scattered across code, configuration files, and cloud consoles.

What OPA is for

• Access control: who is allowed to perform an action, on which resource, under which conditions.
• Compliance rules: technical requirements, e.g. which container images are allowed or which tags a deployment must carry.
• Data filters: which records a caller is allowed to see at all.

Why it matters in mid-market IT

In long-grown systems, rules are usually scattered across code. OPA makes them visible, reviewable, and versionable. A change to access policy becomes a traceable event - rather than a search across ten repositories.

Related concepts

OPA is not the only tool for policy-as-code, but it is the most widely used. In Kubernetes environments you typically meet it as Gatekeeper; in API gateways as a sidecar or library.

A PWA (Progressive Web App) is a web application that runs in the browser yet feels like a native app: it can be installed to the home screen, works without a permanent connection, and integrates with the operating system for push notifications or background data.

What makes a PWA

• Manifest: describes the app's name, icon, and start behaviour.
• Service worker: a background script that manages caches and enables offline behaviour.
• HTTPS: a precondition, since modern browser APIs only become available over HTTPS.

When a PWA fits

PWAs are a good fit when the same functionality is needed on desktop, tablet, and phone without maintaining a separate build per platform. Typical use cases are internal tools, customer portals, booking and order applications.

How it differs from a native app

Native apps remain essential when deep device integration, Bluetooth, sensors, or specialised performance is required. For most business applications, a PWA is enough - at significantly lower cost and without going through store review.

Retrieval-Augmented Generation (RAG) augments a language model's answer with content from a dedicated document source. Instead of relying only on the knowledge baked into the model, the system first retrieves a small set of relevant passages from an index (retrieval), then has the model generate an answer grounded in those passages (generation).

Why it matters

In a business setting the relevant knowledge usually does not live inside the model - it lives in case files, contracts, wikis, and email threads. RAG combines both: the language understanding of the model with the concrete, current source material from the company. This reduces the risk of fabricated answers and makes statements traceable.

Typical building blocks

• Ingest pipeline: extracting and preparing documents, often including OCR and cleanup.
• Chunking: splitting documents into passages that can be indexed individually.
• Embedding index: vector representation of the chunks in a vector database.
• Retrieval step: semantic search for relevant chunks, often with re-ranking.
• Grounded generation: the model produces an answer and points to the supporting passages.

Common pitfalls

A pilot on sample data is far easier than running RAG in production. Permissions, versioning, OCR quality, and traceable citations decide whether a RAG system is actually accepted in day-to-day work.