MHMDA para herramientas de salud con IA: cuándo un evaluador de síntomas con LLM, un chatbot de salud mental con inteligencia artificial (IA) o un entrenador de fitness con IA se convierte en entidad regulada
Si su producto de IA responde preguntas de salud, bienestar, síntomas, salud mental, fertilidad, sueño o medicamentos para usuarios de Washington, MHMDA lo alcanza, sea o no el insumo un registro "médico". El estatuto cuenta las inferencias como Consumer Health Data. Un LLM que recibe prompts ordinarios y genera una hipótesis de estado de salud está generando Consumer Health Data sobre la marcha. Eso por sí solo arrastra las herramientas de IA al Capítulo 19.373 RCW, con el puente per se hacia el Consumer Protection Act bajo RCW 19.373.090. Este hub es el mapa práctico de cumplimiento para productos de salud con IA: alcance, política de privacidad separada, consentimiento de dos capas, contratos con proveedores y procesadores (OpenAI, Anthropic, APIs de terceros), exposición de datos de entrenamiento, y la prohibición de geofence.
El problema de la inferencia: por qué "solo somos un asistente de IA" no lo libra de MHMDA
El punto más comúnmente pasado por alto en revisiones del lado del operador para productos de salud con IA es que RCW 19.373.010 define Consumer Health Data como "información personal que está vinculada o razonablemente vinculable a un consumidor y que identifica el estado de salud física o mental pasado, presente o futuro del consumidor," y esa definición incluye expresamente "cualquier información que sea derivada o extrapolada de información que no es de salud." Un LLM que recibe un prompt como "me he sentido cansado y ansioso durante dos semanas, ¿qué podría estar pasando?" y devuelve una lista de explicaciones plausibles está extrapolando estado de salud a partir de un insumo no relacionado con la salud. La salida es Consumer Health Data. Y también lo es el propio prompt, una vez que el modelo lo ha clasificado como consulta de salud y el sistema ha almacenado la clasificación. El producto puede ser un chatbot de propósito general, un bot de servicio al cliente que ocasionalmente responde preguntas de salud, o un entrenador de fitness con IA que infiere calidad del sueño a partir de datos de frecuencia cardíaca. Los tres caen dentro de RCW 19.373.010 por la vía de la inferencia.
Ocho páginas, un mapa de cumplimiento
- Cumplimiento MHMDA para evaluadores de síntomas con IA: alcance, riesgo de inferencia, contraindicaciones para triage directo al consumidor.
- Cumplimiento MHMDA para chatbots de salud mental con IA: la categoría de producto de mayor riesgo bajo RCW 19.373.010, incluyendo inferencias de estado emocional.
- Cumplimiento MHMDA para entrenadores de fitness con IA: cómo las inferencias de pasos, frecuencia cardíaca, sueño y recuperación cruzan la línea de Consumer Health Data.
- Política de privacidad de datos de salud con IA: la política independiente requerida por RCW 19.373.020, reescrita para entradas de IA, uso del modelo, entrenamiento y APIs de terceros.
- Flujo de consentimiento para herramientas de salud con IA: construir el régimen de consentimiento de dos capas de RCW 19.373.030 en una UX real.
- Contratos con proveedores y procesadores de salud con IA: OpenAI, Anthropic, Azure OpenAI y APIs de IA aguas abajo como procesadores bajo RCW 19.373.060.
- Lista de verificación legal para startups de salud con IA: lista de verificación en etapa fundadora alineada con MHMDA, más los riesgos específicos de IA que los inversionistas preguntarán.
- Analizador MHMDA para herramientas de salud con IA (calculadora interactiva).
Los cinco anclajes de cumplimiento específicos de IA bajo el Capítulo 19.373 RCW
1. Las inferencias son Consumer Health Data. RCW 19.373.010 alcanza "información que se deriva o extrapola de información que no es de salud." Si su modelo clasifica una consulta del usuario como relacionada con la salud, genera una explicación probabilística, o almacena la clasificación como metadatos, esa salida es Consumer Health Data. La postura genérica de SaaS ("no recopilamos datos de salud, solo somos un producto de chat") no sobrevive la vía de la inferencia.
2. Los prompts y registros de conversación son datos recopilados. Una vez que un usuario ingresa un prompt sobre un síntoma, patrón de sueño, estado de ánimo, medicamento o fertilidad, y el sistema retiene el prompt, eso es recopilación de Consumer Health Data bajo RCW 19.373.030. Se requiere consentimiento afirmativo para la recopilación antes del almacenamiento, y se requiere un consentimiento separado para cualquier compartición con terceros.
3. Usar prompts para entrenamiento del modelo es un evento de compartición con alto riesgo de auditoría. Si sus términos con OpenAI, Anthropic, u otro proveedor de modelos permiten al proveedor usar los datos enviados para mejorar modelos, ese arreglo es una compartición de Consumer Health Data. RCW 19.373.030(1)(b) requiere un consentimiento separado para la compartición, distinto del consentimiento de recopilación. La mayoría de los términos de SaaS para consumidores no exponen una opción de exclusión de entrenamiento a nivel del usuario, lo cual es la brecha de cumplimiento.
4. Las APIs de IA de terceros son procesadores. Cuando su aplicación envía el prompt de un usuario de Washington a OpenAI, Anthropic, Azure OpenAI, o cualquier API de modelo externo, ese proveedor está procesando Consumer Health Data en su nombre. RCW 19.373.060 requiere un contrato vinculante que establezca las instrucciones de procesamiento, limite las acciones permitidas, y obligue al procesador a asistir con sus obligaciones. Los términos de servicio estándar de las APIs normalmente no satisfacen esto por sí solos; se requiere un addendum escrito de DPA o un proveedor que publique un addendum compatible con MHMDA.
5. Adtech y analítica dentro del producto son una superficie de riesgo separada. Si su producto de IA carga Google Analytics, Meta Pixel, Mixpanel, o cualquier SDK de terceros que observe consultas de usuarios o metadatos de sesión, esos SDKs pueden estar compartiendo datos de salud inferidos. La prohibición de geofence bajo RCW 19.373.080 prohíbe cualquier límite virtual dentro de 2,000 pies de una instalación de atención médica usada para identificar consumidores que buscan servicios de salud, recopilar Consumer Health Data, o enviar notificaciones. Las configuraciones de adtech que apuntan a radios de instalaciones de atención médica están categóricamente fuera del menú.
Por qué "no estamos cubiertos por HIPAA" no es una defensa
HIPAA alcanza a entidades cubiertas (planes de salud, cámaras de compensación, proveedores que transmiten información de salud electrónicamente en transacciones HIPAA) y sus business associates. La mayoría de los productos de salud con IA están fuera del perímetro de HIPAA: son apps directas al consumidor, no proveedores. MHMDA fue diseñada para llenar esa brecha. La exención en RCW 19.373.100 es específica de datos, no general de entidades. Una app de bienestar que no está cubierta por HIPAA no puede reclamar una exención HIPAA. Un proveedor de telesalud cubierto por HIPAA para PHI clínico no puede extender esa cobertura a píxeles de marketing en una landing page pública.
Lo que reviso cuando llega un producto de salud con IA
- Alcance: ¿sirve usted a usuarios de Washington, y la salida de su modelo alguna vez equivale a una inferencia de estado de salud bajo RCW 19.373.010?
- Política de privacidad: ¿Consumer Health Data Privacy Policy independiente bajo RCW 19.373.020, enlazada de forma prominente desde la homepage de un modo que sobrevive al colapso móvil?
- UX de consentimiento: ¿dos consentimientos afirmativos bajo RCW 19.373.030, con el consentimiento de compartición distinto del consentimiento de recopilación?
- Stack de proveedores: ¿términos de API con OpenAI, Anthropic, Azure OpenAI, o cualquier proveedor de modelo externo, más un addendum escrito de procesador bajo RCW 19.373.060?
- Exposición de datos de entrenamiento: ¿el contrato por defecto de su proveedor usa los datos enviados para entrenar modelos, y eso se expone a los usuarios con un consentimiento separado de compartición?
- Analítica y adtech: cualquier SDK que pueda observar prompts relacionados con la salud; cualquier geofence de campaña dentro de 2,000 pies de una instalación de atención médica bajo RCW 19.373.080.
Nota práctica de Sergei
La mayoría de los fundadores de IA que reviso llegan convencidos de que MHMDA no aplica porque "no son un producto de salud." La vía de la inferencia de RCW 19.373.010 es lo que los atrapa. Una vez que un usuario de Washington escribe "he estado ansioso últimamente" y el modelo devuelve una respuesta estructurada, el sistema está procesando Consumer Health Data. La forma más rápida de hacer triage es ejecutar el Analizador MHMDA para herramientas de salud con IA, luego enviarme la URL de la política de privacidad, capturas de pantalla del UX de consentimiento, y su contrato con el proveedor de IA. La Consulta escrita con abogado de $240 (Written Attorney Consultation) es el punto de partida adecuado; el memo de alcance de $499, el memo más lenguaje DPA de $900, o el memo más política independiente redactada de $1,500 siguen si las brechas son materiales.
Recurso educativo. Sergei Tokmakov es abogado de California (CA Bar #279869) actualmente buscando admisión al Washington State Bar. Nada en esta página crea una relación abogado-cliente ni constituye asesoría legal de Washington. La revisión MHMDA para productos de salud con IA es trabajo de asesoría regulatoria bajo licencia de California. Relacionado: Hub MHMDA de Washington; Analizador de alcance MHMDA; Verificador de brechas en política de privacidad; Guía de términos SaaS de Washington.