Cómo crear una política de uso para un AI Sales Copilot

Escribe una política que pueda aplicarse durante el trabajo

Una política útil establece decisiones y límites. Explica para qué existe el copiloto, quién puede utilizarlo, qué información puede recibir y qué efectos puede producir. También indica qué hacer cuando una solicitud queda fuera del alcance. Frases como usar la IA con responsabilidad expresan una intención, pero no resuelven una duda frente a un cliente, un precio ausente o un acceso extraordinario.

NIST sitúa las políticas, los procesos y las responsabilidades dentro de la función permanente de gobernanza del riesgo de IA. La recomendación no consiste en copiar todos los controles disponibles, sino en seleccionar los que corresponden al contexto y conectarlos con la gestión de datos, seguridad, privacidad, compras, recursos humanos, legal y continuidad que la empresa ya utiliza.

Distingue política, procedimiento y control. La política define la regla y la autoridad; el procedimiento explica cómo cumplirla; el control técnico limita o registra la acción. Los tres deben coincidir. Si el documento prohíbe compartir datos sensibles, pero los permisos permiten exponerlos sin advertencia ni bloqueo, la política no está implementada.

Define propósito, alcance y versión sin dejar zonas grises

Empieza con una frase concreta: qué problema comercial ayuda a resolver el sistema y qué resultado espera la organización. Después delimita áreas, cuentas, roles, dispositivos, entornos, fuentes e integraciones incluidas. Indica si la política cubre una prueba, un piloto o producción y registra la versión del producto o configuración evaluada.

Incluye sistemas de terceros y herramientas adquiridas por equipos individuales. Una política limitada a desarrollos internos deja fuera extensiones, asistentes incorporados en otras aplicaciones y cuentas creadas sin revisión. Mantén un inventario con nombre, dueño, finalidad, estado, datos, herramientas conectadas y fecha de próxima revisión.

Aclara a quién aplica: empleados, contratistas, socios, administradores y personas que revisan las salidas. Si existen escenarios fuera del alcance, nómbralos. Evita expresiones como cualquier uso comercial cuando en realidad solo se autorizó preparar resúmenes internos o borradores para un grupo concreto.

Clasifica los usos como permitidos, condicionados o prohibidos

Construye la matriz por escenario y efecto. Un uso permitido puede ser resumir notas autorizadas y mostrar las fuentes. Un uso condicionado puede ser preparar una propuesta que una persona debe revisar antes de compartir. Un uso prohibido puede ser inventar un precio, asumir una identidad, enviar un compromiso sin aprobación o utilizar una fuente que la empresa no autorizó.

Añade ejemplos cercanos al trabajo real. El equipo necesita reconocer si puede resumir una llamada, analizar una oportunidad, redactar un correo, cargar una lista, combinar bases, cambiar una etapa, calcular un descuento o compartir una Buyer Room. Para cada caso indica datos permitidos, revisión, registro y responsable.

Incluye una regla de abstención: cuando falten datos, exista conflicto entre fuentes, la instrucción sea ambigua o la persona no tenga autoridad, el sistema y el usuario deben detenerse, pedir información o escalar. No conviertas el silencio de la política en permiso implícito.

Decide qué datos puede utilizar y qué debe permanecer fuera

Alinea la política con la clasificación de información de la empresa. Separa datos públicos, internos, confidenciales, personales, sensibles, credenciales, secretos comerciales y material de terceros. Para cada clase especifica si puede entrar en prompts, fuentes de consulta, memoria, registros, exportaciones o herramientas conectadas.

Define fuentes oficiales. En ventas pueden incluir el CRM, el catálogo vigente, documentos aprobados y notas accesibles para ese usuario. Una carpeta encontrada, una versión antigua o un archivo recibido sin procedencia no se convierten en fuente autorizada por estar disponibles técnicamente.

Aplica minimización. Utiliza únicamente el contenido necesario para la tarea, limita retención y evita copiar conversaciones completas o adjuntos cuando bastan campos concretos. Establece cómo corregir, eliminar y atender solicitudes relacionadas con datos según las reglas aplicables de la organización.

Separa asistencia, borrador y acción con efecto

