Procurement / Vendor governance
AI Vendor Due Diligence for Data Center Operators
Before an AI product receives facility telemetry—or permission to change a physical setpoint—procurement needs evidence that the product can be operated, constrained and exited safely.
Sections in this article
Can your team explain exactly what the supplier reads, what it can change, how the model is tested, and how operations continue if the contract or connection ends? If any answer depends on a sales demonstration alone, the procurement review is incomplete.
An AI cooling optimizer and an AI assistant that summarizes maintenance tickets are not equivalent purchases. One may need only access to a ticketing API; the other may request data from building management systems (BMS) and, eventually, permission to change mechanical plant settings. A vendor review should begin with that distinction.
The aim is not to demand a perfect model. It is to obtain enough evidence to judge whether its failure modes, dependencies and contractual boundaries are acceptable for the facility. NIST’s AI Risk Management Framework includes third-party and supply-chain risks as part of AI governance; NIST’s OT guidance adds the safety and availability considerations specific to industrial systems.
Define the system and its authority before reviewing the vendor
Ask the supplier to provide a diagram showing the data sources, processing locations, external dependencies and permitted outputs. Identify whether the deployment is read-only analytics, operator-approved recommendations or bounded automation. Write the approved use case into the purchase specification, rather than relying on broad descriptions such as “AI-powered facility optimization.”
| Question | Evidence to request | What it tells the buyer |
|---|---|---|
| Where is inference performed? | Architecture diagram, hosting regions, dependencies. | Whether facility data leaves the OT environment and what outages might affect the service. |
| What can it modify? | Read/write permissions, supported commands, BMS integration specification. | The physical scope of the vendor's authority. |
| What happens when inputs fail? | Missing-data handling, error cases, acceptance tests. | Whether unreliable telemetry can become unsafe recommendations. |
| Who approves model changes? | Release notes, version controls and customer notification policy. | Whether updates can alter behavior without an approved change. |
Verify the technical claims on the actual facility
Performance claims need a measurement boundary
A promise to “reduce cooling energy by 20%” is not a site-specific business case. Ask which equipment was measured, over what period, under which IT loads and weather conditions, and what happened to reliability metrics. Require a proposed baseline and independent way to check results. A strong supplier can discuss uncertainty and circumstances where its model performs poorly.
Demonstrate constrained operation
For products with control authority, request a test showing what occurs when an optimization recommendation conflicts with approved equipment limits. Independent controller interlocks, approved command ranges and a tested transition back to normal operation matter more than an attractive dashboard. The precise architecture must be validated by the facility engineering team—not copied from a generic reference design.
Check lifecycle support, not just the initial model
Ask how the vendor handles replaced chillers, recalibrated sensors, seasonal operating changes and new rack densities. Model drift and changing input distributions are distinct from software defects; both can undermine the original acceptance test. Demand a named escalation route, monitoring criteria and an agreed process for revalidating significant changes.
A supplier demonstrates a useful anomaly-detection model but requires unrestricted write access to the entire BMS network. The engineering team may still pilot the analytics function through a restricted, read-only interface. Production control access should not be approved until an independently reviewed architecture restricts commands to authorized devices and setpoints.
Review cybersecurity, data use and subcontractors together
OT integration creates different risks from ordinary SaaS procurement. Request an asset and data-flow map, identity and privileged-access design, remote-support procedure, vulnerability disclosure process and incident response responsibilities. NIST SP 800-82 provides a framework for network separation and assessing OT security without ignoring operational availability.
- Data boundaries: identify telemetry, identifiers, maintenance records and any personal information transferred to the supplier.
- Training and reuse: verify whether customer data may be used to improve shared models; check the actual contract and product settings.
- Access: apply unique identities, minimum permissions, revocation and logging for vendor personnel and service accounts.
- Subprocessors: document relevant hosting, inference, support and analytics providers; define notification of material changes.
- Security evidence: request independent testing evidence, vulnerability management and a software component inventory when appropriate.
Do not assume every vendor must provide a data diode or that a paid enterprise subscription automatically guarantees confidentiality. Controls should be selected according to the actual threat model, architecture and contract. Any AI Act or privacy-law classification also requires assessment of the system's actual role and purpose; the technology label alone does not establish a legal category.
Translate operating assumptions into contract terms
Service levels should address the right failure scenarios: unavailable inference, degraded data feeds, unannounced model changes, delayed security patches and loss of vendor connectivity. Specify incident contact times, support escalation, access revocation and what happens if a supplier is acquired or ends the product.
A viable exit plan identifies which logs, configuration records, integration documentation and customer data can be exported, and when they are deleted. Where the AI system interacts with physical controls, the operator must retain an independently verified way to run the facility without the vendor. Commercial remedies and liability caps need legal review in light of the site's actual exposure; a standard uptime credit is not a substitute for engineering resilience.
A short vendor evaluation scorecard
| Review area | Minimum decision evidence | Owner |
|---|---|---|
| Operational scope | Approved use case and access diagram. | Facilities engineering |
| Model performance | Representative acceptance tests and monitoring plan. | Engineering / data team |
| OT security | Network paths, credentials, permissions and incident plan. | OT security |
| Data handling | Data map, retention, reuse and subcontractor terms. | Security / privacy |
| Changes and exit | Version notice, rollback and termination plan. | Operations / procurement |
| Contractual risk | Support, service levels, liability and audit clauses. | Legal / procurement |
Before signing: document unresolved exceptions and who accepted them. A “pass” should mean that evidence was reviewed against the site's own criteria—not that a vendor claimed alignment with an abstract industry standard.
Procurement succeeds when the product can be deployed safely, monitored in service and removed without surprises. The first contract review is also the first entry in the facility's ongoing AI system inventory.
Sources and further reading
Primary frameworks and reference materials. Engineering decisions require site-specific validation; legal classifications require assessment of the actual use case.