AI in Software Development: Which Tools We Use and How Your Data Is Protected

The short answer

Yes, AI tools are used in developing your software, and yes, source code does leave the building and head to those tools' providers.

In 2026, that's the norm for any development team that wants to stay competitive. The difference between a service provider where this is unproblematic and one where it isn't has nothing to do with whether AI is used at all — it comes down to three things: which tools are involved, what's contractually agreed about training, and what is explicitly never fed in.

This article answers both questions: how we handle it, and how you can check it with any other provider.

‍

What an AI tool actually gets to see

"The developer uses AI" sounds like a chat window someone occasionally pastes something into. In practice, there are three separate channels, and the second is the one almost nobody thinks about.

‍

The prompt. What the developer deliberately enters: a question, a code snippet, an error message. The most visible channel, and the easiest to control.

The context from the development environment. An assistant running inside the editor sees more than just the selected section. Depending on the tool and its settings, the open file, neighboring files, the project structure, or entire directories go along as context. The developer types one line and ends up transmitting more than they consciously selected. For tools that act as agents and take on whole tasks, this context is considerably larger still.

This is where it's decided how much of your project a provider gets to see. And this is where the real risk lies — not in the chat window.

Telemetry. The tool's own usage data: which suggestions were accepted, how often, in what environment. Usually uncritical for your trade secrets, but relevant for a complete picture.

‍

What goes into our tools, and what doesn't

Our developers follow a clear internal policy: no real personal data in AI tools. Our data protection rests on privacy by design under Article 25 GDPR — a separation that takes effect before the first prompt is even written.

‍

Certain data never leaves your systems toward AI:

• personal data belonging to your employees or customers
• production and live data from your systems
• passwords, credentials, and API keys
• sensitive business or financial data

Only what's technically necessary for development and unproblematic from a data protection standpoint flows into the AI:

• abstract code logic and algorithms
• source code fragments, project-related
• technical configuration data, pseudonymized
• telemetry data from the development environment

The second item in the first list is the most effective one. If you develop with anonymized or synthetic test data, you've solved the problem at the root: there's no live data sitting in the development environment that could accidentally be swept up as context.

‍

‍

Protection levels by AI tool

For every tool we use, we document the protection level, the safeguard mechanism, and the supporting evidence, so everything is comparable at a glance.

‍

‍

‍

‍

Why the data processing agreement doesn't cover your source code

This is the point where most vendor assessments talk past each other, and it matters more than any list of tools.

A data processing agreement under Article 28 GDPR governs the processing of personal data. Source code, as a rule, is not personal data. It's a copyrighted work under Section 69a of the German Copyright Act and, as long as it isn't public, a trade secret.

Two things follow from this that are regularly overlooked.

First, having a data processing agreement in place does not protect your source code. It's still necessary as soon as personal data sits in your systems, but for this particular question it's the wrong contract. The right place is the confidentiality provisions in the project contract, and these need to explicitly cover disclosure to third parties — including AI providers.

Second, the Trade Secrets Act carries a condition that's not widely known: information is only legally protected as a trade secret if it's safeguarded by appropriate confidentiality measures. If you don't define which tools are allowed to see your code, you risk not only the leak itself in a dispute, but also the argument that, for lack of protective measures, it wasn't a trade secret to begin with.

So this isn't a formality. It's the precondition for being able to invoke that protection at all, later on.

‍

Opportunities and risks

Transparency is a high priority for us, which is why we name both sides.

On the opportunity side there's a noticeable efficiency gain: faster development and therefore an earlier delivery date, more consistent code, fewer errors thanks to AI-assisted code reviews, and technical documentation that's produced alongside the work. The hourly rate doesn't go up because of this — the benefit goes to you.

We actively manage the risks:

• Access by US authorities. Theoretically possible via FISA Section 702 and the CLOUD Act. Our Transfer Impact Assessments conclude: low risk. Abstracted code fragments are not a typical target.
• Disclosure of data. Contractually excluded via the data processing agreement.
• Training on your data. Disabled through our business accounts and contractually excluded — not just toggled off in a setting.
• Faulty suggestions. Caught by manual review from our developers. An AI suggestion never goes into your system unreviewed.
• Data leaks through carelessness. Internal policy and regular training.

‍

What you should ask every service provider

Three questions that make the difference visible. They work just as well on us as on any other provider.

1. Which AI tools are in use, and who provides them, and where are they based?

Not "we work with AI," but an actual list. Every tool, every provider, every company headquarters. If the provider is based outside the EU — which is the norm for the common tools — standard contractual clauses and a Transfer Impact Assessment are required as soon as personal data is involved.

If someone can't produce this list within a day, they don't keep one.

2. Is training on your inputs contractually excluded, and where is that written down?

The most expensive question if it's answered wrong. In personal and standard tiers of the common tools, using inputs to improve the model is often the default; in business and enterprise tiers, it's contractually excluded.

The difference is a contract, not a toggle in the settings. Anyone with account access can flip a toggle, and nobody would notice. Ask to see the contract clause, not a screenshot of a settings page.

3. What gets fed in, and what explicitly doesn't?

A solid answer is two-sided. It names what goes in, and it names what doesn't. An answer that only covers the first half is incomplete. One that consists of "we take data protection seriously" isn't an answer at all.

How to recognize a solid answer

The difference lies in the specifics, not the tone.

