# Sencai - full site text

> EU-sovereign cloud operating platform. One control plane to provision, secure and
> optimize infrastructure across 11 cloud providers and on-premise servers.
> Built and operated in the Czech Republic by Sencai Tech s.r.o.

This file is generated from the site's English content at build time, so it cannot
drift from the pages it describes. For the short version see /llms.txt. For product
documentation (including the REST API and the MCP server) see https://docs.sencai.space.

---

## Positioning
Source: https://sencai.space/

### One platform to run your entire cloud.
Provision. Secure. Optimize.
Sencai unifies provisioning, security, FinOps, and AI-assisted operations across your cloud providers and your own on-prem servers - one control plane, so a small team can operate like an enterprise platform group.
Start free trial
See how it works
Fleet coverage
Cloud + on-prem
Cloud providers
11 integrated
Time to first deploy
< 30 minutes

## The problem Sencai solves
Source: https://sencai.space/

### Multi-cloud is the norm. Managing it is chaos.
73% of organisations now run hybrid estates (Flexera, 2026) - each provider with its own API, billing and security model. The result is a tool sprawl that small teams cannot keep up with.
#### Tool sprawl without a central view
Dozens of disconnected dashboards, each provider speaking its own language. Context switches kill productivity.
#### DevOps talent is scarce and expensive
A senior engineer runs €9,000-14,000 per month in Western Europe, with 5-6 months to hire. Most teams can't afford the wait.
#### Security gets bolted on - or skipped
Unpatched CVEs, expiring certificates, open ports. 79% of organisations had a security incident involving a vulnerability they already knew about (Cloud Security Alliance, 2026).
#### FinOps stops at dashboards
Wasted cloud spend is back up to 29% of the bill (Flexera, 2026). The problem isn't visibility - it's the absence of automated action.

## Capabilities (overview)
Source: https://sencai.space/

### Everything your platform team would build - already built.
Built around what platform teams actually do all day. No bloat, no feature theater.
#### Infrastructure
##### Cloud Provisioning
Provision, scale, and retire compute across every provider we integrate - EU-native (Hetzner, OVHcloud, Scaleway, UpCloud) and global (AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode, Oracle Cloud) - with managed databases, object storage, and DNS on the providers that offer them, from a single API and UI.
##### Import & Discovery
Already running in the cloud? Connect an account and Sencai discovers your existing VMs, networks, and storage - then promotes them into managed resources without re-provisioning anything.
##### Fleet Management
A lightweight agent for cloud instances, on-premise, and bare-metal servers - monitoring, patch management, software inventory, and a browser SSH terminal. Kubernetes clusters join the same fleet via Helm.
#### Day-2 Operations
##### Runbook Automation
Codify your incident response once, run it everywhere. Approval-gated runbooks executed by the fleet agent turn 3 a.m. firefighting into a reviewed, one-click action.
##### AI Operations
Automated root-cause analysis, alert correlation, and remediation recommendations powered by a pluggable LLM backend with per-tenant cost guardrails.
##### Monitoring & Alerting
Centralized metrics for CPU, memory, disk, and network across your entire estate, with alert routing to email, Slack, and webhooks.
#### Trust & Compliance
##### Security & Compliance
CVE scanning on container images, CIS benchmark and Lynis hardening checks on VMs, automatic SSL/TLS renewal, and a policy engine with governance scoring - NIS2 evidence collection built in.
##### Immutable Audit Trail
Every action lands in an append-only, hash-chained audit log - tamper-evident and verifiable end-to-end. Exactly the evidence trail NIS2 and GDPR reviews ask for.
##### Identity & Access
Single sign-on with Microsoft Entra ID and Google Workspace, SCIM provisioning, two-factor authentication, and fine-grained roles with just-in-time elevation - enterprise identity from day one.
#### Business & Teams
##### FinOps
Real-time spend by service, project, and environment. Statistically flagged cost anomalies, right-sizing recommendations, and budget alerts - with automated actions (Autopilot) on the roadmap.
##### Developer Platform
Go, Python, and TypeScript SDKs, a versioned REST API, and Terraform export of everything you manage - plus an MCP server, so your AI assistant can work with Sencai directly.
##### Built for MSPs & Agencies
Manage every client organisation from one login. Scoped, time-boxed cross-tenant access with approval workflows keeps client boundaries intact.

## Capabilities (detail)
Source: https://sencai.space/features/

### Your accounts. Your servers. One control plane.
Sencai is one control plane for everything you run - the cloud accounts you already pay for, the servers in your own rack, and the workloads on both. It connects to what already exists instead of asking you to rebuild it, then carries the daily work: provisioning, network and access changes, evidence, and cost. Here it is in the order you'd actually use it, with the full capability list below.
Your accounts stay yours
Connect the cloud accounts you already have - eleven providers today, with the European ones treated as first-class rather than exotic - and your own servers alongside them. Nothing migrates: the account, the contract and the billing relationship stay with you, and you can revoke our access at the provider whenever you want. Credentials are encrypted at rest. On-premise and bare metal are targets in their own right here, not a bolt-on to a cloud tool.
See what you actually have
Most estates are bigger than the documentation says. Connect an account and Sencai inventories what is already running - instances, networks, storage, DNS - across every provider and every site, in one list. From there you choose what comes under management, resource by resource, and nothing is rebuilt or moved to get there.
Run it, day to day
Provision, start, stop, resize and destroy instances from one place, with the same workflow whichever provider sits underneath. Firewalls, networks and DNS records are changed live at the provider, so what you see is the current state and not a cached copy of it. Live management goes deep rather than wide: each provider is built against its real API until the behaviour genuinely matches, instead of being wrapped in a lowest-common-denominator abstraction that breaks on the first real difference. DNS is live on five providers, firewalls on two - AWS joined most recently - and networks on one, and each release adds to that. A lightweight agent on each server adds monitoring, patching, software inventory and runbooks - incident response written down once, and run the same way everywhere.
Prove what happened - and where it runs
Every action lands in an append-only, hash-chained audit log - tamper-evident and verifiable end to end, which makes "who changed this, and when" a query instead of an investigation. Each organisation is a hard boundary with its own roles and invitations: teams, clients and subsidiaries share the platform, never the data. Sencai is run by an EU company under EU law and platform data is stored in the EU - residency is part of the design, not a clause you negotiate later. That is the evidence NIS2, ISO 27001 and GDPR reviews ask for, and our Data Processing Agreement is published as part of our Terms.
Know the cost before the invoice does
Spend is tracked as it happens, by provider, project and environment - not reconstructed from a pile of billing portals at the end of the month. Set caps and budgets where overspend actually hurts, and get told when something starts drifting rather than when the bill lands. The cost sits next to the resource that produced it, so the number that justifies resizing or switching something off is there when you decide.
See it against your own estate
Connect one account, let the inventory run, and judge the picture it gives you. 14-day trial, no credit card, no sales call - and you can revoke our access at any time.

## How onboarding works
Source: https://sencai.space/

### From signup to operating - in under an hour.
No sales calls required. Connect your cloud accounts, let Sencai audit your estate, and act on the recommendations.
#### Sign up and connect
01
Register and start your 14-day trial - no credit card required - then connect your cloud accounts via secure API keys or IAM roles.
#### Automated audit
02
Sencai discovers and inventories your existing infrastructure, then scans for CVEs, misconfigurations, cost anomalies, and expiring certificates.
#### Unified dashboard
03
See every resource, every euro spent, and every security finding in one place. Prioritized recommendations, no noise.
#### Ongoing optimization
04
Continuous monitoring, automatic certificate renewal, and weekly savings reports. Your platform, on autopilot.

## Supported providers
Source: https://sencai.space/

### Works with the clouds you already use
Native integrations for European and global cloud providers - bring your own accounts, or let Sencai provision and bill capacity for you.
Coming soon
On-premise and bare metal
Not every machine lives in a cloud. Sencai enrolls your own servers - in your rack, your colocation or your factory floor - through the same agent, with the same inventory, patching and monitoring. On-premise is a first-class target, not an afterthought.
Run a cloud and want to be on this list? Smaller European providers integrate with Sencai so customers can pick them at the moment they provision - the same depth of integration as the hyperscalers above.
For cloud providers

## Security
Source: https://sencai.space/

### Security you can verify - not just trust.
Sencai manages access to your infrastructure, so our security bar has to be higher than most SaaS. Here's how we protect your accounts, your data, and your audit evidence.
#### Tamper-evident audit trail
Every action in the platform is recorded in an append-only audit log protected by cryptographic hash chaining. Tampering is detectable, and the complete history can be verified at any time - exactly the evidence trail NIS2 and GDPR reviews ask for.
#### Credential protection
Cloud credentials you connect are encrypted at rest, are not displayed back or written to logs, and are scoped to the organisation that added them, with that scoping covered by regression tests. Every use is audit-logged, and you can revoke access at any time.
#### Identity & access
Single sign-on with Microsoft Entra ID and Google Workspace, SCIM user provisioning, two-factor authentication, and fine-grained role-based access with just-in-time elevation and approval workflows - so day-to-day access stays scoped to what's actually needed.
#### Continuous hardening
Automated CVE scanning, CIS benchmark checks, automatic SSL/TLS certificate renewal, and per-organisation scoping covered by regression tests. Security runs continuously in the platform - not as a yearly checkbox exercise.
#### European by design
Built and operated by an EU company under EU law. Platform data is stored in the EU, and your workloads run wherever you choose - including EU-only providers.
#### Compliance & due diligence
NIS2-oriented evidence collection, governance scoring and GDPR-aligned data handling. For enterprise procurement and vendor reviews we provide records of processing, a verifiable export of your audit trail, our published sub-processor register, a written data-residency statement, our published Data Processing Agreement, and direct answers to your security questionnaires. We do not list certifications we do not hold.
Found a vulnerability? Email security@sencai.space - we respond within two business days and credit reporters who want to be credited.
Preparing a vendor review? Our Data Processing Agreement is published at sencai.space/legal/dpa/ and forms part of our Terms - questions about it go to privacy@sencai.space. For security documentation, write to sales@sencai.space.

## Trust and compliance
Source: https://sencai.space/

### Built on European foundations
Security, sovereignty, and compliance are baked into the platform - not bolted on.
Platform data - your account, your audit trail and your operational records - stays in EU regions. Your workloads run in the region you choose.
Data handling aligned with EU privacy regulation.
Immutable, hash-chained audit trails, a policy engine, and governance scoring back every account - not just a badge.
CVE scanning, SSL automation, and CIS benchmarks from day one.
First-class support for Hetzner, OVHcloud, Scaleway, UpCloud and more.
#### Evidence you can hand to an auditor
GDPR-aligned processing, EU hosting by default, and an audit trail your own people can check - without taking our word for it.
##### GDPR-aligned processing
You get a published data processing agreement that forms part of our Terms, a published register of every company that processes data on our behalf, and export and erasure handled inside the product instead of by email ticket.
Published sub-processor register

Data processing agreement with every customer

Export and erasure handled in-product
##### Evidence for NIS2 and ZoKB
The platform records what changed, who approved it and when, and turns that record into something you can put in front of a regulator. We do not sell you a certificate - we give you the evidence your own obligations require.
Change, access and approval records

Just-in-time elevation with an approval trail

Exportable reporting for your own filings
##### An audit trail that proves itself
Every entry carries a SHA-256 digest of its own content and of the entry before it, and the record is append-only, with immutability enforced by the database itself. Alter or remove one entry and every link after it stops adding up.
SHA-256 chained entries

Append-only, immutability enforced in the database

A break is detectable anywhere in the history
##### EU hosting, no third-party telemetry
The platform runs in EU regions. Error tracking, product analytics, billing metering and observability all run on our own infrastructure, so your operational data is not handed to a telemetry vendor on the way past.
EU regions by default

Self-hosted error tracking and product analytics

Self-hosted metering and observability
Verify the trail yourself
Most vendors ask you to trust their audit log. This one is built so you do not have to. Each entry binds the hash of the entry before it, so a single altered, inserted or deleted record breaks every link that follows - and you can prove it on your own machine, with your own tools, whenever you like.
Export your organisation's audit trail from the platform.

Recompute the SHA-256 digest of each entry from its own content.

Check that every entry carries the digest of the entry before it, back to the first one.

Any edit, gap or deletion shows up as a broken link - found by you, without our help.
Read the documentation
Talk to us about compliance

## Pricing
Source: https://sencai.space/pricing/

#### Two things are paid for, and they are separate
One is the organisation - a company, its people and its infrastructure. The other is you, personally. They are billed independently, and neither one caps the other.
Free to start
One user, one organisation and five managed resources cost nothing - no card, no time limit. One organisation per person can be free; a second organisation you own needs a plan. A free organisation has no AI and no automation, and four things stay switched off until it moves to a paid plan: MCP write tools, API-key issuance, AI agents and RoPA records for GDPR Article 30. The first thing you pay for is your sixth managed resource, or your second user.
What an organisation pays for
One continuous curve, anchored on what the organisation actually runs: how many managed resources it has, how much of running them you hand over to automation, and how many people need access beyond the allowance every configuration includes. There is no base fee and no package to choose - the curve starts at zero and rises from there. Each organisation is priced on its own, so the total grows with every organisation you run.
What a person pays for
AI is bought here, never on the organisation: every paid personal plan includes a monthly AI allowance, and going past it costs {rate} per {quote} credits rather than cutting you off. A personal plan also decides how many organisations you may own: one on Free, five on Plus, ten on AI, no limit on Unlimited. An organisation can pay for its people's personal plans, so a company that wants AI buys it for the colleagues who will use it, on one invoice. A personal plan never limits how many members an organisation can have.
Before you commit, know how this ends if the money stops. Every organisation has a spending ceiling - €20 to begin with, and you can raise it. When it binds, your resources stop: compute is switched off, while anything that accrues continuously, such as disks and networks, keeps being billed. If payment stops altogether, we export your resources as Terraform so they can be redeployed quickly elsewhere, and then we tear them down - your data goes with them. That export describes your infrastructure; it is not a backup of what was inside it, so keep your own backups of anything you cannot lose. The two axes themselves stay independent throughout: a free personal account inside a large paid organisation is perfectly normal, and so is a paid personal plan whose organisations are all free.
Monthly
Annual (save 17%)
Personal plans
Individuals
/month
/year
from
Most common setup
Start 14-day trial
Contact sales
A personal plan is about your own productivity: AI working inside your account, prepared functions and automations, how many organisations you may own - and soon a Playground where you build your own workflows. Every paid plan includes a monthly AI allowance and lets you keep going past it at the same rate. AI is bought only here, never on the organisation, and your organisation can pay for your plan if it wants you to have it. It has no effect on how many people an organisation can have.
One managed resource = one compute instance, managed database, storage bucket, or DNS zone managed through Sencai.
#### All of this is in every organisation
There are no feature tiers between paid plans. Nothing below is reserved for larger customers - a one-person paid organisation and a 250-person one run exactly the same platform, and only the price differs. The free configuration is the single exception: it comes without AI, without automation, and without MCP write tools, API-key issuance, AI agents and RoPA records.
A private registry for your images, scanned for known vulnerabilities on every push, with container signing so you can prove what you deployed. Storage grows with your configuration, from tens of gigabytes to a terabyte and beyond by arrangement.
CIS benchmark checks and Lynis hardening audits on every machine you manage, cloud instance or bare metal, with container image signing on top. The scope can be narrowed or extended to match your own baseline.
All of your cloud spend in one place: forecasting for the months ahead, side-by-side comparison between providers, an alert when a bill jumps, and reports you can shape yourself. The AI explanation of why it jumped comes from a personal plan with AI, because AI is bought per person rather than by the organisation.
Reach any server in your fleet from the browser - no VPN, no shared private keys. Elevated access is requested when it is needed, approved by a colleague, expires on its own, and every session is recorded.
Sign in through Microsoft Entra ID or Google Workspace, and create, update and remove accounts automatically over SCIM, with role-based access control down to the individual resource.
Run the platform in your own data centre when that is what the rules require. The fleet agent behaves the same on a bare-metal server as on a cloud instance, so on-premise is a deployment choice, not a reduced version of the product.
Email, chat and phone, answered by the engineers who wrote the platform rather than a first-line script. Response targets and out-of-hours cover, up to 24×7 with a named engineer, are agreed with you.
A written availability target - 99.9%, 99.95% or 99.99% - agreed in your contract. It is a service level backed by a human response time, not a feature a package unlocks, so it is bought deliberately rather than assigned by the size of your invoice.
#### Free
For individuals just getting started. Automatic fallback after your trial.
1 organisation owned

Core platform access
#### Plus
9.9
More capacity for your accounts, your first prepared functions - and AI included from here up.
5 organisations owned

Prepared functions library

AI-assisted remediation and AI code review

Core platform access
#### AI
39.9
Your AI co-pilot: remediation, code review, and an AI allowance sized for automating your daily work.
10 organisations owned

AI-assisted remediation and AI code review

A monthly AI safety ceiling you control

Early access to the automation Playground (roadmap)
#### Unlimited
89.9
For power users and consultants who automate everything they touch.
Unlimited organisations owned

AI-assisted remediation and AI code review

Early access to the automation Playground (roadmap)

Priority support
New accounts begin with a 14-day trial of the platform. The trial does not include AI; afterwards the account falls back to Free unless you decide otherwise. Personal plans can be sponsored: another person, or the organisation itself, pays for someone's plan straight from the profile, on one invoice, and the sponsored person keeps their own organisation quota. Since AI lives on this axis, sponsoring is how a company gives a colleague AI.
#### Work out your price
Set the numbers below and you have your figure. No form, no sales call.
##### How this price is composed
Managed resources above the free five
Automation scope
People beyond the ones your automation includes
Per organisation
Organisations
Total
People who need access
The automation level you choose prepays for a number of people - one with no automation, more as you automate. Beyond that, each person is priced on the curve. There is no cap on how many you add, and no personal plan ever limits it.
Managed resources
Managed resources are what the price mainly follows: compute instances, managed databases, storage buckets and DNS zones you run through Sencai. The first five are free; you pay only above that.
How much should run on its own?
Organisations
Each organisation is priced on its own and the figures add up. Most companies need one.
Estimated total
per organisation
Free
One user, one organisation and five managed resources - at no cost. One organisation per person can be free; any further organisation needs a plan.
Included at this configuration
People included
/month
/year
Annual billing: two months free, about 17% less.
Start 14-day trial
Contact sales
This is an estimate, not an offer. Your final price is confirmed before your first invoice. It covers the platform only - cloud resources running on Sencai accounts are billed separately, at what the provider charges plus 2%, under a monthly spend ceiling.
In every plan
##### No automation
Sencai watches, measures and alerts. Every change stays in your hands.
##### Standard
Patching, backups and routine runbooks run on a schedule and report back.
##### Advanced
Policy-driven remediation across the whole fleet, with approvals and a full record of what changed.
EU data residency for platform data and GDPR-aligned processing

