Datos sintéticos: cómo probar software e IA con casos útiles

La pregunta es qué error queremos encontrar

Una empresa que conecta su CRM con un sistema de pedidos necesita ensayar altas, modificaciones y excepciones. Para muchas pruebas funcionales puede construir registros ficticios a partir de reglas acordadas, sin trasladar una copia completa de clientes al entorno de desarrollo. Esta guía explica cómo decidir qué fabricar y qué comprobar antes de confiar en ese conjunto.

El informe técnico de NeMo Data Designer, presentado en arXiv el 15 de septiembre de 2026, describe un marco para generar datos sintéticos mediante columnas configurables y dependencias entre campos. Incluye un ciclo de generación de muestras, inspección y ajuste antes de ampliar. Es una referencia reciente sobre herramientas de generación, no una prueba de resultados para una empresa chilena. Greco y colaboradores, informe de NeMo Data Designer.

La oportunidad práctica es convertir los requisitos del negocio en escenarios repetibles. Acumular miles de registros plausibles aporta poco si ninguno reproduce un pedido incompleto, una devolución parcial o una diferencia de moneda. La aceptación debe partir de situaciones y respuestas esperadas, no del volumen de datos producido.

Elegir el método según la prueba

Para verificar una regla, proponemos generar casos desde una especificación: campos permitidos, relaciones y resultados esperados. Un generador convencional puede resolver fechas, cantidades e identificadores; un modelo de lenguaje puede aportar variaciones de textos cuando ese sea el aspecto que se quiere evaluar. No es necesario usar IA para fabricar cada columna.

Otro objetivo es reproducir distribuciones para probar análisis o modelos predictivos. Allí importan las proporciones y las relaciones estadísticas del origen, además de que las filas parezcan razonables. La documentación de Snowflake describe la generación de tablas artificiales a partir de tablas existentes y la conservación de claves consistentes para cruzarlas, cuando se configuran como tales. Snowflake, generación de datos sintéticos.

Estas dos necesidades requieren criterios distintos. Un conjunto pequeño con excepciones deliberadas puede servir para probar una integración; por sí solo no representa la frecuencia real de esas excepciones ni permite estimar el desempeño de un modelo sobre toda la cartera. Conviene registrar el propósito del conjunto para evitar reutilizarlo fuera de ese alcance.

Conservar relaciones, no solo formatos

Proponemos comenzar con un esquema de cliente ficticio, pedido y detalle de productos. Cada pedido debe referenciar un cliente existente en el conjunto; cada línea debe pertenecer a un pedido; el total debe poder recalcularse con la regla acordada. Para una operación chilena, también conviene incluir moneda, zona horaria y formatos de fecha que efectivamente utiliza el sistema.

Ejemplo hipotético: el pedido DEMO-001 contiene dos unidades de $15.000 y una de $8.000, sin descuentos ni cargos adicionales. El total esperado es $38.000. Una variante deliberadamente incorrecta declara $37.000 y debe activar el control de diferencia. Otra repite el identificador del pedido para comprobar el tratamiento de duplicados. Son escenarios de ensayo, no transacciones ni resultados de clientes.

Los casos inválidos deben llevar una etiqueta explícita y una respuesta esperada. Así se distingue un error introducido a propósito de un defecto del generador. También deberían existir casos con campos opcionales vacíos, cambios de estado y fechas fuera del rango aceptado, seleccionados según el proceso real. La revisión del responsable de negocio establece qué comportamiento cuenta como correcto.

Sintético no demuestra anonimato

El nombre del método no basta para concluir que puede compartirse libremente. NIST explicó el 3 de mayo de 2021 que muchas técnicas de generación sintética no satisfacen privacidad diferencial ni ofrecen sus garantías matemáticas. Esta referencia conceptual histórica ayuda a separar la apariencia artificial de una evaluación de privacidad. NIST, datos sintéticos con privacidad diferencial.

Hay un detalle concreto que conviene revisar: Snowflake indica que los valores de texto categóricos pueden proceder del origen. También documenta un filtro opcional para retirar filas demasiado similares a los datos de entrada. Por tanto, no corresponde asumir que todos los valores fueron inventados ni que activar un filtro resuelve cualquier riesgo de exposición. Snowflake, valores generados y filtro de similitud.

Para el piloto funcional proponemos partir de reglas y ejemplos ficticios revisados, sin incluir correos, contratos o conversaciones reales en las instrucciones de generación. Si se requiere aprender de datos de producción, esa entrada necesita una evaluación separada: qué información se utiliza, dónde se procesa, quién accede y qué se autoriza exportar. La utilidad del conjunto y su privacidad son verificaciones diferentes.

Añadir IA donde aporte variación comprobable

En un asistente comercial, por ejemplo, pueden fabricarse distintas maneras de pedir el estado del mismo pedido ficticio. La IA genera la redacción; una tabla controlada define el estado correcto y la respuesta permitida. El evaluador contrasta la respuesta con esa referencia, sin aceptar como verdad una etiqueta inventada por el mismo modelo que produjo la pregunta.

Conviene reservar escenarios que no se usaron para ajustar instrucciones. Si cada fallo del asistente termina convertido en una nueva instrucción y se vuelve a medir sobre las mismas preguntas, el resultado describe ese conjunto conocido. Una evaluación posterior con datos reales autorizados y separados permite investigar cuánto se conserva del desempeño fuera del ensayo; la prueba sintética no lo demuestra por sí sola.

Qué pedir en una primera entrega

El piloto debería entregar un inventario de escenarios, los archivos generados, las reglas de validación y un reporte de resultados. Registrar versión del generador, configuración y fecha ayuda a explicar diferencias entre ejecuciones. Como métricas iniciales proponemos cobertura de escenarios acordados, errores detectados y tiempo de revisión, con una línea base comparable y sin prometer ahorros.

En un proyecto de desarrollo de software a medida, este material puede formar parte de los criterios de aceptación. La primera decisión no es cuántos registros generar: es qué fallo relevante queremos detectar, cuál sería la respuesta correcta y qué evidencia necesitamos para autorizar el siguiente paso.