Weak: "We use AI in a data-protection-compliant way." "Our tools are GDPR-compliant." "Customer data is of course never used."

Solid: a table like the one above, showing provider, location, purpose, and the status of the data processing agreement, standard contractual clauses, Transfer Impact Assessment, and training for each tool. Plus a list of what never gets fed in, right down to passwords and live data.

Only someone who has already answered this question for themselves can give that kind of answer.

‍

‍

What the law requires now

Three points that describe where things stand today.

The roles are assigned, and they're not negotiable. Most of the EU AI Act has applied since August 2, 2026. Whoever develops an AI system and makes it available under their own name is a provider. Whoever uses it within their own operations is a deployer. Your obligations follow from your role. In a custom development project, you are typically the provider, and your service provider delivers the technical work.

The training obligation applies to you too. Since February 2, 2025, Article 4 of the EU AI Act has required providers and deployers to ensure their staff have sufficient AI literacy, measured against their existing knowledge and the context of use. Anyone using AI within their company is a deployer. So this obligation doesn't stop at your service provider.

Data protection isn't the whole picture. The GDPR covers personal data. Your source code, your pricing calculations, and your process descriptions don't fall under it. For those, you need the confidentiality provisions in the contract.

‍

Frequently asked questions

Is my data used for AI training?

No. We use exclusively business and enterprise accounts. On these, training on user data is contractually excluded and documented in writing in the data processing agreement.

Does an AI tool see our entire source code?

Not necessarily, but more than just the selected section. Assistants running inside the development environment transmit open and neighboring files as context, depending on the tool and its settings. How far this context extends is configurable, and belongs in any serious disclosure.

Is a data processing agreement enough to protect our source code?

No. It governs personal data under Article 28 GDPR. Source code is a copyrighted work and a trade secret. Its protection belongs in the confidentiality provisions of the project contract, and these must explicitly cover disclosure to AI providers.

Can US authorities access my data?

Theoretically, yes, via FISA Section 702 and the CLOUD Act. Our Transfer Impact Assessments conclude: low risk. Abstracted code fragments are not a typical target for government access.

Is data passed on to search engines or third parties?

No. Whatever is entered into the AI tools stays within that system. Disclosure to search engines or other third parties is contractually excluded.

Why do I need to sign a data processing agreement?

It's required under Article 28 GDPR as soon as a service provider could process personal data on your behalf. It governs what data we process, for what purpose, and which protective measures apply — protecting both sides.

Can I, as a client, object to the use of AI?

Yes. The data processing agreement grants you a right of objection with a 14-day notice period. After that, we jointly determine whether the project can be carried out without AI tools. Opting out can affect the timeline and cost.

Can we generally prohibit our service provider from using AI?

Contractually, yes. In practice, a blanket ban rarely achieves its goal, because it either drives up the price or gets quietly circumvented. A named list of tools with training contractually excluded is a more effective approach than a ban nobody actually checks compliance with.

Who owns code that an AI wrote?

The rights to the software in your project are governed by your contract with the service provider, regardless of which tools were used to create it. Make sure the transfer of rights is worded without restriction and contains no exception for AI-generated portions.

What's the difference between a personal plan and a business plan?

It lies in the contract, not the features. Business and enterprise plans typically include the data processing agreement and the contractual exclusion of using inputs for training. Personal plans usually include neither, even though the interface looks identical.

How do we prevent live data from ending up in an AI tool?

Through test data. If you develop with anonymized or synthetic test data, you've solved the problem at the root. Developing with original data pulled from live operations is one of the most common silent violations in day-to-day project work.

Do we need to train our employees on how to use AI?

If you use AI within your company, yes. Since February 2, 2025, Article 4 of the EU AI Act has required deployers to ensure sufficient AI literacy among the people working with these systems. No specific level is prescribed, but doing something about it is required.

What happens to the data after the project ends?

All data handed over is returned, or verifiably deleted on request. The AI providers have defined deletion deadlines and deletion processes in their data processing agreements, which we have contractually required.

What do we require when switching service providers?

The same disclosure, retroactively: which tools were in use over the project period and what was contractually agreed about them. Plus confirmation that project data will be deleted or returned after the contract ends, with a deadline.

How does Devware demonstrate compliance internally?

Devware is certified to ISO/IEC 27001:2024 and ISO 9001:2015. We maintain a record of processing activities under Article 30 GDPR, have appointed an external data protection officer with heyData GmbH, and regularly train our developers on data-protection-compliant use of AI tools.

‍

For what further evidence you can request from a service provider, see Compliance evidence from software service providers. For when personal data may be entered into an AI system, see Giving customer data to AI systems. You can find the full current status of our own tools and contracts at AI compliance and data protection.

‍

Note: This article is a professional perspective from a software developer's point of view, not legal advice.

On how this was written: Our content is produced with AI support, but every text goes through a double human review before it's published.

‍

Sources

• Regulation (EU) 2016/679, General Data Protection Regulation, in particular Articles 25, 28, 30, 32, and 44 to 49.
• Regulation (EU) 2024/1689, Artificial Intelligence Act, in particular Article 4 on AI literacy, applicable since February 2, 2025.
• German Act on the Protection of Trade Secrets (GeschGehG), Section 2.
• German Copyright Act, Section 69a, protection of computer programs.
• DIN EN ISO/IEC 27001:2024, information security management systems.