Bring Your Own AI in software development: the token dilemma for IT decision-makers

The phenomenon: shadow AI at your own expense

The use of artificial intelligence has long been standard in software development. Tools such as GitHub Copilot, Claude or ChatGPT drastically speed up refactoring, troubleshooting and writing boilerplate code. The problem is that many companies are still hesitant to officially introduce them or shy away from the license costs.

The result is a new form of shadow IT: developers simply use the tools at their own discretion and for their own account. As they pay for the tokens privately, the management is often lulled into a sense of security - after all, the company incurs no costs and the software is completed more quickly. However, the legal and technical risks in the background are immense.

The 3 biggest risks for IT decision-makers

1 The creeping outflow of IP (intellectual property)

Whoever pays sets the rules. With private standard subscriptions or free access, providers such as OpenAI or Anthropic usually reserve the right to use the prompts and data entered for training future model generations in their terms and conditions.

As soon as your developer uploads proprietary company code, API keys or algorithms to a private AI tool, this intellectual property leaves your company. Your code becomes part of the global AI knowledge pool and, in the worst case, can appear as a code proposal for competitors.

2 The license and plagiarism risk (copyleft effect)

AI models have been trained with billions of lines of open source code - often in violation of restrictive licenses (e.g. GPL). If the private AI generates a code fragment that the developer incorporates unchecked into your commercial product, you risk serious copyright infringements.

If the so-called copyleft effect applies here, in extreme cases this can lead to you having to disclose the source code of your entire own product. As the account is private, the IT department lacks any audit logs to check the origin of the code afterwards.

3 Compliance and GDPR violations

Real data is also used in development - whether in log files, database dumps for testing purposes or customer error messages. If a developer copies this data into a private AI, this constitutes a breach of the GDPR. There is no data processing agreement (DPA) between your company and the AI provider for this private account.

The reality under employment law

Voluntary use is clearly regulated under employment law: Since the employer does not order the AI use and the developer could also do his work without AI, there is no entitlement to reimbursement for the tokens.

However, this does not exempt the employer from liability in the external relationship. If the AI-generated code causes serious security vulnerabilities or system failures at the customer, a company is liable. The internal liability of the developer is heavily capped by the principles of business-related activity (limited employee liability), which makes it necessary to strengthen security guidelines for development teams.

Roadmap for IT decision-makers: Ignore, ban or tax?

Simply looking the other way is no longer an option for IT managers. They need to take action. There are two strategic ways to do this:

Path A: The strict BYOAI ban

You completely prohibit the use of private AI accounts for business purposes by means of a company directive or IT policy.

• Advantage: Maximum control and legal certainty.
• Disadvantage: You risk frustration in the team and slow down the speed of innovation. There is also a risk that use will only go deeper underground.

Path B: The controlled permission model (recommendation)

You accept the reality, but set out unambiguous rules via a binding AI guideline. This should contain the following key points:

1. Strict upload ban: no proprietary code, no real customer data, no API keys in private systems.
2. Use only for generic logic: The AI may only be used as a digital sparring partner for general programming questions (e.g. 'How do I implement a QuickSort algorithm in Python?').
3. Obligation to check and responsibility: Every AI code must be checked manually for bugs, security gaps and license compliance before it is added to the repository.

Whoever checks in is responsible.

Successful companies ensure that every change to the code is strictly dated and given an author abbreviation. Because the supposed anonymous writing of code in the hope that no one will check the history on GitHub to find the culprit is true poison for code quality in 2026.

Developers who pay tokens out of their own pocket usually do so out of high motivation and a desire for efficiency. Use this energy, but channel it into safe channels.

The most sustainable solution for IT decision-makers is to replace BYOAI with enterprise solutions. Provide your teams with official, company-licensed tools (such as GitHub Copilot for Business or ChatGPT Enterprise). With these models, data training is deactivated by default, GDPR compliance is guaranteed and the source code stays where it belongs: in your company.

Checklist

• Observe the binding format: The exact format for the code comment is defined for all programming languages (e.g. // AI-gen: [abbreviation] [DD.MM.YYYY]).
• Comply with disclosure requirements: AI-generated code must not be deliberately concealed; this is considered a breach of the documentation obligation and can result in a warning.
• Assume ultimate responsibility: Responsibility for code security and quality remains entirely with the human developer despite labeling.