Built for the people who have to say yes.
Security, quality and validation teams carry the risk of any AI system. This page is written for them: where OwnIQ runs, what it can reach, how it's protected, and how every answer can be traced.
Principles
Five rules every design decision has to pass.
By default there is no inbound internet access and only allow-listed outbound traffic.
The same hardened stack runs on a single server or a multi-rack cluster, so updates and support stay predictable.
If a GPU server fails, search, ingestion and administration keep running; only the model degrades.
Everything is remotely manageable through sessions you approve, updates are signed bundles, and it works fully air-gapped.
Our fleet tooling only ever sees metadata: versions, uptime, GPU utilisation and any aggregate eval scores you agree to share.
Where it runs
Every pilot starts in your own cloud account so work can begin in week one, while hardware is ordered. The platform is identical in all four models.
| Model | Where the hardware lives | Who owns it | Best for |
|---|---|---|---|
| On-premMaximum control | Your server room | You, bought or leased | Sites with adequate power and cooling |
| Your coloExisting data-centre cage | Your colocation facility | You | Organisations already running their own racks |
| Dedicated coloHardware as a service | A single-tenant cage we operate | OwnIQ, dedicated to you | Teams without a data centre |
| Your cloudBring your own cloud | Your AWS, Azure or GCP account | You rent the GPUs | Pilots and cloud-first organisations |
Architecture
Everything that touches your content runs inside your environment. The only thing outside is an optional fleet console that sees health metadata, and in air-gapped deployments it runs inside too.
Threat model
The threats your security team will raise, and the control that answers each one.
| Threat | Control |
|---|---|
| Server stolen or disk removed | Full-disk encryption with keys sealed to the TPM plus a customer-held or network-bound key. A disk on its own is unreadable. |
| Tampered software | Secure Boot, signed container images, a software bill of materials per release, and an admission policy that rejects anything unsigned. |
| Data exfiltration over the network | No inbound internet. Outbound only through an allow-listed forward proxy; every request logged. |
| Our own staff | No standing access. You approve each support session; sessions are time-boxed, SSO-authenticated and recorded. Read access to content is off by default. |
| Lateral movement | Network policies between services, mutual TLS, and separate networks for management, cluster, service and egress traffic. |
| Unauthorised user access | SSO and MFA from your identity provider, with group permissions mirrored from each source system. |
| The model leaking restricted informationThe one people forget | Scoped adapters trained only on data every user may see; sensitive facts retrieved rather than trained in; planted canaries tested on every release. |
| Audit and accountability | An immutable log of who asked what, which documents were retrieved and which model version answered, exportable to your SIEM. |
Data handling
Content and metadata from the sources you connect, the access rules for each item, and version history, which is where much of the learning signal lives.
Highly sensitive facts, client IP at contract manufacturers, and anything not visible to every user of a given model. These are retrieved at query time with permissions checked.
Pseudonymised or removed before it can train any broadly shared model, with memorisation probes in the eval suite.
Lineage maps every source record into the datasets and models that used it. Delete the record and the next release is rebuilt without it.
Usage traces feed improvements under the retention policy you set. You decide how long anything is kept.
Off by default. If you enable it for low-sensitivity work, entities are replaced with placeholders before anything leaves and restored on return.
Model governance
No model reaches your users until it passes a release gate you define. The default policy:
| Gate | Requirement |
|---|---|
| Beats the current modelBlind, pairwise | At least 55% win rate, with the 95% confidence interval above 50%. That needs roughly 400 or more cases, so small eval sets can't sneak a release through. |
| Reaches your team's decisions | Accuracy on held-out past decisions, all dated after the training cutoff, is no worse than the current model. |
| Keeps general skill | No regression beyond your threshold, for example −2 points, on standard reasoning and instruction-following tests. |
| Leaks nothing | Zero leakage-canary failures across every scoped model. |
| Your experts agree | A subject-matter expert reviews the 30 to 50 biggest changes in output before sign-off. |
Releases go through shadow mode and a canary group before promotion. The previous version stays loaded, so rollback takes one command. Every answer is traceable to a model version, adapter, dataset version and the sources retrieved.
Regulated use
No US rule forces AI on-prem. What does shape it is trade-secret law, client contracts and validation rules. OwnIQ is designed around those, and around a clear boundary on what AI should do.
Non-critical work
Search across procedures and past deviations, first drafts, training material.
Allowed today, with qualified human review of each output.
Regulated documents
Procedures, specifications, deviation reports.
AI drafts; the quality unit reviews and approves in OwnIQ, with a full audit trail.
Critical decisions
Batch release, accept or reject, anything affecting data integrity.
Out of scope. These stay with qualified people.
Owning the weights means you decide when the model changes, not a vendor's deprecation schedule.
Improvements are bundled into versioned releases your quality unit approves. The model in production never learns on its own, in line with the direction of the EU's draft Annex 22.
Secure, computer-generated, time-stamped audit trails for every output that becomes a record.
Documentation to support your risk-based computer software assurance approach. OwnIQ supports your validation; it doesn't replace it.
Support and access
| Remote support | Every session approved by you, SSO-authenticated, time-limited and recorded. You hold a kill switch. |
| Who does what | Your IT handles power and physical access. We handle everything else remotely, through those approved sessions. |
| Patching | Monthly OS and security patches, quarterly driver updates, each staged on our own lab system first. |
| Hardware failure | Manufacturer on-site parts, typically within hours. The model keeps serving on remaining GPUs in degraded mode. |
| Availability targets | 99.5% for single-server pilots; 99.9% for the gateway in production deployments. |
| Company assurance | We're building toward SOC 2 Type II and ISO 27001 for our own processes. Ask us for our current security documentation. |
Common questions from security teams
No. Connectors reach your own tenant through the allow-listed egress proxy. We document every domain up front for your firewall review.
As signed offline bundles of container images, configuration and model weights, on encrypted media or through a one-way transfer.
Not by default. Content read access is disabled for our staff, and any session requires your approval and is recorded.
We favour permissive licences and flag anything else for legal review. A software bill of materials ships with every release.
Have a security questionnaire? Send it with your briefing request and we'll work through it with you.
Book a briefing