Un prototipo de IA no necesita toda la base de clientes

El equipo quiere comprobar si la inteligencia artificial puede clasificar solicitudes de clientes. La base del CRM está disponible y alguien propone copiarla completa al entorno de prueba para "tener datos reales". Parece el camino corto. También es una forma de convertir un experimento acotado en una segunda base de clientes, con más accesos, más copias y una responsabilidad que nadie había presupuestado.

Un prototipo serio sí necesita realidad. Debe encontrar nombres escritos de varias maneras, mensajes incompletos, solicitudes ambiguas y casos que no caben en una categoría cómoda. Pero realidad no significa volumen indiscriminado. Significa escoger la información que permite probar una capacidad concreta y excluir la que no cambia el resultado.

La minimización de datos en IA empieza allí: no preguntando cuánto puede copiar el sistema, sino qué necesita demostrar la prueba.

La prueba debe tener un verbo preciso

"Probar IA con clientes" es un alcance demasiado amplio. Clasificar el motivo de contacto, detectar campos faltantes, asociar un mensaje con un caso abierto o preparar un resumen son trabajos distintos. Cada uno necesita entradas diferentes y produce riesgos diferentes.

Si el prototipo solo clasificará consultas, tal vez necesite el texto del mensaje, la categoría final asignada por una persona y algunas señales del canal. No necesita saldos, documentos de identidad, contratos, datos bancarios ni todo el historial comercial. Si la prueba busca reconocer clientes, entonces necesita comparar identificadores y variaciones de nombre, pero eso tampoco le da permiso para leer cada nota del CRM.

Antes de extraer un registro, conviene escribir una frase comprobable: "el prototipo propondrá una categoría para solicitudes recibidas por correo y enviará los casos dudosos a revisión". Esa frase permite discutir campos, usuarios y resultados. También evita que una demostración de clasificación termine convertida, por comodidad, en un asistente con acceso general.

Una implementación de inteligencia artificial aplicada debería empezar por esa frontera operativa. El modelo viene después del trabajo y de la evidencia necesaria para evaluarlo.

Una muestra pequeña puede ser más exigente que una copia completa

Copiar miles de registros no garantiza una buena prueba. La mayoría puede contener casos normales y repetidos. El sistema obtiene un porcentaje atractivo porque reconoce lo fácil, mientras las excepciones que consumen tiempo permanecen escondidas.

Una muestra útil se construye por variedad, no solo por cantidad. Debe incluir mensajes claros y ambiguos, información completa e incompleta, clientes nuevos y recurrentes, errores de escritura, solicitudes que cambian de tema y casos que el sistema debería rechazar o escalar. Si existen categorías poco frecuentes pero costosas, deben aparecer deliberadamente.

Este enfoque también mejora la conversación con el equipo. Operaciones puede señalar qué excepción detiene el trabajo. Ventas puede identificar condiciones que no deben resumirse sin contexto. Soporte puede mostrar cuándo dos mensajes parecidos necesitan rutas distintas. El prototipo deja de ser una exhibición estadística y empieza a revelar si entiende el problema que la empresa quiere aliviar.

La base completa suele traer mucho ruido: registros viejos, duplicados, campos abandonados y notas sin dueño. Una selección razonada obliga a reconocer esos defectos antes de atribuirle al modelo un error que nació en los datos.

El inventario de campos descubre lo que sobra

La extracción no debería empezar con SELECT *. Antes conviene preparar una tabla sencilla con cada campo candidato, su propósito dentro de la prueba, su sensibilidad, la fuente y el tiempo previsto de conservación. Si nadie puede explicar para qué sirve un campo, ese campo queda fuera.

El nombre del cliente puede ser necesario para una prueba de asociación, pero innecesario para clasificar la intención de un mensaje. La dirección completa quizá pueda reemplazarse por una zona cuando la prueba solo necesita asignar una sucursal. Una fecha exacta puede convertirse en un rango. Los comentarios libres merecen especial cuidado porque suelen mezclar contexto útil con teléfonos, condiciones comerciales, reclamos y apreciaciones internas.

Eliminar columnas visibles tampoco resuelve todo. Un texto puede identificar a una persona por su contenido, y la combinación de pocos datos puede volverla reconocible. Cambiar el nombre por un código reduce exposición directa, pero no convierte automáticamente el registro en anónimo. La empresa debe tratar esa transformación como una reducción de riesgo, no como permiso para relajar controles.

En Panamá, la Ley 81 de 2019 sobre protección de datos personales establece principios y obligaciones para el tratamiento de datos. Su reglamentación mediante el Decreto Ejecutivo 285 de 2021 desarrolla, entre otros puntos, la evaluación previa del tratamiento para asegurar proporcionalidad y minimización. Un prototipo no queda fuera de esa conversación por llamarse prueba.

Datos sintéticos primero, casos reales después

