Tools, policies and governance to use artificial intelligence safely and productively

Adopting AI in a development team almost never starts with a decision: it starts with a discovery.

End of sprint retrospective: a senior developer mentions having pasted eight hundred lines of a service into a cloud model to have them rewritten.

That service handled payment data.

In 2026 the question is no longer whether your team uses artificial intelligence, but whether anyone in the company has decided how.

The CTO sitting in that room does not have a technology problem.

They have a problem of dates: AI arrived in the company months before they authorised it, and it came in through the side door, the one nobody watches because it appears in no budget.

Nobody did anything wrong.

Quite simply, nobody did anything.

Adopting AI in a technical team without a policy is not digital progress, it is running a business risk without noticing it.

In here you will find what is really happening inside development teams, the three risks that were missing from the conference slide deck, and how to choose a tool by reading the contract instead of watching the demo.

Then how to write a policy developers actually open, the four step process for introducing it, and the arithmetic of the return on a team of five.

How widespread is AI adoption in development teams in 2026?

Try it in the meeting room, by a show of hands: who uses artificial intelligence to do their job?

Two hands go up, and they belong to the people who misunderstood the question.

Ask again over coffee: every hand goes up.

In 2026, AI adoption in development teams is not a company choice waiting to be made: it has already happened, and in most cases the company has neither authorised it nor measured it.

GitHub's survey on AI use in software development, published in August 2024 and run on two thousand developers at companies with more than a thousand employees across the United States, Brazil, Germany and India, says two things that need to be read together.

More than 97% have used AI tools at work, while companies that actively encourage adoption are still fewer than four in ten even in the United States, which is the best placed country in the sample.

On time saved, the most solid reference is still the McKinsey study "Unleashing developer productivity with generative AI", from 2023: 45 to 50% on documentation, 35 to 45% on code generation, 20 to 30% on refactoring, and less than 10% on the tasks developers themselves judge to be complex.

That last set of numbers never makes it onto the slides.

Those surveys cover a handful of large markets, and for most of the rest of the world figures of the same quality simply do not exist: what I see in the teams I work with in Italy is that here the gap between real use and authorised use is even wider.

So the problem is not adoption.

It is that adoption is happening out of sight.

It is called shadow AI, and it is worth calling it by its name: the use of artificial intelligence tools inside company processes without the company knowing which tools they are, who is using them and with which data.

Anyone who lived through 2012 will recognise it: it is the same story as the personal Dropbox folders with customer quotes inside them, except that this time what leaves the building is not the files, it is the reasoning about how your software works.

From there, companies take different roads.

The first is the ban, and on paper it holds up beautifully.

An IT manager at a financial services firm proudly explained to me that they had blocked the domains of the main services on the company firewall; three weeks later I watched one of their developers pasting code from a smartphone, standing next to the coffee machine, because the deadline was Friday.

The ban did not remove the use: it removed any chance of seeing it.

The second road is the most common and also the worst: no ban and no rules, everyone uses whatever they prefer with whatever data they need.

That is not freedom, it is the absence of a decision, and its flaw is that it leaves no trace.

The day you need to know which code passed through which model, the answer exists nowhere.

The third road is taken by very few, and they are the ones already gaining ground: chosen tools, written rules, measured use.

Banning AI in a development team is not a conservative strategy, it is a strategy of accelerated decline.

The real question was never whether to use it, but who answers for what when it is used.

And here is the point that makes the conversation difficult: the risk you are afraid of is not the one that will actually hurt you.

The real one is far more boring, it makes no headlines, and it presents the bill eighteen months later.

What are the real risks of AI in company code?

The slide they showed you at the conference had three bullet points and the word "hallucinations" in bold.

In practice, inside companies, I have never seen a project go into crisis because of a hallucination: those you can see, they raise a smile, and then somebody corrects them.

