Evaluar proveedores, contratos y cambios

Contratar una herramienta de IA no transfiere la responsabilidad de comprender cómo encaja en tu proceso. El proveedor aporta capacidades, infraestructura y compromisos; la organización debe decidir si esas condiciones son compatibles con su finalidad, datos y riesgo.

La evaluación debe referirse al servicio y plan concretos, no a la marca.

Construye una ficha de proveedor

Registra:

• entidad contratada;
• producto;
• plan;
• región;
• modelos disponibles;
• APIs;
• subservicios;
• funcionalidades activadas;
• soporte;
• SLA si existe;
• fecha de revisión;
• propietario interno.

Una empresa puede ofrecer productos con políticas distintas. No uses la política de una cuenta empresarial para justificar una cuenta personal.

Evidencia contractual

Recopila, cuando proceda:

• contrato principal;
• DPA o anexo de tratamiento;
• subencargados;
• ubicación de datos;
• transferencias;
• retención;
• borrado;
• uso de datos para entrenamiento o mejora;
• seguridad;
• notificación de incidentes;
• auditoría;
• propiedad intelectual;
• límites de uso;
• exportación;
• terminación.

Si trata datos personales por cuenta de la organización, revisa con el responsable competente los requisitos del artículo 28 del RGPD.

No conviertas un certificado o una página comercial en sustituto del contrato.

Evidencia técnica

Verifica:

• autenticación;
• SSO;
• RBAC;
• logs;
• cifrado;
• aislamiento;
• API;
• rate limits;
• versionado;
• disponibilidad regional;
• controles de datos;
• exportación;
• eliminación.

Una funcionalidad de la interfaz puede no existir en API, o viceversa.

Identifica la cadena de suministro

El producto puede depender de:

SaaS → proveedor de modelo → cloud → conectores → subencargados

Registra dependencias críticas.

Pregunta:

• ¿quién procesa el prompt?
• ¿quién almacena archivos?
• ¿quién ejecuta conectores?
• ¿qué ocurre al activar web search?
• ¿qué tercero procesa transcripciones?
• ¿qué servicios salen de la región elegida?

La cadena cambia al activar funciones.

Evalúa cambios

Los proveedores modifican:

• modelos;
• nombres;
• límites;
• APIs;
• términos;
• subencargados;
• regiones;
• controles;
• precios;
• retención;
• funcionalidades.

Define eventos que reabren evaluación:

• cambio de proveedor;
• cambio de modelo;
• nueva tool;
• nueva integración;
• nueva categoría de datos;
• nuevo país;
• cambio contractual;
• incidente;
• downgrade o upgrade de plan.

No revises solo una vez al contratar.

Define obligaciones operativas

Una ficha útil debe indicar qué debe hacer la organización si:

• cambia un subencargado;
• el proveedor sufre una incidencia;
• la API queda obsoleta;
• un modelo desaparece;
• cambia la política de datos;
• se supera presupuesto;
• se termina el contrato.

El riesgo de terceros se gestiona con procedimientos, no con una puntuación estática.

Evalúa lock-in

Observa:

• formato de datos;
• prompts;
• tool schemas;
• APIs propietarias;
• evaluación;
• embeddings;
• almacenamiento;
• modelos;
• workflows.

Pregunta qué puede exportarse.

No necesitas evitar todo lock-in. Una dependencia puede ser razonable si el beneficio lo compensa y existe un plan de salida.

Diseña una prueba de salida

Antes de producción, simula:

1. exportar configuración;
2. descargar datos;
3. revocar acceso;
4. eliminar datos;
5. cambiar credencial;
6. sustituir modelo;
7. ejecutar tests con alternativa.

Esto convierte «podemos migrar» en evidencia.

Comprueba cambios de rol

Si tu organización modifica, integra o comercializa el sistema, puede cambiar su papel regulatorio. El AI Act contiene reglas específicas para operadores y cadena de valor.

No decidas el rol por intuición. Cuando el uso deje de ser simplemente «consumir un SaaS», escala la revisión.

Métricas

Puedes monitorizar:

• proveedores sin DPA revisado;
• subencargados sin revisar;
• contratos próximos a renovación;
• casos sin plan de salida;
• servicios con términos cambiados;
• APIs con deprecación;
• incidentes por proveedor;
• dependencias críticas únicas.

Ejemplo

Un equipo contrata un asistente empresarial para resumir documentos. Meses después activa un conector de almacenamiento y web search.

Aunque el nombre del producto no cambie, el flujo de datos y la cadena de terceros sí. El evento debe reabrir la evaluación.

Separa diligencia inicial y monitorización continua

La evaluación previa a la compra responde: «¿podemos usar este servicio para esta finalidad?». La monitorización responde: «¿siguen siendo válidas las condiciones que justificaron la decisión?».

Define un registro de cambios del proveedor con:

• fecha;
• fuente;
• cambio observado;
• casos afectados;
• severidad;
• responsable;
• decisión.

No esperes a la renovación contractual para revisar cambios técnicos que alteran el riesgo.

Diferencia evidencia del proveedor y evidencia independiente

La documentación del proveedor es necesaria para saber qué declara o configura el servicio. Pero no demuestra por sí sola que un control sea eficaz en tu entorno.

Combina, cuando proceda:

• contrato;
• documentación;
• certificaciones;
• informes de auditoría disponibles;
• pruebas propias;
• logs;
• resultados de seguridad;
• referencias del equipo técnico.

No conviertas una certificación en una conclusión universal de seguridad.

Define requisitos antes de comparar

Una comparación de proveedores debe partir de requisitos:

• residencia;
• retención;
• SSO;
• RBAC;
• exportación;
• tool calling;
• structured outputs;
• disponibilidad;
• modelo;
• coste;
• soporte.

Después marca:

required / preferred / irrelevant

Así evitas elegir por una demo atractiva que no satisface controles críticos.

Evalúa reversibilidad económica

La salida no depende solo de poder descargar datos. También importa:

• coste de reescribir integraciones;
• prompts;
• evals;
• tool schemas;
• embeddings;
• formación;
• procedimientos.

Documenta TCO de salida de forma aproximada cuando sea relevante.

Simula un cambio adverso

Ejemplos:

• subida de precio;
• retirada del modelo;
• cambio de región;
• nuevo subencargado;
• pérdida de una función;
• modificación de límites.

Pregúntate qué casos se bloquean y cuánto tardas en sustituir la dependencia.

El ejercicio revela si el plan de salida existe realmente.

Ejercicio

Elige un proveedor y crea una ficha con:

• producto y plan;
• contrato;
• datos;
• retención;
• entrenamiento;
• subencargados;
• región;
• seguridad;
• API;
• cambios;
• lock-in;
• salida.

Marca cada campo como verified, unknown o not_applicable.

Luego define cinco eventos que obliguen a revisar de nuevo.

Resultado de la lección

Debes terminar con evidencia suficiente para explicar qué compraste, qué procesa, de quién depende, qué puede cambiar y cómo sales. La siguiente lección convierte esos compromisos y riesgos en supervisión, transparencia y respuesta operativa.