Before Your AI Agent Goes Live: A Pre-Launch Checklist

An AI agent that works in the demo and an AI agent that is ready for your customers are two different things. The gap between them is rarely the model. It is the questions nobody asked before launch: what the agent is allowed to do, how you know it is right, who takes over when it is not, and which rules apply to the data it touches.

This is the checklist I run before any agent crosses from build into production. It is the same gate I use for every delivery phase: a phase cannot be half-closed. Done means done, or it is not this phase.

1. Can you say exactly what it is allowed to do?

Write the agent's job in one sentence, then list every tool, system and permission it can reach. If the list is longer than the job needs, cut it. The OWASP Top 10 for LLM Applications calls this excessive agency (LLM06): an agent with more functionality, permission or autonomy than its task requires can be steered into actions nobody intended.

• Read access where read is enough. Write access only to the records it owns.

• No shared admin credentials. Give the agent its own identity, so every action is attributable.

• Anything irreversible (payments, deletions, messages to customers) goes through an approval step until the agent has earned trust.

2. Have you tested it against its real job?

A demo proves the happy path. Production is everything else. Before launch, build a small evaluation set from real examples: the common cases, the awkward ones, and the ones that should be refused or escalated. Score the agent against it, and keep the set, because every prompt or model change needs the same test again.

For the AI triage agent I built to sort maintenance requests, the questions were simple and unforgiving: does it classify the request correctly, does it route it to the right owner, and does it tag the SLA the contract actually promises? Accuracy you have not measured is a guess.

3. What happens when someone tries to break it?

Assume someone will. Prompt injection has held the top spot on the OWASP list for two editions (LLM01), because a model reads instructions and data through the same channel. An email, a web page or an uploaded file can carry text that the agent treats as a new instruction.

• Red-team the agent with injected instructions hidden in the content it processes, not just in the chat box.

• Check what it will reveal: personal data, credentials, internal documents, its own system prompt (LLM02 and LLM07).

• Never pass its output straight into another system. Validate it first, exactly as you would validate user input (LLM05).

4. Who takes over when it is unsure?

Every agent needs an exit. Decide in advance which situations it must hand to a person: low confidence, a complaint, anything involving money or personal data, anything it has not seen before. Then make that hand-off easy to act on, with the context attached.

Log what the agent saw, what it decided and why. An audit trail is how you answer a customer who asks "why did your system do that?", and it is how you find out what went wrong before the customer does.

5. Does it know its own budget?

Agents can loop, retry and call tools far more often than anyone planned. The OWASP list names this unbounded consumption (LLM10). Set limits on steps, tokens and spend per task, alert when a limit is hit, and model the monthly cost before launch rather than discovering it on the invoice.

6. Which rules actually apply?

For most teams in the UAE, the honest answer is: more than one, and not a single "AI law". There is no standalone federal AI act. What applies depends on what the agent does and whose data it touches.

• UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) whenever the agent processes personal data.

• DIFC Data Protection Regulation 10 if you operate in the DIFC and the agent processes personal data autonomously or semi-autonomously: notice to users, a register of systems, human intervention for unfair or unlawful outcomes, and an Autonomous Systems Officer for high-risk processing.

• The EU AI Act if the agent serves users in the EU. Transparency duties, such as telling people they are dealing with an AI, apply from 2 August 2026. Under the Digital Omnibus (Regulation (EU) 2026/1744), obligations for high-risk use cases now apply from 2 December 2027.

• Sector rules where they exist: regulated industries such as financial services and healthcare set their own expectations for AI.

Frameworks help you organise the work, even where nothing requires them. The NIST AI Risk Management Framework gives you four functions (Govern, Map, Measure, Manage), and its Generative AI Profile covers the risks specific to language models. ISO/IEC 42001 turns the same ideas into a management system you can be audited against. This is general guidance, not legal advice: confirm what applies to you with counsel.

The short version

• Scope: one-sentence job, least-privilege tools, approvals for anything irreversible.

• Evals: a real test set, scored before launch and after every change.

• Security: red-team for prompt injection, data leakage and unsafe output.

• Oversight: clear hand-off rules and a full audit trail.

• Cost: limits on steps, tokens and spend, with alerts.

• Rules: PDPL, DIFC Regulation 10, the EU AI Act where relevant, and your sector.

If you have built an agent and want an independent check before it goes live, that is exactly what my AI assurance review does: a risk classification, a control review across NIST AI RMF, ISO/IEC 42001 and the EU AI Act, adversarial testing, and a report you keep. Tell me what you are building.