Why I chose Semantic Kernel over Python for AI in .NET

Most AI training and most AI experts start from Python. That is a logical choice: the AI ecosystem (notebooks, libraries, community) grew up there. But after fifteen years delivering information systems in .NET and Angular, across contexts as different as private banking, offshore industry and the public sector, I keep running into a problem that “just use Python” does not solve: a company’s application estate is not written in Python. It is written in .NET, in Java, in SQL Server, in business applications that have been running for ten or fifteen years.

The problem I see at client sites

A company that wants to “do AI” ends up facing a badly framed choice: either hand the subject to Python specialists who do not know the existing IT estate, or let the .NET teams improvise without an AI culture. Either way, the outcome is the same: a prototype that stays a prototype, or a bolted-on integration sitting next to the information system instead of inside it.

Semantic Kernel: plug in, do not rewrite

That is the problem I set out to address when I passed the Microsoft Applied Skills AZ-2005 certification, which covers building generative AI solutions with Azure OpenAI and Semantic Kernel. What interests me about Semantic Kernel is not the technical novelty: it is that it does not require rewriting what already exists. The framework lets you plug language models, RAG and agents directly into business logic that is already written, tested and audited in C#.

In practice, this means the business rules that protect an application (checks, validations, workflows) stay exactly where they are. AI gets added as a new capability, not as a chatbot sitting next to the system, disconnected from the rules that keep the application running day to day.

The pattern I apply on engagements

This is exactly the approach I use on AI integration engagements: automated document extraction, a correction loop that learns from mistakes, business rules that can be reconfigured without redeploying, direct persistence into existing databases. This pattern (AI proposes, a deterministic layer validates, a human decides on ambiguous cases) is what makes an AI system hold up in production over time. I cover it in detail in a dedicated article.

What is next

The AZ-2005 certification is only one step: the roadmap continues with AI-103 (Azure AI Agent Developer). This blog documents these field notes as engagements progress, with a single thread running through all of them: AI that creates value for a business is AI that integrates into what already exists, not AI that ignores it.