Software Migration, AI Governance and the EU AI Act: Who Controls Your Source Code?

AI is increasingly becoming a routine part of software migration. Let’s consider a typical project: a monolithic Delphi application that has been developed and expanded over the past twenty years. The documentation is partially outdated, some of the original developers have long since left, and the architectural decisions are scattered across thousands of Delphi units, SQL scripts, configuration files, and integration modules. When migrating a legacy system, the team can use ChatGPT, Claude Code, Cursor, and other AI tools to quickly understand the existing architecture, restore documentation, write characterization or unit tests, identify dependencies, and propose a target architecture.

From a technical standpoint, this appears to be a natural evolution of a developer’s toolkit. The governance issue arises before the AI even begins writing new code: it begins the moment the source code and project context become accessible to an external AI system. The main question is no longer just whether an LLM can help with migration, but rather what code we have the right to show it, through which product, under which account, with what settings, and who actually authorized this approach in the first place.

From R&D Experiment to Everyday Development

In many organizations, the use of AI begins as R&D. A developer takes a few Delphi units, feeds them to an LLM, and checks how well the model understands the legacy code. The results prove useful, after which AI begins to be used for documentation, testing, code analysis, and discussions about migration architecture. One team chooses Cursor, another chooses Claude Code, and some continue to work with ChatGPT.

Gradually, the tool ceases to be perceived as an experiment. For the developer, it becomes just as natural a working environment as an IDE (Visual Studio, RAD Studio): the project is open, the tool is always available, and AI assistance is integrated into the usual development workflow. At this point, the initial permission to “try out AI on a limited part of the project” easily turns into an informal rule that “this tool can be used.” These are fundamentally different levels of permission: R&D approval is not operational approval.

If a company has approved an experiment involving several files, this does not automatically grant the AI access to the entire client repository. But this is exactly the kind of shift that can easily go unnoticed, because after a few successful tasks, the developer stops viewing the AI as a separate channel for information transfer and begins to see it as part of their familiar workspace.

A Code Snippet and a Repository Are Not the Same Thing

When working with a standard chat interface, a developer makes a relatively explicit decision about what exactly to send to the model: they copy a method, a Delphi unit, or an SQL query and paste it into the prompt. Modern AI coding tools can operate in a much broader scope. To understand the architecture, a developer can open a directory or repository, after which the tool can search for connections between files, extract additional context, and utilize codebase indexing mechanisms.

This is a different risk profile. Cursor, for example, explicitly describes two main data flows outside the local environment: LLM requests, in which prompts and code context are sent to model providers, and Cloud Agents, which require temporary access to the repository. The documentation also describes Privacy Mode, model controls, repository blocklists, and the ability to restrict personal accounts on corporate devices. This illustrates why the phrase “we just sent a piece of code to the LLM” often no longer reflects the actual architecture of modern AI-assisted development.

For a software migration company, it is important to understand not only the name of the model, but also the entire data flow: which files are accessible to the tool, what leaves the local environment, where the context is created, whether indexing is used, which providers and subprocessors are involved, what is stored, which retention rules apply, and which privacy settings are in effect specifically for that workspace. It is especially important not to assume a product’s behavior based on the brand name alone: it depends on the plan, the account, administrative settings, and enabled features.

Personal, Corporate or Enterprise Account?

One of the most underrated elements of AI governance is the account type. A policy that simply states “ChatGPT is allowed” or “Cursor is allowed” is insufficient, because the same product can be accessed through a personal account, a developer’s own paid subscription, a corporate workspace, a Business plan, an Enterprise account, or a company-managed API account. These are different modes for protecting client-owned source code.

OpenAI states that data from ChatGPT Business, ChatGPT Enterprise, and the API is not used to train models by default. For consumer services, the rules differ and depend on user settings. Cursor, in turn, states that Privacy Mode prevents the use of code for training and can be centrally enforced for commands; Enterprise also provides additional administrative controls, including a repository blocklist, model access restrictions, and limitations on the use of custom API keys.

This leads to a practical conclusion: governance should specify not only the approved tool, but also the approved account type, workspace, privacy configuration, and project scope. The company must also prevent situations where a developer independently decides to use a personal account, a personal API key, or their own subscription simply because it’s faster. If the source code belongs to the client, the developer’s convenience cannot automatically serve as the basis for choosing a processing channel.

