AI Governance

AI that survives the compliance review

Every AI system we ship comes with the paperwork and the engineering that legal, security and works councils ask about: which model runs where, who checked it, what happens when it is wrong, and how you leave. This page describes how we govern AI in client systems, in the same depth we apply to building them.

How we govern AI in client systems

Every AI system we ship comes with the EU AI Act paperwork and the engineering to back it. We classify each use case during scoping, keep a human in the loop where decisions matter, log every automated decision so it can be reviewed, and train no public model on your data. Hosting stays in the region you require, EU-only when you ask, and you own the code and the data from the first commit. The result is one system that legal, security, the works council and procurement can each sign off on, governed in the same depth we apply to building it.

EU AI Act use-case classification and the supporting technical documentation
Humans stay in charge: every automated decision can be overridden and is logged
Your data trains no public or shared model, and EU-only hosting is available on request
You own the code and the data from day one, with a documented exit

Four commitments

Humans stay in charge

Every automated decision path has a defined human oversight point. Agents act inside explicit boundaries and hand over when confidence drops or stakes rise.

Your data trains nothing

We configure providers with no-training agreements and document it. Client data is not used to train foundation models, by contract and by configuration.

Evidence over claims

Quality is measured with evaluation sets and acceptance criteria agreed before go-live, not demos. If we cannot measure it, we say so.

Exit is part of the design

Model and provider choices are documented and swappable. You get the prompts, the evaluation data and the runbooks. Leaving us must be possible without losing the system.

How a governed AI request flows

Every request runs the same audited path: approved sources, permission-aware retrieval, a bounded model step, human approval, and an audit log.

Approved sources

Permission-aware retrieval

Model / agent (bounded tools)

Human approval

Audit log

Guardrails and feedback across every step

Guardrails and feedback wrap every step. Consequential actions wait for human approval before anything commits.

Where we stand on the EU AI Act

In our assessment so far, the systems we typically build (internal automation, retrieval, assistants with disclosure) fall into the minimal or limited risk categories of the EU AI Act; we classify every use case individually during scoping. When a use case touches a high-risk category, we say so at the proposal stage and design the required controls in: risk management, logging, human oversight, technical documentation. As a development partner we support you in your deployer obligations and document everything you need for your own assessment. We do not sell certification; we deliver the technical groundwork that makes your compliance work possible.

Who signs off, and what each one gets

An AI system reaches several reviewers before it goes live. We give each of them the evidence their role requires.

Legal and data protection (DPO)

You have to confirm the GDPR and EU AI Act position before the system can process real data.

Per-use-case risk classification, a record of processing, an AVV and TOM on request, and EU-only hosting where you need it.

Review trust and data handling

Security and IT

You need to know which model and provider handle each request and where the data physically sits.

A model and provider register, EU hosting on Render in Frankfurt, a named subprocessor list, and logs for every automated decision.

See the security posture

Works council (Betriebsrat)

You need to confirm the system does not decide about employees without a human and stays transparent.

Human oversight on decisions that affect people, full logging you can inspect, and no automated action shipped without a person in the loop where it matters.

Read how we govern AI

Procurement

You have to clear a new vendor and confirm price, ownership and exit before any budget moves.

A German GmbH with a full Impressum, fixed-price engagements from 25k EUR, code in your own repositories, and a documented handover.

See engagement terms

Public engineering you can inspect

Running on this site

Live

The assistant on this site is an agentic, tool-using system we built and run in production, not a demo behind a login.

Vendure Data Hub

Open source

A Vendure commerce plugin we built and published, public on GitHub. Two of our eleven engineered bundles are public.

View on GitHub

Pimcore Asset Pilot

Open source

A Pimcore asset bundle we built and published, public on GitHub and inspectable end to end.

View on GitHub

The model and provider register

Every project carries a living register, delivered as part of the documentation:

Model and version

Which model runs, with pinned versions and a change log for every upgrade.

Provider and region

Where inference happens, under which contract, in which jurisdiction.

Purpose in the system

What the model is allowed to do in the system, and what it is not.

Data classes

Which categories of data reach the model, mapped against your privacy documentation.

No-training status

The contractual and technical setting that keeps your data out of training.

Fallback behavior

What the system does when the model fails, times out or returns garbage.

What we do with your data, and what we never do

Governance is easier to trust when it is specific. This is the line we hold on your data.

What we do

Keep your data in the region you require, including EU-only hosting
Pass a model only the context a task needs, nothing more
Log every automated decision so it can be reviewed and explained
Let a human override or stop any automated action
Delete data on the schedule we agree, and show that it happened

What we never do

Train public or shared models on your data
Send personal data to a third party without your consent
Ship an AI decision to production without a human in the loop where it matters
Hide which model or provider handled a request
Leave you without an exit: the system and its data stay yours

Governance across the lifecycle

Scoping and risk classification

Before we build: what the system decides, who is affected, what the worst credible failure looks like, and which EU AI Act category applies.

Data mapping

Which data reaches which model under which contract. Aligned with your DPO and privacy documentation before the first token flows.

Evaluation and acceptance

An evaluation set and acceptance criteria agreed with you. The system ships when it passes, and the numbers go into the handover documentation.

Human oversight design

Defined review queues, confidence thresholds and escalation paths. The people who oversee the system get tooling, not just responsibility.

Versioning and change control

Model upgrades are changes, not surprises: tested against the evaluation set, logged in the register, reversible.

Incident handling

Defined severities, a kill switch or degradation path, and an honest post-mortem. AI incidents are treated like production incidents, because they are.

Four commitments

Humans stay in charge
Your data trains nothing
Evidence over claims
Exit is part of the design

Talk to an engineer

Standards and practices we work to

We do not invent governance from scratch. We align to the frameworks your auditors already know.

GDPR

Data minimisation, purpose limitation and the right to erasure are designed into the system rather than bolted on. Processing stays documented and lawful.

EU AI Act

We classify each AI use by risk and apply the transparency, oversight and documentation that tier requires, so you are ready as the rules phase in.

OWASP LLM Top 10

Prompt injection, data leakage and insecure output handling are threats we design against, with the same rigour as any other application security work.

Data residency

EU-region hosting and, where you need it, on-premise or private-cloud deployment, so your data stays where your policy says it must.

Questions legal and security teams ask

Can you run models in the EU only?

Yes. We default to EU regions where the provider offers them and document the region per model in the register. Where a capability only exists outside the EU, we flag it and you decide.

What happens to our prompts and outputs?

They are processed to run the system and logged for operations and audit, under your retention rules. Under the provider terms we contract and the configurations we document in the register, they are not used to train foundation models. Logging is documented so your DPO can verify it.

Who is liable when the AI is wrong?

The system is designed so that consequential decisions pass a human oversight point. The contract defines responsibilities precisely; the architecture makes the answer auditable, and the decision log shows what happened.

Can we audit the system?

Yes. The documentation includes the register, the evaluation results, the data flows and the runbooks. We support audits instead of fearing them; the system is built to be explained.

What if a provider changes terms or shuts down?

Provider choices are documented and the integration layer keeps models swappable. The fallback behavior is part of the design, and the register names the alternatives we validated.