Ted TschoppNo global car company asks each manufacturing plant to invent its own production system.
One plant may build a subcompact for one market, while another plant builds a sedan for an entirely different market somewhere else. Local matters. Local regulations matter. Local demand matters. But the company brand, its values, the engineering tolerances, the platform standards, the safety systems, the test procedures, and the production gates do not emerge plant by plant. They are designed centrally, then adapted responsibly.
Local matters. The center matters. They just have different jobs.
That is the mental model I keep coming back to for the future of IT.
For years, many of us in IT have operated more like a workshop with artisan craftsmanship than a factory network. Demand came in. Specialists built the answer. The business waited. That model was already under strain before AI. Cloud strained it. SaaS strained it. Mobile strained it. Laptops strained it. Even desktops strained it back in the day. But now AI is causing a rethink from the ground up.
That is because AI changes the economics of creation. And as we learned in high school, economics is the discipline of allocating scarce resources to deliver the best combination of value, quality, and speed. AI will allow more people to create workflows, apps, automations, analytics, copilots, agents, and data products at speeds that would have seemed unrealistic not long ago. Building is no longer scarce. Trust is. Trust that what is built has sustainable value, quality, and speed.
So when people ask whether AI makes IT less central, I think they are asking the wrong question.
In an enterprise where AI is assumed, the future of IT is not to remain the sole builder of every solution. It is to design and operate the production system in which many solutions can be built at quality. IT becomes the central engineering function for a digital factory system: the team that builds the platforms, sets the standards, defines the paved roads, governs the exception paths, and establishes the production gates that let speed scale without breaking trust.
If we get that right, IT is not being diminished. It is being promoted from a supporting capability to a strategic one. The question is whether we will rise to the occasion.
IT becomes central engineering, not just central delivery
The old mental model cast IT mainly as the team that delivered software and hardware. The next one asks more of us. IT has to industrialize how digital capability is produced.
That means building and validating the shared foundations before the rest of the enterprise scales them: approved tools, reusable templates, identity and access controls, secure connectors, governed data products, AI guardrails, deployment pipelines, monitoring standards, lifecycle controls, support models, and the architectural patterns that make local speed compatible with enterprise reliability.
In the past, most digital organizations and departments were given air cover to achieve speed and ignore governance. That is no longer an option. The enterprise has to assume that AI will be used everywhere, and that means the production system has to be ready everywhere. For digital organizations that came up in the era of rapid prototyping, that is a big mindset shift.
This is the work of industrialization. The business should not have to invent its own safe way to put AI into production. IT should do that work once, do it well, and make it broadly consumable.
That is how mature industries scale. Central automotive engineering does not personally assemble every vehicle. It designs the platform, the tolerances, the safety requirements, and the production system that allow many plants to produce many vehicles across many countries with consistent quality. IT’s future looks much more like that. We are not there to personally operate every machine. We are there to make sure the factory system works.
Governance has to become the fast lane
In too many enterprises, governance is still experienced as a checkpoint. That model will not survive in an enterprise where AI is assumed.
Governance has to feel more like lane markings, guardrails, and traffic engineering than a police stop. Its purpose is not to slow people down. Its purpose is to provide a fast lane where teams can safely go very fast. The goal is not to be the police. The goal is to engineer conditions under which quality survives speed.
A serious operating model therefore needs paved roads for the common work, platform standards for the scaled work, exception paths for the unusual work, and production gates for the high-consequence work. The right controls should increasingly live inside the platforms themselves: secure defaults, approved connectors, pre-cleared patterns, automated testing, model evaluation, release controls, observability, and auditability.
IT also has to own its side of the bargain. The paved road has to be genuinely paved. If the approved path is slower, weaker, or harder to use than the workaround, people will route around it. When that happens, it is not only a governance failure in the business. It is a product failure in IT. In these cases, IT must take a long, hard look at itself, internalize this failure as IT not doing its job, and do better.
The tiering should be explicit. Team-level productivity solutions should move quickly on approved platforms with light controls. Departmental capabilities should run in a managed model, with named owners, stronger review, and lifecycle expectations. Enterprise-critical, regulated, customer-facing, or deeply integrated systems should remain under full architecture, engineering, security, and DevSecOps discipline. Not every idea needs a factory. But anything the enterprise intends to trust at scale needs these gates to ensure safety.
Business capability should expand. Parallel engineering empires should not.
I want to be direct here. Business units should absolutely become more digitally capable. In fact, they need to. The people closest to the work should be able to improve the work.
But as a rule, non-IT organizations should not stand up independent software engineering organizations outside IT.
That is not because the business should remain dependent. It is because a company cannot run one brand with multiple hidden factories, each using different tolerances, tooling, security practices, support models, and standards of quality. What looks fast at first becomes fragmentation later: vendor sprawl, duplicated platforms, brittle integrations, inconsistent controls, higher support cost, and lower trust.
The goal is not to keep the business away from the tools. The goal is to keep the enterprise on one production system.
The better model is federated delivery on shared foundations. Let the business build more on approved platforms. Put embedded IT teams close to business domains where demand is sustained. Create formal cross-functional product teams where the capability becomes strategic. But keep one engineering operating model.
In my view, that should be a hard rule, not a gentle preference. If an exception is truly necessary, it should follow an explicit exception path requiring agreement from the business executive, the IT executive, and the accountable process owner, with named ownership for risk, support, funding, lifecycle, and compliance.
A useful tell is when someone in the business starts spending most of their time building apps, automations, pipelines, or technical products. That is not a sign that democratization has reached perfection. It is usually a sign that the factory needs another production line, another embedded team, or a formal product structure.
AI and data science need labs, but they also need production gates
Data science should remain close to the business because discovery is shaped by domain understanding. That part is right and should not change.
What should change is the assumption that a promising prototype is therefore ready for enterprise use. Pharma offers a better mental model. A compound that works in the lab is not yet a pill you can manufacture in multiple countries and distribute across multiple markets. Between prototype and product sit stage gates: validation, controls, repeatability, packaging, monitoring, and regulatory discipline.
Analytics, models, and AI systems should follow the same logic. Exploratory work can happen in approved sandboxes with lighter controls. Pilots should move into governed data, limited access, and human oversight. Production systems should require clear ownership, monitoring, lineage, evaluation, explainability where appropriate, fallback procedures, incident response, and supportability. Cross-enterprise or regulated uses should trigger even stronger review.
This is not about stripping freedom away from data scientists. It is about turning local excellence into enterprise-grade capability that benefits everyone.
AI lowers the cost of invention. It does not automatically lower the cost of ownership
AI will make it easier to create more things. That is good news. It is also dangerous news if the enterprise confuses faster invention with cheaper outcomes.
Without discipline, faster creation simply produces a larger inventory of duplicate automations, lightly used apps, unsupported models, and orphaned assets. The economic benefit does not come from building more things. It comes from selecting, industrializing, and sustaining the right things.
That is why portfolio discipline matters more, not less. The enterprise needs a better view of expected value, realized value, adoption, cycle-time reduction, error reduction, labor avoidance, licensing, compute consumption, integration load, support burden, and lifecycle cost. When AI increases the number of ideas that can become working prototypes, triage becomes one of the most important management disciplines in the company.
There is also a capability challenge here. Many organizations have not historically asked leaders to estimate benefits rigorously, compare investment alternatives, manage demand against constrained capacity, or measure value after release. In an enterprise where AI is assumed, those skills are no longer optional. Product thinking, financial analysis, prioritization, value realization, lifecycle management, and change leadership become part of the operating model.
There will be real upfront investment in platform hardening, training, data products, governance automation, and support design. Those are not administrative taxes. They are the cost of building a factory that can be trusted.
The deeper question is trust
The question is not whether AI will multiply builders. It will.
The deeper question is whether we will multiply trust at the same pace.
The healthiest manufacturing company was never the one where one master craftsperson insisted on shaping every part by hand. Nor was it the one where every plant improvised its own standards and called the chaos innovation. The healthy company was the one where central engineering, local skill, clear standards, paved roads, exception paths, and production gates made it possible for ordinary people to do extraordinary work at scale.
That is what IT should become in an enterprise where AI is assumed. Not the sole maker of every solution, but the steward of how solutions are made.
That is not a smaller calling for IT. It is a larger one.
Build the factory. Keep the trust.