The concrete risks of AI in company code are three others: intellectual property that walks out without anyone noticing, vulnerable code that reaches production, and technical debt that piles up at the same speed AI writes.

Intellectual property leaves the company quietly

Nobody would take home a copy of the source code on a memory stick.

Pasting four hundred lines into a browser window feels like a different act, and it is not.

The only difference is that you can see the first one and not the second.

Cloud models used with personal accounts or free plans may use conversations to train the next versions.

If a developer loads in the pricing algorithm, the logic that calculates insurance premiums or the scheduling engine you spent six years building, what you are handing over is not code: it is the competitive advantage that code represents.

It breaks no law, it sets off no alarm, and nobody notices.

The answer is not to ban it.

It is to decide two things and write them down: which categories of data may leave and towards which tools, and on which contractual plans.

The enterprise plans of GitHub Copilot, ChatGPT and Claude contractually guarantee zero training on customer data, which is exactly why they exist and why they cost more.

Generated code is probable, not safe

A language model does not know what a vulnerability is.

It knows what is statistically likely to come after the line you have just written, which is a completely different thing.

There are documented suggestions with SQL injection in queries built by concatenation, credentials written in plain text inside tests, insecure handling of JWT tokens and missing authorisation checks, the ones the trade calls IDOR.

An endpoint that hands you order number 4711 simply because you asked for it, without checking that it is yours.

In an ASP.NET Core project the classic case is the query built by hand with FromSqlRaw, which the model suggests because there are thousands of examples of it online, not because it is the right choice in your context.

The defence is mechanical and belongs in the pipeline, not in good intentions: static code analysis, mandatory at build time, on everything that comes in, not only on what you suspect was generated.

SonarQube, Snyk and Semgrep catch most of this before the merge.

And it is an investment worth making anyway, AI or no AI.

Technical debt arrives at the speed of AI

This is the one nobody puts on the slide, because it is not frightening and it is not news.

Picture a very fast bricklayer who has never seen the rest of the house: what they build stands up, but there is no guarantee it fits with everything else.

A complete feature arrives in a few minutes.

If nobody checks that it is consistent with the architecture you have, what piles up is different patterns for doing the same thing, names that follow no convention, logic duplicated in three places and circular dependencies between projects that used to be separate.

The code works, it passes the tests, it goes to production.

It becomes unmanageable six months later, when somebody has to change it and discovers there is no longer a single way of doing anything.

The countermeasure costs time and is not popular: features generated with AI need an architectural review, not just a read of the diff.

Somebody who looks at what that code leans on, and not only at whether it compiles.

The paradox is that none of these three risks is solved by choosing the right tool.

The choice of tool does decide how much they will cost you, though, and it is made on a criterion that never appears in the demo.

Two teams with the same Copilot and the same budget.

The first finds out downstream what ended up in production, the second has somebody who looks at that code first.

The difference is not the model, it is who sits at the table: the AI Software Architect Course is there to make you that somebody.

Security, preventing data leaks, validating output: the three things this article has shown you as risks become design choices in there.

Vulnerable code is cheap to catch before the merge, and expensive after release.

How to build the list of approved AI tools for a .NET team in 2026

A software company I worked with showed me its list of approved tools: four names, chosen because somebody was already using them.

No date, no owner, not one line about the contractual plan that had been signed.

It was a list, not a decision.

The approved tool list of a .NET team is built on three criteria, in this order:

• What the contract guarantees about your data.
• Where the tool lives in relation to Visual Studio.
• What kind of work it is for.

Price is the fourth criterion, and at these figures it counts for far less than it seems.

The starting point for anyone working in .NET is still GitHub Copilot on the Business and Enterprise plans, between 19 and 39 euros per developer per month.

It lives inside Visual Studio 2022, VS Code and the JetBrains environments without anyone having to change habits, which sounds like a detail and is in fact what decides the real adoption rate.

The Enterprise plan is the one that puts in writing zero training on your data and protection on intellectual property.

