1. Naturaleza de SUActivo

Estas Políticas de Métodos de Actualización, Curaduría, Versionado y Vigencia de Información de Usuarios Sintéticos, en adelante “SUActivo”, regulan los procesos mediante los cuales Synthetic User By jsadsAI | José Santamaría actualiza, revisa, corrige, valida, versiona, audita, sustituye, depura, enriquece y mantiene la información utilizada para construir y operar usuarios sintéticos.

SUActivo aplica a fuentes oficiales, públicas, privadas, licenciadas, académicas, gubernamentales y empresariales; APIs externas; redes sociales; datos abiertos, agregados, anonimizados y pseudonimizados; datos cargados por clientes; datasets curados; usuarios sintéticos base, regionales y sectoriales; modelos de comportamiento; variables de estudio; reportes; dashboards; outputs; metadatos; versiones de modelos; y estudios históricos.

2. Objetivo de SUActivo

SUActivo tiene como objetivo establecer un marco claro para:

1. Definir cómo se actualizan los usuarios sintéticos.
2. Establecer qué fuentes pueden alimentar la plataforma.
3. Determinar criterios de calidad, vigencia y confiabilidad.
4. Documentar fecha de corte, versión y trazabilidad de cada estudio.
5. Evitar promesas de actualización en tiempo real no garantizada.
6. Evitar uso de datos obsoletos sin advertencia.
7. Reducir errores por fuentes deficientes.
8. Mejorar precisión progresiva de estudios.
9. Permitir auditoría metodológica.
10. Controlar sesgos y desviaciones.
11. Gestionar cambios en APIs externas.
12. Corregir errores de fuente, modelo o procesamiento.
13. Definir límites de responsabilidad por actualización.
14. Proteger la propiedad intelectual del sistema de curaduría.
15. Establecer reglas para estudios históricos frente a nuevas versiones.

3. Relación con otros documentos

SUActivo debe interpretarse junto con SUWeb, SUConsola, SUData, SUGarantia, contratos empresariales, anexos de tratamiento de datos, anexos de procesamiento local, anexos de fuentes privadas, acuerdos de licencia, NDAs, SLAs, propuestas aceptadas, órdenes de servicio, políticas de APIs externas y términos de proveedores. En caso de conflicto, prevalecerá el documento más específico para el servicio contratado.

4. Definiciones

Actualización

proceso mediante el cual se incorpora, modifica, elimina, recalibra o sustituye información, variables, fuentes, modelos, ponderaciones o usuarios sintéticos.

Curaduría

proceso técnico, metodológico y, cuando aplique, humano, mediante el cual se limpia, valida, normaliza, compara, clasifica, documenta y mejora la calidad de los datos.

Fuente

entidad, base, API, documento, dataset, estudio, repositorio, publicación, encuesta, censo, dato abierto, proveedor o sistema que aporta información.

Fuente primaria

fuente original o autoridad principal que produce el dato.

Fuente secundaria

fuente que recopila, interpreta, transforma, redistribuye o analiza datos de fuentes primarias.

Fuente oficial

organismo gubernamental, estadístico, censal, público o autoridad competente que produce información dentro de su función institucional.

Fuente privada

empresa, proveedor, centro de encuestas, consultora, organización, universidad, laboratorio o entidad privada que produce o licencia información.

Dataset curado

conjunto de datos que ha pasado por procesos de limpieza, validación, estandarización, enriquecimiento, documentación y control de calidad.

Usuario sintético

representación artificial, estadística, algorítmica o probabilística de perfiles, comportamientos, segmentos, variables o escenarios de una población, zona, sector, mercado, ciudad o país.

Snapshot

captura versionada de datos, modelos, variables y configuración usada para ejecutar un estudio en una fecha determinada.

Versión

identificador técnico que permite distinguir un estado específico de una fuente, dataset, modelo, usuario sintético, metodología, output o estudio.

Fecha de corte

fecha hasta la cual una fuente, dataset, modelo o estudio incorpora información disponible.

Fecha de ingesta

fecha en la que Synthetic User incorpora una fuente o actualización a sus sistemas.

Fecha de publicación de fuente

fecha en la que la entidad emisora publica el dato.

Score de confianza

indicador interno o visible que estima calidad, cobertura, actualidad, consistencia, trazabilidad y utilidad de una fuente o estudio.

Drift de datos

cambio en la distribución, comportamiento, cobertura o relevancia de datos frente a versiones previas.

Drift de modelo

pérdida de desempeño, estabilidad, coherencia o precisión de un modelo frente a cambios en los datos o contexto.

Dato obsoleto

dato que ha perdido vigencia para una finalidad determinada.

Dato estable

dato que no cambia frecuentemente o cuyo cambio no afecta de forma sustancial el estudio.

Dato volátil

dato que cambia con alta frecuencia, como tendencias sociales, precios, opinión pública, actividad digital o indicadores coyunturales.

Errata

corrección formal de un error detectado en fuente, procesamiento, output, reporte o documentación.

5. Principios rectores de actualización

1. Legalidad de fuente: solo se usarán fuentes legalmente admisibles.
2. Trazabilidad: cada fuente relevante debe tener origen, fecha, versión y estado.
3. Calidad: se priorizarán datos verificables, consistentes y metodológicamente sólidos.
4. Actualidad proporcional: no todos los datos requieren la misma frecuencia de actualización.
5. Finalidad: la actualización debe responder a la utilidad del estudio.
6. Minimización: no se incorporarán variables innecesarias.
7. Seguridad: las actualizaciones no deben comprometer datos, sistemas o derechos.
8. No reidentificación: ninguna actualización debe facilitar identificación de personas reales.
9. Versionado: los cambios relevantes deben quedar registrados.
10. Reproducibilidad razonable: los estudios deben asociarse a un snapshot.
11. Corrección: los errores detectados deben ser evaluados y, si procede, corregidos.
12. Transparencia metodológica: el usuario debe conocer límites de vigencia y confianza.
13. No garantía absoluta: actualizar datos no elimina margen de error.
14. Mejora continua: los usuarios sintéticos deben evolucionar con mejores fuentes y modelos.
15. Control de riesgo: sectores sensibles requieren actualización y validación reforzada.

6. Alcance de la actualización

Synthetic User podrá actualizar fuentes de datos, datasets base y usuarios sintéticos; variables demográficas, económicas, territoriales, sociales, culturales, comerciales, políticas agregadas, de consumo, de salud pública agregada, de movilidad agregada, de percepción, sectoriales y temporales; modelos de comportamiento; ponderaciones; segmentos; clústeres; embeddings; taxonomías; ontologías; dashboards; reportes tipo; plantillas de estudio; APIs internas; pipelines de datos; scores de calidad; alertas metodológicas; niveles de confianza; documentación; y sistemas de auditoría.