Developers Optimize for Getting the Job Done

Developers typically choose the workflow that best helps them solve a technical problem. This is especially evident when migrating a 20-year-old Delphi monolith: to properly explain the architecture or propose a migration strategy, it’s often not enough for AI to examine just a few isolated functions. You need to understand the dependencies between modules, the data access layer, shared libraries, the database schema, integration code, and other parts of the project.

Therefore, the rule “You can use AI, but only send small snippets” may be formally safe but practically useless. If the official workflow doesn’t allow the task to be solved, a predictable risk arises: the developer will expand the context, open more directories, or connect the entire repository, because otherwise the tool loses its main value.

Good AI governance must anticipate this behavior in advance. Its goal is not simply to impose restrictions, but to establish a permitted way to provide the AI with sufficient context to function: through an approved enterprise environment, centrally managed settings, repository controls, contractual approval, and clear rules for each project. A policy that makes a useful workflow impossible quickly becomes, in real-world development, a policy that people learn to circumvent.

Client-Owned Source Code Changes the Responsibility

For a contractor, the situation is even more sensitive because the source code often does not belong to them. Let’s say Softacom receives a client’s Delphi application for modernization or migration. The technical ability to open a repository in Cursor or Claude Code does not, in and of itself, grant the right to do so: one must take into account the contract with the client, the NDA, restrictions on subprocessors, internal AI policy, the agreed-upon project scope, and the client’s specific requirements regarding the use of external AI services.

Sometimes a client assumes that an internal development team will automatically handle intellectual property more carefully than an external software migration company. This is not guaranteed. Within a company, an AI tool can gradually become a routine part of development without a separate governance checkpoint, whereas a mature contractor works with third-party intellectual property on a constant basis and is required to formalize approved tools, account management, project permissions, and contractual restrictions, since a breach of these terms affects not only internal discipline but also the relationship with the client.

This does not mean that outsourcing is inherently safer. The advantage arises only when the contractor already has effective AI governance controls in place and employees are actually required to comply with them. For a company that is just beginning to implement AI, the alternative is either to build such a process in-house and train its own team, or to engage a software migration services provider that already has the necessary operational controls built into its delivery process.

Internal AI Policy Must Be Explicit

An AI policy should not consist solely of a verbal agreement with a team lead or a message in a corporate chat. The company must formally define the rules and obtain confirmation from developers that they have read and understood them and are aware of their responsibilities. Such a policy must address at least the following questions:

• Which AI tools are permitted;
• Which account types and corporate workspaces are permitted;
• Whether personal accounts and personal API keys may be used;
• For which clients and projects AI is permitted;
• Which categories of source code may be shared;
• Whether full-repository access is permitted;
• Who approves exceptions;
• Which privacy, retention, and training settings are mandatory;
• What to do in the event of an erroneous transfer of code or other protected information;
• Who approves AI-assisted architectural decisions;
• What minimum audit information must be retained.

At the same time, governance should not be structured as if all responsibility rests with the individual developer. If a company allows AI-assisted development, it must create an environment where the right course of action is easier than the wrong one: the corporate account is already set up, prohibited repositories are blocked, privacy settings are enforced centrally, and the developer does not have to interpret the client’s contract on their own every time.

What the EU AI Act Actually Says

The EU AI Act does not contain a specific rule stating “do not upload Delphi source code to Cursor,” nor does it classify a standard coding assistant as a high-risk AI system simply because it is used by a development team. However, Regulation (EU) 2024/1689 sets out several principles that are useful for establishing effective AI governance. It is important to distinguish between direct legal obligations and governance principles: Article 4 applies generally to providers and deployers, whereas Articles 12, 14, and 26, in the sections cited below, apply to high-risk AI systems.

Article 4 — AI Literacy

The current consolidated version of Article 4(1) requires providers and deployers to take measures that “support the development of AI literacy” among their employees and other individuals who use AI systems on their behalf. The article also requires consideration of technical knowledge, experience, education, training, and context of use; following the 2026 amendments, it explicitly clarifies that an organization is not required to guarantee any specific level of AI literacy for every individual.

For software migration, this means that AI literacy cannot be reduced to the ability to write a good prompt. A developer must understand what client code they are exposing, how a personal account differs from a managed enterprise workspace, which settings affect data usage, and why providing whole-repository context is a separate governance decision.

EU AI Act — Article 4, AI literacy

