AI guardrails
You already run AI, built in-house or bought. We put governance around it, check it against the EU AI Act and revFADP, test its security, and hand you evidence your auditor and your accountable executive can read.
What you get
- An inventory of the AI you run, with an accountable owner and a risk class for each system
- A screening against the EU AI Act, revFADP and your sector rules, written for your counsel to confirm
- An evaluation set built from your process and agreed with your experts
- Results across repeated runs, by risk class
- Security findings: prompt injection, tool misuse, data leakage, access and secrets
- A check of human oversight and logging against what an auditor needs
- An evidence pack, and a regression suite that gates every change in operation
Who it is for
You run an AI system that someone else built, or that your own team built quickly. It answers customers, reads documents or prepares decisions, and it works on the cases people have tried. Nobody can say who owns it, which rules apply to it or how it behaves on the cases that matter most, and an auditor, a regulator or your board is starting to ask.
What we do
- Map what you run. We list every AI system in use, built or bought, name an accountable owner for each and agree what it may be used for.
- Screen it against the rules. We check each system against the EU AI Act, including its reach into Switzerland, revFADP and the rules of your sector.
- Build the evaluation set. We collect cases from your process, including the ones that went wrong, and agree with your experts what a correct outcome is for each. The set is frozen and versioned before the first run.
- Run it, several times. Language models do not always give the same answer twice, so every case runs more than once. A system that fails a case on the third run has not passed it.
- Test its security. We add cases written to break the system, run a red-team session against it and check how it handles access and secrets.
- Check oversight and logging. We check where people approve, override or stop the system, and whether any single decision can be reconstructed from its logs.
- Hand over the evidence. You receive the results, the findings and the fixes we recommend, in a form an auditor can follow.
- Keep testing in operation. The set becomes a regression suite that runs on every change.
Governance
| What we set up | What it answers |
|---|---|
| AI inventory | Which systems run, who built them, and which data and models they use |
| Accountable owner | Who answers for each system and can stop it |
| Usage policy | What staff may use AI for, and with which data |
| Risk class | Which systems need the most scrutiny, and why |
Compliance
- EU AI Act. The Act reaches Swiss companies whose AI output is used in the EU. We screen each system for its risk class and the obligations that follow from it.
- revFADP. An impact assessment where processing is likely to carry a high risk (Art. 22), and a review path for decisions taken solely by automated means (Art. 21).
- Sector rules. GxP in pharma and life sciences, and the expectations of your sector’s supervisor.
The rules themselves, with dates and primary sources, are on the regulatory reference.
What a test case contains
| Part | What it holds | Invoice agent example |
|---|---|---|
| Task | The input, as the system will receive it | An invoice, its purchase order and its goods receipt |
| Expected outcome | What a correct result looks like, agreed with your experts | Flag the quantity mismatch; do not post; draft a query to the supplier |
| Grader | How the outcome is checked | Code checks the posting state; a model grader checks the query against a rubric |
| Class | Which risk the case covers | Partial delivery |
| Source | Where the case came from | A disputed invoice from last year, anonymised |
A good case would get the same verdict from two of your experts working independently. If they disagree, we rewrite the case before it enters the set. We grade the outcome: what the system did to your records and what it told a person. Two answers worded differently can both be correct, and a well-phrased answer can be wrong.
| Grader | Use it for | Limits |
|---|---|---|
| Code | Anything with a checkable answer: a posting state, a field value, a refusal, a tool that must not be called | Cannot judge tone, completeness or reasoning |
| Model | Open answers graded against a written rubric | Calibrated against human verdicts on a sample first, and rechecked when the grader model changes |
| Person | Cases where judgement is the point, and samples of the other two | Slow and expensive, so used where it changes the result |
Security
A set made only of ordinary cases measures the easy days. We add six classes of red-team case written to break the system:
- Euphemism. The risk is described indirectly, so a keyword check misses it.
- Social engineering. Pressure, urgency or false authority pushes toward a reassuring answer.
- Positive framing. The question invites the answer the user wants to hear.
- Instructions inside documents. An email or PDF contains text addressed to the agent, which it must treat as data.
- Tool misuse. A path that would lead the agent to call a tool it should not, or with arguments it should not use.
- Data leakage. Inputs designed to draw personal data into an output or a model call.
We also check who can reach the system and what it holds: keys and secrets kept out of prompts and logs, and each tool limited to what the agent needs.
The evidence pack
An auditor needs to reconstruct what the system did, why, and how you knew it was safe to run.
| Evidence | What it shows |
|---|---|
| Evaluation set, versioned | What the system was tested against, and who agreed the expected outcomes |
| Results per release | Pass rates by class across repeated runs, and the decision to release |
| Change log | Every change to models, prompts, retrieval and tools, linked to its evaluation run |
| Traces | For any single case: the inputs, the tool calls, the outputs and any human decision |
| Persona cards | What each agent was permitted to do, signed by the accountable owner |
| Human oversight design | Where people approve, override or stop the system, and how each action is logged |
| Incident reports | What went wrong, the cause and the case added to the set |
For GxP environments, the suite answers what validation teams ask about AI: what is monitored between validation events, what triggers a re-validation and what evidence is kept.
In operation
- Every change to a model, prompt, retrieval source or tool reruns the suite before release.
- When a model provider updates or retires a model, the replacement passes the suite before it handles live work.
- Live cases that went wrong, or that a person overrode, are reviewed and added as new cases.
- Drift is measured against the suite on a schedule, so a slow change in your documents or suppliers shows up as a number.
On a system we build, this work runs through stages 02 to 06 of the KARPINITY Method: the set is frozen in stage 02 (3-6 weeks), wired into the release pipeline in stage 03, red-teamed before users in stage 04, extended with cases from new sites in stage 05 and run every quarter in stage 06. On a system you already run, we scope the assessment as a fixed piece of work, priced on request.
Proof from the lab
| Build | Label | What it shows |
|---|---|---|
| An adversarial evaluation harness for allergen safety | Internal build | 117 adversarial cases for a hospitality AI product, with euphemism, social-engineering and positive-framing classes, run in CI as a merge gate that needs a 100% pass rate |
| Anonymise before inference | Internal build | Personal data replaced with aliases before any model call, with an independent check that fails the run if a real value leaks |
| kredis | Beta | An append-only case history and versioned policy packs, so an assessment can be reconstructed for any past date |
| Nauvo | In the App Store | A pure game engine with time and randomness injected, full branch coverage and property-based tests, held to the same discipline as our AI systems |
When an improvement in one place causes a regression in another, the harness blocks the change until the regression is fixed.
Built on
Questions
Is your compliance screening 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 each system quickly.
Is this a penetration test?
No. We test the AI layer: what the model can be made to say, which tools it can be pushed to call and what data it can be drawn into revealing. Network and infrastructure testing stays with your security team or a specialist firm, and we work alongside them.
Can you assess a system you did not build?
Yes. We need access to the system in a test environment, cases from your process, and an expert who can say what a correct outcome is. The method is the same one we apply to our own builds.
Do you use a language model to grade another language model?
Where the outcome cannot be checked by code, yes, and only after the model grader agrees with your experts on a sample of cases. Code checks come first, and a person grades what neither can judge reliably.
What pass rate do you require?
It depends on the cost of a wrong answer, and you set it with us before the first run. For our allergen harness the bar is 100%: one failing case blocks the release.
What happens to the evaluation afterwards?
It becomes the regression suite. Every change to a model, prompt, retrieval source or tool reruns it before release, and live cases that go wrong are added to it.
Is this the same as validation under GxP?
No. An evaluation set is evidence a validation can use, especially for what happens between validation events. Validation itself follows your quality system and the frameworks it applies, such as GAMP 5 and the ISPE GAMP AI Guide.
Next step
Start a project
Start a project: tell us which system you run, what it decides and who relies on it, and we reply with a scope, a duration and who we need from your side.
Start a project