TL;DR The German Federal Office for Information Security (BSI) has extended its IT-Grundschutz to AI applications. Anyone deploying AI in regulated environments must go beyond classic data-protection considerations. Which modules apply, what requirements hold for language models and RAG systems, and what an implementation path looks like.

Why BSI Grundschutz and AI go together

AI applications shift the security model. Classic protection goals like confidentiality, integrity and availability remain, but new risks emerge: training-data manipulation, prompt injection, model theft, unintended data leakage through language models.

Organisations deploying AI in regulated environments (federal authorities, critical-infrastructure operators, the defence-industry supply chain) must align their architecture with the BSI Grundschutz. The EU AI Act adds requirements for high-risk systems. BSI Grundschutz and EU AI Act complement each other.

Which BSI modules are relevant

The BSI Grundschutz uses thematic modules. For AI systems, particularly relevant:

  • - APP.4.6 General Applications as starting point for any AI application
  • - APP.7.x depending on application type (chatbots, recommender systems, image analysis)
  • - CON.10 Web Application Development for AI APIs and frontends
  • - OPS.1.1.5 Logging for traceability of model inference
  • - DER.2.x Detection for anomaly detection in operations
  • - NET.1.1 Network Planning for segmenting AI workloads
  • - SYS.1.x Servers for the hosting infrastructure

Additionally, the BSI publishes sector-specific guidance like the AIC4 (AI Cloud Service Compliance Criteria Catalogue) and recommendations for the secure use of language models. Anyone running AI on cloud platforms should consider both in parallel.

Specifics for language models and RAG systems

Language models and Retrieval-Augmented-Generation architectures have security requirements that classic applications do not have:

Prompt injection and jailbreaks. Inputs can change model behaviour in unintended ways. Inputs must therefore be treated as untrusted, even when coming from authenticated users. Output filters, prompt templating with clear separation of system and user instruction, and rate limiting are mandatory.

Data flow in RAG architectures. When the model accesses internal knowledge documents, the permissions architecture must filter these documents by user role. Otherwise the model leaks information through search that the user could not see in the original source.

Training and fine-tuning data. For models trained on proprietary data, training data must be classified, approved and handled by protection level. Personal data requires a legal basis under GDPR.

Model hosting. Self-hosting in a controlled environment is usually the only viable option for regulated users. External APIs without clear data residency, without contracts under German law and without audit capability do not meet BSI Grundschutz for elevated protection needs.

Steps for implementation

We recommend six steps for AI applications in regulated environments:

  1. 1. Protection-need analysis for the AI application. What data does the model process? What decisions do the outputs drive? This produces the protection level (normal, high, very high).
  2. 2. Identify relevant BSI modules. From application type and infrastructure. Map into a gap analysis.
  3. 3. Derive architecture decisions. Self-hosting vs API, model selection, RAG components, permissions model. These decisions are expensive to revise later.
  4. 4. Implement technical measures. Input validation, output filters, logging, detection, backup, encryption. With auditable configuration.
  5. 5. Organisational measures. Role concept, training, emergency plan, regular testing (including adversarial, e.g. red-team engagements).
  6. 6. Documentation and audit. Audit-ready evidence of measures, mapped to BSI modules. For elevated protection needs: additional penetration tests and model reviews.

Where things typically break down

Three patterns regularly underestimated in projects:

  • - Model selection becomes IT-driven instead of risk-driven. Teams pick the currently best-performing model without checking regulatory viability. At elevated protection levels, many commercial models are not usable, regardless of performance.
  • - Permissions handled at application level, not in the RAG layer. This leads to subtle data leakage that normal tests do not catch.
  • - No emergency plan. What happens if the model systematically delivers wrong answers? When is it shut down, who decides, how is it communicated?

Relationship to the EU AI Act

The EU AI Act and the BSI Grundschutz address different layers. The AI Act classifies applications by risk class and defines duties for high-risk systems. The BSI Grundschutz describes how those duties are implemented technically and organisationally, in the context of German information-security standards. The two frameworks are compatible and can be addressed in one programme.

How GermanAI Defense supports

We design and operate AI applications with clear permissions architecture, audited data flow and BSI-compliant documentation. Self-hosting on sovereign infrastructure in Germany, models and data under customer control, no third-country jurisdiction risk.

For federal authorities, critical-infrastructure operators and regulated mid-market. ISO/IEC 27001:2022 certified.

→ More on our AI Services: germanaidefense.com/ai-services