Cómo crear un ciclo de feedback para un AI Sales Copilot B2B

Qué es un ciclo de feedback de IA y qué problema resuelve

Un botón de pulgar arriba o abajo no constituye por sí mismo un sistema de mejora. El ciclo comienza cuando una observación puede relacionarse con una tarea, una versión y un efecto; continúa con una investigación reproducible; y termina cuando existe una decisión verificable. El objetivo no es acumular opiniones, sino reducir fallas conocidas sin introducir otras nuevas.

En un copiloto comercial, una respuesta insatisfactoria puede proceder de capas diferentes. La nota del CRM puede estar vencida, la recuperación puede omitir el catálogo correcto, una instrucción puede ser ambigua, una herramienta puede recibir argumentos incorrectos o la interfaz puede ocultar que falta una moneda. Cambiar el modelo antes de identificar la causa suele mover el síntoma y deja el problema operativo intacto.

NIST recomienda documentar errores e impactos, revisar si las métricas y controles siguen siendo suficientes y utilizar la retroalimentación de usuarios para actuar. Microsoft relaciona observabilidad, trazas, evaluación y monitoreo como capacidades complementarias para entender y mejorar el comportamiento de una aplicación de IA durante su ciclo de vida.

Separa feedback, defecto, dato incorrecto, incidente y solicitud

No todos los reportes siguen la misma ruta. Una preferencia de estilo puede resolverse en producto o capacitación. Un precio inventado es una falla crítica aunque la persona lo detecte antes de compartir. Un acceso indebido, una divulgación o una acción externa puede exigir contención inmediata y activar el proceso de incidentes. Mezclar estas categorías retrasa los casos urgentes y llena el backlog técnico con solicitudes que pertenecen al proceso comercial.

Clasifica primero por efecto observable, no por la explicación inicial. El usuario puede escribir que la IA alucinó cuando en realidad el CRM contiene dos versiones del mismo dato. También puede reportar un dato viejo como problema de integración cuando la fuente autorizada nunca definió una vigencia. Conserva el lenguaje original y añade después una clasificación provisional.

Captura un reporte que otra persona pueda investigar

Pide la mínima información que permita reconstruir el trabajo: qué intentaba hacer la persona, qué esperaba, qué observó y qué hizo después. Relaciona el reporte con el identificador de la ejecución, la versión del recorrido y los objetos comerciales relevantes. Evita obligar al vendedor a copiar prompts extensos, datos personales o documentos completos en un formulario paralelo.

Distingue entre la salida visible y su efecto. Un borrador descartado, una nota guardada, una etapa modificada y un correo compartido tienen impactos distintos. Registra también si la persona corrigió el resultado, utilizó otro proceso, detuvo el trabajo o avisó a alguien. Esa acción posterior ayuda a priorizar y a saber si todavía existe exposición.

Permite reportar desde el punto de trabajo y confirma la recepción con un identificador. El canal debe aceptar una descripción breve y recuperar la telemetría autorizada por separado. Si la organización necesita una captura, aplica controles de acceso y retención; una imagen del CRM puede contener más información de la necesaria para estudiar el problema.

Conserva evidencia sin convertir el feedback en otra fuga

Las trazas pueden incluir solicitudes, respuestas, recuperación, argumentos de herramientas y metadatos. Microsoft advierte que esta telemetría puede contener información sensible y recomienda minimizar o redactar datos, restringir el acceso y aplicar políticas de retención equivalentes a las de otros registros de producción. La utilidad para depurar no elimina la obligación de proteger el contenido.

Guarda una referencia estable a la evidencia en lugar de copiarla en tickets, chats y hojas distintas. Define quién puede consultar texto completo, quién solo necesita la clasificación y cuándo se elimina o desidentifica. Los secretos, tokens y credenciales no deben aparecer en prompts, argumentos ni atributos de traza.

Cuando un caso real deba convertirse en prueba, sustituye nombres, correos y datos que no influyen en la falla. Conserva la relación necesaria: rol, moneda, vigencia, permiso, secuencia o conflicto. Documenta qué puede comprobar la versión sintética y qué requiere una validación separada en el entorno autorizado.

Haz triage con impacto, alcance, repetibilidad y control