La autonomía debe aparecer en la política con verbos específicos. Observar, resumir y recomendar no son equivalentes a guardar, enviar, modificar, publicar, conceder acceso o comprometer una condición. Define qué acciones puede preparar el copiloto y cuáles necesitan una confirmación humana antes de producir un efecto.

Microsoft recomienda reservar aprobación para acciones difíciles de revertir o que afecten personas, dinero o cumplimiento. Añade límites deterministas cuando una acción esté prohibida: permisos, listas autorizadas, topes, separación de funciones y bloqueo por defecto. Una instrucción en lenguaje natural no sustituye una restricción técnica.

Describe qué información verá la persona al decidir: solicitud, fuentes, faltantes, destinatario, cambio, efecto y posibilidad de reversión. La aprobación solo aporta criterio si el revisor comprende el caso y puede corregir, rechazar, pausar o escalar.

Asigna responsables y derechos de decisión

Nombra una persona responsable del valor y el riesgo del caso de uso. Define quién administra la configuración, quién conserva las fuentes, quién revisa seguridad y privacidad, quién atiende soporte y quién puede aprobar, limitar, pausar, reanudar o retirar el sistema. En organizaciones pequeñas una persona puede cubrir varias funciones, pero la autoridad debe seguir siendo explícita.

Utiliza una matriz RACI cuando ayude a evitar confusión, pero acompáñala con derechos de decisión. Saber quién fue consultado no dice quién puede aceptar una excepción o detener una función. Incluye respaldo, horario de cobertura y ruta para desacuerdos.

La persona usuaria sigue siendo responsable de aplicar la política al trabajo que realiza. Eso no traslada toda la responsabilidad al vendedor: dirección, producto, tecnología, datos y funciones de control conservan sus propias obligaciones sobre diseño, acceso, operación y seguimiento.

• Dueño de negocio: propósito, resultado y tolerancia al riesgo.
• Dueño operativo: aplicación diaria, soporte y seguimiento.
• Datos: calidad, clasificación, acceso y ciclo de vida.
• Tecnología: configuración, identidades, integraciones y recuperación.
• Seguridad, privacidad y legal: requisitos y controles aplicables.
• Usuarios y revisores: uso autorizado, verificación y reporte.

Aplica mínimo privilegio a personas, copiloto y herramientas

Concede únicamente los datos, funciones y herramientas necesarios para el escenario autorizado. Separa lectura y escritura, producción y prueba, administración y uso cotidiano. No compartas credenciales entre personas o integraciones y conserva identidades que permitan atribuir acciones de forma razonable.

Revisa el alcance efectivo, no solo el permiso directo. Una integración puede heredar acceso por una cuenta de servicio, un grupo, un complemento o una herramienta posterior. Deniega por defecto nuevas fuentes, plugins y acciones hasta que tengan dueño, finalidad y revisión.

Prueba la revocación. La política debe explicar qué ocurre cuando una persona cambia de función, termina una relación, vence una excepción o se retira una integración. Desactivar la pantalla principal no basta si permanecen tokens, enlaces, claves o rutas alternativas.

Define transparencia y evidencia sin registrar de más

Indica cuándo debe informarse que una salida fue preparada con IA y cómo distinguir contenido generado, editado y aprobado. La forma de comunicación depende del contexto y de las reglas aplicables; evita prometer una divulgación universal que no pueda sostenerse en todos los canales.

Conserva evidencia proporcional: sistema y versión, usuario o identidad, fuente relevante, acción propuesta, cambio humano, aprobación, efecto y excepción. Para casos de bajo impacto puede bastar telemetría agregada; para una acción importante se necesita una reconstrucción más completa.

Separa observabilidad de vigilancia laboral. Define finalidad, acceso, retención y revisión de registros. Redacta secretos y datos personales innecesarios. Comunica al equipo qué se conserva y para qué; un registro oculto o ilimitado puede crear un riesgo adicional.

Haz que excepciones e incidentes tengan una ruta conocida

Una excepción debe ser temporal y específica. Registra la regla afectada, razón, alcance, responsable, aprobador, control compensatorio y fecha de vencimiento. Revisa las excepciones activas y elimina el acceso cuando termina la necesidad. La urgencia comercial no debe convertirse en permiso permanente.

