Hosting and data residency

Kaisa runs inside EG's Azure environment — the same environment that hosts the rest of EnerKey.

• Cloud provider Microsoft Azure

• Tenancy EG-owned Azure subscription

• Region EU (matches the EnerKey platform)

• Network isolation Critical services live inside a private Virtual Network — not reachable from the public internet

• Edge protection Web Application Firewall (WAF), DDoS protection, TLS termination

• Compute Managed Azure compute

• Conversation storage Managed Azure database, encrypted at rest

• Secrets management Azure managed identities and Azure Key Vault — no long-lived credentials in application code

Your data does not transit through third-party SaaS AI vendors. There is no path from Kaisa to any public LLM service.

Profile-scoped data access

Kaisa authenticates through your existing EnerKey identity. No separate account, no shadow login. Every API call carries a short-lived Bearer JWT issued by the EnerKey identity provider.

Authorization is inherited from EnerKey, not invented for AI. Kaisa can only call the APIs your user is already entitled to call, and can only see data your user is already entitled to see. If a user doesn't have access to a product area, Kaisa doesn't get those tools.

In EnerKey, a profile is a collection of facilities, sites, and meters grouped together by your administrators. Kaisa always operates inside the currently active profile, the same one selected in the rest of the portal. It cannot reach data in facilities outside it. Switching profiles starts a clean conversation context. There is no AI-side mechanism to widen data scope.

Conversation isolation. Each user's conversation history is isolated. No user can read another's, regardless of role.

Role mapping is enforced server-side. Hiding a feature client-side is never the security boundary.

Kaisa never has access broader than the human using it.

Enterprise AI is not like consumer AI

Kaisa uses GPT-class large language models via Azure OpenAI Service. The enterprise Azure deployment, not the consumer OpenAI API.

The Azure OpenAI terms applicable to EG:

• Your prompts and completions are not used to train OpenAI's or Microsoft's foundation models

• Data stays within the EU Azure region

• Model versions are tracked, pinned, and upgraded under change control. No silent swaps behind production traffic

The model is invoked without any standing access to your databases. Every data retrieval goes through the controlled tool layer described below.

What the model can actually do, and what it can't

A large language model is a text generator. It can answer questions about your data only if something hands it that data. We treat that "something" as a security boundary.

Between the model and EnerKey's APIs sits an orchestration layer. A layer built on a mature, Microsoft-backed agent framework, that mediates every tool call. The model has no free SQL connection, no code execution sandbox, and no generic web access.

Only an explicit, allow-listed set of EnerKey APIs is exposed to the model as tools. Endpoints are reviewed and approved by EG's engineering team before they enter Kaisa's surface.

Every tool call:

• Goes through the same EnerKey API gateway as any normal portal request

• Carries the end-user's JWT, not a service principal

• Is enforced by the same downstream role checks as the UI

• Is logged with the user, profile, conversation, tool name, and parameters

Write and update operations are not exposed to Kaisa. It has read-only access to platform data. If a request requires data the user doesn't have rights to, it fails at the API layer, the same way it would fail in the UI. Kaisa cannot bypass that.

Multiple safety layers on every message

Every user turn passes through several layers before it reaches the model. Every model response passes through layers on the way back.

• Prompt injection and jailbreak defenses: Managed Microsoft AI safety services screen inputs — including content inside uploaded documents — for known attack patterns before they reach the model.

• PII detection: Managed services identify personally identifiable information on inputs and outputs, handled according to EG's content policy.

• Harmful-content filtering: Managed filters cover hate, sexual, violence, and self-harm categories, configured for an enterprise B2B context.

• Topical scoping: Kaisa operates within a defined scope: energy, facilities, sustainability, and EnerKey workflows. Out-of-scope requests are declined.

• Document handling: When users attach documents (PDF, DOCX, XLSX, CSV, PPTX, TXT, JSON) as context, they are processed inside the same Azure tenancy, scanned, and treated as untrusted input. Content in documents is data — not instructions.

Engineering and operational controls

Every change to Kaisa ships through pull requests with mandatory code review. No live editing of prompts or tool definitions in production. Each release is tagged and can be rolled back.

Container images and dependencies are scanned continuously; patching follows a defined SLA. The platform — including the Kaisa surface — is included in EG's regular third-party penetration testing program, with findings tracked to closure.

Structured logs and traces cover every chat turn: who, when, which tools were called, latency, and any safety-filter actions. Logs are retained according to EG's data retention policy and are accessible to EG's security team for investigation. Incident response is covered by EG's group-wide process.

Your data and your rights

Conversations are retained until you delete them. From the Kaisa UI, you can rename or delete any conversation at any time. Deletion is permanent.

Documents you upload as context can be deleted at any time, permanently.

GDPR data-subject rights — access, rectification, restriction, portability, and erasure — follow the existing EnerKey Data Subject Request process. There is no separate Kaisa workflow.

Operational logs (tool calls, safety filtering, latency) are retained under EG's group retention policy and accessible only to EG's security and operations teams.

Compliance posture

GDPR — Kaisa processes personal data only as part of the EnerKey service. The lawful basis, controller/processor relationship, and data subject rights follow the existing EnerKey Data Processing Agreement. No separate AI DPA is required.

EU AI Act — Kaisa is classified and reviewed against the AI Act's risk tiers. It operates as a decision-support assistant — not as an autonomous decision-maker for energy or financial actions.

Data residency — EU region, EG-owned Azure subscription.

ISO / certifications — Inherited from the underlying EG EnerKey platform. Refer to EnerKey Trust documentation for the current list of certifications.

Sub-processors — Microsoft Azure (cloud platform, model hosting, and AI safety services) and EG's edge-protection provider. No additional AI sub-processors.

What Kaisa doesn't do

We think this list matters as much as everything above.

• Does not train any model on your data

• Does not send your data to OpenAI, Anthropic, Google, or any consumer AI service

• Does not use a standing service-account login — it uses your session

• Does not execute arbitrary code on your behalf

• Does not browse the open internet

• Does not persist documents or data outside the EnerKey environment

• Does not expose tools or data beyond the user's existing EnerKey role and active profile

For your security team

Completing a vendor questionnaire? EnerKey can complete CAIQ, SIG, or custom security assessments for Kaisa alongside the platform. Architecture diagrams and a redacted penetration testing summary are available under NDA.

Contact your EnerKey account manager to start the process.

Reporting a security issue: security@enerkey.com or via your usual EnerKey support channel.