Where your data goes
| Question | What to ask them to show |
|---|---|
| 1. Where is our information stored and processed? | A diagram showing where files, AI requests, activity records and backups go, including the countries involved. |
| 2. What retention and training terms apply? | The terms and settings for your account, including how long your information and AI results are kept or used. |
| 3. Which third parties receive information? | The other companies and connected services involved, why they receive data and exactly what they receive. |
| 4. Which security requirements can you demonstrate? | Proof for the security requirements that matter to you, clearly separating what works now from what is planned. |
Permissions and actions
| Question | Evidence to request |
|---|---|
| 5. What can the tool read or change? | A list of records it can see, messages it can send and records it can change, including effects on other systems. |
| 6. How is access restricted? | The permissions used and a demonstration that one person cannot see another client's or team's records. |
| 7. Can we begin with draft preparation only? | A first version that prepares drafts without sending messages or changing business records. |
| 8. Which operations can run without a new approval? | The agreed rules, limits and checks that allow each action. |
Approvals and records of what happened
| Question | Evidence to request |
|---|---|
| 9. Who defines and enforces the approval policy? | Who may approve each action and a test showing that someone without permission is blocked. |
| 10. What exactly does a reviewer approve? | The exact content, recipient and record being approved, plus what happens if approval is declined or expires. |
| 11. What happens on failure or retry? | A test showing what happens after an error or repeated request, and how a person can stop the task. |
| 12. Which records can we inspect afterwards? | Which source records, decisions and results are saved, who can see them and how you can download them. |
Test the actual action, not just the approval button. Check that a rejected request stays blocked, that a change to the record is noticed and that repeating a request does not repeat the action.
Checking results and changing providers
| Question | Evidence to request |
|---|---|
| 13. Why are these models appropriate for the task? | Tests using examples like your real work, including wrong answers and answers the records cannot support. |
| 14. How can important output claims be checked? | Links to the source records, a way to check calculations and a clear response when records are missing or disagree. |
| 15. What happens if a provider or model changes? | Tests needed after a change and who will update the instructions, connections or result format. |
Having a choice of AI providers can help, but changing providers still takes work. Ask what has actually been tested and which checks must be repeated after a change.
Daily use and support
| Question | Evidence to request |
|---|---|
| 16. Who looks after the tool and its connections? | A named person or team for access details, file changes, failures and help requests. |
| 17. How do we monitor usage and operating effort? | Usage charges, service limits and time people spend checking results or resolving problems. |
| 18. How will the team operate it after handover? | Written instructions, training, what to do when it fails and where to get help. |
If you stop using it
| Question | Evidence to request |
|---|---|
| 19. What can we retain or export at the end? | Which files, settings, code and activity records you can keep, in which formats and who provides them. |
| 20. How can we stop using the tool safely? | How to stop actions, remove access, finish pending work and handle copies of your information. |
A tool that uses your existing records may still make it difficult to leave if it keeps its own files or depends on special connections. Ask for a practical handover plan.
How to use these questions with Genaima
Genaima AI builds Omni to help teams use their records for specific tasks. We agree which records it needs, what it should prepare, who can approve a change and who will support it. We cannot answer every question for your systems from a general page; we write down anything still to be checked before building.
Data and approvals covers the access questions. How Omni works explains the steps we take, and working with us covers the agreement and handover. Bring an example of the task so we can answer these questions for your situation.
Common questions
Who should take part in the evaluation?
The person responsible for the task and the person who checks the result. Include IT, security or finance when the tool would affect their work.
Which answers should stop a project?
Treat an unmet mandatory requirement as a reason to stop or change the design. A missing access boundary, uncertain authority or unsupported data-handling arrangement should not be bypassed by a successful demo.
Does the checklist apply to a chat interface?
Yes, where relevant. Read-only systems still need data and output controls; systems that can act also need authority, failure and action-record checks.
Talk through your taskTell us the task and the questions your team needs answered before proceeding.