Article 12 — Record-keeping and Traceability

Article 12 applies to high-risk AI systems and links automatic logging to the “traceability of the system’s functioning”. This does not mean that Article 12 automatically requires a company to log every use of Cursor or Claude Code during a migration project, but the principle of traceability clearly highlights a weakness in the informal adoption of AI.

If, a year from now, a client asks whether their repository was used with an external AI provider, a mature organization should have a more reliable answer than the memories of individual developers. At a minimum, it’s helpful to know which approved tool was used, which corporate account, which project, which organization-level settings were in effect, and who had the authority to grant repository access. Governance that depends on developers remembering what they did is not governance.

EU AI Act — Article 12, Record-keeping

Article 14 — Human Oversight and Automation Bias

Article 14 also applies to high-risk AI systems. Article 14(4)(b) requires consideration of the risk of “automatically relying or over-relying on the output” of an AI system. In software migration, this principle is useful not only for verifying AI-generated code. There is another type of normalization: at first, the developer carefully monitors every prompt and every file that is submitted, but after a few months, the AI tool becomes part of the regular workflow, the repository is opened almost automatically, and the very act of submitting context ceases to be perceived as a separate decision.

This transition is particularly risky for client-owned IP. The process may change in practice, even though the formal approval and project policy remain the same.

EU AI Act — Article 14, Human oversight

Article 26 — Competence, Training and Authority

For deployers of high-risk AI systems, Article 26(2) requires that human oversight be entrusted to individuals who possess “the necessary competence, training, and authority”. For a typical coding assistant, this should not be interpreted as a direct requirement of Article 26, but the principle itself clearly distinguishes between two roles that are often conflated within a development team.

A developer may understand better than anyone else why Claude Code or Cursor needs access to the entire Delphi repository, but a technical necessity does not mean they have the authority to decide on their own whether the company has the right to transfer client-owned source code to an external AI system. Technical need and authorization must be kept separate.

EU AI Act — Article 26, Obligations of deployers

What Good Governance Looks Like in a Migration Project

Practical AI governance for legacy system migration can be boiled down to a few interrelated controls. The company identifies approved tools and account types, prohibits unmonitored personal accounts where they are not permitted, sets project-level permissions, defines the permissible repository scope, and, where possible, centrally enforces privacy, model access, and retention-related settings. If a contract or the nature of the project requires client authorization, the use of AI with client-owned IP is agreed upon separately.

Developers undergo training and formally confirm their familiarity with the policy, but human accountability doesn’t end with a signature. AI can explain the architecture, write tests, identify dependencies, and propose migration designs; however, its output remains a recommendation, not a source of truth. For a twenty-year-old Delphi application, the source of truth remains the running system, the source code, database behavior, and validated business requirements.

AI Does Not Remove Responsibility

AI can significantly speed up software migration: it can help understand legacy code, reconstruct missing documentation, prepare tests, and explore modernization options. However, it does not relieve the company that grants it access to the project of its responsibility.

The most dangerous situation arises not when an organization consciously decides to use AI, but when a small experiment quietly becomes part of the standard development process. Today, an engineer shows the models a single Delphi unit; tomorrow, an AI agent has access to the entire repository; and a few months later, no one can remember exactly when or by whom this transition was authorized.

Therefore, the key governance question is not “Can AI help us migrate this software?”. From a technical standpoint, the answer is increasingly “yes.” The more important question is: Can we prove that we know which AI is being used, by whom, with which account, on which client code, and under which rules?

AI governance should be part of the engineering process, not an obstacle that the team learns to work around. If AI is truly meant to accelerate migration, a secure and authorized workflow must remain convenient enough for developers to use in their day-to-day work.

Sources

– Regulation (EU) 2024/1689 — Artificial Intelligence Act, consolidated version as of 27 July 2026: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689-20260727

– OpenAI — Business data privacy, security, and compliance: https://openai.com/business-data/

– OpenAI — How your data is used to improve model performance: https://openai.com/policies/how-your-data-is-used-to-improve-model-performance/

– Cursor Docs — Privacy and Data Governance: https://cursor.com/docs/enterprise/privacy-and-data-governance

– Cursor Docs — Enterprise: https://prod.cursor.com/docs/enterprise

– Cursor Docs — Security and Privacy Hardening: https://prod.cursor.com/docs/enterprise/security-hardening