It works very well on completion, on generating tests and on documentation inside the code.

Its limit shows the day you ask it to reason about an entire module: deep project context is something it does not have.

That limit is exactly why a second tool appears in many teams.

Cursor, at around twenty dollars a month, is a development environment built around AI on top of VS Code, with a much broader understanding of the project.

It becomes useful where Copilot stops: refactoring a complex module, migrating code, rebuilding the sense of a legacy system nobody carries in their head any more.

You pay the price elsewhere: it is not Visual Studio, so anyone working in Visual Studio has to change environment, and that is a team decision, not an individual one.

Then there is a kind of work that neither of them covers, and it is the one that counts most when decisions are expensive.

Claude, used through the API or on the Pro plan, is the tool teams turn to for architectural reviews, for analysing a design problem, for the technical documentation of a complex system, for code reviews done to understand rather than to fix a comma.

It is not an assistant that completes while you type: it is a tool to think with before you write.

ChatGPT Enterprise completes the picture on general code generation and explanations, with the same contractual guarantees on privacy.

Lined up side by side, the four do different jobs and are chosen for them:

The rest of the list is administration, and it is the part that always gets skipped: next to every tool you write the permitted contractual plan, because the free plan of the same product belongs on the banned list, and you write a review date and the name of whoever signs it.

A list of names, though, has never stopped anyone.

You need the document that says what you may do with them, and that is the point where almost every company gets the format wrong.

How to write a company AI policy that actually works

I have read a fair number of them.

The longest ran to fourteen pages and cited three European regulations in the introduction.

Nobody in the development team had opened it, and nobody found that surprising.

An AI policy that works fits on two pages, reads in ten minutes and answers five questions developers genuinely ask: what may I use, what may I upload, who answers for the code, what must I have learned before I start, and how will all of this be checked.

The first question is the simplest and almost nobody closes it properly.

You need the explicit list of approved tools with the permitted contractual plan, the list of banned ones, which includes the free plans of the same products and open models installed with no control over where the data end up, and a third list, the tools under evaluation, which exists to give an answer to whoever arrives with a new proposal instead of leaving them to work it out alone.

It is revised every six months, because at this speed a year is geology.

The second answers the question developers ask themselves in front of the empty window: can I paste this or not?

A useful classification fits in two lines.

On one side, what may leave: non proprietary code, public documentation, reconstructed examples.

On the other, what never leaves: the algorithms that are your advantage, customer data, credentials, pricing logic.

Translated onto an ASP.NET Core project, that boundary becomes concrete.

The connection strings and keys that live in appsettings.json never leave, not even anonymised: the structure of that file describes how your environment is built even without the real values.

And the internal repository is not fed to any tool without an enterprise plan, however convenient it would be to let it index everything.

A controller with the names changed, on the other hand, can leave without anyone losing sleep over it.

If the classification needs a lawyer to be applied, it will not be applied.

The third is the one that decides all the rest, and it is a single sentence: responsibility for the code always belongs to whoever makes the commit, never to the model.

Translated into process: all code generated with AI goes through a human review before the merge, and pull requests where generated code goes above 30% require a review by a senior.

It is not mistrust, it is the same rule that applies to a third party library you decide to include.

The fourth is a deadline, not a principle: a mandatory four hour hands on workshop for everyone within thirty days of adoption, covering safe use of the approved tools, the patterns to avoid and examples of generated code with real vulnerabilities in it.

The fifth is the check: a monthly review by the team lead of how many pull requests contain generated code and how many of those are rejected, with the policy adjusted on the data and not on impressions.

There are two questions, though, that an internal policy cannot close on its own, because it is not the company that asks them: who answers for the data that end up in a prompt, and who has to be able to prove it.

The AI adoption process in a development team: the 4 steps to get it right

The fastest way to make the whole thing fail is to start with the document.

You write the policy, you send it by email, and three months later you find out the team is using exactly the same tools as before, only with less inclination to say so.

