Hey, I’m building automation solutions (mostly using n8n) for clinics.
During the first 1–2 months we won’t officially be registered as a business yet, but we still want to start onboarding a few clinics as early adopters.
Here’s the challenge:
Since clinics work with sensitive medical-related data, I don’t want to store or process any databases under my personal name before the business is registered both for privacy reasons and for compliance reasons.
I considered letting each clinic own the infrastructure (e.g., n8n account under the clinic’s name, their own database, and we just connect and configure automations).
That solves the “data ownership” issue, but raises new questions:
If the n8n account is registered to the clinic but we have access to build the workflows — is that still considered safe for separation of responsibility?
If the database is hosted under the clinic’s account but we connect via API/credentials — is that an acceptable model from a privacy/regulatory standpoint?
Is there a recommended architecture for agencies/consultants who build automation for medical or semi-medical businesses, where the client fully owns the data layer?
Would it make more sense to wait and set up shared infrastructure only after the business is formally created?
If it’s under their name, they could steal my automations and my intellectual property. What can I do about it.
I’m looking for guidance on:
The safest architecture for “client-owned data but contractor-built automations.”
Whether this separation is common/best-practice.
Any pitfalls I should be aware of when accessing client-owned cloud services (n8n, DBs, API keys, etc).
Thanks in advance any experience or suggestions are welcome.
Hey @Stav_Aloni
Really interesting topic. This isn’t professional/legal advice, just thinking out loud so take with a huge grain of salt.
”If the n8n account is registered to the clinic but we have access to build the workflows — is that still considered safe for separation of responsibility?”
Security and compliance should always a shared responsibility. You still have to do your part in security practices (encryption, device monitoring, keys), data protection (making sure not storing copies of the data or causing any leaks, access management and training) etc. IF there is a data/security breach relating to the work done, I wouldn’t assume you’d be totally off the hook. If your clients are going to store sensitive data on n8n servers, you may just want to double check if the service is compatible with the type of data Security
”If the database is hosted under the clinic’s account but we connect via API/credentials — is that an acceptable model from a privacy/regulatory standpoint?”
This is really a question your client’s compliance department/person should be answering. If they’re okay with the arrangement, done their due diligence and it falls within their risk parameters, I don’t see why it wouldn’t be acceptable. Definitely make sure they understand what they’re getting themselves in for and get something in writing beforehand!
”Would it make more sense to wait and set up shared infrastructure only after the business is formally created?”
If it’s all going under your client’s organisation then probably not.
”If it’s under their name, they could steal my automations and my intellectual property. What can I do about it.”
(Not legal advice) Contracts! As long as your make sure it’s in writing what is theirs and what remains yours before any work begins then that will offer some protection. Totally understand where you’re coming from though - working with n8n means you are delivering the source code along with the end product and you’ll have to make your peace with that. In my experience, most clients will want to exclusive IP to the work they pay you to build though so if that’s not agreeable, you may need to sell them a product service instead.