7. Lo que SUActivo no garantiza

SUActivo no garantiza:

1. Actualización en tiempo real de todas las fuentes.
2. Actualización simultánea de todos los países.
3. Actualización simultánea de todas las ciudades.
4. Actualización simultánea de todos los sectores.
5. Disponibilidad permanente de APIs externas.
6. Ausencia de errores en fuentes oficiales.
7. Ausencia de errores en fuentes privadas.
8. Ausencia total de sesgos.
9. Exactitud del 100%.
10. Reprocesamiento automático de estudios históricos.
11. Que todos los outputs antiguos sean reemplazados por nuevos.
12. Que cada fuente tenga misma frecuencia de actualización.
13. Que toda zona tenga datos suficientes.
14. Que toda variable pueda actualizarse.
15. Que los resultados no cambien después de una actualización.
16. Que una actualización mejore todos los estudios.
17. Que se mantengan fuentes retiradas por terceros.
18. Que las APIs externas no cambien términos.
19. Que el cliente reciba devolución por cambio de fuente.
20. Que se incorporen fuentes solicitadas si no cumplen criterios legales o técnicos.

8. Tipos de actualización

8.1 Actualización automática

Se realiza mediante pipelines, APIs, conectores, cron jobs, sistemas de ingesta o procesos automatizados. Aplica a fuentes con acceso técnico estable, licencia válida, estructura predecible, permiso de uso, frecuencia conocida, bajo riesgo de reidentificación, formato compatible y reglas de validación.

8.2 Actualización manual

Se realiza por revisión humana, carga controlada, validación documental o intervención técnica. Aplica cuando la fuente es sensible, no tiene API, requiere interpretación o cambia metodología; cuando hay riesgo legal, de sesgo o de duplicidad; cuando hay datos incompletos; cuando se requiere aprobación interna; o cuando se trata de un sector regulado.

8.3 Actualización híbrida

Combina ingesta automática con revisión humana. Aplica a fuentes oficiales complejas, fuentes privadas, estudios de alto impacto, datos de salud pública, datos políticos agregados, datos económicos sensibles, datos sociales volátiles, estudios gubernamentales, estudios empresariales críticos y usuarios sintéticos de alta precisión.

8.4 Actualización por evento

Se ejecuta cuando ocurre un evento relevante: publicación de censo; nueva encuesta; cambio regulatorio; cambio de API; corrección de fuente; publicación de errata; evento social significativo; crisis sanitaria; cambio económico abrupto; cambio territorial o electoral; cambio de metodología oficial; detección de drift; incidente de calidad; o solicitud contractual empresarial.

8.5 Actualización programada

Se ejecuta en ciclos predefinidos: diario, semanal, quincenal, mensual, trimestral, semestral, anual, multianual, según calendario oficial o según contrato.

8.6 Actualización bajo demanda

Se ejecuta por solicitud de cliente, contrato empresarial, estudio personalizado, procesamiento local o necesidad específica. Puede tener costo adicional.

9. Frecuencias orientativas de actualización

Las frecuencias siguientes son orientativas y pueden variar según país, fuente, licencia, contrato, disponibilidad, metodología y riesgo.

10. Clasificación de fuentes por nivel

Nivel 0 — Fuente crítica oficial primaria

Organismos nacionales de estadística, centros de censo, bancos centrales, ministerios, entidades regulatorias, autoridades electorales, entidades oficiales sectoriales, organizaciones internacionales oficiales, portales gubernamentales y repositorios estadísticos públicos. Uso preferente para estudios de alta importancia.

Nivel 1 — Fuente institucional confiable

Universidades, centros de investigación, organizaciones multilaterales, organismos de cooperación, cámaras de comercio, asociaciones sectoriales, institutos reconocidos, think tanks con metodología documentada, laboratorios académicos y observatorios sectoriales. Uso permitido con evaluación metodológica.

Nivel 2 — Fuente privada licenciada

Empresas de investigación, centros de encuestas, proveedores de datos, consultoras, plataformas privadas, bases comerciales, estudios contratados, paneles autorizados, datos de mercado y APIs pagas. Uso sujeto a licencia, contrato y restricciones.

Nivel 3 — Fuente social o digital autorizada

APIs de redes sociales y plataformas digitales, datos agregados de interacción, tendencias públicas permitidas, métricas digitales, datos de búsqueda agregados, datos de contenido bajo permisos, señales de mercado digital, fuentes de reputación agregada y métricas de audiencia. Uso sujeto a términos de cada plataforma y restricciones reforzadas.

Nivel 4 — Fuente experimental

Fuentes emergentes, datos no consolidados, estudios preliminares, datasets piloto, variables nuevas, modelos en prueba, datos con baja cobertura o granularidad, fuentes no plenamente validadas y resultados exploratorios. Uso con advertencia visible.

Nivel prohibido

No se aceptan: bases filtradas; datos obtenidos por hacking; scraping ilegal; datos personales sin base legal; datos sensibles sin autorización; datos de menores sin base legal estricta; información clasificada no autorizada; secretos de terceros; datos comprados ilegalmente; datos que permitan persecución o reidentificación; ni fuentes que violen términos de terceros.

11. Fuentes oficiales por país de intervención inicial

Synthetic User podrá priorizar, entre otras, las siguientes fuentes oficiales o institucionales de referencia:

La inclusión de una fuente en esta lista no significa que dicha fuente avale, patrocine, certifique o participe en Synthetic User.

12. Criterios de aceptación de fuentes

Antes de incorporar una fuente, Synthetic User podrá evaluar: legalidad, licencia y términos de uso; autoridad emisora; metodología; fecha de publicación y periodo cubierto; cobertura territorial y poblacional; tamaño de muestra; representatividad; granularidad; variables disponibles; formato; consistencia; trazabilidad; actualización esperada; historial de cambios; riesgo de sesgo, de reidentificación, regulatorio y reputacional; compatibilidad técnica; restricciones de redistribución, entrenamiento, publicación y exportación; costo; dependencia del proveedor; y utilidad para usuarios sintéticos.

13. Criterios de rechazo de fuentes

