Managed Hosting
Die Anwendung läuft auf unserer Infrastruktur. Wir übernehmen Bereitstellung, Updates, Überwachung, Sicherung und Wiederanlauf.
Betrieb aus einer HandHosting and local AI from Itzehoe.
Applications, models and hardware under understandable control.
We operate applications and local AI on our own infrastructure in northern Germany. Together we clarify model choice, data paths, GPU and storage needs, monitoring, recovery and ownership.
Your starting point
Signs that the operating model needs work
We start with the workload, data, risk and responsibility before deciding where systems should run.
01
Sensitive data should not leak into uncontrolled systems
Teams want to use AI, but data paths, logs, external administration and model changes are not clear enough.
02
The local AI prototype has no operating model
A model runs on a workstation, but load, permissions, monitoring, versioning and recovery are not defined.
03
Application, hardware and AI have different owners
During incidents, responsibility moves between software, hosting, model and hardware although users only need a working workflow.
04
Cloud promises do not answer the exit question
Data, configuration, models and logs need to remain transferable before the first productive dependency is created.
- IZET
- Firmensitz und Infrastruktur in Itzehoe
- 1 Haus
- Büro und Technik unter einem Dach
- RPO
- Sicherungs- und Wiederanlaufziel je Anwendung festlegen
- DE
- Betrieb und Datenhaltung in Deutschland
Warum Itzehoe
Nähe ist Teil unseres Betriebsmodells.
Unsere Infrastruktur steht am selben Standort wie unser Büro im IZET Innovationszentrum. Im Fehlerfall beginnt die Arbeit deshalb nicht mit der Suche nach einem anonymen Zuständigen.
Vor dem Umzug klären wir Abhängigkeiten, Wartungsfenster, Wiederanlauf und Rückweg. Danach bleiben Überwachung, Sicherung und dokumentierte Zuständigkeiten Teil des laufenden Betriebs.
Standort und Housing ansehenBetriebsmodelle
Drei Wege, keine anonyme Plattform.
Lokale KI
Sprachmodelle, Vektorsuche und sensible Wissensbestände laufen in einem kontrollierten Betriebsraum mit klaren Rollen und Datenwegen.
Modelle und Daten unter KontrolleCo-Hosting
Deine eigene Hardware steht im Rack. Strom, Netz und geregelter Zugang kommen von uns, die Maschine bleibt deine.
Eigene Hardware im IZETHybrid
Sensible Systeme laufen bei uns, weitere Dienste dort, wo es technisch und wirtschaftlich sinnvoll ist. Die Übergänge werden bewusst abgesichert.
Für gewachsene LandschaftenOperations and local AI
Host with ownership, not just somewhere.
We connect application, infrastructure, local AI, security and recovery. You know where data lives, who is responsible and what happens during an incident.
Infrastructure
Operate applications under control
Compute, storage, networking, certificates, logs, updates and recovery are planned as part of the application. Operations are not an afterthought.
- Cluster
- Monitoring
- Recovery
Local AI
Keep models and knowledge manageable
Language models, vector search and internal knowledge stores receive explicit data paths, roles, quality limits and traceable logs.
- Local LLM
- RAG
- Data paths
Co-hosting
Integrate your own hardware cleanly
If your machine belongs in the rack, we clarify power, cooling, access, networking, responsibility and the path back to your own environment.
- Rack
- Access
- Handover
Hybrid
Use cloud only where it helps
Sensitive systems remain local or with us, other services run where cost, availability and integrations fit better. The boundary is secured deliberately.
- Boundaries
- VPN
- Interfaces
Security
Plan operation and protection together
Segmentation, secrets, backup, patch level, roles and alerting are considered together. The result does not need to be hardened after launch.
- Segmentation
- Secrets
- Alerting
Cost
Measure capacity with real load profiles
GPU, model size, latency and storage are tested with representative requests. The best fit is decided by measured usefulness, not by model size.
- GPU
- Load test
- Cost per task
Operating decision in detail
From server wish to validated operating model.
Good infrastructure does not start with hardware. It starts with data, models, latency, failure impact and responsibility for a concrete workflow.
Phase 1 Understand the workload
Application, model, data classes, latency, utilisation and failure impact are assessed using real cases.
Phase 2 Define data paths and roles
Who may see what, what is logged, which data leaves the system and which approvals are required.
Phase 3 Choose the operating model
Managed hosting, local AI, co-hosting or hybrid setups are compared by protection need, cost and responsibility.
Phase 4 Validate the setup
Network, permissions, certificates, models, backups, recovery and monitoring are tested before production.
Operation Operate continuously
Updates, model changes, utilisation, alerts and recovery stay visible and are reviewed regularly.
Decision criteria
Production is sensible only when purpose, data paths, load profile and recovery work together.
Business purposeThe application or model solves a measurable task
Data controlSources, permissions, logs and deletion paths are known
Operational readinessLoad, updates, monitoring and recovery are tested
Protection needNetwork boundaries, secrets and access are documented
What you receive
- Operating concept for application, data and local AI
- Decision between managed hosting, local AI, co-hosting or hybrid
- Network, permission, backup and recovery plan
- Load test with realistic requests and clear cost assessment
- Monitoring, alerting and defined incident path
- Documented handover of data, configuration and hardware
Market and decision
What changes and what to clarify first
We assess infrastructure decisions by whether they improve control, quality, recovery and operating responsibility.
Development
Smaller local models become practical
For limited domain tasks, measured quality, data control, latency and total cost matter more than using the largest available model.
Development
RAG becomes an operating responsibility
Documents, permissions, updates, source visibility and deletion paths have to remain connected with the model operation.
Development
Sovereignty becomes measurable
Location, administrator access, model exchange, export, energy use and hardware demand are becoming concrete procurement criteria.
Primary sources · August 2026
Clarify before commissioning
- Define use case and quality boundary before buying hardware
- Document data classes, roles, logs and deletion paths
- Measure the load profile with real requests
- Test application, data and AI recovery together
- Clarify who operates models, updates and access rules
- Keep configuration, data and hardware handover documented
From workload to operation
A controlled path into production
- 01
Understand workload
Application, model, data classes, latency, utilisation and failure impact are assessed using real cases.
- 02
Define data paths
Permissions, logs, storage locations, provider access and deletion paths are made explicit.
- 03
Choose operating model
Managed hosting, local AI, co-hosting or hybrid setups are compared by need, cost and responsibility.
- 04
Validate setup
Network, certificates, permissions, models, backups and monitoring are tested before production.
- 05
Operate and review
Updates, model changes, utilisation, alerts and recovery stay visible during operation.
Outcome
What changes for your operation
1
Controlled data paths
You know which content reaches the system, which logs are created and who can access them.
2
Right-sized capacity
Model size, GPU needs and cost follow the task instead of a product promise.
3
Close to the infrastructure
During incidents, we can work directly on the systems instead of starting with an anonymous ticket queue.
4
Tested exit and recovery
Data, configuration, models and hardware remain available through a documented handover and recovery path.
FAQ
Common questions about hosting and local AI
Practical answers before infrastructure, model or migration decisions are made.
Is local AI automatically secure?
No. Purpose, data, permissions, logs, model origin, updates and human control still need to be assessed technically and organisationally.
Can you host our own hardware?
Yes. Co-hosting and hybrid setups are planned around rack space, power, cooling, network, access, utilisation and operating responsibility.
How do you size GPU capacity?
We test model size, quantisation, context, parallel use and latency with representative tasks before hardware is committed.
Can this be combined with cloud services?
Yes. Sensitive workloads can stay local while other services run where cost, availability and integration make more sense.
What happens if something fails?
Monitoring, alerting, backup, recovery order and responsible contacts are defined before production. Recovery is tested, not only described.
Further depth
Continue with practical guidance
Local AI operation
Define data, model, quality and responsibility before production.
Explore insightsRAG and internal data
Keep sources, permissions and deletion paths connected with retrieval.
Explore insightsCo-hosting in Itzehoe
Bring own hardware into a controlled operating environment.
Explore insightsRecovery planning
Test application, data and AI dependencies as one chain.
Explore insightsNext step
Discuss operation Put hosting and local AI on a reliable operating model
We clarify workload, data paths, hardware, model choice, monitoring and recovery. Afterwards you know which setup carries the risk, cost and responsibility.