Your GenAI experiments are quietly becoming production dependencies

Somewhere in your organization, a proof of concept is having a birthday. It began eighteen months ago as an experiment: one team, one API key, a modest budget, and a well-understood agreement that none of it was "real." Since then it has been demoed, praised, connected to a workflow, and recommended to a neighboring department. Customers now experience its output. It has never been through architecture review, because it is, officially, still an experiment.

This is the quiet pattern of enterprise GenAI in 2024. Adoption did not arrive as a program with a steering committee. It arrived as a hundred small conveniences, each too minor to govern, which together now constitute a dependency on external model providers that would surprise most boards if it were drawn on one page.

The test for "production"

A system is in production not when someone declares it so, but when its failure would be noticed by someone outside the team that built it. By that test, a remarkable share of GenAI experiments crossed the line months ago. And crossing it brings unglamorous questions that experiments were allowed to skip: What data leaves the building? Under which agreement? Who is watching availability? What happens when the provider changes the model, the price, or the terms?

You do not choose the moment an experiment becomes infrastructure. You only choose whether to notice.

Why the "experiment" label is dangerous

The word "experiment" does real damage once it stops being true, because it functions as a permission slip to skip the disciplines a production system requires. As long as everyone agrees the thing is not real, nobody asks it to pass a security review, nobody assigns it an owner accountable for uptime, and nobody writes down what would happen if the provider disappeared. The label protects the system from scrutiny long after the scrutiny is warranted.

This is precisely how the largest exposures form: not through a deliberate decision to run something ungoverned, but through the slow drift of a system that was born unofficial and never had a moment of reckoning. The failure mode is rarely dramatic on the way in. It becomes dramatic on the day the provider has an outage, changes a model, or updates its terms, and a workflow customers depend on breaks with no owner and no fallback.

Treat model providers as critical third parties

The good news is that enterprises already know how to manage critical external dependencies; they have done it for payment processors and cloud platforms for years. The discipline transfers directly.

• Inventory the usage honestly, including the departmental subscriptions on expense reports.
• Route the traffic through infrastructure you control, so screening, quotas, and records are enforced rather than requested.
• Establish exit options while calm: a second provider, tested, reachable by configuration rather than re-engineering.

None of this is a brake on adoption; teams that no longer need to improvise their own safeguards move faster, not slower. The experiments were the easy part, and they did their job. What they proved is now infrastructure. It is time it was treated with the respect, and the suspicion, that infrastructure has always earned.