Respuesta directa: elija al socio por su capacidad de demostrar una transacción empresarial completa y controlada, no una respuesta aislada del modelo. Exija evidencia en siete dimensiones: resultado y frontera, contratos de datos, identidad y autorización, orquestación y APIs, confiabilidad y fallback, observabilidad y economía, y propiedad y transferencia. Antes del rollout, pruebe datos representativos, una integración caída, un permiso denegado y un cambio de contrato. La empresa debe mostrar cómo impide acciones indebidas, registra decisiones y mantiene el proceso operable cuando falla la IA o el legacy.
La mayoría de los proyectos corporativos de IA no termina en el modelo. Para generar valor, la solución debe consultar fuentes, interpretar contexto, pedir aprobación, escribir en sistemas, alertar personas y manejar excepciones. En esa cadena se acumulan demoras, costos y riesgos. Un socio capaz trata el legacy como parte del producto: comprende contratos, límites, responsables y modos de falla, y propone una evolución incremental sin ocultar dependencias.
Integration Delivery Proof-7
Puntúe cada dimensión de 0 a 4: ausente, descrita, demostrada, validada en un ambiente representativo u operada en contexto comparable. El máximo es 28. Identidad, autorización, trazabilidad y recuperación deben ser gates no compensables. Solicite la misma evidencia a cada finalista.
1. Resultado y frontera del sistema
Comience por la tarea que debe terminar mejor: resolver una solicitud, actualizar CRM, reconciliar un documento, recomendar una acción o ejecutar un paso operativo. Exija baseline, volumen, excepciones, responsables y resultado económico. El diseño debe mostrar dónde la IA recomienda, una regla decide, una persona aprueba y el sistema registra. Sin frontera explícita, crece el alcance y se diluyen responsabilidad y aceptación.
2. Contratos de datos y contexto
Pida inventario de fuentes, dueños, finalidad, calidad, vigencia, campos sensibles y retención. Cada integración necesita contrato de esquema, validación, versiones y manejo de datos ausentes, tardíos o contradictorios. El socio debe explicar cómo excluye contenido no autorizado del contexto y reconcilia salidas con el sistema de registro. Datos disponibles no equivalen a datos confiables o permitidos.
3. Identidad, autorización y aprobación
La solución debe actuar con identidad correcta y privilegio mínimo. Evalúe autenticación, autorización por objeto y función, separación de funciones, credenciales de máquina, consentimiento y aprobación humana. OWASP destaca autorización y autenticación rotas entre los principales riesgos de APIs. Exija pruebas negativas con otro cliente, una función privilegiada y una herramienta prohibida.
4. Orquestación, APIs y compatibilidad
Solicite un diagrama completo con modelos, gateways, colas, APIs, conectores, reglas, sistemas de registro y canales. Revise límites, idempotencia, timeouts, reintentos, duplicados, versiones y compensación de transacciones. El socio debe mantener inventario de APIs y evaluar servicios consumidos; OWASP también señala consumo inseguro e inventario deficiente. Prefiera adaptadores reemplazables a dependencia directa de un modelo.
5. Confiabilidad, fallback y recuperación
Defina el comportamiento ante modelo caído, latencia alta, salida inválida, API fuera de servicio, escritura parcial y conflicto de datos. Exija circuit breaker, colas, modo lectura, ruta manual, reconciliación y rollback cuando corresponda. Un proceso que funciona solo en el happy path es una demo. Las pruebas deben inyectar fallas y demostrar que ninguna acción importante queda invisible o sin responsable.
6. Observabilidad, evaluación y economía
Logs desconectados no bastan. Exija correlación entre intención, contexto, llamada al modelo, herramienta, sistema, aprobación y resultado, protegiendo datos sensibles. OpenTelemetry organiza observabilidad con traces, métricas y logs; la propuesta debe especificar señales de calidad, latencia, error, costo e impacto. Combine evaluación de respuestas con métricas de proceso y costo total por resultado, incluyendo revisión, soporte y reproceso.
7. Propiedad, operación y transferencia
Separe código, conectores, prompts, evaluaciones, datos, modelos, licencias y servicios gestionados. Exija repositorio, documentación, infraestructura como código, runbooks, telemetría, backlog, capacitación, soporte, SLAs y salida. NIST SP 800-218A extiende prácticas seguras durante el ciclo; esto requiere versiones, pruebas y responsabilidades que sobrevivan al equipo inicial. El comprador debe poder operar, auditar y reemplazar componentes.
La prueba de ruptura para finalistas
Use el mismo escenario: CRM agrega un campo obligatorio, una API se vuelve lenta, una credencial pierde permiso y el modelo intenta repetir una escritura. Pida arquitectura, secuencia, controles, telemetría, mensaje al usuario, reconciliación y responsable. La respuesta revela si la empresa comprende integración distribuida o solo conecta un modelo a una API en una demo.
Piloto vertical antes de expandir
Elija un journey completo con valor y riesgo controlables. Incluya casos comunes, excepciones, datos reales gobernados, una escritura en sistema y fallback humano. Congele criterios de calidad, autorización, latencia, disponibilidad, costo y reconciliación. El Perfil de IA Generativa de NIST recomienda medir y gestionar capacidades, límites e impactos; el piloto debe producir evidencia para detener, rediseñar o escalar.
Cómo comparar propuestas
Normalice volumen, integraciones, ambientes, datos, modelos, disponibilidad, soporte y responsabilidades. Compare discovery, construcción, licencias, consumo, observabilidad, seguridad, mantenimiento y cambio. Un precio fijo sin inventario técnico y un cronograma que ignora accesos y dueños del legacy no eliminan incertidumbre. Vincule pagos a contratos de datos, integración validada, pruebas negativas, recuperación, documentación y aceptación operativa.
Señales eliminatorias
Descarte proveedores que piden credenciales amplias, omiten pruebas de autorización, no registran llamadas a herramientas, tratan reintentos como detalle, no explican datos enviados a terceros, dependen de un ambiente manual irreproducible o impiden exportación y transición. También es alerta prometer reemplazar el legacy antes de mapear sus reglas y excepciones.
Próximo paso
Use este framework con la guía de automatización en https://makinai.co/insights/es/como-elegir-empresa-automatizacion-procesos-ia, la evaluación de agentes en https://makinai.co/insights/es/como-evaluar-empresa-agentes-ia y la guía de contrato y SOW en https://makinai.co/insights/es/que-incluir-contrato-sow-servicios-ia. Para integrar agentes, automatizaciones y sistemas empresariales, visite https://makinai.co/services/es/desarrollo-agentes-ia-automatizacion.