
Su agente IA gestiona las solicitudes de presupuesto desde hace tres meses. Un lunes por la mañana devuelve respuestas vacías. Usted abre el contrato: describe un alcance, un precio, una duración. Nada sobre el plazo de restablecimiento, nada sobre quién contesta a las 8:30. Un SLA (acuerdo de nivel de servicio) existe precisamente para cubrir ese hueco. Pero debe estar escrito para un agente IA, no copiado de un contrato de alojamiento web.
Key Takeaways
- Un agente IA se apoya en tres capas (infraestructura, modelo, integración). Un porcentaje de disponibilidad anunciado sobre una sola capa no protege el conjunto.
- Exija plazos cifrados por nivel de criticidad, con las horas cubiertas y el punto de partida del reloj.
- Los créditos de servicio limitan la reparación: en un hiperescalador se reducen a un porcentaje de la factura mensual y constituyen el único recurso contractual.
- El SLA debe decir quién responde cuando el proveedor del modelo falla y en qué plazo el proveedor le avisa de un incidente.
- Dos cláusulas pesan tanto como los plazos: la notificación de incidente y la salida (prompts, registros, datos).
Un SLA de alojamiento no protege a un agente
Una web está caída o no lo está. Un agente IA, en cambio, puede responder a cada petición y decir cosas falsas. Esa diferencia cambia la naturaleza de los compromisos que hay que pedir.
Tres capas se superponen en un agente en producción:
- La infraestructura que ejecuta el servicio (servidor, contenedor, base de datos).
- El modelo que llama el agente, normalmente mediante una API de terceros.
- La integración que conecta el modelo con sus herramientas: mensajería, CRM, base de conocimiento y el prompt que enmarca el comportamiento.
Un contrato que promete 99,9 % de disponibilidad casi siempre habla de la primera capa. Las otras dos ya fallaban y nadie prometió nada. Una versión de modelo obsoleta, una cuota de llamadas agotada, un conector que devuelve un error silencioso: el agente está en pie, pero ya no trabaja.
La consecuencia práctica es simple. Antes de negociar una cifra, haga que se precise por escrito qué se mide, sobre qué capa y desde el punto de vista de quién.
Lo que esconde el porcentaje de disponibilidad
Los valores publicados por los grandes proveedores dan un orden de magnitud útil. En su acuerdo de nivel de servicio para Compute Engine, Google Cloud (SLA consultado el 13 de noviembre de 2026) distingue «a single instance of all other families» al 99,9 % e «instances in multiple zones» al 99,99 %.
La diferencia parece mínima. No lo es. Sobre un mes de 30 días, es decir 43 200 minutos:
- 99,99 % permite unos 4 minutos de indisponibilidad.
- 99,9 % permite unos 43 minutos.
- 99,5 % permite unas 3 horas 36.
Pasar de 99,9 a 99,5 multiplica por cinco el tiempo de parada tolerado, sin que el contrato cambie de nombre. Un SLA sin método de cálculo es un eslogan.
Cuatro preguntas resuelven este punto:
- ¿Qué periodo? Mes natural, trimestre, año móvil. Un cálculo anual borra tres malos meses.
- ¿Qué alcance? El servicio completo, una ruta de API, un recorrido de negocio concreto.
- ¿Medido por quién? Solo el proveedor, con sus sondas internas, o un tercero con un punto de medida externo.
- ¿Qué exclusiones? Mantenimiento planificado, fuerza mayor, caída del proveedor del modelo, error por su parte. La lista de exclusiones suele ser más larga que el compromiso.
Plazos de atención y de resolución por criticidad
Un porcentaje de disponibilidad no dice qué hacer cuando llega la avería. Hace falta una tabla con dos plazos distintos: la atención (alguien cualificado lo mira) y el restablecimiento (el servicio vuelve a funcionar). Confundir ambos es la trampa más habitual, porque un proveedor puede atender en diez minutos y restablecer en tres días.
Este es el tipo de tabla que debe figurar en el contrato. Los valores se negocian según la criticidad del proceso; los siguientes son una ilustración, no una norma de mercado.
| Nivel | Ejemplo para un agente | Atención | Restablecimiento previsto | Seguimiento |
|---|---|---|---|---|
| P1 | Agente inaccesible, proceso bloqueado | 1 hora laborable | 4 horas laborables | Actualización cada 2 horas |
| P2 | Una intención principal ya no funciona | 4 horas laborables | 1 día laborable | Actualización diaria |
| P3 | Molestia limitada, solución alternativa posible | 1 día laborable | 5 días laborables | Ticket |
| P4 | Solicitud de evolución, ajuste de prompt | 5 días laborables | Según planificación | Ticket |
Tres precisiones que debe obtener por escrito:
- Las horas cubiertas. 24/7, días laborables de 9:00 a 18:00, o una guardia de pago como opción. Un agente que responde a clientes el sábado necesita cobertura el sábado.
- El punto de partida del reloj. Desde la detección por el proveedor o desde su aviso. El segundo es más favorable y obliga al proveedor a instrumentar la supervisión.
- El canal de aviso. Una dirección de soporte genérica no es un canal de incidentes. Pida un número y un contacto nominativo para los P1.
Qué significa «restablecer» para un agente
En un servidor, restablecer significa que el servicio responde. En un agente puede significar cuatro cosas distintas: el servicio responde, responde correctamente, responde correctamente en los casos críticos, o la causa está corregida.
Pida la distinción entre solución provisional y corrección definitiva, con un plazo para cada una. Una solución provisional puede consistir en desactivar una habilidad del agente, lo que restablece el servicio y degrada el resultado. Debe saberlo antes, no durante el incidente.
Añada una cláusula de control de cambios. Un agente evoluciona a pequeños toques: un prompt ajustado, un modelo actualizado, un conector modificado. Sin procedimiento, el mismo cambio que corrige un caso puede romper otros veinte, y la responsabilidad se vuelve imposible de establecer. Un conjunto de pruebas de no regresión, ejecutado antes de cada cambio, convierte esa cláusula en un compromiso verificable.
Cuando el proveedor del modelo falla
Su proveedor casi nunca es dueño del modelo. Alquila un acceso a una API. Una caída, una subida de tarifas o una obsolescencia de versión en ese proveedor afectan a su agente sin que su proveedor haya cometido falta alguna.
La guía de la ANSSI sobre las recomendaciones de seguridad para un sistema de IA generativa (ANSSI, 29 de abril de 2024) aborda este punto cubriendo todo el ciclo de vida, del entrenamiento a la producción, incluidas las herramientas de IA de terceros. La lógica contractual se inspira en ella: no se puede prometer lo que no se controla, pero sí se puede prometer una reacción.
Tres compromisos que pedir:
- Conmutación. ¿Existe un modelo de respaldo, probado, con un plazo de conmutación anunciado? Si no, póngalo en el contrato en lugar de descubrirlo.
- Preaviso. ¿Con cuánto tiempo avisa el proveedor antes de la obsolescencia de una versión de modelo, y quién asume el coste de la adaptación?
- Transparencia sobre las dependencias. La lista de subcontratistas y proveedores de modelo, actualizada. Su jurista y su DPO también se la pedirán.
Los créditos de servicio no son un seguro
La mayoría de los SLA prevén créditos: si no se alcanza el nivel, el cliente recibe un abono en la factura. La escala de Google Cloud es explícita: los créditos van del 10 % al 100 % de la factura mensual del servicio afectado según la gravedad de la caída. El contrato añade que esos créditos son el único recurso del cliente en caso de incumplimiento del objetivo, «Customer's sole and exclusive remedy».
Dicho de otro modo, un mes entero de indisponibilidad se salda con un abono, no con una indemnización por la facturación perdida. Para un agente que gestiona solicitudes entrantes, ese techo es muy bajo.
Tres contramedidas, que conviene arbitrar con su jurista:
- Un crédito proporcionado al servicio prestado. Un abono sobre la suscripción es escaso si el agente es el único canal de pedidos.
- Una cláusula de continuidad. Plan de recuperación documentado, plazo de restauración de las copias de seguridad, pruebas anuales.
- Una penalización negociada aparte para los incidentes P1, con tope y un procedimiento de constatación.
Un proveedor serio aceptará discutir estos puntos. Un proveedor que rechaza todo plazo cifrado le está diciendo, sobre todo, que no tiene guardia.
La notificación de incidente, eslabón de su cumplimiento
Si el agente trata datos personales, el incidente también pasa a ser un problema normativo para usted. La CNIL recuerda que las organizaciones deben prever procedimientos para detectar una violación, contenerla, analizar los riesgos y determinar si procede notificar, en virtud de los artículos 33 y 34 del RGPD (CNIL). El plazo de notificación corre desde el momento en que usted tiene conocimiento de la violación. Cada hora que el proveedor tarda en avisarle es una hora consumida de su propio plazo.
Pida por tanto:
- un plazo de notificación de incidente en horas, no en días laborables;
- un contacto nominativo, localizable, y un procedimiento si esa persona está ausente;
- un informe posterior al incidente por escrito en pocos días: causa, alcance de los datos afectados, medidas adoptadas;
- la conservación de los registros durante el tiempo suficiente para reconstruir el incidente.
La salida, la cláusula más descuidada
Un SLA solo vale si usted puede marcharse. Pida qué recupera, en qué formato y en qué plazo: prompts e instrucciones de sistema, conjuntos de pruebas, registros de ejecución, documentación de los conectores, historial de conversaciones útil para la auditoría. Precise también la propiedad de esos elementos y el tiempo durante el cual el proveedor debe conservar sus datos tras el fin del contrato. En este terreno, la reversibilidad de un agente IA merece tratarse como un entregable, con fecha.
El contrato de mantenimiento responde a otra pregunta, la del esfuerzo recurrente: qué está incluido, qué se factura, con qué frecuencia se reevalúa el agente. Los dos documentos se complementan, y qué debe prever el contrato de mantenimiento detalla ese aspecto.
Lo que ningún SLA resolverá
Tres temas quedan fuera, y conviene saberlo antes de firmar.
La calidad de las respuestas. Ningún porcentaje de disponibilidad dice si el agente responde bien. Eso se trata con un protocolo de evaluación: muestra de casos reales, revisión humana, umbral de aceptación, frecuencia. Pídalo como anexo, no como promesa.
La seguridad. El SLA habla de disponibilidad, rara vez de seguridad. Las medidas esperadas (aislamiento, control de acceso, registro, gestión de secretos) pertenecen al contrato y al anexo de seguridad. La guía de la ANSSI citada más arriba ofrece un marco de trabajo útil para la revisión.
El aumento de carga. Un agente que aguanta 50 conversaciones al día puede saturarse a 500. Pida las cuotas de llamadas al modelo, qué ocurre en un pico y el coste marginal. Un agente cuyo coste por petición se duplica en temporada alta se retira rápido.
Preguntas que hacer antes de firmar
- ¿Qué capas cubre el compromiso de disponibilidad y con qué método de cálculo?
- ¿Cuáles son los plazos de atención y restablecimiento para un P1, en horas laborables o en 24/7?
- ¿Quién mide la indisponibilidad, con qué sondas, y se puede acceder a los registros?
- ¿Qué ocurre si el proveedor del modelo cambia sus tarifas o declara obsoleta una versión?
- ¿Cuál es el plazo de notificación en caso de incidente de seguridad y quién llama a quién?
- ¿Qué recupera en caso de salida, en qué formato y en qué plazo?
- ¿Los créditos de servicio son el único recurso y cubren el servicio prestado o solo la suscripción?
Estas respuestas caben en dos páginas de anexo. Un proveedor que las facilita antes de la firma le ahorra semanas. Para situar el nivel de exigencia que cabe esperar de un socio, las preguntas que hacer a una agencia IA completan esta lista en el plano del proyecto.
Preguntas frecuentes
¿Es obligatorio un SLA para un agente IA?
No. En Francia nada impone un acuerdo de nivel de servicio y se aplica la libertad contractual. La obligación se desplaza: si el agente alimenta un proceso crítico, la ausencia de plazos escritos se convierte en un riesgo que usted asume solo, sin recurso identificable en caso de caída.
¿Qué nivel de disponibilidad pedir para un agente interno?
Depende del uso. Un asistente que ayuda a redactar notas soporta algunas horas de parada. Un agente que recibe las solicitudes entrantes o genera presupuestos necesita una cobertura amplia y un plazo de restablecimiento corto. La cifra importa menos que la coherencia entre el nivel prometido, las horas cubiertas y el plan de continuidad.
¿Bastan los créditos de servicio como compensación?
Rara vez. Un crédito recae sobre la factura del servicio, mientras que el perjuicio suele estar en la facturación o en la carga de trabajo internalizada. Para un uso crítico, añada un plan de continuidad probado y, si la relación de fuerzas lo permite, una penalización negociada.
¿Qué hacer si el proveedor rechaza todo plazo cifrado?
Pida al menos tres cosas: una guardia nominativa para los incidentes bloqueantes, un plazo de notificación de incidente y un informe posterior al incidente. Si nada es posible, reduzca la dependencia: haga documentar el agente, conserve el control de los prompts y prevea una solución de respaldo. Una auditoría técnica antes de la firma aclara a menudo esa decisión, y nuestra página de auditoría describe este tipo de intervención.
Conclusión
Un SLA útil no promete lo imposible. Describe quién reacciona, en cuánto tiempo, sobre qué capa y qué recupera usted si la relación termina. Para un agente IA, esa descripción debe cubrir el modelo y la integración, no solo el servidor que los aloja.
La secuencia correcta tiene tres etapas. Escriba primero el nivel de servicio que exigen sus procesos, no el del catálogo del proveedor. Haga cifrar después los plazos y las exclusiones. Verifique por último el contrato con una prueba real: simule una caída y observe quién llama.
NexeAI diseña y mantiene agentes IA para pymes, con los compromisos de servicio escritos en el proyecto: nuestros agentes IA y nuestra oferta de automatización parten del proceso que hay que sostener, no de un paquete. Si debe encuadrar estas cláusulas en un proyecto en curso, escríbanos mediante la página de contacto.