AI adoption in a development team takes six months and four steps, in an order that is not negotiable:

1. Weeks 1 and 2: take stock of what the team already uses.
2. Weeks 3 and 4: write the policy and explain it in person.
3. Month 2: hands on training on your own code.
4. Months 3 to 6: measure, and correct the policy on the data.

The stocktaking is done with an anonymous questionnaire, and the anonymity is not a courtesy: it is the condition for anyone to answer at all.

Which tools are you using, to do what, with which data.

The results do two things at once: they tell you where the risk is already inside the building, and they tell you where spontaneous adoption has already found real value.

That second piece of information is worth more than the first, because it is free and no consultant can hand it to you.

Communicating the policy is not an announcement from human resources, it is a technical meeting with the questions built in.

Every rule is explained together with the risk it covers: a developer who has understood what happens if they paste in the pricing algorithm does not need to be policed, they simply do not paste it.

Whoever does not understand a rule works around it, and they are right to.

Month two is the first thing to go when the calendar tightens, and it is also the only one that really changes behaviour.

Not slides and not videos: your own code, on the screen, with real examples of bad suggestions to recognise and correct.

In the workshops I run on this subject the scene that moves people is always the same: a generated method that looks perfect, that passes the tests, and that opens an authorisation hole nobody in the room had spotted in five minutes of reading.

From the third month you measure, and it pays to have fixed the starting values before you begin: story points per sprint, defect density per released feature, average review time.

Those are the baseline.

The numbers that tell you whether adoption is really working, though, are four others.

You have the four step process.

The first and the fourth you can do on your own, with a questionnaire and an admin panel.

The second month you cannot, and trying it alone is why most adoptions stop at the policy: that is what the AI Software Architect Course is for.

Four hours with me are worth six months of rules read and never applied.

The architecture workshop runs with a maximum of five participants, because beyond that number nobody gets their hands on the code.

AI and GDPR in software development: who answers for the data that end up in a prompt

The bug only reproduces with real data, the customer has been waiting two days, and at six in the evening an extract of the customer table ends up inside a chat window with the question: why does this query return duplicates?

Nobody stole anything.

It is simply that those data, from that moment, have left.

When personal data end up in a prompt the company remains the data controller: the tool vendor is at most a processor, and only if there is a contract that names it as one.

So three things are needed before use, not after:

• A lawful basis.
• A written agreement with the vendor.
• Certainty about where the data are processed and how long they are kept.

One misunderstanding is worth clearing up straight away.

The GDPR, the European regulation that applies to anyone handling data about people in the European Union, is not concerned with code: it is concerned with personal data.

Your source code, for all that it is worth, is an intellectual property problem, and we have already covered that one.

The data protection problem comes from everything around it:

• Test data copied from production.
• Logs pasted in to understand an error.
• The screenshot with names and addresses in it.
• The sample file attached to the prompt.

That is where the processing begins, and almost nobody notices, because that window looks like a notepad.

Who answers is the next question, and it has one answer only: the company.

The model vendor becomes a data processor only if you appoint it under a contract, which is exactly what the enterprise plans of GitHub Copilot, ChatGPT and Claude provide and the personal plans do not.

A developer using their own free account on company data is not doing the company a favour: they are carrying out processing that the company has not authorised, has not documented and cannot reconstruct.

That is the difference between shadow AI as an organisational nuisance and shadow AI as a finding on the day of an audit.

The operational part is shorter than it looks.

Approved tools go into the record of processing activities like any other vendor, with three pieces of information beside them: which region the data are processed in, how long prompts are retained, whether they are used for training.

Enterprise contracts answer all three in writing, and that is half the reason they cost more.

If processing happens outside the European Union you need a basis for the transfer, typically the standard contractual clauses: it is not an obstacle, it is a box you tick before signing instead of after an incident.