Synthetic User podrá rechazar una fuente cuando no tenga origen claro, licencia verificable o metodología suficiente; contenga datos personales sin base legal, datos sensibles sin autorización, datos de menores sin base legal o información filtrada; haya sido obtenida ilegalmente; viole términos de una plataforma; permita reidentificación; tenga sesgo extremo no corregible, baja calidad o inconsistencias graves; no tenga fecha de corte o cobertura suficiente; no pueda documentarse ni auditarse; tenga restricciones incompatibles; exija atribuciones imposibles; o implique riesgo legal, ético o reputacional.

14. Proceso general de actualización

Synthetic User podrá seguir un proceso general como: identificación de fuente; evaluación legal, técnica, metodológica, de privacidad, de licencia y de riesgo; ingesta preliminar; validación de esquema; limpieza; normalización; deduplicación; enriquecimiento; cruce con fuentes existentes; detección de anomalías; evaluación de sesgo; asignación de score de calidad; versionado; prueba en sandbox; revisión humana cuando aplique; aprobación; despliegue; monitoreo; documentación; y comunicación interna o externa cuando corresponda.

15. Ingesta de datos

La ingesta de datos podrá realizarse por API; archivos CSV, XLSX, JSON o XML; bases SQL o NoSQL; data warehouse o data lake; portal de datos abiertos; descarga manual; conector autorizado; webhook; transferencia segura; repositorio privado; entorno local; integración empresarial; carga por cliente; procesamiento documental; o pipeline personalizado.

16. Validación de esquema

Antes de usar una fuente, Synthetic User podrá validar formato; tipos de datos; campos obligatorios; rango de valores; unidades de medida; códigos territoriales y sectoriales; fechas; idioma; codificación; duplicados; valores nulos y atípicos; inconsistencias; cambios de columnas, API o versión; integridad referencial; y compatibilidad con taxonomías y modelos.

17. Limpieza de datos

La limpieza podrá incluir eliminación de duplicados; corrección de formatos; homologación de nombres; normalización de categorías; estandarización territorial, temporal y monetaria; conversión de unidades; corrección de codificación; supresión de campos innecesarios; eliminación de identificadores; tratamiento de valores nulos y outliers; consolidación de registros; eliminación de ruido; separación de variables; agrupación de segmentos; documentación de transformaciones; control de versiones; y validación posterior.

18. Normalización territorial

Synthetic User podrá normalizar información territorial usando país, región, departamento, provincia, estado, municipio, ciudad, distrito, comuna, zona, código geográfico, código postal, coordenadas agregadas, división administrativa oficial, división comercial, división censal, división electoral agregada, área metropolitana, área rural y área urbana. La normalización territorial no debe usarse para identificar domicilios o personas.

19. Normalización temporal

Synthetic User podrá etiquetar datos por fecha de publicación, fecha de corte, fecha de ingesta, fecha de actualización, periodo de observación, periodo de vigencia, ciclo estadístico, versión, horizonte de proyección y fecha de expiración metodológica. Los reportes deberán indicar, cuando sea viable, la fecha de corte de los datos relevantes.

20. Enriquecimiento de usuarios sintéticos

Los usuarios sintéticos podrán enriquecerse con variables demográficas, socioeconómicas, culturales, territoriales, de consumo, de comportamiento, de movilidad agregada, de acceso digital, de mercado, sectoriales, de percepción, de intención, de afinidad, de necesidad, de barrera, de oportunidad, de riesgo agregado, de sensibilidad contextual, históricas y proyectadas. Estas variables deben mantenerse en niveles que eviten identificación de personas reales.

21. Métodos de actualización de usuarios sintéticos

Reponderación: ajuste de pesos estadísticos de variables existentes según nueva información. Recalibración: ajuste de parámetros del modelo para mejorar correspondencia con datos actuales. Enriquecimiento: adición de nuevas variables, fuentes o dimensiones. Depuración: eliminación de variables obsoletas, redundantes, sesgadas o no confiables. Reclusterización: reorganización de segmentos o grupos sintéticos según nuevos patrones. Reconstrucción parcial: actualización de una parte del usuario sintético sin reemplazar toda la estructura. Reconstrucción completa: regeneración completa cuando los cambios son estructurales. Actualización incremental: incorporación progresiva de nuevos datos. Por país: ajuste según legislación, fuentes y contexto local. Por sector: ajuste por salud, empresa, gobierno, política, educación, defensa, retail, consumo, tecnología u otro permitido. Por ciudad o zona: ajuste territorial cuando la disponibilidad de datos lo permita. Por evento: ajuste ante crisis, cambios regulatorios, elecciones, eventos económicos, cambios sociales o nuevos estudios.

22. Versionado de usuarios sintéticos

Cada usuario sintético o conjunto de usuarios sintéticos podrá estar asociado a: ID; tipo; país; región; ciudad; sector; segmento; versión de dataset; versión de modelo; versión de fuente; fecha de creación; fecha de última actualización; fecha de corte; estado de vigencia; score de confianza; nivel de granularidad; restricciones; variables principales; metodología; e historial de cambios.

23. Versionado de estudios

Cada estudio ejecutado podrá registrar: ID; usuario ejecutor; cuenta; fecha y hora; país; zona; sector; objetivo; variables; parámetros; fuentes usadas y sus versiones; versiones de dataset, modelo y usuarios sintéticos; configuración; prompt o instrucción; créditos consumidos; output generado; score de confianza; advertencias mostradas; fecha de corte; estado del estudio; hash o identificador de integridad cuando aplique; y snapshot metodológico.

24. Snapshots metodológicos

Synthetic User podrá crear snapshots para preservar el estado técnico de un estudio. Un snapshot puede incluir fuentes utilizadas, versiones, fecha de corte, variables, ponderaciones, modelo, segmentos, configuración, parámetros, advertencias, score de confianza, metadatos, output, reporte y limitaciones. El snapshot permite explicar por qué un estudio produjo un resultado determinado en una fecha específica.

25. Estudios históricos

Los estudios históricos se interpretan bajo las condiciones, fuentes, modelos y versiones vigentes al momento de ejecución. Una actualización posterior: no invalida automáticamente el estudio histórico; no obliga a reembolso automático; no obliga a reprocesamiento gratuito; no garantiza coincidencia con resultados nuevos; puede requerir nuevo estudio o nuevos créditos; puede generar cambios en conclusiones; puede mejorar, corregir o modificar estimaciones; puede requerir adenda si el contrato lo prevé; y debe analizarse según relevancia y finalidad.

26. Reprocesamiento de estudios