14-day trial, no card required

Provisioning across 11 cloud providers, plus your own hardware

Monitoring, alerting and a tamper-evident audit trail

Change your configuration or cancel at any time
#### How we compare
Where Sencai is the better fit - and where, honestly, it is not.
Sencai
Compiled from each vendor's own public pages in August 2026. Where a vendor does not state something publicly we write “not published” rather than guess. Pages change - if anything here is wrong or out of date, tell us and we will correct it.
##### emma
Multi-cloud management and cost control
##### meshcloud
Cloud foundation and landing zones
##### Cycloid
DevOps portal with IaC and FinOps
##### Enterprise ITSM suites
ServiceNow-class service management platforms
Prices published on the website
yes
not published

not published

yes

not published
Free trial without talking to sales
14 days
yes

no

not published

not published
Self-service signup
yes
yes

not published

not published

not published
Public product documentation without an account
yes
yes

yes

yes

yes
Public API reference
yes
yes

yes

yes

yes
Agent for on-premise and bare-metal servers
yes
not published

not published

not published

yes
Cloud providers named on the vendor's own site
11
not published
Built-in cloud cost management (FinOps)
yes
yes

partial

yes

partial
Named sub-processor list published on the website
yes
not published

not published

not published

not published
Customer telemetry kept in-house instead of third-party SaaS
yes
not published

not published

not published

not published
Tamper-evident audit trail you can verify
yes
not published

not published

not published

partial
NIS2 evidence reporting
yes
not published

not published

not published

partial
{credits} AI credits a month
No AI on this plan
A Sencai AI credit is our own unit, not a provider token. It is a fixed amount of money spent on AI ({unitCredits} credits = {unitAmount}), so what a model costs changes how many tokens a credit buys, never what the credit is worth. The allowance is monthly whether you pay monthly or annually, and every account has a safety ceiling at {multiple}x it so a runaway script cannot produce an unbounded bill.

## Pricing page copy
Source: https://sencai.space/pricing/

### Start free. The price grows with you.
Start free with one user, one organisation and five managed resources. From there the price follows what you actually run: your managed resources, how much of running them you automate, and the people who need access beyond the allowance every configuration includes. There is no base fee. AI is not part of this price - it is bought per person on a personal plan, which an organisation can pay for. Nothing is locked behind a higher paid tier: every paid organisation gets the whole platform, and only the price differs.

## Frequently asked questions
Source: https://sencai.space/faq/

The short version of what prospects usually ask us. Something missing? Ask below.
#### What exactly is Sencai?
A control plane over infrastructure you already own. Connect your cloud accounts and your on-prem servers, and Sencai gives you provisioning, security scanning, cost management, monitoring, and AI-assisted operations in one place - instead of a dozen consoles and point tools.
#### Do I have to migrate anything?
No. Connect your existing cloud accounts and Sencai imports the infrastructure you already run - VMs, networks, and storage are discovered and promoted to managed resources without re-provisioning. Starting fresh with no accounts of your own? Run it on Sencai accounts instead: we hold the account with the provider, you get one invoice from us, and what the provider charges is passed through with 2% added.
#### Which cloud providers are supported?
Today: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Microsoft Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode, and Oracle Cloud - plus your own on-premise and bare-metal servers through the same agent. IBM Cloud is next.
#### Can Sencai manage servers outside any cloud?
Yes - this is one of the things that makes Sencai unusual. The fleet agent enrolls on-premise and bare-metal servers exactly like cloud instances: monitoring, patching, inventory, runbooks, and a browser SSH terminal, no cloud account required. Kubernetes clusters join via a Helm chart.
#### Where does my data live?
Platform data - your account, your audit trail and your operational records - is handled under GDPR by an EU company and is held in EU regions. Where your workloads run depends on the mode you choose: with your own cloud account or your own hardware they never leave your infrastructure; in Sencai-managed accounts they run in cloud accounts we operate, and the provider underneath is named to you as our sub-processor.
#### How does pricing work?
Two independent axes. An organisation starts at zero - one user, one organisation and five managed resources cost nothing - and from there the price grows continuously with the managed resources you run, how much of running them is automated, and the people who need access beyond the included allowance. There is no base fee and no tiers to jump between; the calculator on the pricing page gives you the exact figure. Your personal plan is the other axis: your own AI features, prepared automations and how many organisations you may own, from free. AI is bought only there, and an organisation can pay for its people's plans. One organisation per person can be free; further organisations need a plan. Every new account also starts with a 14-day full-access trial, no credit card required. And the other end of it: at your organisation's spending ceiling your resources are stopped - compute is switched off, while disks, networks and anything else that accrues continuously keep being billed - and if payment stops altogether, your resources are exported as Terraform so they can be redeployed quickly elsewhere, and are then torn down; your data is lost with them.
#### Do I pay the cloud providers, or Sencai?
Either, and you can combine both inside one organisation. With your own cloud accounts (BYOC) you keep paying the providers directly: the contracts, credits and provider relationship stay yours, and we never touch that bill. On Sencai accounts you pay us - we hold the account with the provider, and their charges are passed through with 2% added on top. The provider's cost and our 2% appear as two separate figures on your statement, so the line can be checked. Every organisation also carries a monthly ceiling on what may be spent on our accounts; it moves up with your plan, so the bill cannot quietly run away.
#### How is the platform secured?
Encrypted credential storage, an immutable hash-chained audit log, continuous vulnerability scanning, SSO with 2FA, and role-based access with just-in-time elevation. See the Security & Trust section on this page.

## Developer platform - API, MCP, SDKs
Source: https://sencai.space/developers/

### Automate the control plane - or let your AI assistant do it.
Everything Sencai does in the browser it also does over an API, and over the Model Context Protocol - so an assistant can work with your infrastructure directly instead of you copy-pasting between windows.
MCP server
Sencai speaks the Model Context Protocol, an open standard that lets an AI assistant call a defined set of tools on your behalf. Point any MCP-capable client at the endpoint below, authenticate with a personal access token, and it works inside your organisation with your permissions - not with a shared key.
The server uses MCP's Streamable HTTP transport over this single URL. Where you enter the URL and the header depends on your client - check its own MCP documentation.
What it can read
Read tools are scoped to your own organisation and cannot be pointed anywhere else - none of them accepts an organisation ID. Your assistant can look up your organisation and billing tier, list cloud instances and fleet agents, check your compliance score, and search the documentation.
What it can change, and what has to be true first
Write tools need three separate things to hold, checked server-side on every call: the token carries the read/write scope, an Owner or Admin has switched AI-agent write access on for the organisation, and the organisation is on a paid plan. A token by itself is never enough. Every write an agent makes is recorded in an Agent Activity log you can review afterwards.
Full MCP setup guide
REST API
One versioned REST surface, authenticated per organisation. It is the same API the Sencai dashboard is built on, so anything you can do in the browser you can script.
API reference
SDKs
Go, Python and TypeScript clients, generated from the OpenAPI specification so they track the API instead of drifting from it.
SDK documentation
Webhooks
Subscribe to what happens in your organisation - provisioning, incidents, compliance findings, billing - and receive a signed request at your own endpoint instead of polling for changes.
Webhook documentation
Fleet agent
A single Go binary that brings any Linux server under management, cloud or bare metal. Published with checksums and a cosign signature, and with an explicit list of what it is allowed to do as root.
Download and verify the agent
Start with a token.
Create an account, issue a personal access token from Settings, and point your client at it. Reading works on any plan; write tools need a paid one.

## Fleet agent download
Source: https://sencai.space/download/

### One agent. Every server you own.
The Sencai fleet agent is a small binary that brings a server under management: a cloud instance, a bare-metal box in your own rack, or the machine under someone's desk. Install it once, and it reports into your Sencai organisation - the same agent, the same fleet, regardless of who runs the hardware underneath.
What it does once it's running
Continuous monitoring of CPU, memory, disk, and host health, visible in your fleet dashboard.

Automated patch management, applied inside maintenance windows your team controls.

Software inventory with end-of-life detection, so ageing packages don't stay invisible.

Approval-gated runbooks - pre-approve an action once, and the agent can run it during an incident without anyone re-typing commands at 3 a.m.

A browser-based terminal session for people your organisation has actually granted access to - no SSH keys to distribute or lose track of.
Install
Run this on the server you want to enrol, as root. It detects the host's architecture, downloads and checksum-verifies the right binary, installs it as a systemd service, and enrols it with your organisation.
You'll need a gateway URL and a one-time enrollment token from your Sencai organisation's fleet settings before running this - the token ties the new host to your account and can only be used once.
Prefer to fetch the binary yourself?
Every release is published as plain, signed binaries - no installer required. Download the one for your architecture, verify it, and run it however your own tooling expects.
linux/amd64
linux/arm64
checksums.txt
Each release also stays available under its own version path (for example /v0.1.0/) if you'd rather pin an exact build than track /latest/.
Verify before you run it
Checksum
Confirm the binary matches the published manifest:
Signature
Every release is signed with a key held in our cloud KMS, never on a laptop or a CI runner. Verify the binary against our published public key:
It runs as root - here's exactly what that buys it
The agent installs as a systemd service running as root, because host-level monitoring, patching, and inventory genuinely need that access. That's worth stating plainly before you pipe anything into a root shell, not leaving it to a licence agreement nobody reads.
Reads host metrics, installed software, and OS/kernel version, and reports them to your organisation.

Installs OS patches inside the maintenance window your team configures.

Executes only the specific runbook actions someone in your organisation pre-approved - nothing arbitrary, and every run is logged.

Opens a terminal session on the host, only for people your organisation has granted that permission to.

Talks only to your Sencai organisation, over an authenticated, encrypted connection - the systemd unit itself is hardened (no new privileges, and it can only write inside its own configuration directory).
Removing it
Stop and disable the service, then remove the binary and its configuration directory:
Bring your first server under management
Create a Sencai organisation, generate an enrollment token, and run the install command above - most people are watching real metrics within a few minutes.

## Who it is for
Source: https://sencai.space/

### Built for your world
#### For MSPs & Agencies
Every client. One login. Clean boundaries - scoped cross-tenant access, per-client audit trails, unified fleet and costs.
#### For Regulated Industries
Compliance you can prove, not just claim - NIS2 evidence, immutable audit trails, and EU jurisdiction built into daily operations.
#### For Cloud Providers
Get in front of European buyers at the moment they choose where a workload runs. One integration, a place in the provider list, and a commercial arrangement stated plainly.
#### For Government & Public Sector
EU jurisdiction, eleven providers including European operators, and a hash-chained audit trail a supervisory body can re-check. For public bodies and for the agencies assessing them.

## For MSPs and agencies
Source: https://sencai.space/for/msp/

### Every client. One login. Clean boundaries.
Managed service providers and digital agencies run other people's infrastructure for a living - usually through a browser full of client consoles, shared credentials, and spreadsheets. Sencai replaces that with one control plane built for multi-client operations from day one.
Cross-tenant operations without credential chaos
Each client is a separate organisation with hard boundaries. Your engineers get scoped, time-boxed access to exactly the client they're working on - elevated through an approval workflow, automatically expired, and logged. No shared admin accounts, no credentials in a password vault spreadsheet, no forgetting to revoke access when a project ends.
A defensible audit trail per client
Every action your team takes in a client's environment lands in that client's tamper-evident, hash-chained audit log. When a client asks "who touched our production server and when" - or their auditor does - the answer is one export away, not an archaeology project.
One fleet across every client's infrastructure
Cloud instances, on-prem servers, and Kubernetes clusters across all your clients join the same fleet: monitoring, patch management, software inventory, and runbooks - standardized once, applied everywhere. Codify your incident response as approval-gated runbooks and stop re-solving the same 3 a.m. problem per client.
Costs and margins you can actually see
Per-client, per-project, per-environment spend across every provider in one view - with anomaly detection that catches the surprise bill before your client does. Whether you resell capacity through Sencai or manage client-owned accounts, the numbers stay attributable.
Run your practice on Sencai
Start with one client organisation on the trial, or talk to us about multi-org setups and partnership terms.

## For regulated industries
Source: https://sencai.space/for/regulated-industries/

### Compliance you can prove, not just claim.
Finance, healthcare, energy, public-sector suppliers - if NIS2, DORA, or GDPR shape your infrastructure decisions, Sencai was built with your reviewers in mind. Not as a compliance product bolted onto operations, but as an operations platform that produces evidence as a side effect of daily work.
Evidence, collected while you work
Every provisioning action, configuration change, and access grant lands in an append-only, hash-chained audit log - tamper-evident and verifiable end-to-end. When the audit comes, the trail already exists: no reconstruction from ticket systems and shell histories.
European jurisdiction by default
Sencai is operated by an EU company under EU law, platform data is stored in the EU, and first-class EU provider support (Hetzner, OVHcloud, Scaleway, UpCloud) means workloads with residency requirements have somewhere real to live - alongside your existing hyperscaler footprint.
Continuous hardening, scored and reported
CVE scanning, CIS benchmark and hardening checks, automatic certificate renewal, and a policy engine with governance scoring - so your security posture is a number that trends, not an annual surprise. NIS2-oriented evidence reporting is built in.
Identity your IT department already trusts
Single sign-on with Microsoft Entra ID and Google Workspace, SCIM provisioning, support for two-factor authentication, and fine-grained roles with just-in-time elevation and approval workflows. Access is scoped, temporary, and logged - the way your access-control policy already says it should be.
Ready for your vendor review
Records of processing, a verifiable export of your audit trail, our published sub-processor register, a written data-residency statement, our published Data Processing Agreement, and direct answers to security questionnaires - request the package at sales@sencai.space and involve your security team from day one of the evaluation. We do not list certifications we do not hold; what we hand you is the record, in a form your own people can check.
Bring your compliance team
Start a trial on non-production infrastructure and put the audit trail in front of the people who'll review it.

## For government and public sector
Source: https://sencai.space/for/government/

### Run it in Europe. Prove what happened.
Sencai is a European cloud operating platform: one control plane for cloud providers and for the servers an organisation already runs itself. It is built and operated in the EU, and every action taken through it lands in an audit trail meant to be checked rather than trusted. This page is for public bodies evaluating the platform - and for the procurement and oversight teams who will review that decision.
What Sencai actually does
One control plane for infrastructure spread across cloud providers and your own server rooms. Provision, start, stop, resize and decommission instances; manage firewalls, networks and DNS directly at the provider; track spend per organisational unit and set caps before a budget is overrun. Live management at the provider is delivered depth-first, one provider at a time, so each integration is proven against the real API before it ships rather than assumed to work: DNS is live on five providers, firewalls on two and networks on one, and the list grows with every release. Eleven cloud providers sit behind one interface - European operators such as Hetzner, OVHcloud, Scaleway and UpCloud alongside the global hyperscalers. Each department, subordinate body and external supplier is a separate organisation with hard boundaries, its own roles and its own invitations.
European jurisdiction, not a European label
Sencai is built and operated by an EU company under EU law, and platform data is stored in the EU. Data residency is part of the data model rather than a box someone remembers to tick: every organisation and every environment carries the region it belongs to. European providers are first-class here, not a compatibility gesture - running an EU-only footprint is a normal way to use the platform, not a degraded one.
A record an auditor can check
Every action lands in an append-only, hash-chained audit trail. Each entry is cryptographically linked to the one before it, so a later edit or deletion breaks the chain and shows up - to your own internal control function, to a supervisory body, or to an external auditor working from an export, who does not have to take our word for any of it. That is what makes it usable as evidence for NIS2 obligations, GDPR accountability and internal control reporting. We do not list certifications we do not hold; what we provide is the record, in a form that can be verified.
The estate you already have
Public bodies rarely start from a clean sheet. Sencai scans your cloud accounts for what is already running and presents it as an inventory; your own servers join the same picture once the fleet agent is installed on them. Nothing comes under management until you decide it should. The agent then handles monitoring, patching, software inventory and approved runbooks, so a server in your own building is operated the same way as anything in a cloud - which matters when the estate you are answerable for was assembled over years and several procurement cycles.
Independence from any single supplier
Your cloud accounts stay yours. Sencai operates them on your behalf with credentials you own and can revoke at any time, held encrypted at rest, and nothing has to be migrated for the platform to reach them. Adding or replacing a provider does not mean rebuilding how you operate: the control plane, the roles and the audit trail stay the same, whichever provider is underneath. For a public body that is the workable part of digital sovereignty - keeping the option to leave, and keeping it cheap enough to actually use.
Put us through due diligence
Public bodies can start on non-production infrastructure and put the audit trail in front of the people who will review it. Procurement, security and internal audit teams assessing suppliers can reach us at sales@sencai.space - we answer within one business day, and we will tell you plainly what the platform does not do yet.

## For cloud providers
Source: https://sencai.space/for/cloud-providers/

### Your capacity. Their shortlist. One integration.
Sencai customers choose where each workload runs - from inside the product, in the same step where they provision it. Eleven providers are in that list today. If yours isn't, you're not losing the comparison; you're not in it.
The decision happens inside the product
Teams don't pick a provider from a comparison article. They pick one from a list, in the same step where they're already provisioning, with regions and options side by side. Being in that list means being considered. Being outside it means the evaluation ends before your name comes up.
European buyers - and where we are today
Sencai is built for European companies working under NIS2, GDPR and sector rules that push workloads into EU jurisdiction, and sometimes rule out US hyperscalers entirely. Those buyers want a European option they can name and defend to a reviewer - and they choose it at the moment they provision, from the list in front of them. A provider in that catalog is in the evaluation; a provider outside it never enters the comparison at all.
You keep the account and the customer
Sencai runs on a bring-your-own-cloud model: the customer signs up with you, keeps their own account, and holds the billing relationship directly. We store their credentials encrypted and act on their behalf. We also discover what a customer already runs with you and let them bring it under management as it stands - so an integration reaches your existing customers, not only new ones.
The customer's controls extend over your infrastructure
Whatever a customer has set up in Sencai applies the moment they add your cloud: roles and organisation boundaries, a tamper-evident audit trail of every action, cost tracking with spend caps, and the evidence their compliance reviewers ask for. For the operations Sencai covers, you don't need to ship an enterprise access model or an audit log of your own to be evaluated alongside a hyperscaler.
What integration involves, and what it costs
We build and maintain the integration against your public API: provisioning and the instance lifecycle, discovery of what a customer already runs with you, and - where your API supports it - networks, firewalls and DNS. From you we need API documentation, a test account and one technical contact; the engineering is ours, the review is yours. It's a paid partnership covering integration work and ongoing maintenance, not an advertising slot, and terms depend on how much of your API we cover - so it starts with a technical conversation, not a price list.
Get your cloud into the catalog
Tell us where you operate and what your API exposes. We'll come back with integration scope and partnership terms.

