01 / Deployment & Security

The deployment model is the security model.

Qeino runs inside your perimeter — on-premises, air-gapped, or in EU-sovereign infrastructure under your control. No engineering data leaves, because there is nowhere for it to go. This page documents what that means in practice: what Qeino reads, what it can never do, and the posture behind it.

02 / Deployment models

Three ways to deploy. All of them yours.

On-premises

Your infrastructure, your data centre, your identity provider. Updates arrive as signed artefacts you apply on your own schedule.

Air-gapped

Full operation with no external connectivity of any kind. Deployment, updates and model operation all function offline — built as the primary case, not the degraded one. There is no feature that quietly needs a connection.

EU-sovereign

Where policy permits controlled cloud: single-tenant deployment in EU-resident infrastructure under your control and your keys. The same no-egress guarantees apply.

03 / Access surface

A narrow, documented, read-only surface.

Qeino connects read-only to Jira, GitHub, Azure DevOps and Slack inside your perimeter — work-item metadata, repository activity and team threads, in the scope you grant. The full access surface is documented per connector in the Security Overview.

What never happens, by architecture:
  • No engineering data leaves your perimeter — not for analytics, telemetry, support or model improvement.
  • No source code, credentials or model weights are transmitted to Qeino or anyone else.
  • No write access to your systems of record without explicit, revocable, per-action authority controlled by your CTO.
  • No individual-level performance scoring. The unit of measurement is the programme. That is a design commitment, not a configuration.

Nothing leaves. Not code, not telemetry, not trust placed and then tested.

04 / Security posture

Documented posture, not promised posture.

Penetration test
Independent penetration test of the deployment model by a CREST-accredited firm
[status + date]
SOC 2
SOC 2 Type I · SOC 2 Type II observation window
[status] · [status, named auditor]
ISO 27001
ISO 27001
[status]
Customer reviews
Customer security reviews cleared
[EVIDENCE SLOT — “N customer security reviews cleared”, publish only when true]

Security documentation — architecture, access surface, data handling, test summaries — is available under NDA. The request goes to a named security lead, not a sales queue.

05 / Compliance position

Where Qeino stands under EU regulation.

EU AI Act. Qeino measures programme capacity, not individual workers — built, documented and operated to stay clearly outside employment-decision use. Our position paper, prepared with external EU regulatory counsel, is available to your legal team.

NIS2. For in-scope customers, perimeter deployment simplifies the supplier question materially: there is no data egress to assess. The NIS2 mapping for sovereign deployments is documented and available on request.

MDR and sector regimes. Where your industry adds documentation and audit-trail obligations, the Ledger’s signal-level traceability is designed to support them, not complicate them.

06 / Vendor stability

The questions procurement should ask a young vendor — answered in writing.

We are an early-stage company, and your procurement team will treat that as a risk. Correctly. So we answer it in writing rather than in reassurances: source-code escrow with a regulated-grade depositary, standard on sovereign contracts. A financial-viability pack — capitalisation, runway, governance, key-person commitments — available to procurement under NDA. And a pilot structure that puts evidence of value in your hands before a contract asks anything of you.

07 / Talk to security

Put your security team in front of ours.

The fastest route through a regulated evaluation is a direct conversation between security engineers. We bring documentation, not slides.