AI Governance and Data in Software Migration: Practical Risks and Controls

AI Governance Is Not Just an Enterprise Problem

AI governance is important not only for banks, healthcare organizations, defense companies, or large corporations. Companies with 50, 100, or 500 employees also handle confidential information, even if they do not store medical records or financial data for millions of customers.

For a small business, the consequences of a data breach can be more severe than for an enterprise-level company. A large organization has more legal, financial, and technical resources: it can afford to engage in litigation for years and recover from an incident. For a company with 200 employees, a similar problem could be a matter of survival.

That said, it would be unwise to do without AI in software migration. AI speeds up the analysis of legacy software systems, the preparation of documentation, and development. The question is who controls the tools’ access to data—not just on day one, but also after six months of work.

The Hidden Risk: Access Changes During the Project

At the start of a project, things often seem safe. The client allows the use of AI as a development tool but prohibits the sharing of passwords, personal data, and the contents of production databases.

Developers connect Cursor, Claude Code, or another AI tool to their working directory. Depending on the settings, the tool can read and index files and send the selected context to the model. A few months later, someone places a database dump, a financial report, or a file containing personal data there to troubleshoot an error.

The initial agreements have not formally changed, but the context available to the tool is now different. Data may end up in an index or a query to the model. Whether an external transfer has occurred depends on the specific architecture, and it can be extremely difficult to pinpoint the moment of a potential data breach.

Who is responsible: the employee who uploaded the file, the manager who authorized the AI, or the company that failed to implement technical controls? AI governance must account for changes in data access throughout the entire project, rather than being limited to the initial approval of the tool.

Jira, Confluence and Trusted Environments

Effective software migration requires more than just source code. AI helps analyze specifications, business documentation, defect history, requirements, and reports—which are often stored in Jira and Confluence.

Let’s say a company has integrated an AI assistant into these systems. A support specialist then creates a ticket and attaches the actual data from the customer who encountered the error. Previously, this information remained within the integrated system. Now, it is potentially accessible to the connected AI as well.

This raises a separate issue of trust: if Jira is permitted to store customer data, does that mean any AI processing within its ecosystem—for example, via Atlassian Rovo—is also permitted? No. It’s important to determine which models and subcontractors are involved in the processing, where the context goes, how access rights work, and what contractual safeguards are in place.

This is not a claim that Atlassian is insecure. It is an example of how trust in a storage system does not automatically extend to all of its AI integrations.

Production Data and Indirect Disclosure

Real-world databases containing personal, financial, and other sensitive information should not be thoughtlessly shared with external AI providers in their raw form. Whenever possible, masked, anonymized, or synthetic data should be used.

But the risk isn’t limited to directly uploading the production database to OpenAI or Anthropic. A company might use an API to assist analysts and project managers, connect AI to Jira, or have an agent read diagnostic logs. Personal data can end up in SQL queries, screenshots, stack traces, and tickets.

However, synthetic data does not replicate all historical anomalies and non-standard relationships within the production system. Therefore, what is needed is not an absolute ban on real data, but clear rules: who needs it, for what purpose, in what volume, and in what environment.

Responsibility: Customer, Contractor and AI Provider

Responsibility must be shared. The contractor must comply with the agreed-upon terms: which tools are permitted, what data is allowed, and what restrictions apply. Incorrect access configuration or the transmission of prohibited information constitutes one category of risk.

Another scenario involves an incident within the infrastructure of a trusted AI provider. We cannot directly control all processes at OpenAI, Anthropic, or Azure, and we should not unconditionally assume all risks that are beyond our control.

However, the agreement does not supersede legal requirements: the roles of data controller and data processor, obligations under the GDPR, and liability for violations are also determined by the actual processing of data. Therefore, prior to the project, it is important to have agreements in place, conduct vendor due diligence, define permitted scenarios, and allocate risks within the bounds of the law.

On-Premise AI: Security Comes at a Price

When a client prohibits the use of cloud AI, it is often suggested to deploy an on-premises infrastructure. This can reduce the risks associated with external data transfer if the entire processing chain truly remains within a controlled environment.