La prioridad no debe depender del cargo de quien reporta ni de lo extraña que parezca la respuesta. Evalúa qué decisión pudo cambiar, cuántas personas u objetos están expuestos, si el efecto es reversible, si puede propagarse y si los controles existentes lo detienen. Un caso poco frecuente de acceso entre cuentas merece más urgencia que muchos ajustes de tono.

Añade cuatro estados separados: severidad provisional, ruta asignada, responsable y próxima actualización. Si falta evidencia, marca el caso como pendiente de confirmación en lugar de cerrarlo. La ausencia de reproducción no demuestra que el usuario se equivocó; puede depender de una versión, un permiso, una fuente o un estado que ya cambió.

Define un acuerdo interno de respuesta por clase, sin prometer una corrección inmediata para cualquier comentario. Los casos críticos pasan a contención. Los defectos reproducibles entran al flujo de cambio. Las señales de calidad se agrupan para detectar patrones. Las solicitudes de producto reciben una decisión explícita de aceptar, posponer o rechazar.

Reproduce la falla con la versión y el contexto correctos

Antes de editar una instrucción, intenta reproducir la ejecución en un entorno controlado. Identifica modelo, prompt, reglas, fuentes, índice, permisos, herramientas, configuración y estado de la interfaz. Una respuesta parecida no es necesariamente el mismo defecto. La reproducción debe conservar las condiciones que explican el resultado y bloquear efectos reales.

Comienza con la evidencia original y reduce después el caso hasta encontrar la condición necesaria. Cambia un elemento por vez: rol, nota, documento, catálogo, fecha, historial o argumento de herramienta. Este aislamiento ayuda a distinguir una causa de una coincidencia. Si el problema es intermitente, registra frecuencia, variantes y factores que todavía no controlas.

No fuerces una explicación cuando el caso no se reproduce. Conserva el reporte, verifica si la versión cambió y busca señales similares. Puedes cerrar como no reproducido solo con los intentos documentados, los límites de la investigación y una condición clara para reabrirlo.

Busca la causa en el recorrido completo, no solo en el modelo

Traza la salida hacia atrás. ¿Qué afirmación fue incorrecta? ¿De qué fuente debía proceder? ¿La fuente estaba disponible y autorizada? ¿La recuperación la encontró? ¿Una regla transformó el dato? ¿El modelo recibió contexto contradictorio? ¿La herramienta validó sus argumentos? ¿La interfaz mostró la incertidumbre y la versión? Cada pregunta reduce el espacio de investigación.

Clasifica la causa primaria y los controles que permitieron el efecto. Un precio inventado puede comenzar con una partida sin importe y llegar al usuario porque la validación no exigió coincidencia con el catálogo. Corregir solo la frase del prompt deja abierta la ruta. La causa primaria explica por qué apareció; la falla de control explica por qué no se detuvo.

• Datos: valor faltante, vencido, duplicado o sin procedencia.
• Recuperación: fuente omitida, contexto excesivo o acceso incorrecto.
• Instrucciones: prioridad ambigua, conflicto o límite no expresado.
• Modelo: variación o comportamiento no cubierto por controles.
• Herramientas: función, identidad o argumento sin validación suficiente.
• Interfaz: fuente, incertidumbre, estado o efecto poco visibles.
• Proceso: revisión, capacitación o autoridad mal definidas.

Corrige la capa responsable y versiona el cambio

Elige el control más cercano a la causa. Corrige el dato en su sistema de origen, no en una copia dentro del prompt. Aplica autorización antes de recuperar información restringida. Valida precios, monedas, objetos y acciones en código. Usa instrucciones para orientar el comportamiento lingüístico, pero no como único control de acceso o de dinero.

Describe qué cambiará, qué permanecerá igual y qué riesgos nuevos puede introducir. Asigna una versión a modelos, instrucciones, fuentes, reglas y herramientas. Conserva la línea base para comparar y una ruta de reversión. Una edición silenciosa impide saber qué versión resolvió el caso y qué usuarios recibieron el cambio.

Si la corrección completa requiere tiempo, utiliza una mitigación explícita: limitar la función, ocultar una fuente, exigir revisión adicional o volver al proceso manual. La mitigación necesita responsable, vencimiento y condición de retiro; de lo contrario, puede convertirse en una excepción permanente sin evaluación.

