Cómo poner en práctica la debida diligencia de los proveedores de IA sin ralentizar la entrega de productos

La debida diligencia de los proveedores de IA avanza rápidamente cuando se diseña como un flujo de trabajo de producto basado en el riesgo, no como un cuestionario que comienza justo antes del lanzamiento. Comience con una breve descripción del uso previsto, diríjala a una revisión ligera, estándar o mejorada, solicite solo la evidencia necesaria para ese carril y realice verificaciones de privacidad, seguridad, legales, de productos y comerciales en paralelo. Termine con una decisión registrada (aprobar, aprobar con condiciones, poner a prueba, escalar o rechazar) y aclarar los factores desencadenantes de la reevaluación.

El objetivo no es aprobar a todos los proveedores más rápido. Se trata de llegar a la decisión correcta con menos espera, duplicación y ambigüedad. Un asistente de notas de reuniones que utiliza información pública no debería enfrentar el mismo proceso que un sistema de inteligencia artificial que maneja datos de clientes, toma acciones en producción o influye en el empleo, el crédito, el acceso, la seguridad u otro resultado importante.

Por qué la revisión de proveedores de IA se convierte en un cuello de botella en la entrega

La mayoría de los retrasos comienzan antes de que alguien revise las pruebas. Un gerente de producto describe al proveedor como “un asistente de IA”, el departamento de adquisiciones envía un cuestionario de seguridad genérico, el departamento legal ve el contrato retrasado y el departamento de ingeniería no ha documentado qué datos o integraciones se utilizarán. Los revisores hacen diferentes versiones de las mismas preguntas porque nadie ha definido la implementación real.

Los servicios de IA también cambian con mayor fluidez que el SaaS convencional. Un proveedor puede cambiar de proveedor de modelos, enrutar solicitudes entre modelos, agregar fuentes de recuperación, cambiar la configuración de retención o capacitación, introducir agentes o acceso a herramientas, o alterar los controles de seguridad. El mismo proveedor puede ofrecer configuraciones empresariales y de consumo sustancialmente diferentes. Por lo tanto, revisar la marca o la página de marketing no establece si el servicio configurado es adecuado.

La solución es un historial operativo común. Debe conectar el uso propuesto, la cadena de proveedores y modelos, el ciclo de vida de los datos, las pruebas, el contrato, las condiciones de aprobación y el seguimiento continuo. Esto evita el problema de revisión manual de proveedores, donde las pruebas y las decisiones se fragmentan en bandejas de entrada, hojas de cálculo y tickets.

Inicie el flujo de trabajo con una ingesta objetiva

Mantenga el ingreso lo suficientemente breve como para que el propietario de un producto o negocio pueda completarlo antes que un piloto. Pida hechos en lugar de conclusiones jurídicas:

• el objeto comercial y el beneficio esperado;
• usuarios y personas afectadas por los productos;
• entradas, salidas, categorías de datos, retención y ubicaciones de datos;
• modelo, proveedor, subprocesadores, integraciones y permisos de herramientas;
• si los resultados informan o determinan las acciones;
• opciones de revisión, anulación y recuperación humanas;
• mercados, compromisos con los clientes y fecha de lanzamiento prevista;
• el propietario interno del negocio y el propietario técnico.

Pídale al solicitante que distinga el uso aprobado actual de las posibilidades futuras. “Redactar respuestas de soporte interno para revisión humana” es un límite útil. “Mejorar la atención al cliente con IA” no lo es. Un límite preciso permite a los revisores identificar evidencia relevante y brinda a la ingeniería una condición que puede hacer cumplir.

La admisión debe partir de eventos que los equipos ya reconocen: agregar un proveedor de IA, habilitar una función de IA en un producto existente, enviar una nueva categoría de datos, conectar herramientas de producción, expandirse a un nuevo mercado, cambiar el modelo o propósito, reducir la revisión humana o hacer una nueva promesa al cliente.

Revisiones de ruta por riesgo

Utilice tres carriles con criterios de entrada escritos y expectativas de servicio.

Revisión ligera

Utilícelo para obtener asistencia interna de bajo impacto con datos no confidenciales, sin acciones de producción, sin decisiones consecuentes, resultados reversibles y una configuración empresarial establecida. Confirme el límite de uso, los controles de la cuenta, la configuración de datos, el estado del contrato, las restricciones de uso aceptable y el propietario. Una aprobación documentada puede ser suficiente.

