Security and Data Protection

Automation moves your data around by definition. It reads from your systems, transforms information, calls services and writes results back. So the honest way to talk about security is to say where the data goes at each of those moments, what is stripped from it before it travels, and what remains verifiable afterwards.

This page states the positions transtorm.ai actually applies. It covers where data physically lives, what happens before anything reaches an external model, how access and secrets are handled, what gets logged, our GDPR posture, and who owns the code at the end. Our method page describes the project sequence these positions sit inside.

Local processing comes first

We favour local data processing wherever it is possible. Many of the operations a business automation performs, such as reading a file, checking a condition, reconciling two sources, generating a document or triggering a notification, need no external service at all. When those steps stay local, there is no transfer to secure, no subprocessor to audit and no retention question to answer.

That preference is a design constraint, not a marketing line. It changes which architecture we propose, and it sometimes rules out a service that would have been convenient.

What reaches an external model, and what never does

When an external resource is genuinely required, the data sent to it has been fully anonymised beforehand. No sensitive data is sent to those services.

The anonymisation happens inside the flow, before the call is made, and it is part of how the connector is designed rather than a filter bolted on at the end. The consequence matters in practice: what the external model sees is a stripped payload, and the identifying information stays on your side of the boundary.

None of that data is used to train a model. We train no artificial-intelligence model, neither on the data in your systems nor on the data this website collects, and our privacy policy states it for the latter.

Some of our systems take the argument to its conclusion and use no language model at all. Our field audit application computes its eleven derived fields with a deterministic engine, depends on no model and asks for no API key, precisely so that we can show a client where every figure comes from.

Self-hosting, when the data should not leave the building

For clients who need it, the whole system can run on their own infrastructure.

Our patient check-in kiosk is self-hosted on the practice’s own machines, containerised with Docker, and no data is sent to an external cloud. Its mobile companion is secured by physical presence rather than by an account or a shareable link: the QR code on the waiting room screen carries a daily token computed from a secret and the date, so it can only be obtained by standing in front of the physical screen. Our electronic signature workflow runs on Documenso, an open source platform that we host ourselves for the public demo, and the same setup installs on the clinic’s own premises, where the signed documents then stay.

Self-hosting is not free of consequences. It moves the operational burden, meaning backups, updates and availability, onto the client. We say so during the audit rather than afterwards, and the trade-off is decided with the facts on the table.

Least privilege, secrets, and environment separation

Each micro-process holds only the access rights its own execution requires, which limits the blast radius if any single component is compromised. Credentials are encrypted, rotated, and never shared between environments. Development, staging and production stay strictly isolated from each other, so that a test can never reach real data or a real recipient.

Splitting a process into short micro-processes helps here as well. A step whose only job is to generate a document has no reason to hold the credentials of the messaging system, and it does not.

Everything important is logged

An automated system that cannot be audited is a black box, and a black box in production always ends up being expensive. So every action is logged with its timestamp, its context and its result.

That log answers the questions an incident actually raises. What happened, which decision was taken, why did the flow stop, which step failed, can it be restarted without creating a duplicate, and who needs to be alerted. It also serves compliance, because an auditor asking for evidence of a control receives a record that was written at the time rather than reconstructed afterwards. Our banking control use case exists largely because the client’s auditors demanded proofs that manual work made hard to rebuild.

Human validation on sensitive actions

Traceability tells you what happened. Human validation decides whether it should happen at all.

Manual validation is optional, and it is switched on where the business rules call for it. For actions with a significant business, financial or operational impact, the system asks before it acts. That takes the form of a confirmation before a sensitive action, an approval before something is sent or run, an automatic block when a case is ambiguous, an alert when a critical threshold or rule is crossed, and a log entry for every important decision. Notifications are instant and a timeout fires automatically, so a pending validation never silently stalls a queue.

Our GDPR posture

Hosting is in Europe. A data processing agreement is signed with every subprocessor, including AI model providers, and the list of subprocessors is given to you before any deployment rather than discovered later. The GDPR position of your specific case is examined during the audit, which is the moment when changing the architecture is still cheap.

transtorm.ai is the controller for the personal data collected through this website. For the client data handled inside the projects it delivers, the role each side plays under the GDPR is fixed in writing in the project contract, before anything is built. Where a provider sits outside the EU or EEA, we apply appropriate safeguards such as the European Commission Standard Contractual Clauses together with suitable technical and organisational measures. Personal data is kept no longer than necessary and is then deleted or anonymised, with technical logs kept for a limited period proportionate to security and operations.

You hold the usual rights of access, rectification, erasure, restriction, objection and portability, and where a processing operation rests on your consent you can withdraw it. You exercise those rights by writing to info@transtorm.ai. You can also lodge a complaint with a competent supervisory authority, including the Estonian Andmekaitse Inspektsioon. The full text sits in our privacy policy.

This website itself

The site is published by transtorm.ai , registered in Estonia under registry code 17443658, at Harju maakond, Tallinn, Kesklinna linnaosa, Pärnu mnt 388b, 10131. It is hosted by OVH SAS, 2 rue Kellermann, 59100 Roubaix, France. The legal notice carries the complete publication details.

We collect identity and contact details when you write to us, technical data such as the IP address, device type and browser, and usage data about the pages visited. We do not seek to collect sensitive personal data, including health data, through this website. This site sets one category of cookie of its own, the audience measurement described in our privacy policy, and it loads only after you accept it in the consent banner. The same policy names the third parties this site calls and explains how to block them from your browser.

You own what we build for you

The bespoke work, meaning the code and the workflows built for you, belongs to you as soon as it is paid for, and section 7 of our general terms says so whether or not the quote repeats it. Two things stay outside that transfer. The third-party tools keep the licences of their own vendors, and the reusable components we owned before your project or built independently of it stay ours, licensed to you for as long as you run the system. Both are named to you before anything is built.

Maintenance is not compulsory. It can be cancelled with one month’s notice, the system keeps running without us, and we provide documentation precise enough for another provider to take it over. Ownership and reversibility are what make the rest of this page verifiable rather than merely promised: a system you own is a system you can inspect, move or shut down.

Ask us the awkward question

If a specific requirement applies to your sector, your auditors or your data protection officer, ask before the project starts. The audit is the right moment to answer it, and a clear no is more useful than a vague yes.