Clarify the enterprise boundary
AI Consulting vs Systems Integrator
Separate business decisions from integration responsibilities when AI crosses enterprise systems, suppliers and an existing transformation programme.
When an AI proposal depends on enterprise systems, the buying question is often whether the business needs help deciding what should change, help connecting and operating the chosen solution, or both. AI consulting and systems integration can overlap. A supplier’s category does not establish the capability of the team it will assign.
For example, IBM’s public AI integration services describe both agentic application design and integration with existing systems. That first-party description, checked on 22 October 2026, demonstrates overlapping service scope; it does not independently establish performance. Compare proposed obligations and relevant evidence rather than assuming integrators only connect systems or consultants only write recommendations.
If the shortlist includes a large multidisciplinary firm, the Big Four comparison helps examine the proposed team, advisory scope and delivery commitments beyond the brand name.
Identify which uncertainty dominates the assignment
Advisory uncertainty concerns the operating outcome, alternatives, decision authority, investment logic and acceptable boundaries. Integration uncertainty concerns how an agreed capability fits systems, data flows, identities, change programmes and ongoing support. An engagement can require both types, but they should not disappear into one vague promise to deliver transformation.
Ask what remains unknown. If nobody has decided whether an agent may modify a purchase order, an integration estimate cannot settle the authority question. If the business has approved a bounded workflow but access to the system of record is unresolved, another strategy workshop may not remove the main obstacle. Distinguish the need from a product-vendor recommendation, which answers a different question about a supplier’s own offering.
| Decision or output | Business responsibility | Specialist contribution to agree |
|---|---|---|
| Outcome and operating boundary | Process owner accepts the intended change and excluded actions | Advisor analyses options and consequences; integrator challenges practical assumptions |
| System-of-record access | System and information owners authorise appropriate access | Integrator validates the agreed access and connection approach |
| Evaluation criteria | Business owner accepts what a useful result means | Advisor helps define evidence; delivery specialists make the test executable |
| Operational release | Authorised owners accept the service and remaining conditions | Delivery and support teams provide acceptance and recovery evidence |
| Benefit realisation | Operating leader changes the process and owns the result | Both providers contribute agreed evidence without claiming control they do not have |
This is a proposed allocation to adapt, not a mandatory organisational chart. A single provider may supply several contributions. The buyer still needs a clear answer to who can resolve a disagreement and who accepts the operational change.
A manufacturing group adding AI during an ERP migration
Consider an illustrative food-manufacturing group replacing its enterprise resource planning system. Purchasing staff want an agent to summarise exceptions across supplier correspondence and order records. The migration integrator knows the target system and interface schedule. A consulting proposal offers use-case assessment and an AI roadmap.
The business first needs to decide whether the proposed assistance should read exceptions, recommend a response or amend orders. A limited summary may be valuable before all workflows migrate. An order amendment could depend on permissions, approval rules and records that are still changing. Those are materially different commitments.
A useful combined assignment would define the business boundary, identify the authoritative records during transition and ask the integrator to validate the feasible sequence. It would not create a parallel AI plan that assumes the migration has finished. The output should state which work can proceed now and which depends on a specific migration decision or release.
For example, historical-case analysis may be possible with authorised extracts. A live workflow that changes orders may remain conditional on migration acceptance and approved authority. These are illustrative possibilities to investigate, not claims that a particular ERP product supports them.
Keep a joint dependency record
Record every material dependency with an owner, required evidence, due decision and consequence if it is not met. Include business dependencies as well as technical ones. The purchasing policy may be unresolved even when the connection works. The source record may exist in two systems during transition. A support team may not have accepted the new service.
Require the advisor and integrator to review the same record. If one assumes daily source updates and the other plans a less frequent exchange, resolve the difference before testing a business claim. Ask whether changing the assumption alters the outcome, the cost or the authorised action. This makes the interface between contracts reviewable.
The AI operating model defines enduring responsibility after the programme. Use vendor due diligence to inspect the supplier arrangements and subcontracting relevant to the chosen scope. Avoid treating the existing relationship with an integrator as evidence that every new AI responsibility is covered.
Agree shared acceptance without blurring contracts
Technical connection success and business suitability are different acceptance questions. A message can reach the correct system while containing an unsuitable recommendation. Conversely, a useful analysis can fail to operate within the required enterprise environment. The acceptance plan must address both.
Maintain a joint record that identifies the business scenario, expected behaviour, relevant system condition, evidence owner and unresolved issue. Each provider accepts responsibility for its contracted work, and the buyer accepts the operating result through the agreed authority. A shared record does not require pretending that all suppliers provide the same warranty or service commitment.
When results fail, classify the cause before allocating corrective work. Was the requirement incomplete, the information unreliable, the implemented behaviour inconsistent with the brief or the environment changed? Do not allow “the AI is wrong” and “the interface works” to become competing explanations that leave the user’s problem unresolved. The pilot-to-production playbook develops the release decision.
Use change control for changed decisions
A new request to move from summarising orders to modifying them changes authority and acceptance, even if the supplier says the code change is small. A migration delay may change timing without changing strategy. Record the difference and require the appropriate approval before additional work begins.
Compare proposals using the same scope, internal effort, integration assumptions and support boundary. The evaluation scorecard can structure that comparison. Do not assume a specialist is cheaper, an integrator is slower or an incumbent will always reduce coordination; ask for the actual team and commitment.
Decide whether to use one provider or two
A single provider can reduce some handoffs if it genuinely has the necessary advisory, engineering and operating capabilities. Separate providers can add specialist challenge, but the buyer must manage their shared decisions. The value depends on the work and governance, not the number of logos in the programme.
Publisher disclosure: Open for AI offers consulting and develops solutions, so a proposal should separate advice from any later delivery recommendation. The buyer should retain the evidence and the option to use another qualified provider. Consulting versus implementation explains that commercial boundary in more detail.
For agentic AI consulting around an existing integration programme, bring a redacted system map, the migration decisions already made and the action you want AI to support. Discuss the advisory and integration responsibilities so the enquiry can focus on the unresolved decisions and the evidence needed from each party.
FAQ
Your questions, answered.
Can our existing systems integrator provide AI strategy advice?
It may be able to, but verify the proposed team and outputs rather than relying on the existing contract. Ask for relevant advisory experience, options analysis, business participation and a clear treatment of alternatives outside its preferred platform. An integrator’s familiarity with your systems is useful context, but it does not automatically answer the investment or authority questions.
Should we wait for an ERP migration to finish before considering AI?
Not necessarily. Some discovery and historical-case assessment may be useful during migration, while live actions depend on stable records, access and operating responsibilities. Identify those dependencies explicitly. Avoid committing to an integration that will be invalidated by the migration unless the interim value and replacement effort justify it. The decision should follow the actual transition plan.
Who should own the requirements between a consultant and an integrator?
A named buyer-side owner should maintain the approved business requirements and resolve scope decisions with the appropriate specialists. The consultant can clarify the intended outcome and evidence; the integrator can challenge feasibility and define delivery details. Keep one accepted version of the boundary and decision record so neither provider relies on a different interpretation.
Does a successful interface test prove the AI workflow is ready?
No. It establishes only the aspects the test covered. The business still needs evidence that information is interpreted appropriately, proposed actions respect authority, exceptions reach the right owner and the operating team can support the workflow. Combine technical and business acceptance, while keeping each provider’s contractual responsibilities explicit. Do not turn connection success into a broader readiness claim.
How should we handle a request for the AI to write back to enterprise systems?
Treat it as an explicit scope and authority decision, not just another connector. Identify the permitted changes, approval conditions, evidence and recovery responsibilities before estimating or authorising delivery. Revisit the business case and evaluation if the action becomes more consequential. The existing read-only assessment does not automatically support permission to change enterprise records.
Is using two providers better for independent challenge?
It can add challenge if the second provider has a clear review mandate, access to evidence and freedom to raise concerns. It also creates coordination work and can leave gaps if responsibilities are unclear. Compare the value of that challenge with the buyer’s ability to manage the handoff. Two contracts do not by themselves create independent assurance or shared accountability.