GPU Cloud RFP Template: AI Infrastructure Requirements
Paste-ready GPU cloud requirements (capacity commitments, cluster networking, storage, scheduling, isolation, inference, pricing), vendor questions that separate providers, and a scoring rubric.
Paste-ready requirements for data labeling software and managed labeling services: annotation types, quality control, model-assisted labeling, LLM data, security and pricing.

See the structure before you download. The Word file has every section listed below, ready to fill in.
The sections in the document, in order.
Use this data labeling RFP template when you're choosing an annotation platform, a managed labeling service, or both, to produce training and evaluation data for machine learning and generative AI models.
It's written for the ML, data and procurement team running the evaluation, and it covers the whole process: when to issue an RFI first, the requirements to send for each data type, the quality controls to insist on, the questions that separate vendors, and how to score the answers.
Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.
A data labeling evaluation is mostly about your data: what types you have, how much, how sensitive it is, and how precisely the labels are defined. Settle those first, then make vendors prove themselves on a sample of it. The example schedule below runs about 11 weeks from kickoff to contract award; add time if an external workforce needs a security review.
Data labeling purchases come in three shapes. With software only, you license a platform and your own staff or contractors do the labeling. With managed services, a vendor supplies the annotators, project management and quality checks, usually on its own platform, and you pay for labeled output or annotator time. Many buyers need both: a platform they control, plus workforce capacity from the same vendor or a separate one.
Your RFP should say which you're buying, because it changes the requirements, the pricing table and the scoring. This template works for all three. Lines that start with 'Managed services:' apply only when the vendor supplies the workforce; delete them for a software-only purchase. If you buy the platform and the workforce from different vendors, require the workforce provider to work in your platform, so you keep the ontology, labels and quality history if you change providers.
Questions that help you decide:
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
| ID | Requirement | Priority |
|---|---|---|
| F1 | Labeling of images, video, text, audio and documents (PDF and scanned pages) in one platform, with the same workflow, review and quality features across them. State any data type that needs a separate product or add-on, and support for specialized formats we use, such as [DICOM medical images, multi-page TIFF, geospatial imagery]. | Must-have |
| F2 | 3D point cloud and LiDAR annotation, including cuboids, point-level segmentation and object tracking across frames, with synchronized camera views. | Nice-to-have |
| F3 | Image annotation with classification, bounding boxes, rotated boxes, polygons, polylines, keypoints and skeletons, and pixel-level semantic and instance segmentation. | Must-have |
| F4 | Video annotation with object tracking across frames using persistent object IDs, interpolation between keyframes, and labels at frame, segment and whole-video level. State the maximum video length, resolution and frame rate supported. | Must-have |
| F5 | Text and document annotation: classification, entity spans, relationships between entities, and labeling of regions and fields on document pages with the extracted text visible to annotators. State supported languages and scripts, including right-to-left. | Must-have |
| F6 | Audio annotation: transcription, time-stamped segments, speaker labels and sound-event tags, with a waveform or spectrogram view and playback speed control. | Must-have |
| F7 | Ontology (taxonomy) management: hierarchical classes, nested and conditional attributes, required fields and validation rules. Ontologies are versioned and reusable across projects, and the platform shows which existing labels are affected when an ontology changes. | Must-have |
| F8 | Configurable workflows with multiple labeling and review stages, review queues by reviewer or skill, and routing rules (for example, send items with annotator disagreement or low model confidence to expert review). | Must-have |
| F9 | Consensus labeling: a configurable number of annotators per item, for all items or a sample, with automatic agreement scoring and an adjudication step for disagreements. | Must-have |
| F10 | Gold sets: items with known correct answers mixed into annotators' queues without being identifiable, used to score each annotator's accuracy over time and to qualify new annotators. | Must-have |
| F11 | Quality metrics measured and reported by the platform: inter-annotator agreement by class, attribute and annotator (state the measures used, such as intersection over union for shapes and Cohen's or Fleiss' kappa for categories), accuracy against gold sets, and review rejection rates. | Must-have |
| F12 | Model-assisted pre-labeling: import predictions from our own models, or run models the vendor provides, so annotators correct labels rather than start from scratch. Each label records whether it came from a model, which model version, and its confidence score. | Must-have |
| F13 | AI-assisted tools inside the editor, such as segmentation from a click or box prompt, automatic object tracking in video, and suggested labels for text, with every suggestion confirmed or corrected by a person. | Nice-to-have |
| F14 | Active learning and data curation: queue prioritization by model uncertainty or other scores we supply, plus search by metadata and by visual or text similarity to find edge cases, near-duplicates and under-represented classes. | Nice-to-have |
| F15 | Labeling for large language models: pairwise and ranked comparison of model responses (preference data), writing and editing prompt-response pairs for fine-tuning, and review of multi-turn conversations. Make this Must-have if you build or tune generative AI models. | Nice-to-have |
| F16 | Model evaluation and red-teaming tasks: grading model outputs against a rubric, side-by-side comparison of model versions, and recording adversarial prompts with harm category and severity, exportable as reusable evaluation sets. | Nice-to-have |
| F17 | Workforce management: roles (annotator, reviewer, project manager, administrator), task assignment by skill, language or qualification result, and per-annotator dashboards for throughput, time spent and quality. This applies to our own staff and to any external labeling vendor working in the platform. | Must-have |
| F18 | Managed services: a vendor-supplied annotation workforce with the domain and language expertise we specify, qualification testing against our guidelines before anyone works on production data, and the ability to scale capacity up or down with [notice period]. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | Browser-based annotation with no local install for annotators, configurable keyboard shortcuts, and stated minimum hardware and bandwidth for video and 3D work. State the interface's conformance with WCAG 2.1 AA or later. | Must-have |
| T2 | Connection to our cloud object storage [name provider] that reads files in place using delegated, revocable access (for example, a cross-account role or time-limited signed URLs) and picks up new files automatically. State what the platform copies or caches, such as thumbnails, video frames or embeddings, and for how long. | Must-have |
| T3 | Deployment in our own cloud account (VPC) or on-premises, for data that cannot leave our environment. List any features that are unavailable or delayed in that deployment. Make this Must-have if your data can't be processed in a vendor-hosted service. | Nice-to-have |
| T4 | Performance at our scale: [number] items per project, files up to [size or duration], and [number] concurrent annotators without slowing the editor. State the limits you have tested. | Must-have |
| T5 | Versioned label snapshots tied to the ontology version, so we can reproduce exactly which labels trained or evaluated a given model. | Must-have |
| T6 | A full history for every item: who labeled, reviewed and changed it, when, and whether each label came from a person or a model. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| I1 | A Python SDK and a documented API covering data import, project and ontology setup, task assignment, label export and quality metrics, with versioned endpoints and published rate limits. | Must-have |
| I2 | Export in standard formats, including COCO JSON and Pascal VOC for computer vision, JSONL for text and LLM data, and CSV, plus a documented native format that keeps all attributes, review history and ontology versions. List every supported format, and confirm support for [the formats our training pipeline uses]. | Must-have |
| I3 | Import of existing labels and model predictions in standard formats, so labels from our current tool [name] carry over with their classes and attributes. | Must-have |
| I4 | Webhooks or event notifications (for example, batch completed, review finished, export ready) to trigger our data and training pipelines. | Must-have |
| I5 | Integration with our MLOps and data platforms [list them], such as pulling dataset versions into training jobs and sending model predictions back for review. | Nice-to-have |
| I6 | Single sign-on for internal users and external annotators via SAML 2.0 or OIDC, with user provisioning and deprovisioning via SCIM. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| S1 | A current SOC 2 Type II report and ISO/IEC 27001 certification covering the platform and, for managed services, the labeling operations, available under NDA. | Must-have |
| S2 | Encryption in transit and at rest, isolation of our data from other customers, and a documented key-management approach. State whether customer-managed encryption keys are supported. | Must-have |
| S3 | Storage and processing of our data, including backups, in [regions]. State the countries from which support staff and annotators can access it. | Must-have |
| S4 | Detection and redaction of personal data before items reach annotators, such as masking names and identifiers in text and documents, and blurring faces or license plates in images and video. | Nice-to-have |
| S5 | Annotator access limited to assigned items, with no bulk download of source data, and optional restriction of access by IP address range or network. | Must-have |
| S6 | Administrator access through SSO with MFA, role-based permissions at workspace and project level, and an exportable audit log of data access and configuration changes. | Must-have |
| S7 | A contractual commitment that our data, labels and annotator output are not used to train the vendor's models or shared with other customers without our written consent. | Must-have |
| S8 | A data processing agreement, a current list of sub-processors (including any labeling subcontractors), support for our privacy obligations (for example, GDPR), and a defined time limit for notifying us of security incidents affecting our data. State the time. | Must-have |
| S9 | Willingness to sign a HIPAA business associate agreement. Make this Must-have if you label protected health information. | Nice-to-have |
| S10 | Managed services: background checks and confidentiality agreements for every annotator on our work, controls on personal devices and work locations, and the option of a dedicated team that works only on our projects. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | An onboarding plan covering storage connection, SSO, ontology and workflow setup, and migration of existing labels, with named roles and the effort expected from both sides. | Must-have |
| M2 | Help turning our labeling guidelines into in-tool instructions with examples, and a calibration round on a sample before production volumes start. | Must-have |
| M3 | Managed services: committed throughput and turnaround time per batch, and a quality target measured against our gold set, with rework at no charge for batches that miss it. State your proposed targets. | Must-have |
| M4 | Managed services: a named project manager, weekly reporting on throughput and quality, and a documented process for escalating unclear items to our team and sharing the answers with all annotators. | Must-have |
| M5 | A service-level agreement for platform availability, with service credits. State how availability is measured. | Must-have |
| M6 | Support with response-time targets by severity. State your targets, support hours and channels. | Must-have |
| M7 | Advance notice of changes to annotation tools, export formats or the API that could affect our pipelines, with a deprecation period for retired API versions. | Must-have |
| M8 | Training and documentation for administrators, reviewers and annotators, including material we can reuse to onboard new annotators. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by component: platform subscription, any usage charges (data volume, storage, or compute for model-assisted labeling) and managed labeling services. Show the metric, list price, discount and net price for each. | Must-have |
| C2 | Seat definitions: which roles (annotator, reviewer, administrator, viewer) need paid seats, whether seats can be reassigned, and pricing for short-term annotators. | Must-have |
| C3 | Managed services: the billable unit (per label, per item, per task or per annotator hour), how complexity changes the price (for example, objects per image, shape type, or minutes of audio or video), and, for hourly pricing, the rate by skill level and location and how time is measured and reported. | Must-have |
| C4 | A cap on price increases at renewal, and the terms that apply if we exceed licensed seats or usage limits. State the cap. | Must-have |
| C5 | A pilot on our own data, at no charge or with the fee credited against the contract, with success criteria agreed in advance. | Nice-to-have |
| C6 | Exit terms: export of all data, labels, ontologies, review history and quality metrics in documented formats at any time and at contract end, at no extra charge. | Must-have |
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Annotation tools and data-type coverage | 15% | Every Must-have data and annotation type shown working on your own sample data, in a generally available release. |
| Quality control and measurement | 20% | Consensus, gold sets and review queues that are easy to configure, and agreement metrics reported by class and annotator, not just overall. |
| Model-assisted labeling and automation | 15% | Pre-labeling with your own models, label provenance recorded, and time saved in the pilot without a drop in measured quality. |
| Workforce management and managed services | 10% | Clear task assignment and per-annotator reporting; for managed services, vetted annotators with the right expertise, committed throughput and a quality guarantee backed by rework. |
| Security, privacy and deployment | 15% | Data read in place or kept in approved regions, tight annotator access controls, no training on your data, and a deployment option that matches its sensitivity. |
| Integration, SDK and export | 10% | A usable SDK and API, standard export formats, and versioned datasets that load into your training pipeline without conversion work. |
| Implementation and support | 5% | A realistic onboarding plan, practical help turning guidelines into instructions, and clear support targets. |
| Commercials and total cost | 10% | Clear unit definitions, quotes on the same volume assumptions, a renewal cap and free export at exit, over a three-year view. |
| Total | 100% |
Scoring scale
Your data types, volumes and sensitivity; the annotation types and a draft ontology; requirements for quality control, model-assisted labeling, workforce management, security, integration and export formats, each marked Must-have or Nice-to-have; whether you're buying software, managed labeling services or both; a pricing table that fits your pricing model; and the rubric you'll score with. Attach a de-identified sample dataset and your labeling guidelines so vendors can price and pilot accurately.
Data labeling software is the platform where annotation, review and quality measurement happen; your own team or contractors do the work. A data labeling service, often called managed labeling, supplies the annotators, project management and quality checks, and charges for labeled output or annotator time. Many vendors offer both. If you buy them separately, require the service provider to work in your platform so you keep the labels and quality history when you change providers.
Software is usually priced per seat, often with different rates for annotators, reviewers and administrators, or by usage such as data volume or compute for model-assisted labeling. Managed services are priced per label, per item or task, or per annotator hour, with rates that rise with complexity and expertise. Ask every vendor to price the same volume assumptions and to define exactly what counts as a billable unit, or the quotes won't be comparable.
Use three measures together: accuracy against a gold set of items with known answers, inter-annotator agreement on items labeled by more than one person, and the rate at which reviewers reject or correct labels. Set the target and the measurement method in the RFP, and require the platform to report these measures by class and by annotator. For managed services, tie acceptance and rework to the same measures.
The example schedule in this template runs about 11 weeks from kickoff to contract award, including three weeks for vendor responses and three weeks for a pilot batch on your own data. Allow longer if an external workforce needs a security review, if you run an RFI first, or if your labeling guidelines aren't written yet.
Paste-ready GPU cloud requirements (capacity commitments, cluster networking, storage, scheduling, isolation, inference, pricing), vendor questions that separate providers, and a scoring rubric.
Paste-ready LLM gateway requirements (routing and fallback, per-team keys, budgets, caching, logging, guardrails, data residency), vendor questions that separate platforms, and a…
Paste-ready AI governance platform requirements (AI inventory, risk assessments, framework mapping, model documentation, testing evidence, vendor AI risk), vendor questions and a…
Please provide your feedback below.
"*" indicates required fields