Foundation
Trust and compliance built in
Compliance work starts in stage 01, while the design can still change. By go-live you hold the evidence: the impact assessment, the oversight design, the logs and the test results.
What every project includes
- An impact assessment. Every engagement that touches personal data gets a DPIA, scoped in stage 01. revFADP Art. 22 requires one where processing is likely to carry a high risk to the people concerned.
- A hosting decision on record. Swiss or EU cloud, your own infrastructure, on premises or on the device. The model provider and region are agreed per engagement, and client data is never used to train models.
- Personal data kept out of models. Names and identifiers are replaced with aliases before a model call wherever the design allows, and an independent check fails the run if one leaks.
- Human oversight by design. Every agent has an autonomy rung chosen by your accountable executive, a human approval queue for anything irreversible and a stop control a named person can use. Where a decision about a person is taken solely by automated means, the revFADP Art. 21 review path is built before go-live.
- Logs that reconstruct a decision. Every step is logged with the documents used and the rule applied.
- Evidence an auditor can read. The evaluation set, results per release, change log, traces, signed persona cards and incident reports, kept per release. AI guardrails describes the pack.
In the six stages
| Stage | What you receive |
|---|---|
| 01 · Ground the case | A regulatory applicability note for the use case; the DPIA scoped; the hosting option chosen |
| 02 · Prove the value | An evaluation set that doubles as evidence; personal data aliased in the prototype where the design allows |
| 03 · Engineer the system | A governance pack: model documentation, access and data-handling controls, monitoring thresholds, human oversight design, audit trail; the Art. 21 review path built |
| 04 · Pilot in one place | A red-team session before users; every handoff and override logged; incident response tested with your team |
| 06 · Run and evolve | A regulatory watch: when a rule that touches the system changes, you hear what must change and by when |
The rules themselves
revFADP, the EU AI Act’s reach into Switzerland, GxP and sector rules, with dates and primary sources, are on the regulatory reference.
Built in the lab
| Build | Label | What it shows |
|---|---|---|
| kredis | Beta | Append-only case history and versioned policy packs, so any assessment can be reconstructed for a past date; no clearance without a recorded human approval |
| Wellsura | Beta | Reason codes from a fixed list; insurance status kept out of the ranking and enforced by a test; personal data deleted physically |
| Anonymise before inference | Internal build | Personal data replaced with aliases before any model call, with an independent check that fails the run |
| Allergen evaluation harness | Internal build | 117 adversarial cases and a 100% pass rate to merge, for the questions food law makes mandatory to answer correctly |
Used by
Questions
Is your regulatory note a legal opinion?
No. It is a screening note from people who work with revFADP, the EU AI Act and sector rules, written so your counsel can confirm the position for your system quickly.
How do you handle security on an engagement?
We can run the system inside your own infrastructure and controls. Our own sites deploy with narrow tokens, fail their build on any third-party resource load, and keep internal tools behind a login. The principles page lists the practices.
Do you train models on our data?
No. The model provider and the hosting region are agreed for each engagement, and we do not use client data to train or fine-tune models.
Related
Start with the applicability note
Every AI Opportunity Assessment includes a regulatory applicability note for your use case, written so your counsel can confirm it quickly.
See the AI Opportunity Assessment