Ficha de datos
Este documento es el complemento orientado a la gobernanza de la declaración de datos. Mientras la declaración de datos proporciona la ficha completa del conjunto de datos según la estructura del Google Data Cards Playbook, este documento se centra en la trazabilidad de la procedencia, la postura de licenciamiento y la alineación regulatoria. Léase junto con la ficha del modelo y la postura regulatoria.
Descripción general
Section titled “Descripción general”La distribución publicada incluye dos conjuntos de datos sintéticos, ambos confirmados como JSONL bajo control de versiones:
- Corpus de evaluación — casos conversacionales multiturno curados en tres configuraciones regionales (en, es-419, pt-BR). Los casos cubren las categorías dorada, adversarial y de sin coincidencia con el comportamiento esperado de etiqueta dorada por turno.
- Tarjetas de la base de conocimiento — tarjetas estructuradas breves sobre contenido de adherencia a la medicación,
cada una con metadatos de procedencia (
source_url,accessed_at,source_license).
Ambos conjuntos de datos son 100% sintéticos, no contienen PHI ni PII, y son redistribuibles bajo la licencia MIT. El código circundante es Apache-2.0.
Procedencia de los datos
Section titled “Procedencia de los datos”Corpus de evaluación
Section titled “Corpus de evaluación”| Propiedad | Valor |
|---|---|
| Formato | JSONL (un objeto JSON por línea) |
| Tamaño | 315 casos (105 en, 105 es-419, 105 pt-BR) |
| Generación | Generación alineada a persona/guion por LLM con bucle productor-crítico |
| Curaduría | 100% de revisión manual por el autor |
| Semillas adversariales | 25 redactadas a mano en inglés más porciones adversariales en es-419/pt-BR |
| Licencia | MIT |
La metodología de generación sigue un pipeline de cuatro etapas: creación de personas (cinco grupos de condiciones muestreados de rangos epidemiológicos publicados), generación de diálogos con puntuación productor-crítico sobre la fidelidad a la entrevista motivacional, el cumplimiento del alcance y la fundamentación, curaduría manual de cada turno generado e inyección de casos adversariales redactados a mano. La metodología completa se documenta en la declaración de datos.
Tarjetas de la base de conocimiento
Section titled “Tarjetas de la base de conocimiento”| Propiedad | Valor |
|---|---|
| Formato | JSONL (id, title, text, source_url, source_license, topics, accessed_at) |
| Tamaño | 38 tarjetas |
| Licencia | MIT (contenido parafraseado) |
Cada tarjeta es un resumen estructurado breve parafraseado de fuentes de dominio público:
- DailyMed (FDA Structured Product Labeling) — obra del Gobierno de EE. UU., dominio público
- MedlinePlus (US National Library of Medicine) — obra del Gobierno de EE. UU., dominio público
- WHO Essential Medicines List — consultada para la selección de medicamentos; el contenido de las tarjetas se parafrasea de forma independiente, nunca textualmente
Una auditoría de licencias por fuente acompaña a los datos sintéticos. Las tarjetas sin procedencia fallan la validación al momento de la carga.
Corpus excluidos
Section titled “Corpus excluidos”Los siguientes corpus se excluyen explícitamente de la distribución en cualquier forma:
- MedDialog (licencia de uso solo académico)
- ChatDoctor / HealthCareMagic-100K (prohibición de redistribución en los términos de servicio)
- MIMIC-IV / MIMIC-IV-Note (el DUA de PhysioNet prohíbe la redistribución)
- i2b2 / n2c2 (el DUA institucional prohíbe la redistribución)
- Asclepius (CC-BY-NC-SA incompatible con la redistribución permisiva)
Categorías de datos
Section titled “Categorías de datos”El corpus de evaluación se organiza en tres categorías en todas las configuraciones regionales:
| Categoría | Descripción |
|---|---|
| Dorada | Conversaciones de adherencia a la medicación dentro del alcance |
| Adversarial | Intentos de dosificación, diagnóstico, inyección de prompts y coerción de rol |
| Sin coincidencia | Preguntas clínicas sin coincidencia de tarjeta de KB |
La porción en inglés (105 casos) tiene el mismo tamaño que cada porción no inglesa; las porciones es-419 y pt-BR (105 casos cada una) incluyen cobertura tanto dorada como adversarial. La base de conocimiento comprende 38 tarjetas de contenido de adherencia a la medicación.
Resumen de licenciamiento de fuentes
Section titled “Resumen de licenciamiento de fuentes”| Fuente | Licencia | Uso en la distribución |
|---|---|---|
| DailyMed | Dominio público (Gob. de EE. UU.) | Contenido parafraseado de tarjetas de KB |
| MedlinePlus | Dominio público (Gob. de EE. UU.) | Contenido parafraseado de tarjetas de KB |
| WHO Essential Medicines List | CC-BY-NC-SA | Referencia para la selección de medicamentos; contenido parafraseado de forma independiente |
| Diálogos generados por LLM | MIT | Sin entrada con derechos de autor; salidas redistribuibles bajo MIT |
| Código | Apache-2.0 | Independiente de la licencia de datos |
Estado actual
Section titled “Estado actual”Esta implementación de referencia opera con datos 100% sintéticos. Ningún dato real de pacientes, ningún dato real de EHR y ninguna información identificable entra en la distribución en ningún momento. La verificación de aceptación de datos en CI rechaza cualquier archivo que no haya pasado una revisión de identificabilidad.
Controles de gobernanza de datos clave que existen hoy:
- Política exclusivamente sintética: aplicada por el flujo de contribución y documentada en la declaración de datos
- Metadatos de procedencia: cada tarjeta de KB lleva
source_url,accessed_atysource_license; el cargador rechaza las tarjetas sin procedencia - Paridad entre configuraciones regionales: el arnés de evaluación sujeta en, es-419 y pt-BR a umbrales idénticos en cada ejecución de CI
- Control de versiones: los archivos de datos son JSONL confirmado, versionado junto con el código bajo versionado semántico; los cambios al corpus de evaluación o la KB están controlados por compuertas
- Declaración de IRB: sin datos de sujetos humanos; la aprobación del IRB no aplica (véase la sección IRB de la declaración de datos)
Limitaciones conocidas heredadas de la declaración de datos:
- Corpus de dominio único; la cobertura es intencionalmente estrecha
- Sesgo de vocabulario clínico en inglés estadounidense en los datos sintéticos, corregido parcialmente por el bucle productor-crítico pero documentado como residual
- Las tarjetas de KB están en inglés; una KB localizada está en la hoja de ruta
- Las preguntas clínicas casi fuera de corpus no se rechazan de forma confiable (véase la ficha del modelo, “Riesgos y limitaciones conocidos”)
Subprocesadores y manejo de datos
Section titled “Subprocesadores y manejo de datos”Los siguientes servicios externos reciben datos derivados de solicitudes de esta implementación. Todas las divulgaciones se basan en los términos públicos del proveedor al 2026-06-09 (la fila de Langfuse Cloud se reverificó el 2026-07-14). No se ha ejecutado ningún DPA ni BAA para esta demo, que opera con datos 100% sintéticos y no maneja PHI.
| Subprocesador | Punto de salida | Categoría de datos | Postura de entrenamiento / retención | Certificaciones (anunciadas) |
|---|---|---|---|---|
Inferencia LLM (completado): OpenAI gpt-4o-mini (primaria), Anthropic claude-haiku-4-5 (respaldo) | llamada a la API de completado en el camino en vivo /chat | Prompt redactado más el contexto de KB recuperado | Sin entrenamiento con datos de la API por defecto; las entradas/salidas se retienen hasta ~30 días para monitoreo de abuso y luego se eliminan; retención de datos cero disponible bajo términos enterprise | SOC 2 Tipo II / HIPAA (BAA) / GDPR (anunciadas; con acceso restringido) |
Voyage AI - embeddings voyage-3.5 + reranking rerank-2.5 | llamada a la API de embedding; llamada a la API de reranking | Texto de consulta redactado | El contenido está licenciado para entrenamiento por defecto a menos que el administrador de la organización opte por no participar; la exclusión proporciona retención de cero días en el posprocesamiento (prospectiva solamente) | SOC 2 Tipo II / HIPAA / GDPR (con acceso restringido). Subprocesadores: AWS + Google LLC |
| Langfuse Cloud - telemetría OTLP (sumidero de la demo en vivo) | exportador de telemetría / trazas | Solo atributos de span; el texto del mensaje del usuario nunca se escribe en un span (invariante de privacidad forzado); valores de entrada/salida redactados | Sin entrenamiento con los datos de trazas del cliente; el nivel gratuito Hobby retiene 30 días con 50K observaciones/mes; los niveles de pago agregan retención configurable, enmascaramiento y eliminación de datos | SOC 2 Tipo II / ISO 27001 / GDPR (DPA) / controles HIPAA (BAA y región compatible con HIPAA, con acceso restringido). Región de datos: EE. UU. / UE / Japón seleccionable |
Las trazas de las corridas de evaluación se exportan a una instancia de Phoenix autohospedada (Docker Compose, retención solo de sesión, interfaz local). Como corre dentro del propio despliegue del operador y no recibe datos de solicitudes en vivo, no es un subprocesador externo; Arize AX se admite solo como un panel secundario opcional sobre el mismo flujo OTLP y no está habilitado en la demo.
Camino a producción: Ejecutar el DPA de cada proveedor, confirmar la disponibilidad de BAA, habilitar la exclusión del entrenamiento de Voyage a través del panel de administración de la organización, y re-verificar las listas de subprocesadores y la residencia de datos al momento del contrato.
Camino a producción
Section titled “Camino a producción”Un despliegue real que maneje datos de pacientes necesitaría aumentar o reemplazar los conjuntos de datos sintéticos y atender lo siguiente:
- Gobernanza de datos reales de pacientes: aprobación del IRB, consentimiento informado, acuerdos de tratamiento de datos y regulaciones de datos de salud específicas de cada jurisdicción (HIPAA, GDPR, Ley 19.628 de Chile, etc.)
- Expansión de la base de conocimiento clínica: el corpus de la demo cubre cinco grupos de condiciones; un sistema de producción necesitaría una KB validada clínicamente con revisión clínica regular, verificación de fuentes y comprobaciones de vigencia
- Monitoreo de calidad de datos: pipelines automatizados para detectar deriva de datos, brechas de cobertura y degradación de la calidad de las etiquetas tanto en el corpus de evaluación como en las tarjetas de KB
- Contenido localizado: revisión clínica en lengua nativa para cada configuración regional, no solo traducción de contenido generado en inglés; rutas de escalamiento clínico específicas de cada configuración regional
- Políticas de conservación y eliminación de datos: la implementación de referencia no tiene datos de usuario persistentes; producción necesitaría calendarios de conservación, procedimientos de eliminación y gestión de solicitudes de acceso de los titulares de datos
- Auditoría de sesgos: evaluación sistemática de la representación demográfica en los datos de entrenamiento y de evaluación, más allá de las verificaciones de paridad entre configuraciones regionales vigentes
Véase también
Section titled “Véase también”- Declaración de datos — ficha completa del conjunto de datos con metodología de generación
- Ficha del modelo — CHAI Applied Model Card del agente
- Postura regulatoria — límite FDA/WHO/MHRA/Reglamento de IA de la UE
- Evaluación de preparación para HIPAA — documento de gobernanza específico de HIPAA