AI Guidelines Agencies & Service Providers | IT-Medienrecht

AI Guidelines for External Parties: Ensuring Compliance and Mitigating Risks

Agencies, freelancers, external development studios, and content service providers have long been integral to the value chain for many companies. This applies to both established corporate structures and startups, which often scale growth, marketing, and product development with external partners.

Simultaneously, the use of AI has become commonplace. This includes text drafts, design variants, code snippets, translations, research, image and video creation, automation in ticket systems, and even AI-supported analysis of customer data. This widespread adoption, however, creates a typical compliance problem: AI is being used without clear guardrails.

When external service providers are involved, the risk multiplies. Information, data, and work results pass through additional systems, people, and tool chains, increasing exposure and potential vulnerabilities.

An AI guideline for external parties is not merely a "nice-to-have"; it is an essential operational management tool. It defines permissible systems, data usage within specific tools, transparency and documentation obligations, and how rights to work results are safeguarded. Furthermore, it outlines how to maintain operability in emergencies, such as data protection incidents, IP claims, or reputational damage.

Without such clear rules, companies operate without oversight. A service provider might use "any" tool, feed content into open systems, or engage subcontractors without the client's knowledge. The company may only discover these issues when it is too late, perhaps through a warning, a data protection notification, or if confidential information appears where it should not.

Why AI Policies for External Parties Differ from Internal Policies

Many companies already possess internal AI guidelines or at least instructions for tool usage. However, internal policies have a limited effect on external partners because these partners are not integrated into the organizational structure. They often utilize their own systems, accounts, and processes.

Agencies, in particular, frequently work with standardized toolchains. These range from text and image generators to automation platforms and collaboration tools. Without binding regulations, the client quickly faces an undesirable situation regarding evidence and control. Results arrive, but no one can definitively say what data was processed where, whether training occurred, if third parties were involved, or if the output is based on problematic sources.

Moreover, AI usage is not a binary "AI yes/no" decision, but rather a spectrum. A key distinction lies in whether a service provider uses a closed system in a controlled environment or an open system where inputs could potentially be used for training or other purposes.

It also matters whether a service provider is merely "smoothing text" or processing sensitive information. This sensitive data could include product roadmaps, customer lists, financial data, internal strategy papers, unpublished campaigns, or source code. Consequently, an AI policy for external parties must not only state rules but also clearly operationalize approval processes, transparency mechanisms, and minimum standards.

Tool Selection, Data Flows, and Control Mechanisms

In practice, most disputes are determined not by whether AI was used, but by how it was used. Therefore, a robust AI policy should incorporate three often-missing components:

• Tool classification: Distinguishing between open and closed systems.
• Approval process: A formal method for authorizing AI tool use.
• Verification and documentation logic: Clear procedures for tracking and auditing AI activities.

Tool classification involves differentiating between open and closed systems. Crucially, it defines under which conditions each category is permitted. A practical approach often involves prohibiting open systems for confidential information, or only allowing them after explicit approval. Closed systems might be more readily permitted if certain settings, such as training or logging options, and contractual bases, like data processing agreements or subcontractor lists, have been clarified.

The approval process is the central mechanism for translating a "we have a policy" statement into genuine control. A mere notification obligation offers little help if the service provider, despite informing, remains free to make decisions. In practice, a clear rule has proven effective: new or modified AI systems require prior approval in text form (email is sufficient).

This approach is low-threshold yet provides clarity in case of a dispute. Additionally, a "tool list" is beneficial. It specifies which tools are already approved for continued use, which changes require notification, and which new tools necessitate fresh approval.

The documentation logic must be straightforward enough to be genuinely implemented. No one wants a 20-page log for every campaign. However, a concise deployment log—detailing the tool/provider, deployment environment/account, open/closed status, key settings, and subcontractors—serves as an extremely effective compromise.

This approach creates verifiability, streamlines audits, and reduces the risk of being without crucial facts in an emergency. For larger companies or those in regulated sectors, this often marks the difference between a "controllable" and "uncontrollable" situation.

Copyright, Rights Chain, and AI Output

The second significant risk area pertains to rights and IP issues. Agencies deliver logos, campaign visuals, texts, claims, videos, templates, code, music, or UI elements. When AI is involved, two common questions arise:

• Are there any transferable rights at all?
• Can the service provider effectively grant these rights?

Legal pragmatism is essential here. Rights can only be granted to the extent that they originate and to the extent that the grantor is authorized to dispose of them. This is precisely why AI guidelines and accompanying contractual clauses should operate with an "if and when" logic. This is not an end in itself, but a strategy for risk reduction.

It prevents the service provider from "guaranteeing" something they cannot actually guarantee. It also stops the client from relying on a seemingly watertight rights clause that could be challenged in a dispute.

Furthermore, a clear chain of rights is crucial. Employees, freelancers, subcontractors, and production studios involved must all grant their rights in a manner that ensures the final result reaches the client unencumbered. In traditional agency contracts, this is often handled with a blanket "the contractor warrants" clause.