## On-premise and partnerships
Source: https://sencai.space/

### Beyond SaaS: on-prem and partnerships.
Critical systems that can't leave the building, and partners who want to build on the platform - both are first-class at Sencai.
#### Sencai On-Prem
For critical and strategic systems, Sencai ships as an on-premise edition: an annual licence with support included, delivered as a complete server - hardware, software, and installation. Optionally with a local AI server that automates the platform entirely on-site.
Annual licence with support included

Delivered as a complete server: hardware, software, installation

Optional local AI server - platform automation without data leaving your building

Rack or tower form factor, per agreed terms

Built for critical and strategic systems that must stay in-house
#### Partner with Sencai
We're opening the platform to partners: cloud providers who want to be available in the Sencai catalog, and feature providers who extend the platform or sell their licences and functions through the Sencai services marketplace.
Cloud providers: get listed in the Sencai catalog

Feature providers: extend the platform with your own functions

Sell licences and services through the Sencai marketplace

Reach EU-focused customers through a single integration

## About Sencai
Source: https://sencai.space/about/

### Infrastructure should answer to the people who run it.
Sencai is an early-stage European company building the cloud operating platform we always wished existed: one place to provision, secure, and optimize everything a team runs - across cloud providers and their own servers.
Why we exist
Every European company we know runs on more clouds than it wants to, with fewer people than it needs. The tooling answer so far has been a stack of point solutions - one for cost, one for security, one for monitoring, one console per provider - each solving a slice and adding to the sprawl. We started Sencai because we believe a small team should be able to operate like an enterprise platform group without hiring one: one control plane, one audit trail, one bill that makes sense.
European by conviction, not by compliance
We're built in the Czech Republic, operated under EU law, with first-class support for European providers alongside the global hyperscalers. That's not a regulatory checkbox - it's the product thesis. Europe's regulatory wave (GDPR, NIS2, DORA, the Data Act) is turning digital sovereignty from a conference topic into a procurement requirement, and European companies deserve infrastructure tooling that treats that as the default, not an enterprise add-on.
What we believe
Verify, don't trust - claims should be checkable, which is why every action in Sencai lands in a tamper-evident audit trail. Show, don't pitch - the product onboards you in 30 minutes on your real infrastructure, with no sales call. And boring is a feature - infrastructure software should be predictable, honest about trade-offs, and quietly excellent at the unglamorous work that keeps systems running.
Where we are
We're early - deliberately so. The platform is live, the trial is open, and we work closely with our first design partners, shipping weekly. If you want infrastructure tooling shaped by people who actually run infrastructure - and a vendor small enough that your feedback lands in the product, not a backlog - this is the right time to talk to us.
Build with us
Try the platform, challenge our claims, or just tell us what your cloud setup looks like - we answer within one business day.

## For investors
Source: https://sencai.space/investors/

### A control plane is easy to draw. This one runs.
Sencai is a European cloud operating platform: one control plane over eleven natively integrated cloud providers and over the servers a company already runs itself. It is built and operated in the EU, from Prague. This page is for investors and for EU and national grant programmes, and it starts where the evidence is - with what the product does today.
What the product does today
One interface covers infrastructure that physically sits in different places. Eleven cloud providers are natively integrated - Hetzner, OVHcloud, Scaleway and UpCloud alongside AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode and Oracle Cloud - and a customer's own servers join the same picture through a host agent. From there: provision instances and run their full lifecycle, manage networks, firewalls and DNS live at the provider, deepened deliberately one provider at a time - DNS on five today, firewalls on two, networks on one - discover what an account already runs and bring it under management without rebuilding it, track spend per organisational unit with caps, patch and monitor fleets, and reach a machine through a browser terminal with just-in-time elevation. Each organisation is a hard boundary with its own roles and invitations. That is the shipped surface, not a roadmap.
The obligations already have dates on them
NIS2 had to be in national law across the Union by 17 October 2024, and each transposition turns a directive into an obligation with a supervisor behind it. DORA has applied to financial entities and their IT suppliers since January 2025. The Data Act has applied since September 2025: switching charges are already capped and are prohibited outright from 12 January 2027, which turns leaving a provider back into a technical decision rather than a budget one. GDPR and the Schrems II line of decisions turned US jurisdiction into a legal argument rather than a technical detail. None of those dates are in the future. European companies now need more of what they run to sit demonstrably in European jurisdiction. The European landscape they are pushed toward is real but fragmented - national and regional operators, each with its own console, API and conventions. The compliant choice is currently the operationally worse one.
Why this is not a wrapper over a few APIs
A control plane built on other people's APIs invites that question, and the answer is in the shape of the work. Eleven provider integrations cover the instance lifecycle and discovery of what already exists; networks, firewalls and DNS are managed live at the provider, deepened deliberately one provider at a time - DNS on five today, firewalls on two, networks on one - because each one is built against a public API that drifts, disagrees with the others and exposes a different subset of the same idea. A firewall rule does not mean the same thing at two providers, and no two of them model a DNS zone the same way. Keeping that consistent behind one interface is unglamorous, continuous engineering, and it does not survive being done cheaply. Every provider added widens the surface a competitor would have to match before the comparison even starts, and every layer of depth inside a provider widens it again.
Evidence that can only be produced where the actions happen
Every action taken through the platform lands in an append-only, hash-chained audit trail. Each entry is cryptographically linked to the one before it, so a later edit or deletion breaks the chain and shows. The export carries entry_hash and prev_hash on every row, so an external auditor can recompute the chain from the file and does not have to take our word for any of it. For the customer that record is evidence for NIS2 obligations, GDPR accountability and internal control reporting, and it accumulates from the first day. It cannot be reconstructed elsewhere after the fact - it exists because the actions passed through here. Operational tooling that produces evidence as a by-product is difficult to leave.
One integration, paid for twice
Organisations subscribe on published tiers, with an on-premise edition sold as an annual licence for systems that cannot leave the building. Customers keep their own provider accounts and their own billing, and the platform acts on their behalf with credentials they can revoke. There is no migration project to scope, no new capacity to procure and no engineering quarter to justify before anyone sees value - the evaluation happens on infrastructure the buyer already runs. Separately, cloud providers pay to be built into the catalog customers choose from at the moment a workload is placed. A provider outside that list is not losing the comparison - it is absent from it, because the evaluation ends before its name comes up. Supply pays for distribution, demand pays for the product, and one body of integration work serves both.
What compounds, and what capital is for
Provider consoles are excellent and stop at the edge of one provider - they exist to keep a workload where it is, not to make it portable. General multi-cloud platforms are largely US-domiciled, which is the property the regulation is moving buyers away from, and their coverage reflects the market they were built for. What we hold grows with time in market rather than with capital alone: eleven maintained integrations, an audit trail accumulating in the customer's hands, and a catalog two-sided by construction. Capital goes to provider coverage while the regulatory window is open, to the security certification that shortens enterprise and public-sector procurement, and to commercial capacity matched to a demand curve a legislature already set. For EU and national grant programmes this is digital-sovereignty and cyber-resilience work, and the technical and audit documentation an assessor needs exists.
See it run before you decide
We would rather show the platform than present slides: a server provisioned at a European provider while you watch, and the audit trail for that action exported so you can recompute the hash chain yourself. Investors and grant programmes can reach us at investors@sencai.space - tell us what you invest in and at what stage, and we answer within one business day. Detailed metrics and references are shared directly, under NDA.

## Careers
Source: https://sencai.space/careers/

### Help us build the European cloud control plane.
We're an early-stage team building the platform European companies wish their cloud console had been. Remote-first across CET ± 2.
Why Sencai
#### Real ownership
Small team, big surface area. You ship features end-to-end and own them in production.
#### European by design
EU sovereignty is not a marketing slide - it's the product. We build for companies who care.
#### Quiet infrastructure work
No hype-chasing. We optimize boring, expensive, broken parts of the cloud and make them disappear.
Open positions
No open roles right now - but we always want to hear from people who care about this space.
All roles are remote-first (CET ± 2), full-time or part-time by agreement. Don't see your role? We're early - convince us we need it.
Full-time
Remote · CET ± 2
Apply
#### Support Specialist
Own our customers' first line: onboarding help, technical triage, and turning support insights into product fixes. You'll talk to real infrastructure teams daily and shape how the platform explains itself.
#### Cloud Operations Manager
Run the managed-capacity side of the business across our provider catalog: capacity planning, provider relations, escalations, and keeping customer environments boring in the best possible way.
#### Platform Engineer (TypeScript / Go)
Build the control plane: provisioning flows, integrations, APIs, and the occasional gnarly distributed-systems puzzle. You ship to production weekly and own what you ship.
#### DevOps / SRE Engineer
Own reliability across our own stack and our customers' fleets: observability, automation, incident response, and making the runbook library something you'd want to use at 3 a.m.
#### Security & Compliance Engineer
Harden the platform and help customers pass their audits: security reviews, NIS2/GDPR evidence tooling, vendor questionnaires, and keeping our hash-chained audit story bulletproof.
#### Partnerships & Sales Manager
Build the other side of the marketplace: recruit cloud providers into the Sencai catalog, onboard feature partners, and close the first wave of MSP and enterprise deals across the EU.
Send your CV to careers@sencai.space
careers@sencai.space
#### Apply for {role}
Tell us a bit about yourself. We read every application and usually reply within a few business days.
Jane Doe
Email
jane@example.com
Cover letter / anything else
Tell us why you're a good fit, link to your portfolio or LinkedIn, and anything else we should know.
Sending...
Thanks - we received your application and will get back to you soon.
Something went wrong. Please try again or email careers@sencai.space directly.
Too many requests right now - please wait a few minutes and try again.
Close
General application

## Contact
Source: https://sencai.space/contact/

### Talk to the team building Sencai.
Have questions about deployment, security, or pricing? Drop us a line and we'll get back within one business day.
Work email
Company
Message
Jane Doe
jane@company.com
Acme s.r.o. (optional)
Tell us about your cloud setup and what you're hoping to solve...
optional
required
What brings you here?
Pricing & plans

Enterprise & custom contracts

Sencai On-Prem

Security & compliance review

Partnership / provider listing

Something else
Send message
Sending...
Thanks - we received your message and will reply within 1 business day.
Something went wrong. Please try again or email hello@sencai.space.
Prague 1, Czech Republic
We are based in Prague 1, in the European Union. That is not a detail of our address - EU jurisdiction is the premise the whole platform rests on, so it matters where the company answering your message actually sits.
Map of Prague 1

## Contact page copy
Source: https://sencai.space/contact/

### Every message here reaches a person.
No ticket queue, no chatbot, no gatekeeper. Pick the address closest to what you need - or use the form and we will route it ourselves.
Who to write to
hello@sencai.space
Anything that does not fit below.
sales@sencai.space
Pricing, enterprise terms, vendor reviews, paperwork.
security@sencai.space
Vulnerability reports. We will not take legal action against good-faith research.
privacy@sencai.space
Data subject requests, DPAs, sub-processor questions.
careers@sencai.space
Open roles are listed on the careers page.
investors@sencai.space
Funds, angels, grant programmes and journalists.
What to expect
We are a small European team, so replies come from someone who can actually answer - usually within one business day, on European working hours. If a question needs a call, we will say so rather than write an essay.

## Changelog
Source: https://sencai.space/changelog/

### What shipped, and when.
A curated summary of everything we release - the product changes worth knowing about, updated regularly. Not a raw commit feed.
RSS feed
Nothing here yet. Check back soon.
All areas
New
Improved
Fixed
Removed
Security
Cloud
Fleet
Security & audit
Billing
Platform
Identity
Developer tools
#### We ship, and we show it.
See the full changelog

## Blog articles (full text)
Source: https://sencai.space/blog/

### Notes from the cloud control plane.
Engineering write-ups, product updates, and opinions on European cloud sovereignty.
Read article
Related articles
min read
Back to blog
Sencai Team
#### Cloud asset inventory: the infrastructure nobody remembers renting
Every cloud estate is bigger than its documentation, because the defaults favour the leftovers. The security case for finding it is harder than the cost case, and it is the one that should set your triage order.
2026-09-09
Terminate an EC2 instance and its root disk goes with it. Every volume attached after launch stays behind, and AWS documents the default plainly: DeleteOnTermination is true for the root volume and false for attached volumes. Nobody chose that for your estate; it is what the account does when the question never comes up. Your engineers were not careless. Your infrastructure is larger than your documentation because the defaults sit on the side of the leftovers.

A cloud asset inventory assembled from memory will always be a subset of what is running and billing. Flexera's 2026 State of the Cloud Report, published on 18 March 2026 from 753 cloud decision-makers, put wasted cloud spend at 29 percent, the first increase in five years. That is filed as a finance number. The security version of it is worse: a machine nobody remembers renting is a machine nobody is patching. It is still holding the credential it was issued, still answering on a port, and outside the scope of your next penetration test, because the scoping call worked from the same list you did.

## Where orphaned cloud resources actually come from

The engineer who left is the cleanest example. Somebody stood up a proof of concept in a region the team does not otherwise use, demoed it, and left eighteen months later. The instance is still running and it is in nobody's Terraform. Next to it sits the second account: a project that needed to move faster than procurement, opened on a personal card, never folded back in. Cisco puts the share of employees using unsanctioned technology at 80 percent. Gartner found 41 percent acquired, modified or created technology outside IT's visibility in 2022, and puts 38 percent of technology purchases under business leaders rather than IT.

The rest is mechanical. Autoscaling scaled up for a launch and the scale-down policy was never written as aggressively as the scale-up one, so a group that should sit at four sits at eleven. A load balancer outlives the service it fronted. Snapshots run on a schedule someone set in 2022 with no expiry. And somewhere in most estates a staging environment became production by accident, because a customer integration was pointed at it once and nobody wanted to be the one to turn it off.

## An unknown machine is an unpatched machine

Verizon's 2026 DBIR, published on 20 May 2026, found vulnerability exploitation had become the single most common initial access vector at 31 percent of breaches, up from 20 percent the year before. It puts the median time to remediate a known-exploited vulnerability at 43 days, up from 32, and finds only 26 percent of the vulnerabilities on CISA's known-exploited list were ever fully remediated. Those figures describe the machines you know about. For the others the remediation time is never.

An instance that predates your patch tooling is also still holding whatever credential it was handed on its first day. Datadog's State of Cloud Security 2025 found 59 percent of AWS IAM users have an active access key older than a year, a quarter of all keys older than three years and one in ten older than five. The 2026 Cloud Security Report from Cybersecurity Insiders and Fortinet, based on 1,163 IT and security practitioners, has 69 percent naming tool sprawl and visibility gaps as the top factor limiting their cloud security. The forgotten machine is where those two findings meet.

## What idle cloud spend looks like line by line

Since 1 February 2024 AWS charges $0.005 per hour for every public IPv4 address, attached or not, about $43 a year for an address doing nothing. An Application Load Balancer in US East (N. Virginia) is $0.0225 an hour, roughly $16.43 a month, billed whether or not it routes a single request. Individually these are rounding errors, which is why they survive: no line is big enough to make anyone open a ticket, and a mid-size estate carries hundreds of them. The heavier money is in resources running correctly and doing nothing. Datadog's 2024 State of Cloud Costs found 83 percent of container costs associated with idle resources: 54 percent of container spend is cluster idle, infrastructure provisioned and never scheduled onto, and 29 percent is workload idle, resource requests larger than the workloads need.

## Running discovery across accounts you did not open

Start from money and identity, not from consoles. Every account is attached to a payment instrument, so twelve months of card and bank statements is a better discovery source than any provider API; after that your identity provider and your DNS zones, because an account nobody remembers still resolves a name somebody registered.

Inside an account the provider tooling helps and also lies by omission. AWS Resource Explorer builds one index per Region, permits exactly one, and needs one promoted to an aggregator before cross-Region search works at all, so a Region you never indexed contributes nothing to results that look complete. Tagged resources surface in minutes and untagged ones take up to two hours or longer, so the least documented resources are the slowest to appear. Run it twice, a day apart, before you believe it.

Across providers the merge is the work, and by hand it never finishes, because each export has its own idea of what counts as a resource and no two name regions the same way. Sencai does that merge as the product: connect an account with scoped credentials and its existing instances, networks, storage and DNS arrive in one list, beside the machines in your own racks that a host agent can reach, none of it migrated or rebuilt. Promotion into management happens one resource at a time, so seeing something is not agreeing to run it.

## Triage by blast radius, not by monthly cost

The first pass returns more than any team can act on. A sheet of a thousand-odd findings sorted by monthly cost puts a $9 disk above an internet-facing instance with a three-year-old access key on it. Wiz's State of Cloud Risk 2026 found only 9 percent of findings are remote code execution; exposure and access issues dominate what becomes an incident. Order by what an attacker gets instead: anything reachable from the internet that holds a credential first, then anything holding data, then the keys and roles belonging to unclaimed resources. Unattached addresses and idle load balancers go last, however easy they are to fix. Being wrong about one of those costs $43.

Deletion is the wrong first action for anything unclaimed. Stop it and watch instead. An instance that sits stopped for thirty days without one person noticing is safe to remove; one that produces a support ticket within four hours has just identified its owner. Snapshot anything with a disk before you touch it. The single irreversible mistake available here is deleting the storage of something that turned out to be load-bearing, and every team that has done it once performs the thirty-day wait forever after.

## An inventory with a finish line is worthless in six weeks

A spreadsheet is accurate on the afternoon it is produced and decays from that evening. Everything that produced the gap is still running: the defaults have not changed, and the deadline that justified the second account comes round again in March. Article 21(2)(i) of NIS2 lists asset management among the ten minimum risk-management measures in-scope entities must implement, alongside risk analysis under 21(2)(a) and cyber hygiene under 21(2)(g), and no document satisfies any of them. The transposition deadline was 17 October 2024; on 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice over incomplete transposition, asking for daily penalties.

