Five Questions to Answer Before You Deploy an AI Agent in Your Business
The pitch for AI agents is compelling: automate the repetitive work, scale the interactions that would otherwise require staff, handle the tasks that run 24/7 without a human in the loop.
The pitch is real. The results are real. And the failure modes are also real, and they mostly share a common cause: the agent was deployed before anyone documented what it was expected to do, what it was not allowed to do, and how to tell the difference.
These five questions are not a comprehensive audit. They are the threshold test — the questions where a "we haven't thought about this" answer means you are not ready to go live.
1. What is the agent permitted to do without asking a human?
Every AI agent deployment exists on a spectrum between "suggest and wait for approval" and "act autonomously until something breaks."
Most businesses start at one end (too much human approval, which defeats the purpose) and drift toward the other end (too much autonomy, which creates incidents).
The right answer is not a philosophy — it is a specific list. The agent can send emails under a certain word count without approval. The agent can process refunds under a certain amount without escalation. The agent can schedule appointments without confirmation. Everything else requires a human in the loop.
If you cannot produce this list before the agent goes live, the agent will produce it for you by doing things you did not intend.
2. What data does the agent have access to, and does that scope match the task?
AI agents that access customer data, financial records, or internal systems need a scope that matches their function. A customer service agent that handles returns does not need access to your full customer database. A scheduling agent does not need access to your payment systems.
Scope creep in data access is not a privacy nicety — it is the primary vector for the incidents that make the news. The agent with access to everything is the agent that eventually does something with everything.
Ask your implementation team to show you, explicitly, what data the agent can read and write. If the answer is "we haven't configured that yet" or "it uses the same credentials as the admin account," that is a hold on deployment.
3. How does a customer know they are interacting with an AI?
This question has legal answers in an increasing number of jurisdictions, and it has practical answers that matter regardless of the legal requirement.
Customers who discover they were interacting with an AI — and were not told — respond consistently: they feel deceived, even when the interaction went well. The disclosure moment, handled correctly, builds trust. The discovery moment, handled badly, destroys it.
The practical question is not just "does the agent identify itself?" It is: does it identify itself at the right moment, in language that a non-technical person understands, without burying the disclosure in boilerplate that nobody reads?
If your agent interacts with customers, the disclosure design matters as much as the agent design.
4. What does the agent do when it encounters something outside its training?
Every AI agent will eventually encounter a situation it was not designed for. A customer asks an off-topic question. A transaction pattern that was not in the training data. An edge case your implementation team did not model.
The question is not whether this happens — it will. The question is what the agent does when it happens.
The answer should not be "it tries its best." The answer should be a specific escalation path: the agent acknowledges the limit, transfers to a human, or logs the encounter for review. "Tries its best" on an out-of-distribution input is how agents confidently produce wrong answers.
If your agent does not have a documented fallback behavior, it has an undocumented one that you will discover at the worst possible time.
5. How will you verify the agent's outputs before they reach the real world?
This is the question most deployments skip, because the answer is not built into the AI platform itself.
AI agents are confident by default. They produce outputs that look correct even when they are not. The invoice with the wrong figure looks like every other invoice. The compliance response that misses a requirement reads fluently. The customer email with outdated pricing is grammatically perfect.
Verification does not mean reviewing every output manually — that defeats the automation purpose. It means having a layer between the agent and the real-world consequence that catches the outputs that fail.
What does "fail" look like? It depends on your business, but in general: an output fails if it contains information that contradicts your current records, if it commits to something outside the agent's permitted scope, or if it produces a result a human reviewer would flag on inspection.
Building that verification layer is the last step before the agent goes live. Without it, you are not deploying an AI agent — you are deploying an AI agent and hoping the outputs are good enough.
---
The Pattern Across All Five
Every question above is a version of the same question: did someone explicitly design this behavior, or did you assume the AI would figure it out?
AI agents are remarkably capable at doing what they were explicitly configured to do. They are remarkably bad at figuring out what they were supposed to do when the design was left implicit.
The deployment failures that create the most damage are not the ones where the AI was bad at the task. They are the ones where nobody specified the task precisely enough for the AI to succeed or fail cleanly.
Define the scope. Document the limits. Design the fallback. Build the verification. Then go live.
---
Attest by ECTD provides the verification layer for AI agent deployments — structured assessment of your agent's scope, output quality, and compliance posture before the first live transaction. See how it works →