Plantilla de SLA para Agentes de IA: Precisión, Latencia, Handoff Humano y Auditabilidad
Un acuerdo de nivel de servicio para agentes de IA es un anexo contractual que define cuándo una tarea tiene éxito, cómo se mide, cuándo debe intervenir una persona, qué evidencia conserva el proveedor y qué ocurre si el agente incumple el umbral acordado. El uptime no basta. Una API puede devolver HTTP 200 mientras el agente cita una fuente inexistente, llama a la herramienta equivocada, duplica un pago o deja a un cliente esperando en una cola sin atención.
Esta plantilla cubre la fase contractual después de elegir un workflow y un posible proveedor. Si todavía defines el build, usa la plantilla de alcance para un MVP de IA. Si decides si un piloto merece pasar a producción, usa el scorecard para cancelar o escalar un piloto de IA. Si aún verificas seguridad y tratamiento de datos, usa el cuestionario europeo para proveedores de IA. Este SLA empieza donde terminan esos documentos: obligaciones recurrentes en producción, evidencia y remedios.
Es una ayuda técnica y comercial para redactar, no asesoramiento jurídico. Los valores entre corchetes y los objetivos de ejemplo son puntos de partida para negociar. Adáptalos al workflow, clasificación de riesgo, legislación, normas sectoriales y responsabilidad con asesoramiento cualificado.
¿Necesitas una arquitectura de agente que pueda producir esta evidencia?
Diseñar un Agente AuditableEl anexo de SLA para agentes de IA listo para copiar
Pégalo en el anexo de servicios, Statement of Work u order form. Completa cada corchete. Si un campo no tiene responsable, reloj, denominador o fuente de evidencia, todavía no es exigible.
Anexo de niveles de servicio para agentes de IA, [nombre del workflow]
Versión [1.0] · vigente desde [fecha] · responsable del servicio [nombre] · responsable del proveedor [nombre]
1. Alcance. Clases de tarea [lista], canales [lista], idiomas [lista], horario de servicio [zona], herramientas autorizadas [lista], volumen mensual previsto [rango], concurrencia máxima [valor] y usos excluidos [lista].
2. Tarea Elegible. Solicitud de producción aceptada con input, autenticación y configuración del cliente requeridos. Se excluyen tráfico de prueba, abuso documentado e input inválido causado por el cliente. No se eliminan reintentos, fallos de dependencias elegidas por el proveedor ni intentos fallidos.
3. Finalización Exitosa. El agente alcanza el resultado de negocio aprobado, cumple schema y políticas, usa solo herramientas autorizadas, no crea efectos duplicados o no autorizados, no contiene una Alucinación Material y llega a un estado final permitido dentro del límite de latencia. SLO mensual: ≥ [98,0]% de las Tareas Elegibles.
4. Alucinación Material. Afirmación, cita, argumento de herramienta o acción falsa, inventada, contradicha o sin apoyo que cambia, o podría razonablemente cambiar, el resultado o causar un daño económico, legal, de seguridad, privacidad, integridad física, cliente o reputación que sea material. SLO: 0 eventos de Severidad 1 no contenidos y ≤ [1,0]% de la muestra de calidad adjudicada.
5. Éxito de Tool Use. La herramienta autorizada prevista recibe argumentos válidos, se ejecuta una vez salvo reintento idempotente, devuelve un resultado verificado y crea el estado previsto. SLO: ≥ [97,0]% al primer intento y ≥ [99,0]% final. Cada intento y retry permanece en telemetría.
6. Latencia. Tiempo end-to-end desde la aceptación hasta finalización, rechazo seguro o handoff con contexto completo. Tareas interactivas: p50 ≤ [5] segundos, p95 ≤ [15] segundos, p99 ≤ [30] segundos. Tareas asíncronas: p95 ≤ [5] minutos. Time to first token se reporta aparte y no satisface la latencia de finalización.
7. Escalado y Handoff. El [100]% de los triggers obligatorios llegan a [cola] con resumen, fuentes, acciones intentadas, resultados, motivo, riesgo y siguiente paso recomendado. Acuse humano p95 ≤ [15] minutos durante [horario]. El reloj humano empieza cuando el paquete completo entra en la cola.
8. Dependencias y Modo Degradado. El Anexo [X] enumera dependencia, responsable, fallback y timeout. Si una dependencia no está disponible, el agente no inventará resultados ni repetirá efectos. Conservará el trabajo aceptado, activará el modo degradado y recuperará, rechazará o escalará en [tiempo].
9. Cambios. Set de evaluación, grader, prompt, modelo, proveedor, routing, fuente de retrieval, tool schema y guardrails se versionan. Un cambio material planificado requiere [30] días de aviso, informe de regresión sobre la baseline congelada y aprobación antes de producción. Un cambio de emergencia requiere aviso en [1] día laborable y rollback probado.
10. Evidencia y Retención. El proveedor entrega un informe SLO mensual y evidencia por tarea cuando se solicite. Las trazas filtradas para privacidad permanecen consultables [90] días y archivadas [12] meses, salvo otro plazo legal o contractual. Acceso, redacción, legal hold y borrado figuran en el Anexo [Y].
11. Severidad y Remedios. Severidad, acuse, contención, restauración, root cause, créditos, rollback, suspensión y rescisión siguen la tabla inferior. Los créditos no sustituyen remedios por confidencialidad, privacidad, seguridad, IP o acciones no autorizadas salvo pacto expreso.
Reglas de medición que evitan disputas
| Campo | Definición contractual |
|---|---|
| Ventana | Un mes natural en [zona horaria], con dashboards diarios y sin borrar fallos de forma retroactiva. |
| System of record | Telemetría del proveedor conciliada con IDs del cliente. El cliente puede exportar eventos métricos y registro de versiones. |
| Muestra de calidad | Muestra aleatoria estratificada de al menos [200] Tareas Elegibles al mes, más cada reclamación, override, acción de alto riesgo y sospecha de Alucinación Material. Con menos volumen se revisan todas y se declara la limitación. |
| Adjudicación | Validación determinista cuando sea posible y después una rúbrica documentada aplicada por reviewers formados. Ven la evidencia, no el resultado preferido del proveedor. Los conflictos pasan a [experto de dominio o tercero independiente]. |
| Segmentación | Informe por clase de tarea, idioma, canal, nivel de riesgo y versión de modelo. Un buen agregado no oculta un segmento crítico deficiente. |
| Exclusiones | Solo cuentan las exclusiones enumeradas. Cada tarea excluida conserva trace, reason code, evidencia y duración. "Problema de tercero" no basta. |
| Versiones | Cada medición identifica prompt, modelo, proveedor, herramienta, corpus, política y versión del set activos. |
La fórmula es sencilla a propósito: Tasa de Éxito = Tareas Elegibles exitosas / todas las Tareas Elegibles × 100. No uses runs finalizados como denominador. Eliminarías timeouts, loops bloqueados y handoffs fallidos, justo los fallos que el comprador paga por controlar.
1. Define el éxito como resultado de negocio
"El modelo devolvió una respuesta" no es finalización. Para soporte, éxito puede exigir una respuesta correcta basada en una fuente aprobada, una sola actualización del CRM y resolución correcta o entrada en la cola humana adecuada. Para facturas, puede exigir que todos los campos coincidan con el documento, se aplique la regla de confianza y ningún pago salga sin la aprobación indicada.
Escribe un predicado de finalización por clase. Un rechazo seguro puede ser comportamiento correcto, pero no debería contar como resultado completado salvo que el modelo comercial lo defina así. Reporta straight-through completion, rechazo seguro y handoff por separado para impedir que el proveedor cumpla escalando todo.
2. Convierte la alucinación material en una definición de severidad
El perfil de IA generativa de NIST usa confabulation para contenido falso o erróneo presentado con seguridad. El contrato necesita una prueba de materialidad más estrecha: ¿la afirmación o acción carece de apoyo o es falsa, y puede cambiar un resultado o causar daño relevante?
Un typo, defecto de estilo inocuo o incertidumbre correctamente etiquetada no es Alucinación Material. Una política de devolución inventada, cita legal inexistente, consentimiento no otorgado, cuenta bancaria errónea o tool call basado en estado ficticio sí. Un borrador falso capturado por un verificador obligatorio antes de cualquier efecto externo sigue siendo un defecto de calidad, pero no un evento de Severidad 1 no contenido. Conserva ambos contadores.
3. Mide tool use al primer intento y al resultado final
Medir solo el éxito final premia tormentas de reintentos. Medir solo el primer intento ignora una recuperación segura. Reporta ambos y conserva cada intento. Una llamada exitosa requiere herramienta autorizada correcta, argumentos válidos, permiso en el momento de ejecución, respuesta verificada y el cambio de estado previsto exactamente una vez.
Exige claves de idempotencia para refunds, reservas, emails y escrituras en bases de datos. Una llamada no autorizada, acción irreversible duplicada o bypass de aprobación obligatoria falla automáticamente y activa la severidad acordada aunque la API downstream responda success.
4. Incluye todo el workflow en el reloj de latencia
Mide la experiencia comprada, no el span más rápido del modelo. El reloj incluye routing, retrieval, llamadas al modelo, herramientas, validadores, retries y cola controlada por el proveedor. Solo termina con finalización, rechazo seguro o handoff completo. Entonces comienza un SLO separado para la respuesta humana.
La guía SRE de Google recomienda percentiles porque la media oculta la cola larga. Usa p50 para el caso típico, p95 para el compromiso operativo y p99 donde importe un peor caso plausible. Interacción, voz, batch y aprobaciones de alto riesgo necesitan objetivos diferentes.
5. Contrata el escalado y su paquete de contexto
Los triggers obligatorios deben ser reglas observables, no una sensación de confianza del modelo. Incluyen petición fuera de alcance, fuente necesaria ausente, herramienta de escritura fallida tras el retry budget, registros contradictorios, umbral de política, decisión regulada, petición de una persona, posible prompt injection o acción por encima de un valor de aprobación.
El handoff solo funciona cuando llega a la cola indicada con contexto suficiente para actuar sin reconstruir la conversación. Mide detección, routing, completitud, acuse, resolución y reapertura. La guía del ICO sobre revisión humana recomienda registrar overrides y motivos, evidencia útil para la siguiente revisión del set.
6. Asigna las dependencias no disponibles
Enumera API del modelo, vector store, proveedor de identidad, CRM, pagos, fuentes del cliente y cola humana. Para cada dependencia indica quién la eligió y controla, timeout, retry budget, fallback, conservación de datos y responsable del incidente.
Una caída controlada por el cliente puede excluirse del crédito de calidad durante el periodo probado, pero sigue en reporting de dependencias y modo degradado. Un proveedor de modelo elegido por el suministrador no puede convertirse en una exclusión general. Quizá no controle la caída, pero sí timeouts, circuit breakers, colas, fallback, prevención de duplicados y mensajes honestos.
7. Congela el set de evaluación sin congelar el aprendizaje
Versiona casos, resultados esperados, rúbricas, graders, pesos y sampling. Guarda un hash por release. Ninguna parte puede borrar un caso difícil, reclasificar un fallo o cambiar el grader solo para aprobar el sistema actual.
Los riesgos nuevos deben entrar. Usa reporte dual: ejecuta baseline congelada y set propuesto durante una ventana completa, muestra deltas por categoría, aprueba el cambio y fija la fecha de autoridad. Conserva un holdout oculto y comprueba contaminación. El NIST AI RMF pide sets, métricas y herramientas documentados, evaluación en condiciones similares a producción y monitorización continua.
8. Trata los cambios de modelo como releases de producción
Un cambio material incluye proveedor, familia, snapshot, routing, system prompt, tool schema, corpus, política de seguridad o grader. Fija versiones donde sea posible. La propia guía de compatibilidad de OpenAI advierte que el comportamiento puede cambiar entre snapshots y recomienda versiones fijadas más evals.
Exige aviso, regresión por segmento, revisión de seguridad si cambia la ruta de datos, deltas de coste y latencia, responsable de aprobar y rollback. Ante una retirada forzada, el proveedor debe presentar evidencia con tiempo para aprobar sucesor, activar fallback o suspender la clase afectada.
9. Conserva trazas probatorias sin conservarlo todo
Cada trace debe tener IDs de tarea y traza, clase, timestamps, actor y tenant, versiones de modelo y prompt, IDs y revisiones de documentos recuperados, herramienta y argumentos redactados, estado, retries, aprobaciones, handoff, disposición final, códigos métricos e incidente vinculado. Guarda prompt u output crudo solo si lo permite el anexo de datos.
La guía de observabilidad GenAI de OpenTelemetry muestra spans de agente, modelo y herramienta y advierte que los mensajes pueden contener datos sensibles. Regula acceso, redacción, región, legal hold, exportación y borrado junto a la retención. "Tenemos logs" no es auditoría si el cliente no puede recuperar evidencia.
10. Vincula severidad, contención y remedios comerciales
Estos valores son puntos de partida editables. Los tiempos deben ajustarse al riesgo, horario y precio del soporte.
| Nivel | Trigger de ejemplo | Compromiso operativo | Remedio contractual |
|---|---|---|---|
| Severidad 1, crítica | Acción irreversible no autorizada, datos personales expuestos, falsedad material no contenida con impacto grave, output inseguro generalizado o pérdida de evidencia. | Acuse en [15] minutos, desactivar o contener en [60] minutos, restaurar servicio seguro en [4] horas, avisar, preservar evidencia y entregar root cause y prevención en [5] días laborables. | Suspensión inmediata de la autonomía afectada, rollback a coste del proveedor, crédito del [25]% de la cuota afectada y derecho de rescisión tras [un] evento no remediado o [dos] repetidos en [seis] meses. |
| Severidad 2, mayor | SLO mensual de calidad o latencia incumplido, tool failure repetido, handoff roto para un segmento material o fallback inoperativo. | Acuse en [1] hora laborable, mitigación en [1] día, restauración en [2] días y plan correctivo en [5] días laborables. | Crédito del [10]% de la cuota mensual afectada por cada SLO core, límite del [25]% mensual y remediación obligatoria. [Tres] meses de incumplimiento en [seis] permiten rescindir. |
| Severidad 3, menor | Defecto aislado no material, metadata no crítica incompleta o informe tardío sin impacto. | Acuse en [1] día laborable y reparación en [10] días o release acordado. | Corrección y backlog. Eventos similares repetidos se agregan como Severidad 2. |
Los créditos deberían surgir automáticamente de evidencia compartida, no de una ventana de reclamación corta que solo el proveedor puede calcular. También necesitan escalado. Un 10% no hace aceptable un pago no autorizado. Para entidades financieras reguladas, el artículo 30 de DORA ofrece buena mecánica: niveles cuantitativos y cualitativos precisos, aviso de cambios, monitorización, auditoría, corrección y salida. DORA no aplica a todos, pero la mecánica es útil.
Por qué el SLA del proveedor de modelos no cubre al agente
El SLA upstream es una entrada de arquitectura, no el resultado del cliente. El SLA de Vertex AI define downtime mediante errores del servidor y ofrece créditos escalonados. No promete que un agente elija bien una herramienta, cite una fuente real o complete el proceso. Tu contrato debe convertir disponibilidad upstream en un diseño end-to-end y sumar calidad, handoff y auditoría.
Por eso el precio también pertenece junto a fiabilidad. Un fallback que mantiene el SLO a diez veces el coste puede proteger continuidad y destruir el business case. Mide el denominador con el coste por acción exitosa de un agente de IA y asigna retries, proveedor alternativo, retrabajo humano e incidentes.
Contexto de procurement y cumplimiento en la UE
No afirmes que esta plantilla hace compliant al sistema. Clasificación y obligaciones dependen del propósito y sector. Cuando aplican las reglas de alto riesgo, el texto oficial trata logging, supervisión humana, precisión, robustez y ciberseguridad en los artículos 12, 14 y 15 de la Ley de IA. La comunidad europea de compradores públicos publica además cláusulas contractuales modelo y advierte que no son un contrato completo.
El SLA comercial acompaña, no sustituye, DPA, anexo de seguridad, IP, restricciones de uso, roles regulatorios, seguro, responsabilidad y salida. La guía del ICO sobre contratos y terceros recomienda decidir la precisión aceptable antes de comprar e incluir KPIs o SLAs de precisión en contratos escritos.
"Lo difícil no es elegir 98% en vez de 97%. Es definir el denominador, conservar las trazas fallidas y acordar qué debe hacer el proveedor cuando el agente se equivoca con seguridad. Ahí una métrica se convierte en contrato."
Preguntas frecuentes sobre SLA de agentes de IA
¿Qué es un SLA para agentes de IA?
¿Cómo se mide la precisión de un agente de IA en un contrato?
¿Qué es una alucinación material?
¿Debe excluirse una caída del proveedor del modelo?
¿Qué pasa cuando cambia el set o el modelo?
¿Qué remedios incluye un SLA de IA generativa?
¿Es lo mismo un SLA de IA que los criterios de aceptación?
Reflexiones finales
Un buen SLA para agentes de IA vincula un workflow con un denominador, una cadena de evidencia y una consecuencia. No promete precisión abstracta. Declara qué tareas cuentan, qué significa terminar bien, qué errores son materiales, cuándo empieza el reloj humano, cómo se tratan dependencias y cambios, y qué debe el proveedor tras incumplir.
Completa los corchetes con evidencia de tu piloto, no con un benchmark comercial. Después pide a ingeniería que demuestre que trace, registro de evals, cola de handoff, rollback e informe mensual se pueden producir. Si el sistema no genera la evidencia, la cláusula es teatro.
Fuentes de investigación
Investigado y comprobado el 19 de julio de 2026. Estándares, términos de proveedores e implementación regulatoria cambian. Verifica la fuente vigente antes de firmar.
- NIST AI 600-1, Generative Artificial Intelligence Profile, confabulation y controles de riesgo.
- NIST AI RMF Core, sets documentados, evaluación similar a producción y monitoring.
- Reglamento (UE) 2024/1689, Ley de IA, artículos 12, 14 y 15.
- Reglamento (UE) 2022/2554, DORA, artículo 30 para entidades aplicables.
- ICO, Contracts and third parties in AI, due diligence de precisión, KPIs y auditoría.
- Google SRE Book, Service Level Objectives, indicadores, percentiles, ventanas y error budgets.
- Google Cloud Vertex AI Platform SLA, uptime, exclusiones y créditos.
- OpenTelemetry, GenAI observability, traces y datos sensibles.
- OpenAI API backward compatibility, snapshots, versiones fijadas y evals.
- AgentSLA: Towards a Service Level Agreement for AI Agents, marco de investigación para calidad de servicio agéntica.
¿Quieres diseñar SLA, evals y audit trail como un solo sistema de producción?
Hablar de tu Agente de IA