Scorecard de due diligence de IA (B2B): seguridad, derechos de datos y riesgo de entrega

Muchas organizaciones B2B siguen evaluando proveedores de IA como si compraran un SaaS más: demo, un par de referencias, cuestionario de seguridad y checklist de compras. Con GenAI y plataformas centradas en modelos, ese enfoque se rompe porque los principales riesgos no son “si funciona”, sino “qué pasa con nuestros datos, nuestras obligaciones y nuestros compromisos de servicio después de firmar”.

La due diligence de proveedores de IA se ha convertido en una decisión de riesgo operativo: determina lo rápido que puedes pasar de piloto a producción, lo defendibles que son tus compromisos con clientes y cuánto coste oculto absorbes por volatilidad de uso, control de cambios e integración. Si lo tratas como un trámite de compras, lo volverás a vivir como un incidente, un hallazgo de auditoría o un despliegue bloqueado.

Qué hace diferente el riesgo de proveedor en IA para B2B

En IA, el riesgo de proveedor se concentra en tres áreas que los procesos de compra tradicionales suelen infraestimar:

/
Derechos sobre datos y usos posteriores: qué puede hacer el proveedor con inputs, outputs, logs, embeddings, fine-tunes y telemetría—incluyendo usos internos y con terceros.
/
Seguridad en un sistema probabilístico: cambia la superficie de ataque (prompt injection, exfiltración vía tool calls, cadenas de plugins, riesgos de inversión de modelo) y exige controles más allá de los checkboxes típicos.
/
Riesgo de entrega y de cambio: actualizaciones de modelos, deprecaciones, cambios de precios por tokens, disponibilidad regional y rate limits pueden romper comportamientos en producción aunque el “uptime” parezca correcto.

Por eso el gobierno del proveedor externo debe conectarse con el gobierno interno de IA y con tu plan de escalado. Si internamente estás definiendo controles, aprobaciones y ownership del riesgo, la selección de proveedor tiene que integrarse en los mismos derechos de decisión y guardrails—no funcionar como una vía paralela de compras. (Consulta también nuestra guía de gobierno interno.)

Un flujo de due diligence “de decisión” (no un ejercicio de cuestionarios)

Para evitar sorpresas al final, ejecuta la due diligence como una evaluación por gates con responsables claros. El objetivo es llegar a una decisión go/no-go con riesgo residual cuantificado y plan de mitigación—antes de invertir en integración difícil de revertir.

/
Gate 0 (encaje y alcance): confirma casos de uso, clases de datos implicadas y el modelo de despliegue necesario (SaaS, VPC, on-prem, híbrido). Define qué significa “listo para producción” desde el inicio.
/
Gate 1 (seguridad y derechos de datos): valida controles, tratamiento de datos y términos contractuales antes de ir más allá de un sandbox.
/
Gate 2 (preparación para entrega): prueba integraciones, observabilidad, respuesta a incidentes, rate limits y control de cambios con un thin vertical slice.
/
Gate 3 (comercial y modelo operativo): cierra precios, SLAs, modelo de soporte y el runbook interno (quién monitoriza, quién aprueba cambios, quién responde por el rendimiento del modelo).

Si ya estás pasando de pilotos a producción, trata la evaluación de proveedor como parte del modelo operativo de escalado: controles, telemetría y ownership importan tanto como la “calidad” del modelo. La brecha piloto‑producción es donde la ambigüedad del proveedor se convierte en deuda operativa.

El scorecard de due diligence (qué puntuar y cómo decidir)

Un scorecard ayuda a mantener consistencia entre proveedores y deja un rastro de decisión defendible ante auditorías. Puntúa cada dominio 1–5 (o Rojo/Ámbar/Verde) y registra: evidencias revisadas, aprobación por responsable, riesgo residual y mitigaciones requeridas. No se trata de “todo perfecto”, sino de trade-offs transparentes.

1) Derechos de datos, uso y retención (máximo impacto, más ignorado)