Explica cómo reportar una salida insegura, una exposición, un acceso indebido, una acción fuera del alcance o un intento de eludir controles. El canal debe aceptar dudas y señales tempranas, no únicamente incidentes confirmados. Define quién clasifica, contiene, comunica y decide sobre reanudación.

Protege la posibilidad de cuestionar el sistema. NIST propone una cultura de análisis crítico y rutas para comunicar preocupaciones serias. El equipo debe poder detenerse o reportar sin presión para aprobar una recomendación por velocidad, jerarquía o confianza excesiva en la herramienta.

Capacita con decisiones reales y comprueba comprensión

La capacitación debe cubrir el propósito, los límites, las fuentes, los datos, las aprobaciones, las excepciones y el reporte. Adapta los ejemplos por función: un administrador necesita dominar permisos y revocación; una persona de ventas debe reconocer un dato faltante, una propuesta no aprobada y una señal que no demuestra intención de compra.

Pide practicar casos permitidos, condicionados, prohibidos y ambiguos. Comprueba que la persona sepa localizar la fuente, corregir una salida, conservar la duda y escalar. Una aceptación electrónica demuestra que recibió el documento, no que pueda aplicarlo.

Actualiza materiales cuando cambien el producto, las fuentes, las integraciones, la autonomía o la política. Incluye a contratistas y respaldos operativos. Registra la capacitación necesaria sin recopilar información ajena a ese propósito.

Convierte la política en un ciclo de revisión

Define una cadencia y eventos que obliguen a revisar: una función nueva, cambio de modelo o proveedor, integración adicional, expansión de usuarios, nueva clase de datos, incidente, modificación importante del proceso o requisito aplicable. Cada revisión debe concluir en mantener, aclarar, reforzar, limitar, pausar o retirar.

Observa si la política se entiende y funciona. Revisa preguntas frecuentes, correcciones, rechazos, excepciones, incidentes, accesos, resultados de pruebas y carga de aprobación. Una cifra baja de reportes puede indicar pocos problemas o un canal que nadie conoce; combina métricas con muestras e entrevistas.

Controla versiones y conserva un historial de cambios. Comunica qué cambió, desde cuándo y a quién afecta. Retira procedimientos antiguos y comprueba que permisos, interfaces y capacitación reflejen la versión vigente.

Utiliza una estructura mínima para redactar la primera versión

La primera versión puede ser breve si toma decisiones completas. Reúne propósito y alcance; definiciones; inventario; matriz de usos; datos; acciones y aprobación; roles; acceso; transparencia y registro; excepciones; incidentes; capacitación; monitoreo; cambios y retiro. Vincula procedimientos técnicos donde haga falta.

Antes de aprobarla, recorre tres escenarios normales y tres difíciles. Verifica que una persona nueva pueda decidir qué hacer sin depender de una interpretación informal. Comprueba también que los controles del producto sostengan la regla y que exista una alternativa manual.

Publica la política en un lugar accesible, asigna un canal de dudas y fija fecha de revisión. Una política que nadie encuentra, que no tiene dueño o que contradice el sistema se vuelve obsoleta desde el primer día.

Documenta los límites verificables de Cerravi

En Cerravi, el copiloto organiza señales registradas en el CRM y propone siguientes pasos para revisión humana. No envía mensajes, cambia etapas ni ejecuta decisiones comerciales automáticamente. La política de cada empresa debe definir quién puede utilizar esas recomendaciones y qué revisión requiere su proceso.

Las propuestas utilizan productos y precios disponibles en el catálogo cargado. Si falta un importe, la persona debe confirmar la fuente; el producto no inventa la cifra. MXN, USD y otras monedas permanecen separadas mientras no exista una conversión aprobada. La actividad de una Buyer Room aporta contexto, pero no confirma identidad, aceptación, contrato, pago o intención de compra.

El Forecast de Cerravi es una estimación operativa basada en reglas transparentes y datos registrados en el CRM. No es un modelo predictivo entrenado o calibrado y no garantiza cierre ni ingresos. Cerravi aporta funciones y límites del producto; la empresa conserva responsabilidad sobre configuración, datos, usuarios, decisiones y requisitos aplicables.