Synthetic User podrá reprocesar estudios cuando exista error técnico imputable a Synthetic User, error metodológico comprobado o error de fuente relevante; se haya publicado errata; el contrato o SLA lo establezca; el cliente adquiera reprocesamiento; se trate de estudio crítico; se requiera por cumplimiento; o Synthetic User lo considere necesario. No todo cambio de fuente o modelo genera derecho a reprocesamiento gratuito.

27. Etiquetas de vigencia

Synthetic User podrá clasificar datos, usuarios sintéticos o estudios con etiquetas como:

28. Score de confianza

Synthetic User podrá asignar un score de confianza basado en autoridad de fuente, legalidad, licencia, fecha de actualización, cobertura territorial y poblacional, tamaño de muestra, representatividad, consistencia histórica y con otras fuentes, granularidad, estabilidad metodológica, transparencia, disponibilidad de metadatos, riesgo de sesgo y de reidentificación, compatibilidad con finalidad, calidad técnica, frecuencia de actualización y nivel de revisión humana.

29. Niveles de confianza recomendados

Los niveles de confianza son orientativos y no constituyen garantía absoluta.

30. Alertas de actualización

SUConsola podrá mostrar alertas como: fuente recientemente actualizada; fuente en revisión; fuente con baja cobertura; fuente histórica o experimental; fuente retirada; modelo actualizado; usuario sintético recalibrado; estudio ejecutado con versión anterior; reprocesamiento recomendado; nueva fuente disponible; cambio metodológico relevante; drift detectado; baja confianza; datos insuficientes; API externa degradada; fuente pendiente de validación; variable no actualizada; reporte sujeto a revisión; y errata disponible.

31. Registro de cambios

Synthetic User podrá mantener un registro interno o público de cambios relevantes, que podrá incluir fecha, fuente afectada, país, sector, tipo de cambio, motivo, impacto, versión anterior y nueva, responsable interno, estado, recomendación, necesidad de reprocesamiento, clientes impactados y acción tomada. No todos los cambios menores serán publicados al usuario.

32. Cambios menores

Se consideran cambios menores: correcciones de formato; normalizaciones internas; ajustes de nombres; eliminación de duplicados; optimización de pipeline; correcciones de visualización; ajustes de rendimiento; mejoras de documentación; reetiquetado interno; y cambios sin impacto material en outputs. Estos cambios pueden implementarse sin aviso individual.

33. Cambios materiales

Se consideran cambios materiales: sustitución de fuente principal; cambio de metodología; corrección significativa de datos; cambio de ponderaciones clave; recalibración importante de modelo; retiro de fuente crítica; cambio de cobertura territorial o de granularidad; cambio de nivel de confianza; corrección de output relevante; detección de sesgo importante; cambio por obligación legal; cambio de API externa; cambio de licencia; y nueva restricción de uso. Synthetic User podrá comunicar cambios materiales por consola, correo, changelog, reporte o documentación.

34. Corrección de errores

Cuando se detecte un error, Synthetic User podrá clasificar su severidad; identificar la fuente afectada; evaluar impacto; pausar la fuente y los estudios relacionados; corregir datos; recalcular variables; reprocesar modelos; emitir errata; actualizar reportes; notificar a clientes afectados; marcar estudios históricos; bloquear exportaciones; emitir créditos si corresponde; y aplicar SUGarantia cuando proceda.

35. Niveles de severidad de error

36. Erratas

Synthetic User podrá emitir erratas cuando una fuente oficial o privada corrige datos; se detecta error de ingesta, procesamiento, modelo, interpretación automática, visualización, exportación o metadatos; o se detecta error que afecte reportes. La errata podrá indicar qué ocurrió, qué datos fueron afectados, qué estudios podrían verse afectados, qué versión corrige el error, qué acción se recomienda, si procede reprocesamiento y si procede crédito o devolución según SUGarantia.

37. Retiro de fuentes

Synthetic User podrá retirar una fuente cuando la licencia expire; la fuente sea eliminada; la API se suspenda; cambien términos de uso; se detecte baja calidad, riesgo legal, riesgo de reidentificación o sesgo grave; la fuente quede obsoleta o sea sustituida por otra mejor; la fuente viole SUData; el proveedor lo exija; una autoridad lo requiera; se detecte origen ilícito; o exista riesgo reputacional.

38. Sustitución de fuentes

Synthetic User podrá sustituir fuentes por una fuente oficial más reciente, con mejor cobertura, metodología o licencia, con menor riesgo, más granular, más estable, más trazable, menos sesgada o más compatible técnicamente. La sustitución puede cambiar resultados.

39. Fuentes externas y APIs

Cuando una actualización dependa de APIs externas, Synthetic User podrá verse afectado por rate limits; cambios de endpoint, versión, permisos, precios o términos; suspensión de acceso; revisión de aplicación; errores del proveedor; mantenimiento externo; eliminación de datos; y restricciones de almacenamiento, entrenamiento, redistribución y publicación. Synthetic User no garantiza continuidad de APIs externas.

40. Datos de redes sociales

Los datos provenientes de redes sociales o plataformas digitales pueden cambiar rápidamente, ser parciales, estar sujetos a permisos y a sesgos de plataforma, representar comportamiento digital y no población completa, excluir audiencias sin presencia digital, estar afectados por bots o campañas coordinadas, tener restricciones de uso y no estar disponibles de forma continua. Synthetic User podrá usar estos datos preferentemente de forma agregada, autorizada y contextualizada.

41. Prohibición de fuentes ilegales

No se incorporarán fuentes obtenidas por hacking, filtración, scraping prohibido, compra ilegal, suplantación, violación de API, de credenciales, de confidencialidad, de propiedad intelectual, de derechos de titulares, de datos personales, datos sensibles, datos de menores o secretos empresariales, ni en violación de normativa aplicable.

42. Datos cargados por clientes

Cuando el cliente cargue datos para actualizar usuarios sintéticos o ejecutar estudios, será responsable de la legalidad de la fuente, vigencia, calidad, exactitud, licencia, base legal, consentimiento cuando aplique, derechos de terceros, formato, metodología, ausencia de datos prohibidos, sensibles o de menores no autorizados, actualización periódica, corrección de errores, notificación de restricciones, revocaciones, cambios de licencia y retiro de datos, y uso permitido de outputs.

43. Actualización de datos del cliente

Los datos del cliente podrán actualizarse por nueva carga del cliente, integración API autorizada, sincronización programada, procesamiento local, contrato empresarial, solicitud de soporte, actualización manual, reemplazo completo, actualización incremental o corrección de error. Synthetic User no está obligado a verificar de forma independiente la veracidad de todos los datos del cliente, salvo contrato específico.