/
Derechos de entrenamiento/mejora: ¿inputs/outputs se usan para entrenar o mejorar algún modelo (tuyo, compartido o del proveedor)? ¿hay opt‑outs y son el default?
/
Clases de datos y restricciones: tratamiento explícito de PII, datos de cliente, datos regulados y propiedad intelectual/confidencial (incluyendo qué no puede enviarse, ni siquiera de forma transitoria).
/
Retención y borrado: periodos de retención de logs, SLAs de borrado y si el borrado incluye artefactos derivados (embeddings, pesos fine-tuned, cachés).
/
Propiedad y reutilización de outputs: quién es dueño de los outputs y si el proveedor puede usarlos para benchmarking, evaluación o mejora para otros clientes.
/
Subprocesadores y transferencias: visibilidad de subprocesadores, ubicaciones de procesamiento y controles de notificación/aprobación ante cambios.
/
Residencia de datos: si la residencia es exigible en la práctica (no solo “best effort”), incluyendo backups, telemetría y acceso de soporte.

Nota de ejecución: involucra gobierno del dato desde el inicio para que la evaluación refleje cómo se clasifican, acceden y trazan los datos en tu entorno. Si la trazabilidad y los controles de acceso son débiles, ni el mejor contrato evita exposiciones accidentales.

2) Controles de seguridad alineados con amenazas específicas de IA

/
Aislamiento de tenants y gestión de secretos: cómo se almacenan/rotan API keys, conectores y credenciales de herramientas; y si soporta customer‑managed keys cuando aplique.
/
Control ante prompt injection y uso de herramientas: guardrails para tool calls, allowlists, validación de parámetros y prevención de exfiltración hacia sistemas conectados.
/
Logging y redacción: capacidad de controlar qué se registra, redacción de información sensible y segregación de logs por entorno.
/
Gestión de vulnerabilidades y alcance de pentest: que se prueben superficies “alrededor” del modelo (plugins, frameworks de agentes, conectores), no solo la app web.
/
Control de accesos y auditabilidad: roles granulares, logs de auditoría y trazabilidad de acciones administrativas—especialmente en revisiones humanas (human‑in‑the‑loop).
/
Respuesta a incidentes: plazos de notificación, límites de responsabilidad compartida y evidencias utilizables en comunicaciones con clientes y reguladores.

3) Preparación para entrega: integración, fiabilidad y soporte operativo

Muchos despliegues de IA fracasan no por la calidad del modelo, sino porque el modelo de entrega del proveedor no encaja con producción: identidad, red, observabilidad, gestión de releases y expectativas de guardia. “Hay API” no es un plan de entrega.

/
Vías de integración: compatibilidad con SSO/IAM, requisitos de red, opciones de conectividad privada y cómo fluyen los datos entre sistemas.
/
Requisitos no funcionales: latencia, throughput, rate limits, concurrencia y si los límites varían por región o plan.
/
Observabilidad: métricas/logs disponibles, trazas de tool calls y capacidad de correlacionar fallos con versiones/config del modelo.
/
Modelo de soporte: escalado, tiempos de respuesta por severidad y si el soporte puede acceder a datos (y con qué aprobaciones).
/
Runbooks: modos de fallo documentados y mitigaciones recomendadas (fallbacks, reintentos, circuit breakers, respuestas cacheadas).

4) Ciclo de vida del modelo y control de cambios (el “rompe‑producción” silencioso)

/
Garantías de versionado: posibilidad de fijar versiones; políticas de deprecación; plazos de aviso; y soporte de rollback.
/
Notas de release y evaluación: transparencia de cambios que afectan comportamiento, seguridad u outputs (no solo disponibilidad).
/
Ventanas de cambio del cliente: si las actualizaciones pueden diferirse, testearse o desplegarse por entornos.
/
Soporte a pruebas de regresión: tooling o guía para ejecutar tu suite (prompts, outputs esperados, cadenas de herramientas).
/
Deriva por capas de seguridad: cómo se actualizan y cómo impacta en tu caso (p. ej., refusals, cambios de política).

5) Comerciales y gobierno de costes (evitar el “impuesto al éxito”)

La economía de la IA es no lineal: el uso crece rápido cuando el usuario confía, y el coste se dispara por reintentos, contextos largos, tool calls en cadena o upgrades de modelo. La due diligence debe confirmar si el proveedor habilita control de coste en runtime, no solo en el contrato.

/
Claridad de pricing: unidades predecibles, definiciones claras (tokens, tool calls, almacenamiento, fine‑tuning) y mecánicas de overage transparentes.
/
Controles presupuestarios: caps, throttling, imputación por proyecto y alertas por umbrales.
/
Palancas de eficiencia: soporte a caching, gestión de contexto, modelos más pequeños cuando aplique y estrategias de routing (si es relevante).
/
Protecciones comerciales: plazos de aviso ante cambios de precio, flexibilidad en compromisos y condiciones de salida sin penalizar una retirada responsable.

