Un asistente de inteligencia artificial puede responder preguntas frecuentes, buscar información en documentos y ayudar a clasificar solicitudes. Pero una demostración que conversa con fluidez no equivale a un canal de atención preparado para clientes reales.
La diferencia está en el sistema que rodea al modelo: fuentes actualizadas, permisos, reglas de derivación, protección de datos, pruebas y responsables capaces de intervenir. El perfil de riesgos para IA generativa de NIST advierte que estos sistemas pueden generar contenido falso o inconsistente con apariencia convincente. Por eso, el objetivo no debe ser conseguir que el asistente responda siempre, sino que responda dentro de límites definidos y reconozca cuándo no corresponde hacerlo.
Un buen asistente no es el que improvisa más respuestas, sino el que sabe dónde buscar, qué puede hacer y cuándo debe pedir ayuda.
Empezá por una función concreta, no por un chatbot general
“Atender clientes” es un alcance demasiado amplio. Incluye consultas informativas, reclamos, cambios de datos, operaciones con dinero, decisiones comerciales y situaciones que pueden requerir empatía o interpretación. Cada una presenta riesgos diferentes.
Conviene comenzar con un recorrido delimitado, por ejemplo: explicar modalidades de entrega, orientar sobre documentación necesaria, informar el estado de una solicitud autenticada o reunir datos iniciales antes de transferir la conversación.
Definí tres zonas de actuación
- Permitida: preguntas que el asistente puede resolver utilizando información aprobada.
- Condicionada: acciones que requieren autenticación, confirmación explícita o revisión humana.
- Prohibida: decisiones, promesas, cambios o respuestas que el sistema no debe realizar.
Esta división evita que la capacidad del modelo determine por sí sola el alcance. También permite documentar quién es responsable de cada excepción, una práctica coherente con el enfoque de gobernanza y supervisión del NIST AI RMF Playbook.
Construí una fuente de verdad antes de conectar la IA
El asistente necesita saber qué información puede utilizar y cuál tiene prioridad. No alcanza con entregarle carpetas completas, historiales de conversaciones o documentos acumulados durante años. Esos materiales suelen contener duplicados, contradicciones, versiones vencidas y datos que no deberían exponerse.
Para cada fuente, registrá:
- el tema y las preguntas que puede responder;
- su propietario interno;
- la fecha de actualización;
- su nivel de confidencialidad;
- qué usuarios pueden consultarla;
- qué documento prevalece cuando existen diferencias.
Una implementación habitual recupera fragmentos autorizados de una base documental y los incorpora al contexto de la respuesta. Este enfoque puede mejorar la pertinencia, pero no garantiza exactitud. El asistente debe poder abstenerse si no encuentra evidencia suficiente y, cuando sea útil para el usuario, indicar la fuente o la fecha de la información.
Separá conversación, permisos y acciones
El modelo puede interpretar una solicitud, pero no debería decidir por sí mismo qué datos tiene permitido leer ni qué operación puede ejecutar. La autenticación, la autorización y las reglas comerciales deben aplicarse fuera del modelo mediante controles verificables.
Esta separación es especialmente importante si el asistente consulta pedidos, modifica turnos, crea tickets o interactúa con sistemas internos. El OWASP Top 10 para aplicaciones con modelos de lenguaje incluye riesgos como la inyección de instrucciones, la divulgación de información sensible y la autonomía excesiva.
Controles mínimos para una integración
- Aplicar el principio de menor privilegio a cada herramienta conectada.
- Validar identidad, permisos y parámetros antes de ejecutar una acción.
- No guardar contraseñas, claves o secretos dentro de las instrucciones del asistente.
- Solicitar confirmación antes de operaciones con consecuencias para el cliente.
- Registrar acciones y resultados sin almacenar datos innecesarios.
- Establecer límites de uso, tiempo y costo.
- Ofrecer una forma de detener o revertir la automatización.
Diseñá la privacidad y la derivación humana como partes del servicio
Antes de recopilar datos, preguntá cuáles son realmente necesarios para resolver la consulta. También debe definirse dónde se procesan, cuánto tiempo se conservan, quién puede acceder, qué queda en los registros y cómo se atienden solicitudes relacionadas con esos datos.
La guía sobre IA y protección de datos del ICO organiza estas decisiones alrededor de principios como transparencia, finalidad, minimización, exactitud, seguridad y responsabilidad. Aunque las obligaciones legales dependen de cada jurisdicción, estos criterios son una referencia práctica para diseñar el sistema.
La persona usuaria debería saber que interactúa con un sistema automatizado, qué función cumple y cómo solicitar atención humana. La transferencia no puede ser una salida decorativa: debe enviar el contexto necesario al equipo para evitar que el cliente repita todo.
Casos que suelen requerir derivación
- El asistente no encuentra una fuente suficiente o detecta información contradictoria.
- La consulta incluye un reclamo sensible, una excepción o una amenaza.
- Se requiere interpretar documentación o tomar una decisión de impacto significativo.
- La identidad o los permisos no pueden verificarse.
- El cliente pide hablar con una persona.
Probá conversaciones reales y medí calidad, no solamente volumen
Antes del lanzamiento, reuní preguntas reales y variantes: expresiones incompletas, errores ortográficos, cambios de tema, intentos de obtener datos ajenos y solicitudes fuera de alcance. Cada prueba debería indicar la respuesta esperada, las fuentes admitidas y si corresponde responder, abstenerse o derivar.
No existe una única métrica suficiente. Un tablero operativo puede combinar:
- respuestas respaldadas por fuentes autorizadas;
- errores críticos y respuestas inventadas;
- derivaciones correctas e incorrectas;
- consultas resueltas sin contacto posterior por el mismo motivo;
- acciones canceladas, rechazadas o corregidas;
- tiempo de respuesta y costo por interacción;
- comentarios de clientes y agentes humanos.
Los objetivos deben establecerse según el impacto del proceso. Una equivocación en el horario de atención no tiene la misma consecuencia que modificar una reserva, informar una deuda o interpretar una condición contractual.
Checklist para pasar de una prueba a producción
- Documentar el objetivo, los usuarios y los límites del asistente.
- Nombrar responsables de contenido, operación, privacidad y seguridad.
- Ordenar las fuentes y establecer un proceso de actualización.
- Definir permisos y validaciones para cada integración.
- Crear reglas claras de abstención y derivación humana.
- Preparar un conjunto de pruebas normales, ambiguas y adversarias.
- Fijar métricas, umbrales de alerta y criterios para detener el sistema.
- Lanzar primero en un alcance reducido y revisar conversaciones.
- Registrar incidentes, correcciones y cambios de versión.
La implementación no termina cuando el asistente empieza a conversar. Las políticas cambian, las fuentes envejecen y aparecen formas nuevas de usar o forzar el sistema. La revisión continua es parte del producto.
Próximo paso: elegí un recorrido de atención acotado y completá este checklist con las personas que administran el proceso. Si necesitás diseñar las fuentes, integraciones y controles como una solución empresarial, Ideasweb desarrolla soluciones de inteligencia artificial adaptadas a cada operación.
