Buying an AI agent? Ask for evidence, not promises

Start with the decision and the data

Identify who is affected, which data enters the system, where processing happens, which tools are reachable and what the agent can commit. Require declared subprocessors and locations, then assess cross-border safeguards in the real context — instead of assuming data always stays in Switzerland.

Procurement evidence checklist

Ask for evidence about your proposed configuration, not just the vendor’s general platform. Your security, privacy, business-owner and operations teams should agree who reviews each item — and where the acceptance decision is recorded.

• Signed scope and versioned architecture, including model and knowledge sources
• Data-flow map with providers, processing locations, retention and deletion
• Tool permission matrix plus customer-separation and out-of-scope tests
• Approval records for bookings, messages, deletions and other consequential actions
• Representative failures, regression results, incident roles and change triggers
• Remaining-risk statement, fallback process and exit or data-return plan

Turn an observed failure into an acceptance condition

Suppose a test shows that a support agent can retrieve a document title from another customer account but cannot open the document. “Low risk because content stayed hidden” is not a good enough conclusion. The acceptance condition can require authorization before retrieval, a clean repeat attack test across accounts, a review of affected records and proof that cached titles were removed — before any pilot.

The internal business owner decides whether the use still creates value inside the restricted scope. Security owns the technical closure criteria, privacy assesses the data consequence, procurement makes the obligation contractual, and operations owns monitoring and shutdown. A positive external assessment never transfers those responsibilities.