Private Cloud Security and Privacy by Design

The Problem with Bolt-On Security

Most cloud security frameworks start with a general-purpose infrastructure and add controls on top of it. Encryption layers are added. Access policies are defined. Audit logs are configured. The result is a compliant deployment in the sense that it passes a checklist. But the underlying infrastructure was not designed with those requirements in mind, and the controls sit on top of architecture choices that were made without them.

Privacy by design - the principle that privacy and security properties should be built into systems from the start rather than added afterward - is well understood as a concept in software development. In cloud infrastructure, it remains more principle than practice.

GreenPow's Private Cloud takes a different approach. The security and privacy properties of the deployment are not configurations applied to a generic platform. They are architectural requirements that shape how the platform is built.

Sovereignty and Residency as Infrastructure Properties

Data residency is often treated as a geographic constraint: data stays within a specified country or region. This is necessary but not sufficient.

True sovereignty in cloud infrastructure means three things:

Jurisdictional control: The legal framework governing the data and the infrastructure that processes it is unambiguous and known in advance. This matters for regulated industries, government IT, and any organization subject to cross-border data protection law.

Residency by enforcement: Data residency is enforced at the infrastructure level, not just declared in a service agreement. Workloads cannot escape the residency boundary due to misconfiguration, failover events, or provider decisions.

Personnel control: The humans with operational access to the infrastructure are known, vetted, and subject to appropriate controls. This covers both the customer's own staff and any infrastructure provider personnel with access to physical or logical layers of the environment.

GreenPow's Private Cloud provides all three as first-class infrastructure properties, not policy declarations.

Compliance Frameworks and What They Actually Require

DORA, NIS2, and the AI Act are the three European frameworks that most directly affect cloud infrastructure choices for regulated organizations.

They require, in different ways:

• Documented and tested ICT risk management frameworks
• Incident detection, response, and reporting capabilities
• Third-party risk management, including cloud providers as critical third parties
• For the AI Act, specific documentation and oversight requirements for high-risk AI systems using cloud infrastructure

Meeting these requirements on hyperscaler multi-tenant infrastructure is possible but difficult. The customer shares the infrastructure with unknown neighbors, has limited visibility into the physical layer, and is dependent on the provider's security posture for the shared components.

In a customer-owned, dedicated tenancy, the compliance surface is cleaner. The customer controls the physical boundary of the infrastructure. The audit trail covers every action taken within it. Third-party access is governed by documented agreements rather than shared responsibility models with broad carve-outs.

Privacy-Sensitive Workloads Need Private Runtime

The emergence of AI workloads in regulated environments adds a specific privacy challenge. AI systems trained on customer data, handling personal data, or generating outputs that affect individuals are subject to data minimization, purpose limitation, and auditability requirements under GDPR and the AI Act.

Running these workloads on shared hyperscaler infrastructure means accepting that the provider has visibility into the training data, the model weights, and the inference requests and outputs. For many regulated use cases, this is not acceptable.

GreenPow's Private Cloud provides a dedicated runtime environment where AI workloads run without provider access to the data or the model. Combined with Cortex for per-tenant isolated agent memory, it provides the complete stack for privacy-preserving AI in regulated environments.

Carbon Awareness Within the Security Boundary

Private cloud security requirements do not eliminate the possibility of carbon-aware optimization. MAIZX operates within compliance boundaries, not around them. Workloads that must remain in a specific jurisdiction do so. The temporal shifting and resource utilization optimization that reduces emissions happens inside that boundary.

The Carbon Ledger records Scope 2 emissions from infrastructure inside the security perimeter. This produces verifiable emissions data that satisfies reporting requirements without requiring any data or workload to leave its required boundary.

Security, sovereignty, and sustainability are not competing requirements in GreenPow's Private Cloud. They are solved together, from the same architectural foundation.