Trust
Evidence, not promises. Everything you can check, on one page.
A vendor that handles personal data has to prove, not reassure. Here is everything a data protection officer, an auditor or an engineer can verify: the measurements with their method, the architecture, the legal texts, the checks that run on every release, and what we do not have yet.
Detection is not infallible and no page replaces your own assessment. Whatever you submit, you submit on your own responsibility and for lawful use.
What you can check today
Every claim with its evidence next to it
- Measured accuracy: Precision, recall and leak recall per category and detection level, from gold sets we do not tune on, and the negative set for false positives. The table is generated by the evaluation and checked in CI.
- The published method: What counts as a correct detection, why two recall figures are published together, how the sets are built, what is not measured and what is not published. Versioned, so a number cannot change its definition quietly.
- Security and architecture: What leaves for the model, what stays encrypted, what is never written. AES-256-GCM vault, HMAC search, 30-minute ephemeral files, hosting in Germany.
- Data processing agreement (DPA): The Article 28 terms an organisation accepts, with the sub-processor table and breach notification within 48 hours. The same text that is hashed on acceptance.
- Sub-processors: Which third party receives what: the model provider (masked text only), hosting, payments, email. A public list, with the place of processing.
- AI transparency notice: What in the product is artificial intelligence and what is not, which model, where it runs, and what that means under Article 50 of the AI Act.
- Vulnerability disclosure: Responsible disclosure with /.well-known/security.txt (RFC 9116). We answer every report and credit anyone who wishes.
- The team: The people behind the product, by name. The operator’s legal identity is provided on request, as the legal texts say.
Documents for your DPO
The policies, public
The two texts every vendor questionnaire asks for, written from what the code does rather than from a template. Data retention has its table in the privacy policy, so there is one text and not two that drift.
- Technical and organisational measures (Article 32): Encryption and keys, access, detection that refuses rather than leaks, supply chain, checks in development, backups, what does not exist yet.
- Incidents and breaches: How we classify an incident, what we do in the first hours, and when and how we notify customers, the authority and data subjects.
- Retention and deletion: The retention table per kind of data (vault 30 days, ephemeral files 30 minutes, logs, backups) in section 7 of the privacy policy.
On request
A DPIA template per deployment tier, a template record of processing (Article 30) for the use of AI tools through filterit, answers to a vendor questionnaire, and the operator’s legal identity. Write to contact@filterit.app.
How every release is checked
Automatic gates that do not loosen quietly
A change reaches production only through a pull request that needs an approval and only if it passes all of the below. Lowering a floor requires a recorded rationale.
Detection quality gate
The gold sets run in hermetic replay. At the deep level, one personal datum left uncovered in any category stops the release. The published table is compared with the fresh run: if it drifts, the release does not ship.
Negative set and snapshot
False positives on 660 documents without personal data have a ceiling. The byte-exact reference snapshot and the matrix of 52 national identifiers must stay identical or change deliberately.
Secrets and dependencies
Secret scanning on every push, vulnerability scanning of the Java and npm dependencies and the container images, automatic update proposals, and a lint of the compose files for ports, privileges and docker socket access.
Content policy and copy
The Content Security Policy check of the public pages, the readiness of the legal texts (no draft, no blank field, one copy of the DPA) and the wording rules (pseudonymisation, not anonymisation; no absolute guarantees).
The audit trail
What our record can prove, and what it cannot
A hash chain, free of personal data
Every send to an external model leaves one row: destination, size, SHA-256 digest and masked preview, linked to the previous row. A row that was changed or removed breaks the chain.
Evidence pack
An organisation exports a pack with the period’s statistics and the chain verification. In the hosted service it is sealed with a symmetric code (verifiable by the key holder), on the device with an Ed25519 signature (verifiable offline).
The limit, stated
The chain proves integrity and ordering, not absolute time: there is no trusted third-party timestamp on its head. Time claims rest on the operator’s clock. We say it before you ask.
To be precise
What we do not have yet
- No ISO 27001 or SOC 2 certification. The gap assessment is in the plan; certification is a project of months and we will say so when it exists.
- No completed external penetration test. One is planned; until then security rests on the automatic checks and on responsible disclosure.
- No named case studies yet. What we say about accuracy comes from our own sets, not from customer documents, and the method says so.
Want to check it on your own data?
A pilot on your own documents is the measurement that matters to you. For a DPA, a questionnaire or a call with your DPO, write to us.