All insights
EN · AI Strategy & Transformation

How to write an RFP for AI services: requirements and scorecard

A strong AI-services RFP compares evidence, risk and operational readiness—not technology labels, polished demos or vendor promises.

To write an RFP for AI services, define the business decision or operating outcome that must improve, the data and boundaries of the engagement, how the system will be tested, and who will be accountable in production. Require every bidder to submit the same evidence. Apply non-negotiable security, privacy and control gates first; then use a weighted matrix to compare delivery capability rather than sales language or demos.

This structure matters because AI proposals are often unlike by design. One firm sells discovery, another promises a ready-made agent, and a third leads with a platform. An RFP that prescribes a model, vendor or abstract feature list too early can eliminate better approaches before evaluation begins. UK Government procurement guidance offers a useful principle: begin with the problem, support iterative delivery, involve multidisciplinary expertise, and address black boxes and unnecessary vendor lock-in.

The Decision-to-Operation RFP

MAKINAI organizes the procurement decision around six gates. A vendor should not advance merely because its aggregate score is high; it must show that the proposed solution can pass each gate. The point is not to add procurement theater. It is to connect an AI promise to a measurable decision, a maintainable architecture and an operating system with clear accountability.

  • 1. Outcome and decision: which behavior, cycle time, revenue, cost, risk or quality measure should change, and for whom?
  • 2. Data and architecture: which sources, integrations, permissions, models and dependencies make the solution possible?
  • 3. Evaluation and acceptance: which tests, reference sets, metrics and thresholds determine whether it works?
  • 4. Risk and governance: who approves, monitors, intervenes, investigates incidents and remains accountable?
  • 5. Adoption and operations: how will people, process, support, observability and continual improvement work?
  • 6. Commercials, transfer and exit: what is total cost, what belongs to the buyer, and how can the buyer change vendors without losing the system?

The NIST AI Risk Management Framework helps turn the fourth gate into concrete work because it treats trustworthiness as part of AI design, development, use and evaluation. NIST's Generative AI Profile adds risks and actions specific to generative systems. ISO/IEC 42001 provides a management-system reference spanning policies, processes and continual improvement. These sources do not replace your legal, security or privacy review, but they make requirements and vendor answers more precise.

The 12 requirements every bid should answer

Start with the problem and baseline. State the current workflow, affected users, approximate volume, decision being supported and cost of error. Separate in-scope and out-of-scope work. Instead of requesting “an AI chatbot,” ask for a reliable way to reduce the time needed for a task or improve a decision within stated constraints. Let bidders propose technology, architecture and delivery sequence, but require them to disclose assumptions and dependencies.

Next, define data and integrations: source systems, known quality issues, classification, residency, retention, access rules and owners. Request a proposed architecture diagram plus a list of external services, models, libraries and components that may affect cost or continuity. Ask for fallback options if a model, cloud service or license becomes unavailable. This section quickly reveals whether a bid was designed for your operating context or adapted from a generic capabilities deck.

Define evaluation and acceptance before development. Each proposal should include outcome metrics, quality criteria, adverse scenarios, a sampling method, validation owners and conditions to stop, repair or expand. For an agent, pleasant answers are not enough: evaluate unauthorized actions, tool use, human escalation, traceability and autonomy boundaries. For automation, measure exceptions and rework, not only execution rate. Require the bidder to explain how evaluation continues after launch as data, prompts, models and user behavior change.

Make security, privacy and governance architectural requirements. Ask for an initial risk register, data flow, access controls, logs, incident response, handling of sensitive content and assignment of roles. The OWASP risks for LLM applications—including prompt injection, sensitive information disclosure, excessive agency, improper output handling and unbounded consumption—are a useful starting point for technical questions. A bidder should describe controls and residual risk, not merely assert that the system is secure.

Close with delivery, operations and commercial terms. Request evidence-producing milestones, responsibilities for buyer and vendor, named team members and availability, an adoption plan, documentation, monitoring, support and an update process. Ask for phase-level pricing and assumptions for usage, licenses, infrastructure, support and change requests. Define intellectual property, rights to data and artifacts, portability, code access where appropriate, transfer documentation and exit assistance.

