Respuesta directa
En pocas palabras
Para controlar datos de CRM usados en entrenamiento o evaluación de IA, separa primero cada finalidad: atender una solicitud, medir calidad, revisar un incidente, crear un dataset, ajustar un modelo o mejorar un servicio no son la misma operación. Autoriza población, campos, fuente, versión, acceso, proveedor, plazo y resultado por separado; usa datos sintéticos o minimizados cuando sean suficientes; evita que feedback y logs se conviertan automáticamente en entrenamiento; y prueba rectificación, exclusión, eliminación y no reaparición en copias, índices y versiones derivadas. Una opción que dice no training no demuestra por sí sola que no existan logs, evaluación, soporte o retención.
Separa inferencia, evaluación, feedback, ajuste y mejora antes de autorizar datos
Un CRM puede enviar contexto a un modelo para responder una solicitud sin usar ese contenido para entrenar. También puede conservar una muestra para evaluar calidad, recibir una corrección humana, crear un conjunto de regresión, ajustar un modelo o permitir que un proveedor mejore su servicio. Esas rutas difieren en propósito, acceso, duración, destinatarios y efecto. La etiqueta datos de IA no describe lo que realmente ocurre y la frase no entrenamos puede dejar fuera registros de abuso, soporte, evaluación o feedback.
Dibuja cada operación como un carril independiente. Nombra entrada, transformación, salida, sistema, entidad, región, acceso y condición de cierre. Distingue modelo base, prompt, recuperación, reglas, evaluador, clasificador, modelo ajustado e índice. Si una corrección de un vendedor termina en un dataset o una conversación de soporte llega a un evaluador, registra el salto como una nueva decisión. El comportamiento comprobable debe coincidir con aviso, contrato, configuración y proceso interno.
Define la finalidad y la decisión permitida para cada dataset
Escribe una finalidad concreta y un resultado verificable. Evaluar si las propuestas conservan la moneda requiere casos con moneda, catálogo y resultado esperado; no exige por defecto nombres, teléfonos o toda la conversación. Investigar una fuga puede necesitar una muestra restringida durante un periodo corto, no una copia permanente de producción. Ajustar un clasificador de intención requiere justificar por qué reglas, ejemplos sintéticos o un modelo sin ajuste no alcanzan la calidad necesaria.
Documenta quién recibe valor y quién puede sufrir exposición, inferencia, exclusión o uso inesperado. Separa finalidades necesarias del servicio y secundarias. Para datos personales en México, la empresa debe revisar licitud, finalidad, información, consentimiento o excepciones, proporcionalidad, calidad y responsabilidad conforme al caso. Esta guía no decide la base jurídica ni la compatibilidad de una finalidad; convierte la decisión revisada en fronteras técnicas y evidencia reproducible.
Mapea seis carriles y evita que producción alimente todo por defecto
Separa al menos: inferencia operativa, observabilidad técnica, prevención de abuso o seguridad, soporte, evaluación y entrenamiento o mejora. Añade moderación, red teaming, análisis humano o investigación cuando existan. Para cada carril registra entradas, salidas, metadatos, identificadores, contenido, retención, subencargados y posibilidad de uso propio. Una misma API puede aplicar condiciones distintas según plan, endpoint, configuración o tipo de cuenta.
Marca los puntos donde los datos cambian de carril: muestreo desde producción, exportación a un notebook, etiquetado externo, envío al proveedor, incorporación a un benchmark, ajuste, publicación de una métrica o archivo en un respaldo. Usa identificadores de dataset y de propósito para impedir mezclas silenciosas. Un lago de datos accesible para todos los experimentos elimina la frontera aunque los documentos describan finalidades separadas.
| Criterio | Resultado permitido | Control que no debe heredarse |
|---|---|---|
| Inferencia | Resolver una solicitud concreta | No reutilizar entrada o salida por defecto |
| Observabilidad | Medir estado, latencia y errores | No copiar contenido completo si bastan eventos |
| Evaluación | Medir una versión contra criterios | No convertir la muestra automáticamente en entrenamiento |
| Feedback | Corregir y revisar un resultado | No asumir permiso para crear ejemplos duraderos |
| Ajuste o mejora | Modificar comportamiento o parámetros | No heredar finalidad, acceso ni retención de producción |
Crea un inventario versionado de datasets, etiquetas y derivados
Asigna un identificador a cada conjunto y registra nombre, dueño, finalidad, origen, fecha de corte, población, campos, idioma, región, licencias o restricciones, transformaciones, etiquetas, calidad, accesos, ubicación, cifrado, versiones y plazo. Incluye prompts, respuestas, fragmentos recuperados, documentos, embeddings, feedback, resultados de revisión y metadatos. Un archivo llamado final-v3 no demuestra qué registros contiene ni de dónde llegaron.
Conecta cada fila o lote con una procedencia suficiente para corregir, excluir o investigar sin duplicar identidad innecesaria. Conserva manifiestos, consultas, código y parámetros. Registra filtros fallidos, registros rechazados y decisiones de etiquetado. Si mezclas varias fuentes, conserva la contribución y las restricciones de cada una. La trazabilidad no exige guardar indefinidamente el contenido original; puede usar referencias protegidas, agregados y comprobantes mínimos según la finalidad.
Diseña el muestreo desde producción como una excepción limitada
Empieza con datos sintéticos, casos escritos por especialistas o ejemplos desidentificados cuando puedan probar el criterio. Si una evaluación necesita producción, delimita población, ventana, porcentaje, campos, exclusiones y razón. Filtra antes de copiar. Excluye conversaciones, adjuntos, secretos, datos sensibles y cuentas restringidas salvo una decisión explícita y controles proporcionales. Evita muestrear por conveniencia todo lo que resulta fácil extraer.
Ejecuta el muestreo con una identidad de servicio dedicada, consulta versionada, aprobación y registro. Cifra temporales y elimina archivos intermedios. Define máximos por volumen y frecuencia, y detén ante columnas nuevas o categorías prohibidas. Una muestra aleatoria puede seguir exponiendo casos raros; revisa estratos, outliers y texto libre. No pegues datos reales en tickets, chats o notebooks personales para explicar una falla.
Aísla producción, evaluación, desarrollo, demo y entrenamiento
Usa proyectos, cuentas, buckets, claves, índices y permisos distintos. Limita conectividad de salida y bloquea accesos cruzados. Desarrollo no debe consultar producción por defecto; demo no debe usar contactos reales; soporte no debe conservar una exportación después del caso. Separa quien prepara el dataset, quien etiqueta, quien entrena y quien aprueba la liberación cuando el riesgo lo justifique.
Prueba la frontera con identidades negativas: otro workspace, rol menor, cuenta desactivada, token vencido y persona externa de etiquetado. Revisa cachés, artefactos de experimentos, checkpoints, registros, herramientas de seguimiento, reportes y respaldos. Una política de carpetas no aísla si el mismo secreto puede leer todas. La salida del entorno también se controla: métricas, ejemplos, capturas y errores pueden reconstruir contenido.
Gobierna feedback y etiquetas como datos nuevos, no como verdad automática
Una corrección contiene la opinión de una persona dentro de un contexto, no una etiqueta universal. Registra tarea, instrucción, versión, fuente visible, rol, fecha, confianza y desacuerdo. Separa corrección factual, preferencia de estilo, decisión comercial, aceptación y resultado posterior. Un clic, una edición o una apertura de Buyer Room no demuestra por sí solo que una recomendación fue correcta ni que existe intención de compra.
Define guías de etiquetado, ejemplos límite, revisión y adjudicación. Mide acuerdo cuando sea útil y conserva incertidumbre. Protege a quienes etiquetan de contenido innecesario y limita la posibilidad de inferir desempeño individual. No premies volumen a costa de calidad. Si el feedback activa memoria, una regla o un dataset, muestra el destino y permite excluirlo según la decisión aplicable. Corrige etiquetas derivadas cuando cambie el dato fuente.
Minimiza, transforma y usa datos sintéticos sin confundirlos con una garantía
Conserva solo campos y granularidad necesarios para la métrica. Redacta texto, generaliza fechas, separa vínculos y elimina metadatos antes de mover el conjunto. La seudonimización reduce exposición bajo controles, pero mantiene una relación. La anonimización requiere evaluar reidentificación. Un embedding, hash o token no cambia automáticamente la clasificación del conjunto.
Los datos sintéticos sirven para permisos, monedas, errores, relaciones y escalas sin copiar personas reales. Aun así, un generador entrenado con producción puede memorizar registros o reproducir casos raros. Documenta fuente, método y parámetros; busca duplicados, vecinos, fragmentos y outliers. Separa utilidad y privacidad. Cuando la prueba necesite realidad estadística, limita el uso real a lo que el criterio no puede obtener de forma sintética.
Mide calidad y procedencia sin convertir una métrica en permiso
Evalúa cobertura, duplicados, valores faltantes, vigencia, consistencia, representatividad, errores de extracción y cambio de distribución. Segmenta por tarea, idioma, sector y condición relevante sin crear atributos sensibles innecesarios. La ausencia de una población puede limitar el uso; no la completes con inferencias dudosas. Registra quién revisó y qué no se pudo comprobar.
Una mejora de exactitud no autoriza datos adicionales por sí sola. Compara el beneficio incremental contra exposición, esfuerzo, derechos, retención y alternativas. Evita reportar una sola cifra sin intervalo, denominador o conjunto. Separa train, validation, test, challenge y producción; impide que el mismo ejemplo contamine varias particiones. Un benchmark repetido hasta optimizarlo deja de ser una medida independiente.
Verifica qué hace cada proveedor con entradas, salidas, feedback y telemetría
Revisa entidad, producto, plan, endpoint, región, subencargados, soporte, prevención de abuso, retención, configuración y cambios. Pregunta por separado si entradas, salidas, archivos, feedback, evaluaciones y telemetría se usan para entrenamiento, ajuste o mejora. Confirma excepciones y periodos. Una página general no demuestra la configuración de la cuenta ni cubre necesariamente una función empresarial distinta.
Haz coincidir contrato, aviso, administración y prueba observable. Conserva captura o exportación de la configuración con fecha, cuenta y responsable, pero vuelve a verificar ante cambios de modelo, plan, región o términos. Reduce datos antes de enviarlos incluso cuando exista una promesa de no entrenamiento. Define revocación, devolución, eliminación, asistencia a derechos, incidente y salida. Si el proveedor usa datos para una finalidad propia, revisa roles y transferencias por actividad, no solo por marca.
Controla checkpoints, modelos ajustados, índices y artefactos derivados
El dataset no es la única copia. Registra checkpoints, adaptadores, pesos ajustados, índices, cachés, estadísticas, diccionarios, prompts optimizados, ejemplos few-shot, reportes, capturas y artefactos de experimento. Define cuáles pueden contener, memorizar o facilitar la recuperación de información. Aplica acceso, versión, retención y disposición según su riesgo y uso.
No prometas eliminar una influencia de un modelo sin un método comprobado. Borrar la fila fuente puede no retirar lo aprendido o memorizado. Define de antemano si puedes reconstruir desde un conjunto limpio, retirar un adaptador, bloquear una versión, filtrar una salida o limitar uso mientras investigas. Conserva relación entre versión, dataset y evaluación para identificar qué debe pausarse. La palabra unlearning no sustituye una prueba de resultado.
Propaga rectificación, oposición, cancelación y retención a cada carril
Mantén referencias controladas para localizar la fuente, muestra, etiqueta, evaluación, exportación y proveedor mientras exista un vínculo. Una rectificación puede cambiar etiqueta y resultado esperado. Una oposición o restricción debe bloquear nuevos muestreos y usos secundarios según la decisión aplicable. La cancelación puede requerir bloqueo y después supresión; revisa obligaciones y excepciones con el área competente.
Asigna plazos por finalidad, no por tecnología. Un log operativo, una investigación, un benchmark y un modelo ajustado pueden requerir decisiones distintas. Elimina temporales, copias de etiquetado, notebooks, artefactos y accesos al cerrar. Prueba que el registro no reaparezca al reconstruir un dataset, reindexar, restaurar respaldo o repetir una consulta. Conserva evidencia mínima del resultado sin guardar otra copia completa del contenido.
Prueba fugas, memorización, contaminación y cambios de propósito
Incluye un contacto excluido, dato corregido, texto sensible, otro workspace, registro duplicado, caso raro y fuente vencida. Intenta recuperar datos del train desde outputs, herramientas, búsqueda, logs y errores. Comprueba que el test no apareció en entrenamiento y que una cuenta de evaluación no escribe en producción. Registra versión, identidad, entrada, esperado, observado y evidencia.
Monitorea datasets nuevos, columnas, accesos, exportaciones, errores de redacción, muestras vencidas, cambios de proveedor, checkpoints y reutilizaciones. Usa alertas sobre comportamiento, no solo inventario. Reabre ante nueva finalidad, población, dato, fuente, modelo, región, proveedor o técnica. NIST AI RMF y su perfil de IA generativa ofrecen acciones voluntarias para mapear, medir y gestionar riesgos, incluidos privacidad, procedencia y evaluación; no certifican un sistema ni determinan la ley mexicana.
Libera solo con evidencia, límites y una salida verificable
El paquete de liberación incluye finalidad, fuentes, población, campos, transformaciones, versiones, accesos, proveedores, regiones, evaluaciones, riesgos, derechos, plazos, decisión y disparadores. El resultado puede autorizar una evaluación acotada, permitir ajuste con datos minimizados, exigir sintéticos, limitar al entorno restringido, pedir más evidencia o rechazar el uso. Ninguna métrica sustituye la autoridad y ninguna aprobación cubre versiones o finalidades futuras.
Cerravi organiza contexto comercial y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Las propuestas usan productos y precios disponibles, y un importe faltante requiere confirmación. Forecast usa reglas transparentes del CRM y no se presenta como un modelo predictivo entrenado. Cada empresa decide qué datos carga, integra, evalúa o comparte y qué proveedores configura. Esta guía ayuda a instrumentar decisiones, pero no demuestra cumplimiento, no certifica un dataset y no sustituye asesoría jurídica, evaluación especializada o resolución de la autoridad.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Usar un CRM con IA significa que el proveedor entrena con todos los datos?
No necesariamente. Inferencia, registro, prevención de abuso, soporte, evaluación, feedback y entrenamiento son operaciones diferentes. Deben revisarse el producto, plan, endpoint, contrato, configuración, región, subencargados y comportamiento observable. Una afirmación de no training tampoco demuestra por sí sola que no existan logs o retención.
¿Una corrección del vendedor puede entrar automáticamente al entrenamiento?
No debería asumirse. La corrección puede resolver el caso actual, pero convertirla junto con su contexto en un ejemplo duradero es otra finalidad y otro flujo. Deben definirse autorización, minimización, acceso, versión, plazo, proveedor y mecanismo de exclusión conforme a la decisión aplicable.
¿Puedo evaluar un modelo con datos reales del CRM?
Solo después de justificar por qué datos sintéticos, redactados o minimizados no cubren el criterio y de acotar población, campos, volumen, ventana, acceso, entorno y eliminación. La ruta jurídica, contractual y de información debe revisarse para el caso; una evaluación útil no autoriza automáticamente todo el historial.
¿Borrar un contacto del dataset elimina su influencia de un modelo ajustado?
No siempre. El dato puede existir en copias, checkpoints, adaptadores, índices, cachés o haber influido en parámetros. La organización debe conocer qué artefactos puede reconstruir, retirar o filtrar y probar el resultado. Borrar el archivo fuente o invocar unlearning sin evidencia no demuestra eliminación completa.
¿Cerravi entrena un modelo predictivo con el Forecast de cada cliente?
No según los límites públicos actuales. Forecast usa reglas transparentes del CRM: no es un modelo de machine learning entrenado o calibrado y no garantiza cierres ni ingresos. Cada empresa debe revisar su configuración, integraciones y proveedores reales antes de describir otros usos de datos.