Cuando una empresa compra una máquina, sabe qué garantía tiene: dos años, piezas y mano de obra, un teléfono al que llamar. Cuando compra un proyecto de inteligencia artificial, la conversación se vuelve borrosa. ¿Qué pasa si el agente responde mal? ¿Y si el modelo empeora tras una actualización del proveedor? ¿Y si el sistema deja de funcionar seis meses después de la entrega?
La garantía de IA es exactamente eso: el conjunto de compromisos escritos que un proveedor asume sobre el comportamiento, la disponibilidad y el mantenimiento de un sistema de inteligencia artificial una vez está en producción. No es un detalle legal para el final del proceso. Es lo que separa un proyecto que aguanta tres años de un piloto bonito que nadie se atreve a tocar cuando falla.
En este artículo repasamos qué se puede garantizar de verdad, qué es humo, y qué cláusulas conviene revisar antes de firmar.
Por qué la IA no se garantiza como el software tradicional
En un desarrollo clásico, la garantía es relativamente sencilla de definir: el software cumple una especificación funcional. Si el botón "Guardar" no guarda, hay un defecto y el proveedor lo corrige. La conducta es determinista: la misma entrada produce siempre la misma salida.
Un sistema basado en modelos de lenguaje no funciona así. La misma pregunta puede recibir dos redacciones distintas. La calidad de la respuesta depende de los datos a los que el agente tiene acceso, del contexto de la conversación y, en parte, del propio modelo, que es un componente de terceros que se actualiza sin pedirte permiso.
Eso no significa que no se pueda garantizar nada. Significa que la garantía se formula de otra manera: en lugar de "el sistema nunca se equivoca", se garantizan umbrales medibles, procesos de corrección y límites de comportamiento. Un proveedor serio te dirá exactamente esto. Uno que te prometa "IA con 100% de acierto" está vendiendo algo que no existe.
¿Qué puede garantizar realmente un proveedor de IA?
Un proveedor solvente puede comprometerse por escrito con cinco cosas concretas. Primero, la disponibilidad del servicio: un porcentaje de uptime mensual con su correspondiente ventana de mantenimiento. Segundo, los tiempos de respuesta ante incidencias, diferenciados por gravedad. Tercero, un umbral de calidad medible sobre un conjunto de casos de prueba acordado contigo, por ejemplo un porcentaje mínimo de resoluciones correctas sobre 200 consultas representativas. Cuarto, la corrección sin coste de los defectos detectados durante el periodo de garantía. Y quinto, la trazabilidad: que puedas auditar qué hizo el sistema, cuándo y con qué datos. Lo que no puede garantizar es que el modelo jamás cometa un error, ni que un proveedor externo como OpenAI o Anthropic no cambie sus condiciones. Por eso el contrato debe cubrir qué pasa cuando eso ocurre.
El umbral de calidad: cómo se define sin discusiones
Aquí es donde la mayoría de contratos fallan. "El agente responderá correctamente" no es un criterio; es una invitación a discutir. La alternativa es construir, antes del arranque, un conjunto de evaluación: entre 100 y 300 casos reales de tu empresa, con la respuesta esperada validada por alguien de tu equipo.
Ese conjunto se convierte en el juez. El contrato fija un umbral (por ejemplo, resolución correcta en un porcentaje mínimo acordado de los casos, y ningún error de la categoría "grave") y define quién ejecuta la evaluación y con qué periodicidad. Si el sistema baja del umbral, se activa la garantía. Es objetivo, se automatiza y elimina el "a mí me parece que responde regular".
Las cifras concretas dependen del caso de uso. Un agente que clasifica correos internos puede convivir con un margen de error mucho mayor que uno que emite presupuestos vinculantes. Fijar el umbral es una decisión de negocio, no técnica.
Las siete cláusulas que conviene revisar antes de firmar
- Periodo de garantía y qué lo activa. Un plazo habitual en proyectos a medida va de tres a doce meses desde la puesta en producción. Debe quedar claro si cuenta desde la entrega o desde la aceptación formal.
- Definición de defecto. Distingue entre un fallo del sistema (el agente no responde, la integración con el CRM se cae) y una limitación conocida y aceptada (el agente no gestiona reclamaciones legales porque así se acordó). Sin esta distinción, cada desacuerdo se convierte en una negociación.
- Niveles de servicio y tiempos de respuesta. Clasifica las incidencias por criticidad y asigna a cada nivel un tiempo de primera respuesta y otro de resolución o mitigación.
- Dependencia de modelos de terceros. ¿Qué pasa si el proveedor del modelo sube precios, deprecia una versión o cambia su política de uso? El contrato debe prever la migración a un modelo alternativo y quién asume ese coste.
- Propiedad del código, los prompts y los datos. Es la cláusula más olvidada y la más cara de arreglar tarde. Debe quedar por escrito que el código, la configuración, los prompts y los datos generados son tuyos, y que puedes llevártelos si cambias de proveedor.
- Plan de salida. Un compromiso de entrega de documentación, credenciales y traspaso ordenado en un plazo determinado, incluso si la relación termina mal.
- Protección de datos y ubicación del tratamiento. Contrato de encargado de tratamiento conforme al RGPD, dónde se procesan los datos y si se usan o no para entrenar modelos de terceros.
¿Qué diferencia hay entre garantía, soporte y mantenimiento evolutivo?
Se confunden constantemente y cuestan cosas distintas. La garantía cubre que lo entregado funcione conforme a lo pactado: si hay un defecto, se corrige sin coste adicional durante el periodo acordado. El soporte es la atención continuada: alguien disponible para resolver dudas, atender incidencias y restablecer el servicio cuando algo se cae, normalmente con una cuota mensual. El mantenimiento evolutivo es otra cosa: añadir capacidades nuevas, conectar un sistema que antes no existía o adaptar el agente a un cambio de proceso. Eso no entra en garantía, porque no es un defecto sino trabajo nuevo. Mezclar los tres conceptos en una sola línea de presupuesto genera el clásico conflicto de "yo pensaba que esto estaba incluido". Sepáralos en el contrato y en la factura.
La garantía que sí depende de ti
Hay una parte incómoda de esta conversación: buena parte de la fiabilidad de un sistema de IA depende de la calidad de los datos y los procesos del cliente, no del proveedor.
Si el agente responde con información desactualizada porque el catálogo interno lleva ocho meses sin revisarse, eso no es un defecto del sistema. Si clasifica mal facturas porque el criterio contable cambió y nadie lo comunicó, tampoco. Un contrato bien hecho reconoce esta frontera y establece responsabilidades compartidas: qué mantiene el proveedor y qué mantiene la empresa.
En la práctica esto se traduce en tres compromisos por tu parte: designar un responsable interno del sistema, mantener actualizadas las fuentes de conocimiento que consulta el agente, y avisar de los cambios de proceso que le afecten. Cuesta poco y evita la mayoría de las discusiones de garantía.
¿Cómo se comprueba que la garantía se está cumpliendo?
Con métricas, no con sensaciones. Un sistema de IA en producción debe registrar cada interacción: qué se preguntó, qué respondió, qué fuentes consultó, cuánto tardó y si hubo escalado a una persona. Con ese registro se construye un cuadro de mando sencillo con cuatro indicadores: tasa de resolución autónoma, tasa de escalado, tiempo medio de respuesta y número de correcciones manuales. Revisándolo mensualmente se detecta la degradación antes de que la note un cliente. Si el proveedor no te entrega ese panel o no te da acceso a los registros, no tienes forma de reclamar nada: estarías firmando una garantía que no puedes verificar. Exige la observabilidad desde el primer día del proyecto, no como añadido posterior.
Una forma sencilla de plantearlo al proveedor
Si estás valorando propuestas, tres preguntas separan bastante bien el grano de la paja:
- ¿Sobre qué conjunto de casos vais a medir la calidad y quién lo valida?
- ¿Qué ocurre si el modelo que usáis deja de estar disponible o cambia de precio?
- ¿Qué me llevo si mañana decido cambiar de proveedor?
Las respuestas a esas tres preguntas dicen más sobre la seriedad de un proveedor que cualquier presentación comercial.
Conclusión
La garantía de IA no consiste en prometer perfección, sino en definir con precisión qué se mide, quién responde y cómo se corrige cuando algo falla. Umbrales medibles, tiempos de respuesta, propiedad del código y plan de salida: con esas cuatro piezas por escrito, un proyecto de inteligencia artificial deja de ser un salto de fe.
En MG Solutions diseñamos e implantamos agentes de IA y automatizaciones con criterios de aceptación acordados por escrito antes de empezar, panel de métricas desde el primer día y el código en tu poder. Si quieres revisar qué garantías tiene (o le faltan) tu proyecto actual, escríbenos y lo analizamos contigo.