AI for your organization

AI pays off when it does real work inside an organization: it answers questions from your own knowledge, takes care of routine steps in your processes, and supports your people with the tools they already use. Getting there involves more than choosing a model. You need the right use cases, reliable engineering, and an answer to the question every board and works council asks sooner or later: where does our data go, and who controls it?

I help organizations answer that question and build AI they can trust, from the first workshop to software running in production.

What I help with

• AI strategy: finding the use cases that are worth it economically, and ruling out the ones that aren’t
• Agentic AI: autonomous agents and multi-step workflows that use tools and APIs, grounded in enterprise knowledge through vector search and retrieval-augmented generation (RAG)
• Secure and sovereign AI: security, data sovereignty, and the choice between open source and commercial offerings, from local AI infrastructure or LLMs hosted in Germany to hyperscaler services
• Engineering: modern ML pipelines, containerized services, CI/CD, and the agile and DevOps practices that let teams ship reliably
• Technology due diligence and digital leadership: assessing technology and advising executives through transformations

What you can gain

• Knowledge at hand: employees find answers in manuals, contracts, tickets, and wikis in seconds instead of searching for them, with sources they can check.
• Less routine work: agents prepare, check, and route documents, draft replies, and fill in systems, leaving people to make the decisions.
• Better service: faster and more consistent answers for customers, around the clock, with a human taking over where it matters.
• Faster decisions: analyses and summaries that used to take days are ready while the question is still relevant.
• Independence: where open models and your own infrastructure fit, AI becomes a capability you own rather than a subscription you depend on.

What makes it hard

The technology is impressive; the difficulties are mostly elsewhere:

• Reliability: language models can be confidently wrong. Systems need grounding in your data, systematic evaluation, and clear limits on what they may do on their own.
• Data quality and access: AI is only as good as the knowledge it can reach. Scattered, outdated, or badly permissioned data shows up in the answers.
• Cost: usage-based pricing can grow quickly. The economics have to be worked out per use case, not assumed.
• People and change: tools that nobody trusts or understands won’t be used. Teams need training, and processes need to be adapted, not just automated.
• Regulation: the GDPR, the EU AI Act, and industry rules apply. In Germany, introducing AI tools usually also involves the works council.

The hardest and most important questions concern data: sovereignty, privacy, and security.

Data sovereignty

Data sovereignty means you decide where your data is processed, who can access it, and under which law, and that you can change your mind later without starting over. For AI this applies to everything a model sees: prompts, documents, embeddings, logs, and any data used for fine-tuning.

There is no single right answer, but there is a spectrum of options:

A few things are easy to overlook:

• Data residency is not sovereignty. Data stored in an EU data center of a US provider can still be subject to US law, such as the CLOUD Act. Whether that matters depends on your data and your risk appetite, but it should be a conscious decision.
• Contracts matter as much as technology. Read the data processing agreement: Is your data used for training? How long are prompts and logs kept? Which subprocessors are involved, and where?
• Avoid lock-in by design. An architecture with a thin layer between your applications and the model lets you switch providers, or move to a self-hosted model, when prices, laws, or requirements change.
• Mix and match. Most organizations do well with a tiered approach: public models for non-sensitive tasks, sovereign or self-hosted models for confidential and personal data.

In practice, a thin gateway between your applications and the models decides which data may go where, filters out what must not leave, and logs every call. Switching providers then means changing a route, not rebuilding applications:

flowchart TD
    apps["Your applications and users"] --> gw["AI gateway<br/>routing, filtering, logging"]
    gw -->|"public"| pub["Public<br/>AI service"]
    gw -->|"internal"| eu["EU-hosted<br/>model"]
    gw -->|"confidential,<br/>personal"| own["Self-hosted<br/>model"]

Open-weight models now meet the requirements of many demanding business applications, as my projects show, and they run on hardware you control, on premises or with a German hosting provider. I help you decide where that pays off and build the infrastructure if it does. Where a hyperscaler or a commercial product serves you better, I’ll recommend that instead.

Privacy

If an AI system processes personal data, the GDPR applies in full, and AI brings some specific challenges:

• Legal basis and purpose: every use case needs a legal basis, and data collected for one purpose cannot simply be fed into AI for another.
• Data minimization: only what the task really needs should reach the model. Pseudonymization and filtering before the model call help.
• Permissions: an assistant that searches company knowledge must respect the same access rights as the user asking. Otherwise it becomes the easiest way to read the CEO’s mail.
• Deletion: personal data can be removed from a search index, but not from a model’s weights. That’s one reason to prefer retrieval (RAG) over fine-tuning when personal data is involved.
• Impact assessments: many AI use cases require a data protection impact assessment (Art. 35 GDPR). Done early, it shapes a better design rather than blocking a finished one.
• Employees: AI tools that could be used to monitor performance or behavior are subject to co-determination in Germany. Involving the works council early saves months later.
• The EU AI Act: depending on the use case, there are transparency and documentation obligations, and stricter rules for high-risk systems such as AI in recruiting. Since February 2025 organizations must also ensure their staff have sufficient AI literacy.

Security

AI agents act: they read emails and documents, call APIs, and change data. That makes them useful, and it makes them a new kind of attack surface:

• Prompt injection: instructions hidden in a document, email, or web page can hijack an agent that reads them. There is no complete technical fix yet, so systems must be designed to limit the damage.
• Data exfiltration: an agent that can read confidential data and also send messages or open links can be tricked into leaking it.
• Excessive agency: agents should get the minimum rights they need, and consequential actions like payments, deletions, or external messages should need human approval.
• Supply chain: models, plugins, tool servers, and libraries all come from somewhere and need the same scrutiny as any other dependency.
• Shadow AI: if official tools are missing or unusable, employees paste company data into whatever is available. Good, sanctioned tools are part of the security strategy.

The answer is to treat everything an agent reads as untrusted and to limit what it can do with it:

flowchart TD
    user["User"] --> agent["AI agent<br/>sandboxed, least privilege"]
    input["Untrusted content<br/>emails, documents, web pages"] --> agent
    agent --> tools["Read-only tools<br/>search, lookups"]
    agent --> approval{"Human approval"}
    approval -->|"approved"| actions["Consequential actions<br/>payments, deletions, external messages"]
    agent -.-> log[("Audit log")]

I design AI systems with these risks in mind: least privilege, clear trust boundaries, sandboxed execution, audit logs, human approval where it counts, and testing against known attack patterns such as the OWASP Top 10 for LLM Applications.

How we work together

1. Assess: we look at your goals, processes, and data, and identify the use cases worth pursuing, including their risks and regulatory requirements.
2. Pilot: a small, measurable project with your real data, under your rules, that shows within weeks whether the idea holds up.
3. Production readiness: together with your IT, I design and set up hardening, integration, monitoring, and evaluation so the system stays reliable after launch; operation stays with your IT or provider.
4. Enablement: training, governance, and guidelines so your teams can continue on their own.

If you also need software built, I can develop it myself, quickly, using AI agents as my tools. See software built with AI agents.

Contact

Write to . I’m happy to start with an informal conversation about where you stand.