The most interesting conversation happening in digital right now isn’t about which AI model to use. It’s about what happens next, when the request hits legal, or risk, or procurement, and the answer comes back as a nervous no.
Every team we talk to has someone pushing for AI. Chatbots, search tools, content generation, intelligent assistants. The ambition is real, and so is the friction. The agencies that are actually winning these conversations aren’t the ones with the most impressive demos. They’re the ones who show up with a framework for deciding when AI belongs in a project, and what to build when it doesn’t.
We’re navigating that exact tension on two separate projects right now. Both started with the same problem. They landed in completely different places.
When AI is the right answer
One client needed a better way to surface course information from a catalog so large that keyword search was failing the people trying to use it. A GPT-powered search tool was the right fit: it could interpret intent, not just match strings, and return results that felt like answers rather than a list of possible matches. So that’s what we’re building.
Anyone who’s watched an AI demo knows that demo conditions are not production conditions. The part nobody shows you is what we’ve spent most of our time on: rate limit thresholds and what happens when you hit them, kill switches that can disable the tool without a code deployment, prompt-injection mitigations, cost ceilings with alerting before they become surprises, and a review mechanism so the institution can audit outputs over time.
The AI capability takes about 10% of the conversation. The governance infrastructure takes the other 90%. That’s not a complaint, but what responsible AI integration looks like. A tool that works brilliantly in a demo and fails in production at 2x expected traffic, or surfaces a manipulated response because nobody thought about injection, isn’t a win for anyone. The scaffolding is the actual work.
When AI is the wrong answer
The second project had a similar surface-level brief: build an experience that guides users toward the right information based on who they are and what they’re trying to do. An AI chatbot was the first proposal. It didn’t survive legal review due to the risk that AI would be potentially speaking with authority to the public, representing the company’s interests.
The organization’s legal team had legitimate concerns about data handling, response consistency, and liability if the system hallucinated or said something wrong. Those aren’t objections to dismiss. They’re constraints to design around.
So we went a different direction entirely: a deterministic, persona-driven experience on rails with no AI. Logic-based routing, structured content, a rules engine that surfaces the right material based on explicit user inputs. It’s not a less sophisticated solution; it’s a different kind of sophistication. The kind that can be fully audited, behaves identically every time, and doesn’t require an acceptable-use disclaimer.
The users get what they came for. The legal team can stand behind it. The organization isn’t dependent on a third-party model whose behavior could change with the next API version. Both outcomes are good. Neither path was wrong. The AI project needed AI. The other one didn’t.
The decision framework that actually matters
Here’s what we’ve started bringing into early conversations before anyone’s committed to an approach:
What does the AI need to do that a deterministic system can’t?
If the answer is “handle natural language variation” or “interpret intent across a wide range of inputs,” that’s a legitimate AI use case. If the answer is “it would be faster to build,” that’s not.
Who needs to approve this, and what are their actual concerns?
Legal, security, and risk teams aren’t obstacles to route around, but stakeholders whose requirements shape the solution architecture. Find out what they need to say yes, and design for that upfront.
What happens when it goes wrong?
Every AI integration needs a failure mode that doesn’t end in a user-facing disaster. Kill switches, fallbacks, output monitoring, cost controls. If you can’t answer this question before you build, you’re not ready to build.
What are the governance requirements post-launch?
AI systems don’t stay static. Models change, outputs drift, usage patterns evolve. Who owns reviewing this? What’s the threshold for intervention? “We’ll figure it out later” is not a governance plan.
These aren’t questions we ask to slow things down. They’re the questions that make the difference between a project that clears legal review and one that stalls there indefinitely.
What this means for agencies
The default mode for a lot of agencies right now is to lead with the AI capability and figure out the governance later. That’s backwards. Clients don’t just need someone who can build an AI feature, but someone who can help them decide whether to build one at all, and then architect whatever they build to survive contact with their actual organization. That means getting comfortable with the conversation where the answer is: actually, a rules-based system is a better fit for what you need. It means knowing how to design governance infrastructure, not just AI features. It means being able to walk into a room with legal or risk and speak their language.
The agencies that earn trust in this moment are the ones who make the hard call early and explain their reasoning clearly. Not the ones who show the best demo.
If you’re trying to figure out when AI belongs in your project, and how to build it in a way your whole organization can stand behind, that’s exactly the conversation we have every day.