Revisión estándar

Utilícelo cuando la información del cliente o de la empresa ingrese al servicio, la herramienta esté integrada en un producto, los resultados lleguen a usuarios externos, las integraciones puedan leer los sistemas operativos o los errores puedan crear un daño significativo. Agregue evidencia de privacidad y seguridad, pruebas de casos de uso, visibilidad de modelos y subprocesadores, revisión de contratos, rutas de incidentes y monitoreo.

Revisión mejorada

Úselo para datos personales confidenciales o regulados, decisiones importantes, grupos vulnerables, autonomía significativa, acceso por escritura a la producción, resultados difíciles de revertir, proveedores inciertos o un contexto de la Ley de IA potencialmente de alto riesgo. Requieren una clasificación más profunda, evidencia técnica, revisión de impacto, pruebas adversarias o de dominio, aprobación de liderazgo o especialistas y condiciones de lanzamiento explícitas.

Estos carriles son rutas de decisión, no etiquetas permanentes de proveedores. Un proveedor puede admitir un uso de redacción de bajo riesgo y un uso sensible de apoyo a la toma de decisiones. Dirija la implementación, no el logotipo.

Establecer un paquete mínimo de evidencia para cada carril

Las solicitudes de pruebas deben responder a los riesgos identificados. No envíe el cuestionario más largo a todos los proveedores.

Para el proveedor y la cadena de IA, capture la entidad contratada, el nivel de producto, el alojamiento, los proveedores de modelos, los subprocesadores relevantes, el límite del servicio, el control de versiones, el proceso de cambio de materiales y los contactos de soporte. Para datos, indicaciones de mapas, cargas, contenido recuperado, resultados, comentarios, registros, datos de soporte, retención, eliminación, uso de capacitación, acceso y divulgación posterior.

Para seguridad y resiliencia, solicite evidencia proporcional a la integración: alcance de garantía, controles de acceso, cifrado, aislamiento de inquilinos, manejo de vulnerabilidades, notificación de incidentes, recuperación y desarrollo seguro. Cuando sea relevante, examine la inyección rápida, la fuga de datos, el uso inseguro de herramientas, el contenido de recuperación envenenado, el manejo de resultados y los controles de abuso.

Para conocer el rendimiento, pregunte qué probó el proveedor, en qué usuarios, idiomas y condiciones, con qué base y con qué umbral de aceptación. Registre limitaciones y patrones de falla conocidos. Luego pruebe el uso configurado con datos representativos y legales. Los puntos de referencia de los proveedores no reproducen sus indicaciones, fuentes de recuperación, revisores, integraciones ni consecuencias.

El marco voluntario de gestión de riesgos de IA del NIST es útil para diseñar este proceso porque trata la gobernanza, el mapeo, la medición y la gestión como actividades conectadas. Su perfil de IA generativa también proporciona una referencia práctica para riesgos de pruebas, datos, seguridad y terceros. Estos marcos respaldan el diseño de diligencia; por sí solos no prueban el cumplimiento legal.

Ejecutar el trabajo de revisión en paralelo

Las transferencias secuenciales crean tiempo de inactividad. Una vez que la entrada establezca un límite estable, abran juntos los flujos de trabajo relevantes:

• el producto confirma el uso previsto, los usuarios afectados, el manejo de la salida y el alcance del lanzamiento;
• documentos de ingeniería, flujos de datos, configuración, integraciones, permisos, registros y comportamiento de falla;
• revisiones de seguridad de acceso, arquitectura, garantía, manejo de incidentes y riesgos técnicos;
• funciones de evaluación legal y de privacidad, procesamiento legal, transferencias, notificaciones, regulaciones y términos contractuales;
• adquisiciones gestiona la evidencia de proveedores, los términos comerciales, las renovaciones y el escalamiento;
• el cumplimiento u operaciones mantiene el registro completo y traslada los problemas no resueltos a los propietarios.

El trabajo paralelo necesita un coordinador y una lista de preguntas abiertas. De lo contrario, simplemente se crea una duplicación simultánea. Celebre una breve reunión de decisión solo cuando la evidencia revele una compensación real o el carril requiera aprobación multifunción.

Traducir las lagunas de evidencia en decisiones

No todas las brechas requieren rechazo y no todas las respuestas de los proveedores merecen aceptación. Para cada problema no resuelto, elija un tratamiento:

• obtener pruebas faltantes o un compromiso contractual;
• cambiar la configuración o restringir datos;
• usuarios específicos, propósito, geografía, integraciones o autonomía;
• agregar revisión humana, pruebas, monitoreo o un interruptor de apagado;
• realizar una prueba piloto de duración limitada con datos sintéticos o de bajo riesgo;
• aceptar un riesgo residual definido a través de la autoridad adecuada;
• rechazar o aplazar el uso.

Las condiciones deben ser comprobables. “No ingresar datos personales” es débil si la interfaz lo acepta y nadie monitorea su uso. Una condición más estricta combina restricciones de acceso, reglas de entrada aprobadas, orientación para el usuario, configuración, monitoreo y un propietario.

El contrato debe seguir la evidencia. Dependiendo del riesgo, aborde el uso permitido, capacitación sobre datos del cliente, proveedores de modelos, subprocesadores, ubicaciones, medidas de seguridad, aviso de incidente, documentación, evidencia de auditoría, cambios materiales, limitaciones de desempeño, soporte, eliminación, portabilidad, continuidad, responsabilidad y salida. Un contrato no puede convertir un sistema inadecuado en uno adecuado, pero puede preservar los derechos de información y hacer que las promesas operativas sean ejecutables.

Cuenta para la Ley de IA y las responsabilidades del RGPD

No le pida al proveedor que decida su función o clasificación legal. Según la Ley de IA de la UE, los deberes dependen del sistema, el propósito previsto, la categoría de riesgo y la posición en la cadena de valor. El artículo 25 establece circunstancias en las que un distribuidor, importador, implementador u otro tercero puede convertirse en proveedor de un sistema de alto riesgo, incluido cierto cambio de marca, modificación sustancial o cambios en el propósito previsto. El artículo 26 establece deberes para quienes implementan sistemas de alto riesgo, incluidas medidas apropiadas para seguir las instrucciones de uso. Registre los fundamentos de la clasificación y los supuestos para el despliegue real.

Cuando un proveedor procesa datos personales en nombre de la empresa, la diligencia del procesador del RGPD no se completa con la recopilación de un acuerdo de procesamiento de datos. Las directrices del CEPD explican que los responsables del tratamiento deben evaluar si los encargados del tratamiento ofrecen garantías suficientes, en función de las circunstancias, y que la evaluación no es meramente formal. Haga coincidir las declaraciones contractuales con el nivel implementado, la cadena de subprocesador, la configuración, el flujo de datos y la práctica operativa.

Por eso la diligencia operativa conecta el análisis jurídico con los controles técnicos. Un memorando de rol sin un límite de uso obligatorio es frágil; una configuración segura sin un propósito de procesamiento legal y documentado está incompleta.

Ponga la decisión en un registro duradero

El registro final debe mostrar:

• proveedor, servicio, modelo o versión, propietario, revisores y fecha;
• usos, usuarios, datos, integraciones y geografía aprobados y prohibidos;
• carril de riesgo, roles legales, fundamentos de clasificación y supuestos;
• evidencia revisada, pruebas realizadas, hallazgos y brechas descubiertas;
• controles contractuales y restricciones operativas;
• decisión, aprobadores, condiciones, propietarios y plazos;
• señales de seguimiento, ruta del incidente, fecha de caducidad y factores desencadenantes de la reevaluación.

Enlace a la fuente de evidencia en lugar de pegar documentos en el expediente. Conserve la versión revisada para que las actualizaciones posteriores del proveedor no reemplacen silenciosamente la base de aprobación. Esto también hace que la recopilación de pruebas forme parte de la entrega y mejora la calidad de las respuestas de los clientes, las auditorías y los inversores.

Monitorear el cambio después de la aprobación

La aprobación es válida para un alcance definido, no para siempre. Reabrir la revisión cuando cambie el propósito previsto, el grupo de usuarios, la categoría de datos, el mercado, el modelo, el proveedor, el subprocesador, la integración, la autonomía, la supervisión humana, la retención, el uso de capacitación o el contrato. Los incidentes, las fallas importantes en el desempeño, los cambios regulatorios y las inquietudes creíbles de los clientes también deberían dar lugar a una revisión.

Solicite a los proveedores avisos de cambio de materiales, pero no confíe únicamente en los avisos. Las notas de lanzamiento de productos, los inventarios de configuración, las renovaciones de adquisiciones, el monitoreo de seguridad, los informes de usuarios y las certificaciones periódicas de los propietarios pueden revelar desviaciones. Establecer una fecha de revisión basada en el riesgo y el ciclo del contrato.

