Defina la aceptación antes de la propuesta final: cada entrega necesita métrica, baseline, conjunto de prueba, entorno, tolerancia, evidencia, responsable y consecuencia. Libere un pago solo después de que un aprobador autorizado supere la puerta correspondiente. Una demostración, una cifra de precisión o el cierre de un sprint no prueban que un sistema de IA esté listo para operar.
El comportamiento de IA cambia con datos, contexto, versiones y uso humano. La aceptación debe combinar resultado de negocio, calidad técnica, límites de riesgo y preparación operativa. TEVV-Athlon de NIST construye evaluaciones desde objetivos y mediciones adaptadas; aplique esa disciplina al contexto del comprador y no a una prueba elegida por el proveedor.
AI Acceptance & Payment Gate-8: matriz de 32 puntos
Califique cada dominio de cero a cuatro: cero es indefinido; uno, promesa; dos, prueba parcial; tres, evidencia reproducible en el entorno acordado; cuatro, evidencia aprobada, registrada y operada. Exija al menos 24 de 32, ningún cero y aprobación de filtros obligatorios. Ajuste el umbral al riesgo y a la normativa local.
- Resultado de negocio — baseline, fórmula, población, periodo, owner y contramétricas.
- Calidad de la tarea — evaluación representativa, denominador, segmentos, tolerancia y revisión humana.
- Confiabilidad — disponibilidad, latencia, recuperación, volumen y degradación segura.
- Seguridad y privacidad — acceso, logs, datos, terceros, pruebas adversarias e incidentes.
- Integración y datos — contratos de interfaz, calidad, linaje, fallas y conciliación.
- Economía — costo por resultado, topes, consumo, variación y alertas.
- Operación — observabilidad, soporte, runbooks, cambios, rollback y responsables.
- Transferencia — código, prompts, configuración, evaluaciones, documentación, formación y salida.
Cinco condiciones que bloquean la aceptación
- El criterio es subjetivo, como 'satisfactorio', sin métrica ni tolerancia.
- No existe baseline, conjunto de evaluación fijado, denominador o entorno reproducible.
- Modelo, prompt, datos o configuración pueden cambiar durante la prueba sin versión ni repetición.
- El pago vence antes de que el comprador reciba evidencia, acceso y artefactos.
- No hay plazo de subsanación, nueva prueba, excepción aprobada, rollback o dueño del riesgo residual.
Cree un registro de aceptación, no un acta ambigua
Registre por requisito: ID, resultado, métrica, baseline, objetivo y tolerancia, datos y versión, entorno, procedimiento, evidencia, tester, aprobador, fecha, resultado, excepción, plazo de corrección, nueva prueba y pago afectado. Conserve evidencia suficiente sin acumular datos personales innecesarios.
FAR Part 46 separa calidad, inspección y aceptación. Subpart 46.5 ubica la aceptación después de las acciones de aseguramiento y exige evidencia de la decisión. Adapte el principio al contrato y legislación aplicables: entrega, prueba, aceptación formal y factura son eventos conectados, pero distintos.
Vincule pagos con evidencia acumulada
No existe una distribución universal. Un esquema ilustrativo puede liberar 10–15% por movilización y plan de medición, 15–20% por baseline y diseño validados, 20–25% por evaluación controlada, 25–30% por preparación productiva y el saldo después de estabilización y transferencia. Ajuste cifras a esfuerzo, dependencias, riesgo y capacidad de corrección.
Pruebe por capas y congele la versión
- Componente: modelo, recuperación, reglas, herramientas y contratos de datos.
- Sistema: recorrido completo, integraciones, identidad, auditoría, latencia y costo.
- Escenarios adversos: datos deficientes, caída, prompt injection, abuso, picos y salida insegura.
- Operación asistida: usuarios reales, revisión humana, excepciones, soporte y rollback.
- Estabilización: ventana definida para observar SLO, incidentes, costos y transferencia.
Congele versiones de modelo, prompt, índice, dataset, configuración y dependencias para la prueba. Un cambio material invalida las pruebas afectadas cuando el contrato define impacto y regresión. El perfil de IA generativa de NIST recomienda evaluación documentada durante todo el ciclo de vida.
Separe defecto, excepción y mejora
Un defecto incumple el criterio y activa corrección o remedio. Una excepción es un desvío conocido con impacto, plazo y riesgo residual aprobados. Una mejora aumenta valor sin bloquear el uso acordado y entra al backlog. Defina análisis, subsanación, retest, aceptación parcial, créditos, reducción de alcance y terminación.
Mantenga agilidad sin aceptación arbitraria
Las historias pueden cambiar, pero resultados, guardrails, Definition of Done, procedimiento de aceptación y control de cambios deben seguir claros. La guía británica para contratación ágil relaciona iteración con gobernanza y gestión de desempeño. Separe feedback de producto de aceptación contractual.
Conecte contrato, evaluación, piloto y pago
Use https://makinai.co/insights/es/que-incluir-contrato-sow-servicios-ia para estructurar obligaciones, https://makinai.co/insights/es/como-elegir-empresa-evaluacion-pruebas-ia para diseñar pruebas y https://makinai.co/insights/es/como-estructurar-piloto-pago-contratar-empresa-ia para validar hipótesis antes de escalar. Conozca https://makinai.co/services/es/consultoria-estrategia-ia-transformacion.
Cuándo involucrar a MAKINAI
MAKINAI puede convertir objetivos en un registro de aceptación, alinear datos, métricas, tolerancias y responsables, y crear puertas ejecutables por compras, tecnología y proveedor. El resultado debe distinguir evidencia comprobada, excepciones aprobadas y la prueba exacta que libera cada pago.