Greis from Acceligence commented on two other options for bringing in outside AI help. Using an independent contractor “can be great for eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck,” he said, but it can increase the risk of “key-person dependency,” where a single external person is the only one who understands the system.
As for purchasing an AI firm and onboarding its employees, a practice known as “acquihiring,” Greis said it can work well when the AI capability and expertise being brought in are truly strategic for the acquiring enterprise. But there is a risk that the acquired team will be smothered by the parent company’s bureaucracy: “You buy a speedboat, bolt it to an aircraft carrier, and then wonder why it stopped moving,” he said.
Finally, an open-source strategy can give companies flexibility and reduce vendor dependence, but “many companies underestimate the operational burden that comes with it,” Kodezi’s Khan said. “Open source only helps if the organization has the internal talent and discipline to maintain it properly.”
Bottom line: enterprises need to define their true objectives before deciding on an approach. Khan offered several key questions for CIOs to consider: “Who owns the deployment after implementation? Can we move providers later without rebuilding everything? What happens if the vendor relationship changes or disappears? Are we optimizing for short-term deployment speed or long-term operational resilience?”
In any scenario where outside firms have direct access to enterprise systems, IT needs to be kept fully in the loop. “The worst outcome is when an enterprise successfully deploys AI but no longer fully understands how its own systems operate underneath,” Khan said.
External help for AI deployments: 6 options
| Pros | Cons | |
| AI vendor FDEs | + Best expertise on the main model being used | – Vendor lock-in
– Operational detail leaks |
| Traditional IT consultancies | + Best understanding of change management, legacy integration, global rollout, governance, and operating-model redesign | – Can be too slow, too expensive, or too generic |
| AI consulting firms | + More practical AI deployment experience than traditional consultants
+ Less vendor lock-in than model-provider FDEs |
– May not sufficiently understand enterprise-grade requirements: security, identity, auditability, compliance, incident response, cost controls, and long-term maintainability |
| Independent contractors | + Useful for precision tasks: eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck | – Risk of ‘key-person dependency’ |
| ‘Acquihiring’ an AI firm | + Works when the acquired capability is truly strategic | – Acquired team can be smothered inside existing bureaucracy |
| Deploying open-source products | + Reduces dependency on one model vendor
+ Attractive for data sovereignty, control over enterprise systems, cost efficiencies, and regulated environments |
– Enterprise takes on full responsibility for security, patching, evaluation, deployment, monitoring, and lifecycle management |
Related reading: