Multi-Cloud Strategy for the Federal Administration: Architecture, Procurement and Compliance
AI In The Public Sector, Azure CAF & Cloud Migration, Sovereignty Series 22nd Aug 2026Martin-Peter Lambert
Single cloud providers have their limits. A multi-cloud strategy overcomes them: Azure, Google Cloud, the Deutsche Verwaltungscloud and sovereign platforms complement each other, and the result is maximum flexibility with full compliance. This article builds on our Cloud Migration Roadmap for the Public Sector.
Multi-Cloud is the Future of Public Sector IT
The public sector benefits particularly: specialised workloads find their optimal platform, and digital sovereignty is maintained by placing each workload where its protection needs are met — not where the first contract happened to be signed.
What Multi-Cloud Really Means
Multi-cloud is more than just using two providers. It is a strategy, an architecture, and an operating model. The Cloud Adoption Framework for Azure provides the methodology; a GCP Landing Zone provides the structure; a sovereign landing zone covers the workloads that must stay under EU control.
Each workload is analysed. Where does it run best? Azure? GCP? A sovereign cloud in Germany? The answer is often: it depends — on data classification, required services, cost and exit strategy.
The Building Blocks of a Multi-Cloud Architecture
Governance Layer — Centralised control is essential. Azure and GCP landing zones follow common principles: uniform policies as code, consistent monitoring, and end-to-end security.
Connectivity Layer — Azure ExpressRoute connects data centres; Google Cloud Interconnect complements it. Hybrid scenarios become possible and datacenter migration proceeds without interruption — see Multi-Cloud Connectivity.
Security Layer — BSI C5 applies across the board. One BSI-compliant cloud security concept covers all platforms; IT-Grundschutz in the cloud and ISO 27001 remain the standard.
Application Layer — This is where multi-cloud shows its strength. Kubernetes runs on AKS, GKE and sovereign platforms alike. Containers are portable. Vendor lock-in is avoided.
Quick Checklist: Multi-Cloud Readiness
Area
Checkpoint
Status
Governance
Central Policy Engine Defined
☐
Network
Connectivity Concept Created
☐
Security
BSI C5 Mapping for All Clouds
☐
Identity
Centralised IAM Planned
☐
Costs
FinOps Process Established
☐
Operations
Multi-Cloud Monitoring Active
☐
Exit
Portability and exit plan tested per workload
☐
To-Do List for Multi-Cloud Success
Immediately: Conduct a cloud strategy workshop.
Week 1: Start workload classification.
Week 2: Create a compliance matrix.
Month 1: Build landing zones in parallel.
Month 2: Migrate pilot workloads.
Month 3: Establish governance processes.
Structuring Tenders and Procurement Correctly
A cloud migration tender requires expertise. The procurement of cloud service providers follows public procurement law (VgV, EVB-IT); a cloud framework agreement accelerates procurement. Consulting should begin before the tender so that requirements — C5 Type 2 attestation, DVC conformity, EU operator control, exit clauses — are written into the specification and offers become comparable.
Migration costs vary widely. A fixed-price migration creates certainty, provided the assessment phase has produced a reliable inventory.
Compliance as an Enabler
Being BSI C5 compliant is not an obstacle; it is a mark of quality. KRITIS cloud security becomes the standard and NIS2 integrates European requirements. A Data Protection Impact Assessment for the cloud is mandatory — it protects citizens and the authority alike.
The Insight42 Approach
We understand multi-cloud, public authorities and procurement. From strategy to operations we deliver landing zones, migration and managed services across Azure, GCP and sovereign platforms from a single source.
IT Baseline Protection in the Cloud: Shared Responsibility in Practice
Resilience, Security 22nd Aug 2026Martin-Peter Lambert
IT Baseline Protection (IT-Grundschutz) is not limited to on-premises environments. Its principles are universal, but implementation in the cloud requires a new way of thinking. This article is the cloud-specific companion to our guide on ISO 27001 based on IT Baseline Protection.
IT Baseline Protection Meets the Cloud
The Shared Responsibility Model is key. Who is responsible for what? This question must be answered clearly. For the public sector, cloud migration means reinterpreting IT Baseline Protection: the building blocks do not change, but the way the requirements are met does. Automation and cloud-native tools play a central role.
The Shared Responsibility Model in Detail
Cloud Provider (e.g., Azure, AWS, GCP): Responsible for the security of the cloud. This includes the physical security of data centres, the security of the virtualisation layer, and the basic infrastructure.
Customer (Authority): Responsible for security in the cloud. This includes service configuration, identity and access management, data protection, and operating system patching.
The BSI-compliant cloud security concept documents this demarcation — and it is exactly the demarcation that BSI C5 calls the corresponding user-side criteria.
Implementing Baseline Protection Building Blocks in the Cloud
OPS.1.1.5: Logging
Azure: Azure Monitor, Log Analytics, Microsoft Sentinel
GCP: Cloud Logging, Cloud Monitoring, Google Security Operations (Chronicle)
Implementation: Enable logging for all services. Define retention periods. Automate analysis.
CON.1: Cryptography
Azure: Azure Key Vault, Always Encrypted, Transparent Data Encryption
Implementation: Use hub-and-spoke or VPC peering. Enforce network segmentation. Activate DDoS protection.
Quick Checklist: IT Baseline Protection in the Cloud
Baseline Protection Building Block
Cloud Tool (Azure Example)
Implemented?
ORP.4 (IAM)
Entra ID, PIM
☐
CON.1 (Crypto)
Key Vault, TDE
☐
OPS.1.1.5 (Logging)
Log Analytics, Sentinel
☐
NET.1.1 (Network)
VNet, NSGs, Firewall
☐
SYS.1.1 (Server)
Azure Policy, Defender for Cloud
☐
CON.8 (Secure Development)
Azure DevOps / GitHub Advanced Security
☐
To-Do List for Cloud Baseline Protection
Week 1: Understand and document the Shared Responsibility Model.
Week 2: Conduct a cloud-specific risk analysis.
Month 1: Create a mapping of Baseline Protection building blocks to cloud services.
Month 2: Build a landing zone with Baseline Protection configurations (Policy-as-Code).
Month 3: Centralise logging and monitoring.
Ongoing: Monitor compliance status with cloud tools (e.g., Defender for Cloud).
The Role of BSI C5
BSI C5 and IT Baseline Protection are complementary. BSI C5 is a requirements catalogue specifically for cloud services. Many C5 requirements can be met directly with Baseline Protection measures. Anyone implementing IT Baseline Protection in the cloud is well on their way to BSI C5 compliance — and C5:2026 is now structurally aligned with ISO 27001:2022, which makes the mapping even more direct.
The BSI-compliant cloud security concept should integrate both frameworks. It demonstrates how the requirements of C5 and Baseline Protection are met through technical and organisational measures in the cloud.
Insight42: Your Partner for Cloud Security
We translate IT Baseline Protection for the cloud. We build secure landing zones that incorporate ISO 27001 and BSI C5 requirements from the start, and ensure ongoing secure operations with managed services.
Multi-Cloud Connectivity: Combining Azure ExpressRoute and Google Cloud Interconnect
AI In The Public Sector, Azure CAF & Cloud Migration 22nd Aug 2026Martin-Peter Lambert
Multi-cloud is a reality for the German public sector: Azure and Google Cloud are used in parallel. But how do you connect both securely — without routing sensitive data over the public internet? This article extends our guide to Azure ExpressRoute for public authorities to the multi-cloud case.
Multi-Cloud Needs Multi-Connectivity
The answer is dedicated lines to both clouds: Azure ExpressRoute for Microsoft and Google Cloud Interconnect for GCP. Both operate on similar principles and offer enterprise-grade security.
Understanding Google Cloud Interconnect
Cloud Interconnect is Google’s equivalent of ExpressRoute. Dedicated Interconnect provides physical connections, while Partner Interconnect uses carrier infrastructure.
Interconnect is crucial for a GCP migration: large data volumes must be transferred, and GKE workloads benefit from low latency.
The Architecture for Multi-Cloud
Central Network Hub — A hub connects everything: on-premises, Azure, and GCP. Routing is centrally controlled, and security is uniformly enforced.
ExpressRoute to the Azure Hub — Private Peering connects to Azure VNets. A hub-and-spoke topology distributes traffic. The Azure Landing Zone is the destination.
Interconnect to the GCP Hub — Use either Dedicated or Partner Interconnect. A Shared VPC receives the traffic. The GCP Landing Zone takes over.
Inter-Cloud Connection — Azure and GCP can also be connected directly through partner solutions or the central hub.
Quick Checklist: Multi-Cloud Connectivity
Cloud
Connection Type
Bandwidth
Redundancy
Azure
ExpressRoute
As needed
Dual Circuit
GCP
Dedicated Interconnect
As needed
Dual Attachment
Inter-Cloud
Partner/Hub
As needed
Active-Active
To-Do List for a Multi-Cloud Network
Week 1: Conduct a traffic analysis.
Week 2: Create a connectivity design.
Week 3: Prepare the carrier tender.
Month 1: Order ExpressRoute.
Month 2: Order Interconnect.
Month 3: Optimise routing.
Month 4: Establish monitoring.
VPN as a Backup and Entry Point
Not every authority needs dedicated lines immediately. VPN is a valid entry point. A Site-to-Site VPN connects securely at a lower cost. Azure VPN Gateway and Cloud VPN from GCP both support IPsec and offer high availability; they are often sufficient for smaller workloads.
The transition to ExpressRoute or Interconnect can happen later when bandwidth or latency become critical — a decision we typically make in the cloud migration assessment.
Connectivity Compliance
Being BSI C5 compliant also means secure connections. The BSI-compliant cloud security concept must address connectivity. Encryption is mandatory, even on dedicated lines.
A Data Protection Impact Assessment for the cloud considers data flows. Where does data flow? Via which paths? These questions must be answered.
Optimising Costs
Multi-cloud connectivity is not cheap, but it is necessary. FinOps approaches help with optimisation: traffic routing is analysed, egress costs are allocated, and a fixed-price migration offer should include connectivity transparently.
Insight42 Multi-Cloud Network Services
We design multi-cloud networks, providing ExpressRoute and Interconnect from a single source for secure, performant, and cost-effective solutions — with managed services that monitor the connections proactively under SLA.
Conditional Access and MFA: Intelligent Access Control for the Public Sector
AI In The Public Sector, Security 22nd Aug 2026Martin-Peter Lambert
Old access models are obsolete. Once authenticated, always trusted? Dangerous. Conditional Access changes the game: every access is evaluated, context is key. This article follows on from our guide to Entra ID migration for public authorities and shows how to design the policies that make Zero Trust real.
Rethinking Access Control
For the public sector this is a step change. Security becomes dynamic, user-friendliness is maintained, and a cloud-first administration becomes defensible in front of auditors.
What Conditional Access Does
Conditional Access is a policy framework that evaluates access in real time. Who? From where? With what device? To what? These questions are answered on every sign-in.
Based on the answers, decisions are made: allow access, block access, require MFA, or restrict the session.
Understanding the Signals
User and Group — Who is accessing? Administrators have different rules than standard users. Externals different from internals.
Location — Where is the access coming from? Known networks are more trustworthy. Unknown countries are blocked.
Device — Is the device managed? Is it compliant? Unknown devices require additional verification.
Application — Which app is being accessed? Sensitive applications need stronger protection.
Risk — Entra ID automatically assesses sign-in and user risk. Unusual behaviour is detected. Compromised accounts are locked.
Quick Checklist: Conditional Access Policies
Policy
Goal
Action
MFA for Admins
Protect privileged accounts
Enforce MFA
Blocked Countries
Stop attacks from high-risk regions
Block access
Compliant Devices
Allow only secure devices
Require compliance
Block Legacy Auth
Prevent insecure protocols
Block
Session Timeout
Reduce risk during inactivity
Limit session
App Protection
Protect sensitive apps
Require MFA + Compliance
To-Do List for Conditional Access
Day 1: Activate report-only mode.
Week 1: Define baseline policies.
Week 2: Enforce MFA for all admins.
Week 3: Block legacy authentication.
Month 1: Introduce device compliance.
Month 2: Implement location-based policies.
Month 3: Implement risk-based policies.
Comparing MFA Methods
Not all MFA methods are equal. Some are more secure, others more user-friendly. The right choice depends on the context.
Microsoft Authenticator — Push notifications are simple. Number matching increases security. Passwordless login is possible.
FIDO2 Security Keys / Passkeys — Hardware-based and phishing-resistant. Ideal for high-security environments and administrators. Slightly higher cost.
SMS and Phone — Easy to implement, but less secure. Recommended only as a fallback.
Windows Hello for Business — On-device biometrics. Very user-friendly. Requires compatible hardware.
Meeting Compliance Requirements
BSI C5 demands strong authentication; Conditional Access delivers it. ISO 27001 based on IT-Grundschutz requires documented access control; Conditional Access logs every decision. NIS2 recommends Zero Trust; Conditional Access is a core component and supports the Data Protection Impact Assessment for cloud services.
Integration with Other Services
Conditional Access does not stand alone. It integrates with Microsoft Defender, uses Intune for device compliance, and connects to a SIEM (e.g., Microsoft Sentinel) for monitoring. A well-designed Azure Landing Zone includes the Conditional Access baseline from day one, and managed services keep the policies monitored.
Insight42 Conditional Access Services
We design Conditional Access strategies tailored for public authorities — compliant with BSI C5 and IT-Grundschutz, and user-friendly. From analysis to implementation and managed operations.
GDPR-Compliant Cloud Usage: Technical and Organisational Measures (TOMs) in Azure and GCP
Resilience, Security 22nd Aug 2026Martin-Peter Lambert
Article 32 of the GDPR calls for “appropriate technical and organisational measures” (TOMs) to ensure a level of security appropriate to the risk. But what does this mean in practice in the cloud? How do you translate legal requirements into technical configurations in Azure or GCP? This article is the practical follow-up to our guide to the Data Protection Impact Assessment for the cloud.
From Requirement to Technology
This article shows how to practically implement the abstract requirements of the GDPR using the native tools of the major cloud platforms. The cloud provider only supplies the tools; the authority, as the controller, is responsible for their correct use — the same shared-responsibility logic that applies to BSI C5.
Mapping GDPR Requirements to Cloud Services
1. Pseudonymisation and Encryption (Art. 32(1)(a))
Goal: Make data unreadable to unauthorised persons.
Azure — Encryption at Rest: Transparent Data Encryption (TDE) for databases, Storage Service Encryption for storage accounts.
Azure — Encryption in Transit: Enforce TLS 1.2+ for all connections.
Azure — Key Management: Azure Key Vault for secure storage and management of keys (Bring Your Own Key – BYOK possible; Managed HSM for HYOK).
GCP — Encryption at Rest: Enabled by default for all services.
GCP — Encryption in Transit: Default for all connections.
GCP — Key Management: Cloud Key Management Service (Cloud KMS), also with BYOK and External Key Manager options.
Goal: Ensure that only authorised persons can access data and that it cannot be altered unnoticed.
Azure — Access Control: Entra ID with Conditional Access and MFA, Privileged Identity Management (PIM) for admin rights.
Azure — Network Security: Network Security Groups (NSGs) and Azure Firewall for segmentation.
GCP — Access Control: Cloud IAM with Conditions, Identity-Aware Proxy (IAP) for Zero Trust access.
GCP — Network Security: VPC Firewall Rules and Cloud Armor.
3. Availability and Resilience (Art. 32(1)(b))
Goal: Ensure that systems function even in the event of disruptions or attacks.
Azure — High Availability: Use of Availability Zones and Availability Sets.
Azure — Scalability: Virtual Machine Scale Sets, App Service Plans.
GCP — High Availability: Distribution of instances across multiple zones.
GCP — Scalability: Managed Instance Groups (MIGs).
4. Recoverability (Art. 32(1)(c))
Goal: Be able to quickly restore data and systems after an incident.
Azure: Azure Backup for backing up VMs, databases, and file shares. Azure Site Recovery for disaster recovery.
GCP: Backup and DR Service, Snapshots for Persistent Disks.
5. Regular Testing and Evaluation (Art. 32(1)(d))
Goal: Continuously verify the effectiveness of the TOMs.
Azure: Microsoft Defender for Cloud for monitoring security configuration and detecting threats. Azure Policy for enforcing compliance rules.
GCP: Security Command Center for centralised vulnerability and compliance management.
Quick Checklist: Important TOMs in the Cloud
TOM Category
Measure
Implemented?
Encryption
Data-at-Rest & Data-in-Transit fully active
☐
Access
MFA for all administrative and privileged accounts
☐
Network
Strict segmentation and firewall rules
☐
Backup
Regular, tested backups of all critical systems
☐
Monitoring
Continuous monitoring of security configuration
☐
Patching
Timely application of security updates
☐
TOMs as Part of the Security Concept
The defined TOMs are a central component of the security concept according to BSI C5 or IT Baseline Protection. They demonstrate how information security objectives are technically implemented. Good documentation of the TOMs is therefore essential not only for GDPR but also for audits according to BSI C5, ISO 27001 or NIS2.
Cloud consulting for public authorities helps to select and implement the right TOMs for your specific requirements. It is not about doing everything that is technically possible, but what is appropriate for the risk.
Insight42: We Make Your Cloud GDPR-Compliant
We translate the GDPR into the language of the cloud. We configure Azure, AWS and GCP to meet the requirements for technical and organisational measures — securely, documented, and auditable. Our managed cloud operations include the continuous monitoring and optimisation of your TOMs, so that your data protection level remains high even as threats and technologies change.
Cloud Key Management: BYOK vs. HYOK in Azure and GCP
Security, Sovereignty Series 22nd Aug 2026Martin-Peter Lambert
Encryption is the foundation of cloud security. But who controls the keys? By default, the cloud provider does. This is convenient, but often not sufficient for sensitive government or regulated data — because whoever controls the key can decrypt the data, and that includes the provider itself and potentially foreign authorities. This article is the practical companion to our guide on digital sovereignty for the public sector and compares the two models that put key control back in your hands.
Whoever Holds the Key, Holds the Power
The solution: take control of your keys yourself. The two most important models for this are Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK), also known as external key management.
Bring Your Own Key (BYOK)
The principle: You create your keys in your own environment (e.g., with an on-premises Hardware Security Module – HSM) and securely import them into the cloud provider’s key management system (e.g., Azure Key Vault, GCP Cloud KMS).
Advantages:
Full control over the creation and lifecycle of the key.
The key can be revoked (deleted) at any time, rendering the data unusable.
Relatively simple integration with most cloud services.
Disadvantages:
The key is physically located in the provider’s cloud. Access by the provider, though unlikely, is not 100% technically impossible.
Provider services: Azure Key Vault (Premium tier), GCP Cloud KMS with imported keys, AWS KMS with imported key material.
Hold Your Own Key (HYOK) / External Key Management
The principle: The key never leaves your own controlled environment. The cloud services send the data to be encrypted or decrypted to your external key manager. The key itself is never transferred.
Advantages:
Maximum control and sovereignty. The key is physically and logically separate from the cloud.
Access by the cloud provider or third parties is technically impossible without your key manager.
Disadvantages:
Higher complexity and potentially higher latency.
Requires a highly available key management infrastructure of your own.
External key management is not an isolated topic. It must be integrated into the overall BSI-compliant cloud security concept. It is a central measure for meeting the requirements of BSI C5, IT Baseline Protection, NIS2 and GDPR.
The processes surrounding key management must be clearly defined and documented. Who can create keys? Who approves their use? What happens in an emergency? IT Baseline Protection consulting helps to design these processes robustly.
Insight42: Cloud Key Management Expertise
We help you regain control over your keys and thus your data. We analyse your needs, compare the solutions, and implement the model that is right for you — whether it’s BYOK with Azure Key Vault or HYOK with external HSMs.
Preparing for a BSI C5 Audit: Practical Tips for the Public Sector
Resilience, Security 22nd Aug 2026Martin-Peter Lambert
You have decided on BSI C5. Implementation is underway. Now comes the audit. How do you prepare? What can you expect? This article is the practical follow-up to our BSI C5 Cloud Certification guide and walks through documentation, evidence, typical findings and interview preparation.
The Audit is Approaching
BSI C5 audits are thorough. Auditors want to see evidence — not just documents, but also established practices. Since April 2026 the reference catalogue is C5:2026; if your attestation period starts after mid-2027, prepare against the new criteria (container management, tenant isolation, confidential computing, post-quantum cryptography, supply chain).
Documentation is Everything
No attestation without documentation. Auditors can only audit what is documented. Every control needs evidence. Every process needs a description.
What must be documented: Security policies and their approval, process descriptions with responsibilities, configuration standards and their implementation, employee training records, and logs as proof.
The Most Common Audit Findings
Preparation also means avoiding mistakes. These findings are common:
Incomplete Documentation
Controls exist but are not documented, or the documentation is outdated. Solution: Keep documentation current by automating evidence collection from your cloud platform, so reality and documentation stay in sync.
Missing Evidence
Processes are followed but not logged. Solution: Enable logging and recording.
Inconsistent Implementation
Policies exist but are not followed. Solution: Conduct regular internal audits.
Unclear Responsibilities
No one feels responsible. Solution: Create a RACI matrix.
Quick Checklist: Audit Preparation
Document
Content
Current?
ISMS Manual
Overall Security Overview
☐
Security Policies
All Policies
☐
Risk Analysis
Current Assessment
☐
Asset Register
Complete Inventory
☐
Access Matrix
Permissions Documented
☐
Incident Log
Incidents Logged
☐
Training Records
All Employees
☐
Audit Trail
Changes Traceable
☐
To-Do List for Audit Readiness
8 weeks prior: Fully review documentation.
6 weeks prior: Conduct an internal pre-audit.
4 weeks prior: Remediate findings.
2 weeks prior: Compile evidence.
1 week prior: Brief interview partners.
Audit Day: Stay calm, cooperate.
After Audit: Remediate findings promptly.
The BSI-Compliant Cloud Security Concept
The security concept is the centrepiece. It comprehensively describes your cloud security. Auditors will read it carefully.
Contents of the Security Concept:
Scope and demarcation of cloud use, risk analysis and assessment, technical and organisational measures, responsibilities and processes, and emergency and business continuity management.
IT baseline protection consulting helps with its creation. ISO 27001 based on IT-Grundschutz provides the structure. The result: an audit-proof document.
Mastering Interviews
Auditors conduct interviews. They want to understand how controls are put into practice. Brief every interview partner on their controls, the evidence that backs them and the process for exceptions — preparation is of the utmost importance.
Continuous Compliance
BSI C5 is not a one-time project; it is a continuous process. After the audit is before the audit — especially for a Type 2 attestation, where the controls must demonstrably work throughout the audit period.
Cloud managed services for authorities help with this through continuous monitoring, regular reviews, and automated compliance checks. Azure and GCP native tooling provides dashboards showing compliance status and alerts for deviations.
Insight42 Audit Support
We guide you through the audit: preparation, execution, and follow-up, with experienced consultants by your side. We create the BSI-compliant cloud security concept together with you and implement the technical controls that back it.
KI im Unternehmen: Warum die meisten Projekte scheitern — und wie Sie KI liefern, die Ihre Compliance-Abteilung freigibt
AI In The Public Sector 22nd Aug 2026Martin-Peter Lambert
Jeder Vorstand will KI auf der Roadmap. Die meisten Unternehmen bekommen eine Chatbot-Demo, Compliance-Kopfschmerzen und einen gestoppten Pilot. Hier ist, was in europäischen KI-Projekten wirklich schiefläuft — und die Architektur, mit der Sie vom Proof-of-Concept zur Produktion kommen, ohne Ihre Daten, Ihr Budget oder Ihre DSGVO-Position aufs Spiel zu setzen.
Die unbequeme Wahrheit über Unternehmens-KI 2026
Der Druck ist real: Wettbewerber kündigen Copiloten an, der EU AI Act ist in Kraft, und „Wie sieht unsere KI-Strategie aus?“ ist zur Vorstandsfrage geworden. Doch die meisten KI-Initiativen in Unternehmen kommen nie über die Pilotphase hinaus. Nicht weil die Modelle schwach wären — heutige Modelle sind erstaunlich — sondern weil die Projekte drumherum die vier Zwänge ignorieren, die die europäische Realität prägen: Datenschutz, Datenreife, Souveränität und Rechenschaftspflicht.
Bei Insight42 bauen wir KI-Systeme für Organisationen, bei denen „move fast and break things“ keine Option ist — regulierte Branchen, der öffentliche Sektor und Unternehmen, die schlicht nicht bereit sind, Kundendaten in eine Blackbox im Ausland zu schicken. Dieser Artikel destilliert, was wir im Feld sehen: die Herausforderungen, die KI-Projekte töten, den Ansatz, der funktioniert, und die Vorteile, die Sie tatsächlich messen können.
Fünf Herausforderungen, die europäische KI-Projekte töten
1. Die Compliance-Mauer
DSGVO, der EU AI Act, Branchenregeln wie BSI C5 — bis die Rechtsabteilung ein US-gehostetes KI-Tool geprüft hat, ist die Dynamik des Piloten tot. Der Versand personenbezogener Daten an Drittland-APIs wirft Schrems-II-Fragen auf, die kaum ein Anbieter beantworten kann, und „der Anbieter sagt, das sei in Ordnung“ ist in einem Audit keine verteidigbare Position.
2. Daten, die nicht bereit sind
Modelle sind nur so gut wie die Daten, die sie erreichen. In den meisten Organisationen liegen diese Daten in Silos, ohne Governance, und enthalten personenbezogene Informationen, die niemand klassifiziert hat. Ein Sprachmodell auf diese Landschaft anzusetzen schafft keine Intelligenz — es schafft selbstbewussten Unsinn mit einem Datenschutzproblem.
3. Vendor-Lock-in als Bequemlichkeit getarnt
Der einfachste Weg — die gebündelte KI-Suite eines Hyperscalers — wird still und leise zum teuersten. Preise ändern sich, Modelle werden abgekündigt, und die Wechselkosten wachsen mit jedem verdrahteten Workflow. Souveränität ist keine Ideologie; sie ist Verhandlungsmacht.
4. Halluzination ohne Rechenschaftspflicht
Ein Modell, das in einem Consumer-Chat eine Antwort erfindet, ist amüsant. Dasselbe Verhalten in einer Beschaffungsentscheidung, einem Bürgerservice oder einem medizinischen Kontext ist eine Haftungsfrage. Ohne Grounding, Evaluation und menschliche Aufsicht ist generative KI eine Risikomaschine — und der EU AI Act verlangt jetzt den Nachweis des Gegenteils.
5. Piloten ohne Weg zur Produktion
Die Demo beeindruckt; dann kommt die Realität: Identität und Zugriff, Logging, Kostenkontrolle, Monitoring, Updates. Die meisten Piloten waren nie darauf ausgelegt, den Kontakt mit dem IT-Betrieb zu überleben — also überleben sie ihn nicht.
Der Insight42-Ansatz: Souveräne KI, technisch sauber umgesetzt
Souveräne Architektur als Standard. EU-Region oder On-Premises-Bereitstellung, Ihre Schlüssel (BYOK/HYOK), Ihre Datenresidenz. Das Modell kommt zu Ihren Daten — Ihre Daten werden nie zu den Trainingsdaten von irgendjemand anderem.
Grounded Generation (RAG) auf governten Daten. Wir verbinden Modelle über Retrieval mit Ihren Dokumenten und Systemen — mit Quellenangaben — damit Antworten auf Ihr eigenes Wissen zurückführbar sind, nicht auf die Fantasie des Internets.
Agentische Automatisierung mit Mensch in der Schleife. KI-Agenten, die mehrstufige Workflows ausführen — Triage, Entwürfe, Abgleich — innerhalb von Leitplanken, mit Freigabe-Gates dort, wo der Einsatz es verlangt. Mehr dazu in unserer Agentic AI Beratung.
EU-AI-Act-Konformität by Design. Risikoklassifizierung, Dokumentation, Logging und Evaluation sind Teil der Lieferung — nicht vor dem Audit angeklebt.
Eine Use-Case-Pipeline statt eines Mondschusses. Wir beginnen dort, wo ROI in Wochen nachweisbar ist — dann skalieren wir, was funktioniert. Jeder Use Case bekommt eine Kennzahl, bevor er ein Modell bekommt.
End-to-End-Lieferung. Strategie, Datenplattform, Implementierung und Betrieb aus einem Team — keine Übergabeverluste zwischen Folie und Deployment.
Die Vorteile — in Zahlen, die Ihr CFO versteht
Durchlaufzeiten sinken: Dokumentlastige Prozesse (Support, Beschaffung, Reporting) beschleunigen sich spürbar, sobald grounded KI den ersten Entwurf übernimmt — die konkrete Kennzahl definieren wir pro Use Case vor dem Start.
Compliance wird zum Aktivposten: Auditierbare KI — mit Datenresidenz, Logging und dokumentierten Risikoklassen — macht aus „Dürfen wir KI einsetzen?“ eine Checkliste statt eines Blockers.
Keine Lock-in-Prämie: Modellagnostische Architektur bedeutet, Sie tauschen Modelle, wenn sich der Markt bewegt — und verhandeln aus einer Position der Stärke.
Wissen verlässt nicht mehr die Tür: RAG über Ihre eigene Dokumentation macht institutionelles Wissen durchsuchbar, zitierbar und ab Tag eins nutzbar.
Teams, die annehmen statt abzulehnen: Gemeinsam entwickelte Workflows und Schulungen machen aus KI ein Alltagswerkzeug statt einer Bedrohungserzählung.
Wo Sie anfangen
Wenn Sie eines aus diesem Artikel mitnehmen: Beginnen Sie nicht mit einem Modell — beginnen Sie mit einem Use Case, einer Kennzahl und Ihrer Datenrealität. Unsere Teams für Generative KI und Agentische KI führen genau diese Übung mit Kunden durch: ein fokussiertes Assessment, das in einer priorisierten, compliance-geprüften KI-Roadmap endet, die Sie noch in diesem Quartal umsetzen können. Wenn Ihre Daten eine EU-kontrollierte Infrastruktur verlangen, ist unsere Souveräne Cloud Beratung der passende Startpunkt.
Enterprise AI in Europe: Why Most Projects Stall — and How to Ship AI Your Compliance Team Can Approve
Uncategorized 18th Aug 2026Martin-Peter Lambert
Enterprise AI should not end at a chatbot demo. It should become a secure, measurable capability that your business, IT and compliance teams can stand behind.
Every board wants artificial intelligence on the roadmap. Yet many organisations still reach the same frustrating point: an impressive proof of concept, followed by a compliance debate, fragmented data, unclear ownership and a pilot that never becomes part of day-to-day operations.
The problem is rarely a lack of model capability. The real challenge is the work around the model: deciding where AI genuinely creates value, making the right data available safely, designing meaningful human oversight, and operating the solution with the same discipline applied to any other business-critical service.
For European organisations, that work now takes place within an evolving regulatory environment. The EU AI Act uses a risk-based approach, and its obligations vary by the system’s intended purpose and the actor’s role. High-risk use cases can require, among other things, risk management, data-quality controls, logging, technical documentation, human oversight, accuracy and cybersecurity measures — with the Digital Omnibus of July 2026 deferring the Annex III high-risk obligations to December 2027 while transparency and AI-literacy duties already apply. GDPR principles remain directly relevant whenever personal data is processed, including purpose limitation, data minimisation, integrity and confidentiality.
At Insight42, we help organisations move beyond experiments and into real-world AI delivery. Our work connects strategy, architecture, implementation, adoption and operations, so that technology creates outcomes rather than another isolated pilot.
The uncomfortable truth about enterprise AI in 2026
The pressure to adopt AI is real, but a model alone is not a strategy. A sensible programme starts with a business workflow, a measurable outcome and a clear understanding of the data and decision rights involved. It then selects the models, retrieval pattern, automation boundaries and deployment environment that fit those constraints.
This is especially important in regulated industries, public-sector services and organisations that need strong control over sensitive knowledge. In those settings, it is not enough for an assistant to produce fluent answers. Teams need to understand which source material informed an answer, who may approve an action, how a result can be challenged, and what happens when the system is unavailable or wrong.
The key shift is simple: treat AI as an engineered business capability, not as a disconnected interface.
Five challenges that stop European AI projects
1. Compliance is reviewed too late
A common pattern is to build a promising demo first and ask legal, security and data-protection stakeholders to approve it later. That sequence creates rework, not speed. The EU AI Act does not regulate every AI system in the same way; classification depends on the intended purpose, context and role. But for relevant high-risk systems, the Commission identifies requirements such as risk management, traceability, documentation, human oversight, robustness and cybersecurity.
The practical response is not to turn every use case into a legal project. It is to bring the right stakeholders into the discovery phase, define permissible data and actions early, and document the decisions that shape the solution.
2. The data is not ready for the task
Models cannot correct an organisation’s information architecture by themselves. Knowledge may sit across shared drives, line-of-business systems and email archives, with different owners, access rules and quality levels. Feeding that landscape into an assistant without selection, access control and ownership can create privacy, security and quality problems.
A more reliable pattern is grounded generation: retrieve relevant, governed enterprise content at the moment of use; present the sources; and give the user a way to verify the answer. Insight42’s AI architecture work includes RAG design, vector stores, safety filters and evaluation harnesses precisely because useful output depends on the system around the model, not only on the model itself.
3. Convenience turns into lock-in
A bundled AI suite can be the quickest route to a first prototype. It can also make future choices harder if prompts, integrations, identity patterns and operational data are all tied to one provider’s proprietary layer. Digital sovereignty is not an abstract preference; it is the ability to make deliberate decisions about deployment, data residency, keys, models and commercial terms.
The answer is not to avoid cloud or refuse all managed services. It is to make portability, interfaces and exit options visible in the architecture. Decide where a provider-specific service is an intentional trade-off and where model-agnostic components protect the organisation’s flexibility.
4. There is no credible assurance loop
A fluent answer is not necessarily an accurate or appropriate one. In customer service, procurement, citizen-facing services or internal decision support, AI output needs the right evidence, guardrails and escalation path. The risk rises when an answer is presented as authoritative, triggers a workflow, or affects a person.
A production system therefore needs more than a prompt. It needs test cases derived from real tasks, defined acceptance criteria, source-grounding checks, monitoring, feedback capture and clear human approval points. These controls complement the human oversight and traceability themes reflected in the EU AI Act’s high-risk framework.
5. The pilot has no route into operations
A demo can be built in days. A service that earns trust needs identity and access management, audit logging, integration boundaries, cost visibility, support ownership, monitoring and a lifecycle plan for models and prompts. If those questions arrive after the demo, the pilot becomes technical debt before it ever serves a user.
Production readiness is therefore a design concern from the first workshop. It is also why Insight42’s approach spans adoption, monitoring, feedback loops, model lifecycle and cost control—not only initial implementation.
The Insight42 approach: sovereign AI, engineered
Insight42 does not start by asking, “Which model should we buy?” We start with the problem worth solving, the people affected, the data that may be used and the evidence that will show the solution is working. That creates a delivery path that is business-driven, technically credible and ready to withstand scrutiny.
Delivery layer
What it establishes
Practical outputs
Discover
A prioritised use-case pipeline tied to a business decision or workflow.
Value hypothesis, baseline metric, user journey, risk and data assessment.
Govern
Clear boundaries for data, roles, deployment and approvals.
System classification review, data-access rules, decision rights, logging and documentation plan.
Build
A secure, grounded and usable AI workflow.
Retrieval pattern, integrations, safety controls, evaluation harness and exception handling.
Adopt
A workflow people can use responsibly.
Training, playbooks, user feedback, ownership and human-in-the-loop gates.
Operate
Measurable, resilient performance over time.
Monitoring, lifecycle management, incident handling, cost controls and continuous improvement.
Sovereign architecture by design
Deployment should follow the organisation’s requirements, not a one-size-fits-all assumption. Depending on the context, that may mean an EU-region cloud configuration, a dedicated environment, customer-managed keys, an on-premises approach, or a deliberately chosen mix. The guiding principle is control: know where data goes, who can access it, how it is protected, and which decisions remain with the organisation.
Grounded generation over governed knowledge
For enterprise knowledge work, the most valuable AI is often not the one that knows the most about the internet. It is the one that can locate the right internal information, respect existing permissions, cite the source and help a colleague take the next step. Retrieval-augmented generation can support that pattern when it is designed around information quality, access control, source traceability and evaluation.
Agentic automation with meaningful human control
AI agents can support multi-step work such as triage, drafting, reconciliation and information gathering. The right level of autonomy depends on the workflow. Low-consequence actions may be automated within strict limits; higher-consequence actions should stop at a clear review and approval point. Human oversight becomes a practical workflow design choice, not a vague promise.
Compliance and assurance built into delivery
Risk classification, documentation, transparency, logging, evaluation and oversight should evolve alongside the solution. This is not legal advice, and it does not replace the organisation’s own assessment of legal obligations. It does, however, create the technical and operational evidence that security, privacy, legal and business owners need to make informed decisions.
Benefits your CFO can verify
The case for AI becomes stronger when it is expressed as an operating metric, not an impressive promise. Rather than claiming a universal percentage improvement, agree the baseline before the build and track the outcome that matters in the live workflow.
Business objective
Example measure
What a good target looks like
Faster work
End-to-end cycle time, queue time or first-draft time.
Less time spent locating, reformatting or summarising trusted information.
Better quality
Source-citation rate, reviewer acceptance rate, escalation rate and rework.
Output is traceable, relevant and easier for a qualified person to verify.
Lower operational risk
Coverage of access controls, logged actions, exception handling and approval gates.
Important workflows have visible owners and predictable fallbacks.
Stronger knowledge reuse
Search success, reuse of approved content and time to locate policy or case information.
Institutional knowledge becomes easier to find without weakening permissions.
Sustainable economics
Cost per resolved case, workload volume, platform spend and support effort.
Adoption grows without uncontrolled cost or operational overhead.
This approach creates a clearer conversation with finance, technology and compliance: what changed, how do we know, and who owns the result?
Where to start
Do not begin with a model. Begin with one process where the value can be measured, the data can be understood and the right people can participate in the design. A focused assessment can identify the workflow, establish the baseline, surface the key compliance and data questions, and produce a prioritised roadmap for delivery.
Insight42’s Generative AI and Agentic AI teams support that journey from strategy and use-case discovery through architecture, implementation, adoption and operations. The goal is not AI slideware. It is an AI capability that works simply—and simply works for your organisation. German readers: see our Agentic AI Beratung and the German version of this article, KI im Unternehmen: Warum die meisten Projekte scheitern.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
