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.
Three ways to deploy. All of them yours.
Your infrastructure, your data centre, your identity provider. Updates arrive as signed artefacts you apply on your own schedule.
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.
Where policy permits controlled cloud: single-tenant deployment in EU-resident infrastructure under your control and your keys. The same no-egress guarantees apply.
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.
- 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.
Documented posture, not promised posture.
These are status lines. Publish only the ones that are true on the day the page ships; leave the rest as bracketed placeholders — do not present a future plan as a present fact.
- Independent penetration test of the deployment model by a CREST-accredited firm: [status + date]
- SOC 2 Type I: [status] · SOC 2 Type II observation window: [status, named auditor]
- ISO 27001: [status]
- Vulnerability disclosure programme: published at /.well-known/security.txt, with a named responder and a stated triage SLA.
- Customer security reviews cleared: [publish “N customer security reviews cleared” 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.
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.
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.
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.