Respuesta directa
En pocas palabras
Para evaluar a un proveedor de AI Sales Copilot, define primero el caso de uso y su impacto; inventaría modelos, datos, APIs, integraciones, ubicaciones y subprocesadores; solicita evidencia proporcional sobre privacidad, seguridad, calidad, cambios e incidentes; prueba el servicio con escenarios normales y de falla; asigna controles entre proveedor y cliente; y establece monitoreo, contingencia, portabilidad y salida. Una declaración comercial no sustituye un artefacto verificable ni una prueba propia.
Evalúa la dependencia durante todo su ciclo de vida
Un proveedor de IA no es solo la empresa que vende la interfaz. Puede aportar el modelo, una API, datos, búsqueda, almacenamiento, identidad, observabilidad, correo, una biblioteca de código o personal con acceso al servicio. Cada componente modifica lo que el copiloto puede ver, producir y hacer. Por eso la debida diligencia empieza antes de contratar, continúa durante la operación y termina cuando los datos y accesos ya fueron tratados.
NIST recomienda políticas específicas para riesgos de sistemas, componentes y datos de terceros, con transparencia sobre limitaciones y mecanismos para responder a fallas. También propone monitorear regularmente los riesgos y beneficios de terceros. La evaluación no debe reducirse a un cuestionario anual: necesita evidencia vigente, pruebas dentro del caso de uso y señales que permitan revisar una decisión.
La empresa compradora conserva decisiones que no puede delegar. Debe definir el propósito, los datos autorizados, los efectos aceptables, la supervisión, la tolerancia y la alternativa operativa. El proveedor explica y demuestra sus controles; la organización decide si esa evidencia es suficiente para su contexto.
Define el caso de uso y su materialidad antes de pedir documentos
Describe la tarea en lenguaje operativo: resumir actividad del CRM, preparar un correo, recomendar un siguiente paso, generar una propuesta desde un catálogo o ejecutar una actualización. Separa observar, redactar, recomendar, guardar, enviar y modificar. La misma tecnología cambia de riesgo cuando pasa de un borrador revisado a una acción con efecto sobre clientes, dinero, acceso o compromisos.
Identifica a las personas afectadas, la reversibilidad y la alternativa manual. Una función de apoyo interno con datos mínimos no exige la misma profundidad que una integración con información confidencial y permiso de escritura. Utiliza la materialidad para decidir qué evidencia, pruebas, aprobaciones y frecuencia de revisión necesita cada dependencia.
Registra también lo que queda fuera. No supongas que una función demostrada en la interfaz cubre todos los canales, idiomas, regiones o integraciones. Si el proveedor no confirma una capacidad o condición, trátala como no demostrada hasta obtener evidencia.
Dibuja la cadena de valor, no solo el nombre comercial
Construye un inventario desde la entrada hasta el efecto. Incluye aplicación, modelos base y ajustados, recuperación, índices, fuentes, conectores, herramientas, alojamiento, identidad, telemetría, soporte y subprocesadores. Para cada elemento registra proveedor, versión, región, acceso, datos tratados, responsable interno y dependencia aguas abajo.
Pregunta qué componentes administra directamente el proveedor y cuáles obtiene de terceros. Una actualización del modelo, una biblioteca sin mantenimiento o un endpoint que cambia pueden modificar disponibilidad, calidad o seguridad aunque la marca visible permanezca igual. NIST señala que datos, software y hardware externos añaden complejidad y opacidad; el inventario permite localizar esa exposición.
Distingue flujo de datos y flujo de autoridad. Un componente puede recibir información sin poder actuar, mientras otro puede escribir en el CRM o enviar una comunicación. Registra secretos, cuentas de servicio, permisos y límites por organización. Así se identifica dónde un fallo técnico podría convertirse en un efecto comercial.
Separa afirmaciones, artefactos, pruebas y señales operativas
Una respuesta del equipo comercial orienta la conversación, pero no prueba por sí sola que un control existe. Pide el artefacto que corresponda: documentación, diagrama, reporte independiente, configuración, historial de cambios, resultado de prueba o procedimiento de incidente. Después confirma si el documento cubre el producto, versión, región y servicio que realmente utilizarás.
La evidencia más útil conecta una afirmación con un alcance, una fecha y un resultado. Un certificado puede respaldar un programa de control sin demostrar cómo se comporta una función concreta. Una prueba propia puede demostrar el recorrido evaluado sin cubrir la infraestructura completa. Combina fuentes en lugar de pedir un documento mágico que resuelva todas las dudas.
Registra faltantes y contradicciones. No rellenes con una interpretación favorable una retención no definida, un cambio sin aviso o una responsabilidad ambigua. La decisión puede ser aprobar con límites, pedir una corrección, añadir un control compensatorio, reducir el alcance o descartar la dependencia.
| Criterio | Qué aporta | Cómo utilizarla |
|---|---|---|
| Afirmación | Explicación del proveedor | Convertirla en una pregunta verificable |
| Artefacto | Documento, reporte o configuración | Confirmar alcance, versión, fecha y propietario |
| Prueba observada | Resultado dentro del escenario evaluado | Conservar método, rol, datos y resultado |
| Señal continua | Cambio, degradación, incidente o tendencia | Vincular umbral, responsable y respuesta |
Aclara datos, privacidad, propiedad intelectual y procedencia
Documenta qué información recibe cada tercero, con qué propósito, dónde se procesa, cuánto tiempo se conserva y cómo se elimina. Pregunta si entradas, salidas, feedback o telemetría pueden utilizarse para entrenamiento o mejora, bajo qué configuración y con qué excepciones. Separa datos de producción, soporte, evaluación y seguridad porque pueden seguir rutas distintas.
Revisa residencia, transferencias, subprocesadores, copias de respaldo y recuperación. Define cómo se atienden solicitudes de acceso, corrección o eliminación cuando correspondan. La ubicación técnica no resuelve por sí sola obligaciones de privacidad; el equipo responsable debe revisar el tratamiento aplicable al país, sector y tipo de información.
Examina procedencia y derechos sobre datos, modelos y salidas. Pide que el proveedor describa restricciones conocidas, mecanismos de reporte y tratamiento de reclamaciones. No presentes esta guía como asesoría legal: contratos, propiedad intelectual y protección de datos deben revisarse con profesionales competentes para la organización.
Comprueba seguridad, identidad y respuesta a incidentes
Revisa autenticación, separación entre organizaciones, roles, mínimo privilegio, administración, sesiones, secretos y registros. Confirma qué permisos necesita cada integración y si lectura, escritura y acciones sensibles pueden limitarse por separado. Una conexión técnicamente funcional no debe recibir autoridad adicional por comodidad.
Pregunta cómo se gestionan vulnerabilidades, pruebas de seguridad, dependencias de software, divulgación responsable, respaldos y continuidad. Solicita una ruta de contacto para incidentes, tiempos de notificación definidos contractualmente cuando correspondan y la información que el proveedor puede aportar para investigar. La organización también necesita su propio mecanismo de pausa, revocación y contención.
Prueba la baja de un usuario, la rotación de un secreto y la pérdida de un permiso. Verifica que los logs permitan reconstruir accesos y acciones sin almacenar contenido innecesario. Microsoft recomienda evaluar riesgos de modelos, bibliotecas, APIs y fuentes externas, además de aplicar un proceso claro de revisión; esa frontera debe incluir tanto controles del proveedor como los del cliente.
Evalúa calidad, límites, versiones y cambios del modelo
Pide documentación sobre capacidades, limitaciones, idiomas, condiciones de evaluación y uso previsto. No traslades una métrica pública a tu proceso comercial sin comprobar población, tarea y criterio. Construye un conjunto propio con casos normales, datos incompletos, conflicto entre fuentes, instrucciones externas, permisos insuficientes y solicitudes fuera del alcance.
Aclara cómo se identifican versiones, qué puede cambiar sin aviso, qué periodos de deprecación existen y si es posible fijar, probar o revertir una versión. Registra también modificaciones de filtros, políticas, herramientas y límites de servicio. El comportamiento puede variar aunque el nombre del modelo no cambie.
Define criterios de aceptación por escenario, no una sola puntuación. Mide utilidad, corrección, fundamento, consistencia, abstención, escalación, latencia y efecto operativo. Conserva ejemplos críticos y repítelos cuando cambien modelo, prompt, fuente, integración, permiso o proveedor.
Asigna responsabilidades y convierte condiciones críticas en acuerdos
Construye una matriz sencilla: control del proveedor, control del cliente, control compartido y evidencia esperada. Incluye configuración segura, administración de usuarios, clasificación de datos, monitoreo, soporte, incidentes, cambios, respaldos, eliminación y salida. Compartido no debe significar que nadie sabe quién actúa primero.
Las condiciones materiales deben quedar en documentos aplicables, no solo en una presentación: servicio incluido, regiones, subprocesadores, uso de datos, notificaciones, soporte, disponibilidad, conservación, devolución o eliminación, portabilidad y cooperación ante incidentes. Cuando el riesgo lo justifique, la organización puede buscar derechos de evaluación o evidencia acordada. La redacción y suficiencia jurídica requieren revisión legal.
NIST recomienda actualizar la debida diligencia de adquisición y, para riesgos relevantes, considerar contratos que permitan evaluar procesos y estándares de terceros. La implementación concreta depende del poder de negociación y del contexto. Si una condición crítica no puede obtenerse, reduce datos, permisos o dependencia; no la ocultes detrás de una aceptación genérica.
Haz una prueba controlada que incluya fallas y recuperación
Utiliza un entorno aislado y datos sintéticos o minimizados cuando sea posible. Ejecuta el mismo recorrido que llegará a producción: acceso, recuperación de contexto, generación, revisión, registro y efecto. Participan negocio, operación y quienes administrarán datos, seguridad e integración. Una demo guiada por el proveedor no sustituye la ejecución del equipo.
Incluye condiciones adversas: dato faltante, precio no confirmado, dos monedas, fuente vencida, instrucción maliciosa, permiso revocado, API lenta, modelo no disponible y respuesta incompleta. Observa si el sistema conserva la duda, evita inventar, informa el límite y ofrece una ruta segura. Prueba también pausa, proceso manual y recuperación.
Registra escenario, versión, rol, entrada, resultado esperado, resultado observado, evidencia, severidad y decisión. Los hallazgos críticos deben corregirse y repetirse antes de ampliar. Una prueba exitosa solo respalda el alcance y la configuración evaluados.
Monitorea cambios, desempeño y concentración de proveedores
Define señales desde el inicio: disponibilidad, latencia, errores, calidad, correcciones humanas, abstenciones, incidentes, cambios de versión, deprecaciones, subprocesadores, documentación y soporte. Cada indicador necesita fuente, responsable, umbral y respuesta. El estado publicado por el proveedor complementa, pero no sustituye, la observación del recorrido propio.
Revisa la concentración. Varias funciones pueden depender del mismo modelo, nube, identidad o índice, aunque parezcan productos distintos. Un fallo común puede afectar cotización, seguimiento y análisis al mismo tiempo. Registra dependencias compartidas, capacidad disponible y orden de recuperación.
Programa revisiones según criticidad y también por evento. Reabre la evaluación ante una nueva función, región, clase de datos, modelo, integración, incidente, adquisición, cambio contractual, degradación persistente o fin de soporte. La decisión debe quedar en el registro de riesgos y en el control de cambios.
Diseña contingencia, portabilidad y salida antes de depender
NIST recomienda procesos de contingencia para fallas o incidentes de terceros. Define qué trabajo debe continuar, con qué datos, durante cuánto tiempo y quién puede activar el modo alternativo. El fallback puede ser otro proveedor, una versión estable, una capacidad limitada o un proceso manual; debe probarse, no solo mencionarse.
Aclara formatos de exportación, metadatos, historial, configuraciones, prompts, evaluaciones y registros que la organización podrá recuperar. Identifica componentes portables y dependencias difíciles de sustituir. Calcula el esfuerzo con condiciones confirmadas, sin inventar tiempos o costos que el proveedor no haya comprometido.
El plan de salida cubre comunicación, congelamiento de cambios, transferencia, revocación de cuentas y secretos, detención de integraciones, tratamiento de datos, verificación y excepciones temporales. No esperes a un incidente o a una renovación para descubrir que no existe una ruta operativa.
Aplica la metodología sin atribuir a Cerravi funciones que no tiene
En Cerravi, el copiloto organiza contexto y propone siguientes pasos para revisión humana. No envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios disponibles en el catálogo; si falta un importe, la interfaz debe mostrar el faltante y esperar confirmación. Las monedas permanecen separadas salvo que exista una conversión aprobada.
La actividad de una Buyer Room aporta señales de interacción, pero no confirma identidad, aceptación, firma, pago ni intención de compra. Forecast utiliza reglas transparentes del CRM; no es un modelo predictivo entrenado o calibrado como machine learning y no garantiza cierres ni ingresos.
Estos límites forman parte de la evaluación del servicio y deben compararse con el uso que cada empresa pretende habilitar. La organización sigue siendo responsable de configurar accesos, autorizar datos, revisar salidas, definir su política y comprobar que contratos y controles son adecuados para su operación.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué proveedores deben entrar en la evaluación?
Todos los terceros que puedan cambiar datos, comportamiento, acceso o continuidad del caso de uso: aplicación, modelo, APIs, nube, índices, conectores, identidad, observabilidad, soporte y subprocesadores materiales. La profundidad depende del impacto y la autoridad de cada componente.
¿Un certificado de seguridad es suficiente para aprobar al proveedor?
No por sí solo. Puede respaldar un programa de controles, pero debes confirmar alcance, fecha, producto y excepciones; revisar el caso de uso; y probar los recorridos y permisos que tu organización utilizará.
¿Qué hacer si el proveedor no comparte información sensible de su arquitectura?
Define qué evidencia alternativa permitiría decidir: reporte independiente, descripción bajo confidencialidad, prueba observada, control contractual o reducción del alcance. Si una incertidumbre material permanece, documenta el riesgo y limita o descarta la dependencia.
¿Cada actualización del modelo exige una evaluación completa?
No necesariamente. Clasifica el cambio y su posible efecto. Una actualización material puede requerir pruebas críticas, revisión de riesgos y aprobación; un cambio sin impacto en el alcance puede seguir una ruta abreviada. La decisión y la evidencia deben quedar registradas.
¿La evaluación de proveedores sustituye la revisión legal o de privacidad?
No. Esta metodología organiza preguntas, evidencia, pruebas y decisiones operativas. Las obligaciones contractuales, de propiedad intelectual, protección de datos y sectoriales deben revisarse con profesionales competentes para la organización y las jurisdicciones aplicables.