Un asistente puede redactar una respuesta convincente y, al mismo tiempo, prometer una devolución que la empresa no ofrece. Si nadie sabe quién revisa esa respuesta, qué información utilizó o cómo detener el envío, el problema también está en la forma de gestionar el servicio.
La gobernanza de IA en Customer Experience consiste en definir quién puede usar cada sistema, para qué tareas, con qué datos y bajo qué controles. Abarca el recorrido completo: selección de herramientas, pruebas, operación, cambios y retirada cuando un uso deja de ser adecuado.
El AI Risk Management Framework de NIST es una referencia voluntaria para gestionar riesgos de IA. Su estructura organiza el trabajo en gobernar, comprender el contexto, medir y gestionar. La propuesta operativa de esta guía adapta esa lógica a situaciones de atención al cliente; no constituye una certificación de cumplimiento.
Haz visible dónde se está usando IA
Empieza con un inventario sencillo. Incluye asistentes de atención, herramientas de transcripción, clasificación de comentarios, generación de respuestas y aplicaciones que los colaboradores utilizan por iniciativa propia.
Por cada uso, registra su responsable, propósito, proveedor, información que recibe, salida que produce y sistemas sobre los que puede actuar. Distingue redactar una sugerencia de ejecutar una acción: un texto que revisa un agente tiene consecuencias distintas de un sistema capaz de emitir reembolsos.
La llamada IA no autorizada puede aparecer cuando una herramienta resuelve una necesidad real que la empresa todavía no ha atendido. Investiga esa necesidad y ofrece un camino claro para evaluar herramientas. Una regla que el equipo no entiende o no puede cumplir termina siendo difícil de sostener.
Asigna responsabilidades concretas
| Responsabilidad | Decisión que debe poder tomar |
|---|---|
| Responsable del servicio | Delimitar el problema del cliente y aceptar o rechazar el uso |
| Responsable de la información | Mantener políticas, respuestas y documentos de referencia |
| Responsable técnico | Controlar acceso, integraciones, registros y cambios |
| Supervisión de calidad | Evaluar respuestas y detectar patrones de error |
| Responsable de incidentes | Suspender el uso afectado y coordinar la recuperación |
En una empresa pequeña una persona puede asumir varias funciones. Aun así, conviene escribir qué le corresponde y quién la sustituye. “Lo ve tecnología” no resuelve quién responde ante una promesa comercial incorrecta.
Define permisos según la consecuencia de equivocarse
Como criterio inicial, separa los usos internos de apoyo, las respuestas revisadas por una persona y las acciones automatizadas. La decisión no depende solo del nombre del modelo: también depende de los datos, la tarea y el impacto de un error.
Por ejemplo, resumir comentarios previamente desidentificados puede admitir un circuito distinto al de modificar una reserva. Para una operación que cambie un pedido, establece qué acción está permitida, qué límites tiene, qué confirmación necesita y cómo se revierte.
Evita que un asistente amplíe sus permisos porque un mensaje del cliente se lo solicite. Las instrucciones recibidas en conversaciones o documentos deben tratarse como información a procesar, no como autorización para cambiar las reglas del negocio.
Establece reglas sobre datos y fuentes
Define qué información puede entrar en cada herramienta y para qué finalidad. Revisa quién puede acceder a ella, cuánto tiempo se conserva y qué condiciones ofrece el proveedor. La privacidad de datos en CX e IA debe formar parte de esa evaluación desde el inicio.
Un agente que solo necesita resumir el motivo de una consulta no debería copiar por defecto el expediente completo. Para pruebas, puedes utilizar situaciones ficticias o material preparado para ese propósito.
También necesitas gobernar las fuentes de respuesta. Asigna una persona que mantenga las políticas de cambios, devoluciones y precios. Registra su versión y vigencia. Una respuesta basada en información desactualizada puede sonar correcta y conducir al cliente a una decisión equivocada.
Prueba los casos difíciles antes de ampliar el uso
Prepara una colección de situaciones representativas del servicio: preguntas frecuentes, mensajes ambiguos, información que falta, clientes molestos, políticas contradictorias y solicitudes fuera de alcance. Incluye variaciones de lenguaje que realmente encuentre tu equipo.
Para cada caso, define qué respuesta sería aceptable, cuándo corresponde pedir aclaración y cuándo debe intervenir una persona. Revisa tanto la exactitud como la capacidad de reconocer límites. El perfil de IA generativa de NIST desarrolla riesgos y acciones de gestión específicos de estos sistemas, incluidos problemas de información generada, privacidad y relación entre personas e IA.
No uses una puntuación promedio para ocultar un fallo que el servicio considera inaceptable. Una promesa de devolución indebida puede exigir un bloqueo aunque otras respuestas sean satisfactorias.
Mantén una salida hacia atención humana
Establece condiciones observables para escalar: el cliente pide hablar con alguien, el sistema no tiene información suficiente, hay una excepción a la política o se repite una respuesta sin resolver el problema.
El traspaso debería conservar el contexto necesario para que el cliente no tenga que empezar de nuevo. Explica qué ocurrirá después y comunica expectativas realistas. Un canal automatizado también debe contemplar qué pasa cuando no hay agentes disponibles.
Mide la resolución, no solo la automatización
Puedes seguir consultas resueltas, contactos repetidos, correcciones humanas, escalaciones apropiadas y satisfacción tras la atención. Define cada indicador antes de comparar periodos; por ejemplo, qué ventana usarás para considerar que un cliente tuvo que volver por el mismo asunto.
La resolución en el primer contacto y el esfuerzo del cliente ayudan a formular preguntas sobre el resultado del servicio. Reducir conversaciones con agentes no demuestra por sí solo que las necesidades quedaron resueltas.
Prepara la respuesta a incidentes
Imagina que un asistente empieza a ofrecer una compensación inexistente. Un procedimiento operativo podría contemplar detener esa respuesta, conservar la evidencia necesaria, identificar las conversaciones afectadas y asignar a una persona la comunicación con los clientes. Es un ejemplo hipotético para preparar el proceso, no un caso de resultados comprobados.
Después, corrige la fuente o configuración que contribuyó al problema, añade el caso a las pruebas y define quién autoriza la reanudación. Revisa también si otros usos comparten la misma debilidad.
Un primer piloto puede ser una sola tarea, con permisos limitados y revisión humana. Amplía el alcance cuando puedas explicar con evidencia qué funciona, qué límites permanecen y quién responde cuando algo falla.