Where it runs
Your data is yours. It can stay on your own hardware.
The strongest guarantee against anyone at MAIA seeing your data is not a policy, an NDA or an access-control list. It is that the data is never on our side of the network.
Read this first
Three words that tell you how much to trust each line.
A security document that blurs what is inherent with what is chosen is not useful to a reviewer. So every claim below carries one of three markers.
-
Architectural
A property of how the platform is built. It is not a setting, it cannot be switched off and it is the same in every deployment.
-
Deployment option
Supported by the platform and chosen per client, because the right answer depends on your infrastructure, your key management and your regulator.
-
Built on request
A capability that follows directly from the architecture and is delivered as a scoped item of your deployment. Commissioning work against a known design, on a date in your contract. Not research.
Capability and configuration are different questions. What is switched on for you is named in the security schedule for your deployment, and that is the document that binds us.
Deployment option
Where your data lives.
The platform runs in three configurations. They differ in exactly one respect that matters to a security reviewer: whose infrastructure holds the data, and therefore whose staff could conceivably reach it.
| Configuration | Where the record sits | Where inference runs | Who can reach the data |
|---|---|---|---|
| Fully private | Your servers, inside your perimeter | Your GPUs, inside your perimeter | Your staff only. No MAIA access path exists. |
| Private cloud | Your cloud tenancy, your region | Your model endpoint, your contract | Your staff, plus whoever your own cloud controls admit. |
| Managed | MAIA-operated region you nominate | Managed model endpoint under zero-retention terms | Your staff, plus named MAIA operators under control. |
-
Air-gapped operation
With a model running on your own hardware, a MAIA deployment has no required outbound network dependency for normal operation. Updates are delivered as signed artefacts and can be applied from media. This is the configuration for classified, sovereign and safety-critical environments, and it is a supported one rather than a special build.
-
Residency
Where the record physically sits is a deployment decision, and the platform does not constrain it. On your own hardware, in your own cloud region or in a managed region you nominate. MAIA BRAIN is a Malta entity and EU data protection law is the baseline we design to.
Deployment option
Encryption is the easy half. Who holds the keys is the half that matters.
All network traffic uses TLS 1.3, with mutual TLS available between platform components and for machine-to-machine connectors. Data at rest is encrypted with AES-256: the record, the object store holding documents, backups and any derived index or cache. There is no tier of storage exempt from this.
| Custody model | Key held by | What it gives you |
|---|---|---|
| Platform-managed | MAIA-operated KMS | Simplest to run. Protects against storage compromise and a lost backup, not against a compelled or malicious operator. |
| Customer-managed | Your KMS, your cloud account | You can revoke at any moment, unilaterally. Revocation renders the data unreadable to us as well as to an attacker. |
| Hold-your-own-key | Your HSM, on your premises | Every decryption requires a call your hardware can refuse and always logs. You hold a veto over each use, not just over access. |
| Fully private | You, entirely | There is no MAIA-side copy for a key to protect. Custody is not shared, so it cannot be misplaced. |
-
Separation per client
Key hierarchies are per client instance. There is no key whose compromise crosses a tenancy boundary, because there is no key shared across one.
-
Rotation without migration
Keys rotate on a policy you set, and on demand after any event you judge to warrant it. Rotation does not require re-encrypting or moving your data.
-
Erasure by key destruction
Destroying the key hierarchy renders every copy unreadable at once, including backups and snapshots. Deletion by key destruction is verifiable in a way deletion by request is not.
Deployment option
The model is a component. It can be yours.
The language model MAIA uses is a replaceable component, and which one serves a deployment is your choice. There is no architectural dependency on a particular provider.
-
Your own hardware
MAIA can be pointed at models running on physical GPUs you own and operate, in your own data centre. No inference traffic leaves your estate.
-
Your own private endpoint
A model instance in your own cloud tenancy, under your own provider contract, subject to retention terms you negotiated and can audit.
-
Egress control
A deployment can be set to deny all outbound network access except an explicit allow-list. Where the model is local, that list can be empty. Enforced at the network boundary, not by the application.
In every configuration, the reasoning about your company happens against your structured record. The language model is a component used to read and write prose, not the thing that holds your knowledge.
Deployment option
Sensitive data does not leave in the clear.
Before any text reaches a general language model, it passes through a small model whose only job is to find personal and sensitive data and take it out.
The mapping between token and real value never leaves your perimeter. It is held by the symbolic core, and it is the symbolic core that puts the real values back when the answer returns.
Substitution is exact and deterministic. It is not a model guessing at what a placeholder meant. The answer you read is complete and correct. The model that helped write it never saw who it was about.
Two controls a regulator will ask about
The exchange is auditable. Every substitution is recorded: what was detected, what replaced it and what was put back. You can show precisely what left your perimeter, per request, rather than describing your intentions.
Fail-closed is available. Where a span is detected but cannot be classified confidently, the layer can withhold it rather than pass it. A withheld span costs a little fluency. A leaked one costs considerably more, and the choice belongs to you.
Architectural
The audit trail is the database.
Most systems can tell you what they currently believe. The question an auditor asks is what you believed in March, and who changed it.
It cannot be quietly edited.
Every entry is identified by its own content, and each entry commits to the one before it. Change a past document and its identity changes. Change its identity and every entry after it fails to verify. There is no edit that leaves the chain intact.
Deletion is visible. Removing something is itself an entry. The record does not silently shrink, and an absence has a cause you can name.
Verification does not need us. The chain is checkable with the copy you hold. Our cooperation is not a dependency, which is the only form of tamper-evidence worth having.
Every fact names what it rests on.
Where MAIA states something about your company, it can name the document and page it was read from, the person who typed it or the correction that overrode both. A value is never reported as though the company were certain of it when it is not.
Contested facts are shown as contested. Where sources disagree, the platform reports the disagreement rather than silently choosing a winner. A confident wrong answer costs more than a visible conflict.
Exportable evidence. History for a defined scope and period can be exported for an auditor and verified independently.
Deployment option
What our own staff can reach, and how to remove it.
Under a fully private deployment the answer is structural and needs no trust: there is no access path, no credential and no copy. This is the configuration we recommend to any client for whom vendor access is a material risk, and it is the honest end of this document.
-
No standing access
No engineer holds persistent credentials to a client instance. Access is requested, scoped, time-limited and expires without action.
-
Break-glass needs you
Access for support can be gated on an approval from your side, per incident, with a stated reason and duration.
-
Logged where you can see it
Operator access appears in the same tamper-evident history as everything else. A log the vendor can quietly edit is not evidence.
-
Your keys end the question
Under hold-your-own-key, an operator with full infrastructure access still cannot read your documents without a call your hardware logs and can refuse.
Architectural
Being able to leave is the control that gives every clause its force.
Your operational data is not an input to our product. Your documents, your records and everything MAIA derives from them are yours. They are not training data, they are not a corpus and they are not aggregated across clients.
The company brain is a self-contained artefact. Everything MAIA knows about your company is one exportable, verifiable object, not rows spread across systems that only we can reassemble.
Exit is a copy, not a project. You can take the whole record, with its full history and its integrity intact, and verify it without us. There is no extraction fee and no cooperation dependency, because there is nothing to extract.
Intellectual property in bespoke work transfers to you on payment in full. That is the standing position in MAIA BRAIN's Standard Terms of Business, version 4, and it is not a concession made per deal.
Nothing persists between tasks. The execution environment is rebuilt each time. Two tasks running at once cannot observe each other's state, and client instances are separate deployments rather than rows sharing a table.
Restoring is not a reconstruction project. A complete copy is a complete company brain: history, documents, rules and all. Integrity is checkable after a restore, so a silently corrupted one is detectable rather than discovered later.
Architectural
Data protection, and what to ask for in procurement.
Data minimisation by construction. MAIA reads your documents where they are and derives structured facts from them. It does not require you to copy your business into a second system in order to be useful.
Subject rights are answerable because the history is answerable. What is held, where it came from, when it arrived and what has been derived from it are retrievable rather than estimated. A subject access request is a query, not an investigation.
Records of processing fall out of the design. What was processed, when, by whom and under which authority is already written down in a form you can export.
No cookies and no tracking on anything MAIA BRAIN publishes.
Evidence for your reviewers
Every claim on this page is one of two things. Either it is a property of the architecture, which we will demonstrate on your own data in a technical session. The fastest way to test a security document is to make its author run it.
Or it is a deployment choice, which is written into the security schedule that binds us.
Certification status, third-party assessments and completed security questionnaires are supplied with that schedule. Ask for them by name in procurement and they are answered specifically, with dates.
A data processing agreement and subprocessor list are provided per engagement. Under a fully private deployment the subprocessor list is materially shorter, and it can be empty.
The next step
Send us your security questionnaire.
The one your procurement team already uses, unaltered. We will return it completed, with the security schedule for the configuration you are considering, and we will sit with your reviewers while they test it on your own data.