Continuous discovery is a different thing from a project, and the only version that survives a real estate. Sencai's free configuration, one user and one organisation with five managed resources, will run a discovery pass against a real account and show you the list before you promote anything into management. Be clear-eyed about the limit: live management at the provider is deep rather than wide, DNS on five providers, firewalls on two and networks on one, so plenty of what you find you will still change in the provider's console. Whatever you use, take your oldest account, enumerate every region including the two you are certain are empty, and sort what comes back by whether it can be reached from the internet, not by what it costs. The first resource nobody can put a name to is where the work begins.
#### AIOps: what AI fixes in cloud operations, and what it does not
AI names the root-cause service in over 90% of incidents and picks a valid fix in barely half of them. That gap decides what you let it do, and two controls decide whether it is safe to have at all.
2026-09-02
An evaluation posted to arXiv on 6 July 2026 ran 302 quality-audited Kubernetes incidents past retrieval-augmented models and scored two abilities separately. Naming the root-cause service: correct between 91.4% and 99.7% of the time. Choosing a valid recovery action for the incident it had just diagnosed: 36.8% to 60.3%. Forty to fifty-five points sit between those two columns, and that distance is the most useful number published about AIOps this year.

That is a claim about kinds of work, not about model quality. The model reads well and decides badly, and that sorts the market into two piles. Some operational work fails visibly, in front of the person holding it. Some fails by turning into an action against production. AIOps earns its money in the first kind and is currently a liability in the second, and most of the disappointment in this market comes from buying it for the second after a demo of the first.

## Alert correlation, deduplication and the first draft of the story

PagerDuty markets its AIOps product as cutting alert noise by up to 91%. Read that beside a February 2026 survey of 1,039 SRE, DevOps and IT operations professionals, sponsored by NeuBird, in which 44% reported an outage in the past year linked to suppressed or ignored alerts. Correlation that folds forty pages into one incident is a genuine gain. Correlation that quietly decides which pages you never see is how that 44% happens, and what separates them is whether the grouping can be inspected.

The strongest cases are the ones a human can check in seconds. A model that reads the deploy history, the metric shift and three log streams and drafts the incident narrative is doing work otherwise done at 3am by someone with poor recall, and when it is wrong the evidence sits in the paragraph. Explaining why a bill moved is the same kind of task, full of correlations a human spots a month late, and the FinOps Foundation's State of FinOps 2026, released on 19 February 2026 across 1,192 respondents managing over $83 billion of annual spend, found 98% of them now manage AI spend, up from 31% two years earlier. Turning a resolved incident into a written runbook is better still: the facts are settled, and the worst outcome is a human correcting a sentence.

## AI code review on infrastructure catches one class of mistake and is blind to another

Veracode's 2026 GenAI Code Security Report, published on 28 July 2026, tested more than 100 models and found the average security pass rate stalled at 56%, up one point from 55%. Roughly 44% of generation tasks introduced a risky vulnerability when nobody prompted specifically for security. The best performer, GPT-5.5, reached 68%, still failing one security task in three.

The uneven part is the useful part. Those models passed SQL injection tasks 83% of the time and cryptography 87%, but cross-site scripting only 15% and log injection 12%. An AI reviewer is strong on what it has seen labelled a thousand times, close to blind elsewhere, and it will not tell you which mode it is in. On an infrastructure-as-code diff, use it as a second reader for the mistakes obvious in hindsight: the security group opened to 0.0.0.0/0, the change that is a replacement rather than an update. Do not make it the gate: the classes it misses are the ones nobody wrote a rule for.

## Autonomous remediation is where the evidence stops supporting the pitch

The same study carries the finding that should end the self-healing conversation for another year. Even when the model correctly identified both the root-cause service and the fault type, it chose an invalid remediation in 39.5% to 62.0% of those correctly diagnosed incidents. Diagnosis does not carry over into action. Gartner's June 2025 prediction that over 40% of agentic AI projects would be cancelled by the end of 2027 named inadequate risk controls alongside cost, and this is the one that is missing.

Capacity planning fails for a related reason: the model produces a confident number from thin evidence, and a confident number is what a planning meeting wants. EU AI Act Article 14 is written against exactly that, requiring that a human overseer can interrupt a high-risk system and bring it to a halt in a safe state, and naming automation bias as the thing oversight has to resist.

## The spending ceiling has to sit above the provider's billing console

In May 2026 an autonomous agent was handed unrestricted AWS credentials and told to port-scan DN42, a hobbyist network. It provisioned five m8g.12xlarge instances, 48 vCPUs each, plus load balancers and Lambda functions, then kept re-applying the same CloudFormation template. The operator found out roughly 24 hours later from credit-card charges totalling $6,531.30, for a workload the community reckoned would fit on a $5 per month VPS. AWS later cut the bill to $1,894. The protection that worked was a goodwill credit.

No major provider's budget tooling would have stopped it, and all three say so in writing. Amazon documents AWS Budgets as refreshing up to three times a day, each update typically 8 to 12 hours behind the last, a cadence built for humans who make expensive mistakes one at a time. Microsoft states that an exceeded Azure budget threshold does not affect resources or stop consumption, with cost data typically available within 8 to 24 hours. Google Cloud states that an alerts-only budget does not automatically cap usage or spending. AWS ships an open-source Budget Controls solution that acts at 90% of a budget, covers four services in one region, and concedes that storage and networking keep accruing charges. A three-person agency, written up in July 2026, took a $14,000 single-day AWS charge against a normal monthly bill of $10 to $15 after attackers pulled static keys off an instance and spent them on Bedrock model calls.

Our answer is to put the limit where the credentials are issued, not where the invoice is assembled. Spend on Sencai is tracked as it happens by provider, project and environment, with caps and budgets that alert while it is accruing rather than on an 8 to 24 hour billing cycle. Acting on a breached cap automatically is on our roadmap and is not shipped, so today a human still pulls the credential. AI is the one budget we can bound in advance: it is bought in credits, and a credit is a fixed amount of money rather than a token count, so a model price change moves how many tokens a credit buys and never what it is worth. Each paid personal plan has a monthly allowance and a hard ceiling set at a multiple of it, so a runaway script cannot produce an unbounded bill. Runbooks are approval-gated for the same reason: the model proposes, a named human executes.

## An audit trail that can say whether a person or a model did it

EU AI Act Article 12(1) requires high-risk systems to technically allow the automatic recording of events over the lifetime of the system, and Article 26(6) requires deployers to keep those logs at least six months unless other law says longer. If you are planning against an August 2026 date, correct it. Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force from 27 July 2026, moved Annex III stand-alone high-risk systems to 2 December 2027 and Annex I product-embedded systems to 2 August 2028. The dates moved; the obligations did not.

The operational reason to build this has nothing to do with the deadline. Six months after an incident the question is whether a person or a model made the change, and a setup that records AI actions in one system and human ones in another cannot answer it without a join nobody trusts. We refused to keep two records: model actions and human actions land in one append-only trail. Sencai exports it as CSV with the entry_hash and prev_hash on every line, so a reader who does not take our word for it can recompute the chain. The field that earns its place is the small one next to the actor, saying whether the change came from a person or from a model spending a person's allowance.

The rule that falls out of the evidence is unglamorous and holds. Let a model read anything, including the things it reads badly, because a bad reading is visible in the paragraph it wrote. Let it write only where a named person signs the change and a credential limit sits underneath in case that person is wrong too. Between a provider notification on an 8 to 24 hour cycle and someone who reads email on weekdays there is a smoke detector and no sprinkler. The DN42 operator had a smoke detector.
#### Sovereign AI in Europe: where your prompt is actually computed
Sovereign AI in Europe is sold as a badge. Replace it with five checkable questions - entity, law, inference location, retention, sub-processors - and most EU AI data residency claims answer a different one.
2026-08-26
Of the ten regions OpenAI's data residency documentation sells, seven - Australia, Canada, Japan, India, Singapore, South Korea and the United Kingdom - are listed as regional storage yes, regional processing no. A UK residency contract on those terms keeps the record of your request at home and computes the request elsewhere. One word covers both states without distinguishing them, which is why it survives so many architecture reviews intact.

EU AI data residency is a storage property. Sovereignty is a jurisdiction property. The gap between them turns expensive later, in a court or a supervisory authority's inbox. The fix is a chain of five questions, each with a checkable answer.

## Five questions that survive a procurement meeting

Start with the legal entity that operates the endpoint your code calls, and the law under which it contracts and litigates. Then ask where inference physically runs. Retention is third: what is kept from the request, for how long, and who can read it. Last, the sub-processor list behind the endpoint, including whichever company terminates your TLS. Every item is a sentence a vendor can sign, and the ones who will not are telling you something.

Run OpenAI through it. The contracting entity for EEA and Swiss customers is OpenAI Ireland Limited, registered in Dublin, so the first two questions have decent answers. The third narrows fast: regional processing exists for the United States, the EEA plus Switzerland, and the United Arab Emirates, and nowhere else. OpenAI's own documentation says requests to eu.api.openai.com use Cloudflare Regional Services so TLS terminates inside the region, which means the sub-processor OpenAI names for that job, Cloudflare, Ltd., decrypts the traffic on the European endpoint, with an ultimate parent incorporated in the United States. That page also excludes account data, metadata and usage data from residency, and the EU endpoint carries a published 10 percent uplift on models released from 5 March 2026. Sovereignty has a list price.

## The CLOUD Act argument that nobody applies to model endpoints

The statute is short enough to read in full. 18 U.S.C. 2713 obliges a provider to disclose material within its possession, custody or control, regardless of whether it sits inside or outside the United States. Possession there describes a corporate relationship, not a location, so at a model endpoint the duty settles on whoever holds the prompt logs: the model vendor, not the cloud region a customer selected. An EU region bought from a US-incorporated vendor moves the bytes and leaves the obligation untouched. On 10 June 2025 Anton Carniaux, director of public and legal affairs at Microsoft France, told a French Senate hearing under oath that he could not guarantee French citizens' data would never be transmitted to US authorities without French authorisation, adding that no such transfer had occurred. Only one of those halves is a control.

Anthropic's commercial terms answer the entity question precisely: Anthropic means Anthropic Ireland, Limited if the customer resides in the EEA, Switzerland or the UK, and Anthropic, PBC otherwise, with Irish law and Dublin arbitration for the former and California law for the rest. That settles the first two questions and not the third. The Claude API has no first-party EU inference region, and EU-region processing runs through AWS Bedrock or Vertex AI, both operated by US-incorporated providers.

The framework underneath all this is less settled than the marketing suggests. The General Court dismissed the first challenge to the EU-US Data Privacy Framework in Latombe v Commission on 3 September 2025, and the appeal is pending as C-703/25 P. On 29 June 2026 the US Supreme Court decided Trump v. Slaughter, overruling Humphrey's Executor and holding for-cause removal protection for FTC commissioners unconstitutional. The Data Privacy Framework leans on the FTC for the independent enforcement that made it adequate in the first place.

## Retention is a separate question from EU AI data residency

By default OpenAI generates abuse-monitoring logs of prompts and responses for all API traffic and retains them for up to 30 days. Zero Data Retention and Modified Abuse Monitoring both exist and both require prior approval, and any non-US residency region needs that approval plus a signed modified retention amendment. The honest description of a default deployment is that your prompts sit in someone else's log for a month, and the sovereign version starts with an application form.

GDPR Article 4(2) counts storage, retrieval, consultation and use as processing, so an inference call is a processing event rather than a transmission, and a call to a non-EU region is a Chapter V transfer every time it happens - a thousand times a day, if that is your traffic. The EDPB's Opinion 28/2024, adopted 17 December 2024, closes the other exit: a model trained on personal data cannot be declared anonymous.

## What the genuinely European sovereign AI options give up

Mistral made regional endpoints generally available on 11 August 2026, and its own announcement carries the caveat that matters: inference and the associated processing take place in the selected region, subject to limited, safeguarded transfers to sub-processors that may occur outside that region. The same announcement commits to up to 1 GW of European compute by 2030, which does not help a decision you make this quarter.

Ownership is the harder half of the fifth question. On 24 April 2026 Canada's Cohere announced it would acquire and merge with Germany's Aleph Alpha in a 20 billion dollar deal, with Aleph Alpha backer Schwarz Group putting 600 million into Cohere's Series E. Germany's flagship sovereign AI champion has agreed to become part of a company that is not EU-owned, and the deal has still to clear regulators. A sovereignty argument resting on a vendor's nationality had someone else's corporate development team as a single point of failure.

That leaves open-weight models on EU infrastructure you control, or in your own building, which answer the whole list without qualification. The hardware stopped being exotic. Hetzner's GEX131, launched 11 December 2025, pairs an NVIDIA RTX PRO 6000 Blackwell Max-Q with 96 GB of GDDR7 and a 24-core Xeon Gold, at 889 euros a month in German or Finnish datacentres. What you give up should be said plainly: open weights are within a few points of the frontier on coding and mathematics benchmarks such as SWE-bench Verified, and clearly behind on multi-hour agentic work, where the gap has not closed since 2025. You have also bought an operations job, and teams underestimate that far more than the hardware. We are not neutral on that trade, since running other people's infrastructure is what we sell. The narrower point: Sencai's model backend is pluggable, so moving from a hosted provider to open weights on a machine like that one changes the answer to question three without a migration.

## The regulator will grade this, not tick it

The regulatory clock is not the one people quote. The EU AI Act became generally applicable on 2 August 2026, Article 50 transparency duties included, but the Digital Omnibus moved Annex III high-risk obligations to 2 December 2027 and high-risk AI inside regulated products to 2 August 2028. The Commission's Cloud and AI Development Act proposal of 3 June 2026 would grade sovereignty for public procurement rather than score it yes or no. Classify your workloads the same way: a support-ticket summariser and a model reading pseudonymised patient records do not deserve one answer.

We ran our own product through the same five. Sencai names its model providers in a public sub-processor list, engaged only when a customer uses an AI feature and never for the platform. Platform data is stored in the EU, and the free configuration has no AI at all.

Exactly one configuration of ours answers all five without a qualifier, and it is the one most teams should not buy: the on-premise edition, a complete server in your own rack with an optional local AI server beside it, automating the estate on site while nothing leaves the building. Everything else, ours included, answers partially, which is survivable when the partial answer is written down. A vendor who will put the datacentre, the retention window and the TLS terminator into a signed sentence has told you where its product sits; one who will only put it on a marketing page has told you that too.
#### EU AI Act compliance is an inventory problem before a model problem
Regulation (EU) 2026/1744 moved deployer duties to 2 December 2027. Article 50 and AI literacy did not move. For an infrastructure team the work is an AI system inventory and a log retention policy.
2026-08-12
The date most EU AI Act compliance work was planned around, 2 August 2026, arrived without the obligations everyone had prepared for. Six days earlier, Regulation (EU) 2026/1744 - the digital omnibus on AI, published in the Official Journal on 24 July 2026 and in force from 27 July - moved the application date for stand-alone high-risk systems under Article 6(2) and Annex III to 2 December 2027, and for AI acting as a safety component of a regulated product to 2 August 2028. The stated reason was that the harmonised standards were not ready. Article 26, which carries the duties that land on deployers, sits inside exactly the block that moved.

What arrived on time was Article 50, alongside an Article 4 that had already applied since 2 February 2025 and that the omnibus rewrote six days before. Neither of them asks whether your AI is high-risk. The work those two articles create is an asset inventory and a log retention policy, two artefacts your NIS2 and ISO 27001 evidence packs already half contain. Nobody has to classify a model to produce either one.

Almost every infrastructure team is a deployer rather than a provider: you use AI systems under your own authority in a professional capacity, but you did not develop one and put your name on it. That makes the obligation set narrower than most compliance vendors imply, and considerably larger than nothing.

## AI Act deployer obligations, and the article that turns you into a provider

Article 25(1) converts a deployer into a provider, with the full Chapter III obligation set attached, in three situations: you put your own name or trademark on a high-risk system already on the market, you make a substantial modification to a high-risk system that stays high-risk, or you change the intended purpose of an AI system, including a general-purpose one, so that it becomes high-risk. The third case catches platform teams without anyone touching a model: wiring a general-purpose assistant into a decision Annex III lists is a purpose change, and the paperwork that follows is not the paperwork you scoped. That conversion runs on the same deferred clock, so it is a design constraint on what you wire up in 2027 rather than an obligation today.

The headline penalty number belongs to somebody else. Article 99 puts prohibited practices under Article 5 at up to EUR 35 million or 7% of worldwide annual turnover. Breaches of the operator obligations, which is where Article 26 and Article 50 live, cap at EUR 15 million or 3%, and misleading an authority at EUR 7.5 million or 1%. Article 99(6) then reverses the formula for SMEs and start-ups, capping the fine at whichever of the two figures is lower rather than higher.

## The AI system inventory is the artefact everything else rests on

An IAPP analysis published on 6 May 2026 listed five things deployers cannot produce when asked: an AI system register, a written rationale for how each system was classified, human oversight documented as something other than an org chart, a retention policy covering specific AI systems, and a defined escalation or suspension threshold for incidents. Every one of those five is a thing an infrastructure team builds, and four are impossible without the first. An AI system register is written against a machine inventory, and Sencai builds that second list by reading the accounts back, across eleven cloud providers and the on-premise hardware a host agent reaches, so it is dated by the run rather than by whoever last edited it.

Shadow AI is where the register goes wrong, and it has a price. IBM's Cost of a Data Breach Report 2025 found that one in five studied organisations reported a breach involving AI nobody had sanctioned, and where shadow AI involvement was high those breaches ran about USD 670,000 above the global average of USD 4.44 million. The statutory link is direct: Article 50 requires you to disclose that a person is dealing with an AI system, and you cannot disclose a system you do not know is running.

## AI Act logging requirements put a six-month floor on two different parties

Article 26(6) requires deployers to keep the automatically generated logs of a high-risk AI system that are under their control for a period appropriate to its intended purpose, and at least six months, unless Union or national law provides otherwise. Article 19 places the mirror duty on providers with the same six-month floor, so the number appears twice in the Act, on two parties who will each assume the other is holding the record.

Article 12(3), written about biometric identification, is the most useful paragraph in the Act for anyone designing a log format. It names the start and end date and time of each period of use, the reference database checked, the input data that produced a match, and the identity of the people who verified the result. Read as a specification rather than as a rule about biometrics, it describes what a defensible log line contains: when, against what, on what input, and on whose authority.

## The same audit trail answers NIS2 and ISO 27001

None of this is new evidence work if you are already inside NIS2. The directive required transposition by 17 October 2024 and runs a three-stage clock on significant incidents: an early warning within 24 hours, a fuller notification within 72, a final report within a month. Meeting that clock is a reconstruction exercise, which is a log problem. ISO/IEC 27001:2022 has carried the matching controls since publication: Annex A 8.15 on producing, storing and protecting logs, 8.16 on monitoring for anomalous behaviour. ISO/IEC 42001:2023, the AI management system standard published on 18 December 2023, is not yet a harmonised European standard, so certifying against it buys you a credible answer to a customer and no presumption of conformity with the Act.