Convierte la falla confirmada en una prueba de regresión

Escribe un caso estable con la entrada mínima, el rol, el contexto autorizado, los hechos obligatorios, las afirmaciones prohibidas y el comportamiento esperado. Conserva una referencia restringida al reporte original, pero utiliza datos sintéticos o desidentificados en la prueba cuando sean suficientes. La prueba debe fallar contra la versión defectuosa y aprobar contra la candidata.

Añade variantes cercanas y controles legítimos. Si corriges una inyección escondida en una nota, prueba otros campos y formatos, pero confirma también que una nota normal siga siendo útil. Si bloqueas una moneda ausente, comprueba que los precios completos aún puedan cotizarse. Prevenir una falla no justifica romper el trabajo autorizado.

Ejecuta la biblioteca de regresión cuando cambien modelo, instrucciones, fuentes, permisos, herramientas o autonomía. Mantén dueño, propósito y fecha de revisión para cada caso. Retira duplicados y escenarios obsoletos sin reescribir los resultados históricos.

Valida la corrección antes de ampliar su alcance

Compara la versión activa y la candidata con el mismo conjunto. Revisa el caso original, las variantes, los escenarios frecuentes y los controles críticos. Una mejora de utilidad promedio no compensa una nueva falla de permiso, precio o acción. Define de antemano qué resultado bloquea la salida y quién puede aprobar una excepción.

Después del despliegue, comienza con el alcance mínimo que produzca evidencia suficiente. Etiqueta feedback, trazas y métricas con la versión. Observa si disminuye el patrón sin aumentar descartes, correcciones o tiempos en otra parte del proceso. Una caída de reportes no prueba mejora si el canal dejó de ser accesible o el equipo dejó de usar la función.

Microsoft describe evaluación, monitoreo y trazas como capas complementarias: las métricas muestran dónde mirar, las trazas ayudan a reconstruir el recorrido y la evaluación comprueba comportamiento contra criterios definidos. Ninguna sustituye la revisión del impacto comercial por personas responsables.

Cierra el ciclo con la persona que reportó y con el equipo

Comunica qué se confirmó, qué se cambió, qué límite permanece y desde qué versión aplica. No hace falta exponer detalles sensibles ni afirmar que todo el sistema quedó resuelto. Si el reporte era una expectativa incorrecta, explica el comportamiento previsto y mejora la interfaz o la capacitación cuando la confusión sea razonable.

El estado cerrado debe exigir evidencia: causa o decisión documentada, corrección o mitigación, pruebas, aprobación, versión desplegada y comunicación. Los casos duplicados se vinculan con el principal para conservar el volumen y los contextos. Los no corregidos mantienen una razón y una fecha de revisión.

Mide el sistema de feedback, no la productividad individual. Observa reportes por tipo y versión, severidad, tiempo de triage, tiempo de corrección, reaperturas, recurrencia y porcentaje convertido en regresiones. Evita usar la cantidad de correcciones como ranking de vendedores; eso reduce el reporte honesto y oculta problemas.

Aplica el ciclo a los límites verificables de Cerravi

En Cerravi, un reporte sobre una sugerencia debe conservar la cuenta u oportunidad, el contexto visible, la versión y la corrección del usuario sin convertir esa corrección en una orden automática. La persona responsable revisa el siguiente paso antes de actuar. El historial permite distinguir señal, inferencia, borrador y decisión.

Las propuestas utilizan los productos y precios disponibles en el catálogo cargado. Si falta un importe o existen fuentes contradictorias, el comportamiento correcto es mostrar el faltante y pedir confirmación; Cerravi no inventa la cifra. MXN, USD y otras monedas permanecen separadas mientras no exista una conversión aprobada con método, fecha y fuente.

Una apertura de Buyer Room aporta contexto, pero no confirma identidad, lectura, aceptación, contrato, pago ni intención de compra. Forecast es una estimación operativa basada en reglas transparentes y datos del CRM, no un modelo predictivo entrenado o calibrado. El ciclo de feedback debe reforzar estos límites, no aprender a ocultarlos con una redacción más convincente.