Before buying an AI tool, decide whether it fits a defined business task at an acceptable total cost and within an operating scope your organisation can control. A useful purchasing decision names the owner, the alternatives, the evidence still missing and the conditions for a pilot or purchase.
An internal-auditing framework proposed by Raji and colleagues in 2020 connects decisions across an AI system’s lifecycle to documented evidence. It informs the questions below. Because it validates neither this worksheet nor any supplier, require evidence for the proposed configuration and use.
Compare the same work and its full cost
Start with the current workflow and a measurable baseline. Compare the proposed product with an existing tool, a different supplier, an internal build or a manual process. Include setup, integration, licences, training, human review, monitoring, maintenance, support and exit effort. Record assumptions instead of treating a demonstration’s speed as a realised saving.
Use the vendor worksheet to compare options against the same acceptance criteria. Ask your technical specialists to validate compatibility, data quality and implementation dependencies.
Illustrative customer-support example
An AI agent may read approved guidance and draft a reply in an authorised workspace. Sending replies or modifying customer records requires separate authority and technical permissions. Compare suppliers for the drafting task first. This is a fictional example, not evidence of customer savings.
Specify data use and operating permissions
Identify the data entering the tool, affected people, processing locations, sub-processors, retention, deletion and any model-training or service-improvement use. Obtain the applicable terms and settings for the proposed plan; clarify which commitments are contractual and which are configurable.
Legal anchors (CH/EU)
- Processor terms: if the supplier processes personal data on your behalf, check its terms against FADP Article 9 and, where the GDPR applies, GDPR Article 28. Both require, among other things, a contract or another legal act, processing within your instructions or permitted purposes, security guarantees and your prior approval before the supplier engages sub-processors.
- Processing locations: disclosure of personal data abroad must meet FADP Articles 16 and 17, for example a Federal Council adequacy decision or standard data protection clauses approved, issued or recognised by the FDPIC. Where the GDPR applies, transfers to third countries or international organisations must meet Chapter V GDPR.
- Impact assessment: under FADP Article 22, carry out a data protection impact assessment before processing that is likely to result in a high risk to the personality or fundamental rights of the people concerned. Where the GDPR applies, Article 35 GDPR sets a comparable duty for processing likely to result in a high risk to the rights and freedoms of natural persons.
- High-risk AI systems: where the AI Act applies under its Article 2(1) and you build a high-risk AI system with a third party’s AI system, AI model, tools, services, components or processes, Article 25(4) of the AI Act, as amended by Regulation (EU) 2026/1744, requires a written agreement on the information, capabilities, technical access and other assistance you need to comply; this does not apply to third parties that make tools, services, processes or components other than general-purpose AI models publicly available under a free and open-source licence. Deployers of high-risk systems have duties under Article 26, including human oversight. Under Article 113, these duties apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Article 6(1) systems related to products under Annex I, Section A. Under Article 2(2), neither Article 25 nor Article 26 applies to systems related to products under Annex I, Section B, for which only Articles 6(1), 60a and 102 to 112 apply; delegated acts under Article 2(13) may limit Article 25 for Section A systems. Systems placed on the market or put into service before those dates are covered only as set out in Article 111(2). Consolidated AI Act
FADP links point to the English translation, which has no legal force; the German, French and Italian texts are authoritative.
For an agent, name the authorising owner and list allowed and prohibited actions. Separate read, draft, send and update permissions. Identify connected tools, accessible data, approval events and the person who can pause operation or revoke delegated access. Record the boundary in the use-case register.
Ask for demonstrations and records
Ask the supplier to demonstrate the proposed configuration with safe test data. Can it deny a send or record-update attempt? Does approval apply to the actual action and recipient? What happens when permission is revoked while work is queued or in progress? Which steps require your own engineering team?
Request usable activity records linking the agent, authorising person, proposed action, approval, execution result and exceptions. Check export format, completeness, access protection and retention. For factual output, require source material that a reviewer can inspect; a polished explanation is not proof of the underlying facts.
NIST’s Generative AI Profile recommends checking sources and evaluating capability claims empirically. It supplies risk-management guidance, not procurement law or a certification of a supplier. Guidance: NIST Generative AI Profile, MS-2.3-002 and MS-2.5-003.
The NIST NCCoE agent-identity paper explores authorisation, delegation and logging. The cited February 2026 paper is a draft project concept, not a final technical standard. Treat it as research context for questions to test. Draft research: agent identity and authorisation.
Test revocation, recovery and exit
Use a bounded pilot to test approved actions, denied actions, human review, pause and revocation. Check queued and in-flight work before retrying to avoid duplicate actions. Agree who validates recovery and authorises a restart. Some external effects cannot be undone; define a manual correction or escalation route.
Before purchase, agree export formats, migration effort, notice periods, data deletion evidence, credential revocation, support escalation and a workable fallback. Test that exported records are usable outside the service. An exit clause alone does not prove that operations can continue.
Make an owned decision
Choose proceed, proceed with conditions, defer or decline. Name the approver and record evidence, residual issues, owners and deadlines. Reassess material changes in purpose, model, supplier, data or permissions before changed operation. The monthly-review worksheet helps follow actions through to completion and check effectiveness.
Ada’s governance service connects supplier decisions to operating controls. Discuss your next procurement decision.