44. Datos insuficientes

Cuando no exista información suficiente para actualizar una variable, zona, país, segmento o usuario sintético, Synthetic User podrá mantener versión anterior con advertencia; marcar dato como histórico o de baja confianza; suspender variable; reducir granularidad; usar rango estimado; usar fuente alternativa; requerir datos adicionales; bloquear estudio; rechazar output concluyente; recomendar estudio físico; o recomendar procesamiento personalizado.

45. Actualización y precisión

La actualización de datos puede mejorar precisión, pero no garantiza exactitud absoluta; eliminación de sesgo o incertidumbre; igual precisión en todos los territorios, sectores o periodos; resultados idénticos a estudios físicos, encuestas privadas o fuentes futuras; ni resultados comerciales específicos. La precisión depende de fuente, zona, disponibilidad, metodología, granularidad, variables y configuración.

46. Rango estimado de exactitud

Synthetic User podrá comunicar rangos estimados de aproximación, incluyendo referencias entre 90% y 98% bajo condiciones favorables. Estos rangos son estimaciones condicionadas, no garantía universal; dependen de la zona, país, sector, calidad y cantidad de datos, granularidad, actualización, modelo, tipo de estudio y configuración; pueden ser menores en zonas de baja cobertura; pueden variar después de nuevas fuentes; y no generan derecho automático a devolución.

47. Drift de datos

Synthetic User podrá monitorear drift de datos cuando cambie la distribución poblacional, el comportamiento de consumo, la situación económica, la opinión pública, una fuente, una metodología, la cobertura territorial, el volumen de datos, la frecuencia o la relevancia de una variable. Cuando se detecte drift, Synthetic User podrá recalibrar modelos, actualizar usuarios sintéticos o marcar advertencias.

48. Drift de modelo

Synthetic User podrá monitorear drift de modelo cuando el desempeño cae, las predicciones se alejan de nuevas fuentes, la distribución de outputs cambia sin explicación, la calidad disminuye, aparecen sesgos, cambian variables críticas, o cambia el contexto social, económico, político o la disponibilidad de datos. El drift de modelo puede requerir recalibración, reentrenamiento, ajuste o suspensión temporal.

49. Backtesting

Synthetic User podrá usar backtesting para comparar resultados pasados contra datos posteriores, sirviendo para medir precisión, detectar sesgos, ajustar ponderaciones, mejorar modelos, validar usuarios sintéticos, detectar drift, corregir metodologías, mejorar scoring, identificar zonas débiles y mejorar confianza. El backtesting no implica que todos los estudios históricos se corrijan automáticamente.

50. Validación cruzada

Synthetic User podrá comparar fuentes para validar coherencia, magnitud, tendencia, fecha, cobertura, distribución, segmentos, territorios, variables y resultados. Cuando existan discrepancias entre fuentes, Synthetic User podrá priorizar fuente oficial, más reciente, más granular o con mejor metodología; usar ponderación; mostrar rango; marcar incertidumbre; excluir fuente; solicitar revisión humana; o bloquear output.

51. Control de sesgos

Synthetic User podrá evaluar sesgos de cobertura, territorial, socioeconómico, digital, de muestra, temporal, de idioma, cultural, de plataforma, político, comercial, histórico, de supervivencia, de selección y de medición. No se garantiza eliminación absoluta de sesgos.

52. Mitigación de sesgos

La mitigación podrá incluir reponderación; exclusión de variables; inclusión de fuentes complementarias; reducción de granularidad; normalización; segmentación más amplia; validación humana; comparación con fuentes oficiales; etiquetas de advertencia; rediseño metodológico; suspensión de fuente; recalibración; análisis de sensibilidad; documentación de límites; y revisión de impacto.

53. Usuarios sintéticos en sectores sensibles

En sectores sensibles, las actualizaciones podrán requerir controles reforzados. Sectores sensibles incluyen salud; política; gobierno; defensa; seguridad; inteligencia; educación; empleo; crédito; seguros; vivienda; justicia; migración; servicios públicos; poblaciones vulnerables; niños, niñas y adolescentes; comunidades étnicas; opinión pública; territorios en conflicto; e infraestructura crítica.

54. Actualizaciones en salud

Las actualizaciones en salud deben priorizar datos agregados, fuentes oficiales, salud pública, series temporales verificables, cobertura territorial, no identificación individual, validación metodológica, revisión humana, seguridad reforzada y advertencias de no diagnóstico. Synthetic User no debe actualizar usuarios sintéticos con historias clínicas identificables en la consola estándar.

55. Actualizaciones en política y opinión pública

Las actualizaciones en política, opinión pública o gobierno deben evitar perfilamiento individual de votantes, reidentificación, manipulación electoral, supresión de voto, desinformación, persecución política, microtargeting ilegal, simulación fraudulenta de apoyo ciudadano, segmentación discriminatoria y uso de datos sensibles sin base legal. Los datos políticos deben tratarse preferentemente de forma agregada, contextual y con revisión reforzada.

56. Actualizaciones en defensa y seguridad

Las actualizaciones relacionadas con defensa, seguridad o inteligencia podrán ser rechazadas si implican selección de objetivos, daño físico, operaciones ofensivas, vigilancia individual, persecución, represión, inteligencia ilegal, control poblacional abusivo, identificación de personas o violación de derechos humanos. Synthetic User podrá suspender cualquier actualización que genere riesgo de daño.

57. Actualizaciones comerciales y de mercado

En empresa privada y mercado, las actualizaciones podrán incluir datos de demanda, consumo, ubicación agregada, económicos, de competencia, de precios, de comportamiento digital, de adopción, sectoriales, de expansión territorial, de intención, de percepción, de audiencia, de tendencias y de canales. Estos datos no deben usarse para discriminación, fraude, manipulación o vulneración de derechos de consumidores.

58. Actualizaciones con datos personales

Por defecto, Synthetic User no requiere datos personales identificables para actualizar usuarios sintéticos base. Cuando exista tratamiento de datos personales, debe existir base legal y finalidad legítima; aplicarse minimización y SUData; evitarse identificación; limitarse retención; aplicarse seguridad y contrato si corresponde; documentarse el tratamiento; y prohibirse la reidentificación.

59. Actualizaciones con datos sensibles

Las actualizaciones con datos sensibles están prohibidas por defecto en la consola estándar. Solo podrán permitirse cuando exista contrato especial, base legal estricta, autorización cuando aplique, anexo de datos, evaluación de impacto, seguridad reforzada, revisión legal, minimización y limitación de finalidad, y cuando Synthetic User lo apruebe expresamente.