That overlap is the argument for logging an AI-assisted action like any other change, instead of standing up a second AI governance record that goes stale by quarter two. Sencai takes it literally: a remediation a model proposed and a person approved is filed beside a firewall rule someone edited by hand, and updates and deletes are refused by the storage layer instead of discouraged by policy. Read Article 26(6) against that design and its point sharpens. Six months of logs are six months of evidence only if retention is a property of the store; a record an operator can quietly edit in month four has a retention policy the way a propped-open door has a lock.

## The supplier questionnaire arrives long before the regulator does

Your customers are in scope too, and their compliance programme reaches you as a document request months before any regulator does. The questions are consistent: which model providers process our data, when they are engaged, under what retention, and what stops usage running away. Three of the four are answerable from a document written once and published, which is how we answer them. The fourth resists that, because a truthful answer needs a number, not a paragraph: ours is a per-person budget with a fixed upper bound, the only form a customer can check against an invoice. A sub-processor list names companies; your DPA and your own classification rationale decide whether naming them is enough.

## What to build first, and what can wait until 2027

Start with the register: Article 50 binds today, and everything later depends on knowing what you run. Machine-readable marking of synthetic output from generative systems already on the market before 2 August 2026 has a grace period closing on 2 December 2026, and the labelling duties for deepfakes and for AI-generated text on matters of public interest fall on the deployer, not on the vendor who sold you the model. Then set retention: six months is a floor for high-risk systems, not a target, and it will collide with a data protection rule you have already written.

Article 4 costs the least of the three. The omnibus softened it from ensuring a sufficient level of AI literacy to taking measures that support its development, with express text that no specific level in any individual has to be guaranteed, so a dated attendance record for a one-hour session is the cheapest compliant artefact in the whole Act. Do that work through 2027 and 2 December arrives with the register written and the retention rule already applied to the systems it names, instead of being drafted in the same month those systems come into scope. The register still goes first.
#### European cloud providers as an alternative to AWS: an honest scorecard
European cloud providers are a credible alternative to AWS for more workloads than most teams assume, and a bad one for a specific set. Here is the scorecard, per workload rather than per company.
2026-07-29
Asking whether European cloud providers are a real alternative to AWS is like asking whether a van is a real alternative to a car. It depends entirely on what you are moving. The debate usually gets conducted at company level - are we an AWS shop or not - which is the wrong altitude and produces the wrong answer in both directions. The useful version is a scorecard applied one workload at a time, and it turns out the answer flips somewhere in the middle of most people's estates.

## Where European cloud providers genuinely win

Price is the obvious one and it is not close. For plain compute, storage and bandwidth, Hetzner, OVHcloud, Scaleway and UpCloud sit at a price point that makes a like-for-like hyperscaler line item look like a typo. Bare metal is the sharpest example: dedicated machines with real disks and real cores, rented monthly, at costs that make CI runners, batch processing and self-hosted databases economically boring again. If a workload is compute-heavy and architecturally dull, this is where the money is.

The shape of the bill matters as much as its size. Hyperscaler pricing is largely a function of behaviour - requests, egress, cross-zone traffic, API calls, the things that move when your product gets popular. European providers more often bill a function of what you rented, with generous or included traffic. That does not make them cheaper in every case, but it makes them forecastable, and a bill you can predict a quarter ahead is a different management problem from a bill you audit after the fact.

There is also a hardware-honesty advantage. You can rent a specific CPU generation, know how many physical cores you have, and get NVMe that is genuinely attached to the machine. For anything latency-sensitive at the storage layer, that removes a whole category of performance mystery. It is a smaller point than price, but it is the one engineers notice first when they move a database off a virtualised, network-attached setup.

## Jurisdiction is the argument that keeps working

Everything else on this list can be answered with money or engineering. Jurisdiction cannot. The CLOUD Act (2018) reaches the operating company rather than the datacentre, which is why an EU region operated by a US corporation answers a different question from the one procurement is actually asking. Schrems II (2020) put transfers on shaky ground, and NIS2 - with a transposition deadline of 17 October 2024 - made supply-chain accountability a board-level obligation. A provider headquartered and operated in the EU removes that entire line of questioning instead of mitigating it.

## Where they are not an AWS alternative

Managed service breadth is the honest gap, and it is wide. There is no European equivalent of the fifteen-year accretion of managed databases, queues, streaming, search and machine-learning endpoints that a mature AWS architecture is assembled from. If your system is mostly glue between managed services, moving is not a migration - it is a rewrite, with a new operational burden you had previously outsourced. Anyone telling you otherwise has not run the workload.

The second gap is governance depth, and it is the one people underestimate. Identity and access management, organisational policy, service control policies, fine-grained resource permissions: the hyperscalers have spent a decade on this and it shows. European providers generally offer project-level separation and API tokens, which is adequate for a team of ten and thin for a regulated enterprise with forty engineers and separation-of-duties requirements. That is a real reason to leave certain workloads exactly where they are.

Then footprint and ecosystem. If you serve users in São Paulo, Singapore and Seattle, an EU-only provider is a latency constraint you cannot engineer around; the regions simply are not there. And the surrounding ecosystem is thinner - fewer Terraform modules, fewer prebuilt images, fewer engineers who have run it before, fewer vendors listing it as a supported target. None of that is fatal, but it is real work that never shows up in the price comparison.

On reliability, resist the easy story in either direction. The OVHcloud datacentre fire in Strasbourg in March 2021 destroyed a building and a lot of customers' data, and it remains the sharpest available lesson - not that European providers are fragile, but that your backup and recovery posture is yours regardless of whose logo is on the rack. Teams with offsite backups had a bad week; teams who assumed the provider had it covered had a bad year. The same sentence would be true about any provider on earth.

## Choose per workload, not per company

A practical split, in the order we would actually move things. CI runners and build agents first: stateless, CPU-hungry, no data gravity, and the savings arrive fast enough to fund the rest. Then batch and scheduled processing. Then development and staging environments, which is where waste concentrates anyway. Then object-storage backups, which want to live somewhere other than your primary provider on principle. What stays put is anything welded to a managed service, and anything where a regional latency requirement makes the decision for you.

## The operational tax nobody prices in

Here is why most of those moves never happen, and it has nothing to do with the scorecard. A second provider doubles the consoles, the credential sets, the billing exports, the security quirks to learn and the runbooks to maintain. A team of thirty cannot staff a platform function per cloud, so they consolidate on one, and the European option becomes a thing to look at next year. Every year. The technology comparison was never the blocker. The operations were.

That is the problem we build against. One control plane across eleven providers - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai's Linode and Oracle Cloud - plus on-premise servers through an agent, with one inventory, spend and caps per organisation across all of them, networks, firewalls and DNS managed at the provider rather than mirrored in a database, and one exportable audit trail over the lot. Bring your own cloud, so the contracts and invoices stay yours. European cloud providers become a genuine alternative to AWS at the point where running both stops costing you a headcount.
#### The hybrid cloud management platform that migrates nothing
A hybrid cloud management platform should not start with a migration. Here is what it takes to run rented cloud and your own racks from one place, without moving a single workload.
2026-07-22
Every hybrid cloud management platform pitch starts in the same place: a diagram with your on-premise servers on the left, a public cloud on the right, and an arrow between them labelled migration. The arrow is the product. It is also the reason most of these projects stall, because the arrow costs eighteen months and the value only arrives at the end of them. The more useful question is what you could manage from one place tomorrow, with nothing moved and nothing rewritten.

Hybrid is not an architecture choice most teams made on purpose. It is what you get after a decade: a rack of your own hardware still running the thing nobody can easily move, an ERP nobody wants to touch, workloads on a hyperscaler because a customer asked for it, cheaper compute somewhere European because somebody did the maths, and a few servers in a colocation facility that predate half the current team. Nobody designed this. Everybody has to operate it.

## Why hybrid usually means two teams

The practical cost of hybrid is organisational. Cloud resources are managed in a browser with API tokens and tags; the physical estate is managed with SSH, a configuration tool and institutional memory. Two toolchains, two mental models, two sets of runbooks, and usually two groups of people who describe each other's work as the legacy side or the expensive side. Inventory becomes a merge of exports. Access review becomes two access reviews. Incidents that cross the boundary become an argument about whose problem it is.

The standard vendor answer is to make one side look like the other: install a private cloud stack on your hardware, or lift everything into the public cloud and be done with it. Both are legitimate strategies and both are enormous. They also share an assumption worth challenging - that unification has to happen at the infrastructure layer. It does not. Most of what a team actually needs unified lives one floor up: inventory, access, change records, cost, and the ability to act.

## What a hybrid cloud management platform must not do

A hybrid cloud management platform earns its place by what it refuses to require. It must not require you to move a workload before it becomes useful. It must not require an agent on every machine to show you your cloud estate, or a cloud account to show you your racks. It must not become a new dependency in your critical path - if it goes down, your systems keep running and you lose visibility, not availability. And it must not hold your infrastructure hostage in its own format.

This is why we built Sencai import-first. You connect a provider account with scoped credentials and your existing instances, networks and storage appear as they are, not as things you have to recreate. Nobody evaluating an infrastructure platform has empty infrastructure, and a product that only shows value once you have rebuilt something inside it has arranged for its own demo to fail. The first session should show you your estate, including the parts you had quietly forgotten about.

## Start from what already exists

On the cloud side that means eleven providers behind one interface: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai's Linode and Oracle Cloud. Not a lowest-common-denominator abstraction that hides everything interesting - networks, firewall rules and DNS records are created and changed at the provider itself, so what you see is what the provider actually has, and anything you configure keeps working if you stop using us tomorrow morning.

On the physical side, a host agent brings your own servers into the same inventory: a machine in your own rack, in a colocation cage, or a box at a provider we do not integrate with directly. It sits alongside the cloud resources rather than in a separate section, because the entire point is that "what do we run" should have one answer. For teams whose constraints rule out a hosted control plane altogether, there is an on-premise edition licensed annually with support.

## The on-premise half is not legacy

There is a lazy assumption in this market that owned hardware is a transitional state on the way to somewhere better. Sometimes it is. Often it is the correct answer: predictable heavy workloads where you own the depreciation, data that regulation or contract keeps inside a specific building, latency requirements a region cannot satisfy, and hardware with years of useful life left in it. Treating that estate as second-class in your tooling does not accelerate its retirement. It just means it gets monitored worse.

One control plane over both halves changes small things that add up. Spend is tracked across providers with caps, so the question of what an environment costs has a single answer instead of five exports. Roles and invitations are per organisation, so access review is one review. And every change, cloud and on-premise alike, lands in the same append-only, hash-chained audit trail, exported with each entry's hash and its predecessor's so an auditor can verify the sequence independently.

## What one control plane buys you

The honest framing is that none of this makes hybrid simple. Two hosting models still have two failure characteristics, two procurement processes and two cost structures, and no interface removes that. What it removes is the tax you pay for the boundary: the duplicated inventories, the second access review, the incident where nobody can say what the on-premise side was doing at the time. That tax is paid by your smallest team, continuously, and it is why hybrid feels worse than it actually is.

So the test we would set for any hybrid cloud management platform, ours included, is a short one. Can you see everything you run, rented and owned, in one list, within an hour, without migrating anything? Can you tell who changed what last month, on both sides of the boundary? Can you answer what this costs without opening five consoles? If yes, hybrid is just infrastructure again. If no, you do not have a platform, you have another console.
#### An immutable audit log is only evidence if you can verify it
An immutable audit log that nobody can independently check is a claim, not evidence. Here is how hash chaining turns a log into a tamper-evident audit trail an external auditor can actually recompute.
2026-06-10
The first time an auditor asks for your audit trail, you will probably export a CSV from whatever logging system you already run, and it will look fine. Timestamps, usernames, actions, resource IDs, all in order. Then someone asks the only question that matters: how do we know this file matches what actually happened? An immutable audit log that nobody outside your team can independently check is not evidence. It is a claim about your own behaviour, produced by systems you control, in a format you chose. Auditors are polite about this. Regulators are getting less so.

"Immutable" in most infrastructure stacks means something weaker than the word suggests. It usually means append-only by convention - the application only ever inserts, and everyone agrees not to run an UPDATE. Sometimes it means a retention policy on an object store, or a WORM bucket, which protects against deletion but says nothing about what was written in the first place. All of these are real controls. None of them lets a third party detect a change after the fact. That gap - between nobody is supposed to edit this and you can prove nobody did - is the whole subject.

## How a tamper-evident audit trail works

Take every field of a log entry that matters - the action, who did it, which organisation they were acting for, the resource, the changed values, the correlation ID, the risk level, the client address - serialise them in a fixed, agreed order, append the previous entry's hash, and run SHA-256 over the result. Store that digest on the row as entry_hash, and store the predecessor's digest as prev_hash. The first row has no predecessor, so its prev_hash is null. Everything after it is welded to what came before it.

The consequence is the useful part. Change a single character in a three-month-old entry and its recomputed hash no longer matches the one stored on the row. Delete a row entirely and the next row's prev_hash points at a predecessor that is not there. Insert a fabricated entry and it has no valid place in the sequence at all. You do not need to trust the storage layer, the operator, or the vendor. You need the entries, the hashing rules, and a script. That is what makes it a tamper-evident audit trail rather than a tidy log.

Be precise about what this does not give you. A hash chain is tamper-evident, not tamper-proof. An attacker who holds write access to the database and knows the hashing rules can rewrite an entry and then recompute every hash after it, producing a chain that verifies perfectly. What defeats that is publishing the chain head somewhere the attacker does not control: signing the current entry_hash with a key held outside the database, exporting it, sending it to an auditor, writing it into a separate system. Any of those freezes history up to that moment.

## Why a single writer matters more than you think

A hash chain has exactly one head, and every new entry has to read it before it can link to it. Run two writers against the same table and they will race - both read the same head, both link to it, and one of them is now wrong. The chain reports itself broken, and you spend a day looking for an attacker who does not exist. We treat this as an invariant rather than a preference: one process consumes the audit queue and writes the table, and turning on a second writer is a deliberate cutover, not a scaling knob.

Verification failures also need to be legible, because operators react to the first word they read. Our verifier reports three distinct reasons. chain_broken means the linkage is wrong, that prev_hash does not match the predecessor. content_tampered means the linkage is intact but recomputing the hash from the stored fields produces something different. entry_never_hashed means the row was written without a hash at all. Only the second is evidence of tampering, and collapsing the three into one message is how you start a security incident over a bug in a test.

That third case is not hypothetical, and it is worth telling on ourselves. A handful of rows in our own chain were written by a test that inserted directly into the table with raw SQL, bypassing the writer, leaving both hash columns empty. The database triggers that make the table append-only refuse deletes as well as updates, which means those rows are permanently unrepairable. They will sit in the chain forever, and every verification run reaches them. The fix was a helper that tests are required to use, plus a guard test that fails the moment anyone reaches for raw SQL again.

## What an auditor should actually receive

The deliverable is not a screenshot of a dashboard saying "chain valid". It is a CSV containing the entries themselves with both hash columns included - id, action, actor, organisation, customer scope, resource type and ID, risk level, correlation ID, address, user agent, prev_hash, entry_hash and timestamp - plus a written specification of exactly which fields go into the digest and in what order. With those two things an auditor writes twenty lines of Python and checks your work without asking you for anything else. That is evidence: something you can hand over and then lose control of.

A small detail with real consequences: exported audit fields are attacker-influenced strings, and spreadsheets will execute anything beginning with an equals, plus, minus or at sign. An audit export that opens a shell on the auditor's laptop is a memorable way to fail an audit. Every field in our export is escaped and formula-prefixed values are neutralised before they reach the file. It is the kind of control that looks like fussiness right up until the first person opens the evidence pack in Excel.

Underneath all of this, the table itself has to refuse the dangerous operations. Append-only enforced in application code is a promise that survives exactly as long as nobody writes a migration, a cleanup script, or a well-meaning fix at two in the morning. Database triggers that reject UPDATE and DELETE on the audit table turn that promise into a constraint. It also means the application and the storage can only disagree in one direction: the database may refuse a write the application wanted, but the application can never quietly rewrite the database.

## Verify your immutable audit log on a schedule

Most teams that have a verify endpoint call it once, during the demo. That is the wrong cadence. A chain break discovered when the auditor asks is a forensic problem covering however many months have passed; the same break discovered by a scheduled run is a bug report with a timestamp. Verification over a large table has to be built for that. Ours walks the entries in ordered pages rather than loading everything into memory, because the table grows with every mutation on the platform, and a verifier that only works on small tables is a verifier that will stop working.

The other habit is coverage. It is easy to put audit logging in the HTTP middleware, watch every API mutation appear in the trail, and declare it done. Then a cron job archives a customer's data, a queue consumer revokes an agent, a background worker rotates a credential, and none of it is in the trail, because none of it was an HTTP request. Those paths have to log explicitly. The uncomfortable truth is that the actions least likely to be logged are exactly the ones an investigator most wants to see.

NIS2 and DORA push in the same direction: controls you can demonstrate rather than assert. Nobody is going to hand you a certificate for using SHA-256, and we are not claiming one. But when someone asks who changed the firewall rule on the third of March, there is a large difference between a query result and a query result whose integrity a stranger can check. Three questions worth asking anyone selling you an immutable audit log: can I export the hashes, can I recompute them without your software, and what happens when the chain reports itself broken?
#### NIS2 compliance evidence: what a regulator actually asks for
NIS2 compliance evidence is not a policy PDF. It is records: who changed what, when, and on whose authority - reconstructable months later, by someone whose job is to doubt you.
2026-06-04
Ask an infrastructure team what NIS2 compliance evidence looks like and you usually get a policy pack: an information security policy, an incident response plan, a supplier questionnaire, all signed and versioned. Those documents matter, but they are not evidence. They describe what you intend to do. Evidence is the record of what you actually did - who changed the firewall rule, when, on whose authority, and what the configuration was before. Assessors ask for the second thing, and the gap between the two is where most teams get uncomfortable.

A quick recap of what we are dealing with. NIS2, formally Directive (EU) 2022/2555, had a transposition deadline of 17 October 2024, and national laws have been landing on their own schedules since. It widened the scope well beyond the old NIS categories, pulled supply chains in explicitly, and attached obligations to management bodies personally rather than to an abstract organisation. If you supply anything to an in-scope entity, expect their obligations to arrive on your desk as contract language, whether or not you are directly in scope.