Esta evidencia continua es parte de la [gobernanza de IA que se espera de los proveedores de SaaS] más amplia (/es/blog/como-la-gobernanza-de-ai-esta-cambiando-las-expectativas-de-compliance-para-proveedores-saas). También crea un paquete reutilizable para diligencia debida de los inversores en lugar de obligar a los equipos a reconstruir las decisiones más adelante.

Errores operativos comunes

A partir de la prueba piloto. Es posible que los datos, los usuarios y las integraciones reales ya estén expuestos antes de que comience la revisión.

Revisar el proveedor en lugar del uso. Un proveedor de buena reputación aún puede no ser adecuado para una configuración o consecuencia particular.

Tratar las certificaciones como aprobación. Los informes de aseguramiento ayudan, pero el alcance, la fecha, las excepciones, el comportamiento de la IA y el flujo de trabajo implementado aún necesitan evaluación.

Mejorar cada revisión. La revisión excesiva envía trabajo de rutina alrededor del proceso y oculta casos genuinamente sensibles en una gran cola.

Permitir que cada función mantenga su propia decisión. Los tickets, hojas de cálculo y notas de contrato en conflicto hacen que la aprobación sea imposible de explicar o monitorear.

Se aprueba una vez. Los modelos, la configuración, los datos, los subprocesadores y los usos previstos cambian. Una decisión sin desencadenantes de reevaluación caduca silenciosamente.

Una implementación práctica de 30 días

En la primera semana, defina la ingesta, los factores desencadenantes y las tres líneas de revisión. Utilice reseñas recientes de proveedores para comprobar si las preguntas distinguen los usos sensibles de los de bajo riesgo.

En la segunda semana, asigne propietarios y pruebas mínimas. Cree solicitudes reutilizables de evidencia de proveedores, datos, seguridad, desempeño, gobernanza y contratos. Indique quién puede aprobar cada carril y quién puede aceptar el riesgo residual.

En la tercera semana, conecte el flujo de trabajo con la planificación de productos, la incorporación de proveedores, la revisión de seguridad y privacidad y la preparación para el lanzamiento. Configure un registro de decisión y una vista de problemas abiertos.

En la cuarta semana, ejecute el proceso con dos proveedores reales: uno simple y otro sensible. Mida el tiempo de espera, las preguntas repetidas, la propiedad no resuelta y las lagunas de evidencia. Elimine las preguntas que nunca cambian una decisión y fortalezca los controles donde los revisores todavía se basan en suposiciones.

Preguntas frecuentes

¿Cuál es el propósito práctico de la debida diligencia de los proveedores de IA?

Produce una decisión defendible sobre si se puede utilizar un servicio de IA específico y cómo. Un buen proceso encuentra riesgos materiales de manera temprana, asigna controles y preserva evidencia para clientes, auditorías, incidentes y reevaluaciones.

¿Cuándo se aplica la diligencia debida de los proveedores de IA a los equipos SaaS?

Utilice al menos una revisión ligera cada vez que un servicio de inteligencia artificial de terceros ingrese a los flujos de trabajo de la empresa o del producto. Aumente la profundidad cuando el uso involucre datos confidenciales, usuarios externos, resultados consecuentes, autonomía, integración de clientes, proveedores inciertos o contextos potencialmente regulados.

¿Qué deberían documentar o cambiar los equipos primero?

Documente el uso previsto, los usuarios, las personas afectadas, los datos, las integraciones, los resultados, la revisión humana y las acciones posteriores. Luego defina las líneas de riesgo, los propietarios, la evidencia mínima, la autoridad para tomar decisiones y los factores desencadenantes de la reevaluación.

¿Cómo evita esto ralentizar la entrega del producto?

Comienza la revisión antes, separa los usos rutinarios de los sensibles, ejecuta comprobaciones relevantes en paralelo, reutiliza la evidencia y convierte las lagunas en condiciones explícitas. Los equipos pasan menos tiempo esperando traspasos poco claros, mientras que las decisiones de mayor riesgo reciben más atención.

La debida diligencia de los proveedores de IA debería hacer que el camino de aprobación sea predecible. Alcance el uso real, enrute por riesgo, recopile evidencia específica, pruebe el servicio configurado, registre una decisión y monitoree el cambio. Así es como los equipos SaaS se mueven rápidamente sin confundir velocidad con revisión débil.