Every AI pilot in a regulated company eventually meets a data protection impact assessment, and most stall there, because the pipeline sends customer documents to a chain of vendors nobody mapped. The fix is not to avoid the tools; it is to know exactly where each byte goes and to keep the parts you control in one place. This post follows a compliance lead approving a Flowise pilot on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, in the Frankfurt region.
The company is an insurance claims processor we will call Halberd Claims, whose operations team wants to use Flowise to build a claims-triage assistant that reads uploaded claim documents. The options are Flowise Cloud, the vendor's hosted service, or the self-hosted Flowise package on the company's own PaaS environment.
Mapping the data flows first
The compliance lead's first document is not a policy but a diagram of where data goes in a Flowise application. There are five kinds of data: the flows themselves (the diagrams, which encode business logic), the credentials for model APIs and internal systems, uploaded documents and their embeddings, chat history including prompts and answers, and the model calls, which by definition leave for whichever model provider is used. The first four are Flowise's data and live wherever Flowise runs. The fifth is a separate decision about the model.
| Data | Flowise Cloud | Self-hosted on PaaS, Frankfurt |
|---|---|---|
| Flows and business logic | Vendor's infrastructure | Company's environment, Frankfurt |
| API credentials for models and internal systems | Vendor's encrypted store | Company's database node, encrypted at rest, TLS in transit |
| Uploaded claim documents and embeddings | Vendor's storage and vector store | Company's persistent storage and PostgreSQL node |
| Chat history, prompts, answers | Vendor's database | Company's database node |
| Model inference | Model provider chosen in the flow | Model provider chosen in the flow, or a self-hosted model |
| Processor agreements needed | Vendor plus model provider | Hosting provider (GDPR DPA, ISO 9001) plus model provider |
The table made the decision for the first four rows. Self-hosting removes an entire processor from the DPIA and puts the documents in a named German data centre under a data processing agreement the company already had with its hosting provider.
What the platform provides for the DPIA's control section
- Region. The environment is created in Frankfurt; the region is fixed for the environment and visible in the dashboard. Migration to another region is a deliberate action, not something that happens.
- Isolation. Flowise and its PostgreSQL node sit in an environment group with network isolation, so no other environment on the account can reach them over the internal network. The container firewall exposes only 443 on the Flowise node; the database accepts connections only from within the group.
- Encryption in transit. Let's Encrypt on the Flowise domain; the PostgreSQL SSL/TLS add-on between Flowise and its database, with SCRAM authentication.
- Access control. Platform access via collaboration roles: the operations team can deploy and restart, the compliance lead can view, only two people can change topology. Flowise's own login is separate and audited.
- Backups and retention. The Database Backup/Restore add-on with a retention matched to the claims retention policy, to a backup storage node in the same region. Uploaded documents on persistent storage with snapshots. Deletion on request is a database delete and a file delete, both under the company's control.
- Logging. Flowise's chat logs and the platform's audit of dashboard actions are both available to the DPO; nothing about a claim leaves the environment except the model call.
The model call, handled honestly
The fifth row cannot be self-hosted away by the platform alone: if the flow calls a hosted model, the prompt with the claim's contents goes to that provider. Halberd handled it in two stages. For the pilot, the flow uses a model provider with an EU processing option and a signed processor agreement, with Flowise's prompt template redacting names and policy numbers before the call, a step the compliance lead insisted appear in the flow diagram itself so it is auditable. For production, the plan is a self-hosted open-weight model on a GPU dedicated server in the same provider's Frankfurt facility, reached through Flowise's Ollama or OpenAI-compatible node, which closes the last row of the table.
What Flowise Cloud would have offered, fairly
The vendor's hosted service is the fastest route to a working flow, has no infrastructure to manage, and is updated continuously. For a team without the platform to hand, or a use case with no personal data, it is the reasonable default. Halberd's use case is the opposite: the documents are the most sensitive thing the company holds. The compliance lead's note records that the decision was about data, not about the product.
Cost, as the DPIA's least interesting line
Flowise on the platform is a Node.js container and a PostgreSQL container, each scaling in cloudlets (128 MiB of RAM plus 400 MHz of CPU) by the hour. For a pilot with a dozen users they average under 10 cloudlets together, on the order of $25 a month at MassiveGRID's published $0.003372 per cloudlet-hour before discounts. The hosted service's subscription tiers would have cost more at the team's size and would still have required the same model-provider agreement. Cost did not decide anything; it simply removed the last objection.
Frequently Asked Questions
Does self-hosting Flowise mean the model provider never sees personal data?
No. Whatever the flow sends to a hosted model leaves your environment. Self-hosting keeps flows, credentials, documents, embeddings and chat history under your control; the model call is a separate decision. Redact in the prompt template, choose a provider with an EU processing option, or run a self-hosted model to close that gap.
Can we prove to an auditor where the data is?
The environment's region is shown in the dashboard and in the platform's API, the hosting provider's data centre locations and certifications are published, and the environment's export function produces a complete copy for inspection. Together with the DPA and the flow diagram, that is the evidence set most auditors ask for.
How are Flowise credentials stored?
Flowise encrypts stored credentials with a secret key you set in its configuration. On the platform that key is an environment variable on the Flowise node, and the encrypted credentials live in Flowise's database, which on this setup is the company's own PostgreSQL node in Frankfurt.
Build the AI pilot the DPIA can approve
Self-host Flowise on MassiveGRID PaaS in Frankfurt, with network isolation, TLS, backups and collaboration roles from the dashboard, under a GDPR data processing agreement with an ISO 9001-certified provider. Free 14-day trial.
Flowise on MassiveGRID PaaS