Clarify the task and decision
This guide turns assessing germany-hosted models into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
Verify every processing location and operator with architecture evidence rather than accepting a regional hosting label.
Practical workflow
- 1
Draw the data flow from collection through processing, logs, cache, support, backup, and deletion.
- 2
Classify each data category and connect it to purpose, legal role, location, recipient, and retention.
- 3
Request architecture, contractual, operational, and testing evidence for every material claim.
- 4
Score risk and record required controls, owners, acceptance evidence, and residual risk.
- 5
Approve only the documented configuration, then monitor subprocessors, incidents, changes, and deletion evidence.
Worked example or tool
An evidence map links each data flow to provider, location, purpose, retention, and contract. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Define what Germany-hosted must mean
A credible hosting claim covers the complete processing chain, not only the address of the application server. Document where prompts, uploaded files, generated text, logs, backups, support copies, monitoring data, and model telemetry are processed and stored. Include temporary processing and disaster-recovery locations because both can move data outside the intended boundary.
Separate contractual commitments from technical configuration. A region selector is useful evidence, but it is not a guarantee that support personnel, subprocessors, or failover services remain in Germany. Require a signed description of the service boundary, named facilities or cloud regions, and a change-notification obligation that applies throughout the contract term.
Use a precise internal definition such as: all customer content and content-derived operational data are processed in German data centres, with no remote access from outside the approved area unless the customer authorises a documented exception. This definition gives procurement, security, and legal reviewers one testable standard.
List every data category, including logs, backups, abuse monitoring, and support records.
Record primary, failover, and restoration locations separately.
Identify every organisation that can access customer data or encryption keys.
Convert marketing statements into signed, testable contract commitments.
Map the technical boundary and model supply chain
Draw a data-flow diagram from the user's browser or CMS to the final response. Mark gateways, queues, object stores, databases, model endpoints, content filters, observability tools, and administration systems. For each component, record operator, location, purpose, retention period, encryption method, and whether customer data can be used to improve a shared model.
Model hosting can involve several layers. The application may run in Frankfurt while inference is performed by an external model endpoint elsewhere. A locally deployed model can still send telemetry to its publisher. Verify the actual runtime endpoint, outbound network controls, model-download process, licence checks, and any remote management channel.
Ask the provider to demonstrate the boundary with configuration exports, architecture diagrams, subprocessor records, and a live walkthrough of the administration console. Evidence should be dated and versioned. Recheck it after material releases because an added safety, analytics, or support service can change the data path.
- 1
Trace one representative request and one file upload end to end.
- 2
Confirm the destination of every outbound connection from the production environment.
- 3
Compare architecture evidence with the data-processing agreement and subprocessor list.
- 4
Store the approved diagram and evidence set with an owner and review date.
Evaluate controls, operations, and separation
Location alone does not provide security. Assess tenant separation, identity management, privileged access, key ownership, vulnerability handling, secure deployment, backup restoration, and incident response. For sensitive public-sector material, require role-based access, strong administrator authentication, access logging, regular privilege review, and an emergency-access procedure with retrospective approval.
Clarify whether encryption keys are provider-managed, customer-managed, or dedicated to one tenant. Ask who can decrypt backups and how keys are rotated, revoked, and recovered. If strict separation is required, request evidence that model caches, vector stores, prompt logs, and evaluation datasets cannot be queried across customers.
Operational evidence matters more than a control list. Review a recent restoration test, a sample access review, security test scope, remediation tracking, and the incident communication process. Certifications can support the review, but they should not replace checking whether the certified scope includes the exact product and hosting environment being purchased.
Verify production access, emergency access, and support access separately.
Confirm encryption and key responsibilities for live data and backups.
Review independent assurance and the precise scope of each report.
Require evidence of restoration, incident, and vulnerability-management exercises.
Make the decision auditable
Use a decision record that states the intended data, required hosting boundary, evidence reviewed, unresolved risks, compensating controls, decision owner, and expiry date. Classify each claim as verified, contractually committed, planned, or not available. Only verified and contractually committed controls should support the approval decision.
For example, a communications team may approve public website text for a shared German-hosted service but exclude case files and unpublished personal data. The decision record should express that boundary in operational language and translate it into product configuration, user guidance, monitoring, and periodic sampling of actual usage.
Reassessment should be triggered by a new model family, hosting provider, subprocessor, region, telemetry function, or support arrangement. Add the evidence review to supplier governance rather than treating it as a one-time procurement task. This keeps the hosting claim accurate after the initial launch.
- 1
Score mandatory location and access requirements as pass or fail.
- 2
Score security maturity separately so location cannot conceal weak controls.
- 3
Approve a clearly bounded use case and encode the boundary in configuration.
- 4
Set annual and change-triggered reviews with named accountable owners.
Roles, evidence, and approval
Security and privacy reviews must describe the production configuration rather than a generic provider. Record the exact service, region, feature flags, optional telemetry, support access, subprocessors, encryption boundaries, retention settings, and customer responsibilities. Reassess after material architecture, contract, provider, or purpose changes and keep the decision linked to the evidence reviewed.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The complete processing path is documented.
Controller and processor roles are agreed.
Locations and subprocessors are evidenced.
Training and secondary use are explicitly addressed.
Access, encryption, logging, and incident controls are verified.
Retention and deletion are defined per data category.
International transfers and safeguards are documented.
Changes, audits, exit, and evidence ownership are assigned.