The company came to us with a problem that many technology firms have today, though they rarely talk about it openly. For several months the team had been using public AI tools to write code, analyse documents and prepare proposals. They did it on their own, without the management’s knowledge and without any rules. This is classic shadow AI: effective in the short term, but dangerous when a fragment of the product’s code or client data ends up in a public model.

The starting situation

The company’s infrastructure ran partly on premises and partly in scattered cloud services, with no shared oversight of cost and access. Bills were rising, and nobody could say clearly which resources were still needed. In parallel, developers and the sales department used free and paid AI tools, pasting into them whatever they happened to have at hand. There was no data classification and no answer to a simple question: what must not be entered into these tools.

Why it was urgent

For a company whose product is software, source code and client data are the most valuable assets. Sending them to an external model can mean losing control of where and how long they are processed. On top of that came specific obligations: GDPR in the scope of personal data and the AI Act, which is beginning to bring order to how AI systems are used in companies. The management was aware that one careless pasted fragment could cost a contract or a client’s trust.

How we ran the project

We started with the infrastructure, because without an organised environment it is hard to talk about safe AI. We moved the resources to Azure for business, introducing a split into subscriptions, budgets, cost alerts and role based access. As a result, the company regained control of what runs and how much it costs.

Next we launched an in-house AI assistant working within the bounds of the client’s Azure environment. The assistant uses the company’s documentation and knowledge, but does not send sensitive data or code to public models. This let the team keep the pace of work it expected from AI tools, without the risk that internal information would leave the organisation.

Finally, and in practice in parallel, we prepared an AI policy aligned with the AI Act. It is not a document for its own sake. It describes specifically which tools may be used, which categories of data are allowed and which forbidden, and how to classify information before using a model. The rules were created together with the team, so they are not a dead regulation but something people understand and accept.

What changed

The most important change is cultural. Instead of hidden use of random tools, the company has one safe place to work with AI and clear boundaries. The team saves time on repetitive tasks, such as preparing documentation, analysing requirements or first drafts of proposals, and does so with no risk of a leak.

On the technical side, the Azure environment is predictable in cost and access to resources is controlled. The management no longer gets bills it cannot explain. The company also has written rules for using AI that it can show to a client asking about security or an auditor verifying compliance with the AI Act and GDPR.

The result is not that the company started using AI. It was already using it, just in a risky way. The result is that it now does so consciously, safely and lawfully, without losing the benefits for which it reached for AI in the first place.