## What the directive actually asks for

Article 21 lists the risk-management measures: policies on risk analysis and information system security, incident handling, business continuity and backup, supply chain security, security in acquisition and development, procedures to assess effectiveness, basic cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication. Read that list as a set of questions you will be asked to answer with records. Every item ends in the same follow-up from an assessor: show me. Show me the backup you restored, the access you revoked, the change you approved.

Article 23 is the one that changes engineering rather than paperwork. An early warning within 24 hours of becoming aware of a significant incident. A fuller notification within 72 hours, including an initial assessment of severity and impact. A final report within one month. Those clocks start when you become aware, which makes your detection timeline part of the evidence itself. If you cannot say when you knew, you cannot demonstrate that you reported on time - and an incident timeline reassembled from memory a week later convinces nobody.

## NIS2 compliance evidence is a record

Here is the practical shape of what an assessor asks for. A list of systems in scope and who owns each one. A record of changes to security-relevant configuration over a stated period. Proof that access was granted, reviewed and removed, with dates. Evidence that backups were not only taken but restored. And for every significant incident, a timeline you can defend: detection, escalation, containment, notification. All of it dated, attributable to a named identity, and produced from something other than a person's recollection.

The awkward truth is that almost all of this already exists somewhere in every company. It is in a ticket system, a chat channel, three consoles, one engineer's terminal history and a spreadsheet. Compliance work then becomes archaeology: two weeks of somebody reconstructing what happened from artefacts that were never designed to be evidence. That is expensive, it is demoralising, and it produces a document nobody entirely trusts - including the person who assembled it.

## The property that makes a log evidence

A log becomes evidence when it is append-only and tamper-evident. The distinction matters more than it sounds. A table an administrator can update is a record of what that administrator wants you to believe. What an assessor wants is a sequence in which any modification to an earlier entry is detectable, without having to trust whoever operates the system - including us. That property is what turns "here are our logs" into something a third party can rely on rather than merely receive.

Sencai's audit trail is append-only and hash-chained. Every entry carries its own hash and the hash of the entry before it, so the records form a chain rather than a pile. The CSV export includes both values, entry_hash and prev_hash, which means your auditor does not have to take our word for anything. They can recompute the chain themselves, offline, with a script they wrote, and see whether it holds. If a single entry had been altered or removed, the recomputation stops matching from that point onward.

## Supply chain questions you will be asked

Article 21 puts supply chain security in the list, and Article 20 makes management personally accountable for approving and overseeing those measures, which is why these questions now arrive with real weight behind them. Expect to be asked which subprocessors touch your data, in which jurisdictions they operate, how you would detect a compromise originating with one of them, and how quickly you could remove one. If you cannot enumerate your providers today, you cannot answer any of it - and an incomplete inventory is the fastest way to fail this section.

This is where per-organisation isolation and a real role model stop being product features and become audit answers. Who can create infrastructure, who can only view it, who invited whom and when, and which of those invitations were actually accepted rather than merely sent - these are questions with dates attached. The same applies to the configuration that genuinely protects you: firewall rules, network boundaries and DNS records, each with a record of who changed them at the provider, and when.

## How to prepare without a compliance department

Start by writing down the questions you would struggle to answer in a room with an assessor. Usually there are four: what do we run, who can touch it, what changed last quarter, and how do we prove any of it. Then fix the recording, not the reporting. A system that captures the answers as the work happens costs almost nothing at the time; reconstructing them afterwards costs weeks, every single time. NIS2 did not create that gap - it just made it expensive to keep.

None of this makes compliance pleasant. It does change its shape. Evidence you can export, hand to an auditor and let them verify independently is a very different conversation from a folder of screenshots and a promise that nothing was edited. That is the bar we built for: your estate in one place, changes recorded as they happen, and an export designed to be checked by someone whose entire job is to doubt it.
#### Bring your own cloud: keeping the provider contract, outsourcing the operations
Bring your own cloud (BYOC) means the provider accounts, contracts and invoices stay yours while someone else's software runs the day-to-day. Here is what that buys you, and what it demands from the platform.
2026-04-22
There are two ways to let someone else operate your infrastructure. In the first, you buy cloud from them: they hold the provider accounts, they get the invoice, you get a marked-up bill and a support address. In the second - bring your own cloud, usually shortened to BYOC - you keep your own accounts with Hetzner or AWS or OVHcloud, your own contract, your own invoice, and you grant a management platform scoped credentials to operate them on your behalf. The two models look similar in a demo and behave nothing alike on the day you want out.

The resale model is not a scam; it is a legitimate business with real advantages, mostly around a single invoice and one place to complain. What you give up is less visible. Your contractual relationship is with the reseller, not the provider, so the SLA you can actually enforce is theirs. Committed-use discounts, startup credits and negotiated pricing all route through them. And the resource identity, the account the servers actually live in, belongs to somebody else, which means leaving is a migration rather than a cancellation.

## What you keep when you keep the contract

Under BYOC the provider relationship stays where a lawyer would expect it. The instances are in your account. The support tickets are yours to open. The invoice arrives in the format your finance team already reconciles, from a company you already did diligence on, under a jurisdiction you already reasoned about. If your compliance posture depends on who legally operates a service - which, after Schrems II, is the interesting question rather than where the servers physically sit - you have not added a link to that chain by adopting a control plane.

The exit test makes the difference concrete. If the management platform vanished overnight, what happens? Under resale, your servers are in an account you do not control and the answer involves lawyers. Under BYOC, the servers keep running exactly as they are; you have lost a console, an inventory and some automation, which is annoying rather than existential. That asymmetry is worth more than any feature list, and it is the first thing to check before signing anything.

## What BYOC demands from the platform

The price of the model is that the platform now holds real production credentials for accounts it does not own. That obligation has to be taken literally. Credentials are encrypted at rest with AES-256-GCM, scoped to a single organisation, never shared across tenants, and never returned in an API response - the fields are private on the way out as well as encrypted on the way in. Every one of those is a boring requirement that becomes interesting the first time an ordinary list endpoint is asked to serialise a credential record.

Then there is the failure mode nobody plans for. A provisioning job arrives with no credential attached: a bug, a race, a message from an older version of a service. The tempting behaviour is to fall back to the platform's own provider token so the job succeeds. We shipped that behaviour once and it did exactly what it was always going to do - created a real machine on the platform's own account, billed to the wrong party, invisible in the customer's inventory. The default is now fail-closed. A job without a credential is refused, and enabling the fallback takes an explicit environment flag.

## Where multi-provider BYOC gets difficult

One provider is an integration; eleven is a taxonomy problem. Sencai currently drives Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai's Linode and Oracle Cloud, plus on-premise and bare-metal servers through a host agent. Each of those has its own authentication model, its own quota system, its own vocabulary, and its own opinion about whether a firewall belongs to a machine, a network, or a project. Normalising that without lying about it is most of the engineering.

The line we try to hold is that the control plane operates the provider rather than a copy of it. When you create a network, a firewall rule or a DNS zone in Sencai, the call goes to the provider's API and the object exists there - visible in their console, deletable with their CLI, real to anyone who has never heard of us. A platform that only records intent in its own database produces a very convincing inventory of things that may not exist.

Billing follows the same logic. Because the invoice stays with the provider, the platform's job is not to bill you. It is attribution and control. Spend is tracked per organisation and project across every connected account, with caps you set, so the question "what did the batch pipeline cost last month" has one answer instead of four exports in four formats. This is also the part BYOC makes genuinely harder than resale, because there is no single ledger to read from; the numbers have to be pulled and reconciled per provider.

## Who bring your own cloud is for

BYOC suits teams with an estate that already exists and constraints that are already real: a few hundred machines accumulated over three years, a jurisdiction requirement from a customer's procurement team, a provider mix that happened rather than was designed. It suits worse if you are greenfield, want exactly one invoice, and have no opinion about where anything runs. A reseller or a single hyperscaler will be simpler, and you should take the simpler thing. Nobody needs a multi-cloud control plane for one account and eleven servers.

Two things get sharper under BYOC and deserve deliberate design rather than good intentions. The first is isolation: credentials belong to an organisation, membership happens by invitation, and roles decide who can spend money or touch a firewall - because the blast radius here is a real production account, not a sandbox. The second is the audit trail. Every action the platform takes on your behalf should be recorded append-only, with the actor, the resource and a correlation ID, in a form you can export. You are delegating operations, so the record of those operations is what you have instead of having done them yourself.

So, the questions worth asking anyone selling you bring your own cloud. Whose name is on the provider contract? What exactly can the credential you handed over do, and can you scope it down? What happens to the running infrastructure if you stop paying them tomorrow? Can you export the log of everything they did inside your accounts, and check it independently? Good answers to those four are what separates outsourcing your operations from outsourcing your infrastructure - and only one of those is reversible on a Tuesday.
#### Cloud exit strategy: what changes when you can actually leave
A cloud exit strategy is not a migration plan you keep in a drawer. It is a measurable property of your architecture - and it changes how you negotiate, budget and sleep.
2026-04-16
Ask ten infrastructure teams whether they have a cloud exit strategy and nine will say yes. Ask what it consists of and you usually get a wiki page written during a vendor review, listing which services are proprietary and which are portable. That is an inventory, not a strategy. The real test is less comfortable: if your provider doubled its prices, changed jurisdiction, or suspended your account on a Tuesday morning, how many weeks until you are serving traffic somewhere else - and who on your team can answer that without opening a spreadsheet?

The regulatory pressure here is real but it is not the interesting part. The Data Act is removing switching charges, which takes away the finance department's excuse. Schrems II and the CLOUD Act took away the legal one years ago. What remains is engineering reality, and no directive fixes that. A regulator can make leaving cheaper on paper; it cannot make your deployment pipeline, your identity model, your DNS records and your restore path work at a second provider. That work is yours, and it is the entire cost.

## What a cloud exit strategy actually is

An exit strategy is a measurable property of your architecture, not a document. The measurement is blunt: what share of your running estate could you stand up at a different provider, using tooling you already operate, without writing new code? For most teams the honest answer lands somewhere between forty and seventy percent, and the gap is never where they expected. It is rarely the application. It is the managed database, the queue, the object storage semantics, and the eleven small operational habits nobody ever wrote down.

The failure mode is believing that having two providers proves anything. Plenty of companies run production on one hyperscaler and a forgotten test project somewhere else, then call the result multi-cloud. Optionality is not the presence of a second account; it is the ability to exercise it. Until one real workload - with monitoring, backups, an on-call rota and a restore you have actually performed - runs somewhere other than your primary provider, you have a second invoice, not a second option.

## The three things that make leaving hard

First, data gravity, which is boring and decisive. Bytes are cheap to copy and expensive to move consistently while a system is live. The moment your data sits inside a proprietary managed service, the exit stops being a copy and becomes a rewrite of everything that talks to it. This is why teams that keep their state in something they could run themselves - even if they choose not to today - preserve options that teams on fully managed stacks quietly lose over a few years.

Second, operational muscle memory. Your team knows one provider's identity model, one firewall abstraction, one way of naming networks, one console layout at three in the morning. Move to a second provider and every one of those is unfamiliar under pressure. The cost is not the migration weekend; it is the following six months of incidents handled a little more slowly by people who are guessing. Nobody puts that on a migration estimate, and it is usually the largest line on it.

Third, cost attribution. Most teams cannot tell you what a single workload costs today, which makes comparing providers impossible in principle. If your bill is one number per provider and your architecture is forty services, the exit conversation degenerates into vibes. Before you can price an exit you need spend broken down by service, project and environment, across every provider you use, including the small ones you forgot about. It is unglamorous groundwork, and it is a prerequisite for every other decision here.

## How to avoid cloud vendor lock-in in the EU

If you want to avoid cloud vendor lock-in, the EU market is in better shape than most teams assume. Hetzner's price-performance makes hyperscaler invoices look like a rounding error in the wrong direction. OVHcloud runs its own data centres and fibre across Europe. Scaleway ships a genuinely modern developer experience from France. UpCloud delivers dependable compute from Finland. None of them replaces every hyperscaler service - but for compute, block storage and networking, where most infrastructure money actually goes, they are credible and answer to EU law alone.

The honest limit is managed services. If your product is built on a proprietary serverless database, a specific event bus, or a machine learning platform with no equivalent elsewhere, no amount of European enthusiasm changes that within a quarter. The useful move is not a heroic all-or-nothing migration. It is to know exactly which workloads are portable today, run some of them where the jurisdiction and the price suit you, and treat the rest as a deliberate, documented decision rather than an accident of history.

## What an exit rehearsal actually involves

Treat it like a restore drill, because that is what it is. Pick a real workload - not the marketing site, something with state and a runbook. Stand it up at a second provider. Point a fraction of real traffic at it. Break it deliberately and see whether your monitoring, your access model and your on-call rota work there too. Then write down the wall-clock time and everything that surprised you. A rehearsal that produces no surprises usually means you picked something too easy.

The reason most teams never rehearse is not laziness, it is tooling. Every additional provider means another console, another credential model, another billing export, another set of quirks to learn - and a small platform team cannot absorb that once per cloud. This is the operational tax that quietly converts a sovereignty conversation into next year's problem, every year. It is also, precisely, the problem a control plane is supposed to remove from your desk.

That is what we built Sencai to be. One control plane across eleven providers - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai's Linode and Oracle Cloud - plus your own servers through a host agent. Networks, firewalls and DNS are managed where they actually live, at the provider, so a second provider becomes a tile in the same interface rather than a second platform team. Spend is tracked per organisation with caps, so the exit conversation has numbers in it.

You can run this on your own provider accounts, or buy the capacity through us and keep one invoice - both are supported, and the choice is yours to change later. Either way the deliverable is the same, and it is the only number worth reporting upward: how long it would take you to be running somewhere else. Measure it once and it stops being a fear. Measure it every quarter and it becomes leverage - in a negotiation, in a procurement review, and on the day something forces the question.
#### Why EU data sovereignty matters in 2026
Sovereignty isn't a checkbox on a procurement form. It's a fundamental constraint that shapes architecture, pricing, and risk - and it's getting harder to ignore.
2026-03-12
When the CLOUD Act passed in 2018, most European CTOs treated it as a legal abstraction - something for the compliance team to worry about, somewhere between cookie banners and printer procurement. Eight years later, with the Schrems II ruling, NIS2 transposed into national law across the EU, DORA in force for financial services, and the Data Act's egress-fee provisions approaching, it's a board-level concern. Not because lawyers won an argument, but because the risk stopped being theoretical.

Let's define terms, because "sovereign cloud" has been marketed into mush. Real sovereignty means three separate things: data residency in EU jurisdictions, operational control by EU-headquartered companies, and legal protection against extraterritorial subpoenas. The marketing departments of US hyperscalers will tell you their European regions tick the first box. They are right. The other two are harder - and they're the two that matter when things go wrong.

What this looks like in practice: a hospital in Munich runs PACS imaging on AWS Frankfurt. The data never leaves Germany. Encryption at rest, EU support staff, the whole compliance package. But the operating company is a US Delaware corporation, subject to US law. A US court order can compel disclosure regardless of where the bytes physically sit. The hospital's lawyers know this. The hospital's board, increasingly, knows this too. This is the gap NIS2 and the Data Act are closing - slowly, imperfectly, but in one clear direction.

The regulatory timeline tells the story. Schrems II (2020) invalidated Privacy Shield and put every EU-to-US data transfer on legally shaky ground. NIS2 (national transpositions landing 2024-2025) made supply-chain accountability a board obligation with personal liability - you're now answerable not just for your own security, but for your vendors'. DORA (January 2025) did the same for financial services with teeth. The Data Act (with egress-fee provisions from 2027) attacks lock-in directly: the exit costs that made "we'll migrate later" a fantasy are being regulated away.

None of this means "stop using AWS." That's the strawman version of the sovereignty argument, and it fails on contact with reality - the hyperscalers are excellent at what they do, and most European companies will keep workloads on them for years. The serious version is about optionality: knowing exactly which of your workloads could move, where they could move to, and what it would cost - before a regulator, a customer's procurement team, or a geopolitical surprise forces the question on someone else's schedule.

That's where the European provider landscape gets interesting, because it's genuinely good now and mostly unknown. Hetzner offers price-performance that makes US-cloud bills look like a prank. OVHcloud runs one of the largest footprints in Europe with its own fiber and data centers. Scaleway ships a modern, developer-friendly stack from France. UpCloud delivers reliable compute from Finland. None of them is a drop-in AWS replacement across every service - but for the compute, storage, and network layers where most infrastructure spend actually lives, they are credible, often cheaper, and answer to EU law alone.

The honest obstacle isn't capability. It's operations. Every provider means another console, another API, another billing export, another set of security quirks to learn. A 30-person company can't staff a platform team per cloud - so they consolidate on one hyperscaler, and sovereignty quietly becomes something to revisit "next year," every year.

This is the actual problem Sencai exists to solve. A multi-cloud strategy - including a sovereignty strategy - is only real if a small team can operate it without drowning. One control plane across hyperscalers and EU-native providers, one place to see every resource and every euro, one audit trail that holds up when NIS2 evidence is requested: that's what turns "we should look at European providers" from a slide into a migration plan.

So here's the practical checklist we'd give any EU CTO for 2026. One: map which of your workloads are jurisdiction-sensitive - personal data, health, finance, government-adjacent - and which are commodity compute that could run anywhere. Two: ask your providers who legally operates each service, not where the servers are; the answers will surprise you. Three: price an exit for your top three workloads, because the Data Act is about to make that number negotiable. Four: run one real workload on one EU provider this year - not as a statement, but as an option you've actually exercised, with monitoring and backups and everything you'd demand anywhere else.

Sencai's position is simple: we ship a control plane that works across hyperscalers and EU-native providers (Hetzner, OVHcloud, Scaleway, UpCloud), and we let you decide where every workload lives. The control plane itself runs in the EU, operated by an EU company, with no US dependencies in the critical path. That's what sovereignty by default looks like: not a badge on a slide, but the freedom to put every workload exactly where it belongs - and to prove it.
#### FinOps for teams who don't have a FinOps team
Most FinOps content is written for enterprises with dedicated practices. Here's what the discipline actually looks like for a 30-person SaaS that just wants to stop wasting money.
2026-02-28
FinOps is one of those terms that means very different things depending on company size. For a Fortune 500, it's a 30-person practice with a CFO sponsor, a tooling budget bigger than your payroll, and quarterly steering committees. For your 30-person SaaS, it's roughly: "why is the AWS bill 27% higher than last quarter, and whose job is it to find out?" This post is for the second group.

