Start with outcomes: scope, ROI and success measures
Question 1: What business outcomes will the engagement be measured against in the first 90–180 days? Ask the agency to specify the workflows to automate, the baseline metrics, and the expected lift (for example, reduced handling time for customer service, higher first‑contact resolution via an AI chatbot, or fewer manual touches in back‑office reconciliations). Good agencies in London will translate ambitions into a narrow pilot with a clear decision gate for rollout, including targets, sample sizes, and acceptance criteria that your operations and finance teams agree to. If they can’t define what “good” looks like in numbers you already track, your risk of stalled proofs‑of‑concept increases.
Question 2: How will total cost of ownership be modelled and governed? Push for a simple model that separates one‑off build costs, platform/model usage, data storage, observability, human‑in‑the‑loop review, and change management. Ask how the agency will prevent surprise usage bills (rate limits, caching, retrieval‑augmented generation to reduce token spend, and batch/off‑peak processing). Request a forecast with sensitivity bands and an explicit plan for cost monitoring from day one. NIST’s AI Risk Management Framework is a useful anchor for risk‑benefit trade‑offs and governance checkpoints across the lifecycle. ([nist.gov](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10?utm_source=openai))
Data protection and regulatory fit for UK and European operations
Question 3: How will personal and sensitive data be handled across training, fine‑tuning, and inference? In the UK, the ICO’s Guidance on AI and Data Protection expects fairness, necessity, and accountability across the lifecycle—including when using third‑party models. Ask the agency to map data flows, identify controllers/processors, define lawful bases, and show how inferences are treated. Require a DPIA where appropriate, data minimisation at ingestion, robust retention policies, and documented opt‑out/erasure pathways if your AI assistants touch customer or employee data. ([ico.org.uk](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/?q=420&utm_source=openai))
Question 4: How will the solution align with the EU AI Act if you serve EEA customers, and what’s the plan for transition dates? Even London‑based firms frequently operate in or sell to the EU. The Act entered into force on 1 August 2024 with phased application through 2026–2027; obligations for general‑purpose AI and most governance provisions phase in during 2025–2026, with some high‑risk provisions extending to 2027. Ask agencies to classify use cases, plan for transparency duties (e.g., chatbot disclosures), and monitor harmonised standards as they emerge. ([digital-strategy.ec.europa.eu](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai?utm_source=openai))
Security by design: threat modelling, controls and testing
Question 5: What AI‑specific security practices does the agency follow, and can they evidence them in proposals and code? Look for alignment with joint guidance from the UK NCSC and international partners covering secure design, development, deployment, and operation (including model/plug‑in supply chain risk, secrets management, and incident response). You want to see concrete artefacts: threat models for LLM‑enabled workflows, red‑team test plans, logging strategies that avoid leaking sensitive prompts, and procedures for model rollback. ([cisa.gov](https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development?utm_source=openai))
Go further than generic cyber controls. For AI assistants and chatbots, ask how the build mitigates prompt injection, training‑data poisoning, insecure output handling, excessive tool permissions, and model theft—risks catalogued in the OWASP Top 10 for LLM Applications. Agencies should demonstrate sandboxing of tools, output validation for actions (especially where the bot writes to CRMs or payment systems), guardrail policies, and safe‑prompt patterns embedded in code reviews. ([owasp.org](https://owasp.org/www-project-top-10-for-large-language-model-applications/?utm_source=openai))
Architecture, model choice and portability (avoid lock‑in)
Question 6: How will the agency choose and justify models—and how easily can you switch later? Ask for evaluation results on your data (latency, quality, safety) and a portability plan across API‑hosted and self‑hosted options. Use a retrieval‑augmented pattern to keep proprietary context outside the model where feasible, and insist on abstraction in the orchestration layer so swapping models doesn’t break downstream processes. ISO/IEC 42001 (the AI management system standard) provides a governance backbone for model selection, risk controls, and continuous improvement; agencies that align to it—or can show equivalent policy/process maturity—generally make fewer design mistakes. ([iso.org](https://www.iso.org/standard/42001?utm_source=openai))
Competition concerns around foundation‑model ecosystems are real. The UK’s Competition and Markets Authority has outlined principles aimed at preserving access, choice, and interoperability. When you review proposals, probe how the design supports model plurality (mix‑and‑match), avoids closed extensions that trap your data or prompts, and maintains exit rights (code escrow, data export, and clear instructions to re‑deploy on alternative providers). ([gov.uk](https://www.gov.uk/government/publications/ai-foundation-models-initial-report?utm_source=openai))
Integration, operations and change management
Question 7: How will the solution integrate with your stack and operating model—safely? For most firms in London, that means Microsoft 365, Teams, Slack, HubSpot/Salesforce, or sector‑specific systems. Demand an integration plan covering authentication patterns (e.g., OAuth with least privilege), event logging to your SIEM, and safe‑actions design (human approval steps where the assistant writes back to systems of record). The UK government’s Technology Code of Practice is a helpful lens for procurement and technical assurance—covering open standards, security, privacy‑by‑design, and purchasing strategy—so ask vendors to map their approach to those criteria. ([gov.uk](https://www.gov.uk/guidance/the-technology-code-of-practice?utm_source=openai))
Operationally, expect a runbook: monitoring dashboards (quality, latency, costs), incident playbooks for degraded model responses, bias/safety regression checks, data drift alerts, and a cadence for prompt and retrieval‑index updates. Agencies delivering AI chatbot development in the UK should also include a human‑in‑the‑loop plan for sensitive intents, plus training and comms materials for front‑line teams so adoption sticks rather than stalls after launch. Where responsibilities are split (your IT, the model provider, and the agency), lines of ownership must be explicit.
Commercials, IP, and delivery assurance
Question 8: Who owns what—code, prompts, fine‑tuned weights, datasets, and evaluators—and how will third‑party terms affect you? Seek IP clauses that give you rights to redeploy in other environments and to continue use if the relationship ends. Require transparency on model/provider terms (e.g., whether your prompts/completions are retained for provider training) and insist that the agency configures non‑training modes where available for business process automation in regulated contexts. Tie this to privacy commitments made in your DPA and the ICO’s expectations for accountability and documentation. ([ico.org.uk](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/?q=420&utm_source=openai))
Question 9: What does the delivery plan look like in practice? Request a milestone‑based statement of work with a discovery phase, a build for a single high‑value workflow, and a time‑boxed pilot in production with explicit accept/reject criteria. Insist on show‑your‑work artefacts: evaluation harnesses, prompt/version control, test data sets, and cost/performance dashboards you can keep. Security and deployment guidance from NCSC and partners can be used as acceptance criteria—for example, evidence of threat modelling, secure deployment controls, and post‑deployment monitoring specific to AI systems. ([cisa.gov](https://www.cisa.gov/news-events/alerts/2024/04/15/joint-guidance-deploying-ai-systems-securely?utm_source=openai))