Quién se hace cargo de un agente de IA después del piloto

29 de octubre de 2026

Tu piloto de IA funciona. El equipo quiere seguir utilizándolo y otro departamento pregunta cuándo podrá disponer del mismo servicio. Entonces alguien pregunta quién se ocupará de una respuesta inadecuada a un cliente, de una factura mensual que no deja de crecer o de un cambio de proveedor cuando el equipo del proyecto pase a otra cosa. La sala se queda bastante más callada.

Ese es el traspaso que conviene planificar antes de ampliar el servicio. Este artículo explica cómo asignar responsabilidades, presupuestar el soporte continuo y acordar las comprobaciones que mantienen útil un servicio de IA. El objetivo es contar con un servicio fiable, costes más previsibles y una base clara para decidir si conviene ampliarlo.

Asigna un responsable de negocio al servicio

Designa a una persona que responda por el resultado de negocio. En el caso de un agente de atención al cliente, podría ser quien dirige las operaciones de atención al cliente. Debe hacerse cargo de los objetivos del servicio, los límites de lo que el agente puede hacer y la decisión de ampliar o suspender su uso. Un proveedor puede gestionar la tecnología; la empresa sigue necesitando a alguien que decida si el servicio está cumpliendo su función.

Esa persona necesita tiempo, presupuesto y autoridad para cambiar el proceso. Asignar responsabilidades sin esos recursos es una forma optimista de delegar. Un comité de dirección puede resolver las decisiones de mayor alcance, pero debe ser fácil saber quién se ocupa del día a día.

Distingue esa responsabilidad por los resultados del trabajo de mantener el servicio en funcionamiento. Acuerda quién atiende las preguntas del personal, quién mantiene las integraciones y los accesos, quién prueba los cambios y quién contacta con el proveedor. Los equipos pequeños pueden combinar funciones. Lo importante es que cada responsabilidad tenga una persona asignada y un suplente.

El marco voluntario de gestión de riesgos de IA del NIST ofrece una base útil: pide responsabilidades claras y una revisión continua durante toda la vida de un sistema. La lista de comprobación para el traspaso que propone este artículo es una forma práctica de aplicar ese principio; no es una certificación del NIST ni una norma universal para poner servicios en marcha.

Acuerda qué está aceptando el equipo

Una demostración satisfactoria muestra que un agente puede hacer un trabajo útil. La aceptación para su uso en producción debe demostrar que la empresa puede confiar en él dentro de un alcance acordado y gestionar las excepciones. Documenta las tareas que realizará, la información que necesita y las acciones que seguirán en manos de las personas.

Pensemos en un mayorista hipotético cuyo agente responde a consultas sobre entregas. El responsable de operaciones acepta las actualizaciones rutinarias del estado de los pedidos a partir de registros vigentes. Los cambios de dirección de entrega y las compensaciones siguen en manos del personal autorizado. Una persona designada como responsable de soporte recibe los casos con registros contradictorios o información incompleta. Estos límites facilitan calcular los costes del servicio, explicarlo y prestarle soporte.

Utiliza casos realistas para comprobar el traspaso, incluidos los complicados: un sistema de pedidos no disponible, información de entrega desactualizada y un cliente que solicita una acción fuera del alcance acordado. Examina qué ocurrió realmente con el caso y los registros relacionados, además de comprobar si la respuesta sonaba tranquilizadora.

Las orientaciones de evaluación de Anthropic distinguen el mensaje final de un agente del resultado en el sistema subyacente y recomiendan repetir las pruebas porque los resultados pueden variar. Para el responsable de negocio, la pregunta útil es si los casos representativos se resuelven correctamente, con la consistencia suficiente para el uso previsto y con la intervención humana acordada.

Presupuesta el servicio que quieres operar

Mantén separado el presupuesto de operación del presupuesto de desarrollo. Incluye los costes del modelo y del alojamiento, las licencias de software, el mantenimiento de las integraciones, el tiempo de revisión del personal, el soporte, la evaluación y las mejoras. Pregunta qué costes aumentan con la demanda y cuáles se mantienen incluso en un mes de poca actividad.

Asigna a una persona la responsabilidad de revisar el uso y los costes. Acuerda un umbral de alerta, quién puede aprobar gastos adicionales y qué ocurre si la demanda supera el presupuesto. Una alerta de gasto sobre la que nadie tiene que actuar es solo otro correo electrónico.

Mide el coste junto con el trabajo útil completado y la calidad del servicio. Si el agente atiende más solicitudes, pero el personal dedica más tiempo a corregirlas, hay que examinar esa aparente ganancia de capacidad. Si se libera tiempo del personal, decide a qué se destinará: reducir tareas pendientes, mejorar el servicio o evitar horas extra. No se convierte automáticamente en un ahorro económico.

Para el mayorista hipotético, una revisión mensual del servicio podría comparar las consultas resueltas correctamente, el tiempo de espera de los clientes, los minutos de trabajo del personal por caso y el coste total de operación. Estas métricas son propuestas de gestión, no resultados obtenidos por Nieve ni promesas de mejora.

Asigna a alguien la decisión sobre los cambios

Un servicio de IA puede cambiar aunque su interfaz visible siga igual. Una actualización del modelo, una instrucción revisada, una nueva fuente de datos o un cambio en una política de la empresa pueden modificar sus respuestas y acciones. Decide quién solicita los cambios, quién los prueba y quién acepta sus efectos en el negocio antes de que lleguen a los usuarios.

