What AI should — and should not — do in an enterprise implementation

There is a lot of enthusiasm for pointing AI at enterprise software work, and some of it is warranted. But the useful version of that idea has a sharp boundary. AI can accelerate a methodology. AI is never the methodology.

What AI should do

Inside an implementation, AI earns its place by doing the things that are genuinely tedious and error-prone for humans at scale:

• Guide the conversation — suggest the next question, surface what hasn't been asked yet.
• Find the gaps — identify missing information and highlight contradictions between what different stakeholders have said.
• Organize knowledge — keep the growing web of decisions structured and navigable.
• Draft the outputs — produce a first version of a requirement, a workbook row, or a test script for a human to review.
• Explain its reasoning — always show the "why," never just the "what."

What AI should not do

The failure modes are just as important as the capabilities:

• It should not replace the consultant or the customer's judgment.
• It should not invent requirements or business facts.
• It should not hide uncertainty behind confident prose.
• It should not approve an implementation.
• It should not make irreversible decisions.

Keep accountability visible

The reason to draw the line clearly isn't caution for its own sake. It's that enterprise transformation involves consequential, hard-to-reverse choices, and someone has to be accountable for them. The tooling should make that accountability visible — who decided, on what basis, with what confidence, and what remains open.

Purposeful AI presence means showing what the AI did and where human judgment still lives. That is a design decision, and we treat it as one.