Start a pilot

DEPLOYMENT & SECURITY

The deployment model is the security model.

Qeino runs inside your perimeter, under your identity controls. This page states the operating boundary. The detailed architecture, connector scopes and current assurance status are reviewed directly with your security team.

Request the Security OverviewStart a pilot

02Deployment

Built around customer control.

On-premises
Qeino services and storage run on your infrastructure. Your team controls identity and access. Deployment and update procedures are agreed during technical review.
Air-gapped
Qeino is designed for environments without external connectivity. The exact deployment, inference and update path is confirmed during technical review.
EU-sovereign
Where policy permits controlled cloud, a single-tenant EU-resident deployment can be scoped under customer-controlled access and key-management requirements.
Main path — Qeino runtime inside the customer perimeter
OUTSIDE THE PERIMETERCUSTOMER PERIMETERSource systemsJira · GitHub · SlackIdentity providerCustomer SSO · SCIMQeino servicesProcessing · Inference · Evidence writerEvidence store (customer-controlled)read-onlycontrols accesswrites recordSigned updates inCurrent (Qeino runtime)Customer-controlledAccess controlSigned update path
Air-gap variant — separated update path
AIR-GAP OPTION · NO INBOUND NETWORKSigned mediaUSB · optical · courierCustomer reviewSignature checkQeino servicesInside air-gapped perimeter
Section02 · Deployment

03Access surface

Read-only first. Explicit scope throughout.

Qeino reads authorised work-item metadata, repository activity and team threads from the connectors agreed for the pilot. Access is documented by system and field.

What does not happen

  • Engineering data does not leave the agreed deployment boundary for analytics, support or model improvement.
  • Credentials do not leave the agreed deployment boundary.
  • Qeino does not take write authority by default.
  • Qeino does not score individual engineers.

Any later action authority is explicit, narrow and revocable by the customer.

Section03 · Access surface

04Current evidence

Dates and status, not trust badges.

The Security Overview sets out the architecture, data flow, access surface, deployment path and current assurance status. Test and certification claims appear only when the work is complete or the current stage can be named and dated.

Requests go to the technical team. If an item is not yet available, the answer will say so.

Section04 · Current evidence

05Regulation

Programme measurement, not workforce scoring.

EU AI Act

Qeino is built for programme delivery decisions. It is not intended for hiring, dismissal, compensation or individual performance decisions.

Sector and regulatory requirements are reviewed with the customer’s legal and security teams. Qeino does not publish a compliance claim before its supporting analysis exists.

Section05 · Regulation

06Vendor maturity

Treat an early-stage vendor as a risk to test.

You should assess Qeino’s security, continuity, ownership and financial position before placing it on a live programme.

We answer those questions with current documents and explicit gaps. We do not use the pilot to bypass procurement; we use it to give procurement evidence before a longer contract.

Section06 · Vendor maturity

07Next step

Put your security team in front of ours.

Bring the architecture questions early. It is faster for both sides.

Request the Security Overview