Then there is the obligation almost nobody connects to this subject.

Article 4 of the EU AI Act requires both those who provide and those who deploy artificial intelligence systems to ensure an adequate level of AI literacy among their staff, and it applies regardless of the risk level of the tool.

It has applied since 2 February 2025, the penalties have been operative since that August, and from 2 August 2026 the supervisory framework is fully in force.

The rule sets no minimum number of hours and no certification: it asks for training proportionate to the role, and documented.

Translated for your team, the four hour workshop from the previous section is not a good practice for a forward looking company, it is the evidence that the obligation has been met, and the list with names, date and programme is worth as much as the content of the day.

It is worth saying what the AI Act does not ask for as well, because a great deal of pointless anxiety circulates around this subject.

A coding assistant is not a high risk system and nobody has to certify Copilot.

The conversation changes the day artificial intelligence enters a process that makes decisions about people, from recruitment to credit scoring, but that is a different system and a different conversation.

The rule that closes the circle is a single one and belongs in the policy next to the data classification: production data never go into prompts.

If you need to reproduce a real case you generate synthetic data, and in .NET that costs very little.

Bogus produces believable names, addresses and orders in about ten lines, Entity Framework Core seed data make them repeatable, and the test case that comes out can be pasted anywhere without asking anyone's permission.

Ten minutes the first time, zero after that, and the problem stops existing instead of being managed.

A well written document, though, does not apply itself.

The way you introduce it decides whether it becomes a shared rule or an annoyance to be worked around, and the first fifteen days weigh more than all six months that follow.

How to measure AI adoption after the first six months: the four numbers that count

Twelve licences up for renewal, the manager asking whether they are all needed, and a silence in the meeting that already gives the answer.

In six months nobody has opened the admin panel.

AI adoption is measured with four numbers, and none of the four is the amount of code generated:

• How many licences are genuinely used every week.
• How much undeclared use is left at the second stocktaking.
• How much of the team has completed the training.
• How many exception requests reach the policy.

The first is the simplest and the most ignored: weekly active users against the total number of paid licences.

The admin panels of the business plans show it without you having to build anything.

Below two thirds the problem is not somebody's laziness: either the tool is no use for the work those people actually do, or they have not had the time to learn it.

In the first case you remove licences and save money, in the second you train people and get the value back.

Those are two opposite decisions, and without that number you pick one at random.

The second comes from running the same anonymous questionnaire again at six months, with the same questions.

It is the most uncomfortable measure and the most honest, because it says how much of the team keeps using tools that are not on the list.

If it falls, the policy is believed.

If it stays the same, the document was read and filed.

If it rises, you banned something that was needed and nobody felt like telling you to your face.

The third is the percentage of people who have completed the required training, with the date beside it.

It serves two purposes that travel together: it is the only lever that really shifts behaviour, and it is the documentary evidence that the literacy obligation from the previous section has been met.

A list with names, date and programme is worth more than any declaration of intent in a meeting.

The fourth is counterintuitive: how many requests for exceptions or for evaluating new tools have arrived in six months.

Zero is not a good sign.

It means the list of tools under evaluation exists only on paper, and that whoever finds something new uses it without asking, because they have already worked out that asking leads nowhere.

A couple of requests a quarter, with an answer within a week, are the signal that the process is alive.

It is worth saying what not to measure as well, because those are exactly the metrics the platforms hand you ready made.

Lines of code generated reward whoever accepts suggestions without reading them.

The percentage of suggestions accepted measures compliance, not quality.

An AI usage score per person turns a tool into a competition, and you get what you measure: conspicuous use and no benefit.

The quality of generated code can certainly be measured, but with different metrics and different tools, and I cover it at length in the article on vibe coding governance in the company.

At the sixth month those four numbers serve one purpose only: rewriting the policy.

The tools nobody uses come off the list, the ones that turn up in the hidden usage survey either come in on an adequate contractual plan or are banned with a written reason, and the data classification is corrected at the points where it created friction without reducing risk.