First, the reassuring news: cloud waste is boring. The overwhelming majority of it comes from the same five patterns, at every company, at every scale. Idle compute nobody switched off. Oversized instances provisioned for a peak that never returned. Untagged resources nobody can attribute, so nobody feels responsible. Forgotten development and staging environments running around the clock for software that ships twice a month. And storage sitting on premium tiers years after anyone last read it. None of these require a FinOps Foundation certification to fix. All of them require someone to actually look.

The pattern we see most often deserves its own paragraph. A developer spins up a c5.4xlarge for a load test on Thursday. The test wraps up at 4pm Friday. The instance runs over the weekend, because turning it off is a manual step in a console nobody opens on Saturday. By Monday standup the team has burned €180 on an idle box - not through incompetence, but because the system's default is "keep billing." Multiply by every team, every weekend, every forgotten experiment, and you have a meaningful percentage of your infrastructure budget doing precisely nothing.

Why don't dashboards fix this? Because visibility was never the bottleneck - your cloud provider already has a cost explorer, and you already don't open it. A dashboard tells you what happened after the money is gone, in a place you have to remember to visit, in a format that requires twenty minutes of filtering before it says anything actionable. Between "the data exists" and "someone acted on it" sits the entire actual discipline of FinOps, and it's exactly the part a small team has no spare capacity for.

There's also a structural problem dashboards can't solve: multi-cloud fragmentation. The moment you run AWS for the product, Hetzner for batch workloads, and a stray DigitalOcean project someone started in 2024, "what do we spend" stops having a single answer. Each provider exports costs in its own format, on its own schedule, with its own idea of what a project is. Most small teams respond by tracking the big bill carefully and letting the small ones drift - which is how a €400/month leak survives for two years.

So what does FinOps actually look like for a team with no FinOps team? In our experience, four habits cover most of the value. One: a single source of truth for spend across every provider, broken down by service, project, and environment - not because dashboards fix things, but because arguments about attribution die when everyone sees the same numbers. Two: anomaly detection that's smarter than a threshold - cloud bills are naturally noisy, and a static "alert me over €X" either fires constantly or never; flagging genuine deviations from your own baseline is statistical work, not a cron job and hope. Three: right-sizing recommendations on a cadence - a monthly list of "these twelve instances are oversized, here's the safe smaller size, here's the saving" that someone reviews in fifteen minutes. Four: budget alerts that escalate - a quiet warning to the engineer at 80%, a louder one to the team lead at 100%, because a budget nobody is accountable for is a wish.

Notice what all four have in common: they shorten the loop from insight to action. That's the entire game. Not more data - less distance between "the system noticed" and "a human decided." A small team doesn't need a FinOps practice; it needs the twenty minutes a week where cost decisions happen to be well-prepared, pre-prioritized, and in one place.

That's what we built into Sencai: spend by service, project, and environment across every connected provider; statistically flagged cost anomalies; scheduled right-sizing recommendations; budget alerts that escalate. The loop from insight to action, compressed to fit inside a standup. And the next step on the roadmap - Autopilot - is about closing that loop entirely for the boring cases: auto-stopping tagged dev resources on schedule, executing approved right-sizing during maintenance windows. The judgment stays with you; the button-pressing shouldn't have to.

If you want to know where you stand today, here's a fifteen-minute exercise: pull last month's bill from every provider you use - including the ones you'd forgotten. Sort by service. Circle everything you can't attribute to a running product feature within ten seconds. At most companies that circle is 25-35% of the total. That's not a budgeting problem. That's just entropy - and entropy is very, very fixable.
#### Your cloud platform should onboard you in 30 minutes
Enterprise infrastructure tools love long sales cycles, demo calls, and six-week proofs of concept. We think your first deploy should happen before your coffee gets cold.
2026-01-30
There's an unwritten rule in enterprise infrastructure software: the more your product costs, the harder it should be to try. First a discovery call with someone whose job title contains the word "growth." Then a demo on carefully staged data. Then a proof of concept scoped by a solutions architect, a security questionnaire, procurement, legal. By the time you deploy anything real, a quarter is gone. Startups don't have quarters to spare - and honestly, neither does anyone else.

The strange part is that everyone involved knows it's theater. The vendor knows the demo environment is nothing like your infrastructure. You know the POC success criteria were written to be met. The only genuine information exchanged in the whole ritual is the price - and even that comes with "talk to sales." For a category of software whose entire promise is operational efficiency, the buying experience is a masterclass in operational waste.

We set ourselves a different bar: from signup to your first managed resource in under 30 minutes, self-serve, no sales call. Not because it demos well - because that single constraint shaped the whole product. If onboarding has to fit in half an hour, you can't hide complexity behind an implementation team. The product itself has to explain what it needs, connect your accounts safely, and show value before the coffee gets cold. Every shortcut we couldn't take for you, we had to design out.

Here's what those 30 minutes actually look like. Minutes zero to five: sign up, verify your email, create your organisation. Minutes five to fifteen: connect a cloud account - guided flows for each provider walk you through creating scoped credentials, and the same path works whether it's AWS, Hetzner, or a bare-metal server with our agent. Minutes fifteen to twenty-five: Sencai discovers what you already run - your instances, networks, and storage appear in the inventory, and the first security and cost findings start landing. Minutes twenty-five to thirty: you're looking at your actual estate, prioritized, in one place - deciding what to fix first rather than configuring a tool.

The import-first design is the part we're most opinionated about. Most platforms greet you with an empty dashboard and a wall of setup - day one is a chore, and value arrives someday. But nobody evaluating an infrastructure platform has empty infrastructure. You have three years of accumulated servers, half-remembered projects, and a bill you'd rather not discuss. So that's where Sencai starts: with what exists. You don't demo Sencai on toy data; you see your actual estate, your actual spend, your actual findings, in the first session. The product makes its case on your infrastructure or it doesn't deserve your business.

There's an honest trade-off here worth naming. A self-serve half-hour can't replicate everything a six-week guided POC does - deep custom integration, organisation-wide rollout planning, bespoke compliance mapping. We're not pretending it does. The claim is narrower and more useful: within 30 minutes you'll know whether Sencai is worth a serious evaluation, based on evidence from your own environment rather than our slides. The expensive ritual, if you still want it, can come after the product has earned it.

Is 30 minutes a gimmick, then? We don't think so. It's a forcing function for product quality. Every confusing form, every unclear permission prompt, every slow moment in that first half-hour gets found and fixed, because the clock is the spec - onboarding is a product surface we maintain, not a tutorial we wrote once. And it keeps us honest in a way no roadmap review can: a product that can't explain itself in 30 minutes to a stranger probably can't explain itself to your new hire in month six either.

Try it yourself: the trial is 14 days, full-featured, and nobody will call you unless you ask. Bring your messiest cloud account - that's the one we're built for.
On this page

## Legal and policies
Source: https://sencai.space/legal/imprint/

Last updated
Back to home
#### Privacy Policy
Sencai Tech s.r.o. ("Sencai", "we", "us"), with registered office in Prague, Czech Republic, is the controller of personal data processed through sencai.space and the Sencai platform. This policy explains what we process, why, on which legal bases, and how you can exercise your rights under the EU General Data Protection Regulation (GDPR). Contact for all privacy matters: privacy@sencai.space.
Data we collect
Account data (name, email address, company, role), billing data (company identifiers, VAT ID, billing address; payment card data is processed exclusively by our payment processor and never stored by us), product usage and telemetry data (features used, log and diagnostic data), security logs (authentication events, IP addresses, audit records), support and contact communications, and cookie data as described in the Cookie Policy.
Purposes and legal bases
We process personal data (a) to conclude and perform the contract with you - providing the platform, billing, and support (Art. 6(1)(b) GDPR); (b) for our legitimate interests - securing the service, preventing fraud and abuse, enforcing our terms, improving the product, and direct marketing to business contacts (Art. 6(1)(f)); (c) with your consent - analytics cookies and optional communications (Art. 6(1)(a)); and (d) to comply with legal obligations, in particular accounting and tax law (Art. 6(1)(c)).
Your infrastructure data - roles
For data contained in infrastructure you connect to or provision through the platform, you (or your organisation) act as the controller and Sencai acts as a processor, processing such data solely on documented instructions and under our Data Processing Agreement, which is published at sencai.space/legal/dpa/ and forms part of the Terms of Service. Where secret values you provide for Secret Injection contain personal data, you remain the controller of that data and Sencai processes it as a processor; Sencai stores such values in Sencai Vault and uses them only for delivery to your own infrastructure. This policy governs the data for which Sencai is the controller.
Recipients
We share personal data only with processors necessary to run the service: EU-based hosting and infrastructure providers, email delivery and company email, payment processing, AI model providers when you use the AI features, and self-hosted analytics and error-tracking operated by us. We do not sell personal data and do not share it with third parties for their own marketing. Public authorities receive data only where the law requires it.
International transfers
Personal data is stored and processed primarily in the EU/EEA. Where a sub-processor processes limited data outside the EEA, we rely on adequacy decisions or the European Commission's Standard Contractual Clauses together with supplementary safeguards.
Retention
Account and contract data is kept for the duration of the contract and thereafter for as long as statutory obligations require (e.g. up to 10 years for accounting records under Czech law) or as long as claims may be asserted. Audit log entries are append-only and are retained indefinitely for security and evidentiary purposes, with access restricted to those purposes; other security logs are retained for the period necessary for those purposes. Data processed on the basis of consent is deleted when consent is withdrawn.
Security
We protect personal data with measures appropriate to the risk, including encryption in transit over public networks and at rest, role-based access controls with support for multi-factor authentication, tenant isolation, and tamper-evident audit logging. We keep secret values you provide for Secret Injection in Sencai Vault, encrypted at rest. Platform services can reach these values only through dedicated credentials limited to storing them, reading them for delivery, or deleting them, over connections encrypted with TLS, and Sencai Vault keeps an audit trail of that access. Each delivery to your infrastructure is encrypted with a key generated for that delivery alone. No system is absolutely secure; we notify affected users and authorities of personal-data breaches as required by Articles 33 and 34 GDPR, and where we act as your processor we notify you as set out in the Data Processing Agreement.
Your rights
You have the right to access, rectify, erase, restrict, and port your personal data, to object to processing based on legitimate interests, and to withdraw consent at any time with effect for the future. Contact privacy@sencai.space; we respond within one month. You may also lodge a complaint with the Czech Office for Personal Data Protection (ÚOOÚ, www.uoou.gov.cz) or your local supervisory authority.
Automated decision-making
We do not carry out automated decision-making that produces legal or similarly significant effects concerning you. AI-assisted features of the platform operate on infrastructure data under your control and direction.
Changes to this policy
We may update this policy as the service or the law evolves. Material changes will be announced on this page and, for registered users, by email or in-app notice before they take effect.
#### Terms of Service
These Terms of Service ("Terms") form a binding agreement between Sencai Tech s.r.o. ("Sencai", "we") and the customer ("you") and govern all use of the Sencai platform and related services. By creating an account or using the service you accept these Terms on behalf of yourself and, where applicable, the organisation you represent - and you confirm you are authorised to do so. The service is intended for business use.
The service
Sencai is a multi-cloud control plane provided as Software-as-a-Service. Subscription tiers, quotas, and current capabilities are described on the Pricing page. Descriptions on the website are informational; we continuously develop the service and may modify, add, or retire individual features, provided the core character of the service is preserved.
Account and security
You must provide accurate registration information and keep it current. You are responsible for all activity under your account and for safeguarding credentials, including enabling the available security features (two-factor authentication, role-based access). Notify us immediately at security@sencai.space of any suspected unauthorised use.
Your responsibilities
You are solely responsible for the cloud accounts and servers you connect, the credentials you store, the workloads you run, and the lawfulness of the data you process through the platform. You remain the operator of your infrastructure; Sencai provides tooling, not operation of your systems, unless expressly agreed otherwise in writing. You must comply with the terms of the third-party providers whose accounts you connect.
Acceptable use
You must not use the service for unlawful purposes, to infringe third-party rights, to conduct security testing against systems you are not authorised to test, to disrupt the service or circumvent usage limits, or to resell or provide the service to third parties except as expressly permitted by your plan (e.g. MSP multi-organisation use). We may investigate violations and take proportionate technical measures.
Managed capacity and third-party providers
Where Sencai provisions and bills infrastructure capacity for you, the capacity is provided on infrastructure of third-party providers and remains subject to the applicable provider's service terms and availability. Sencai is not responsible for outages, changes, or discontinuation of third-party provider services outside our reasonable control; where we receive credits from a provider for such failures, we will pass on a corresponding benefit.
Fees, billing, and taxes
Subscription fees are charged in EUR, monthly or annually in advance, and are non-refundable except where these Terms or mandatory law provide otherwise. Subscriptions renew automatically unless cancelled before the end of the current period. All prices are exclusive of VAT and similar taxes. We may adjust prices with at least 30 days' notice, effective from the next billing period. Late payment may result in suspension of the service after notice, and statutory default interest may apply. Where an invoice remains unpaid, we suspend access on the 14th day after the due date and, if it is still unpaid, delete the affected resources on the 21st day. Resources in your own cloud accounts are never deleted.
Trial
New organisations receive a 14-day trial with full functionality, no payment card required; fair-use limits apply during the trial. We may modify or terminate trial availability at any time. At the end of the trial, continued use requires a paid tier; your configuration and data are retained for a reasonable period as described in the Termination section.
Intellectual property
The platform, its software, design, and documentation are and remain the exclusive property of Sencai or its licensors. You receive a limited, non-exclusive, non-transferable right to use the service for the term of your subscription. Your data remains yours; you grant us only the rights necessary to operate the service. If you provide feedback or suggestions, we may use them without restriction or compensation.
Confidentiality and data protection
Each party will protect the other's non-public information with at least reasonable care and use it only for purposes of the agreement. Processing of personal data is governed by our Privacy Policy and, where Sencai acts as processor, by our Data Processing Agreement, published at sencai.space/legal/dpa/, which forms part of these Terms; if you want a signature record, you can also sign it in the platform. Where you use Secret Injection, Sencai stores the secret values you provide, encrypted at rest, in Sencai Vault, a secret store that Sencai operates itself on Google Cloud infrastructure in the EU, as listed in our sub-processor register. Sencai treats these values as your non-public information under this section and uses them solely for delivery to your own infrastructure: a Kubernetes cluster, or servers running the Sencai agent where you enable it, and only to locations that the cluster's or server's own configuration allows. Stored values cannot be viewed or exported through the platform, and each delivery is encrypted with a key generated for that delivery alone. Earlier versions of a replaced value may be retained until the injection is revoked or deleted. After an injection is revoked or deleted, Sencai deletes the value and all retained versions from Sencai Vault without undue delay. When you revoke an injection, Sencai instructs the agent that received the value to remove it where such an instruction can be sent; where it cannot be sent or the removal is not confirmed, for example because the agent is offline or has been disconnected or delivery is switched off, the value may remain on your infrastructure. Any copy delivered to your infrastructure is under your control and can be read by anyone with sufficient access to the system that holds it, including privileged users and anyone you allow to run commands through the Sencai agent.
Warranties and disclaimer
The service is provided "as is" and "as available". To the maximum extent permitted by law, we disclaim all implied warranties, including merchantability, fitness for a particular purpose, and non-interruption. Availability commitments, where applicable, are governed exclusively by the SLA for your tier, and service credits under the SLA are your sole remedy for availability shortfalls.
Limitation of liability
To the maximum extent permitted by law, neither party is liable for indirect or consequential damages, loss of profits, revenue, goodwill, or data, and Sencai's aggregate liability arising out of or related to the service is limited to the fees you paid in the 12 months preceding the event giving rise to the claim. These limitations do not apply where liability cannot be limited under mandatory law (including damage caused intentionally or by gross negligence).
Indemnification
You will defend and indemnify Sencai against third-party claims arising from your data, your infrastructure, your breach of these Terms, or your violation of applicable law or third-party provider terms, including reasonable legal costs.
Suspension and termination
We may suspend the service wholly or partly with immediate effect where required to protect the service or other customers, in case of a serious security risk, unlawful use, or payment default after notice. Either party may terminate the agreement with 14 days' notice to the end of a billing period; we may terminate for cause with immediate effect. After termination you have 21 days to export your data, after which we delete it as set out in the Data Processing Agreement, subject to statutory retention duties.
Changes to these Terms
We may amend these Terms with at least 14 days' notice by email or in-app notification. If you do not agree with a material change, you may terminate the agreement effective the date the change takes effect; continued use after that date constitutes acceptance.
Final provisions
Neither party is liable for failures caused by events beyond its reasonable control (force majeure). You may not assign the agreement without our consent; we may assign it to an affiliate or in connection with a corporate transaction. If any provision is invalid, the remainder stays in effect. These Terms, including the Data Processing Agreement that forms part of them, constitute the entire agreement regarding the service and supersede prior arrangements.
Governing law and venue
These Terms are governed by the laws of the Czech Republic, excluding its conflict-of-law rules and the UN Convention on Contracts for the International Sale of Goods. Disputes will be resolved by the competent courts of Prague, Czech Republic.
#### Data Processing Agreement
This Data Processing Agreement ("DPA") sets out how Sencai processes personal data on behalf of its customers, as required by Article 28 of the EU General Data Protection Regulation (GDPR). It forms part of the Terms of Service and applies to every customer from the moment the Terms are accepted. Terms such as "personal data", "processing", "controller", "processor", "data subject" and "personal data breach" have the meaning given to them in the GDPR.
Parties and how this DPA applies
This DPA is concluded between Sencai Tech s.r.o., with registered office in Prague, Czech Republic, registered with the Municipal Court in Prague ("Sencai", "we"), and the customer that has accepted the Terms of Service ("you"). It forms part of the Terms and becomes binding when you accept them; no separate signature is needed. If you want a signature record for your files, an owner or admin of your organisation can sign this DPA in the platform. The current version is published at sencai.space/legal/dpa/. This is version 1.0 of this DPA. For customers who accepted an earlier version of the Terms, it applies as an amendment to the Terms in accordance with their provisions on changes.
Scope and roles
This DPA applies to personal data that Sencai processes on your behalf in providing the service, as described below ("Customer Personal Data"). For Customer Personal Data you, or the organisation you represent, are the controller and Sencai is the processor. Where you are yourself a processor for another controller - for example a managed service provider acting for its clients - Sencai acts as your sub-processor, and you ensure that your instructions to Sencai are authorised by that controller. Personal data that Sencai processes for its own purposes, such as account registration, billing and keeping the service secure, is outside this DPA and governed by the Privacy Policy, under which Sencai is the controller. Some records, such as sign-in events and the audit trail, serve both purposes: they are processed under this DPA when used to provide the service to you, and under the Privacy Policy when used to keep the service secure.
Order of precedence and language
If this DPA and the Terms conflict on the processing of personal data, this DPA prevails. This DPA is written in English. Translations are provided for convenience; where a translation differs from the English version, the English version prevails.
Subject matter, duration, nature and purpose
The subject matter of the processing is the provision of the Sencai platform, a multi-cloud control plane provided as software-as-a-service under the Terms. The processing lasts for the term of the agreement and afterwards until Customer Personal Data has been deleted as described in the section on deletion and return. It consists of collecting data through the connections you set up; storing, organising and displaying it to your authorised users; analysing it, for example for security scanning, cost analysis and, where you use them, the AI features; transmitting it to your infrastructure and to the providers you work with through the platform; carrying out the actions you request at cloud providers and on your servers; and deleting it. The purpose is to provide the service to you in accordance with the Terms and your instructions, including the support you ask for and the security of that processing as required by Article 32 GDPR.
Categories of data subjects
Customer Personal Data may relate to the following data subjects:
Your authorised users of the platform, such as your employees and contractors.