Mantén un registro breve de qué cambió, por qué, qué comprobaciones se realizaron y quién autorizó su puesta en producción. Utiliza los mismos casos representativos para comparar el comportamiento antes y después de un cambio, y añade casos nuevos cuando el personal detecte un problema. Acuerda cómo volver a una configuración que se sabe que funciona o suspender la actividad afectada.

El responsable de negocio debe decidir si una ampliación propuesta cambia las responsabilidades del servicio. Consultar el estado de una entrega y modificar un pedido implican compromisos diferentes. Trata los permisos o las tareas adicionales como decisiones que hay que evaluar, en lugar de como una pequeña petición funcional que se cuela entre las tareas de mantenimiento rutinario.

Ensaya esa tarde complicada

Antes del traspaso, pide al equipo que operará el servicio que simule un fallo. ¿Quién detecta las actualizaciones incorrectas? ¿Quién puede detener nuevas acciones? ¿Cómo identificará el personal los casos ya afectados? ¿Quién informa a los clientes de lo ocurrido y quién decide cuándo puede reanudarse el servicio?

Un acuerdo de soporte útil debe indicar cómo comunicar un problema, qué información aportar, el horario de atención y la respuesta esperada. Aclara la diferencia entre acusar recibo de una incidencia y restablecer el servicio. Identifica un contacto de respaldo y una alternativa manual para el trabajo esencial.

Ofrece al personal una vía sencilla para comunicar problemas y formación suficiente para reconocer cuándo el agente se sale de su alcance. Comprueba si pueden suspender un caso afectado o derivarlo al responsable adecuado sin esperar a que vuelva de vacaciones la persona que desarrolló el proyecto. Es una comprobación de preparación más útil que una carpeta que nadie ha abierto.

Distingue la propiedad del código de la responsabilidad operativa

El equipo de compras debe plantear dos preguntas: ¿qué posee la empresa o utiliza bajo licencia y quién mantendrá cada parte? Ser propietario del código a medida no proporciona por sí solo soporte, documentación, credenciales de acceso ni las capacidades necesarias para modificarlo.

El modelo de prestación de AIGENCORE publicado por Nieve distingue los componentes de plataforma bajo licencia de los módulos a medida que son íntegramente propiedad del cliente. También describe el despliegue, la formación, la documentación y el soporte. El traspaso debe identificar qué componentes pertenecen a cada categoría y confirmar el alcance real del soporte en el acuerdo del proyecto.

Documenta quién controla el alojamiento, las cuentas conectadas y el acceso a los datos; quién puede revocar permisos cuando cambian las personas o los proveedores; y cómo asumiría el servicio otro equipo. Incluye revisiones de acceso y los pasos prácticos para exportar datos o retirar el servicio. Son decisiones operativas que deben resolverse con los equipos y proveedores pertinentes, en lugar de dejarlas como supuestos implícitos en una declaración general de propiedad.

Utiliza una lista breve para el traspaso

Antes de ampliar el piloto, pide al equipo receptor que confirme por escrito los siguientes puntos. El nivel de detalle debe ajustarse a la importancia del servicio: un asistente interno de bajo riesgo y un servicio que modifica registros de clientes necesitan distintos niveles de garantía.

Responsabilidad: un responsable de negocio designado, contactos operativos, suplentes y autoridad para suspender o modificar el servicio.
Aceptación: tareas y límites acordados, resultados de pruebas representativas y una vía clara para gestionar las excepciones.
Costes: un presupuesto de operación, métricas de uso, alertas de gasto y un responsable de las decisiones sobre costes.
Cambios y accesos: personas designadas para decidir, pruebas antes de la puesta en producción, un procedimiento de recuperación y responsabilidad sobre la revisión de permisos.
Soporte: contactos, horarios y expectativas de respuesta documentados, formación del personal y un proceso de gestión de incidencias ensayado.
Continuidad: un inventario de componentes propios y bajo licencia, documentación esencial y un plan viable de transferencia o retirada del servicio.

Si falta alguna respuesta, asigna un responsable y una fecha antes de ampliar la parte afectada del servicio. Un despliegue limitado puede seguir siendo razonable cuando los límites y el soporte están claros. La decisión debe ser explícita.

Un buen traspaso facilita la mejora continua. Empieza por un responsable designado, un presupuesto de operación realista y pruebas de que el equipo receptor puede operar el servicio y afrontar los problemas. Después, utiliza los resultados reales del servicio para decidir qué mejorar o ampliar. Un agente de IA ha dejado atrás el piloto cuando alguien ha aceptado la responsabilidad de lo que ocurra a continuación.

Ideas clave

Asigna a un responsable de negocio la responsabilidad por los resultados del servicio, con autoridad, tiempo y presupuesto para actuar.
Acepta un alcance operativo definido y prueba resultados realistas, incluidos los fallos y las excepciones.
Presupuesta la revisión, el soporte y el mantenimiento, además del uso del modelo; evalúa el coste por caso útil completado.
Asigna responsabilidades sobre cambios, accesos e incidencias, y ensaya cómo el personal suspenderá y recuperará el servicio.
Distingue el código propio de los componentes bajo licencia y confirma quién prestará soporte a cada parte.