Compex
Request a Pilot

Run approved AI workloads on data you are not allowed to move.Run approved AI workloads on data you are not allowed to move.

It runs next to the records, never on a copy, and exports a hashed account of what it did.

See the sandboxBook a technical walkthrough
READY
InstitutionInstitutionProtected Data
recordsscansclaims
AI / ITAI / ITProcessor
risk modelcohort queryscoring API
Legal BlockRaw data cannot move
CompexGoverned Execution
Insert to govern
Approved FlowGoverned access · Controlled execution
SetupRaw handoffLegal blockCompex addedGoverned runSafe output

Data access is where deployment stops.

AI teams need real data. Data owners have no way to check what happens to it.

Data

Sensitive records cannot be copied into every model, tool or vendor environment.

Legal

Review teams need clear policy, approval and audit evidence before work can start.

Proof

AI teams need a way to run inference that survives a vendor security review.

Compex creates a controlled path between data owners and AI teams.

Ownership, execution and approval stay separated.

Protected data

records · scans · claims

stays put

Policy and approval

Scope, fields and outputs, signed before anything runs.

Execution

The workload runs against the records, inside those limits.

Evidence

Every event hashed, in the order it happened.

job specapproved output

AI team

risk model · scoring API

reviews

DPO / Legal

Reviews scope before the run. Receives signed evidence after it.

One contract. One run. One file.

  1. 01 Pipeline Contract

    Both sides agree the scope in writing, and the reviewer signs it. Nothing executes until that version exists.

    Pipeline Contractv1 approved
    workload
    compex-analyze-duckdb
    field scope
    3 of 6 admitted
    output
    aggregates only
    purpose
    fraud model validation
    dataset
    synthetic-insurance-claims
    retention
    30 days
    reviewer
    named, signed

  2. 02 Governed runtime

    Ask for a field outside the contract and the job is refused mid-run, and the refusal logged.

    1. Pipeline Contract
      approved · v1
    2. Workload admitted
      compex-analyze-duckdb:2026.05.29-r7
    3. Executing in scope
      synthetic-insurance-claims · 100 rows
    4. Out of scope
      if raised: job stops, refusal enters the chain
    5. Evidence sealed
      sha256 526183fa…f59b21

    Refusal is what the runtime does with an out-of-scope operation. The captured sandbox run completed without one.

  3. 03 Evidence bundle

    Everything the run touched, in one file, checkable against the contract that authorised it.

    evidence.json142 KB

    sha256 526183fa…f59b21

    summary.pdf88 KB

    sha256 2c90f220…b1586d

    audit.csv11 KB

    sha256 8a6ac4e1…a000eab

    Evidence bundlesealed

What a reviewer can check without asking us

Generated at execution time and hashed as it goes.

  1. 01Datasetconfigured
  2. 02Policyconfigured
  3. 03Approvalapproved
  4. 04Executioncompleted
  5. 05Evidenceready
Five stages, each naming its owner. The four that change state are hashed into the chain; the bundle is what they produce.

Who signed what

  • dataset
  • policy
  • approval
  • execution

Every stage names who signed it.

first hash

3530a8a90042108515722e83778f8af0d07f3c96f41489817fe66c299c56eabb

last hash

c35620aeaebae1fdb2479cff13413b4e941f3a0496a5c6384ea4deae067d1ce2

events
4
valid
4
problems
0

The chain, as recorded

  • first hash
  • last hash
  • 0 problems

First hash, last hash, event count. An empty problems array.

evidence.jsonmatch
stored

526183fab2767c8360df9670d0e57334138c0f0849c6f4da77f7d8bf30f59b21

computed

526183fab2767c8360df9670d0e57334138c0f0849c6f4da77f7d8bf30f59b21

summary.pdfmatch
stored

2c90f220d5ca7dcc7ea63fe54a597c4ba67811444fef119375a04a33c4b1586d

computed

2c90f220d5ca7dcc7ea63fe54a597c4ba67811444fef119375a04a33c4b1586d

audit.csvmatch
stored

8a6ac4e1fcb3b9947045e2d8cbbf37cc4c6c287cc9f4605f86254d3c0a000eab

computed

8a6ac4e1fcb3b9947045e2d8cbbf37cc4c6c287cc9f4605f86254d3c0a000eab

Stored against computed

  • sha256
  • per file
  • match

Both hashes in full. Compare them yourself.

Look at a real evidence bundle before you talk to us

Train, Analyze and Serve run under the same governed path. Below is an Analyze job end to end: EU-hosted, synthetic insurance data, isolated tenant. A reviewer approves the scope, the job runs, and the bundle verifies against its own hashes.

Open the sandbox
app.getcompex.com/try

The same run answers to everyone.

AI providers

What do I hand the client's lawyer?

Your model runs against the real data under an approved contract. You receive results and an evidence bundle you can forward to the client's legal team.

Data owners

Can I prove the rows never left?

The records never move. You approve the scope, name the reviewer, and hold a hashed account of every operation inside the run.

DPOs and legal reviewers

Who am I taking at their word?

You read the signed scope and check the hashes yourself.

The same governed path, whatever the field names are

  • GDPR Art. 9
  • Special-category fields

Insurance and Insuretech

Diagnoses, addresses, payout history. Every field is classified in the contract before a workload sees any of it.

1 / 4

Built for European regulation

Where the runtime carries the burden, and where it stays with you.

GDPR

Binds purpose, field and output policy to the run, and records who approved it.

Your duty

Lawful basis, role allocation, transparency, data-subject rights and DPIA conclusions.

DORA

Logs runtime access and deployment, and timestamps every incident.

Your duty

Accountability, regulatory reporting and resilience testing.

EU AI Act

Gates execution behind approval and logs what ran, for high-risk system duties.

Your duty

System classification, conformity assessment, registration and provider/deployer duties.

NIS2

Hashes each execution event and lists the workflows affected.

Your duty

Scope determination, risk governance and statutory notification.

An audit-ready runtime by design.You keep control of your obligations.

Four stages from blocked deal to signed evidence

Bring one that is already stuck. You end up with results, and a file their lawyer can check.

  1. 01AI provider and data owner

    Scope

    One use case, one dataset, the fields you need. That becomes the draft contract.

  2. 02Data owner and DPO

    Approve

    The reviewer reads the scope and approves a version.

  3. 03AI provider

    Run

    Your workload runs.

  4. 04Both parties and legal

    Review

    The bundle is exported and the hashes checked.

Questions we get asked

No. It runs next to the data under the contract's field and output limits. The provider gets the permitted outputs and the bundle. The raw records never move.

The Pipeline Contract declares permitted operations, field scope and output restrictions before execution. The runtime enforces them. An out-of-scope operation is refused while the job is running, and the refusal is written into the evidence bundle as a blocked action.

Each event and each export file is hashed independently. Checksum verification compares stored values against computed ones, and the bundle exports as JSON, PDF and CSV for your reviewer to work with directly.

Production depends on your architecture and residency rules. Tell us your setup and we will go through the options with your infrastructure and security teams.

No. That is your assessment to make. We give you what it needs: the signed contract, the runtime, and the run record.

Duration and retention are fields in the Pipeline Contract, agreed before execution. Output restrictions limit what may leave, and the bundle records what was produced and what was blocked.

The deal is stuck on evidence.

Bring us the one that has been with legal since spring. We will show you the file their reviewer gets.

Request a pilotSee the sandbox