Members of your workforce whose records are synchronised from a directory you connect, such as Microsoft Entra ID, Microsoft 365 or Google Workspace.

Individuals whose personal data is contained in the infrastructure, servers, logs, terminal sessions or secret values you connect to or manage through the platform, for example your own customers and end users.
Categories of personal data
Depending on the features you use, Customer Personal Data may include the categories below. The service is not designed for special categories of personal data (Article 9 GDPR) or personal data relating to criminal convictions and offences (Article 10 GDPR). If your infrastructure, logs or secret values contain such data, you are responsible for assessing whether the measures in this DPA are appropriate before processing it through the service.
Infrastructure data: inventory, configuration and metadata of the cloud resources and servers you connect or provision, such as resource names, tags, IP addresses, DNS records and firewall rules, which can contain personal data.

Credentials for the cloud accounts you connect, stored encrypted.

Data collected by the Sencai agent from servers where you install it, such as installed software and patch status, security scan results, and system and application logs.

Browser terminal sessions: records of who connected to which server and when, and the data passing through a session while it is open.

Directory and identity data, where you connect a directory: user and group records, sign-in and administrative events including email addresses, IP addresses and browser or device information, and mailbox inventory.

The audit trail of your organisation: which user performed which action and when, with IP address and browser information.

Secret values you provide for Secret Injection.

Content you submit to the AI features, together with the infrastructure context sent with it.
Documented instructions
Sencai processes Customer Personal Data only on your documented instructions, including with regard to transfers to countries outside the European Economic Area, unless EU or Member State law requires otherwise; in that case Sencai informs you of that legal requirement before processing, unless that law prohibits it on important grounds of public interest. Your instructions are the Terms, this DPA and the way you use and configure the service, including through its interface and API. Additional instructions must be given in writing, for example to privacy@sencai.space, and must be consistent with the Terms. Sencai informs you immediately if, in its opinion, an instruction infringes the GDPR or other EU or Member State data protection law. You are responsible for the lawfulness of your instructions and of the personal data you process through the service.
Confidentiality
Sencai gives access to Customer Personal Data only to persons who need it to provide, support or secure the service, and ensures that everyone authorised to process Customer Personal Data is bound by confidentiality obligations or is under an appropriate statutory obligation of confidentiality.
Security of processing
Sencai implements technical and organisational measures to ensure a level of security appropriate to the risk, as Article 32 GDPR requires. The measures currently in place include those listed below. Sencai may update them as technology and risks develop, provided the overall level of security is not reduced.
Hosting of the platform in EU regions of Google Cloud.

Separation between organisations: resources are associated with the organisation they belong to, and your users' access is checked against that organisation.

Role-based access within each organisation, so users can see and change only what their role allows.

Encryption with TLS for connections to the platform over public networks; the Sencai agent on servers additionally uses a mutually authenticated connection.

Encryption at rest (AES-256-GCM) of the credentials for connected cloud accounts, which are not displayed back through the platform.

Secret values held in Sencai Vault, as described in the next section.

Protection of sign-in against repeated password guessing, short-lived access tokens, and support for multi-factor authentication and single sign-on.

Network policies that limit which internal services can communicate with each other.

An append-only, hash-chained audit trail in which altering or removing a past entry is detectable.

Backups of the platform database that are encrypted before they are stored.
Sencai Vault and Secret Injection
Where you use Secret Injection, Sencai stores the secret values you provide, encrypted at rest, in Sencai Vault, a secret store that Sencai operates itself on Google Cloud infrastructure in the EU. Sencai uses these values solely for delivery to your own infrastructure: a Kubernetes cluster, or servers running the Sencai agent where you enable it, and only to locations that the cluster's or server's own configuration allows. Stored values cannot be viewed or exported through the platform. Platform services can reach them only through dedicated credentials limited to storing them, reading them for delivery, or deleting them, and traffic between platform services and Sencai Vault is encrypted with TLS. Sencai Vault records an audit trail of access to it, in which credentials appear only as keyed hashes (HMAC). Each delivery is encrypted with a key generated for that delivery alone. A value is released to a cluster or server only after an administrator of your organisation has trusted its agent, and only to the credential that agent held when it was trusted. Earlier versions of a replaced value may be retained until the Secret Injection is revoked or deleted. After it is revoked or deleted, Sencai deletes the value and all retained versions from Sencai Vault without undue delay, and Sencai deletes all such values before an organisation is deleted. When you revoke a Secret Injection, Sencai instructs the agent that received the value to remove it where such an instruction can be sent; where it cannot be sent or the removal is not confirmed, for example because the agent is offline or has been disconnected or delivery is switched off, the value may remain on your infrastructure. Any copy delivered to your infrastructure is under your control and can be read by anyone with sufficient access to the system that holds it, including privileged users and anyone you allow to run commands through the Sencai agent.
Sub-processors
You give Sencai general written authorisation to engage the sub-processors listed in the sub-processor register at sencai.space/legal/subprocessors/. Sencai imposes on each sub-processor, by a written contract, data protection obligations that offer at least the same level of protection as those in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures, as Article 28(4) GDPR requires. Sencai remains fully liable to you for the performance of each sub-processor's obligations, subject to the Liability section. Cloud providers whose accounts you connect yourself are not Sencai's sub-processors: those accounts remain under your own contract with the provider, and Sencai acts in them only on your instruction. Where Sencai runs your resources in cloud accounts it operates, the provider underneath is named to you as a sub-processor before the arrangement starts and is added to the register. Sencai gives notice of any intended addition or replacement of a sub-processor at least 14 days before it takes effect, by updating the register and emailing the owners of your organisation. You may object to the change in writing to privacy@sencai.space within that period; Sencai will then work with you in good faith to resolve the objection, and if it cannot be resolved, you may terminate the affected service, or the agreement where the service cannot be provided without that sub-processor, with effect before the change applies to your data.
International transfers
Customer Personal Data is stored primarily in the EU/EEA. Where a sub-processor processes it outside the European Economic Area, the transfer relies on the basis stated for that sub-processor in the register - an adequacy decision of the European Commission or the Standard Contractual Clauses - together with supplementary safeguards where required. The AI features send the content you submit to them to the model providers named in the register, which may process it outside the EU; they are engaged only when you use those features. Where you choose a region outside the European Economic Area in a cloud account you connect yourself, data goes there on your instruction.
Assistance with data subject requests
Taking into account the nature of the processing, Sencai assists you with appropriate technical and organisational measures, insofar as this is possible, in responding to requests from data subjects exercising their rights under Chapter III GDPR. The service provides self-service tools for this: your users can export the personal data held about their account and request erasure of their account from the platform's privacy settings, and your organisation's audit trail can be exported. Where these tools are not sufficient, Sencai provides reasonable further assistance on request to privacy@sencai.space. If Sencai receives a request directly from a data subject concerning Customer Personal Data, it informs you and does not respond to the request itself unless you instruct it to or the law requires it.
Assistance with security, impact assessments and consultations
Taking into account the nature of the processing and the information available to Sencai, Sencai assists you in meeting your obligations under Articles 32 to 36 GDPR - security of processing, notification of personal data breaches, data protection impact assessments and prior consultation of a supervisory authority. It does so in particular by making available this DPA and its description of security measures, the sub-processor register, the data residency statement, records of processing where your plan includes them, and an export of your audit trail, and by answering the reasonable questions you have for these purposes.
Personal data breaches
Sencai notifies you of a personal data breach affecting Customer Personal Data without undue delay and in any case within 72 hours after becoming aware of it, by email to the owners of your organisation. The notification describes, to the extent the information is available at the time, the nature of the breach including, where possible, the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address the breach and mitigate its possible adverse effects; and a contact point for further information. Where not all of this information is available at once, Sencai provides it in phases without further undue delay. Sencai takes reasonable steps to contain the breach and supports you in notifying the supervisory authority and affected data subjects where you are required to do so.
Deletion and return at the end of the agreement
After the agreement ends you have 21 days to export your data using the export functions of the service, as set out in the Terms. Once that period has passed, Sencai deletes Customer Personal Data unless EU or Member State law requires it to be stored. Deletion is carried out as a process rather than at a single moment; until it is complete, the data is kept only for the purpose of deleting it. In addition:
Data in backups is not removed from each backup individually. It is deleted when the backups containing it are deleted, at the latest one year after each backup was made; until then, backups remain encrypted and are used only for restoring the service.

Entries in your organisation's audit trail are not deleted, because the audit trail is append-only by design. After the agreement ends, Sencai retains them as controller, solely for security and evidentiary purposes as described in the Privacy Policy, with access restricted to those purposes.

Secret values in Sencai Vault are deleted when the Secret Injection is revoked or deleted, and in any case before your organisation is deleted.

Resources in cloud accounts you connect yourself remain yours and are never deleted by Sencai as part of ending the agreement.
Audits and information
Sencai makes available to you the information necessary to demonstrate compliance with the obligations in Article 28 GDPR. It does so primarily through documentation: this DPA, the sub-processor register, the data residency statement, records of processing where your plan includes them, an export of your audit trail, and written answers to reasonable security questionnaires. Sencai does not hold ISO 27001 or SOC 2 certification. To the extent Article 28(3)(h) GDPR requires it, or where a supervisory authority demands it, Sencai also allows for and contributes to audits, including inspections, conducted by you or by an auditor you mandate. Such audits require reasonable prior notice, are carried out at your cost and under confidentiality obligations, and must not give access to other customers' data or compromise the security of the service. Requests go to privacy@sencai.space.
Liability
Liability arising out of or in connection with this DPA is subject to the limitation of liability in the Terms, to the extent mandatory law allows. Nothing in this DPA limits the rights that data subjects have under the GDPR.
Term, changes and governing law
This DPA applies for as long as Sencai processes Customer Personal Data on your behalf, including after the Terms end until deletion is complete. Sencai may amend this DPA in the same way as the Terms, with at least 14 days' notice by email or in-app notification; if you do not agree with a material change, you may terminate the agreement effective the date the change takes effect. This DPA is governed by the laws of the Czech Republic, and disputes will be resolved by the competent courts of Prague, Czech Republic, as set out in the Terms.
Contacts
Questions about this DPA, data protection requests, instructions and objections to sub-processor changes: privacy@sencai.space. Security incidents and vulnerability reports: security@sencai.space. Sencai sends notices under this DPA to the email addresses of the owners of your organisation, so please keep them current.
#### Cookie Policy
This policy explains how Sencai Tech s.r.o. uses cookies and similar technologies (localStorage, session storage) on sencai.space. Our approach is deliberately minimal: no third-party advertising trackers, no cross-site profiling, and nothing non-essential without your consent, in line with the ePrivacy rules and GDPR.
Strictly necessary
Required for the site to function and to remember your cookie choice itself (consent storage, security, load balancing). These are exempt from the consent requirement and cannot be disabled. Legal basis: our legitimate interest in operating a secure website.
Analytics (consent-based)
With your consent we measure site traffic (page views, referrers, approximate region) using self-hosted analytics operated by us - data stays under our control, is not shared with advertising networks, and is not used to identify you. Withholding or withdrawing consent does not limit your use of the site.
Marketing
We currently use no marketing or advertising cookies of any kind. If that ever changes, we will ask for your explicit consent first and update this policy before doing so.
Managing your preferences
Use the cookie banner on your first visit, or the "Manage cookies" link in the footer at any time, to accept, reject, or customize non-essential cookies. Withdrawing consent takes effect immediately for future processing. You can additionally delete or block cookies in your browser settings; blocking strictly necessary cookies may break parts of the site.
Retention
Your consent choice is stored locally for up to 12 months or until you change it, whichever comes first. Analytics data is retained in aggregate form only as long as needed for the purposes described above.
Contact
Questions about this policy or our use of cookies: privacy@sencai.space. Details on how we handle personal data generally are in the Privacy Policy.
#### Service Level Agreement
This Service Level Agreement (SLA) defines the availability commitments for the Sencai platform and the service credits that apply when we miss them. Availability is a service level you buy - it is carried by human response time, not by a feature that is switched on or off - so what applies to you is the level agreed in your contract, not the name of a package. It supplements the Terms of Service.
Uptime commitment
Three service levels are offered: 99.9%, 99.95% and 99.99% monthly uptime. Which one applies is agreed in your contract, together with the response times and out-of-hours cover that back it; a higher level costs more because people carry it, not because it unlocks anything in the product. Organisations without an agreed service level - including every free and self-service organisation - are provided without a contractual SLA. Uptime refers to the availability of the Sencai control plane (dashboard and API).
How uptime is measured
Availability is measured per calendar month as the percentage of minutes in which the control plane responded to our external synthetic monitoring. Partial unavailability affecting a single non-critical feature does not count as downtime.
Exclusions
Downtime caused by scheduled maintenance (announced at least 48 hours ahead), failures of third-party cloud providers or customer-managed infrastructure, customer misconfiguration, force majeure, or suspension for breach of the Terms is excluded from the calculation.
Service credits
If monthly uptime falls below the committed target, you are eligible for a credit on that month's subscription fee: below target 3%, below 99.0% 5%, below 95.0% 10%. Credits are applied to future invoices and are the exclusive remedy for availability shortfalls.
Claiming a credit
Credit claims must be submitted within 30 days of the incident via hello@sencai.space, including the affected time window. We verify against our monitoring data and confirm within 10 business days.
#### Imprint
Information required by Czech law (§ 14 of Act No. 480/2004 Coll.) and the EU Directive on Electronic Commerce.
Operator
Sencai Tech s.r.o.
Registered office
Praha, Czech Republic
Company ID
VAT ID
Contact
hello@sencai.space
Registered with
Municipal Court in Prague
#### Sub-processors
The companies that process data on Sencai's behalf when you use the platform: what they do, where they are, and on what basis data may leave the EU. We publish this openly, with no questionnaire and no NDA first.
2026-09-14
##### Google Cloud
Hosting and infrastructure: compute, storage, secret and key management, DNS, and the container registry for our website and contact form.
EU regions (Belgium, Germany)
Processed in the EU
##### Stripe
Payments and subscription billing. Card details go to Stripe directly and are never stored by us.
Ireland (Stripe Payments Europe)
SCCs for onward transfer
##### Resend
Delivery of transactional email: sign-up, notifications, alerts and billing messages.
United States
Standard Contractual Clauses
##### Anthropic
Default model provider for the AI features - incident analysis and the in-product assistant. Engaged only when you use those features, not for the platform in general.
United States
Standard Contractual Clauses
##### OpenAI-compatible model endpoint
Alternative model backend for the same AI features, used only where one is configured in place of the default provider.
Wherever the configured endpoint is operated
Depends on that endpoint: an EU endpoint keeps processing in the EU, a US one transfers under Standard Contractual Clauses
##### Google Workspace
Company email and correspondence, including messages sent to privacy@sencai.space, security@sencai.space and our other addresses.
Any country where Google or its sub-processors maintain facilities, including the United States
Standard Contractual Clauses, under Google's Cloud Data Processing Addendum
Your own cloud accounts are not on this list, and that is deliberate: when you bring your own cloud account it stays yours, under your own contract with that provider, and we act only on your instruction - so that provider is not our sub-processor. Error tracking, product analytics, billing metering and observability run on our own infrastructure rather than someone else's service, which is why no telemetry vendor appears here either. Sencai Vault, where we store the secret values you provide for Secret Injection, is run by us on the Google Cloud infrastructure listed above rather than by another company, which is why it has no entry of its own here. The container images the platform runs from are hosted on GitHub Container Registry; they contain our software and no customer data, which is why GitHub is not listed either. For the AI features we are working towards EU-hosted infrastructure.
We announce an intended addition or replacement of a sub-processor at least 14 days before it takes effect, by updating this register and emailing organisation owners, as set out in our Data Processing Agreement. Questions about this register: privacy@sencai.space.
#### Data residency
Where your data is stored, where it may be processed, and what changes depending on whose cloud account your infrastructure runs in.
Stored in the EU by default
The platform and its databases run in EU regions - Belgium and Germany. That is where your account data, your audit trail and your operational records are held. No storage region outside the EU is used by default for the platform, and we do not offer a region we do not actually operate.
Where your workloads run
##### Managed Sencai accounts (recommended)
Your resources run in cloud accounts that Sencai operates. Our Data Processing Agreement, which forms part of our Terms, covers the arrangement, so you do not have to procure, negotiate and review every infrastructure provider yourself, and the provider underneath is named to you as a Sencai sub-processor before the arrangement starts, and added to our sub-processor register. Sencai holds the account with that provider and invoices you for it: their charges are passed through with 2% added, and every organisation carries a monthly ceiling on what may be spent on our accounts. It is arranged with you during onboarding rather than switched on from a settings page, so talk to us if you want it.
##### Your own cloud account
You connect accounts you already have, with credentials you supply, and we act only on your instruction. Those accounts stay yours under your own contracts with each provider, so the provider is not our sub-processor, and the region is whichever one you pick - including regions we do not operate in ourselves.
##### Your own hardware
The fleet agent works the same way on bare-metal and on-premise servers as it does in a cloud account, so workloads that must never leave your own building do not have to.
Stored and processed are not the same question. Your data is stored in the EU, but it is processed wherever a listed sub-processor operates: payments through Ireland, transactional email and our company email in the United States and - only if you use the AI features - incident analysis and the in-product assistant through a model provider in the United States. Those transfers run under Standard Contractual Clauses, every one of them is named on the sub-processor page, and for the AI features we are working towards EU-hosted infrastructure.