However, for AI outputs, this is not always sufficient. Not because AI is "automatically illegal," but because the tool chain introduces additional uncertainties. These include the database used, license conditions, potential further use, and which third-party rights might be affected. Therefore, a robust guideline links rights commitments to specific mandatory mechanisms, such as tool release, input prohibitions, testing obligations, and documentation. This approach is far more reliable than broad assurances of "free of third-party rights," which are often too absolute in practice.

Another frequently overlooked point is that even if an IP claim is rare, its occurrence is typically very costly. Campaign halts, redesigns, recuts, redeployments, and reputational damage can quickly materialize. Such incidents can pulverize the supposed cost benefits of using AI. Therefore, a guideline is not "legal bureaucracy" but rather an economic safeguard for the entire production chain.

Liability, Data Protection, and Compliance

When an external service provider utilizes AI, companies quickly navigate the complex intersection of data protection law, confidentiality, and contractual liability. The central challenge is that many regulations are either too lenient ("please be careful") or too stringent ("comprehensive, independent of everything").

Both extremes are impractical. Overly lenient rules are ineffective, while overly strict ones may not be signed, or they create a false sense of security where work proceeds "somehow" outside formal structures.

A practical approach involves a clear line: strict liability and indemnification where obligations are breached, rather than blanket strict liability for all tool risks. A well-crafted AI policy explicitly defines "critical" obligations. These include prohibiting open systems for confidential data, requiring release for new tools, ensuring transparency, preventing unauthorized inputs, and adhering to data protection requirements. If a breach of these specific obligations leads to damage or third-party claims, liability becomes severe. Conversely, if the service provider adheres to the rules, the risk remains manageable.

The fundamental question in data protection is: Who processes what data, for what purpose, and in whose system? Agencies, in particular, often handle customer data incidentally, including CRM exports, newsletter lists, lead data, support cases, and user feedback. When such data enters AI tools, questions about order processing, Technical and Organizational Measures (TOMs), subcontractors, storage locations, and reporting channels regularly arise.

An AI policy cannot, and should not, replace comprehensive GDPR documentation. However, it can establish clear prohibitions, such as preventing certain data categories from being used in specific tool categories, and mandate coordination for relevant uses.

The AI Act is also gaining increasing importance. This is less because every agency will suddenly assume manufacturer obligations, and more because companies have an interest in ensuring clear assignment of obligations along the chain. This includes understanding what responsibilities lie with the provider, what with the operator, and what needs to be documented.

A sensible guideline does not state "we ensure everything" (as this is often not objectively possible). Instead, it articulates, "we fulfill the obligations applicable to us in our role and contribute to providing evidence." This approach is both legally sound and operationally feasible.

Practical Implementation

An AI directive is only effective if it is bindingly incorporated. This typically occurs as an annex to a service, agency, or framework agreement. Three key aspects are crucial for successful implementation:

1. Validity and Hierarchy: A clear rule must establish that the guideline is an integral part of the contract and how it relates to other regulations (e.g., Master Service Agreement/Statement of Work structure).
2. Change Mechanics: The landscape of AI tools is constantly evolving. It must be possible to update a policy without renegotiating the entire contract each time. This can be achieved through notification in text form, an appropriate deadline, and a practicable conflict resolution mechanism (e.g., objection or vote).
3. Operational Connectivity: Approval processes must integrate seamlessly into daily operations. A process requiring a compliance ticket and three signatures will likely be ignored. Conversely, a process managed via email and a tool list is more likely to be adopted and followed.

It is tempting for startups to downplay this issue, thinking, "We're too early, too small, it'll be fine." However, this mindset often leads to typical long-term damage. Contracts are concluded using standard templates, agencies work quickly and creatively, and no one scrutinizes what happens to product and customer data.

Later, as the startup grows, due diligence is required. Suddenly, it becomes unclear whether intellectual property was transferred correctly, data was processed properly, and subcontractors were engaged appropriately. A lean, well-formulated AI policy costs little at the outset but can save significant time, money, and disputes down the line.

For larger companies, the situation is often reversed. While compliance structures are typically already in place, they may not extend to operational agency work. This creates "parallel policy worlds"—strict internally, yet unclear externally. An external AI guideline precisely closes this gap, ensuring consistent compliance.

Conclusion

Once external service providers begin working with AI, the pertinent question shifts from whether risks exist to whether those risks are actively managed. An AI guideline for external parties represents one of the most efficient tools in this regard. It establishes clarity concerning tools, data, approvals, documentation, the chain of rights, and liability.

Such a guideline reduces the potential for disputes, enhances verifiability, and protects companies from being left without facts or contractual safeguards in an emergency.

Anyone collaborating with agencies, studios, freelancers, or external tech teams should not leave this critical issue to chance. In many cases, a compact, practical guideline, clearly linked to the contract and operational on a day-to-day basis, is sufficient. There is no "one-size-fits-all" template for this, as the tool landscape, risk profile, data types, and value creation vary significantly from company to company.

The development, adaptation, and contractual integration of such AI guidelines—particularly for agency and service provider constellations in marketing, content, software, games, and media—typically demand a combination of operational knowledge of the tool chain and precise contractual expertise. Accordingly, creating a tailor-made AI guideline, complete with approval processes, rights chain, and liability logic, can be swiftly implemented to scale collaboration with external parties or secure ongoing projects.