Data protection and privacy
Handling other people's data is a duty, not a detail. In the EU this is also the law. Treat privacy as a design constraint from the first sketch.
This is engineering guidance, not legal advice. For anything consequential, confirm with a qualified Austrian/EU data-protection advisor.
Collect less
The safest data is the data you never hold. For each field ask: do we need this to deliver the outcome? Prefer references over copies, and delete what you no longer need. Data minimisation is both a legal principle and a smaller attack surface.
Have a lawful basis and be transparent
Know why you are allowed to process each category of data (contract, legitimate interest, consent) and tell people plainly what happens to it. Consent must be real and revocable, not buried.
Keep a clear boundary around AI processing
- Be explicit about what is sent to which model or service, and where it runs.
- Avoid sending personal or confidential data to third-party models unless the customer has agreed and a data-processing agreement is in place.
- For sensitive customers, a private or on-prem deployment (for example on OpenShift AI) can be the difference between a "no" and a "yes".
Protect it in transit and at rest
Encryption, least-privilege access, and separation between customers are table stakes. Log access to personal data.
Respect data-subject rights
People can ask what you hold, ask for corrections, and ask for deletion. Design so you can actually honour those requests without heroics.
Make privacy a feature
For diaspora customers, clinics, municipalities and enterprises, "your data stays in the EU / on your infrastructure, and never trains a public model" is a competitive advantage. Say it clearly and mean it.