6) Alineación de compliance y obligaciones con clientes

En B2B, los momentos más dolorosos de “compliance” suelen venir de revisiones de seguridad de clientes y cláusulas que debes trasladar (flow‑downs). El proveedor tiene que permitirte responder de forma consistente y con evidencia.

/
Disponibilidad de documentación: políticas, informes de auditoría, resúmenes de pentest y documentación de tratamiento de datos accesibles bajo NDA cuando sea necesario.
/
Flow‑downs contractuales: capacidad de cumplir obligaciones de notificación, tratamiento de datos y acceso de soporte que te exigen tus clientes.
/
Restricciones geográficas y sectoriales: soporte para entornos regulados, residencia y expectativas de sector (cuando aplique).
/
Revisión humana y accountability: si existe human‑in‑the‑loop, que sea controlado, auditable y compatible con obligaciones de confidencialidad.

Cómo interpretar el scorecard: trade-offs explícitos

Un scorecard útil impulsa decisiones, no documentación. Un patrón simple que funciona en comités ejecutivos:

/
Define no negociables: p. ej., no entrenar con datos de cliente, borrado exigible, notificación mínima de incidentes y posibilidad de fijar versiones para flujos críticos.
/
Acepta riesgo acotado de forma consciente: p. ej., aceptar más latencia por mejores controles de residencia; o aceptar residencia limitada para casos de baja sensibilidad con redacción estricta.
/
Vincula mitigaciones a responsables y fechas: controles técnicos (redacción, routing, aislamiento), adendas contractuales y controles operativos (gates de aprobación, monitorización).
/
Documenta el riesgo residual: qué queda, por qué se acepta y cuándo se revisará (renovación, actualización de atestaciones del proveedor, etc.).

Patrones de fallo comunes (y cómo los evita una buena due diligence)

/
Legal negocia “no training”, pero ingeniería habilita telemetría que retiene prompts sensibles más tiempo del previsto.
/
Seguridad aprueba por atestaciones genéricas, pero los riesgos de herramientas y conectores no se prueban, y aparece una vía de fuga de datos.
/
El piloto va bien, pero producción cae por rate limits, concurrencia o disponibilidad regional.
/
Finanzas valida precio unitario, pero nadie presupuesta reintentos, agentes multi‑paso o contextos largos: el sobrecoste termina siendo una decisión de producto.
/
El proveedor cambia modelo o capa de seguridad, el comportamiento se desplaza y workflows de cara al cliente se degradan sin rollback.

La solución práctica no es “más reuniones”. Es una evaluación integrada que conecte términos contractuales con la realidad técnica de cómo se mueven los datos y cómo se opera el sistema. La selección de proveedor debe tratarse como una decisión de cartera, con accountability claro de valor y riesgo.

Qué pedir como evidencia (para no puntuar promesas)

Una diligencia madura se apoya en evidencias. Artefactos típicos que reducen ambigüedad:

/
Diagramas de flujo de datos y una descripción escrita del procesamiento que encaje con tu arquitectura (incluyendo logs, cachés, embeddings y acceso de soporte).
/
Documentación de seguridad e informes de auditoría adecuados a tu nivel de riesgo (con statement de alcance).
/
Política de cambios del modelo/plataforma: versionado, avisos, deprecación y controles del cliente.
/
SLAs y términos de soporte alineados con workflows críticos (no un uptime genérico).
/
Plan de pruebas de “thin slice” en producción: tests de rate limits, inyección de fallos, validación de observabilidad y simulacros de rollback.

Dónde encaja: de la selección de proveedor a resultados en producción

Si estás decidiendo entre plataformas de LLM, proveedores de modelos o integradores, el enfoque ganador es tratar la due diligence como actividad de preparación para producción: contrato, arquitectura y controles operativos forman un único sistema. Bien hecha, acelera el time‑to‑value y reduce exposición de seguridad y sorpresas comerciales.

Si necesitas apoyo para ejecutar un scorecard, validar arquitectura o montar el flujo de evaluación entre compras, seguridad e ingeniería, podemos ayudar desde nuestra práctica de AI Solutions.

Para evaluaciones lideradas por compras o seguridad, también podemos facilitar un workshop de due diligence para alinear stakeholders, definir no negociables y producir una posición de riesgo basada en evidencias para aprobación ejecutiva.

Due diligence de proveedores de IA en B2B: un scorecard práctico para seguridad, derechos de datos y riesgo de entrega