Principles and trust

Forward this page to your security, legal and procurement colleagues. It covers how we build, where data goes and which rules we work to.

How we build

Four practices run through every engagement, each built into the system as a design rule.

Evaluation before build

In stage 02 we write the evaluation before the prototype and freeze it before reading the first result. You agree the pass threshold with your metric owner in advance, so nobody can argue a result into a success afterwards. Our internal build for allergen questions has a 117-case adversarial test set, wired into CI as a merge gate that needs a 100% pass rate. Read more on AI guardrails.

Human oversight, with a named rung

Your accountable executive, not our engineers, chooses each agent’s autonomy rung. Below the top rung, an uncertain agent stops and hands the decision to a person. When a system decides about a person solely by automated processing, revFADP Art. 21 gives that person the right to be informed and to a human review. We design that review path in from the start. See agentic AI engineering.

Least-privilege tools

An agent gets only the tools its role needs. In our invoice-handling prototype, five role-bounded agents each have their own toolset and context, and anything uncertain opens a decision request for a person. We write down each agent’s permissions before deployment, so revoking one means changing a document and a setting.

Anonymise before inference

Names, addresses and identifiers become stable aliases before any model sees the content. A second, independent check inspects everything about to cross the boundary. It fails the whole run if it finds an identifying value that should have been aliased. The aliases are reversed only at the end, locally, on infrastructure that never sent anything to the model. This is an internal build, and we use the pattern whenever a model does not need to know who a person is. See sovereign and on-device AI.

Data handling and hosting

Residency and sovereignty are two questions

Data residency is geography: which country holds the servers. Data sovereignty is control: which jurisdiction governs the data, who can compel access and who holds the keys. Data stored in Switzerland can still be reachable by a foreign authority, depending on who operates the infrastructure. We answer both questions in writing on every engagement.

Hosting options

The choice depends on how sensitive the data is and where you stand regulatorily.

• Swiss-hosted cloud. You need data residency in Switzerland, and standard cloud controls fit your risk profile.
• EU-hosted cloud. You do not need Swiss residency and your data protection assessment allows EU hosting. We document the transfer basis, and you get a wider choice of models and services.
• Customer-controlled infrastructure. The system runs inside infrastructure you already own.
• On-premise or on-device. The data should not leave your environment, or the device, at all.

We choose with you during stage 01, before any build decision.

Impact assessment by default

On every engagement that touches personal data, we run a data protection impact assessment scoped to your use case before the build. Changes it forces are cheaper before the system exists.

Model providers

Before client data reaches a model provider, the provider, region and contractual terms go into the engagement scope for your approval. We do not use client data to train or fine-tune models for anyone else.

This website

karpinity.com uses Cloudflare Web Analytics, which is cookieless. Google Analytics loads only after you press “Accept” in the cookie notice, and sets its cookies only then. Beyond that, the site processes personal data only when you send the contact form or join the Zeza waitlist. For those forms, two processors act for us under data processing agreements: Cloudflare (hosting, forms, bot check) and Resend (notification email). Both may process data outside Switzerland and the EEA, under standard contractual clauses. Full detail is in the privacy policy.

Security practice

Security on an engagement starts with your requirements. We can run inside your own infrastructure and controls, which often suits sensitive data best, so tell us what your procurement asks for in the first call.

The practices we apply on our own sites and tools:

• Narrow deploy tokens. Our production sites deploy with a token limited to one permission on one account, never a global key.
• Product sites fail their build if a third-party resource load appears in the output.
• Internal tools sit behind a login with an email allowlist.
• Forms are defended with a bot check, a hidden honeypot field and rate limiting.
• Our apps collect little. Kutio, our Mac archiver, has no accounts, no analytics and no network code. Zeza runs speech, writing help and voice on the phone.

Regulatory stance

Last reviewed 25 July 2026. We re-check before every engagement starts. This is not legal advice: your counsel decides where you stand.

revFADP. Switzerland’s revised Federal Act on Data Protection has been in force since 1 September 2023. On 8 May 2025 the FDPIC confirmed that it applies to AI systems that process personal data. We treat it as applying from the first day of any project that touches personal data, and plan the impact assessment (Art. 22) and breach handling (Art. 24) to match.

EU AI Act. The Act reaches Swiss companies through Art. 2(1)(c): it applies where an AI system’s output is used in the EU. Transparency duties and most enforcement structures apply from 2 August 2026. After the June 2026 Digital Omnibus, standalone high-risk systems (Annex III) apply from 2 December 2027, and high-risk AI embedded in regulated products (Annex I) from 2 August 2028. In stage 01 we screen your use case against these.

Switzerland has no horizontal AI law. Regulation goes sector by sector, so the relevant rule is usually the one that already governs the activity.

GxP. GAMP 5 (second edition, July 2022) predates adaptive AI. ISPE published a dedicated AI guide in July 2025. EU GMP Annex 22 on AI closed consultation on 7 October 2025 and was not yet adopted at our last review. We design pharma systems for validation from the start.

The detail is on the regulatory reference.

Report a problem

If you find a security problem, a data exposure or an error in our work, write to innovation [at] karpinity.com with “Security” in the subject line. Tell us what you found, where, and how to reproduce it. Please do not access data that is not yours or degrade the service while you test. We reply to every report in writing.

For privacy requests, use the same address and see the privacy policy.