Open Weights and Enterprise Procurement: The Shift Nobody Finished

January is when many enterprises reset budgets and revisit stack decisions. The presence of strong open-weight options does not automatically imply you should self-host—but it does force clarity. If you host, you are the service provider to your internal customers for uptime, patching, and performance. If you buy an API, you are trading capex and headcount for speed and shared responsibility. Half-measures—downloading weights without operational maturity—create the worst of both worlds.

Procurement has to evolve. Traditional clauses around uptime and indemnity map poorly to weights downloaded from a repository. Organizations that succeed write requirements in terms of control objectives: provenance verification, vulnerability response times, logging standards, and exit ramps. They accept that some risk stays in-house and price the people and systems to manage it.

Engineering leaders should welcome the scrutiny. Open models shine when teams have strong MLOps: evaluation harnesses, canarying, rollback, and observability. Without that foundation, the apparent savings evaporate in incident response and ad hoc fixes.

Legal and compliance teams are right to ask about training data and licenses—not because open is “dirty,” but because obligations flow to whoever deploys. If your product embeds a model into a regulated workflow, “we downloaded it from the internet” is not a strategy.

The pragmatic path is a portfolio. Use efficient models where latency and cost dominate and outcomes are easy to verify. Use managed APIs where you need vendor-side safety filters, rapid updates, or contractual cover. Publish internally which workloads sit where, and revisit quarterly as benchmarks move. The mistake is treating the decision as religious rather than operational.