/ rules for the business

What the rules stop, and what judgement keeps off a cloud API

Two lists, and they are not the same list. The first is what you cannot lawfully send to a cloud API. The second is what is permitted but unwise. Each entry names the rule it comes from, so you can check it rather than take our word for it.

1 · rules

You cannot use a cloud API for this

Personal data with no lawful basis. GDPR: putting a name, salary, case number or other identifiable detail in a prompt is processing, and without a lawful basis you cannot do it. ^[1]
Sensitive personal data without a valid exception. GDPR: health, biometric, ethnicity, politics, religion, sexuality and union data are generally off-limits unless a specific exception applies. ^[2]
Patient information without consent or another legal permission. Danish health secrecy rules: a clinician cannot disclose it to an API provider just because the tool is useful. ^[3]
A lawyer's client material in an API you have not proved confidential. Danish Bar rules: every client detail must be protected from reaching others, including material already public. ^[4]
Client personal data when your agreement does not authorise the API provider. GDPR and the client's processor contract: you cannot add a new processor or sub-processor without the required written authorisation. ^[5]
Personal data sent outside the EEA without a valid transfer mechanism. GDPR: a non-EEA API needs an adequacy basis or appropriate safeguards as well as an ordinary lawful basis. ^[6]
A hiring, credit or other major decision made only by the model. GDPR: fully automated decisions with legal or similarly significant effects are generally barred unless a narrow exception and safeguards apply. ^[7]
Emotion recognition at work or in education. EU AI Act: using AI to infer emotions there is banned, except for medical or safety reasons. ^[8]

2 · judgement

You would not want to use a cloud API for this

NDAs, tenders, price lists, drawings and unpublished work. It may be legal under the provider contract, but one leak can erase the secrecy that gives the material value. ^[1]
A service whose terms let it train on your inputs. If training is only an opt-out, your client's material should not be the default contribution to someone else's model. ^[2]
Case files where provider retention is already too much. Standard API controls can keep prompts and responses in logs; zero-retention access may need approval or exclude features. ^[3]
Work you would hate to name in the client's processor list. If explaining the recipient and the transfer would lose the client's trust, do not make that API part of the workflow. ^[4]
High-volume routine work. Cloud APIs meter input and output tokens every time; a workload that runs all day can make the recurring bill the bigger cost. ^[5]
A service that must answer when the provider is down. Provider incidents become your incidents; the provider's status history is part of your own availability record. ^[6]
A bid whose buyer asks for on-premise or a named data region. Cloud may be legal, but the buyer's procurement and security check can reject it before the work starts. ^[7]
A workflow you may need to move or keep running for years. Cloud contracts now have switching duties because lock-in is real; owning the model removes the provider exit project. ^[8]

Everything in the first list is a rule. Everything in the second is a judgement, and it is yours to make. Not every business needs its own machine — they are not cheap, and we will not pretend otherwise. But if your work keeps landing in the second list, the sooner you move it in-house the better: we set it up for you, we show your team how to use it, and from then on no third party holds the prompt.