Los datos inventados sirven para comprobar el recorrido básico: formatos, integraciones, permisos, pantallas y manejo de errores. Permiten detectar fallas obvias sin exponer información de clientes. Su límite aparece cuando todo está demasiado limpio. Un ejemplo creado por el mismo equipo que diseñó el flujo tiende a cooperar con él.

Por eso una secuencia prudente usa capas. Primero se ensaya con datos sintéticos. Luego se incorpora una muestra controlada de casos reales, seleccionada por responsables que conocen el proceso. Al final se añaden excepciones difíciles y casos negativos donde la respuesta correcta es detenerse.

El conjunto real no necesita viajar sin contexto. Cada caso debe conservar la etiqueta o decisión humana contra la cual se comparará la propuesta del sistema. También necesita una razón para estar en la muestra. De otro modo, el equipo termina revisando respuestas interesantes sin poder decir si mejoraron el trabajo.

Cuando la preparación requiere mover, transformar y revisar información, una automatización de procesos puede crear el conjunto de prueba de manera repetible. Así se evita que cada ensayo dependa de una exportación manual distinta y de una carpeta que nadie limpia después.

El entorno de prueba también necesita límites

Un archivo reducido sigue siendo información empresarial. Debe tener usuarios autorizados, una ubicación definida, registro de accesos cuando el riesgo lo justifique y una fecha de retiro. No conviene enviarlo por correo, dejarlo en enlaces públicos ni compartir una misma cuenta entre proveedor y equipo interno.

También importa saber qué hace la plataforma con lo que recibe. La empresa debe revisar si conserva entradas y salidas, por cuánto tiempo, en qué entorno, quién puede acceder, si utiliza esos datos para otros fines y cómo se ejecuta la eliminación. Una promesa comercial de privacidad no sustituye la configuración efectiva ni el acuerdo aplicable.

Los controles de seguridad y gobernanza de IA deben cubrir tanto el prototipo como la futura operación. La etapa temprana no es una zona sin reglas. Es el momento más barato para definir cuentas, permisos, registro, retención y salida antes de que el equipo dependa de la herramienta.

El acceso del proveedor tampoco tiene que ser permanente. Puede limitarse al periodo de prueba, al conjunto preparado y a una función concreta. Si necesita diagnosticar un error, la empresa debería poder entregar el caso afectado sin abrir toda la fuente original.

La salida puede revelar lo que la entrada ocultó

A veces el equipo protege el archivo original y luego publica una tabla de resultados con nombres, resúmenes y fragmentos de conversaciones. La exposición se trasladó de lugar.

Las salidas necesitan su propio inventario. Un resumen puede revelar una condición privada aunque oculte el documento. Una clasificación puede exponer que una persona pertenece a una categoría sensible. Un registro de depuración puede conservar el mensaje completo y los datos recuperados por herramientas conectadas.

La revisión debe seguir el recorrido completo: dato seleccionado, transformación, entrada al modelo, respuesta, registro técnico, pantalla de revisión y exportación final. Si una etapa no necesita el contenido completo, puede conservar una referencia o un identificador controlado. La trazabilidad no exige duplicar el expediente en cada paso.

Borrar la muestra también forma parte del piloto

Muchos prototipos terminan en una reunión, no en una limpieza. Quedan archivos locales, copias en almacenamiento, tablas temporales, historiales de ejecución y usuarios externos activos. Meses después, nadie recuerda cuál era la versión ni quién todavía puede verla.

La prueba debería definir su cierre antes de comenzar. Si no continúa, se eliminan las copias previstas, se revocan accesos y se conserva solo la evidencia necesaria para documentar el resultado. Si avanza, tampoco conviene transformar el conjunto experimental en producción por inercia. El sistema definitivo necesita su propia fuente, permisos, retención, monitoreo y proceso de corrección.

La evidencia de cierre puede ser sencilla: inventario de ubicaciones, responsable de cada eliminación, fecha, excepciones justificadas y confirmación de accesos revocados. Esa disciplina permite repetir el prototipo sin acumular bases paralelas.

La mejor prueba usa menos datos y deja más conocimiento

Un buen prototipo no se mide por cuánto leyó. Se mide por lo que permitió decidir. Al terminar, la empresa debería saber qué tarea puede asistir la IA, qué excepciones debe escalar, qué campos influyen de verdad, dónde fallan los datos y cuánto trabajo humano permanece.

Ese aprendizaje aparece con una muestra representativa, criterios definidos y un entorno controlado. La base completa rara vez aporta la misma claridad. Más bien hace difícil distinguir qué información fue útil, aumenta el costo de protegerla y complica la salida si la prueba no funciona.

Empezar con menos datos no significa probar en condiciones irreales. Significa llevar al prototipo los casos que ponen a prueba su capacidad, sin entregar información que no participa en la decisión. La empresa conserva control, el equipo obtiene evidencia y el siguiente paso se discute sobre trabajo observado, no sobre una demo que tuvo acceso a todo.