API Providers

Red Ink is software that requires access to a large language model (LLM) through an API (Application Programming Interface) to function. An API is a machine-to-machine interface that allows Red Ink to communicate directly with an LLM, which can be installed locally, on your network, or, most commonly, accessed via the Internet. If you do not run your own LLM, you will need a service provider that offers API access to your desired LLM.

You need either a Cloud API provider, a local API provider – or you get a self-hosted model

Today, cloud providers like OpenAI, Microsoft, and Google, as well as local providers, offer such services. While cloud providers typically offer the most advanced models, local providers often use open-source models. These may be slightly less powerful but can be a better option regarding data protection and support. Each user must make their own choice.

Commercial providers usually charge for API usage based on consumption (“pay-as-you-go”). This model is very inexpensive – often significantly cheaper than per-user monthly subscriptions – making it an attractive solution for businesses, especially those with multiple users.

Using API access generally allows for much better data protection, as providers offer commercial contracts that are unavailable for consumer services. For example, our law firm has a special contract with Google for its Cloud Platform, enabling us to use Red Ink with all data, including information subject to professional secrecy. This was not possible with conventional AI services.

Requirements for using Red Ink under (Swiss) Professional and Official Secrecy

To use Red Ink with information subject to (Swiss) professional or official secrecy, you must either operate the AI model yourself (on-premise) or use a provider that meets specific technical and organisational requirements. Besides adequate information security, the provider must contractually agree to process your data – including all secret information, not just personal data – only for your purposes and under your instruction. You must also have no reason to believe that a foreign authority could access your data (so–called foreign lawful access).

Foreign lawful access is a particular concern with non-Swiss providers, such as US tech companies like Microsoft, Google, OpenAI, Anthropic, or Perplexity. Many fear that the US CLOUD Act grants US authorities unlimited access to data processed by these providers. While this is clearly wrong and the public discussion is often emotional and lacks a factual basis, you must carefully evaluate the risk of foreign lawful access. This risk is not limited to the US but extends to other countries, including those in Europe. David Rosenthal has developed a widely adopted standard method to evaluate this risk, which is described in more detail here, and an Excel tool for this analysis can be downloaded here (it is free).

In practice, you can mitigate the risk of foreign lawful access to an acceptable level by implementing several measures. These measures restrict the legal and practical ability of foreign authorities to access your data, even when using a foreign provider with AI models running in data centres abroad, which is standard for cloud-based services. The following measures are typically recommended for using cloud-based AI services under (Swiss) professional and official secrecy, in addition to a standard provider agreement:

• Data Processing Agreement (DPA): This is a standard and basic requirement under both the Swiss Data Protection Act and the EU/UK GDPR. It also serves to contractually ensure that the provider and its own subcontractors are operating only under the instruction of the customer, which is partially seens as a requirement from a professional and official secrecy point of view.
• Additional contractual clauses for secrets: These should include a commitment to keep all customer data secret, binding the provider and all subcontractors, not just their employees. A clause merely requiring security measures is It should also include a “defend-your-data” clause, obliging the provider to challenge every lawful access request through all available legal channels, even if not permitted to inform you. The secrecy obligation must extend beyond the contract term as required by law, and the DPA’s provisions should cover all customer data, not only personal data.
• Zero data retention: A clause ensuring the provider does not store any AI model input or output, meaning no customer data remains on its systems after a query. This is usually linked to an “abuse monitoring” opt-out.
• No use for provider purposes: An undertaking that the provider will not use customer data (AI input and output) for its own purposes, such as model training or human abuse monitoring. This option is often only available to certain customers through a special application process. If an abuse monitoring opt-out is granted, the provider’s operators will not review customer data, even if an automated system flags it as potentially abusive. In our view, professional and official secrecy does not prohibit a provider from using automated systems to filter or block usage it deems abusive.
• No operator access without approval: An undertaking that the provider’s operators will not access customer data without your approval. This often requires a separate application or configuration (e.g., “Customer Lockbox” in the Microsoft environment). The contractual promise is usually enforced technically by the provider, but this differs from provider to provider.
• Data residency: If customer data is stored, the provider should commit to storing it in the agreed or configured geographical region (e.g., Switzerland). However, accessing the latest AI models on Swiss-based data centres is often not possible with cloud providers, requiring customers to send AI requests to a model hosted elsewhere in Europe, which can be configured. Some providers also undertake to protect access to customer data from outside the EEA/Switzerland, such as Microsoft (“EU Data Boundary”), meaning that there is in principle no direct data access from outside that region.
• Verified information security: An undertaking to maintain appropriate, verified information security measures, confirmed by audit reports like SOC 2 Type 2.
• Customer configuration responsibility: Providers, especially cloud providers like Google and Microsoft, offer extensive configuration options. It is therefore largely the customer’s responsibility to correctly configure the AI services. This includes selecting desired geographical locations (which are usually not set in the contract), using only services that offer the necessary protections, blocking operator access, deactivating automatic Internet searches if problematic, and turning off
• Liability limitation: While there is no requirement that liability must be unlimited for professional or official secrecy breaches, a provider should bear sufficient liability risk to ensure that a provider has sufficient incentive to comply with a contract. Typically, contracts provider for liability caps (sometimes supercaps) and exclude indirect damages, but provide no limitation for gross negligence or intent (which is also what Swiss mandatory contract law provides for). 

Every organisation bound by a professional or official secrecy obligation must on its own assess these measures and conclude that they meet the legal requirements for entrusting protected data to a provider. This includes conducting an assessment of foreign lawful access risks when using providers or data resources outside your own country, for instance, by using the David Rosenthal method. Such assessments typically involve clarifying the legal standards for lawful access in the relevant countries to determine whether the implemented measures will sufficiently protect the data against access attempts.

If you implement all these measures, we believe you can legally use cloud-based AI offerings under (Swiss) professional and official secrecy, which we consider is the currently established view. This is also the view of the Swiss Banking Association (see Cloud Guidelines) or the Swiss Bar Association (see Art. 38 of the Swiss Code of Professional Conduct). However, we provide no confirmation or assurance, and some hold a different view. For them, we recommend using Red Ink with a Swiss-based provider or an on-premise solution. Offerings for these alternatives are listed below. Red Ink is compatible with all of them, although which features can be used and how well they perform ultimately depends on the specific model and the AI server’s performance.

One further note of caution: Some of the models are able to do their own Internet search, in which case special rules can apply for the search terms passed to the Internet search engines (even if from the same provider). The use of this feature (aka search grounding) may not be advisable with professional secrecy data because the protections may not apply to them, depending on the provider. Similar issues may arise if you use models that call “tools”, including third party API and MCP services, in which case the model may pass along to these third parties data you have provided to the model, thus breaching confidentiality if no measures are taken. Red Ink supports such “tool” calls, as well, if you configure alternate models (which means that the users have to actively switch, reducing the risk that they unintentionally end up with the wrong model).

How to get the special contract amendments for users subject to professional and offical secrecy 

To make AI accessible to business users with professional and official secrecy obligations (e.g., attorneys, healthcare professionals, auditors, public authorities), we have negotiated corresponding contract addenda with Google and other providers. These are now available to relevant companies in Switzerland and, in some cases, Germany. We have expanded our model contract addendum for cloud providers to include a contract addendum for AI services (currently available in German here) and have convinced several Swiss providers to offer their services with this addendum.

The following table provides an overview of various cloud offers and – for those who prefer not to use the cloud – local providers whose AI services can be used with Red Ink. Last but not least, it also contains information on companies that offer self-hosted solutions. Please note that these offers are not from us. We provide no warranties for them or for the accuracy of the following information, and we receive no commission if you obtain API access from one of these providers. Everyone must evaluate for themselves which provider is the right fit.