60. Protección contra reidentificación

Antes de actualizar usuarios sintéticos, Synthetic User podrá evaluar si el nuevo dato aumenta granularidad excesiva; permite identificar individuos, inferir domicilios o datos sensibles, cruzar variables raras; reduce el tamaño de muestra; expone grupos vulnerables; o permite persecución, scoring individual o vigilancia. Si existe riesgo, podrá reducirse granularidad, eliminar variables o bloquear la actualización.

61. Umbrales mínimos

Synthetic User podrá aplicar umbrales mínimos para publicar o usar datos, considerando tamaño mínimo de grupo, territorial y de muestra; nivel mínimo de agregación; número mínimo de fuentes; nivel mínimo de confianza; periodo mínimo de estabilidad; calidad y representatividad mínimas; y riesgo máximo aceptable.

62. Reducción de granularidad

Synthetic User podrá reducir granularidad cuando exista riesgo de reidentificación, baja muestra, baja cobertura, variable sensible, población vulnerable, sector regulado, riesgo de daño, fuente incierta, sesgo alto o restricción contractual.

63. Datos obsoletos

Un dato podrá considerarse obsoleto cuando se publique una versión más reciente; cambie la metodología, el territorio, la fuente, la realidad social, el mercado, la regulación o la variable; se detecte error; venza licencia; se retire la fuente; o pierda relevancia para la finalidad.

64. Manejo de datos obsoletos

Cuando un dato sea obsoleto, Synthetic User podrá marcarlo como histórico; retirarlo de estudios nuevos; mantenerlo para análisis longitudinal; sustituirlo; reprocesar variables; reducir confianza; mostrar advertencia; bloquear su uso; conservarlo por auditoría; o eliminarlo según retención.

65. Datos históricos

Los datos históricos podrán usarse para tendencias, comparaciones, series temporales, simulación de evolución, estudios retrospectivos, validación, backtesting, análisis de cambios, contexto e investigación. No deben presentarse como datos actuales.

66. Datos experimentales

Los datos experimentales deben etiquetarse y usarse con cautela; no deben sustentar decisiones críticas; pueden cambiar sin aviso, ser retirados, tener baja cobertura, no estar validados, requerir revisión humana, no ser exportables y no estar cubiertos por garantías.

67. Metadatos obligatorios internos

Cada fuente relevante podrá registrar nombre; ID interno; país; entidad emisora; tipo y nivel de fuente; licencia; restricciones; URL o ubicación; fecha de publicación, de corte, de ingesta y de última validación; frecuencia esperada; versión; formato; variables; cobertura; calidad; riesgos; responsable interno; estado; próxima revisión; historial de cambios; y relación con estudios.

68. Metadatos visibles al cliente

Cuando sea viable, el cliente podrá ver fecha de corte; fecha de estudio; versión general; país; zona; sector; nivel de confianza; advertencias; estado de vigencia; tipo de fuente; si los datos son históricos o experimentales; si existe baja cobertura; si se recomienda validación; y si hay actualización disponible. No necesariamente se revelarán fuentes licenciadas, confidenciales o propietarias.

69. Propiedad intelectual del sistema de actualización

Son propiedad de Synthetic User, jsadsAI, José David Santamaría Corrales o sus licenciantes: pipelines de actualización; algoritmos de curaduría; scores de calidad; sistemas de versionado; taxonomías; ontologías; reglas de ponderación y de actualización; prompts internos; modelos; datasets curados; usuarios sintéticos base; metadatos internos; arquitectura de ingesta; sistemas de validación, de drift, de comparación y de trazabilidad; roadmap; y know-how. El cliente no adquiere derecho a copiar, extraer, revender, clonar o reconstruir estos sistemas.

70. Actualizaciones y propiedad de outputs

Una actualización de fuente, modelo o usuario sintético no transfiere al cliente propiedad sobre la fuente base, dataset curado, usuario sintético base, modelo, ponderaciones, metodología, pipeline, prompts, arquitectura ni sistemas de actualización. El cliente podrá usar outputs conforme a SUConsola, SUData, SUGarantia y contrato aplicable.

71. Actualización de reportes entregados

Los reportes entregados no se actualizan automáticamente salvo que el contrato lo indique; el plan lo incluya; exista SLA; exista error imputable a Synthetic User; Synthetic User lo decida; el cliente adquiera actualización; el reporte sea dinámico; el dashboard tenga actualización activa; el servicio sea suscripción con refresh incluido; o la ley o autoridad lo exija.

72. Dashboards dinámicos

Los dashboards dinámicos podrán actualizarse según plan contratado, fuentes disponibles, frecuencia de datos, APIs, licencias, capacidad técnica, créditos, SLA, módulo habilitado y sector. Un dashboard dinámico puede mostrar fecha de actualización distinta por variable.

73. Reportes estáticos

Los reportes estáticos representan una fecha, versión y configuración específica. No deben interpretarse como información actualizada permanentemente. Todo reporte estático debe idealmente incluir fecha de generación, fecha de corte, versión, alcance, advertencias, nivel de confianza, limitaciones y nota de no actualización automática.

74. Estudios recurrentes

Los estudios recurrentes podrán ejecutarse diaria, semanal, mensual, trimestral, semestral o anualmente; según evento; según contrato; según disponibilidad de fuente; o según créditos. Cada ejecución recurrente puede producir resultados diferentes.

75. Actualización por suscripción

Algunos planes de suscripción podrán incluir actualización periódica de usuarios sintéticos, fuentes, dashboards, reportes, variables, segmentos, modelos, alertas, estudios recurrentes y APIs. La frecuencia y alcance deben estar definidos en el plan.

76. Actualización empresarial

Los clientes empresariales podrán contratar actualización prioritaria; refresh mensual, semanal o diario; monitoreo por evento; reportes recurrentes; dashboards activos; integraciones API; procesamiento local; recalibración sectorial; datasets dedicados; usuarios sintéticos exclusivos; auditoría de fuentes; SLA de actualización; y soporte metodológico.

77. SLA de actualización

Cuando exista SLA de actualización, debe definir fuentes incluidas; frecuencia; ventanas de mantenimiento; tolerancias; excepciones; proveedores y APIs externas excluidos; tiempo de revisión y de corrección; créditos de servicio; responsabilidades del cliente y de Synthetic User; eventos de fuerza mayor; procedimiento de reclamación; y métricas de cumplimiento. Sin SLA firmado, no existe garantía de actualización en plazo específico.