A policy that is identical after six months is not stable, it is ignored.

At the sixth month somebody will ask you what it cost and what it returned.

It pays to get there with the sum already done.

Those four numbers tell you whether adoption is working.

They do not tell you what to change in the architecture when it is not, and that is the decision somebody has to be able to take at the sixth month.

The AI Software Architect Course works exactly there: observability, monitoring and traceability of decisions on systems that use AI inside a company.

You arrive at the six month meeting with the numbers and with the plan to correct them, not only with the numbers.

Deciding now costs a meeting.

Deciding later costs an incident, and somebody else writes the bill.

What AI really returns in a technical team: the ROI calculation with real numbers

The question always arrives the same way, and it is not the CTO who asks it: it is whoever signs.

Five licences, twelve months, how much comes back.

On a team of five .NET developers with GitHub Copilot Enterprise the sum closes at around ten times the investment in the first year: roughly 2,340 euros of licences against roughly 24,000 euros of time recovered.

Those are the two numbers to take into the meeting, and they stand up to scrutiny.

The cost is the only certain part: 39 euros a month for five developers for twelve months makes 2,340 euros a year, which is the order of magnitude of a single day of downtime on an average project.

The saving is estimated conservatively starting from GitHub's data: two hours a week per developer on mechanical work, meaning tests, repetitive code and documentation.

Two hours for five people across forty eight working weeks makes 480 hours a year, which at a fully loaded cost of 50 euros an hour is worth 24,000 euros.

Twenty four thousand divided by two thousand three hundred and forty is ten.

In teams that have done serious training and have clear rules on where AI is worth using, the reported saving rises to four or five hours a week per person, and the ratio reaches twenty to twenty five times.

In the opposite direction, with adoption but no training and no policy, the real saving halves, the security risk grows and technical debt accelerates: the sum stays positive on paper and negative in next year's accounts.

One honest caveat, because that ten circulates in presentations with far too much confidence.

There is a strong assumption inside it: that the time saved is spent on work of value.

If the two hours recovered every week dissolve into extra meetings, the return stays on the spreadsheet and never reaches the product.

The number does not measure AI, it measures how the team using it works.

And that is exactly why the calculation, on its own, is not enough to decide.

AI is an amplifier, not a replacement

The companies that will win between 2026 and 2030 are not the ones with the most powerful model.

They are the ones with the best process for using it.

A team of five developers with clear rules systematically beats a team of eight without them, and not because AI works magic: because it amplifies what is already there.

AI in a technical team is like a force multiplier: it amplifies what is already there. If the team is good, it becomes excellent. If the team has structural problems, it makes them more visible, and more expensive.

That is why this is not a decision for the purchasing department.

Buying the licences is the easy part and everyone knows how to do it; building the people who can steer a tool like this, recognise a bad suggestion and say no to a feature that works but breaks the architecture, that is another matter.

A video will not solve it, a subscription will not solve it: it is solved by somebody who looks at your team's code and tells you where it will break.

Some will spend the next three years on the receiving end of AI, finding out downstream what was uploaded, what reached production and how much it will cost to put right.

And some decide now, while deciding costs a meeting and not an incident.

The right moment to build AI governance in your team is not when the first security problem or the first intellectual property leak forces you to do it in a hurry: it is the quarter in which nothing has happened yet.

Go back for a moment to that retrospective, with the eight hundred lines of the payment service already uploaded somewhere.

It did not happen because your team is careless: it happened because nobody had told them where the line is.

Anyone can buy the licences, the policy fits on two pages, but the person who can look at a generated feature and say where it will break does not arrive with a subscription.

That person is built, and that is what we do together in the AI Software Architect Course, on your system and not on a sample project.

The quarter in which nothing has happened yet is this one.

A year from now you will already know which of the two roads you took, because you will have read it in the accounts.