--- title: "Your own assistants, interchangeable models: what an AI platform is for" lang: en type: blog canonical: https://www.arocom.de/en/blog/one-contract-instead-of-four alternate: https://www.arocom.de/blog/ein-vertragspartner-statt-vier author: "Axel Roth" published: 2026-08-07 last_updated: 2026-09-09 --- # Your own assistants, interchangeable models: what an AI platform is for An organisation acquires an AI platform for two reasons: departments can build their own assistants on it, and work carries on when one model provider goes down. One contract instead of four is an administrative argument that does not justify a purchase on its own. What it is worth all the same is what this piece works through. A platform takes maintenance effort off you; the responsibility stays where it is. Your organisation remains the controller under the GDPR, the number of subprocessors does not fall, and bundling has nothing to do with data sovereignty. The saving is real all the same: one data processing agreement you check once against the list in Article 28(3) GDPR, one subprocessor list instead of four, one offboarding step instead of four, a model switch with no new contract. Under the EU AI Act the role decides: with someone else's platform you are a deployer under Article 3(4), and the obligation that hits everyone is Article 4 on AI literacy, in force since 2 February 2025 and in a loosened version since July 2026. ## Your own assistants, interchangeable models: what an AI platform is for An AI platform gets acquired for two reasons. Departments build their own assistants on it, ones that take on a whole task: read a document, pull out the details, file a draft, report back. And work carries on when one of the model providers goes down, throttles or raises its price. That is what the [service page](https://www.arocom.de/en/services/langdock) is about. This piece takes on the part that comes afterwards, the one somebody has to maintain for years: the contracts. One contract instead of four is an administrative argument that does not justify a purchase on its own. It can still be quantified, and at one point it turns into an operational argument. The starting position is familiar from almost every first conversation. Marketing works with one chat service, development with a second, sales has a third through an existing account, and in administration a fourth arrived bundled with the office package without anyone choosing it. A platform takes maintenance effort off you. The responsibility stays where it is: your organisation remains the controller under the GDPR, the number of subprocessors does not fall, and bundling has nothing to do with German data sovereignty. The numbers are run against Langdock, because that is the platform that comes up most often in our first conversations: one contracting party in Berlin, German law, models from six providers behind it. What the platform can do and where it runs into limits is set out in our overview of [Langdock](https://www.arocom.de/en/knowledge/ai/langdock). ## What four tools generate in administration Every tool that processes personal data on your behalf needs its own data processing agreement under Article 28 GDPR, its own subprocessor assessment and its own deletion concept. | Duty | Four separate tools | One platform | | --- | --- | --- | | Data processing agreement | four contracts, partly different applicable law | one, checked once against Art. 28(3) | | Subprocessors | four lists, four change notices, four objection periods | one list with the model providers | | Record under Art. 30 GDPR | one entry per processing activity, containing four processors with four annexes | the same entry, one processor | | Deletion concept | four procedures, four retention logics | one, retention set by the admin | | User management | four user lists, four offboarding steps per leaver | one directory with SSO and SCIM | | Model switch | new provider, new contract | model choice per conversation | The third row is regularly mis-sold. The record under Article 30 is kept per processing activity: four tools inside the same activity are one entry with four processors, while a platform used in HR, marketing and support is three entries. The saving sits in the annexes. Article 30(5) exempts organisations under 250 employees, but only where processing is risk-free, occasional and free of data under Articles 9 or 10, which regularly fails for membership data, details under [shadow AI](https://www.arocom.de/en/knowledge/ai/shadow-ai). ## How to tell whether a DPA holds up, checked against Langdock Having a DPA on file says nothing about whether it holds up. Article 28(3) GDPR prescribes what has to be in it, which makes it usable as a checklist. The opening sentence requires subject matter and duration, nature and purpose of the processing, the type of data, the categories of data subjects and the obligations and rights of the controller. Plus eight commitments in points (a) to (h): - **(a) Processing on documented instructions**, expressly including transfers to third countries. For AI platforms this is where the question of where inference may happen hangs. - **(b) Confidentiality** of the persons authorised to process. - **(c) Security under Article 32.** Documented at Langdock: AES-256 and TLS 1.2+, ISO 27001 certified, SOC 2 Type II audited. Certificate number, auditor and scope are not public. - **(d) Sub-processors** only under the conditions of paragraphs 2 and 4. For that you need the named list, which was not publicly retrievable at Langdock on 7 August 2026. - **(e) Assistance with data subject rights.** - **(f) Assistance with Articles 32 to 36.** Article 33(2) already obliges the processor to notify you of a personal data breach without undue delay. A contractual deadline turns that into something verifiable. Your own 72 hours run regardless. - **(g) Deletion or return** of all data after the end of the contract, at your choice. Langdock's terms of service set no deadline for this. - **(h) Evidence and tolerating audits.** One step earlier sits the question of whether your plan is built for processing on behalf of a controller at all. With the widely used chat services, training on your inputs is the default with opt-out on the consumer plans and contractually excluded only on the business plans. A private account used for work has no DPA at all. ## The effort sits in maintenance Signing contracts is one-off work, what gets expensive is everything after. When a provider changes its subprocessor list, somebody has to read, assess and document the notice and object in time if needed, with four providers four times. When a person leaves, access has to be revoked in four systems, and orphaned accounts with access to chat histories are reportable in the worst case. The most common case is a different one though: tools management does not know about. A ban helps little here, three steps do. First take inventory, with a survey that carries no consequence for those who answer. Second decide per tool: move it onto a company account, replace it, or shut it down. Third write the result into your record of processing activities. More on that under [shadow AI](https://www.arocom.de/en/knowledge/ai/shadow-ai). ## What the bundling does not deliver Your organisation remains the controller under the GDPR, from the legal basis to the notification duty. What that means in practice is covered in our piece on [GDPR-compliant AI](https://www.arocom.de/en/knowledge/ai/gdpr-compliant-ai). The number of subprocessors does not fall either, it moves one level down: Langdock's terms of service name five processing paths individually, from Microsoft Azure to Black Forest Labs. And bundling is not data sovereignty. The Delaware ownership, the Frankfurt claim, worldwide inference under global deployment, encryption and certificates are all set out with sources in our overview of [Langdock](https://www.arocom.de/en/knowledge/ai/langdock). For a purchasing decision one sentence is enough: a contracting party in Berlin and data sovereignty are two different things. Whether a US parent's control over the subsidiary's data triggers CLOUD Act access is disputed; Article 48 GDPR requires a mutual legal assistance treaty for disclosure to a third country court in principle, while leaving the derogations of Article 49 untouched. ## EU AI Act: which obligation actually applies to you In the advisory decks clients show us, the role is what gets mixed up most often. Anyone using Langdock is a deployer under Article 3(4): a party using an AI system under its own authority, except in the course of a personal, non-professional activity. Under Article 3(3) a provider is whoever develops an AI system or a GPAI model, or has it developed, and places it on the market or puts it into service under its own name. The articles that appear most often in decks address the provider: | Obligation | Who it applies to | What follows | | --- | --- | --- | | Art. 4 AI literacy | providers and deployers, since 02/02/2025 | Take measures that support the development of AI literacy, and document them | | Art. 5 Prohibited practices | everyone, since 02/02/2025 | Do not build use cases that fall under it; the governance add-on has a rule template | | Art. 50(4) Transparency | deployers, since 02/08/2026 | Label deep fakes; for text only where it informs the public on matters of public interest, and not where there is editorial responsibility | | Art. 26 Deployer obligations | deployers of high-risk systems under Art. 6: Annex III from 02.12.2027, Annex I from 02.08.2028 | Assign human oversight, check input data, keep logs, inform workers' representatives | | Art. 11, 12, 14, 72 | providers | Does not apply while you use a third-party platform; the deployer side sits in Art. 26 | Article 4 applies to every organisation that switches such a tool on. It has been in force since 2 February 2025 and has no high-risk threshold. The Digital Omnibus on AI lowered its bar: since 27 July 2026, providers and deployers have to take measures that support the development of AI literacy among their staff, and they no longer owe any particular level of competence in any individual. An obligation of result has become an obligation of effort; the evidence for it stays the same. The 90-minute briefing that every rollout involves anyway is your evidence: record the date, the attendees and the contents. The second obligation with a date is Article 50(4), in force since 2 August 2026: deep fakes have to be labelled as artificially generated. For text it bites more narrowly than training courses suggest, namely only where the text informs the public on matters of public interest, and not even then where someone carries editorial responsibility. The AI draft of a members' letter is normally outside it, an unchecked press release is not. Building your own assistants brings in Article 25: with high-risk systems a deployer can, in certain circumstances, become a provider. The high-risk stage itself has moved back. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, in force since 27 July 2026, recast Article 113 of the AI Act: the obligations for high-risk systems under Annex III apply from 2 December 2027, those under Annex I from 2 August 2028. What moves is the deadline. The classification itself is still due: whether a use case falls under Annex III at all, such as AI-assisted shortlisting of job applications, is better settled now than in 2027. The prohibitions in Article 5 and the transparency obligations in Article 50 are untouched by the postponement. Source: Official Journal L, 2026/1744 of 24 July 2026, together with the European Commission notice on its entry into force, both retrieved on 10 August 2026. That leaves the governance add-on. What is documented is an agent inventory with owner, visibility and approval, plus compliance rules on every new agent version and a template on Article 5. It does not produce your Article 4 evidence, and it does not answer whether you operate a high-risk system. Which role applies to you is sorted out in [EU AI Act for SMEs](https://www.arocom.de/en/blog/eu-ai-act-smes). ## What actually holds One DPA with one contracting party, Langdock GmbH in Berlin, that you check once against the list in Article 28(3). One point of contact. German law and Berlin as the place of jurisdiction, while the contracts behind separate tools regularly carry foreign law and a foreign place of jurisdiction. The most valuable line, in the long run, comes from the product description: the model can be chosen per conversation and switched at any time. No new provider, no new Article 28 review. This is the point where the administrative argument turns into an operational one. If a provider goes down, throttles or raises prices, you carry on with a different model the same morning instead of starting a procurement. The same line carries the assistants built on the platform: they hang on the role and the instructions, not on a provider's name. That is what defines an [AI platform](https://www.arocom.de/en/knowledge/ai/ai-platform), and it is the durable part of the sovereignty discussion. In daily work it looks like this. A case worker in membership administration uploads a funding decision. The assistant pulls out the deadline, the conditions and the required form of the spending report, and turns them into a task list with due dates that the same case worker approves. In the organisations we speak to that is six to twelve decisions a year; the figure is an order of magnitude from the first conversation and not a commitment. When the model behind it changes, this assistant carries on unchanged, with its role, its instructions and its knowledge folder. Which decisions have to be made in small organisations before such a platform is covered in [Six decisions before an AI platform](https://www.arocom.de/en/blog/rolling-out-langdock-smaller-organisations), and how we support it on the service page [Introducing and supporting Langdock](https://www.arocom.de/en/services/langdock). ### Is a DPA with the platform provider enough, or do we also need contracts with the model providers behind it? As a rule yes, because the model providers sit in its chain as sub-processors. That is why you have to know and assess the subprocessor list, it is part of your own documentation. ### How do we quickly spot a weak DPA? In three places. First, deletion after the end of the contract: Article 28(3)(g) prescribes the commitment itself but no deadline, and that is exactly what you should have added. Second, the deadline for notifying you of a personal data breach, because your own 72 hours under Article 33 run regardless. Third, the named subprocessor list. ### Does the EU AI Act apply to us if we only use a platform? Yes, as a deployer under Article 3(4). That makes Article 5 and Article 4 on AI literacy apply, both since 2 February 2025, and the transparency duty in Article 50(4) since 2 August 2026. Article 26 is added if you operate a high-risk system under Article 6: Annex III applies from 2 December 2027, Annex I from 2 August 2028, both postponed by the Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026. Articles 11, 12, 14 and 72 address providers. ### Is Langdock a German provider? Contractually yes: Langdock GmbH in Berlin, German law, Berlin as the place of jurisdiction. In terms of ownership no, the GmbH is wholly owned by Langdock Inc. in Delaware. Saying both at once is the only correct answer. ### What changes contractually when we switch models? On a platform the contracting party stays the same. The only thing to check is whether the new model has an EU region. With separate tools, a model switch means a new provider and a new DPA.