78. Actualización local o dedicada

En procesamiento local o dedicado, la actualización podrá requerir infraestructura separada, conectores privados, transferencia segura, validación manual, revisión legal, anexo de datos, retención específica, aprobación del cliente, instalación técnica, costos adicionales, cronograma propio, control de acceso, auditoría, logs dedicados y seguridad reforzada.

79. Modelos de actualización de costos

Las actualizaciones pueden implicar costos por fuentes premium, APIs pagas, procesamiento, infraestructura, modelos de terceros, almacenamiento, limpieza de datos, curaduría, revisión humana, auditoría, procesamiento local, integraciones, soporte, reportes y reprocesamiento. No toda actualización está incluida en todos los planes.

80. Actualización y SUGarantia

SUGarantia aplica cuando una actualización falla por error técnico imputable; se cobra actualización no entregada; se prometió actualización específica en contrato; se genera cobro duplicado; se incumple SLA; se entrega fuente incorrecta; se detecta error material; se requiere crédito de servicio; o la ley exige remedio. No aplica reembolso automático por cambios normales de fuente, cambios de modelo, actualización de datos o evolución de resultados.

81. Actualización y SUData

Toda actualización debe respetar SUData. Esto implica base legal, minimización, finalidad, seguridad, derechos de titulares, no reidentificación, control de datos sensibles y de menores, retención, eliminación, transferencias, subencargados, gestión de incidentes, licencias y restricciones de uso.

82. Actualización y SUConsola

SUConsola podrá incorporar funciones para mostrar versiones y fecha de corte; mostrar advertencias; bloquear estudios; reducir granularidad; sugerir actualización; ejecutar refresh; comparar versiones; exportar reporte actualizado; mostrar confianza; registrar logs; gestionar permisos; activar alertas; consumir créditos; y solicitar revisión.

83. Actualización y SUWeb

SUWeb podrá comunicar capacidades generales de actualización, pero no debe prometer tiempo real universal; cobertura total; exactitud absoluta; actualización garantizada para todos los países; acceso permanente a todas las APIs; fuentes sin errores; resultados invariables; reprocesamiento gratuito; datos siempre recientes; ni disponibilidad de fuentes externas.

84. Comunicaciones sobre actualización

Synthetic User podrá informar actualizaciones mediante changelog, correo, dashboard, notificación en consola, reporte, estado de fuente, nota técnica, comunicado, ticket, contrato, reunión empresarial, documentación API, metadata, registro interno y alerta en output.

85. Changelog público o interno

El changelog podrá incluir nueva fuente incorporada; fuente retirada o corregida; modelo recalibrado; país o sector actualizado; variable modificada; error corregido; cambio metodológico; API degradada; nueva advertencia; nuevo score; nueva versión; cambio de licencia; y recomendación de reprocesamiento. Synthetic User podrá mantener ciertos cambios como internos por seguridad, confidencialidad o propiedad intelectual.

86. Confidencialidad de fuentes

Algunas fuentes, metodologías o datasets pueden ser confidenciales por licencia privada, contrato, NDA, proveedor, seguridad, propiedad intelectual, riesgo competitivo, restricciones de redistribución, datos empresariales o procesamiento local. Synthetic User podrá mostrar tipo de fuente o nivel de confianza sin revelar la fuente completa.

87. Fuentes de terceros y no aval

El uso de una fuente externa no significa que la fuente avale, patrocine o certifique Synthetic User; que participe en el estudio; que asuma responsabilidad por interpretaciones; que Synthetic User sea fuente oficial; que el output sea dato oficial; que el dato transformado conserve estatus oficial; que el proveedor apruebe todo uso del cliente; ni que la fuente garantice exactitud del estudio.

88. Responsabilidad del cliente sobre actualización

El cliente debe revisar fecha de corte, nivel de confianza y advertencias; solicitar actualización cuando necesite datos recientes; no usar reportes antiguos como actuales; no ocultar limitaciones ni eliminar disclaimers; no publicar resultados obsoletos sin contexto; no cargar datos desactualizados sin advertencia; no exigir exactitud absoluta; validar decisiones críticas; contratar refresh si lo requiere; informar cambios en datos propios y errores detectados; y usar outputs conforme a SUConsola y SUData.

89. Decisiones críticas

Los estudios actualizados no deben usarse como única base para decisiones críticas en salud, seguridad, política pública, defensa, crédito, educación, empleo, vivienda, seguros, justicia, migración, servicios públicos, procesos electorales, poblaciones vulnerables o derechos fundamentales. La actualización mejora la información disponible, pero no reemplaza revisión humana, legal, científica o profesional.

90. Publicación de resultados actualizados

Cuando el cliente publique resultados actualizados, deberá indicar fecha de corte y de generación; no presentarlos como dato oficial; no afirmar exactitud absoluta; mantener advertencias y contexto; indicar el carácter sintético o estimativo; no ocultar baja confianza; no usar datos obsoletos como vigentes; no distorsionar actualizaciones; no atribuir aval de fuentes externas; y no publicar información reidentificable.

91. Comparación entre versiones

Synthetic User podrá permitir comparación entre versiones. Las diferencias pueden deberse a nueva fuente; fuente corregida; cambio metodológico; recalibración; drift; nueva ponderación; cambio de variable; mejora de cobertura; eliminación de sesgo; cambio de contexto; actualización territorial o temporal; corrección de error; nueva segmentación; o cambio de modelo. Una diferencia entre versiones no implica necesariamente error.

92. Versiones congeladas

Los clientes empresariales podrán solicitar versiones congeladas para auditoría, reproducibilidad, investigación científica, comparación histórica, cumplimiento, reportes regulatorios, contratos, estudios longitudinales, evaluación metodológica y defensa legal. Las versiones congeladas pueden tener costo de almacenamiento, mantenimiento o custodia.

93. Retención de versiones

Synthetic User podrá conservar versiones anteriores durante un periodo razonable según plan, contrato, retención legal, necesidad de auditoría, costos, seguridad, propiedad intelectual, reclamaciones, compliance e interés metodológico. No se garantiza disponibilidad indefinida de todas las versiones.

94. Eliminación de versiones

Synthetic User podrá eliminar versiones cuando se cumpla retención; exista riesgo legal o de privacidad; exista instrucción de cliente; exista obligación de proveedor; exista orden legal; exista obsolescencia; exista costo desproporcionado; exista duplicidad; o exista riesgo de reidentificación.

95. Backup de actualizaciones

