Every enterprise architecture conversation in 2026 includes the question: "Where does AI fit?" The honest answer is that it depends, but not in the hand-wavy way that usually means someone doesn't want to commit. It depends on whether you're solving a problem that AI is structurally suited for, or forcing it into a gap where conventional engineering would be faster, cheaper, and more reliable.
I've spent the last two years integrating AI into enterprise platforms at different scales. Some of those integrations created genuine leverage. Others were expensive experiments that taught the team more about what not to do. Both are worth understanding.
Where AI creates real leverage
The integrations that worked had a common pattern: they replaced tasks that were already being done manually, inconsistently, and at high volume. The AI didn't add new capabilities. It made existing workflows faster and more consistent.
Code review triage. On a platform with 200+ developers submitting pull requests daily, the bottleneck wasn't the review itself. It was figuring out which reviews needed senior attention. An LLM that flags architectural concerns, security patterns, and deviations from established conventions doesn't replace reviewers. It means reviewers spend their time on decisions that matter instead of scanning for style violations and obvious anti-patterns.
Documentation generation from decision records. Architecture Decision Records pile up. They're written at different levels of detail by different people. Generating summaries, dependency maps, and onboarding guides from ADRs is exactly the kind of structured synthesis that LLMs handle well. The source of truth stays human-written. The derivative artefacts get generated.
Configuration validation. In configuration-driven systems, where business rules are expressed as JSON or YAML rulesets, AI can validate configurations against business intent rather than just schema correctness. "This configuration removes a required field in the German market" is a more useful error message than "validation failed at line 47." The rules engine checks syntax. The AI checks meaning.
Incident pattern recognition. Production incidents generate logs, metrics, and alert chains that overwhelm human analysis in real time. AI that correlates these signals and surfaces likely root causes doesn't replace the on-call engineer. It gives them a starting point that's better than scrolling through Grafana dashboards at 2 AM.
Where AI creates expensive distractions
The integrations that failed also had a common pattern: they tried to automate decisions that require context the model doesn't have and can't reliably acquire.
Architecture decisions. Choosing between a monolith and microservices, selecting a state management approach, deciding how to split a platform into modules. These decisions depend on team size, organisational structure, existing infrastructure, business constraints, and a dozen factors that live in conversations, not codebases. An LLM can generate plausible-sounding architecture proposals. It can't evaluate whether those proposals will survive contact with your organisation. I've seen teams spend months building AI-assisted architecture recommendation tools that produced suggestions no experienced architect would endorse.
Automated refactoring at scale. AI-generated refactoring works on isolated functions. It falls apart on codebases where the real complexity is in the interactions between components, the implicit contracts, the side effects that aren't in the type signatures. On one project, an AI-assisted migration tool successfully converted 80% of the codebase and introduced subtle bugs in the remaining 20% that took longer to find and fix than doing the migration manually would have taken.
Replacing human judgment in cross-functional decisions. Decisions that sit at the intersection of UX, product strategy, and engineering require navigating trade-offs that are political as much as technical. Should we optimise for developer velocity or end-user performance? Should we standardise the design system or let teams diverge? These are judgment calls that depend on relationships, priorities, and context that no model has access to.
The decision framework
Before integrating AI into an enterprise system, I run every proposal through three questions:
Is the task already being done, manually, at volume? If yes, AI can probably help. If you're inventing a new capability that only makes sense because AI exists, be skeptical. The best AI integrations accelerate existing workflows. The worst ones create workflows that exist only to justify the AI investment.
Is the cost of a wrong answer low? AI-generated code review comments that miss something aren't dangerous. A reviewer catches it. AI-generated deployment decisions that skip a validation step are. Match the autonomy you give the AI to the blast radius of its mistakes.
Can you measure whether it's working? "Our developers feel more productive" is not a measurement. "PR review turnaround dropped from 48 hours to 6 hours with no increase in post-merge defects" is. If you can't define what success looks like before you build the integration, you won't know whether it succeeded after.
Integration architecture that holds up
The AI integrations that lasted beyond the initial enthusiasm shared a few architectural properties:
AI as a layer, not a dependency. The system works without the AI component. When the LLM is slow, unavailable, or wrong, the workflow degrades gracefully to the manual process. This sounds obvious but I've seen teams build critical paths through LLM APIs with no fallback. When the API goes down or the model changes behaviour after an update, the entire workflow breaks.
Human-in-the-loop by default. Every AI output goes through human review before it affects production systems. Not because the AI is always wrong, but because the cost of removing the human from the loop is much higher than the cost of keeping them in it. Automate the preparation. Leave the decision to a person.
Narrow scope, clear contracts. Each AI component does one thing, takes well-defined inputs, and produces well-defined outputs. The same principles that apply to modularisation apply here. A monolithic AI integration that tries to be smart about everything is as fragile as a monolithic codebase.
What I tell CTOs
AI is a tool. Like every tool, it has jobs it's good at and jobs it's bad at. The enterprise teams that get value from AI are the ones that start with a specific problem, build a narrow integration, measure the result, and expand from there. The teams that struggle are the ones that start with "we need an AI strategy" and work backwards to find problems to solve.
Your architecture doesn't need AI everywhere. It needs AI where it creates measurable leverage, integrated in a way that degrades gracefully when it doesn't work. That's a smaller surface area than most vendors will tell you. It's also a more durable one.