However, in-house AI is not automatically safe or cost-effective. Typically, off-the-shelf models—such as the Llama, Mistral, Qwen, or DeepSeek families—are used, rather than in-house frontier models. Factors such as performance for specific tasks, updates, hardware, maintenance, and specialized personnel must be taken into account. Infrastructure begins to become obsolete almost immediately, while cloud solutions evolve rapidly.

For government and defense clients, the model’s origin is a key consideration: some projects allow only specific jurisdictions and suppliers. There is also a risk of unwanted or malicious code. This risk did not arise solely with AI—humans could also have added a backdoor. But AI can generate so much code that fully manual verification is becoming increasingly difficult. Other AI tools can assist with code review, but independent verification and human oversight remain essential.

Policies Are Not Technical Controls

Vibe Coding demonstrates both the capabilities and limitations of AI governance. We can specify allowed models, architectural constraints, and restrictions on the use of external APIs in the Cursor or Claude Code rules. But the developer controls the workflow: they can modify the rules file, issue a conflicting command, or open another tool.

Therefore, an AI policy alone is not enough. It is necessary to distinguish between approved and non-approved tools and scenarios. If the use of a specific service is prohibited, technical controls are needed—as far as possible, in the browser, installed applications, and APIs. Where it is technically impossible to block access, the risk must be explicitly documented.

How We Would Implement AI Governance

In our experience, the main challenge isn’t writing the policy, but ensuring that it works in day-to-day development.

1. Describe the rules. Which tools and data are permitted, who approves exceptions, and who is responsible for what.
2. Test them on a safe project. Run through real-world development and migration scenarios to identify any missing steps or inconsistencies.
3. Train the team. Policies should explain practical situations rather than remain a mere formality.
4. Verify understanding. Testing and questions demonstrate that people truly understand the restrictions.
5. Document responsibilities. Confirm that staff have reviewed the policies and assign responsibility appropriately, within the bounds of the law.
6. Implement infrastructure monitoring. Track tools, integrations, permissions, and potential violations.
7. Review policies regularly. New features change the risks even in long-used software.

It is especially important to involve the very developers, analysts, and project managers who will be responsible for implementing these policies in the policy-making process. They are the ones who notice the details: where AI is already integrated, which folder is being indexed, and which ticket unexpectedly contains real data.

A document that has been signed but not read does not protect the company. When employees realize their actual and fairly distributed responsibilities, they begin to ask questions. This is a good sign: they are trying to understand how to follow the rules in practice.

Governance Must Evolve with the Tools

Even a tool that has long been approved could gain an AI feature tomorrow—such as call transcription, document processing, or intelligent search. If a client prohibits the use of AI, is automatic transcription of a meeting a violation? The answer depends on the wording of the agreement, the nature of the data, and the method of processing.

Therefore, a policy cannot be established once and then forgotten. It is necessary to monitor changes in tools and update policies before new features inadvertently expand access to information. General risk management frameworks, including the NIST AI RMF, are useful, but companies must develop specific technical scenarios on their own.

Why AI Is Already Essential for Legacy Migration

We believe that it makes little sense today not to use AI for the initial analysis of legacy applications. Before modern models became available, we also developed tools to identify dependencies, potential vulnerabilities, missing components, and migration issues. The difference is that now you can practically “talk” to the project.

AI helps determine what a component does, where the business logic is located, what dependencies exist, and why a particular part of the system might complicate migration. For certain initial analysis tasks, this can speed up the work by a factor of ten compared to a fully manual approach; this is our practical assessment of the capabilities, not a universal industry benchmark.

Next, you can quickly prepare the documentation, explore options for the target architecture, and develop a migration roadmap and vision for the next three to five years, taking the client’s business goals into account. This is where AI-assisted software migration delivers real value—provided that the code, documentation, and data are accessible to the tools under controlled conditions.

Conclusion: Governance Is Part of Migration Architecture

Sometimes a client bans the use of AI out of fear of data leaks, only to ask a month later why the team isn’t working faster using modern tools. This contradiction cannot be resolved simply by “allowing” or “banning” it.

AI governance must become an integral part of the architecture and management of software migration—with effective policies, trained personnel, technical constraints, and ongoing risk assessment. This is particularly important for small and medium-sized companies, for which a single serious incident could be business-threatening.

The question is no longer whether to use AI during migration. The question is whether the company is capable of controlling its use throughout the entire project.