The AI POC that will never reach production as-is

It is a signal that keeps coming back at companies running a Microsoft estate: a data scientist builds an AI POC, the demo convinces everyone in the room, and six months later that POC is still running exactly where it was created, in a notebook, on its author’s machine. Nobody else can get it running. This is not a model quality problem. It is an architecture problem.

Three blockers show up systematically in this situation.

The notebook is nobody else’s environment

A POC built in a notebook often relies on dependencies installed by hand, one experiment at a time, with no reproducible configuration file. That causes no issue as long as the POC stays a demo. It becomes a blocker the moment someone else, on the team running the .NET application in production, needs to deploy it: rebuilding that exact environment with no documentation often takes longer than writing a new version from scratch.

The model expects data that nothing produces automatically

Most POCs run on a dataset the data scientist already cleaned by hand before training or inference. That is a reasonable shortcut during exploration. But nothing in the existing IT estate produces that clean data automatically in production. The POC assumes a preparation step that was never built as a real application flow.

The output does not speak to anything else

A POC typically prints its result to the console, a CSV file, or a chart. None of that is directly consumable by the .NET application that actually needs the result to act on it: showing information to a user, triggering a business rule, feeding a dashboard.

The method that actually works

Faced with these three blockers, the most common reflex is to rewrite everything in C# so it fits cleanly into the existing estate. That is rarely the right answer: it doubles the work, and it introduces a risk of drift between the original model’s behavior and its rewrite.

The method that works is to expose the Python code as-is behind an API, in its own containerized service, and let the .NET application call it exactly like it calls any other service in the estate: same interface contracts, same logging, same monitoring, same deployment cycle as everything else. The model keeps its original language. What changes is that it enters the same rules as the rest of the estate, instead of remaining a tolerated exception on one person’s machine.

Industrializing an AI POC is not about migrating Python code to .NET. It is about bringing that code, as it is, into the same rules as the rest of the system.