A 100-point matrix: score evidence, not adjectives

MAKINAI's starting allocation is: outcome and problem understanding, 20 points; data and architecture, 15; evaluation and acceptance, 20; governance, privacy and security, 15; delivery, adoption and operations, 15; and commercial model, transfer and exit, 15. These weights are not an industry standard. Adjust them to the use case and risk before releasing the RFP, then disclose the rules equally to all participants.

Within each dimension, assign a rating from zero to five and multiply by the weight. Zero means absent; one, an assertion without evidence; two, a generic approach; three, evidence suited to the context; four, strong evidence with explicit trade-offs; and five, verifiable evidence, clear ownership and a contingency plan. Require attachments such as proposed team composition, an architecture sketch, a sample evaluation plan, an initial risk register, the operating model, a pricing workbook and a list of transferable artifacts.

Calculate the total only after stop rules. Disqualify a proposal that will not meet indispensable privacy requirements, does not identify critical subcontractors, prevents data export, cannot log consequential actions, or makes continuity depend on components with no reasonable substitute. An attractive price or impressive demonstration should not compensate for a condition that makes the system unsafe, unaccountable or impossible to operate. Document exceptions explicitly rather than hiding them in a weighted average.

How to run the selection

Before issuing the RFP, run a noncommittal market conversation to test whether the problem is stated neutrally. After written responses, hold an evidence session using the same agenda for each bidder. Use synthetic or approved data, and ask the people who would actually deliver the work to explain architecture, evaluation and risk. Check provided references, validate conflicts, and negotiate a phased statement of work with explicit gates to stop, repair or scale.

Red flags include guaranteed accuracy or returns without a test set; security described only through the platform's certifications; pricing that excludes inference, infrastructure and operations; dependence on a single “star” practitioner; no transfer plan; a pilot with no production path; and pressure to select a model before understanding data and workflow. Treat generic statements about human review with caution unless the proposal specifies authority, capacity, response time and the consequences of intervention.

A strong RFP cannot choose the right partner automatically. It creates the conditions for a defensible decision and reduces surprises between prototype and operation. Use this structure to collect comparable bids, then combine it with MAKINAI's 30-point scorecard for selecting an AI implementation company during final evaluation. If your organization needs to turn an opportunity into a vendor-neutral brief, RFP, evaluation plan and investment gates, MAKINAI can structure that process before the implementation contract is awarded.

Sources and references

  1. Guidelines for AI procurement · UK Government

    Advises buyers to start with the problem, support iterative delivery, use multidisciplinary evaluation and address black boxes and vendor lock-in.

    2026-08-16
  2. Artificial Intelligence Risk Management Framework (AI RMF 1.0) · NIST

    Provides a voluntary, use-case-agnostic framework for incorporating trustworthiness into AI design, development, use and evaluation.

    2026-08-16
  3. Artificial Intelligence Risk Management Framework: Generative AI Profile · NIST

    Adds generative-AI-specific risk considerations and actions to the AI RMF.

    2026-08-16
  4. ISO/IEC 42001:2023 AI management systems · ISO

    Specifies requirements for an AI management system, including policies, processes, risks, opportunities and continual improvement.

    2026-08-16
  5. OWASP Top 10 for Large Language Model Applications 2025 · OWASP GenAI Security Project

    Organizes risks for LLM applications, including prompt injection, sensitive information disclosure, excessive agency and unbounded consumption.

    2026-08-16
Making connections

Continue exploring

AI Strategy & Transformation

How to define AI provider governance and performance management before hiring

Read insight
AI Strategy & Transformation

How to evaluate an AI consulting ROI business case before hiring

Read insight
AI Strategy & Transformation

Boutique AI firm, global consultancy, or systems integrator: how to choose

Read insight
Related capability

AI strategy & transformation

An AI transformation consultancy should answer four questions before recommending technology: where business value exists, which capabilities and data are required, how risk will be controlled, and who will operate the change. MAKINAI connects those answers in an executable plan with priorities, owners, metrics and scale decisions.

Explore this capability