Los backups podrán conservar estados previos de datos, modelos o outputs. Los backups no son fuente activa; no garantizan restauración individual; pueden conservarse por ciclos técnicos; pueden estar cifrados; pueden ser inaccesibles al cliente; pueden eliminarse por rotación; pueden conservarse para seguridad o defensa legal; no deben usarse para nuevas finalidades; y se rigen por SUData.

96. Incidentes de actualización

Se considera incidente de actualización: error de ingesta; fuente corrupta; API caída; datos duplicados; esquema roto; variable mal mapeada; recalibración defectuosa; fuente retirada sin alerta; error de fecha de corte, de score o de etiqueta; error de visualización o de exportación; uso de fuente obsoleta sin advertencia; o actualización que genera riesgo de reidentificación.

97. Respuesta a incidentes de actualización

Synthetic User podrá detectar; clasificar; contener; suspender fuente; revertir versión; corregir; reprocesar; emitir errata; notificar; documentar; aplicar mitigación; revisar controles; actualizar procedimientos; emitir crédito si corresponde; y escalar legalmente si aplica.

98. Actualizaciones en fase beta

Las actualizaciones beta pueden ser inestables, cambiar rápido, contener errores, ser retiradas, no tener soporte completo ni garantía, no ser aptas para decisiones críticas, tener baja documentación, requerir feedback y estar limitadas a ciertos usuarios.

99. Roadmap de actualización

Synthetic User podrá desarrollar un roadmap interno o público sobre nuevos países, ciudades, fuentes, sectores, variables, modelos, APIs, dashboards, sistemas de calidad, funciones de auditoría, reportes, usuarios sintéticos y metodologías; y mejoras de precisión y seguridad. El roadmap no constituye obligación contractual salvo pacto expreso.

100. Actualización de países nuevos

Cuando Synthetic User incorpore un nuevo país, podrá requerir identificación de fuentes oficiales; evaluación legal local; evaluación de datos personales; evaluación de fuentes privadas y APIs; normalización territorial; traducción; taxonomía local; variables culturales, económicas y demográficas; validación metodológica; pruebas; score inicial; etiqueta experimental; revisión de sectores sensibles; contratos o licencias; documentación; changelog; y aprobación interna.

101. Actualización para entrada al mercado anglo

Para la entrada al mercado angloparlante, Synthetic User podrá adaptar fuentes; idioma; políticas; contratos; disclaimers; estándares de privacidad y de IA; metadatos; interfaces; reportes; etiquetas de confianza; fuentes oficiales y privadas; términos de API; y cumplimiento local. La expansión internacional no implica disponibilidad uniforme de todos los servicios.

102. Auditoría de actualización

Synthetic User podrá auditar fuentes; licencias; procesos de ingesta; logs; cambios; versiones; scores; modelos; usuarios sintéticos; estudios; outputs; errores; sesgos; drift; reprocesamientos; incidentes; reclamaciones; cumplimiento de SUData; cumplimiento contractual; y cumplimiento de APIs.

103. Auditoría externa

Clientes empresariales podrán solicitar auditoría externa bajo contrato específico. La auditoría podrá limitarse por confidencialidad, propiedad intelectual, seguridad, licencias, datos de terceros, datos de otros clientes, secretos comerciales, restricciones de proveedor, costos y alcance contratado.

104. Documentación metodológica

Synthetic User podrá documentar fuentes; tipos de variables; fechas; niveles de confianza; supuestos; limitaciones; métodos de actualización; cambios; versiones; advertencias; reglas de uso; exclusiones; restricciones; recomendaciones; y riesgos. La documentación completa puede ser interna, pública, contractual o restringida.

105. Model cards y data cards

Synthetic User podrá usar documentos tipo model cards, data cards, source cards, dataset sheets, study sheets, version sheets, quality sheets, risk sheets, audit sheets y update sheets. Estos documentos pueden mejorar trazabilidad y confianza, sin revelar propiedad intelectual sensible.

106. Contacto para actualización y calidad

• Canal único (calidad de datos, actualizaciones, soporte, legal y privacidad): ceo@jsadsai.com
• Responsable: José David Santamaría Corrales · Sitio: SyntheticUser.jsadsAI.com

107. Declaración final de SUActivo

El usuario o cliente reconoce que Synthetic User opera mediante fuentes, datos, modelos, usuarios sintéticos y procesos de actualización que evolucionan con el tiempo.

El usuario entiende que la actualización continua busca mejorar fidelidad, calidad, cobertura y utilidad de los estudios, pero no garantiza exactitud absoluta, actualización en tiempo real universal, disponibilidad permanente de fuentes externas ni resultados idénticos entre versiones.

El usuario acepta que cada estudio debe interpretarse según su fecha de corte, versión, fuentes, nivel de confianza, advertencias y finalidad. El uso de Synthetic User implica aceptación plena de SUActivo.

Anexos operativos

Anexo A — Leyenda para reportes actualizados

Este reporte fue generado por Synthetic User By jsadsAI | José Santamaría usando usuarios sintéticos, fuentes legalmente admisibles, modelos algorítmicos y procesos de curaduría. Los resultados corresponden a la fecha de corte, versión y configuración indicadas. No constituyen dato oficial, garantía de exactitud absoluta ni decisión final autónoma. Las fuentes, modelos y usuarios sintéticos pueden actualizarse posteriormente, generando resultados distintos.

Anexo B — Leyenda para reportes históricos

Este reporte corresponde a un snapshot metodológico generado en una fecha específica. Puede no reflejar actualizaciones posteriores de fuentes, modelos, variables o usuarios sintéticos. Para decisiones actuales, se recomienda ejecutar una nueva versión del estudio o solicitar actualización.

Anexo C — Checkbox antes de ejecutar estudio

Confirmo que entiendo que este estudio se ejecutará con las fuentes, modelos, usuarios sintéticos y versiones disponibles al momento de procesamiento. Entiendo que futuras actualizaciones pueden modificar resultados y que los outputs deben interpretarse según fecha de corte, nivel de confianza y advertencias metodológicas.

Anexo D — Checkbox para actualización bajo demanda

Solicito actualización, refresh o reprocesamiento bajo demanda. Entiendo que esta operación puede consumir créditos, generar costos adicionales, cambiar resultados anteriores y depender de disponibilidad de fuentes, APIs, licencias, modelos y validación técnica.

Anexo E — Formulario interno de alta de fuente

Anexo F — Formato de changelog

Anexo G — Estados de fuente

Anexo H — Matriz de decisión de actualización