Quick Answer: A request for proposal (RFP) for AI-ready colocation must go beyond the standard template. Unlike a traditional data centre RFP, it needs to address sustained power density, AI-specific cooling architectures, low-latency interconnection, and, for Canadian buyers, explicit questions about corporate ownership and data sovereignty jurisdiction. This article walks through every section your RFP needs to cover and the reasoning behind each one.
Your procurement team is probably sending out colocation RFPs right now using a template that was built before AI infrastructure was a real use case.
That template asks about square footage, redundancy tiers, and uptime SLAs, and it will get you responses. What it will not do is separate a facility purpose-built for high-density AI workloads from one that is retrofitting a decade-old data hall with a few extra cooling units and a new marketing page.
The colocation market has changed faster than most procurement processes have kept up with. JLL’s research shows that North American vacancy sits at a record low of 1% for the third consecutive year, with 92% of capacity currently under construction already pre-committed before a single cabinet is installed.
Competition for quality space is real, and providers know that a generic RFP rarely forces them to distinguish their actual capabilities from a competitor's talking points.
Getting specific in your RFP is the only reliable way to tell the difference. For Canadian enterprises, that specificity includes a layer most global templates skip entirely: who owns the company, which laws govern your data, and whether a foreign-parented provider can be compelled to produce it without notifying you.
The standard data centre RFP was shaped by a decade where 4-8 kilowatts per rack was the norm and procurement was mostly about square footage and connectivity. Most templates in circulation today still reflect that era, which means the gap between what a generic RFP asks and what AI workloads actually need is wide enough to produce a bad shortlist on a good budget.
AI infrastructure procurement is a different conversation, and that difference starts with the infrastructure requirements themselves. Before getting into what your RFP sections need to cover, it is worth establishing exactly why the old questions no longer produce useful answers.
Most data centre RFPs cover the right categories at the wrong level of specificity. They ask whether a provider supports high-density power without defining what high-density means in kilowatts.
They ask about cooling without distinguishing between room-based HVAC and rack-level thermal management. They request SLAs without specifying how those SLAs perform under continuous GPU load rather than averaged draw across a mixed-use data hall.
The result is that nearly every provider checks the same boxes. Procurement teams then make decisions based on price or familiarity rather than infrastructure capability. A properly scoped RFP changes that by forcing responses that are technically specific enough to compare side by side.
AI inference workloads, which serve real-time AI responses to end users, have become the fastest-growing category of enterprise AI deployment. Unlike large-scale training clusters, inference runs at lower rack densities, typically 10-20 kW, putting it within reach of a broader range of colocation environments. That accessibility does not mean every facility claiming AI-readiness can support these workloads reliably.
The critical factor is sustained load.
A single NVIDIA H100 GPU draws roughly 700 watts under full operation, and a server carrying eight of those GPUs pulls more than 5.5 kW from the rack before accounting for memory, storage, and networking overhead. An inference cluster running that hardware continuously is not a spiky or intermittent workload. It is a constant thermal and electrical demand that older data halls were not engineered to absorb at scale.
Here’s a comparison that shows how power consumption has increased over the years.
The Nvidia H100 SXM, which is a commonly used GPU for AI use cases, sits at 700W at peak load. This number is 125W more than the highest-tier consumer GPU, the RTX 5090.
If we compare the H1000 SXM’s power draw with old, data centre grade GPUs, it further emphasizes the need for updated RFPs.
The Nvidia A100 80GB SXM from 2020 has a max TDP of 400W, substantially lower than what we have right now. Similarly, the Tesla V100 SXM2 from 2017 has a max TDP of 300W, which is less than half the power draw of a modern H100 SXM.
This is the section most buyers try to shortcut by downloading a generic template and adding a line or two about GPU support. That tends to produce vague vendor responses and weak shortlists because it gives providers room to interpret requirements in whatever way flatters them most. Here are four areas where your RFP needs specific, technical language, and what answers you are actually trying to surface in each one.
The first question most buyers ask about power is how many kilowatts per rack a provider can support. That is a reasonable starting point, but the follow-up matters far more: can the provider sustain that density continuously, across multiple adjacent cabinets, without hot spots, throttling, or special arrangements?
If the answer to that question comes with qualifiers or workarounds, the facility was likely not built for AI workloads from the ground up.
Your RFP should require vendors to specify:
Also ask whether power pricing is all-inclusive or metered separately. AI workloads draw at or near full capacity for extended periods, and metered power pricing can produce significant cost surprises once the deployment is live.
Room-based HVAC was designed for environments where heat distributes relatively evenly across a data hall. GPU clusters generate intense, concentrated heat at the rack level, and increasing total airflow in a room designed decades ago does not solve that. The architecture of how heat is managed matters as much as the total cooling capacity stated on a spec sheet.
The right cooling architecture depends on your workload type, and your RFP should ask vendors to be specific about what is in place for high-density zones rather than letting them answer in generalities:
For most enterprise inference buyers, the key cooling questions are about containment quality and rear-door capacity, not liquid cooling.
Beyond architecture, ask for thermal SLA terms in writing: specific temperature and humidity guarantees, committed response times for cooling failures, and the penalty structure that applies to SLA breaches. Vendors that cannot answer these questions specifically are managing cooling reactively rather than by design.
AI inference requires low-latency connectivity back to end users, cloud platforms, and data sources. A facility's network fabric is therefore a core part of whether the deployment performs as intended, which is why high-availability connectivity should be treated as a primary selection criterion rather than a secondary one addressed late in the RFP process.
Your RFP should confirm:
Carrier-neutral facilities with purpose-built interconnection infrastructure give you the freedom to select and change network providers as requirements shift. For inference-heavy workloads, that flexibility carries direct cost and performance implications across the full contract term.
AI infrastructure requirements shift faster than most enterprise procurement cycles. A workload running at 15 kW per cabinet today may need 40 kW within two years as model complexity grows or inference volume increases. Contracts that do not account for that trajectory tend to produce expensive renegotiation conversations at exactly the moment when you are least prepared for them.
Ask vendors to address expansion rights within the same facility, the lead time and process for adding cabinet space or power capacity, and whether technology refresh clauses allow infrastructure upgrades without triggering a full contract reset.
Exit clauses with clearly stated penalty structures also matter. Signing a long-term colocation agreement without testing the provider's ability to scale with you is a procurement risk that only surfaces when you need to exercise the option and find out the answer is no.
|
RFP Section |
Key Question |
What a Credible Answer Looks Like |
|
Power Delivery |
Can you sustain X kW/cabinet continuously? |
Confirmed kW, no adjacency caveats, A+B feeds |
|
Cooling Architecture |
What system manages heat in high-density zones? |
Named Architecture: DLC, rear-door, cold aisle containment |
|
Thermal SLA |
What are temperature guarantees and breach penalties? |
Specific bounds, response times, stated penalty rates |
|
Network Fabric |
How many carriers terminate independently? |
Carrier-neutral, 15+ networks, isolated entry points |
|
Cloud Connectivity |
Which on-ramps are available and at what latency? |
Named on-ramps with documented latency figures |
|
Contract Flexibility |
What are the expansion and exit terms? |
Defined expansion rights, lead times, penalty structure |
The previous sections apply to any enterprise evaluating AI-ready colocation, regardless of geography. This section does not.
For Canadian businesses, and particularly for regulated industries in financial services, healthcare, and the public sector, the sovereignty layer of a colocation RFP carries as much weight as the technical specifications. In many cases, a facility that cannot satisfy it should not make the shortlist regardless of how strong its infrastructure specs are.
Most colocation buyers understand data residency: the physical location where data is stored. Far fewer build both residency and sovereignty into their RFP as separate, distinct requirements. Sovereignty goes further than residency. It concerns which legal jurisdiction governs that data, who can compel access to it, under what process, and with what notice to the organisation that owns it.
Data can be physically hosted in Canada and still be governed by foreign legal jurisdiction if the provider is incorporated under or controlled by a foreign parent company. As Capital Hill Group's analysis of Canadian data sovereignty confirms, foreign ownership can pierce Canadian hosting. Laws like the US CLOUD Act can reach data regardless of where it physically resides, provided it is stored by an American company. Physical address is not a sovereignty guarantee.
Your RFP should include separate questions for residency and sovereignty rather than treating them as one requirement. Ask where data is physically stored, but also ask for the provider's complete corporate ownership structure, country of incorporation at every entity level, and whether any parent or intermediate company is subject to US jurisdiction.
The Clarifying Lawful Overseas Use of Data Act, passed by the US Congress in 2018, authorises US authorities to compel American companies to produce data stored anywhere in the world, often without notifying the affected data owner. For Canadian enterprises housing sensitive or regulated workloads, this creates a structural exposure that physical data residency alone does not address.
The practical implication for RFP design is that corporate ownership should be a scored criterion rather than an assumed fact. A Canadian subsidiary of a US-parented company does not carry the same sovereignty posture as a Canadian-incorporated, Canadian-owned operator. Your RFP should require each vendor to disclose its full corporate ownership chain and confirm whether any entity in that chain is subject to CLOUD Act jurisdiction.
For organisations handling data under PIPEDA, OSFI guidelines, provincial health privacy legislation, or federal government data residency requirements, this portion of the RFP functions as a structural filter. Providers who cannot confirm Canadian ownership at every level in the chain should be scored accordingly.
A well-structured RFP only produces useful results if vendor responses are evaluated consistently. The discipline of improving the RFP process at the response stage means resisting the temptation to make decisions based on the most polished submission and instead scoring against the criteria you defined before responses arrived.
This is where many procurement teams lose ground they gained by writing a specific, technical RFP.
Whether you are running a formal data centre RFP or refining how to choose a data centre in Canada for your specific workload type, the scoring methodology below gives you a consistent baseline to work from.
Not all RFP criteria carry equal weight for AI workloads, and your scoring matrix should reflect that. Power delivery and thermal management tend to be the most operationally consequential factors for AI deployment success and should carry more weight than, for example, a provider's reference client list or the formatting quality of their proposal response.
A practical starting structure for most AI colocation evaluations:
These weights should shift based on your workload profile. Inference-heavy, latency-sensitive deployments should move interconnection weighting higher. Organisations in regulated sectors should increase compliance and sovereignty weighting accordingly.
The RFI vs. RFP distinction also matters here: if you conducted an earlier RFI process, you already have enough market context to weight criteria based on what you learned from provider conversations, rather than applying a generic default.
A well-scoped RFP also makes it easier to notice when something in a vendor response is missing or deliberately vague. Common warning signs worth flagging during evaluation:
A response that cannot answer specific, technical questions with specific, technical answers is telling you something. Vagueness in an RFP response tends to predict vagueness in the operational relationship once you are locked into a contract.
Canadian enterprises evaluating AI-ready colocation face a market where vacancy is near zero, AI-readiness is claimed by almost every provider, and the sovereignty implications of picking the wrong partner carry real regulatory and operational risk. Qu Data Centres is built specifically for this environment: a pure-play, Canadian-owned operator with 17 MW of available, powered capacity across five markets right now, not announced in three to five years.
Our locations span Toronto, Ottawa, Calgary, Edmonton, and London, Ontario, with carrier-neutral connectivity across 15+ networks and independent Uptime Institute Tier III certification at four facilities.
Whether your workload is inference-first, hybrid cloud, or backup and disaster recovery, Qu's managed services team provides 24/7 technical support within a fully Canadian jurisdiction. Our Ottawa data centre footprint is particularly well-positioned for federal government and regulated industry workloads requiring alignment with Treasury Board and OSFI requirements.
Book a facility tour and speak with the team that will be supporting your workloads. Seeing the infrastructure and asking your technical questions in person is the fastest way to know whether Qu belongs on your shortlist.
A request for information (RFI) gathers general market intelligence before requirements are finalised. A request for proposal (RFP) is issued once requirements are defined well enough to invite vendor solutions and compare them against each other. A request for quotation (RFQ) comes when specifications are fixed and price is the primary remaining variable. Colocation procurement typically moves through all three, with the RFP carrying the most evaluative weight and producing the shortlist.
AI inference workloads typically require 10-20 kW per rack, while training clusters can exceed 50-100 kW. Your RFP should require vendors to confirm sustained kilowatt capacity per cabinet, specify the power distribution architecture including A+B redundant feeds, and disclose whether high-density zones share electrical infrastructure with standard-density deployments. Sustained draw is the number that determines operational viability. Peak or theoretical specs are not the same thing.
Use a weighted evaluation matrix with power delivery and thermal management carrying the most weight, roughly 45-55% combined, since these factors most directly determine whether an AI deployment performs reliably. Network fabric, compliance posture, and contract flexibility should each account for 15-20% of remaining weight. Price should be evaluated in the context of what each vendor's infrastructure actually delivers, not as a standalone comparison.
At minimum, look for SOC 1 Type II, SOC 2, and ISO 27001. For financial services organisations, OSFI B-10 alignment and PCI DSS matter. For healthcare, HIPAA and PHIPA-aligned controls are relevant. Federal government procurement typically requires additional documentation aligned with the Treasury Board and Canadian Centre for Cyber Security assessment standards. Certifications should be confirmed at the specific facility level, not just at the company level, since portfolio certifications do not apply uniformly across all sites.
Not by itself. Data residency confirms where data is physically stored. Data sovereignty addresses which legal jurisdiction governs that data and who can compel access to it. A facility located in Canada but operated by a US-parented company may still be subject to US CLOUD Act access requirements regardless of data location. Canadian enterprises should require the provider's full corporate ownership chain in their RFP, not just the physical address of the proposed facility.